Czy system WMS/MES powinien dopasować się do Twojego procesu, czy odwrotnie?

Krótka odpowiedź

Ani system, ani proces nie powinien automatycznie „wygrać”.

Procesy wynikające ze specyfiki biznesu, wymagań klientów, regulacji czy technologii powinny zostać zachowane i odpowiednio obsłużone przez system. Procesy nieefektywne, ręczne lub będące historycznymi obejściami warto natomiast zmienić.

Dopiero gdy proces jest biznesowo uzasadniony, a standard i konfiguracja systemu nie pozwalają go właściwie obsłużyć, warto rozważyć rozszerzenie lub kastomizację WMS/MES.

Najważniejszym kryterium nie powinno być więc pytanie:

„Czy system zrobi dokładnie to, co robimy dzisiaj?”

lecz:

„Czy docelowy proces pozwoli osiągnąć lepszy wynik operacyjny?”

Jednym z najczęstszych oczekiwań wobec wdrożenia jest odwzorowanie obecnego sposobu pracy w systemie.

Brzmi logicznie: skoro firma działa w określony sposób, system powinien umożliwić jej dalszą pracę bez większych zmian.

Problem zaczyna się wtedy, gdy obecny proces nie jest wynikiem świadomego projektu, lecz efektem wieloletniego narastania wyjątków.

Proces może wyglądać dziś tak:

zamówienie → ręczna weryfikacja → Excel → decyzja pracownika → dokument → ponowna kontrola → system → wysyłka

Nie oznacza to automatycznie, że taki proces jest właściwy.

Część jego elementów może być konieczna. Inne mogą być pozostałością po czasach, gdy firma nie miała odpowiednich narzędzi.

Podczas analizy przedwdrożeniowej często pojawiają się argumenty:

• „pracownicy są do tego przyzwyczajeni”,
• „zawsze robiliśmy to w ten sposób”,
• „bez tego kroku nie czujemy się bezpiecznie”,
• „ten wyjątek zdarza się tylko kilka razy w miesiącu”,
• „musimy mieć możliwość ręcznej zmiany”.

Każdy z nich może być uzasadniony. Ale każdy powinien zostać zweryfikowany.

Warto zadać pytanie:

Jaki konkretny problem rozwiązuje ten element procesu?

Jeżeli odpowiedź brzmi: „tak już mamy”, jest to sygnał, że proces wymaga dalszej analizy.

Jeżeli natomiast odpowiedź brzmi: „wynika to z wymagań naszego klienta”, „jest konieczne ze względu na identyfikowalność partii” albo „pozwala nam obsługiwać określony typ produktu”, sytuacja wygląda zupełnie inaczej.

To jedno z podstawowych rozróżnień, które warto zrobić przed wdrożeniem.

Proces warto zachować, jeśli wynika ze specyfiki biznesu, wymagań prawnych, klientów, produktu, technologii lub rzeczywistej przewagi operacyjnej.

Proces warto zmienić, jeśli jest przede wszystkim historycznym przyzwyczajeniem, ręcznym obejściem ograniczeń systemu albo źródłem błędów i zbędnej pracy.

System warto dostosować, jeśli proces jest uzasadniony biznesowo, ale standardowe rozwiązanie nie pozwala go właściwie obsłużyć.

Dopiero takie rozróżnienie pozwala podjąć racjonalną decyzję.

Przed wyborem WMS lub MES warto przeanalizować procesy, do których system ma zostać dopasowany, a nie tylko opisać to, jak firma pracuje dzisiaj.

To zasadnicza różnica.

W analizie przedwdrożeniowej warto rozdzielić co najmniej trzy poziomy:

Bez tego łatwo wpaść w pułapkę odwzorowania stanu obecnego.

Przykładowo:

Magazyn wykorzystuje arkusz kalkulacyjny do przydzielania zadań pracownikom kompletacji. Pracownik magazynu otrzymuje listę, a kierownik ręcznie decyduje, komu przekazać konkretne zadanie.

Podczas wdrożenia można próbować odtworzyć ten mechanizm w WMS.

Można też zadać inne pytanie:

Czy ręczny przydział zadań nadal jest potrzebny, jeżeli WMS może wykorzystać informacje o lokalizacji, priorytecie, rodzaju zamówienia, obciążeniu stanowisk i dostępnych pracownikach?

To właśnie jest moment, w którym wdrożenie systemu staje się okazją do poprawy procesu, a nie tylko jego cyfryzacji.

Przynajmniej:

1. cel procesu – jaki rezultat chcemy osiągnąć,
2. przebieg procesu – jakie działania są rzeczywiście potrzebne,
3. wyjątki – kiedy i dlaczego proces przebiega inaczej,
4. mierniki – po czym poznamy, że działa lepiej.

Bez ostatniego elementu trudno ocenić, czy zmiana rzeczywiście była zmianą na lepsze.

Jeżeli celem jest skrócenie czasu realizacji zamówienia, trzeba mierzyć czas. Jeżeli celem jest ograniczenie błędów kompletacji, trzeba mierzyć ich liczbę. Jeżeli celem jest zwiększenie przepustowości, trzeba mierzyć liczbę obsługiwanych zamówień lub linii.

Proces nie powinien być broniony wyłącznie dlatego, że jest znany. Powinien być oceniany przez pryzmat rezultatu.

Decyzja o tym, czy zmienić proces, skonfigurować system czy stworzyć rozwiązanie niestandardowe, wpływa nie tylko na sam sposób pracy użytkowników.

Może przełożyć się na:

• czas i koszt wdrożenia,
• zakres testów,
• liczbę wyjątków w systemie,
• łatwość szkolenia pracowników,
• możliwość późniejszego rozwoju rozwiązania,
• koszty utrzymania,
• podatność systemu na zmiany,
• możliwość wykorzystania nowych funkcji w przyszłości.

Dlatego każda niestandardowa funkcja powinna mieć nie tylko uzasadnienie techniczne, ale również uzasadnienie biznesowe.

Jeżeli rozwiązanie rozwiązuje problem o dużej wartości operacyjnej – jego koszt może być uzasadniony. Jeżeli służy przede wszystkim zachowaniu przyzwyczajenia użytkowników, warto najpierw sprawdzić, czy nie lepiej zmienić proces.

Warto zadać pytanie o przyszłość:

Czy rozwiązanie, które dobrze działa przy obecnej skali operacji, pozostanie właściwe przy dwukrotnie większej liczbie zamówień, lokalizacji, użytkowników lub zleceń produkcyjnych?

To szczególnie ważne w przypadku kastomizacji. Rozwiązanie stworzone dla jednego konkretnego przypadku może rozwiązać dzisiejszy problem, ale jednocześnie utrudnić rozwój systemu w przyszłości.

Dlatego oceniając zmianę procesu lub funkcję niestandardową, warto patrzeć nie tylko na:

„czy działa?”

ale również:

„czy będzie skalować się razem z biznesem?”

Nie istnieje uniwersalna odpowiedź.

Można jednak zastosować prostą zasadę:

Im bardziej dany element procesu jest związany z realną potrzebą biznesową, tym mocniejszy jest argument za dopasowaniem systemu. Im bardziej wynika z historycznego sposobu pracy, tym mocniejszy jest argument za zmianą procesu.

Nie chodzi więc o to, aby podczas wdrożenia „przerobić firmę pod system”.

Chodzi o to, aby świadomie zdecydować, które elementy organizacji powinny pozostać niezmienione, a które są dobrym kandydatem do uproszczenia lub automatyzacji.

W praktyce decyzja o dopasowaniu WMS lub MES do procesu nie jest zero-jedynkowa.

Pomiędzy „system obsługuje to w standardzie” a „trzeba napisać rozwiązanie od zera” istnieje jeszcze bardzo duża przestrzeń konfiguracji.

Jeżeli system posiada funkcję, która realizuje wymagany cel biznesowy, korzystanie ze standardu jest zazwyczaj najbezpieczniejszym rozwiązaniem.

Dotyczy to sytuacji, w których różnica polega przede wszystkim na tym, że użytkownik jest przyzwyczajony do innego sposobu wykonywania operacji.

Przykład:

Magazyn od lat przydziela zadania kompletacyjne według kolejności ich otrzymania.

System może natomiast przydzielać zadania według priorytetu, lokalizacji towaru i optymalnej kolejności przejścia magazynu.

Jeżeli nowe rozwiązanie daje lepszy wynik operacyjny, nie ma powodu odtwarzać starego mechanizmu tylko dlatego, że jest znany pracownikom.

Standard nie oznacza gorszego dopasowania. Czasem oznacza wykorzystanie sprawdzonego sposobu rozwiązania problemu.

WMS i MES są projektowane tak, aby wiele elementów można było dostosować bez ingerencji w podstawowy kod systemu.

Przykładowo mogą to być:

• struktura magazynu,
• lokalizacje,
• reguły przyjęć,
• strategie kompletacji,
• priorytety,
• ścieżki procesowe,
• role użytkowników,
• uprawnienia,
• parametry produkcyjne,
• reguły kontroli jakości,
• sposób raportowania.

To często najlepszy kompromis.

Firma zachowuje uzasadnioną specyfikę, a jednocześnie nie buduje całego rozwiązania od podstaw.

Najwięcej ostrożności wymaga tworzenie funkcji niestandardowych.

Nie oznacza to, że kastomizacja jest czymś złym.

Może być uzasadniona, jeżeli:

• proces ma duże znaczenie dla biznesu,
• nie wynika wyłącznie z przyzwyczajenia,
• standard ani konfiguracja nie pozwalają osiągnąć wymaganego rezultatu,
• zmiana procesu byłaby nieuzasadniona biznesowo,
• korzyść przewyższa koszt stworzenia i utrzymania rozwiązania.

Problem pojawia się wtedy, gdy kastomizacja jest sposobem na uniknięcie każdej zmiany.

Podstawowa zasada jest podobna, ale charakter procesów jest inny.

W przypadku WMS dopasowanie systemu często dotyczy m.in. sposobu przyjęcia, składowania, kompletacji, pakowania, obsługi jednostek logistycznych, partii, numerów seryjnych czy reguł wydań.

W przypadku MES większe znaczenie mogą mieć m.in. technologia produkcji, kolejność operacji, parametry procesu, przezbrojenia, kontrola jakości, śledzenie produkcji oraz sposób zbierania danych z maszyn i stanowisk.

W obu przypadkach obowiązuje jednak ta sama zasada:

Specyfika procesu może uzasadniać dopasowanie systemu, ale sam fakt, że firma od lat pracuje w określony sposób, nie jest wystarczającym powodem do jego odwzorowania.

Dlatego analizę należy prowadzić osobno dla każdego procesu, a nie na poziomie ogólnego założenia, że „nasza firma potrzebuje indywidualnego systemu”.

Przed zaakceptowaniem rozwiązania niestandardowego warto określić, na co konkretnie ma ono wpłynąć.

Czy zmiana:

• zmniejszy liczbę operacji ręcznych?
• ograniczy liczbę błędów?
• skróci czas realizacji?
• zwiększy przepustowość?
• pozwoli obsłużyć większy wolumen bez proporcjonalnego zwiększenia zatrudnienia?
• ograniczy ryzyko związane z błędami lub brakiem danych?
• poprawi możliwość skalowania operacji?

Jeżeli nie potrafimy wskazać żadnego mierzalnego efektu, trudno uzasadnić koszt tworzenia rozwiązania niestandardowego.

W praktyce warto więc powiązać decyzję o zmianie procesu lub systemu z konkretnymi KPI.

Dla magazynu mogą to być na przykład:

• czas realizacji zamówienia,
• liczba linii kompletacyjnych na godzinę,
• liczba błędów kompletacji,
• czas przyjęcia towaru,
• wykorzystanie powierzchni,
• koszt realizacji zamówienia.

W produkcji:

• OEE,
• czas realizacji zlecenia,
• czas przezbrojeń,
• liczba braków,
• wykorzystanie maszyn,
• przestoje,
• terminowość realizacji.

Dzięki temu dyskusja o tym, czy zmieniać proces, czy system, przestaje być wyłącznie dyskusją techniczną.

Staje się decyzją operacyjną.

Jedną z największych korzyści z wdrożenia WMS/MES może być uporządkowanie procesów.

Ale sam fakt przeniesienia procesu do systemu nie oznacza jeszcze jego optymalizacji.

Jeżeli pracownik wcześniej wykonywał pięć zbędnych czynności, a po wdrożeniu WMS wykonuje te same pięć czynności na terminalu mobilnym, firma uzyskała cyfryzację.

Nie musi jednak oznaczać to optymalizacji.

Podobnie w produkcji.

Jeżeli operator wcześniej ręcznie wpisywał dane dotyczące realizacji zlecenia, a po wdrożeniu MES nadal wykonuje tę samą pracę, tylko w innym interfejsie, trudno mówić o wykorzystaniu pełnego potencjału systemu.

Dlatego przed automatyzacją warto zadać pytanie:

Czy ta czynność rzeczywiście powinna nadal istnieć?

Dopiero później:

Czy system może wykonać ją automatycznie?

To niewielka różnica w sposobie myślenia, ale może mieć duże znaczenie dla efektu wdrożenia.

Przy każdym istotnym wymaganiu warto przejść przez cztery pytania.

1. Czy proces jest biznesowo potrzebny?

Jeżeli nie – najpierw rozważ jego usunięcie lub uproszczenie.

2. Jeżeli jest potrzebny – czy system obsługuje go w standardzie?

Jeżeli tak – wykorzystaj standard.

3. Jeżeli nie – czy można osiągnąć wymagany efekt przez konfigurację?

Jeżeli tak – skonfiguruj system zamiast tworzyć rozwiązanie niestandardowe.

4. Jeżeli konfiguracja nie wystarcza – czy korzyść biznesowa uzasadnia rozszerzenie systemu?

Dopiero wtedy warto rozważyć kastomizację.

W skrócie:

niepotrzebny proces → zmień lub usuń

potrzebny + standard → wykorzystaj standard

potrzebny + konfiguracja → skonfiguruj

potrzebny + brak obsługi → oceń rozszerzenie/kastomizację

To prosta zasada, ale pozwala uniknąć sytuacji, w której każda różnica względem standardu automatycznie staje się wymaganiem do modyfikacji systemu.

To szczególnie istotne w organizacjach, które mają rozbudowane procesy.

Jeżeli dany wyjątek występuje raz na kilka miesięcy, nie oznacza automatycznie, że należy budować dla niego osobny mechanizm.

Warto ocenić:

• jak często występuje,
• jaki generuje koszt,
• jakie ryzyko powoduje,
• ile osób jest zaangażowanych,
• czy można obsłużyć go inną ścieżką,
• czy automatyzacja rzeczywiście się zwróci.

Inaczej wygląda sytuacja, gdy wyjątek pojawia się kilka razy dziennie i dotyczy istotnej części operacji.

Nie każdy wyjątek wymaga automatyzacji. Ale każdy istotny wyjątek powinien mieć świadomie zaprojektowany sposób obsługi.

Jeżeli firma jest dopiero na etapie wyboru rozwiązania, warto wykorzystać ten moment do czegoś więcej niż porównania list funkcji.

To pytanie jest zbyt ogólne.

Dwa systemy mogą deklarować obsługę tego samego procesu, ale realizować go zupełnie inaczej.

Dlatego warto pytać:

• Jak system realizuje ten proces?
• Jak obsługuje wyjątki?
• Co dzieje się w przypadku błędu?
• Jakie dane są potrzebne?
• Które decyzje podejmuje system, a które pracownik?
• Czy rozwiązanie wymaga dodatkowych operacji ręcznych?
• Jak proces jest mierzony?

Dzięki temu porównujemy nie tylko funkcje, ale rzeczywisty sposób działania.

Dobre demo systemu nie powinno ograniczać się do prezentacji przygotowanego scenariusza.

Warto pokazać dostawcy rzeczywisty, trudny przypadek z własnej organizacji.

Na przykład:

• nietypowe przyjęcie,
• brak towaru podczas kompletacji,
• częściową realizację zamówienia,
• zmianę priorytetu,
• produkt wymagający śledzenia partii,
• reklamację,
• korektę procesu,
• nietypowe zlecenie produkcyjne.

Następnie zapytać:

„Jak system obsłuży tę sytuację i co będzie musiał zrobić pracownik?”

Takie pytanie często mówi o dopasowaniu rozwiązania więcej niż kilkadziesiąt pozycji w tabeli funkcjonalności.

W praktyce wdrożeniowej warto rozdzielić trzy rzeczy: funkcję systemu, jej konfigurację oraz rozwiązanie niestandardowe.

W rozwiązaniach takich jak @Asiston WMS czy @Asiston Produkcja istotne jest właśnie określenie tej granicy: które wymagania można obsłużyć w standardzie, które wynikają z konfiguracji konkretnej organizacji, a które rzeczywiście wymagają dodatkowego rozwiązania.

Dzięki temu analiza przedwdrożeniowa nie sprowadza się do tworzenia długiej listy „system musi mieć”, ale prowadzi do określenia docelowego sposobu pracy i zakresu systemowego wsparcia.

Największa wartość systemu nie zawsze polega na tym, że zastępuje papier albo arkusz kalkulacyjny.

Znacznie ważniejsze jest to, że może zmienić sposób podejmowania decyzji.

W tradycyjnym modelu część procesu może wyglądać następująco:

dane → ręczna analiza → decyzja pracownika → wykonanie → ręczne sprawdzenie

W bardziej dojrzałym modelu:

dane → reguła → decyzja → wykonanie → pomiar → optymalizacja

To zasadnicza różnica.

WMS może nie tylko rejestrować przyjęcie towaru, ale również sterować jego rozmieszczeniem.

Nie tylko rejestrować kompletację, ale wpływać na kolejność realizacji zadań.

Nie tylko zapisywać wynik inwentaryzacji, ale dostarczać danych pozwalających analizować źródła rozbieżności.

MES może nie tylko zbierać informacje z produkcji, ale łączyć dane o realizacji zleceń, parametrach procesu, przestojach, jakości czy efektywności.

Wtedy system przestaje być elektronicznym rejestrem operacji.

Staje się narzędziem zarządzania operacją.

Wdrożenie systemu wymusza zadanie pytań, które w codziennej pracy często są odkładane:

• dlaczego robimy to w ten sposób?
• kto podejmuje decyzję?
• na podstawie jakich danych?
• gdzie powstaje informacja?
• ile razy jest przepisywana?
• co dzieje się w przypadku błędu?
• kto odpowiada za wyjątek?
• czy ten krok jest nadal potrzebny?

Dlatego wdrożenie WMS lub MES warto potraktować nie tylko jako projekt IT.

To również projekt operacyjny.

System będzie tak dobry, jak dobrze zaprojektowany jest sposób, w jaki organizacja chce z niego korzystać.

Dojrzałe podejście do wdrożenia WMS/MES nie polega na wyborze jednej z dwóch skrajności.

Nie chodzi o to, aby:

dopasować firmę do systemu za wszelką cenę.

Nie chodzi też o to, aby:

odtworzyć w systemie każdy element obecnego procesu.

Chodzi o znalezienie właściwej granicy pomiędzy:

standardem systemu,

konfiguracją,

zmianą procesu,

a rozszerzeniem systemu.

Najważniejszym kryterium powinien być nie komfort zachowania dotychczasowego sposobu pracy, ale wartość biznesowa danego procesu.

Dlatego przed wdrożeniem warto przeanalizować każdy istotny proces według prostego schematu:

Czy jest potrzebny? → Czy daje wartość? → Czy można go uprościć? → Czy system obsługuje go w standardzie? → Czy potrzebna jest konfiguracja? → Jeżeli nie, czy koszt rozszerzenia jest uzasadniony?

To pozwala uniknąć dwóch kosztownych błędów.

Pierwszego – wdrażania systemu pod stare, nieefektywne procesy.

Drugiego – wymuszania zmian tam, gdzie specyfika biznesu rzeczywiście wymaga indywidualnego podejścia.

Dobry WMS/MES powinien dopasować się do uzasadnionych potrzeb operacyjnych firmy, ale nie powinien bezrefleksyjnie kopiować jej obecnego sposobu pracy.

Najlepszym efektem wdrożenia nie jest system, który potrafi odwzorować wszystko, co firma robiła wcześniej.

Jest nim system, który pozwala firmie pracować lepiej niż wcześniej – w sposób mierzalny, powtarzalny i możliwy do dalszego skalowania.

Jeżeli analizujesz wdrożenie WMS lub MES, warto przed rozpoczęciem projektu rozdzielić trzy kwestie:

co zachować, co uprościć i co przekazać do obsługi systemu.

Podczas rozmowy możemy przeanalizować wybrany proces i wspólnie określić, czy lepszym rozwiązaniem będzie zmiana sposobu pracy, konfiguracja systemu czy rozwiązanie niestandardowe.

Porozmawiajmy o Twoim procesie i sprawdźmy, gdzie rzeczywiście potrzebne jest dopasowanie systemu.