Waga produktu znajduje się w module gospodarki materiałowej. Udział surowców wtórnych jest zapisany w systemie receptur. Certyfikat dostawcy znajduje się w formacie PDF na dysku sieciowym. Karta produktu wymaga wszystkich trzech danych w jednym rekordzie, i właśnie w tym tkwi istota projektu integracyjnego, a nie w połączeniu dwóch systemów.
„Płynna integracja z systemem ERP” to standardowa obietnica, po której w praktyce następuje trzymiesięczny projekt. Publikujemy nasz przewodnik, aby Państwa dział IT mógł przed podpisaniem umowy sprawdzić, jakie dane są faktycznie wymagane. W niniejszym artykule przedstawiono, jakie dane z Państwa systemów są wymagane w paszporcie, na jakie trzy sposoby trafiają one do nas oraz dlaczego można to zrealizować w ciągu dwóch tygodni.
Co faktycznie musi dostarczyć Państwa system ERP
Aby stworzyć paszport produktu (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 poszczególne komponenty (na potrzeby obowiązków w zakresie należytej staranności)
Teoretycznie wszystkie te dane są dostępne w Państwa systemie ERP. W praktyce są one rozdzielone na 4 do 7 modułów: gospodarka materiałowa, produkcja, jakość, baza dostawców, czasami oddzielny moduł dla danych środowiskowych, a czasami osobny system dla receptur i list części.
Pytanie dotyczące integracji nie brzmi: „Czy Państwa system ERP dostarcza dane do platformy DPP?”. Brzmi ono raczej: „W jaki sposób połączyć dane z 5 podsystemów w spójny zbiór danych?”.
Trzy sprawdzone sposoby
Sposób 1: Pobieranie danych z systemu ERP
Rozwiązanie to sprawdza się dobrze w przypadku nowoczesnych systemów ERP (SAP S/4HANA Cloud, Dynamics 365, Odoo). Dostawca DPP pobiera dane za pośrednictwem interfejsu systemu ERP (technicznie OData lub REST). Pobierane są wyłącznie zmiany - zgodnie z harmonogramem lub w wyniku określonego zdarzenia.
Zalety: niewielki nakład pracy programistycznej z Państwa strony; Państwo zapewniają dostęp do odczytu, a dostawca opracowuje proces konwersji.
Wady: nie działa w przypadku starszych instalacji SAP ECC bez dodatkowej warstwy interfejsu. Konieczne jest ustalenie jasnych zasad określających, kto ma prawo odczytywać jakie dane.
Sposób 2: Przekazywanie zmian
Państwa system ERP zgłasza każdą zmianę jako zdarzenie (za pośrednictwem SAP Event Mesh, Apache Kafka lub RabbitMQ), a dostawca DPP je odbiera.
Zalety: działanie niemal w czasie rzeczywistym, skalowalność, systemy nie są od siebie zależne.
Wady: Konfiguracja jest wymagająca i wymaga infrastruktury, której nie dysponuje każdy dział IT. W przypadku mniejszych firm rozwiązanie to jest zazwyczaj zbyt rozbudowane.
Sposób 3: Wykorzystanie istniejącej warstwy integracyjnej
Posiadają Państwo już warstwę ### integracyjną(Mulesoft, Boomi, Informatica, Azure Data Factory) pomiędzy systemem ERP a systemami zewnętrznymi. Warstwa ta stanowi interfejs: dostawca DPP komunikuje się z nią, nigdy bezpośrednio z systemem ERP.
Zalety: można wykorzystać dotychczasowe inwestycje, reguły pozostają stabilne, brak bezpośredniego dostępu do systemu ERP dla stron trzecich.
Wady: koszty związane z warstwą integracyjną rosną wraz z rozwojem projektu.
Czym wyróżniamy się w konkretnych projektach
Wielu dostawców chce połączyć się bezpośrednio z Państwa systemem ERP. Zasadniczo wprowadzamy etap pośredni: nasz interfejs przyjmuje neutralny format danych (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 interfejsu REST-API
- dostarczamy narzędzie do walidacji importu, które sprawdza Państwa dane przed ich przesłaniem
Pełna specyfikacja formatu oraz wszystkie zapytania są publicznie udostępnione pod adresem /apidocs w postaci opisu interfejsu zgodnego ze standardem OpenAPI. Państwa dział IT może sprawdzić interfejs przed podpisaniem umowy - wraz z przykładowymi zapytaniami, odpowiedziami błędowymi oraz 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 narzędzie do walidacji.
- Dzień 6-8: Usuwanie błędów (brakujące pola, niespójne kodowanie).
- Dzień 9-10: Pierwsze pliki DPP są już dostępne.
Dwa tygodnie, a nie trzy miesiące. Kluczowym elementem są warsztaty dotyczące 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 posiada numer artykułu, 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 określić, który system jest wiodący dla danego pola.
Certyfikaty w formacie PDF: dostawcy przekazują 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ą możliwość pobierania danych za pośrednictwem interfejsu (OEKO-TEX jest liderem, GOTS pozostaje w tyle). Alternatywnie: należy wprowadzać dane ręcznie, ale z podaniem daty ważności, aby w systemie DPP nie pojawiały się certyfikaty, których ważność wygasła.
Zastrzeżenie receptury: szczególnie w branży kosmetycznej, spożywczej i farmaceutycznej: pełna receptura stanowi tajemnicę handlową. Czy DPP ma je upublicznić? Rozwiązanie: model trójpoziomowy ESPR. Publicznie dostępna jest kategoria produktu, a organy administracji mają wgląd w pełny skład. 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 wartość średnią dla całego swojego asortymentu, a nie dla poszczególnych partii. Rozwiązanie: tymczasowo zaakceptować tę sytuację, a w dłuższej perspektywie dostosować umowy z dostawcami. Rozporządzenie ESPR wymaga wartości specyficznych dla poszczególnych produktów od określonej daty, jednak 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 potrzebują Państwo więcej. Rozwiązanie: tłumaczenie maszynowe z wykorzystaniem bazy terminologicznej; poświęciliśmy temu osobny artykuł.
Pytania, które powinni Państwo zadać przed rozpoczęciem projektu
Zanim wyślą Państwo zapytanie ofertowe (RFP) do trzech dostawców, proszę odpowiedzieć na następujące pytania wewnętrzne:
- Ile produktów/numerów artykułów ma posiadać 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 warstwą integracyjną, z której należy skorzystać?
- Czy istnieje już działający interfejs w ramach Państwa systemu ERP?
Odpowiedzi na te pytania określą, która z trzech opcji jest dla Państwa odpowiednia. Określą one również, czy projekt potrwa dwa tygodnie, czy sześć miesięcy.
Pytania dotyczące tego wpisu
Czy interfejs REST jest wystarczający, czy też potrzebujemy oprogramowania pośredniczącego?
Interfejs jest wystarczający. Te trzy wzorce różnią się między sobą miejscem, w którym odbywa się transformacja, a nie tym, co przyjmujemy - nasz interfejs przyjmuje neutralny schemat JSON, niezależnie od tego, za pomocą jakiego narzędzia został on wygenerowany. Pobieranie danych z nowoczesnego systemu ERP, strumień zdarzeń oraz istniejąca warstwa integracyjna - wszystkie te elementy trafiają do tego samego punktu końcowego. Oprogramowanie pośredniczące (middleware) warto zastosować, jeśli i tak już je Państwo wykorzystują, a ma ono pozostać elementem umowy z podmiotami zewnętrznymi. Jeśli obecnie nie istnieje, proszę nie nabywać go wyłącznie na potrzeby certyfikatu produktu.
O czym decyduje się podczas warsztatów z mapowania?
Które pole w systemie ERP odpowiada któremu polu w systemie pasującym - oraz który system stanowi źródło nadrzędne, gdy kilka z nich zawiera tę samą wartość. Warsztaty odbędą się w dniach 1 i 2 i stanowią kluczowy moment całego projektu, ponieważ to właśnie tam podejmowane są decyzje dotyczące jakości danych, a nie później w kodzie. Proszę zabrać ze sobą osoby odpowiedzialne za utrzymanie systemów, a nie tylko tych, którzy kierują projektem - działy danych podstawowych, produkcji, jakości i zakupów rzadko funkcjonują w ramach jednego działu. Wszystko, co nastąpi później, czyli eksporty, walidacja i usuwanie błędów, to już kwestia praktyki.
Nasze certyfikaty są dostępne wyłącznie w postaci zeskanowanych plików PDF. Co mamy z nimi zrobić?
Skan nie jest ustrukturyzowanym źródłem danych i w związku z tym nie nadaje się do wykorzystania w paszporcie. Istnieją dwa skuteczne sposoby postępowania - operatorzy certyfikatów coraz częściej oferują zapytania za pośrednictwem interfejsu API, a tam, gdzie takie nie są dostępne, należy wprowadzać wartości ręcznie, pamiętając jednak zawsze o podaniu daty ważności, aby w opublikowanym paszporcie nie pozostał żaden certyfikat, którego ważność wygasła. Proszę zaplanować tę ręczną procedurę jako zadanie cykliczne, a nie jednorazowe.
Czy nasz dział IT może sprawdzić interfejs, zanim coś podpiszemy?
Tak. Pełny schemat oraz wszystkie punkty końcowe są dostępne w postaci specyfikacji OpenAPI pod adresem /apidocs, wraz z przykładowymi zapytaniami, odpowiedziami błędowymi oraz szczegółami dotyczącymi uwierzytelniania. Żadna z tych informacji nie jest objęta poufnością w ramach rozmów handlowych, więc Państwa zespół ds. integracji może oszacować nakład pracy jeszcze przed zawarciem umowy. Jeśli dostawca nie udostępnia swojego interfejsu na tym etapie, to również stanowi to pewną wskazówkę.
Co dzieje się z naszymi danymi, gdy zmieniamy dostawcę?
Dane są przenoszone. Interfejs akceptuje neutralny schemat JSON zamiast formatu zastrzeżonego, a cała Państwa baza danych jest udostępniana w formatach CSV, XLSX, JSON-LD i SQL lub za pośrednictwem interfejsu REST API. Jest to zamierzone działanie - format, który Państwo wypełniają, jest przenośny, więc zmiana wymaga jedynie eksportu, a nie tworzenia od nowa. Proszę zadać każdemu dostawcy to samo pytanie przed warsztatami dotyczącymi mapowania, ponieważ po ich zakończeniu nazwy Państwa pól znajdą się w modelu tego dostawcy.
Jak długo faktycznie trwa podłączenie?
W projektach, które realizujemy, proces ten trwa dwa tygodnie: dwa dni na mapowanie, trzy dni do pierwszych eksportów za pośrednictwem naszego narzędzia do walidacji, trzy dni na usuwanie błędów oraz dwa dni do opublikowania pierwszych paszportów. Najtrudniejszym etapem nigdy nie jest sam kod, lecz to, co wykrywa walidator - brakujące pola, niespójne kodowanie, wartości, za które nikt nie czuje się odpowiedzialny. Proszę zaplanować te dni, zamiast je skracać. Projekt, który pomija ten etap, publikuje wraz z danymi również te luki.
Czy musimy podłączyć wszystkie produkty jednocześnie?
Nie. Proszę zacząć od produktów, które jako pierwsze wymagają wprowadzenia danych, oraz od systemu źródłowego - neutralny schemat akceptuje zarówno częściowy katalog, jak i kompletny, a importy są powtarzalne, co oznacza, że kolejne przebiegi aktualizują stan magazynowy. Dzięki temu warsztaty dotyczące mapowania pozostają na tyle niewielkie, że można je zrealizować w ciągu dwóch dni. Późniejsze rozszerzenie zakresu jest zadaniem związanym z mapowaniem, a nie nowym projektem.
