Диалог между информационными системами

Е. Июльский, ведущий консультант по направлению WMS в компании «i2 СНГ»

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

Итак, задача интеграции информационных систем необходима для налаживания процесса обмена данными между новой WMS-системой и уже существующей ERP-системой (Axapta, SAP, JD Edwards, Scala, 1С и т. д.) Если вы являетесь провайдером складских услуг (3PL-провайдером), то данная задача становится еще интереснее, и описание того, как она была решена, будет обязательно красоваться на первых страницах ваших рекламных материалов.

Давайте набросаем стандартный перечень информации относительно WMS, которой ей необходимо обмениваться с ERP (как еще говорят, «хост-система»). Главным образом это закачка справочной информации. Под справочной информацией мы понимаем списки владельцев, поставщиков, грузополучателей, грузоотправителей, перевозчиков, артикулов, номеров ГТД, сертификатов качества, пользователей системы и т. д. Следующим пунктом идет импорт приходов (инвойсов, ASN-ок, входов) и заказов на отгрузку (Shipment Orders). Для обратной связи соответственно необходимо экспортировать информацию с подтверждением о реально принятом и физически отгруженном товаре. Для завершения стандартного набора добавим проводки по корректировке складских запасов и их атрибутов, а также данные для сверки товарных запасов. Типы передаваемой информации принято называть «сообщениями» (message). В реальности сами сообщения обычно представляют собой некие файлы данных с заранее определенными форматом и структурой. На практике чаще всего используют форматы XML или CSV (данные разделены неким символом, например «запятой») – их легко формировать и обрабатывать. Структура файлов данных зависит от конкретных задач по обмену информации. Многие ERP-системы имеют свои «фирменные» форматы для импорта/ экспорта данных.

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

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

• физическая удаленность WMS от ERP. Если обе системы находятся под одной «крышей», то за обмен данными будет отвечать одно интеграционное решение. А если наоборот, то тут, скорее, их будет два – по каждому с каждой стороны, т. е. каждый модуль (интеграционное решение) будет отвечать за импорт/ экспорт данных в свою систему и передачу их другой системе;

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

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

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

Обычно для распределительного центра решение оказывается простым, а для 3PL-оператора – сложным.

Следующая часть цены интеграционного модуля – это качество. Под качеством прежде всего надо понимать максимальную устойчивость системы к отказам. Хорошее решение должно работать в режиме «24х7» и выполнять все функции без участия IT-специалиста, а в случае обрыва канала передачи данных переключаться на альтернативный канал или уметь откладывать пересылку до «лучших» времен, иметь хороший механизм регистраций событий и в случае ошибки уметь информировать (отправка сообщения по почте, SMS и т. п.) технического специалиста о возникшей проблеме.

После того как мы рассмотрели общие требования к интеграционному решению, можно приступить к описанию вариантов реализации. Если быть предельно кратким, то варианта всего два: либо вы покупаете некий универсальный инструментарий для интеграции информационных систем и с помощью программистов («своих» или «чужих») доводите его до своих требований, либо строите решение самостоятельно (опять же с помощью «своих» или «чужих» программистов). По какому пути нужно пойти, сможет ответить только ваш руководитель IT-службы, основываясь на знании квалификации технических специалистов, существующих технических наработок и доступных временны’х и финансовых ресурсах. В зависимости от качества универсального инструментария для интеграции вы получаете следующие готовые функции:

• визуализированное построение и администрирование интеграционного процесса;

• автоматическое ведение журналов о выполненных операциях, механизмы отладки;

• поддержка различных форматов (CSV, XML и т. п.) файлов данных;

• различные механизмы для преобразования данных;

• работа с различными протоколами передачи данных;

• поддержка работы с различными системами управления базами данных;

• дополнительные функции (работа с архивами, перекодировка данных, выполнение внешних приложений и т. п.).

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

Завершая рассмотрение вопроса интеграции, необходимо перечислить основные риски в случае неудачного построения решения по обмену данными между информационными системами:

• круглосуточная доступность технического специалиста для поддержки системы;

• ошибки в работе информационных систем и нарушение целостности данных из-за импорта/ экспорта некорректной информации;

• дополнительная нагрузка на конечных пользователей системы;

• cрыв отгрузок, задержка транспортных средств при разгрузке/погрузке;

• трудоемкий процесс развития функционала интеграционного решения.

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