„Integrarea ERP fără sincope” este o promisiune standard, urmată în practică de un proiect de trei luni. Publicăm ghidul nostru privind API-urile, pentru ca departamentul dvs. IT să poată verifica, înainte de semnarea contractului, ce anume se solicită de fapt. Iată ce ar trebui să știți înainte de a demara un proiect de integrare.
Ce trebuie să ofere de fapt sistemul dvs. ERP
Pentru a crea un DPP, avem nevoie pentru fiecare produs de:
- Date de bază - număr de articol, denumire, variante, greutăți, dimensiuni, imagini
- Date privind lista de componente - componente cu cantități și procente de material reciclat
- Date privind proveniența - locul de producție, numărul lotului, data producției
- Date de mediu - CO2eq pe unitate, consumul de apă, consumul de energie
- Date privind furnizorii - cine furnizează ce componentă (pentru due diligence)
În sistemul dumneavoastră ERP, aceste date sunt, teoretic, toate disponibile. În practică, acestea sunt distribuite în 4 până la 7 module: Gestionarea materialelor (MM), Producție (PP), Calitate (QM), Furnizori (LFA1), uneori un modul EHS separat pentru datele de mediu, alteori un sistem PLM pentru rețete.
Întrebarea privind integrarea nu este: „Sistemul ERP furnizează date către un DPP?” Ci: „Cum reuniți datele din 5 subsisteme într-un set de date coerent?”
Trei modele de integrare consacrate
Modelul 1: OData / REST-Pull
Funcționează bine cu sistemele ERP moderne (SAP S/4HANA Cloud, Dynamics 365, Odoo). Furnizorul DPP extrage datele prin OData sau REST. Incremental, planificat sau bazat pe evenimente.
Avantaje: efort redus de dezvoltare din partea dumneavoastră; dumneavoastră furnizați credențialele de citire, iar furnizorul se ocupă de transformare.
Dezavantaje: nu funcționează cu instalațiile SAP ECC mai vechi fără un strat API suplimentar. Aveți nevoie de guvernanță asupra cererilor de acces la date.
Modelul 2: Integrare bazată pe evenimente
SAP Event Mesh, Apache Kafka, RabbitMQ. Sistemul dvs. ERP publică evenimente de modificare, iar furnizorul DPP le preia.
Avantaje: aproape în timp real, scalabilitate elegantă, decuplare.
Dezavantaje: configurarea este complexă și necesită o infrastructură de care nu dispune orice departament IT. De obicei, este excesivă pentru firmele mai mici.
Modelul 3: Middleware / ETL
Aveți un strat de integrare (Mulesoft, Boomi, Informatica, Azure Data Factory) între ERP și sistemele externe. Middleware-ul reprezintă „contractul” - furnizorul DPP comunică cu middleware-ul, niciodată direct cu sistemul ERP.
Avantaje: investițiile existente pot fi valorificate, guvernanța este stabilă, nu există acces direct la ERP pentru terți.
Dezavantaje: costurile cu middleware-ul cresc proporțional.
Ce facem diferit în proiectele concrete
Mulți furnizori doresc să se conecteze direct la sistemul dvs. ERP. Noi integrăm, în principiu, un pas intermediar: API-ul nostru acceptă un schemă JSON neutră, pe care o completați cu un instrument la alegerea dvs. Asta înseamnă că:
- Puteți realiza singuri pregătirea datelor, folosind instrumentele cu care echipa dumneavoastră este familiarizată
- Ne puteți înlocui - formatul neutru este portabil
- Vă puteți recupera întregul stoc de date în orice moment - în format CSV, XLSX, JSON-LD și SQL, precum și prin API-ul REST
- Vă punem la dispoziție un validator de import care verifică datele înainte de încărcare
Schema completă și toate punctele de interfață sunt documentate public sub forma unei specificații OpenAPI la /apidocs. Departamentul dumneavoastră IT poate verifica interfața înainte de semnarea contractului - inclusiv cereri de exemplu, răspunsuri de eroare și detalii de autentificare.
Calendarul practic al acestei abordări:
- Zilele 1-2: Atelier de mapare. Ce câmp ERP corespunde cu ce câmp DPP?
- Zilele 3-5: Primele exporturi JSON din ERP, prin validatorul nostru.
- Zilele 6-8: Remedierea erorilor (câmpuri lipsă, codificări inconsistente).
- Zilele 9-10: Primele DPP-uri sunt active.
Două săptămâni, nu trei luni. Punctul cheie este atelierul de mapare - acolo se decide calitatea datelor.
Ce poate merge prost: cele mai frecvente capcane
Datele de bază ale produselor în mai multe sisteme: SAP are numărul de articol, PIM are imaginile și textele de marketing, PLM are lista de componente. Nimeni nu are o imagine coerentă. Soluție: definiți înainte de proiect care sistem este „sursa de referință” pentru fiecare câmp.
Certificate în format PDF: furnizorii transmit certificatele GOTS, OEKO-TEX sau REACH sub formă de scanări PDF. Aceasta nu este o sursă de date structurată. Soluție: organismele de certificare oferă din ce în ce mai des interfețe API (OEKO-TEX este în frunte, GOTS rămâne în urmă). Sau: introduceți datele manual, dar cu data de valabilitate, pentru ca în DPP să nu apară certificate expirate.
Confidențialitatea rețetei: în special în industria cosmetică, alimentară și farmaceutică: rețeta completă este un secret comercial. DPP ar trebui să o facă publică? Soluție: modelul pe trei niveluri al ESPR. Categoria de produs este publică, iar autoritățile au acces la formula completă. Aproape niciodată nu reprezintă un obstacol, dar trebuie clarificat din timp.
Date privind emisiile de CO₂ la nivel de furnizor: furnizorul dumneavoastră furnizează o valoare medie pentru întregul său portofoliu, nu pentru fiecare lot în parte. Soluție: acceptați această situație temporar, iar pe termen lung adaptați contractele cu furnizorii. ESPR solicită valori specifice produsului începând cu o anumită dată de referință, dar practica actuală reprezintă un compromis.
Versiuni lingvistice locale: sistemul dvs. ERP conține doar denumirea produsului în germană și engleză. Pentru cele 27 de țări ale UE aveți nevoie de mai mult. Soluție: traducere automată cu ajutorul unei baze de date terminologice; avem un articol separat dedicat acestui subiect.
Întrebările pe care ar trebui să le puneți înainte de proiect
Înainte de a trimite o cerere de ofertă (RFP) către trei furnizori, răspundeți la următoarele întrebări la nivel intern:
- Câte produse/numere de articol ar trebui să aibă DPP-uri? (10, 10 000, 1 milion?)
- Ce sisteme stochează în prezent date relevante pentru DPP?
- Care departament administrează fiecare dintre aceste sisteme?
- Aveți o investiție în middleware care ar trebui utilizată?
- Există deja un strat API funcțional deasupra sistemului ERP?
Răspunsurile vor determina care dintre cele trei modele vi se potrivește. Și vor stabili dacă un proiect va dura două săptămâni sau șase luni.