Разработка ПО для логистики

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

Иметь собственную систему не означает, что нужно дублировать все функции рынка. В первой версии должны быть только те операции, которые влияют на ежедневный процесс: получение заказов, распределение, управление статусами, документы и исключения. Остальная функциональность может быть добавлена позже, когда команда получит информацию об использовании. Это помогает избежать риска потратить бюджет на ненужные функции.

Разработка TMS связана с управлением транспортом. Такая система позволяет управлять заказами и заданиями на перевозку, назначать транспорт и водителей, контролировать доставку, хранить документы и генерировать отчеты. Планирование маршрутов может учитывать доступность транспорта, тип груза, временные рамки и ограничения направлений.

Конкретная функциональность TMS зависит от уже автоматизированных операций. Одна компания может требовать интерфейса диспетчера и обмена данными с учетной системой. Другая компания может нуждаться в работе с несколькими перевозчиками и порталом клиента. Важно заранее установить, какая система хранит первоначальные данные заказа, а какая управляет исполнением заказа.

Разработка WMS помогает управлять складскими процессами: приемкой, размещением, комплектацией, перемещением, отгрузкой и остатками. Система формирует задачи для сотрудников, хранит статусы операций и передает данные в другие части логистического контура. Набор функций зависит от схемы склада, номенклатуры, правил хранения и обработки заказов.

Перед включением WMS в проект необходимо проанализировать, какие операции выполняются в учетной системе и как сотрудники используют терминалы или веб-интерфейс. В некоторых случаях достаточно доработать текущее решение. В других случаях требуется отдельный модуль управления складом с четкой моделью ячеек, задач и статусов. Решение принимается после исследования, а не по названию продукта.

TMS обычно помогает управлять транспортировкой: заказами, маршрутами, транспортом, водителями и доставкой. WMS отвечает за операции внутри склада: приемку, хранение, комплектацию и отгрузку. Эти системы могут работать отдельно, но в одном логистическом процессе они часто требуют согласованного обмена данными.

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

Разработка приложений для логистики начинается с роли пользователя, а не с выбора платформы. Водителю нужны задания на перевозку, адреса, статусы, документы и уведомления. Экспедитору или складскому работнику нужны подтверждения операций и работа с задачами. Клиенту нужен доступ к своим заказам, документам и статусу доставки. Менеджеру нужны отчеты и мониторинг эффективности в согласованном объеме.

Мобильный доступ не всегда должен включаться в первую версию. В некоторых случаях достаточно адаптивного веб-интерфейса, в других случаях работа в пути требует отдельного приложения. Тогда команда анализирует сценарии работы без подключения, авторизацию, передачу документов и требования к устройствам. Для мобильной разработки Nomium может использовать Flutter или React Native, если это подходит для задачи проекта.

В первую очередь мы проверяем системы, которые уже содержат критические данные: ERP, CRM, учетные сервисы, WMS, TMS, GPS-мониторинг и внешние сервисы перевозчиков. Для каждой интеграции нам нужно установить источник данных, формат обмена данными, частоту передачи, поведение в случае ошибок и ответственную сторону. Наличие API не гарантирует успешную интеграцию.

Интеграция WMS и TMS не должна создавать две копии одного и того же справочника или заказа. Если данные поступают из нескольких систем, архитектура должна установить, какой источник считается основным для каждого поля. Команда также анализирует доступные протоколы передачи данных, ограничения внешних сервисов и порядок тестирования. Это помогает снизить риск перепроектирования архитектуры после разработки интерфейсов.

Автоматизация транспортной компании начинается с описания процесса: прием заказов, назначение исполнителя, изменение маршрута, требования к документации и способ отслеживания статуса. Команда выявляет повторяющиеся действия, ручные сверки и моменты, в которых ошибка влияет на доставку, простой транспортного средства и взаимодействие с клиентом.

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

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

Минимальная версия обычно включает в себя роли пользователей и авторизацию, справочные данные, карточку заказа, назначение транспорта, историю статусов, интерфейс для сотрудников и взаимодействие с одной или несколькими ключевыми системами. Отчеты и аналитика добавляются по мере необходимости. Решения о дополнительных функциях принимаются на основе фактического использования системы.

Выбор технологий основывается на архитектуре, объеме данных, требованиях к надежности, интеграциям и развитию системы. Для фронтенда Nomium использует React и Angular. Для бэкенда используются C# / .NET, Node.js / NestJS и Rust. Для хранения данных используются PostgreSQL, MongoDB и другие широко используемые базы данных. Kubernetes и облачная инфраструктура используются для работы и масштабирования системы.

Этот список не является шаблоном для каждого проекта. На этапе проектирования команда анализирует модель данных, права доступа, взаимодействие с внешними системами, мониторинг и способ развертывания. Это позволяет принимать технические решения до разработки основных модулей.

Прежде всего команда проводит исследование. На этом этапе Nomium разбирает цели, участников процесса, источники данных, существующие системы и ограничения. Результатом становится согласованный объем работ для первого релиза, список проверяемых рисков и последовательность работ. Затем команда разрабатывает модель данных, роли, интерфейсы и интеграции.

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

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

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

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

Поддержка и развитие требуют четкого порядка: кто сообщает о проблеме, как она классифицируется, кто принимает решение о внесении изменений и как они проходят тестирование. Если система взаимодействует с внешними сервисами, то способ обработки ошибок при обмене данными согласовывается отдельно. Эта работа помогает поддерживать управляемость продукта, когда процессы, состав пользователей или объем заказов меняются.

Для первой встречи полезно подготовить краткое описание процесса, список используемых систем и участников, образцы заказов или документов, а также список проблем, которые команда хочет решить. Не нужно заранее готовить полное техническое задание. Важно показать, где есть ручные действия, задержки, несоответствия данных или неудобные действия для сотрудников и клиентов.

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