Forward East CRM

Система покрывает сквозной процесс от заявки клиента до отгрузки. Модули связаны общей доменной моделью: подтверждённая сделка автоматически порождает производственную заявку, готовая продукция — рейс в логистическом модуле. Статусы транслируются между модулями по событиям, поэтому менеджер продаж видит этап перевозки, а производство — план продаж без ручных запросов и сверок.

Основная задача ядра — прогнозирование: модели на TensorFlow обучаются на исторических данных по сделкам, рейсам и производственным заявкам и оценивают будущий спрос и загрузку направлений. Поверх прогнозов работает приоритизация — система подсказывает, какие сделки и заявки требуют внимания в первую очередь. Модели регулярно переобучаются, поэтому качество прогнозов растёт по мере накопления данных.

Международность заложена на уровне модели данных, а не поверх неё. Суммы в сделках и документах хранятся с указанием валюты, время — в UTC с корректным отображением в поясе пользователя средствами Django и PostgreSQL. Данные разграничены по юрлицам холдинга. Распределённые команды работают в общем пространстве с едиными статусами, но каждая площадка видит привычные валюту и локальное время.

Для бизнеса это непрерывность работы. Обновления выкатываются без остановки системы, упавший сервис автоматически перезапускается, а под пиковую нагрузку кластер выделяет ресурсы сам. Отдельный плюс для проекта с ИИ: ресурсоёмкое переобучение моделей масштабируется независимо от веб-части и не замедляет работу менеджеров. Для холдинга это ещё и предсказуемое развёртывание новых окружений из одних и тех же образов.

Доступ построен на ролевой модели по принципу минимальных привилегий: права выдаются по направлению, компании и функции сотрудника, а действия пользователей фиксируются в журнале аудита. Данные юрлиц холдинга разграничены на уровне запросов, доступ к системе — только по защищённым соединениям. Тот же режим конфиденциальности распространяется и на нас: команда работает под NDA, а кейс публикуется без имени клиента и его показателей.

Поэтапно, модуль за модулем. Сначала на реальных данных заработала связка продаж и логистики, затем подключались производство, аналитика и международный контур. Исторические данные переносились скриптами миграции с проверкой целостности, ключевые пользователи проходили обучение до переключения своего участка. Старые инструменты выводились из работы только после того, как направление стабильно работало в новой системе.

Да, архитектура модульная, и контур собирается под задачу: транспортной компании достаточно логистики, продаж и аналитики, производственной — производственного планирования и продаж. ИИ-ядро подключается позже, когда накопится история для обучения моделей. Инфраструктуру тоже можно упростить: вместо кластера Kubernetes на старте хватает одного сервера с Docker — с понятным путём масштабирования по мере роста.