Вы планируете внедрить на складе WMS и хотите, чтобы она стала органичной частью вашей информационной структуры, хотите наладить взаимодействие между отделом продаж, складом и транспортом, исключив потери данных. Что нужно сделать и о чем подумать, чтобы
Задача организации взаимодействия складской и корпоративной учетной системы актуальна практически всегда. Исключения могут быть связаны с автоматизацией складов ответственного хранения, для которых WMS исполняет роль основной бизнес-системы, где оформляются все коммерческие операции компании, поэтому необходимость в обмене иногда отсутствует. Тем не менее и склады ответственного хранения в рамках проекта автоматизации часто организуют интеграцию со своими системами бухгалтерского учета, учетными системами поставщиков, транспортными системами и другими смежными информационными системами. Поэтому, обобщив имеющийся опыт, можно сказать, что интеграция WMS и внешних систем — задача при автоматизации склада обязательная.
Обмен информацией — процесс не только необходимый, но и очень ответственный. WMS-система является носителем наиболее точной и актуальной информации о состоянии остатков товара на складе, на которую опираются остальные информационные модули компании. Неустойчивая связь между системами, потеря данных в процессе обмена или некорректная их трактовка в системе-получателе чревата большими проблемами в работе склада и компании в целом.
Процесс разработки интеграции между WMS и любой другой внешней системой состоит из трех типов задач: функциональных, технических и организационных. К функциональным задачам относятся определение состава синхронизируемой справочной информации, точек взаимодействия систем по каждому из процессов, интегрируемых бизнес-процессов, способов запуска обменных процессов и состава мигрирующей информации. Технические задачи — это выбор технологии интеграции, определение форматов обмена и средств контроля механизма интеграции. Основная организационная задача — обеспечить взаимодействие сторон при разработке и внедрении инструментов интеграции.
Рассмотрим подробнее каждую из задач на примере взаимодействия между системой WMS и торговой системой.
Функциональные задачи
Для организации взаимодействия требуется пройти несколько этапов.
Синхронизация данных
На первом этапе выясняется, какие данные необходимо синхронизировать в обеих системах для обеспечения корректного обмена данными.
В первую очередь это, конечно, каталог товаров, хранимых на складе. Кроме уникального идентификатора и наименования товара на складе часто нужны данные о фасовках товара с указанием кратности вложения единиц, их весогабаритные характеристики, штрих-коды и другая значимая для данного складского технологического процесса информация. Во избежание путаницы и дублирования в работе с товаром крайне желательно, чтобы ведение каталога товаров подчинялось жестким правилам и выполнялось только в одной системе — той, где работают менеджеры по закупкам. WMS в данной ситуации — ведомая система, которая может дополнять каталог своими специфичными данными (например, правила обработки), но не должна создавать новые позиции в списке товаров.
Кроме каталога товаров часто синхронизируются данные о контрагентах, иногда — о сотрудниках. Большего объема пересекающейся справочной информации обычно не требуется.
В результате на первом этапе должен быть составлен список справочной информации, необходимой в каждой из систем, и определена система — владелец каждого вида информации, которая будет управлять данными и передавать их системе-потребителю.
Эти работы необходимы, даже если существует единый источник данных — например, уже работающая торговая система. При появлении WMS иногда возникает искушение управлять новыми позициями справочников в обеих информационных базах, так как именно склад первым видит новый товар и может внести информацию о нем в систему. Если поддаться этому искушению, то будет получен запутанный справочник товаров с дублированными позициями. В правильно построенном бизнес-процессе обработки нового товара информацию первыми получают и вносят в систему закупщики. Склад уже может дополнить или исправить отдельные данные — такие как, например, вес или габариты товара.
Если же с WMS будет взаимодействовать более одной внешней системы, тогда вопрос выверки и определения единственного источника данных становится еще более значимым. Например, со складом взаимодействуют производственная и торговая компании единого холдинга, каждая из которых имеет свою информационную базу, где каталоги номенклатуры не совпадают, хотя физически работают с одним и тем же товаром.
Синхронизация бизнес-процессов
На этом этапе необходимо понять, какие события на складе должны отражаться и в корпоративной системе и, наоборот, какие планы и/или решения торговой системы должны вызывать движения на складе. В качестве примера можно привести оформление заказа поставщику или приказа о плановой инвентаризации. В первом случае на склад придет информация об ожидаемой поставке («план»), во втором — конкретная задача на проведение инвентаризации («решение»).
Например, заказ покупателя, оформленный в торговой системе, обязательно должен быть передан на склад, где начнется его обработка. В свою очередь склад должен сообщить в корпоративную систему результат отгрузки: весь ли заказ выполнен или что-то не найдено и не было отгружено.
Другим примером может служить процесс отбора товара. Потребность торговой системы в данных результата отбора зависит от того, как организован бизнес-процесс продаж в компании. Этот пример иллюстрирует уникальность интеграции WMS и торговой системы в каждом конкретном случае. Если склад обслуживает внешних покупателей, то торговой системе важно своевременно знать, как прошел процесс отбора, чтобы корректно оформить финансовые документы на отгружаемый товар. В этом случае между передачей заказа на склад и отгрузкой товара покупателю в интеграции обязательно должен быть зафиксирован момент завершения отбора. Если же склад работает со своей розничной сетью, то эта стадия обмена данными может быть пропущена, так как недопоставка в собственные магазины может быть восполнена в следующем заказе, без исправления финансовых документов — для контроля остатков достаточно знать, что в итоге было фактически отгружено в каждый момент.
В результате на этом этапе должен быть составлен список операций в складской и торговой информационных системах, которые должны вызывать отклик в парной системе.
Точки взаимодействия
Следующий шаг — определение моментов обмена данными и инициаторов взаимодействия.
Допустим, речь идет о заказе покупателя. Обычно заказ покупателя в торговой системе проходит несколько стадий обработки: предварительный заказ, оплата, окончательный заказ, после чего возможны дозаказы, отмены части или всего заказа, замена товара. Процесс взаимодействия со складом в данном случае может быть организован по-разному. Первый вариант подходит для достаточно крупных поставщиков, с высокой степенью дисциплины продаж. У них существует жесткий регламент оформления и передачи заказа на склад — например, заказы на завтрашний день могут оформляться и изменяться только до определенного часа текущего дня. Заказы и дополнения, поступившие после этого времени, на склад передаются как новые, отгружаемые на следующие сутки или включаемые в следующую отправку. Для таких случаев в корпоративной системе должен существовать ряд программных запретов, регулирующих изменение и ввод заказов после назначенного времени. Склад в данной ситуации находится в выигрышном положении, так как может в плановом режиме обрабатывать волну заказов, переданную из торговой системы, не опасаясь правок и изменений.
Компании, ставящие превыше всего потребности клиента, вынуждены корректировать заказы в том числе в процессе их складской обработки, что, безусловно, осложняет процедуру обмена данными — необходимо обработать каждое отклонение, внесенное на стадиях отбора, маркировки, упаковки, отгрузки и других операций подготовки товара в зависимости от технологии обработки заказа на складе. Конечно же, процесс сопровождается технологическими трудностями: отобранный товар надо вернуть на место или подобрать ему новое, если старое уже занято (на складах с динамическим адресным хранением), упакованный товар нужно распаковать и т. д. В некоторых случаях, когда товар специфический и оформление и обработка заказа занимает не часы, а сутки, такой подход бывает оправдан.
Также нужно принимать во внимание, что не всякое событие, возникающее в бизнес-процессе, должно сопровождаться синхронизацией данных. Например, в компаниях, торгующих дефицитным товаром, информация о поступившем на склад товаре не должна попасть к менеджерам по продажам раньше, чем товар пройдет процедуру не только приемки, но также маркировки и размещения, иначе они распродадут товар раньше, чем склад физически сможет обеспечить заказы. В этом случае событием, завершающем приемку с точки зрения торговой системы, является не собственно приемка по качеству и количеству, а размещение товара в местах хранения.
На этом этапе должны быть определены те события или документы (счета, накладные, листы отбора), их статусы (создан, записан, проведен, «в работу», «на склад»), сроки их обработки и прочие значимые параметры, однозначно определяющие момент, когда каждая из систем должна (или не должна) передать свои данные в другую систему.
Способы запуска процессов обмена
На этой стадии нужно определить, будет ли обмен полностью автоматическим, полуавтоматическим или ручным в каждой из точек взаимодействия.
Практически всегда высказывается пожелание полной автоматизации. Но на практике не все так очевидно. Программное обеспечение может выполнить действие, если условия его выполнения однозначно определены, а это не всегда возможно. Наиболее характерный пример: торговая система нуждается в данных о результате отбора заказа на момент его окончания. В какой момент можно считать отбор законченным? В процессе подбора товара возможны различные отклонения: что-то не нашли, что-то нашли, но бракованное или другого сорта и т. п. Отбор может идти в несколько итераций, и однозначно определить на каждой итерации, будет ли отбор продолжен, могут только человек ответственный за отбор заказа, и менеджер клиента. Если при отборе проблем не возникло, то результат может быть передан в торговую систему автоматически, без участия пользователей. Если же были проблемы, то решения могут быть приняты самые разные — начиная с полного отказа от заказа, если не найдена ключевая позиция, заканчивая отправкой «как есть», если проблема незначительная. В таком случае результат отбора после выяснения всех обстоятельств подготовки и отправки заказа отправляется в корпоративную систему из WMS по сигналу пользователя. Для сторонников абсолютной автоматизации замечу, что эта схема, конечно же, не единственно возможная при обработке отбора, но часто встречающаяся на практике.
В результате на этом этапе должно быть выработано решение о том, как будет запускаться процедура обмена в каждой из точек взаимодействия систем.
Состав мигрирующей информации
Этот этап относительно прост. Здесь нужно понять, какие данные необходимо передать в каждый момент взаимодействия между системами для того, чтобы принимающая сторона смогла однозначно их трактовать и обрабатывать. Например, при передаче плана поставки из торговой системы в систему WMS нужны общие сведения о поставке (номер документа, наименование поставщика, ожидаемая дата поставки) и сведения о товарах (уникальный идентификатор товара, ожидаемое количество). В зависимости от потребностей процесса обработки, данных может быть значительно больше.
На этом этапе должны быть составлены списки необходимых данных по каждой из точек взаимодействия систем.
Технические задачи
Технические способы интеграции могут быть очень разными, и решение о выборе конкретного способа также нужно принимать в процессе разработки интеграции.
При этом должны быть определены все необходимые механизмы и инструменты, обеспечивающие контроль работоспособности обмена и удобный мониторинг отклонений. Это могут быть различные системы откликов об успешном получении данных, системы сигнализации о потере связи или проблемных транзакциях, журналы регистрации событий обмена с возможностью идентификации причин, вызвавших проблемы. В число средств контроля входят, например, специальные каталоги для хранения обработанных файлов, как удачно загруженных, так и не прошедших входной контроль одной из систем.
В результате должен быть сформирован список требований к созданию, хранению и обработке данных о деятельности механизма обмена.
Организационные задачи
Приступая к разработке механизма интеграции между WMS и торговой системой, необходимо обеспечить тесное взаимодействие всех участников процесса. Интеграция требует модификации обеих систем, причем в торговой системе она затрагивает сразу несколько процессов, поэтому в обсуждении интеграции должны принимать участие люди, компетентные во всех функциональных областях, связанных со складом (закупки, продажи, бухгалтерский учет и пр.), или даже группы сотрудников. Здесь следует обратить внимание на коммуникации и скорость согласования решений. В идеале руководитель проекта со стороны заказчика должен обладать достаточной компетенцией и полномочиями, чтобы принять консолидированное и окончательное решение.
Особого внимания заслуживает ситуация, когда выполняется параллельное внедрение торговой и складской систем с привлечением разных подрядчиков для каждой из систем. В этом случае предъявляются повышенные требования к коммуникациям между тремя сторонами. Как показывает практика, поставить задачу по интеграции систем на базе готовых продуктов (например, типовых решений «1С») можно до этапа согласования и реализации их базового функционала. Обсуждение и согласование работ по интеграции необходимо проводить с участием трех сторон, а результат должен быть отражен в документе, завизированном всеми участниками. Это поможет избежать проблем при реализации функционала интеграции и его внедрении, а если они все же возникнут, то позволит разграничить ответственность между заказчиком и подрядчиками.
Разработка интеграции между WMS и ERP требует ответственного подхода, большой детализации и компетенции. Главная сложность состоит в разнообразии компаний, их бизнес-процессов, организационных регламентов и способов реагирования на нестандартные ситуации. Именно поэтому нельзя сказать, что существует некий «типовой» вариант интеграции, даже если речь идет о типовых продуктах с известным функционалом. Безусловно, можно использовать уже имеющиеся наработки и опыт, но в большинстве случаев на логику интеграции накладывает значительный отпечаток индивидуальность конкретной компании.
Дарья Любовина — руководитель проектов компании Axelot Logistics; d.lubovina@axelotlogistics.ru