Как научить WMS общаться с внешними системами Дарья Любовина

Как научить WMS общаться с внешними системами Дарья Любовина

Как научить WMS общаться с внешними системами

Статья опубликована в журнале \"Директор информационной службы\"
Вы планируете внедрить на складе WMS и хотите, чтобы она стала органичной частью вашей информационной структуры? Хотите наладить взаимодействие между отделом продаж, складом и транспортом, исключив потери данных? Тому, что нужно сделать и о чем подумать, чтобы успешно решить эту важную задачу, и посвящена эта статья.  

Как научить WMS общаться с внешними системами

Статья опубликована в журнале "Директор информационной службы" №3, 2009 г.

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

Задача организации взаимодействия складской и корпоративной учетной системы присутствует практически всегда. Исключения могут быть связаны с автоматизацией складов ответственного хранения, для которых WMS исполняет роль основной бизнес-системы, где оформляются все коммерческие операции компании, поэтому необходимость в обмене иногда отсутствует. Тем не менее, и склады ответственного хранения в рамках проекта автоматизации часто организуют интеграцию со своими системами бухгалтерского учета, учетными системами поставщиков, транспортными системами и другими смежными информационными системами. Поэтому, обобщив имеющийся опыт, можно с высокой степенью уверенности сказать, что интеграция WMS и внешних систем – задача при автоматизации склада обязательная.
Обмен информацией – процесс не только необходимый, но и очень ответственный. WMS система является носителем наиболее точной и актуальной информации о состоянии остатков товара на складе, на которую опираются остальные информационные модули компании. Неустойчивая связь между системами, потеря данных в процессе обмена или некорректная их трактовка в системе-получателе чревата большими проблемами в работе склада и компании в целом. Поэтому разработке процесса интеграции необходимо уделить должное внимание. 
Процесс разработки интеграции между WMS и любой другой внешней системой состоит из трех типов задач: функциональных, технических и организационных. К функциональным задачам относятся определение состава синхронизируемой справочной информации, точек взаимодействия систем по каждому из процессов, интегрируемых бизнес-процессов, способов запуска обменных процессов и состава мигрирующей информации. Технические задачи – выбор технологии интеграции, определение форматов обмена и средств контроля механизма интеграции. Основная организационная задача заключается в обеспечении взаимодействия сторон при разработке и внедрении инструментов интеграции. 
Рассмотрим подробнее каждую из задач. В качестве примера возьмем наиболее распространенный вариант взаимодействия между системой WMS и торговой системой.

 

Функциональные задачи

Синхронизация данных

На первом этапе выясняется, какие данные необходимо синхронизировать в обеих системах для обеспечения корректного обмена данными. 
В первую очередь, это, конечно, каталог товаров, хранимых на складе. Кроме уникального идентификатора и наименования товара на складе часто нужны данные о фасовках товара с указанием кратности вложения единиц, их весогабаритные характеристики, штрихкоды и другая значимая для данного складского технологического процесса информация. Во избежание путаницы и дублирования в работе с товаром крайне желательно, чтобы ведение каталога товаров подчинялось жестким правилам и выполнялось только в одной системе – той, где работают менеджеры по закупкам, обладающие такой информацией. WMS в данной ситуации – ведомая система, которая может дополнять каталог своими специфичными данными (например, правила обработки), но не должна создавать новые позиции в списке товаров.
Кроме каталога товаров часто синхронизируются данные о контрагентах, иногда – о сотрудниках. Большего объема пересекающейся справочной информации обычно не требуется.
В результате работ по первому этапу должен быть составлен список справочной информации, необходимой в каждой из систем, и определена система-владелец каждого вида информации, которая будет управлять данными и передавать их системе-потребителю.
Эти работы необходимы, даже если существует единый источник данных – например, уже работающая торговая система. При появлении WMS иногда возникает искушение управлять новыми позициями справочников в обеих информационных базах, так как именно склад первым видит новый товар и может внести информацию о нем в систему. Если пойти на поводу у этой практики, то получим запутанный справочник товаров с задублированными позициями. В правильно построенном бизнес-процессе обработки нового товара информацию о нем первыми получают и вносят в систему закупщики. А склад уже может дополнить или исправить отдельные данные – такие как, например, вес или габариты товара. 

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

Синхронизация бизнес-процессов

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

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

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

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

Точки взаимодействия

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

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

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

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

В результате работ на этом этапе должны быть определены те события или документы (счета, накладные, листы отбора ...), их статусы (создан, записан, проведен, \"в работу\", \"на склад\"…), временные рамки их обработки и прочие значимые параметры, однозначно определяющие момент, когда каждая из систем должна (не должна) передать свои данные в другую систему.

Способы запуска обменных процессов 

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

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

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

В процессе подбора товара возможны различные отклонения: что-то не нашли, что-то нашли, но бракованное, или другого сорта и т.п. Отбор может идти в несколько итераций, и однозначно определить на каждой итерации, будет ли отбор продолжен или нет, могут только люди - ответственный за отбор заказа и менеджер клиента. Если в отборе проблем не возникло, то результат может быть передан в торговую систему автоматически, без участия пользователей. Если же были проблемы, то решение может быть принято самое разное – от полного отказа от заказа, если не найдена ключевая позиция, до отправки \"как есть\", если проблема незначительна. В таком случае результат отбора после выяснения всех обстоятельств подготовки и отправки заказа отправляется в корпоративную систему из WMS по сигналу пользователя. Для сторонников абсолютной автоматизации замечу, что эта схема, конечно же, – не единственно возможный вариант обработки отбора, но часто встречающийся на практике.

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

Состав мигрирующей информации 

Это относительно простой этап. Здесь нужно понять, какие данные необходимо передать в каждый момент взаимодействия между системами для того, чтобы принимающая сторона смогла однозначно их трактовать и обрабатывать . 
Например, при передаче плана поставки из торговой системы в WMS минимум необходимых данных – это общие сведения о поставке (№ документа, наименование поставщика, ожидаемая дата поставки…) и сведения о товарах (уникальный идентификатор товара, ожидаемое количество…). В зависимости от потребностей процесса обработки данных может быть значительно больше.

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

Технические задачи

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

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

 

Организационные задачи

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

Особого внимания заслуживает ситуация, когда выполняется параллельное внедрение торговой и складской системы с привлечением разных подрядчиков для каждой из систем. В этом случае предъявляются повышенные требования к коммуникациям между тремя сторонами. Как показывает практика, поставить задачу по интеграции систем на базе готовых продуктов (например, типовых решений \"1С\") можно до этапа согласования и реализации их базового функционала. Обсуждение и согласование работ по интеграции необходимо проводить с участием трех сторон, а результат должен воплотиться в документ, завизированный всеми участниками. Это поможет избежать проблем при реализации функционала интеграции и его последующем внедрении, а в случае если они все же возникнут, позволит разграничить ответственность между Заказчиком и подрядчиками.

Разработка интеграции между WMS и ERP требует ответственного подхода, большой детализации и компетенции. Главная сложность состоит в разнообразии компаний, их бизнес-процессов, организационных регламентов и способов реагирования на нестандартные ситуации. Именно поэтому нельзя сказать, что существует некий \"типовой\" вариант интеграции, даже если речь идет о типовых продуктах с известным функционалом. Безусловно, можно использовать уже имеющиеся наработки и опыт, но в большинстве случаев на логику интеграции накладывает значительный отпечаток индивидуальность конкретной компании. 

Дарья Любовина, руководитель проектов AXELOT
https://www.lobanov-logist.ru/library/all_articles/56319/