Блог

Метки: , , , , , , ,
19 Апр

Проблемное поле IT. Интеграция систем.

Здравствуйте, друзья! Известно, что рано или поздно любая торговая компания в своём развитии доходит до стадии выделения склада в самостоятельную организационную единицу, а также доходит до осознания необходимости применения WMS. В момент предшествующий внедрение WMS возникает необходимость обеспечить взаимодействие торговой (учетной) системы и WMS. Кроме того, возникает необходимость обеспечить взаимодействие систем управления транспортом и WMS, а также систем ведения сертификатов и WMS и так далее. 

Почему соединить системы не просто? Просто не желание, друзья! Очень часто встречается ситуация, когда различные «программисты 1С», сопровождающие системы Заказчика на основе «частичной занятости», банально не хотят вникать в суть организации обмена. А если вникают – не хотят трогать архитектуру конкретной инсталляции 1С. Чтобы «не дай бог чего не вышло». При этом для Заказчика выдумывается какая-нибудь наукообразная фигня, которая на деле означает только одно – система, которую использует Торговая компания – устроена архитектурно неверно, и организовать полное и корректное взаимодействие с внешней WMS не затрагивая этой архитектуры невозможно. Особенно в рамках требуемых сроков и бюджета. Я к тому, что при желании, осуществить интеграцию возможно и очень интересно! Тем более, что свобода на поле деятельности есть и вариантов много: 

Варианты организации взаимодействия систем

Задачу организации взаимодействия систем решают по-разному в зависимости от уровня понимания глубины проблемы конкретным программистом (или его руководителем), времени на реализацию системы обмена, культуры использования IT-технологий достигнутой компанией. На основе многолетних наблюдений как за процессом решения вопроса обмена данными, так и за его результатами можно выделить следующие возможные типовые взаимодействия.

Простейшее одностороннее взаимодействие

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

Расхождения в учёте устраняются спонтанно, героически и часто это сопровождается срывами и взаимными обвинениями.

Двустороннее взаимодействие без глубокой обработки ответов WMS

Торговая система не только посылает, но и принимает от WMS ответы.
При этом обрабатываются только два типа ответов:

  1. результаты приёмки
  2. результаты отгрузки

Транспортная система посылает в WMS информацию о маршрутах развоза. 

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

Расхождения в учёте устраняются спонтанно, героически, но часто в конструкцию обмена вносятся «костыли» с обеих сторон, которые улучшают ситуацию до того момента, пока сами «костыли» не помешают одной из систем. И так далее..

Полное взаимодействие

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

Транспортная система обрабатывает информацию о «недовозах» (возвратах с маршрута) – передает ответ в WMS.

Часто уже есть взаимодействие между системой ведения сертификатов и WMS.

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

High-end взаимодействие

Торговая система не только обрабатывает ответы, но и посылает в WMS различные «команды», влияющие на технологию приёмки и отбора:

  1. Для приходов и заказов – указание на кроссовую обработку (cross-docking).
  2. Получение информации из WMS о фактических размерах складских логистических единиц (паллет, коробов или иных носителей). Учёт полученной информации при выписке заказов на отгрузку.
  3. Управление отбором с округлением до складских единиц. Корректная обработка расхождений между планом и фактом (явные, обоснованные причины).
  4. Заказ на сборку содержит указания-требования к транспортному грузовому пакету: совместимость товаров при отборе, размер, вес, состав, последовательность и прочее.
  5. Торговая система посылает обрабатывает задания на инвентаризацию.
  6. Кроме того, торговая система корректно обрабатывает ситуации, о которых сообщает WMS (потери, находки товара, выбраковка и прочее).

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

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

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

Кстати – в последнее время я стал слышать фразу о том, что «все WMS одинаковы». Не согласен. Новость для соискателей состоит в том, что НЕ ВСЯКИЙ УРОВЕНЬ ОБМЕНА можно в принципе организовать с  «ЛЮБОЙ WMS».

Похожие записи

Оставить комментарий: