Waga produktu jest zapisana w module gospodarki materiałowej. Udział materiałów pochodzących z recyklingu znajduje się w systemie receptur. Certyfikat dostawcy jest dostępny w formacie PDF na dysku sieciowym. Paszport produktu wymaga wszystkich trzech danych w jednym rekordzie, i właśnie w tym polega projekt integracji, 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 pokazujemy, jakie dane z Państwa systemów są potrzebne do sporządzenia paszportu, 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 sporządzić 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 (w celu spełnienia 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 między 4 a 7 modułów: gospodarka materiałowa, produkcja, jakość, baza dostawców, czasami oddzielny moduł danych środowiskowych, a czasami osobny system receptur i list części.
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 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 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 do odczytu poszczególnych danych.
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 jest to zazwyczaj rozwiązanie zbyt rozbudowane.
Sposób 3: Wykorzystanie istniejącej warstwy integracyjnej
Dysponują 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 stron trzecich do systemu ERP.
Wady: Państwa 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. My zasadniczo wprowadzamy etap pośredni: nasz interfejs, Transpareo Connect, 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 dowolnym momencie 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 Państwa dane przed ich przesłaniem
Pełny opis formatu oraz wszystkie zapytania są publicznie dostępne w dokumencie „ Dokumentacja API ” (Opis interfejsu zgodnie z OpenAPI). Państwa dział IT może sprawdzić interfejs przed podpisaniem umowy - łącznie z przykładowymi zapytaniami, odpowiedziami o błędach 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 w formacie 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 dane 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: trójpoziomowy model 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₂ w oparciu o 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 należy 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?)
- W jakich systemach przechowywane są 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.
Odpowiedzi te decydują o tym, 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 one kończą się w tym samym punkcie końcowym. Oprogramowanie pośredniczące ma sens, jeśli i tak już je Państwo wykorzystują, a ma ono pozostać elementem umowy z podmiotami zewnętrznymi. Jeśli obecnie go Państwo nie posiadają, nie należy go nabywać wyłącznie na potrzeby paszportu 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 serwisu Transpareo Connect są dostępne w postaci specyfikacji OpenAPI pod adresem Dokumentacja API, wraz z przykładowymi zapytaniami, odpowiedziami błędów 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 ujawnia 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.
