Jakie są wymagania dla systemów ERP w branży cateringu dietetycznego?   

Okno zamówień zamyka się wieczorem. Do wydania to kilkanaście godzin, kierowcy ruszają w trasy między drugą a szóstą rano, a o siódmej zestaw ma stać pod drzwiami klienta. Producent jogurtu, konserw czy mrożonek ma w tym miejscu bufor: zapas wyrobu gotowego, który amortyzuje błąd planisty. Catering dietetyczny nie ma żadnego. Wczorajszego zestawu nie sprzeda się dziś, a nadprodukcja trafia do odpadu tego samego ranka. Czy tak jest u wszystkich? 

Z punktu widzenia systemu jest to produkcja procesowa o cyklu krótszym niż doba, z zamówieniem domykanym na dzień lub dwa przed startem zmiany. Pytanie, które zadaje sobie każdy, kto próbował podłożyć pod ten proces system IT: co z tego powinno mieszkać w ERP, a co obok? I dlaczego tak wiele takich projektów kończy się inaczej, niż zakładał plan? 

Polski rynek cateringu dietetycznego wart był około 3,5 mld zł na koniec 2024 roku według PMR, a liczba firm spadła z ponad sześciuset do mniej więcej czterystu. Konsolidacja premiuje tych, którzy panują nad realizacją zamówień i ich dostarczaniem, bo o rentowności w tym modelu rozstrzygają przede wszystkim dwie pozycje kosztowe: surowiec i ostatnia mila. 

Założenia:  

1. Horyzont zamówienia jest krótszy niż cykl produkcyjny. Plan powstaje na danych, których w momencie planowania jeszcze nie ma, a każda godzina zwłoki w decyzji zakupowej przenosi się wprost na braki albo na odpad. 

2. Surowiec i wyrób mają termin liczony w dniach. FEFO przestaje być jedną ze strategii magazynowych do wyboru i staje się warunkiem działania. Partia, która przeleży dwa dni w niewłaściwej kolejności pobrania, jest już stratą. 

3. Z jednej kuchni wychodzi kilkanaście, czasem kilkadziesiąt wariantów diety. Wariantowość wynika z receptury i gramatury, nie z kodu towaru. To inny problem niż rozmiary i kolory w modzie, gdzie wariant jest osobną pozycją magazynową. Tutaj wariant to inna proporcja tych samych składników, przeliczana na kaloryczność i składniki. 

4. Na każdej sztuce jest etykieta z wartością odżywczą i alergenami. Rozporządzenie 1169/2011 nie pozwala tego wpisywać ręcznie w arkuszu, jeśli receptura się zmienia: dane muszą wynikać ze składników, a zmiana składnika musi przechodzić na etykietę najlepiej bez udziału człowieka. 

5. Dostawa idzie w oknie czasowym, w nocy albo wczesnym rankiem, więc godzina opóźnienia na produkcji zabiera godzinę z okna dostaw. Druga szansa w ciągu dnia, jeśli w ogóle jest możliwa, jest dodatkowym kosztem. 

Poza wymienionymi powyżej dodatkowo firmy mierzą się z popytem, który jest jednocześnie zmienny i słabo lojalny: szczyt w styczniu i wiosną, dołek w wakacje, a pomiędzy nimi klient, który zmienia markę w zamian za rabat.  

Prognozowanie w tych warunkach jest trudniejsze niż w retailu, bo nie ma zapasu, którym można by zamortyzować pomyłkę, a zmienność różnych czynników wpływa na produkt końcowy 

Większość z procesów biznesowych tego typu działalności można obsłużyć w standardzie systemu, w mechanizmach, które są dostępne w Microsoft Dynamics 365 Supply Chain Management. Rolą partnera wdrożeniowego jest właściwy dobór konfiguracji i takie zwymiarowanie rozwiązania, aby osiągnąć kompromis między: wydajnością, kosztem utrzymania systemu, a pracą ręczną wykonywaną przez operatora lub jej automatyzacją. 

Podstawą jest receptura i zamówienia klienta, a nie struktura wyrobu znana z produkcji dyskretnej. Linia receptury może zawierać pozycje kupowane m.in ad hoc, współprodukty, produkty uboczne i pozycje o zmiennej wadze, a receptury mają wersje. Wersjonowanie brzmi jak drobiazg administracyjny do momentu, w którym trzeba odtworzyć, co dokładnie było w zestawie sprzed trzech tygodni. 

Termin przydatności wchodzi do planowania głównego, nie tylko do magazynu. Plan realizuje trzy cele w ustalonej kolejności: najpierw minimalizuje opóźnienia, potem maksymalizuje zużycie partii najbliższych terminu, na końcu ogranicza odnawianie zapasu. Gdy pierwsze dwa cele stoją w sprzeczności, system wybiera dotrzymanie terminu, a nie zużycie starszej partii. Dokumentacja zaleca przy tym, żeby okres pokrycia był krótszy niż termin przydatności pozycji. Przy terminach liczonych w dniach ten jeden parametr potrafi zdecydować o tym, ile surowca trafi do odpadu. 

Partia potrafi być zablokowana jednym kodem dyspozycji: niedostępna dla planowania, rezerwacji, kompletacji lub wysyłki, dopóki nie wróci wynik badania. Zamówienie sprzedaży można związać z jedną partią. Surowiec ważony, czyli mięso, ryba czy warzywa, ma obsługę zmiennej wagi w magazynie, więc różnica między wagą teoretyczną a rzeczywistą przestaje być korektą w Excelu. Tam, gdzie receptura opiera się na zawartości składnika aktywnego, działa bilansowanie partii. 

Etykieta i skan mogą wykorzystywać standard GS1, kody kreskowe i QR. Kontrola jakości ma własny moduł z planami pobierania próbek, obsługą niezgodności i świadectwami jakości, co pozwala na weryfikację punktów krytycznych z planu HACCP. Śledzenie partii wstecz i wprzód jest w standardzie systemu. 

Planowania nie trzeba za każdym razem uruchamiać na całym asortymencie. Dzięki temu planista, dowiaduje się o brakującej dostawie lub zmianach w terminach zakończenia produkcji, nie czeka na nowy plan, tylko przelicza wycinek, którego to dotyczy, może aktualizować plan działania i reagować na bieżące zmiany. 

Zlecenia i surowiec przypisane do potwierdzonych zamówień mogą zostać nienaruszone przy kolejnych uruchomieniach planu, na wszystkich poziomach struktury wyrobu. Przy planowaniu kilka razy dziennie to on rozstrzyga, czy poranne przeliczenie nie zabierze składników zestawom obiecanym już klientom. 

W produkcji tego typu bardzo ważnym elementem jest śledzenie pochodzenia towarów przez cały łańcuch Order to Cash oraz Plan to Produce. To nie to samo co śledzenie partii wstecz i wprzód w standardzie, które działa i jest ogólnodostępne. 

Wszystko powyżej dotyczy doboru funkcji, czyli najłatwiejszej części takiego projektu. W przedsięwzięciach tej klasy, które prowadzimy, system rzadko bywa przyczyną porażki. Częściej są nią decyzje podjęte, zanim ktokolwiek się do niego zalogował. 

Zaczyna się od kolejności uruchamiania zakresów. Finanse i magazyn przed produkcją czy odwrotnie, front zamówień na końcu czy na początku. Zła sekwencja nie daje o sobie znać na starcie. Wychodzi miesiące później, gdy kolejny zakres wymaga przebudowy tego, co już działa. 

Drugi punkt zapalny to sposób zbierania wymagań. „Dostosujcie system do tego, jak dziś pracujemy" brzmi rozsądnie i jest głównym generatorem modyfikacji. Metodyka wdrożeniowa firmy Microsoft zaleca zacząć od dopasowania do standardu, a dopiero potem szukać luk metodą fit/gap, przy wsparciu katalogu procesów biznesowych (Business Process Catalog). Odwrócenie tej kolejności daje projekt, w którym firma płaci za odwzorowanie własnych obejść z poprzedniego systemu. I tu zaczynają się pytania: co z wydajnością, jakie są koszty utrzymania, co z wersjonowaniem...? 

Stąd bierze się liczba modyfikacji, a każda z nich jest kosztem płaconym przy każdej aktualizacji. W jednym z projektów w naszym portfelu, wdrożeniu Dynamics 365 Finance dla firmy z branży adtech, klient był zaskoczony tym, ile zakresu udało się pokryć samym standardem. Projekt zamknął się w trzy miesiące, a przygotowanie raportowania grupowego skróciło się z około dwóch tygodni do dwóch dni. 

Osobno stoi pytanie o właściciela projektu po stronie klienta. Bez decydenta biznesowego z mandatem do podejmowania wiążących decyzji konsultant zaczyna zgadywać intencje, a rozstrzygnięcia zapadają na poziomie, na którym nikt nie odpowiada za wynik. 

Z tym wiąże się gotowość samego zespołu. Projekt wymaga ludzi, którzy przetestują procesy i przejdą szkolenia, a nie tylko zostaną do niego wyznaczeni obok pełnych obowiązków. Metodyka wdrożeniowa firmy Microsoft zaleca sprawdzić, jak szkolenie faktycznie zadziałało, zamiast odnotować, że się odbyło, i wskazuje grupy użytkowników podwyższonego ryzyka, w których opór pojawia się najczęściej. Wskazuje też mechanizm, który łatwo zlekceważyć: jeżeli zamawiający nie ufa temu, co mówi konsultant, nie stosuje jego rekomendacji, proces wychodzi gorzej, a zaufanie spada jeszcze bardziej. Praktyczny wniosek z naszych projektów jest prostszy: zakres, podjęte decyzje i otwarte kwestie muszą mieć jedno miejsce, do którego sięgają obie strony, zamiast być odtwarzane z maili i pamięci. 

Bywa też, że projekt traci ciągłość zespołu. Rotacja konsultantów w trakcie wdrożenia oznacza utratę wiedzy kontekstowej, której nie ma w żadnym dokumencie: dlaczego przyjęto taki model, co odrzucono i z jakiego powodu. 

Najdroższa do cofnięcia jest decyzja architektoniczna: co należy do ERP, a co ma stać obok niego. Obsługa strumienia transakcji o dużym wolumenie wymaga użycia rozwiązań sprawdzonych i dedykowanych do tych zadań.  

Z tą samą decyzją wiąże się druga, typowa dla dóbr szybko rotujących: co w systemie musi potwierdzić się natychmiast, a co może przejść w trybie wsadowym w godzinach mniejszego zapotrzebowania na moce obliczeniowe systemu. Do rozłożenia obciążenia można wykorzystać przetwarzanie wsadowe z grupami zadań, priorytetami i wątkami oraz możliwość przypisania osobnego serwera do każdej grupy. Rozdzielenie operacji wymagających odpowiedzi bez zwłoki od tych, które mogą poczekać, jest decyzją projektową. Podjęta za późno pokazuje, że system zwalnia dokładnie wtedy, gdy wymagana jest jego maksymalna efektywność. 

Skalę, w jakiej to działa, pokazuje nasz projekt w sieci Dealz. Każdy z ponad 360 sklepów jest tam w systemie osobnym magazynem, a nie punktem odbioru zaopatrywanym z centrali. To kilkaset lokalizacji zapasowych obsługiwanych jednym systemem od dnia uruchomienia, z aplikacją mobilną pracującą online w każdej z nich. Catering ma inną skalę i inny rytm, ale ten sam wymóg: operacja nie może czekać na system. 

Do tego dochodzi właściwe wymiarowanie środowiska pod wymagane zapotrzebowanie. Weryfikują je testy wydajnościowe przed startem, prowadzone na realnych wolumenach danych i na scenariuszach z dnia pracy, osobno dla obciążenia normalnego i szczytowego. Firma, która pierwszy raz mierzy wydajność w styczniu na produkcji, mierzy ją na własnych klientach. 

Zostaje jeszcze często pomijany element higieny środowiska i danych. Wolumen transakcji magazynowych rośnie i spowalnia system. Tym bardziej cykl życia danych trzeba zaplanować od pierwszego dnia, kiedy jest jeszcze parametrem konfiguracji. Zaplanowany po roku pracy produkcyjnej systemu staje się osobnym projektem. Do tego dochodzi rytm samych środowisk: aktualizacje, odświeżanie kopii testowych i regularne uruchamianie procedur czyszczących, które firma Microsoft wymienia wprost wśród warunków utrzymania wydajności. I tu pojawia się wiodąca rola partnera świadczącego usługi utrzymania i wsparcia rozwoju systemu. 

Prawie wszystkie te rozstrzygnięcia zapadają na etapie, na którym nie ma jeszcze czego testować. 

W cateringu dietetycznym o powodzeniu wdrożenia decyduje sekwencja zakresów i granica między tym, co mieszka w ERP, a tym, co stoi obok niego. 

Ustal sekwencję zakresów według jednej zasady: każdy kolejny etap ma dokładać, a nie zmuszać do przebudowy tego, co już działa. Metodyka wdrożeniowa firmy xalution, oparta na frameworku Microsoft „Success by Design”, proponuje budowanie z klocków i ostrzega przed odwrotną pokusą, czyli planem, w którym pierwsza faza obejmuje same podstawy, a to, co miało dać przewagę, ląduje w fazie drugiej. Wtedy zwykle nie przychodzi wcale, a użytkownicy dostają gorszą wersję systemu, który już mieli. Tak prowadziliśmy wdrożenie w firmie ETERNA, producencie odzieży działającym od 1863 roku: pierwsza faza spięła produkcję, magazyn i sprzedaż online w sześć miesięcy, trzy osobne systemy ERP zastąpił jeden, a kolejne etapy dokładano do działającego już rozwiązania. 

Rozstrzygnij granicę systemów, zanim wybierzesz dostawcę. Co jest w ERP, co obok i gdzie przebiega integracja, to decyzja architektoniczna, a nie punkt w zapytaniu ofertowym. Podjęta po podpisaniu umowy kosztuje wielokrotnie więcej. 

Potraktuj dopasowanie do standardu jako decyzję zarządu, nie konsultanta. Każde odstępstwo powinno mieć nazwisko osoby, która je zamówiła, i uzasadnienie biznesowe, które da się przeczytać za dwa lata przy okazji aktualizacji. 

Wymiaruj środowisko na szczyt zakupowy, bo średnia roczna jest w tej branży myląca. Cykl życia danych zaplanuj, zanim baza urośnie. 

Jeśli korzystasz z AI, zaczynaj od danych: najpierw porządek w danych transakcyjnych, potem prognoza, na końcu warstwa, która te wyniki komentuje. Ta kolejność nie jest kontrowersyjna: „garbage in, garbage out". Jeśli chcesz mieć porządek w danych musisz zadbać o to, aby właściwie nimi zarządzać w obecnych systemach oraz nowych, które planujesz implementować. 

W xalution wdrażamy Dynamics 365 Finance i Supply Chain Management od ponad dwudziestu lat, w Polsce, Czechach, Niemczech, Szwajcarii, Słowacji i Austrii, a polski zespół pełni w grupie rolę hubu analitycznego. Ostatni duży projekt w Polsce, wdrożenie Dynamics 365 Finance i Supply Chain Management w sieci Dealz, objął ponad 360 sklepów i zamknął się w sześć miesięcy, bez zamknięcia choćby jednego z nich na jeden dzień. 

Jeżeli masz już Dynamics 365 Finance i Supply Chain Management i widzisz w tym tekście własny projekt, punktem wyjścia nie musi być kolejne wdrożenie. Prowadzimy D365 Solution Assessment, czyli audyt istniejącego środowiska Finance i Supply Chain Management, niezależny od tego, kto je wdrażał: przegląd procesów, analiza fundamentu technicznego i przegląd kastomizacji pod kątem odporności na aktualizacje. Kończy się raportem zarządczym z listą działań w kolejności od tych, które można zrobić od razu. Umów rozmowę, a wskażemy, co da się poprawić bez ingerencji w system, a co wymaga decyzji na poziomie zarządu.