Wdrożenie WMS. Jak unikać ryzyka

Rozwinięcie artykułu opublikowanego w "Transport wewnętrzny i magazynowanie" 2/2013 [ISSN 2084-350X]
Autor: Marek Wierzbicki

Wdrożenie WMS to długotrwały proces, który wymaga zaangażowania wielu osób z różnych działów, nie tylko związanych bezpośrednio z intralogistyką magazynową i koordynacji ich działań z pracownikami dostawców oprogramowania. Warto wiedzieć które decyzje i jakie zachowania zwiększają niebezpieczeństwo niepowodzenia wdrożenia, żeby ich unikać bądź kłaść szczególny nacisk na kontrolę tych ryzykownych obszarów. Postaram się przybliżyć jak podejść do tego projektu, aby ryzyko niepowodzenia było jak najmniejsze.

Wdrożenie WMS i ewentualne problemy związane z tym zaczynają się znacznie wcześniej, niż pojawi się dostawca programu magazynowego – dzieje się to niemal jednocześnie z narodzinami świadomości, że potrzebny jest nowy system informatyczny. Nie ważne czy dotyczy to pierwszego wdrożenia, wymiany posiadanego systemu na inny czy też uruchomienia kolejnych modułów (np. połączenia z automatyką magazynową czy uruchomienie obsługi niestandardowej metody kompletacji).

Pierwszy ważny krok, który należy wykonać przed wyborem WMS czy rozszerzeniem jego funkcjonalności to stworzenie specyfikacji wymagań. Jest to sformalizowany koncert życzeń, który pozwoli (po uruchomieniu) na realizację oczekiwań biznesowych związanych z wdrożeniem. Dobrze przygotowana specyfikacja powinna być wielowariantowym dokumentem, przeznaczonym zarówno dla zarządu jako uzasadnienie inwestycji, dla dostawcy jako opis zamówienia, dla kadry kierowniczej jako wytyczne nadzoru do projektu, a na zakończenie jako lista sprawdzająca efektywność i sensowność inwestycji. Oczywiście inne aspekty należy uwypuklić w czasie dyskusji właścicielskich nad sensownością inwestycji, a inne w okresie poszukiwania dostawcy, w czasie wdrożenia czy rozliczania inwestycji. Ale mowa wyłącznie o innym spojrzeniu na ten sam dokument. Podstawowym błędem popełnianym bardzo często, który podnosi ryzyko klęski, jest rozdzielanie specyfikacji oczekiwań od uzasadnienia inwestycji, zarządzania projektem i rozliczania inwestycji. Tworzenie tych dokumentów w sposób rozłączny, nie powiązany ze sobą podnosi ryzyko nieudanego wdrożenia. Rozdzielenie ich powoduje rozejście się wymagań i oczekiwań różnych grup jeszcze przed rozpoczęciem definiowania oczekiwań, gdyż każdy z dokumentów będzie później żył własnym życiem nie związanym z pozostałymi dokumentami. Należy też pamiętać, aby w obszarze specyfikacji wymagań znalazły się również oczekiwania związane z obsługą powdrożeniową (zarówno warunki HelpDesk jak i ewentualnego dalszego rozwoju systemu). Już na etapie przygotowania specyfikacji oczekiwań warto zacząć współpracę z firmą doradczą, aby dokument ten spełniał opisane tu różnorodne wymagania. Często kwestie informatyczne są skorelowane z projektem logistycznym magazynu, aby zmiana w pracy firmy była spójna ze sobą w szerszym zakresie.

Wzorcowa specyfikacja oczekiwań systemu WMS powinna bazować na kilku kluczowych celach, które powinny być zamknięte w niezbyt długich i nieskomplikowanych zdaniach. W zależności od perspektywy spojrzenia cele te powinny być rozwijane pod kątem poszczególnych odbiorców. Takim przykładowym celem może być: Zwiększenie ilości towaru przechowywanego w magazynie dzięki zastosowaniu dynamicznemu przydzielaniu miejsc składowania. Dla zarządu należy rozwinąć ten cel w potencjalną obniżkę kosztów jednostkowego składowania towaru poprzez minimalizację liczby niewykorzystanych półek w porównaniu do modelu ze stałym przypisaniem towaru do lokalizacji. Dla dyrektora logistyki i kierownika magazynu należy to rozwinąć w konieczne do zaprojektowania procesy. Do ich zadań powinna należeć konieczność oszacowania zysków z wprowadzenia tych zmian na podstawie sezonowości obsługiwanego towaru. Dla dostawcy oprogramowania cel należy rozwinąć w możliwe warianty procesów i ich parametryzowania. Dla firmowych informatyków cel należy przekształcić na zalecenia zmian w infrastrukturze (np. sieć bezprzewodowa). Menadżer projektu musi z tych wszystkich celów wyłuskać kolejności poszczególnych etapów, ścieżkę krytyczną zadań i kamienie milowe. A po zakończeniu wdrożenia trzeba sprawdzić, czy cel został zrealizowany i z jakim efektem finansowym.

W przypadku systemu zarządzania magazynem celami może zmniejszenie poziomu błędów wysyłki do klienta sklepu internetowego, przyspieszenie kompletacji, minimalizacja rozbieżności inwentaryzacyjnych, konieczność spełnienia norm branżowych (żywnościowych bądź farmaceutycznych), wprowadzenie możliwości szacowania wiarygodności dostawców za pomocą wskaźnika OTIF, realizacja szczególnych oczekiwań klienta czy inne. Najczęściej celem zakupu WMS jest realizacja większej liczby potrzeb. W takim wypadku powinno ustalić się priorytety poszczególnych celów oraz ich wagi co będzie miało znaczenie przy ocenie inwestycji. W wyznaczeniu celów strategicznych może pomóc audyt logistyczny, który powinien być przeprowadzony wcześniej.

Jednym z celów wdrożenia WMS powinno być porządkowanie przepływu towaru w magazynie. W firmach z długą historią zdarza się, że wiele procesów obecnych w intralogistyce było modyfikowane ad-hoc na potrzeby jednorazowych działań, a z czasem stawały się one regułami obowiązującymi na dłużej. Jeśli nałożymy na to podejście problemy wynikający z braku aktualności danych "papierowych" może się okazać, że obecnie funkcjonujące procesy "efektywne" mają się nijak do nowej cyfrowej sytuacji, którą zamierza się stworzyć. Przeniesienie takich pozornie poprawnych procesów do WMS może doprowadzić do tego, że otrzymamy dobrze zinformatyzowany bałagan. Na etapie tworzenia specyfikacji oczekiwań programu magazynowego należy więc podjąć decyzję jak poprowadzić wdrożenie z perspektywy zmian w procesach. Jako firma zajmująca się doradztwem logistycznym sugerujemy zaczynać od modyfikacji procesów, a potem poszukiwać oprogramowania najlepiej pasującego do tych procesów. Interesującą alternatywą jest poszukiwanie rozwiązań u dostawców specjalizujących się w danej branży i zaadaptowanie procesów standardowych dla danej branży do własnych potrzeb. W praktyce żadne ze skrajnych podejść (modyfikacja wszystkich procesów bądź przejęcie wszystkich procesów od dostawcy systemu) nie jest możliwe do zastosowania. Nie mówiąc o tym, że sensowność tych skrajnych podejść jest niewielka. Zazwyczaj trzeba wybierać pomiędzy przejęciem części najlepszych praktyk z wybranego oprogramowania jak i sztywną implementacja niektórych kluczowych procesów zbudowanych wewnętrzne we własnej firmie, które decydują o przewadze konkurencyjnej (a przynajmniej tak się wydaje). Jednak zaczynając wdrożenie należy zdecydować się czy raczej idziemy w kierunku modyfikacji istniejących w firmie procesów czy stawiamy na customizację wdrażanego WMS.

Decyzja związana z wyborem sposobu podejścia do procesów charakterystycznych dla firmy bądź typowych dla branży wpływa na ścieżkę wyboru dostawcy. Zazwyczaj akceptacja rozwiązania branżowego oznacza trochę mniejszą elastyczność dostawcy w zakresie modyfikowania procesów w obszarze oferowanego oprogramowania. Z drugiej strony daje to nadzieję na przejęcie know-how z branży bądź wcześniejszych wdrożeń. Obszar ten związany jest z wyborem dostawcy WMS, tak więc nie będzie poruszany w tym tekście.

Już na etapie tworzenia specyfikacji systemu informatycznego, można wnioskować o jego potencjalnym zagrożeniu. Klasyczne, wysoko ryzykowne zachowania mogą wynikać z przeniesienia odpowiedzialności za wdrożenie WMS z pionu logistyki magazynowej na dział IT (na zasadzie, że skoro to oprogramowanie, to niech to robią to informatycy). Innym błędem jest próba rozproszenia odpowiedzialności na zbyt dużą liczbę osób (osoba z obszaru przyjęcia dostaw, magazynu zasobowego, kompletacyjnego, zwrotów, ktoś z działu IT, księgowości i kilku innych działów). Wtedy każda decyzja wymaga konsensusu kilkunastu osób. Zazwyczaj wynika to z pomylenia pojęcia Komitetu sterującego z rozproszeniem decyzyjności. Oba wspomniane podejścia stwarzają ryzyko porażki projektu.

Jak ratować się przed taką sytuacją? Ewidentnie należy znaleźć się w firmie osobę, która ma odpowiednie kompetencje i wiedzę do tego by prowadzić merytorycznie projekt i spinać ze sobą różne zagadnienia. Ponadto musi on mieć na tyle silną pozycję w hierarchii zawodowej, żeby móc wymagać i egzekwować od poszczególnych pracowników (które będzie włączał do projektu) realizacji postawionych przed nimi zadań (oczywiście nie unikając odpowiedzialności za własne decyzje). Niestety z istnieniem tego człowieka związane jest kolejne ryzyko, często niedoceniane przez zarząd. Zazwyczaj do takiej pracy wyznaczany jest ktoś zaufany, kto ma już w swoim zakresie obowiązków wiele innej pracy i nie jest w stanie wyrobić się z już posiadanym zakresem. Klasyczny błąd ma swoje źródło w przekonaniu, że Przyjdzie zewnętrzna firma informatyczna, wdroży nam program i wszystko ruszy z kopyta. Niestety to błędne podejście o zbawiennym wpływie zewnętrznego dostawcy dziedziczy się na wszystkich pracowników, którzy powinni brać aktywny udział we wdrożeniu.

Pewnym sposobem na ratunek jest zatrudnienie dodatkowych sił koniecznych do zakończenia projektu. Pojawia się tu pewne zdziwienie – wynajmujemy firmę informatyczną i mamy jeszcze zatrudnić im do pomocy dodatkowych ludzi? Otóż te dodatkowo zatrudnione osoby nie będą pomagać dostawcy, tylko będą pomagać zamawiającemu poprawnie przejść przez wdrożenie. Czy nie można więc zapłacić dostawcy systemu WMS więcej, zażądać więcej i zapomnieć o dodatkowych siłach po własnej stronie? Nie można! Styk dostawcy i odbiorcy oprogramowania to bardzo szeroka płaszczyzna, która musi być poprawnie obsługiwana z obu stron. Zarówno przez dostawcę jak i przez klienta. Drastyczne zwiększenie zatrudnienie po stronie dostawcy nie zmniejsza znacząco zapotrzebowania na pracowników dedykowanych do obsługi tego projektu ze strony odbiorcy systemu informatycznego. Sposobem na ominięcie klasycznego zatrudniania pracowników może tu być tzw. Interim manager albo doradca logistyczny bądź informatyczny, który stanie po stronie zamawiającego WMS.

Potrzeba dodatkowych sił w firmie wynika również z częstego stosowania bardzo efektywnego sposobu szkolenia tzw. metodą kluczowych użytkowników (Key User). Dostawca szkoli tylko niektórych pracowników magazynu, którzy później przekazują wiedzę dalej wewnątrz firmy. Często osoby te otrzymują w przyszłości wyższe uprawnienia do systemu i spośród nich wyłaniani są administratorzy funkcjonalni, mający uprawnienia do wykonywania czynności wymagających wyższej odpowiedzialności i manipulowanie niektórymi krytycznymi funkcjami systemu (np. sposób uwalniania lokalizacji magazynowych w czasie kompletacji). W trakcie wdrożenia to użytkownicy kluczowi powinni uczestniczyć w kontroli, czy funkcjonalność zamówiona u dostawcy jest realizowana we wdrażanych modułach i na bieżąco reagować, jeśli pojawia się niezgodność wynikająca na przykład ze zbyt literalnego potraktowania specyfikacji oprogramowania. Warto wyłonić te osoby już na etapie budowy specyfikacji oczekiwań WMS, wtedy zapewne włączą się one w tworzenie projektu i łatwiej będzie im dokonywać kontroli zgodności systemu z oczekiwaniami, gdyż będą to wspólnie wypracowane oczekiwania. Podobnie jak w przypadku zarządzającego projektem nie można zlecić tej pracy jako dodatkowa czynność najlepszym pracownikom, gdyż nie wyrobią się z nadmiarem pracy.

Jednym z kluczowych aspektów związanych z wdrożeniem (w szczególności dotyczy to systemów WMS) jest określenie sposobu uruchamiania systemu z perspektywy podejścia etapowego, czyli procesów, które będą digitalizowane jako pierwsze i kiedy warto "zamykać" ich funkcjonalność produkcyjnie. Przy czym nie mam tu na myśli zwinnych metodyk Agile czy Scrum, które dotyczą dochodzenia do ostatecznych możliwości w sposób zwinny, ale oddawania do użytku pewnych modułów krok po kroku, bez czekania na gotowość do pracy wszystkich procesów. W praktyce oznacza to, że na początku uruchamiamy system WMS w bardzo okrojonej wersji, obsługującej wyłącznie podstawowe procesy, a kolejne moduły wdrażamy później, gdy tylko są gotowe do produkcyjnej pracy. Ten pozornie nie najlepszy pomysł bazuje na znanej wszystkim zasadzie Pareto, która w tym konkretnym przypadku może być przekształcona na zależność, że 80% przepływu towaru dotyka 20% funkcjonalności systemu. Dzięki takiemu podejściu już po 3-4 miesiącach od uruchomienia współpracy między dostawcą oprogramowania i jego klientem jesteśmy w stanie obsługiwać informatycznie większość procesów intralogistycznych w obszarze informatyzowanego magazynu.

Oczywiście ten sposób działania poza zaletami ma również wady. Jedną z odstawowych jest konieczność życia w trakcie ciągłej zmiany czasem nawet przez okres ponad roku. Jeśli przechodzimy z tzw. "papierowego magazynu" na magazyn obsługiwany elektronicznie, w pierwszym etapie dokonujemy konwersji na system WMS w 60-70%. Niestety niemal zawsze oznacza to, że pozostała część procesów nie tylko pozostaje "papierowa", ale dodatkowo wymaga pewnych zmian w podejściu pracowników (staje się ona "papierowa, ale inaczej niż dotychczas"). Kolejne kroki obejmują digitalizację kolejnych "papierowych" procesów od najczęściej wykorzystywanych i najłatwiej podlegających informatyzacji. Dzięki temu każdy kolejny krok obejmuje coraz większy obszar związany z przepływem towaru przez magazyn i po trzecim kroku zazwyczaj WMS obejmuje już ponad 95% przepływu towaru. Innym problemem, który wypływa na wdrożenie w nieoczekiwany sposób jest konieczność obsłużenia działań, które wcześniej były mało istotnę, bądź w ogóle nie występowały. Klasycznym przykładem może być obsługa danych podstawowych czyli master data. W erze "papierowej" wymiary czy waga towaru była mało istotnym elementem układanki. Często uruchomienie produkcyjne nie może wystartować zanim wszystkie towary nie zostaną pomierzone i zważone, a często trzeba również uzupełnić inne dane o towarze jak struktura pakowania czy czasem nawet zdjęcie produktu. Warto o tym pamiętać, bo takie szczegóły mogą znacząco opóźnić start systemu.

Ten sposób uruchomienia produkcyjnego wzbudza niepokój wśród firm, które miały wcześniej negatywne doświadczenia z dostawcami systemów informatycznych. Dotyczy to szczególnie przypadków, gdy dostawcy zachowywali się bardzo dobrze w okresie wdrożenia a nagle stawali się bardzo "oschli" we współpracy po jego zakończeniu. Zwracam uwagę, że najczęściej problem leży tu po stronie próby nadmiernego "wyciskania" dostawcy, czyli ustalenia wynagrodzenie za późniejszy rozwój na bardzo niskim poziomie. Przeciwko takiemu podejściu protestują też firmy, które wcześniej miały bardzo dobrzy system WMS obsługujący ich magazyn lecz ze względów technicznych musiały go zmienić (np. brak możliwości integracji z nowym systemem ERP narzuconym przez spółkę matkę).

Jako firma zajmująca się doradztwem logistycznym ze sporym doświadczeniem w obszarze nadzoru wdrożeń WMS możemy powiedzieć, że etapowe podejście statystycznie nie obniża ryzyka porażki, ale często znacząco przyspiesza produkcyjne uruchomienie systemu. Oczywiście zależy to od wielu kwestii, jednak zawsze warto rozważyć takie podejście.

Kolejny element związany z obniżaniem ryzyka wdrożenia to kontrola postępu i ewentualny plan awaryjny. Kontrola powinna wynikać ze specyfikacji systemu opisanej na początku artykułu, która powinna zawierać również mierniki postępu i kamienie milowe. Jeśli nie zostały one odpowiednio zdefiniowane na początku, to trudno będzie je egzekwować na końcu. Jeśli dostawca deklarował wykonanie kilku podobnych funkcjonalności w podobnym czasie, to nie wolno w trakcie trwania projektu przyjąć do wiadomości tłumaczenia, że pierwsza funkcjonalność jest najtrudniejsza i w kolejnych będzie się wykorzystywało fragmenty napisane wcześniej. Dostawca powinien to przewidzieć zanim zacznie pracę i wpisać właśnie taki plan do harmonogramu. Skoro nie wpisał, to można podejrzewać, że jest to szukanie usprawiedliwienia, a nie rzeczywista przyczyna opóźnienia. Jest więc to właściwy moment na natychmiastowe podjęcie działań naprawczych.

Znacznie większym problemem jest jednak brak planu awaryjnego. Jeśli termin produkcyjnego uruchomienia WMS skorelowany jest z innymi inwestycjami (np. budowa czy automatyzacja magazynu) należy przewidzieć przypadek, że oprogramowanie nie będzie gotowe na czas. Plan awaryjny powinien powstawać razem z planem głównym, gdyż przygotowanie się do jego do realizacji może wtedy przebiegać niemal bezkosztowo. Realizacja tego planu z opóźnieniem może być niezwykle kosztowna. Planem awaryjnym jest najczęściej próba przygotowania się do obsługi nowego magazynu za pomocą posiadanego oprogramowania i prostych nakładek czy interfejsów. Należy ją rozważyć, nawet jeśli wydaje się to pewną stratą czasu a czasem nawet wymaga drobnych nakładów finansowych. Karygodne jest natomiast podejście (niestety często stosowane), że inwestycja ta jest tak ważna, że musi się udać.

Wymienione przypadki to najczęściej pojawiające się problemy w trakcie wdrożenia WMS, choć oczywiście nie jedyne. Najlepszą metodą unikania ryzyka będzie bieżąca analiza zdarzeń występujących w trakcie projektu. Wszystkie niepokojące sygnały należy wyjaśniać bez nadmiernej podejrzliwości, ale też bez nadmiernego pobłażania. Jeśli jakieś zdarzenie nie było zapisane w harmonogramie wdrożenia, a nagle zaczyna zajmować zbyt dużo czasu i zasobów należy dążyć do wyjaśnienia tego przypadku. Jeśli dostawca deklaruje, że dzięki temu inny etap ulegnie skróceniu należy dotrzeć do źródeł tego optymizmu i spróbować go zweryfikować. Z drugiej strony należy pamiętać, aby nie tworzyć przesadnie restrykcyjnej atmosfery na styku klient-dostawca, gdyż może to doprowadzić do zaostrzenia stosunków zanim pojawi się rzeczywisty problem, który będzie wymagał ostrej interwencji. Ale tych kwestii nie da się niestety zapisać w żaden formalny sposób.