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