«Бесшовная интеграция с ERP» - это стандартное обещание, за которым на практике следует трехмесячный проект. Мы публикуем наше руководство по API, чтобы ваш ИТ-отдел мог перед подписанием контракта проверить, какие именно данные будут запрашиваться. Вот что вам следует знать перед началом проекта по интеграции.
Что на самом деле должна предоставлять ваша ERP-система
Для создания DPP нам требуются следующие данные по каждому продукту:
- Основные данные - артикул, название, варианты, вес, размеры, изображения
- Данные спецификации - компоненты с указанием количества и доли вторичного сырья
- Данные о происхождении - место производства, номер партии, дата производства
- Экологические данные - эквивалент CO₂ на единицу, потребление воды, потребление энергии
- Данные о поставщиках - кто поставляет какой компонент (для проведения комплексной проверки)
Теоретически все эти данные имеются в вашей ERP-системе. На практике они распределены по 4-7 модулям: управление материалами (MM), производство (PP), качество (QM), поставщики (LFA1), иногда отдельный модуль EHS для экологических данных, иногда система PLM для рецептур.
Вопрос интеграции заключается не в том: «Предоставляет ли ваша ERP-система данные в DPP?», а в том: «Как объединить данные из 5 подсистем в единый набор данных?»
Три проверенных шаблона интеграции
Шаблон 1: OData / REST-Pull
Хорошо работает с современными ERP-системами (SAP S/4HANA Cloud, Dynamics 365, Odoo). Поставщик DPP извлекает данные через OData или REST. Инкрементально, по расписанию или по событиям.
Преимущества: минимальные затраты на разработку с вашей стороны, вы предоставляете учетные данные для чтения, а поставщик реализует преобразование.
Недостатки: не работает с устаревшими установками SAP ECC без дополнительного API-слоя. Требуется управление запросами на доступ к данным.
Шаблон 2: Интеграция на основе событий
SAP Event Mesh, Apache Kafka, RabbitMQ. Ваша ERP-система публикует события об изменениях, поставщик DPP их потребляет.
Преимущества: практически в режиме реального времени, элегантная масштабируемость, развязка.
Недостатки: настройка сложна и требует инфраструктуры, которой не каждый ИТ-отдел располагает. Для небольших компаний это, как правило, излишне.
Модель 3: промежуточное программное обеспечение / ETL
Между ERP-системой и внешними системами имеется интеграционный слой (Mulesoft, Boomi, Informatica, Azure Data Factory). Промежуточное ПО выступает в качестве посредника - поставщик DPP взаимодействует с ним, а не напрямую с ERP.
Преимущества: возможность использования существующих инвестиций, стабильное управление, отсутствие прямого доступа третьих сторон к ERP.
Недостатки: ваши затраты на промежуточное программное обеспечение растут пропорционально масштабированию.
Что мы делаем по-другому в конкретных проектах
Многие поставщики хотят подключаться напрямую к вашей ERP-системе. Мы же всегда встраиваем промежуточный этап: наш API принимает нейтральную схему JSON, которую вы заполняете с помощью инструмента по вашему выбору. Это означает:
- вы можете самостоятельно подготовить данные с помощью инструментов, с которыми знакома ваша команда;
- вы можете заменить нас - нейтральный формат является переносимым;
- вы можете в любой момент извлечь весь свой массив данных - в форматах CSV, XLSX, JSON-LD и SQL, а также через REST-API;
- Мы предоставляем валидатор импорта, который проверяет ваши данные перед загрузкой
Полная схема и все конечные точки публично документированы в формате спецификации OpenAPI по адресу /apidocs. Ваш ИТ-отдел может проверить интерфейс до подписания договора - включая примеры запросов, ответы об ошибках и детали аутентификации.
Сроки реализации данного подхода на практике:
- 1-2-й день: семинар по сопоставлению полей. Какое поле ERP соответствует какому полю DPP?
- 3-5-й день: первые экспорты в формате JSON из ERP-системы с проверкой нашим валидатором.
- 6-8-й день: устранение ошибок (отсутствующие поля, несогласованные коды).
- 9-10-й день: первые DPP запущены в рабочем режиме.
Две недели, а не три месяца. Ключевым моментом является семинар по сопоставлению данных - именно там решается вопрос о качестве данных.
Что может пойти не так: самые распространённые ловушки
База данных о продуктах в нескольких системах: в SAP хранится артикул, в PIM - изображения и маркетинговые тексты, в PLM - спецификация. Ни у кого нет целостной картины. Решение: перед началом проекта определите, какая система является «источником истины» для каждого поля.
Сертификаты в формате PDF: поставщики предоставляют сертификаты GOTS, OEKO-TEX или REACH в виде отсканированных PDF-файлов. Это не является структурированным источником данных. Решение: организации, выдающие сертификаты, всё чаще предлагают запросы через API (OEKO-TEX лидирует, GOTS отстаёт). Или: вводить данные вручную, но с указанием срока действия, чтобы в DPP не появлялись просроченные сертификаты.
Конфиденциальность рецептуры: особенно в косметике, пищевой промышленности и фармацевтике: полная рецептура является коммерческой тайной. Должна ли система DPP обнародовать её? Решение: трехуровневая модель ESPR. Категория продукта доступна публично, а органы власти видят полный состав. Практически никогда не становится препятствием, но необходимо уточнить на раннем этапе.
Данные по выбросам CO₂ на основе информации от поставщиков: ваш поставщик предоставляет среднее значение для всего своего ассортимента, а не по каждой партии. Решение: временно принять это, в долгосрочной перспективе скорректировать договоры с поставщиками. ESPR требует значений по конкретным продуктам, начиная с определенной даты, но текущая практика представляет собой компромисс.
Местные языковые версии: ваша ERP-система содержит только названия продуктов на немецком и английском языках. Для 27 стран ЕС вам потребуется больше. Решение: машинный перевод с использованием терминологической базы данных; у нас есть отдельная статья по этому вопросу.
Вопросы, которые следует задать перед началом проекта
Прежде чем отправить запрос предложений (RFP) трём поставщикам, ответьте на следующие вопросы внутри компании:
- Для скольких продуктов/артикулов должны быть созданы DPP? (10, 10 000, 1 миллион?)
- В каких системах сегодня хранятся данные, относящиеся к DPP?
- Какой отдел управляет каждой из этих систем?
- Есть ли у вас инвестиции в промежуточное программное обеспечение, которое следует использовать?
- Существует ли уже работающий уровень API над вашей ERP-системой?
Ответы на эти вопросы определят, какой из трёх шаблонов подходит именно вам. И от них зависит, продлится ли проект две недели или шесть месяцев.