„Płynna integracja z systemem ERP” to standardowa obietnica, po której w praktyce następuje trzymiesięczny projekt. Publikujemy nasz przewodnik po API, aby Państwa dział IT mógł przed podpisaniem umowy sprawdzić, jakie dane są faktycznie pobierane. Oto, co powinni Państwo wiedzieć przed rozpoczęciem projektu integracyjnego.
Co faktycznie musi zapewnić Państwa system ERP
Aby stworzyć DPP, potrzebujemy dla każdego produktu:
- Dane podstawowe - numer artykułu, nazwa, warianty, waga, wymiary, zdjęcia
- Dane z listy komponentów - komponenty wraz z ilościami i udziałem materiałów pochodzących z recyklingu
- dane dotyczące pochodzenia - miejsce produkcji, numer partii, data produkcji
- dane środowiskowe - ekwiwalent CO₂ na jednostkę, zużycie wody, zużycie energii
- dane dostawców - kto dostarcza który komponent (na potrzeby due diligence)
Teoretycznie wszystkie te dane są dostępne w Państwa systemie ERP. W praktyce są one rozproszone w 4 do 7 modułach: gospodarka materiałowa (MM), produkcja (PP), jakość (QM), dostawcy (LFA1), czasami oddzielny moduł EHS dla danych środowiskowych, a czasami system PLM dla receptur.
Pytanie dotyczące integracji nie brzmi: „Czy Państwa system ERP dostarcza dane do platformy DPP?”. Brzmi ono: „W jaki sposób łączą Państwo dane z 5 podsystemów w spójny zbiór danych?”.
Trzy sprawdzone wzorce integracji
Wzorzec 1: OData / REST-Pull
Działa dobrze z nowoczesnymi systemami ERP (SAP S/4HANA Cloud, Dynamics 365, Odoo). Dostawca DPP pobiera dane za pośrednictwem OData lub REST. W sposób przyrostowy, planowany lub sterowany zdarzeniami.
Zalety: niewielki nakład pracy programistycznej z Państwa strony, Państwo udostępniają poświadczenia do odczytu, a dostawca zajmuje się transformacją danych.
Wady: nie działa ze starszymi instalacjami SAP ECC bez dodatkowej warstwy API. Wymagane jest zarządzanie żądaniami dostępu do danych.
Wzór 2: Integracja oparta na zdarzeniach
SAP Event Mesh, Apache Kafka, RabbitMQ. Państwa system ERP publikuje zdarzenia zmian, a dostawca DPP je odbiera.
Zalety: działanie niemal w czasie rzeczywistym, elegancka skalowalność, oddzielenie komponentów.
Wady: konfiguracja jest wymagająca i wymaga infrastruktury, której nie posiada każdy dział IT. Dla mniejszych firm zazwyczaj jest to rozwiązanie przesadzone.
Wzór 3: Oprogramowanie pośredniczące / ETL
Posiadają Państwo warstwę integracyjną (Mulesoft, Boomi, Informatica, Azure Data Factory) pomiędzy systemem ERP a systemami zewnętrznymi. Oprogramowanie pośredniczące pełni rolę „umowy” - dostawca DPP komunikuje się z oprogramowaniem pośredniczącym, nigdy bezpośrednio z systemem ERP.
Zalety: możliwość wykorzystania dotychczasowych inwestycji, stabilne zarządzanie, brak bezpośredniego dostępu stron trzecich do systemu ERP.
Wady: koszty oprogramowania pośredniczącego rosną proporcjonalnie do skali projektu.
Co robimy inaczej w konkretnych projektach
Wielu dostawców chce połączyć się bezpośrednio z Państwa systemem ERP. My zasadniczo wprowadzamy etap pośredni: nasze API akceptuje neutralny schemat JSON, który mogą Państwo wypełnić za pomocą wybranego przez siebie narzędzia. Oznacza to, że:
- mogą Państwo samodzielnie przygotować dane, korzystając z narzędzi znanych Państwa zespołowi
- mogą Państwo zmienić dostawcę - neutralny format jest przenośny
- w każdej chwili mogą Państwo pobrać cały swój zasób danych - w formatach CSV, XLSX, JSON-LD i SQL, a także za pośrednictwem REST-API
- Dostarczamy narzędzie do walidacji importu, które sprawdza dane przed ich przesłaniem
Pełny schemat oraz wszystkie punkty końcowe są publicznie udostępnione w formie specyfikacji OpenAPI pod adresem /apidocs. Wasz dział IT może sprawdzić interfejs przed podpisaniem umowy - łącznie z przykładowymi zapytaniami, odpowiedziami o błędach i szczegółami uwierzytelniania.
Harmonogram realizacji tego podejścia w praktyce:
- Dzień 1-2: Warsztaty dotyczące mapowania. Które pole w systemie ERP odpowiada któremu polu w DPP?
- Dzień 3-5: Pierwsze eksporty JSON z systemu ERP, sprawdzane przez nasz walidator.
- Dzień 6-8: Usuwanie błędów (brakujące pola, niespójne kodowanie).
- Dzień 9-10: Pierwsze DPP są już aktywne.
Dwa tygodnie, a nie trzy miesiące. Kluczowym momentem są warsztaty mapowania - to właśnie tam decyduje się o jakości danych.
Co może pójść nie tak: najczęstsze pułapki
Dane podstawowe produktów w wielu systemach: SAP zawiera numery artykułów, PIM - zdjęcia i teksty marketingowe, a PLM - listę części. Nikt nie ma spójnego obrazu sytuacji. Rozwiązanie: przed rozpoczęciem projektu należy zdefiniować, który system jest „źródłem prawdy” dla poszczególnych pól.
Certyfikaty w formacie PDF: dostawcy dostarczają certyfikaty GOTS, OEKO-TEX lub REACH w postaci zeskanowanych plików PDF. Nie jest to ustrukturyzowane źródło danych. Rozwiązanie: organizacje certyfikujące coraz częściej oferują zapytania przez API (OEKO-TEX jest liderem, GOTS pozostaje w tyle). Lub: wprowadzać dane ręcznie, ale z datą ważności, aby w systemie DPP nie pojawiały się certyfikaty, których ważność wygasła.
Tajemnica receptury: szczególnie w branży kosmetycznej, spożywczej i farmaceutycznej: pełna receptura stanowi tajemnicę handlową. Czy DPP ma je upublicznić? Rozwiązanie: trójpoziomowy model ESPR. Publicznie dostępna jest kategoria produktu, a organy administracji mają wgląd w pełną recepturę. Prawie nigdy nie stanowi to przeszkody, ale należy to wyjaśnić na wczesnym etapie.
Dane dotyczące emisji CO₂ na podstawie informacji od dostawców: Państwa dostawca podaje średnią wartość dla całego swojego asortymentu, a nie dla poszczególnych partii. Rozwiązanie: tymczasowo zaakceptować, w dłuższej perspektywie dostosować umowy z dostawcami. Rozporządzenie ESPR wymaga wartości specyficznych dla produktu od określonej daty, ale obecna praktyka stanowi kompromis.
Lokalne wersje językowe: Państwa system ERP zawiera jedynie nazwy produktów w języku niemieckim i angielskim. W przypadku 27 krajów UE potrzeba więcej. Rozwiązanie: tłumaczenie maszynowe z wykorzystaniem bazy terminologicznej; poświęciliśmy temu osobny artykuł.
Pytania, które należy zadać przed rozpoczęciem projektu
Zanim wyślesz zapytanie ofertowe (RFP) do trzech dostawców, odpowiedz wewnętrznie na następujące pytania:
- Ile produktów/numerów artykułów ma obejmować DPP? (10, 10 000, 1 milion?)
- Które systemy przechowują obecnie dane istotne dla DPP?
- Który dział zarządza każdym z tych systemów?
- Czy dysponują Państwo oprogramowaniem pośredniczącym (middleware), które należy wykorzystać?
- Czy istnieje już działająca warstwa API nad Państwa systemem ERP?
Odpowiedzi na te pytania określą, który z trzech wzorców jest dla Państwa odpowiedni. Określą one również, czy projekt potrwa dwa tygodnie, czy sześć miesięcy.