“Беспрекорна ERP интеграција” је стандардно обећање које се у пракси прати тромјесечним пројектом. Објављујемо наш API приручник како би ваш ИТ тим могао да провери која се подаци заправо захтевају пре потписивања уговора. Ево шта треба да знате пре него што се упустите у пројекат интеграције.
Шта ваш ERP заправо треба да обезбеди
Да бисмо креирали DPP, за сваки производ нам је потребно следеће:
- Основni подаци - шифра артикла, опис, варијанте, тежине, димензије, слике
- Подаци о листи материјала - компоненте са количинама и рециклираним садржајем
- Подаци о пореклу - место производње, број серије, датум производње
- Еколошки подаци - CO₂ еквивалент по јединици, потрошња воде, потрошња енергије
- Подаци о добављачима - ко испоручује коју компоненту (за дужну проверу)
У теорији, сви ови подаци су доступни у вашем ERP систему. Међутим, у пракси су ови подаци распоређени у 4 до 7 модула: Управљање материјалом (MM), Производња (PP), Управљање квалитетом (QM), Управљање добављачима (LFA1), понекад посебан EHS модул за податке о животној средини и понекад PLM систем за формулације.
Питање интеграције није: “Да ли ваш ERP испоручује податке DPP-у?” Већ: “Како да обједините податке из пет подсистема у један кохерентан скуп података?”
Три испробана и проверена обрасца интеграције
Образац 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: Middleware / ETL
Имате слој за интеграцију (Mulesoft, Boomi, Informatica, Azure Data Factory) између ERP-а и спољних система. Мидлвејр делује као интерфејс - провајдер DPP комуницира са мидлвејром, никада директно са ERP-ом.
Предности: постојеће инвестиције се могу искористити, управљање је стабилно, треће стране немају директан приступ ERP-у.
Недостаци: Трошкови вашег мидлвера расте у складу са тим.
Шта радимо другачије у специфичним пројектима
Многи провајдери желе да се повежу директно са вашим ЕРП-ом. Ми увек уводимо посредан корак: наш АПИ прихвата неутралну 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?
- Који одсек управља сваким од ових система?
- Да ли имате улагање у мидлвејр који треба искористити?
- Да ли већ постоји API слој изнад вашег ERP система?
Одговори ће одредити који од три модела је прави за вас. И одредиће да ли ће пројекат трајати две недеље или шест месеци.