Как связать SAP, Dynamics 365 и Business Central с цехом

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

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

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

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

Доступные шаблоны интеграции различаются в основном задержкой и связностью. Файловый обмен прост, поддерживается везде и неизбежно пакетный. Прямой доступ к базе данных быстр и хрупок: он ломается при обновлениях поставщика способами, которые трудно предугадать. Сегодня стандартом по умолчанию стали опубликованные интерфейсы: SAP через IDoc (обмен сообщениями ALE), BAPI/RFC или OData; Dynamics 365 и Business Central через их опубликованные API OData/REST. Они переживают смену версий куда изящнее. Очереди сообщений добавляют устойчивости для высокочастотных событий, потому что цех продолжает порождать данные независимо от того, доступна ERP или нет.

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

Локальные и региональные ERP-системы усложняют картину вполне определённым образом. У глобальных пакетов есть документированные интерфейсы и большая экосистема интеграторов. Региональные продукты (Panteon, Logo, Nebim и их аналоги на других рынках) широко распространены среди средних производителей, часто глубоко доработаны и редко имеют готовый коннектор к MES. Это не повод менять работающую ERP. Это повод относиться к слою интеграции как к полноценной части проекта.

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

Совет по границам проекта, который выдерживает столкновение с реальностью: начните с одного типа заказов на одной линии, докажите полный круг (от выпуска заказа в ERP через исполнение в цехе и обратно к подтверждению в ERP) и только потом расширяйтесь. Интеграции «большим взрывом» сразу по всем площадкам и типам заказов проваливаются так, что диагностировать это крайне трудно: когда всё новое, ничто не может служить точкой отсчёта.