Введение

Развитие электронной коммерции и маркетплейсов существенно изменило требования к складской логистике производственно-торговых компаний. Если ранее значительная часть заказов поступала из ограниченного числа каналов, то в современных условиях компания одновременно работает с собственным интернет-магазином, маркетплейсами, B2B-направлением, розничными продажами, телефонными и email-заявками. Такая модель взаимодействия с клиентами относится к омниканальной, поскольку предполагает обработку заказов из разных источников в рамках единого управляемого процесса.

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

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

В связи с этим актуальной является задача проектирования цифрового продукта, который позволит объединить данные о заказах, товарах, клиентах, складских остатках, заданиях, отгрузках, документах и доставке в единой информационной системе. В рамках настоящей статьи рассматривается методический подход к проектированию такой системы на примере цифрового продукта WG Logistic, предназначенного для мониторинга и контроля омниканальной отгрузки товаров со склада ООО «Гауф Рус».

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

1. Методический подход к проектированию информационной системы

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

В рассматриваемой задаче основой проектирования является сопоставление моделей AS-IS и TO-BE. Модель AS-IS описывает текущее состояние бизнес-процесса, то есть то, как отгрузка выполняется до внедрения проектируемой системы. Модель TO-BE отражает целевое состояние процесса, при котором основные операции автоматизированы, данные хранятся централизованно, а пользователи работают в едином цифровом контуре.

1.1. Анализ существующего процесса AS-IS

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

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

Дополнительной проблемой является отсутствие оперативного подтверждения складских операций. Если комплектовщик работает по бумажному листу, система не получает информацию о фактическом ходе отбора товара. Ошибка в артикуле, количестве или ячейке хранения может быть выявлена только на этапе проверки или после обращения клиента. Это снижает управляемость склада и затрудняет анализ причин ошибок. Существующий процесс показан моделью AS IS в нотации BPMN 2.0 на Рисунке 1.

Рис. 1

Таким образом, модель AS-IS показывает, что существующий процесс является последовательным, но недостаточно автоматизированным. Информация распределена между несколькими инструментами, а контроль процесса зависит от ручных действий сотрудников.

1.2. Формирование целевой модели TO-BE

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

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

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

Рис. 2

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

1.3. Структура модулей информационной системы

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

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

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

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

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

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

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

1.4. Проектирование базы данных

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

Логическую модель базы данных целесообразно представить в нотации Crow’s Foot, так как она позволяет наглядно отразить сущности, атрибуты и связи между ними. Центральной сущностью модели является Order, содержащая сведения о заказе: внутренний идентификатор, внешний номер, канал продаж, клиента, текущий статус, дату создания, срок отгрузки и сумму. Сущность OrderItem описывает состав заказа и связывает заказ с товарами.

Товарно-складская часть базы данных включает сущности Product, Warehouse, StorageLocation и StockBalance. Они позволяют хранить номенклатуру товаров, структуру складов, ячейки хранения, доступное и зарезервированное количество. Эти данные используются при проверке возможности отгрузки и формировании складских заданий.

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

Логистический блок представлен сущностями Shipment, Carrier, ShipmentStatus и TrackingEvent. Они обеспечивают хранение информации о перевозчике, трек-номере, стоимости доставки, датах передачи и доставки, а также истории статусов отправления. Блок документов и уведомлений представлен сущностями Document, DocumentType, Notification, NotificationType и NotificationStatus. Для обеспечения контроля действий пользователей применяется сущность AuditLog.

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

1.5. Показатели эффективности процесса

Для оценки эффективности проектируемой информационной системы используются количественные показатели. Они позволяют сравнить текущее и целевое состояние процесса, а также контролировать работу системы после внедрения.

Полное время исполнения заказа определяется как сумма времени выполнения основных этапов:

(1)

Где — полное время исполнения i-го заказа; — время приема заказа; — время резервирования товара; — время формирования складского задания; — время комплектации; — время упаковки и оформления отгрузки; — время доставки или передачи в канал доставки.

Среднее время исполнения заказов за период рассчитывается по формуле:

(2)

где n — количество заказов за анализируемый период.

Коэффициент соблюдения SLA показывает долю заказов, выполненных в нормативный срок:

(3)

где — количество заказов, выполненных в срок; N_{all} — общее количество обработанных заказов.

Коэффициент ошибок комплектации определяется как отношение количества заказов с ошибками к общему количеству заказов:

(4)

где — количество заказов с ошибками комплектации, упаковки или маркировки.

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

(5)

где — количество автоматизированных операций; — общее количество операций процесса.

Интегральный показатель эффективности процесса может быть представлен в виде:

(6)

где E — интегральная эффективность процесса; K_{info} — коэффициент информационной прозрачности; , , , — весовые коэффициенты значимости показателей.

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

2. Проектная апробация предлагаемого подхода

Предлагаемый подход был применен при проектировании цифрового продукта WG Logistic для мониторинга и контроля омниканальной отгрузки товаров со склада ООО «Гауф Рус». В ходе проектирования были определены участники процесса, входные и выходные данные, основные модули системы, структура базы данных и пользовательские интерфейсы.

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

На этапе формирования целевой модели был разработан бизнес-процесс TO-BE в нотации BPMN 2.0. В модели были выделены дорожки участников: каналы продаж, информационная система WG Logistic, склад и ТСД, перевозчик, централизованная база данных. В процесс включены события поступления заказа, задачи консолидации, проверки, резервирования, формирования задания, отбора через ТСД, упаковки, создания отправления, мониторинга доставки и закрытия заказа. Взаимодействие с базой данных отражено через операции записи и обновления данных о заказах, остатках, заданиях, отгрузках и статусах.

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

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

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

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

Заключение

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

Предложенная целевая модель TO-BE предусматривает создание единой информационной системы WG Logistic, обеспечивающей консолидацию заказов, автоматическую проверку данных, электронную диспетчеризацию складских заданий, применение терминалов сбора данных, оформление отгрузок, интеграцию с перевозчиками, мониторинг доставки, уведомления и KPI-аналитику.

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

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

Литература:

1. Object Management Group. Business Process Model and Notation (BPMN), Version 2.0: Specification. URL: https://www.omg.org/spec/BPMN/2.0/ (дата обращения: 16.05.2026).
2. BPMN.org. Business Process Model and Notation: official BPMN resource. URL: https://www.bpmn.org/ (дата обращения: 01.06.2026).
3. PostgreSQL Global Development Group. PostgreSQL Documentation: Constraints. URL: https://www.postgresql.org/docs/current/ddl-constraints.html (дата обращения: 16.05.2026).
4. PostgreSQL Global Development Group. PostgreSQL Documentation: Data Types. URL: https://www.postgresql.org/docs/current/datatype.html (дата обращения: 16.05.2026).
5. ISO. ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection — Information security management systems — Requirements. URL: https://www.iso.org/standard/27001 (дата обращения: 16.05.2026).
6. Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных»: официальный текст. URL: http://www.kremlin.ru/acts/bank/24154 (дата обращения: 16.05.2026).
7. Грекул В. И., Денищенко Г. Н., Коровкина Н. Л. Проектирование информационных систем. М.: Интернет-Университет Информационных Технологий, 2008.
8. Карпова Т. С. Базы данных: модели, разработка, реализация. СПб.: Питер, 2001.
9. Смирнов М. В. Управление данными: учебно-методическое пособие. М.: РТУ МИРЭА, 2020.
10. Балдин К. В., Уткин В. Б. Информационные системы в экономике. М.: Дашков и К, 2020.
11. Waters D. Logistics: An Introduction to Supply Chain Management. London: Palgrave Macmillan, 2003.
12. Rushton A., Croucher P., Baker P. The Handbook of Logistics and Distribution Management. London: Kogan Page, 2022.