“Беспрекорна ERP интеграција” е стандардно ветување кое, во пракса, е проследено со тримесечен проект. Го објавуваме нашиот API Playbook за да може вашиот ИТ тим да провери кои податоци всушност се бараат пред да го потпише договорот. Еве што треба да знаете пред да започнете со проект за интеграција.
Што всушност треба да обезбеди вашиот ERP
За да создадеме DPP, ни требаат следниве податоци за секој производ:
- Основните податоци - број на артикл, опис, варијанти, тежини, димензии, слики
- Податоци за листата на материјали - компоненти со количини и рециклирана содржина
- Податоци за потекло - место на производство, број на серија, датум на производство
- Еколошки податоци - CO₂eq по единица, потрошувачка на вода, потрошувачка на енергија
- Податоци за добавувачи - кој го снабдува со која компонента (за должна грижа)
Во теорија, сите овие податоци се достапни во вашиот ERP систем. Меѓутоа, во пракса, тие се распределени во 4 до 7 модули: Управување со материјали (MM), Производство (PP), Управување со квалитет (QM), Управување со добавувачи (LFA1), понекогаш посебен EHS модул за еколошки податоци и понекогаш PLM систем за формулации.
Прашањето за интеграција не е: “Дали вашиот ERP систем доставува податоци до DPP?”. Прашањето е: “Како ги спојувате податоците од петте подсистеми во еден кохерентен сет на податоци?”.
Три испробани и проверени шаблони за интеграција
Шаблон 1: OData / REST pull
Работи добро со модерни ЕРП-системи (SAP S/4HANA Cloud, Dynamics 365, Odoo). Давателот на ДПП ги презема податоците преку OData или REST. Инкрементално, закажано или управувано од настани.
Предности: минимален развој потребен од ваша страна; вие ги обезбедувате акредитивите за читање, а провајдерот ја гради трансформацијата.
Недостатоци: не работи со постари инсталации на SAP ECC без дополнителен API слој. Потребно е управување со барањата за пристап до податоци.
Шема 2: Интеграција заснована на настани
SAP Event Mesh, Apache Kafka, RabbitMQ. Вашиот ERP објавува настани за промени; провајдерот DPP ги прима.
Предности: речиси во реално време, елегантно скалабилно, раздвоено.
Недостатоци: Поставувањето е комплексно и бара инфраструктура што не ја има секој ИТ-оддел. Обично е претерано за помали компании.
Шема 3: Middleware / ETL
Имате слој за интеграција (Mulesoft, Boomi, Informatica, Azure Data Factory) помеѓу ЕРП-системот и надворешните системи. Мидлверот делува како интерфејс - провајдерот на DPP комуницира со мидлверот, а никогаш директно со ERP.
Предности: постоечките инвестиции може да се искористат, управувањето е стабилно, нема директен пристап до ERP за трети страни.
Недостатоци: Трошоците за вашиот middleware соодветно се зголемуваат.
Што правиме поинаку во специфични проекти
Многу добавувачи сакаат да се поврзат директно со вашиот ERP. Ние секогаш вклучуваме посреден чекор: нашиот API прифаќа неутрална JSON-шема, која вие ја пополнувате со алатка по ваш избор. Ова значи:
- Можете сами да ги подготвите податоците, користејќи ги алатките со кои е запознаен вашиот тим
- Можете да менувате даватели на услуги - неутралниот формат е пренослив
- Можете да го преземете целиот ваш сет на податоци во секое време - како CSV, XLSX, JSON-LD и SQL, како и преку REST API
- Ние обезбедуваме валидатор за увоз кој ги проверува вашите податоци пред нивното поставување
Целосната шема и сите крајни точки се јавно документирани како OpenAPI спецификација на /apidocs. Вашиот ИТ тим може да го тестира интерфејсот пред да се потпише договорот - вклучувајќи примероци на барања, одговори за грешки и детали за автентикација.
Временска рамка за овој пристап во пракса:
- Денови 1 до 2: Работилница за мапирање. Кое поле во ЕРП одговара на кое поле во ДПП?
- Денови 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?
- Кој оддел управува со секој од овие системи?
- Дали имате инвестиција во middleware што треба да се искористи?
- Дали веќе постои API слој над вашиот ERP?
Одговорите ќе одредат кој од трите модели е вистинскиот за вас. И тие ќе одредат дали проектот ќе трае две недели или шест месеци.