Greutatea unui produs se găsește în modulul de gestionare a materialelor. Procentul de material reciclat se găsește în sistemul de rețete. Certificatul furnizorului este disponibil în format PDF pe o unitate de rețea. Fișa tehnică a produsului are nevoie de toate cele trei informații într-un singur set de date, iar tocmai în acest lucru constă proiectul de integrare, nu în conectarea a două sisteme.
„Integrarea ERP fără sincope” este o promisiune standard, urmată în practică de un proiect de trei luni. Publicăm ghidul nostru pentru ca departamentul dvs. IT să poată verifica, înainte de semnarea contractului, ce anume se solicită de fapt. Acest articol arată ce date are nevoie pașaportul din sistemele dumneavoastră, prin ce trei căi ajung acestea la noi și de ce acest proces poate fi realizat în două săptămâni.
Ce trebuie să furnizeze de fapt sistemul dumneavoastră 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 procentul 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ă fiecare componentă (pentru obligațiile de diligență)
Teoretic, toate aceste date sunt disponibile în sistemul dumneavoastră ERP. În practică, ele sunt distribuite în 4 până la 7 module: gestionarea materialelor, producție, calitate, baza de date a furnizorilor, uneori un modul separat pentru datele de mediu, alteori un sistem propriu pentru rețete și liste de piese.
Întrebarea privind integrarea nu este: „Sistemul dvs. ERP furnizează date către un DPP?” Ci: „Cum reuniți datele din 5 subsisteme într-un set de date coerent?”
Trei metode verificate
Metoda 1: Preluarea datelor din sistemul ERP
Funcționează bine cu sistemele ERP moderne (SAP S/4HANA Cloud, Dynamics 365, Odoo). Furnizorul DPP preia datele prin intermediul interfeței ERP (din punct de vedere tehnic, OData sau REST). Doar modificările, conform unui program sau declanșate de un eveniment.
Avantaje: efort minim de dezvoltare din partea dvs., dvs. acordați acces de citire, iar furnizorul se ocupă de conversie.
Dezavantaje: nu funcționează cu instalațiile SAP ECC mai vechi fără un strat suplimentar de interfață. Aveți nevoie de reguli clare privind cine are dreptul să citească anumite date.
Metoda 2: Transmiterea modificărilor
Sistemul dvs. ERP raportează fiecare modificare ca eveniment (prin SAP Event Mesh, Apache Kafka sau RabbitMQ), iar furnizorul DPP le preia.
Avantaje: aproape în timp real, se adaptează la creșterea afacerii, sistemele nu depind unul de celălalt.
Dezavantaje: configurarea este complexă și necesită o infrastructură de care nu dispune orice departament IT. De cele mai multe ori, este excesivă pentru firmele mai mici.
Metoda 3: Utilizarea stratului de integrare existent
Dispuneți deja de un ### strat de integrare(Mulesoft, Boomi, Informatica, Azure Data Factory) între ERP și sistemele externe. Acest strat reprezintă „contractul”: furnizorul DPP comunică cu acesta, niciodată direct cu ERP-ul.
Avantaje: investițiile existente pot fi valorificate, regulile rămân stabile, nu există acces direct la ERP pentru terți.
Dezavantaje: costurile dumneavoastră pentru stratul de integrare cresc proporțional.
Ce facem diferit în proiectele concrete
Mulți furnizori doresc să se conecteze direct la sistemul dumneavoastră ERP. Noi integrăm întotdeauna un pas intermediar: interfața noastră acceptă un format de date neutru (un schemă JSON), pe care îl completați cu un instrument la alegerea dumneavoastră. 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
Formatul complet și toate interogările sunt descrise public în Documentația API, ca descriere a interfeței conform OpenAPI. Departamentul dumneavoastră IT poate verifica interfața înainte de semnarea unui contract - inclusiv exemple de interogări, răspunsuri de eroare și detalii de autentificare.
Calendarul de implementare a acestei abordări în practică:
- Zilele 1-2: Atelier de mapare. Ce câmp din ERP corespunde cu ce câmp din DPP?
- Zilele 3-5: Primele exporturi JSON din ERP, verificate de 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 crucial 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 deține numărul articolului, PIM deține imaginile și textele de marketing, PLM deține lista de componente. Nimeni nu are o imagine coerentă. Soluție: definiți înainte de proiect care sistem este cel principal 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 posibilitatea de a interoga datele prin intermediul unei interfețe (OEKO-TEX este în avangardă, GOTS rămâne în urmă). Sau: introduceți datele manual, dar cu data de valabilitate, astfel încât în DPP să nu apară certificate expirate.
Confidențialitatea rețetei: în special în domeniul cosmeticelor, al produselor alimentare și al produselor farmaceutice: rețeta completă constituie un secret comercial. DPP ar trebui să o facă publică? Soluție: modelul pe trei niveluri al ESPR. Categoria de produse este publică, iar autoritățile pot vedea 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 pe lot. 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 demararea proiectului
Î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?
- Ce departament administrează fiecare dintre aceste sisteme?
- Dispuneți de un strat de integrare care ar trebui utilizat?
- Există deja o interfață funcțională prin intermediul sistemului ERP?
Răspunsurile vor determina care dintre cele trei variante vi se potrivește.
Răspunsurile vor stabili dacă un proiect va dura două săptămâni sau șase luni.
Întrebări referitoare la această postare
Este suficientă interfața REST sau avem nevoie de un middleware?
Interfața este suficientă. Cele trei modele se deosebesc prin locul în care are loc transformarea, nu prin ceea ce primim - interfața noastră acceptă un schemă JSON neutră, indiferent de modul în care ați generat-o. O extragere dintr-un sistem ERP modern, un flux de evenimente și un strat de integrare existent ajung toate la același punct final. Utilizarea unui middleware este justificată dacă deja operați unul și dacă acesta trebuie să rămână parte a contractului cu terții. Dacă în prezent nu există unul, nu achiziționați unul doar pentru certificatul de produs.
Ce se decide în cadrul atelierului de cartografiere?
Ce câmp ERP corespunde cu ce câmp din pașaport - și care sistem este sursa principală atunci când mai multe sisteme conțin aceeași valoare. Atelierul are loc în zilele 1 și 2 și reprezintă punctul crucial al întregului proiect, deoarece acolo se iau deciziile privind calitatea datelor, nu ulterior, în cod. Aduceți cu voi persoanele care se ocupă de întreținerea sistemelor, nu doar pe cele responsabile de proiect - datele de bază, producția, calitatea și achizițiile sunt rareori concentrate într-un singur departament. Tot ce urmează după aceea, adică exporturile, validarea și remedierea erorilor, ține de măiestrie.
Certificatele noastre sunt disponibile doar sub formă de scanări în format PDF. Ce facem cu ele?
O scanare nu este o sursă de date structurată și, prin urmare, este inutilă pentru pașaport. Există două modalități de a proceda: operatorii de certificare oferă din ce în ce mai des interfețe API pentru interogări, iar acolo unde acestea nu există, introduceți valorile manual, dar întotdeauna împreună cu data de valabilitate, pentru ca niciun certificat expirat să nu rămână în pașaportul publicat. Planificați metoda manuală ca o activitate recurentă, nu ca o sarcină punctuală.
Poate departamentul nostru IT să verifice interfața înainte să semnăm ceva?
Da. Schema completă și toate punctele de interfață sunt disponibile sub formă de specificație OpenAPI la adresa Documentația API, împreună cu exemple de solicitări, răspunsuri de eroare și detalii privind autentificarea. Nimic din toate acestea nu este ascuns în spatele unei discuții de vânzare, astfel încât echipa dvs. de integrare poate estima efortul necesar înainte de semnarea unui contract. Dacă un furnizor nu își prezintă interfața în această fază, și acest lucru constituie un răspuns.
Ce se întâmplă cu datele noastre atunci când schimbăm furnizorul?
Se integrează. Interfața acceptă un schemă JSON neutră în locul unui format proprietar, iar întregul dvs. inventar este exportat în formate CSV, XLSX, JSON-LD și SQL sau prin intermediul API-ului REST. Acesta este scopul - formatul pe care îl completați este portabil, astfel încât o schimbare necesită doar o exportare, nu o reconstrucție. Puneți aceeași întrebare fiecărui furnizor înainte de atelierul de mapare, deoarece după aceea numele câmpurilor dvs. vor fi incluse în modelul acestuia.
Cât durează cu adevărat o conectare?
În proiectele pe care le coordonăm, două săptămâni - două zile de cartografiere, trei zile până la primele exporturi prin validatorul nostru, trei zile de remediere a erorilor, două zile până la publicarea primelor pașapoarte. Cea mai lungă etapă nu este niciodată codul, ci ceea ce găsește validatorul - câmpuri lipsă, codificări neuniforme, valori pentru care nimeni nu își asumă responsabilitatea. Planificați aceste zile, în loc să le scurtați. Un proiect care le omite va publica și lacunele.
Trebuie să conectăm toate produsele deodată?
Nu. Începeți cu produsele care necesită mai întâi un permis și cu un sistem sursă - schema neutră acceptă atât un catalog parțial, cât și unul complet, iar importurile sunt repetabile, astfel încât execuțiile ulterioare actualizează stocul. Astfel, atelierul de mapare rămâne suficient de scurt încât să poată fi finalizat în două zile. Extinderea ulterioară este o sarcină de mapare, nu un proiect nou.
