SAP EWM – Wspomnienia z wdrożenia, część I

W ostatnim czasie, dość częstym dylematem firm posiadających moduł WM jest przejście na wersję SAP S/4 HANA z wbudowanym komponentem EWM, czy po prostu na zdecentralizowany system SAP EWM. Czy warto robić to już teraz, czy może warto poczekać? Jak wdrożyć to dobrze, aby nie było przestojów i czy wniesie to w ogóle jakąś wartość dodaną. Artykuł ten jest relacją naocznego świadka projektu implementacji zdecentralizowanego systemu SAP EWM w firmie produkcyjnej, która nie prowadzi działalności związanej z zarządzaniem powierzchnią magazynową.

Jako członek projektu implementacji SAP EWM, miałem przyjemność uczestniczyć w dwóch wdrożeniach odbywających się fizycznie w tym samym zakładzie, ale systemowo w dwóch (w ramach jednego projektu). Dlaczego? Ponieważ do jednostki gospodarczej, przypisane były systemowo dwa odrębne zakłady (czytaj struktury organizacyjne modułu MM). Jeden z nich zajmował się produkcją wyrobów gotowych, składających się głównie z jednego surowca. Drugi natomiast produkował wyroby o bardzo złożonej i zmiennej strukturze (nawet po 40 komponentów) w referencji do zlecenia sprzedaży (czyli realizował plan produkcji dyskretnej). Początkowy zamiar był taki, aby przeprowadzić wdrożenie dla dwóch zakładów jednocześnie (ponieważ były one przypisane do tego samego numeru magazynu), jednakże trudności na jakie napotkano już w fazie blueprint spowodowały zmianę decyzji i postanowiono rozbić całego przedsięwzięcie na dwa etapy. Przebieg pierwszego wdrożenia odbył się zgodnie z planem i każdy jego etap realizowany był w ustalonym terminie, a nawet powiedziałbym, że projekt ten został prawie niezauważony. Wynikało to z tego, iż 90% procesów biznesowych odbywało się zgodnie ze standardami SAP, ponieważ prostota struktury wyrobów oraz biznesowe wymagania nie wymuszały stosowania żadnych rozszerzeń czy niestandardowych rozwiązań. Etap ten poszedł bardzo gładko i był rozgrzewką przed wdrożeniem EWMki w drugim zakładzie. To już była zupełnie inna bajka. Co komplikowało ten etap? Pojawiły się następujące wymogi:

  • zastosowanie oddzielnych strategii wydania dla każdego typu magazynu,
  • wiele stałych miejsc składowania w różnych typach dla tego samego produktu,
  • integracja automatycznego regału windowego,
  • implementacja kompletacji zleceń przy użyciu technologii Pick-by-Voice, optymalizacja ścieżek kompletacji
  • wiele punktów dekonsolidacji przy przyjęciu towarów,
  • wiele punktów identyfikacyjnych (ID-point) dedykowanych dla oddzielnych grup produktów
  • punkty poboru (pick-point) dla wszystkich części pochodzących ze strefy wysokiego składowania, lub regałów przesuwnych.

Dodatkowym utrudnieniem był fakt iż, nie był to magazyn o charakterze scentralizowanym. Rozproszenie stref magazynowych w różnych miejscach hali wymagało skomplikowanej kodyfikacji i złożoności struktury magazynowej (wiele typów). Poza tym każdy z tych obszarów miał magazynować (w stałych lokalizacjach) części wspólne dla pozostałych stref, więc strategia uzupełniania wymagała starannego zaplanowania. W każdej strefie magazynowane były również produkty o zupełnie innych cechach, i dla każdej z nich zastosowano inną strategię umieszczania, która w późniejszym etapie miała również skrócić ścieżki kompletacji. Kolejną trudnością było przyjęcie wariantów materiałowych z produkcji oraz ich magazynowanie z uwzględnieniem rodzajów rynków, a w niektórych przypadkach wysyłka do klienta bezpośrednio z linii pakującej. Te wymogi i wiele innych, znacznie komplikowały wdrożenie. Serializacja wyrobów gotowych wymagała zastosowania z-transakcji, ponieważ w standardzie obsługa numerów seryjnych w procesie pakowania jest mało intuicyjna i podatna na błędy. Wszystkie te punkty spowodowały rozrost siwizny wśród członków projektu 🙂

Etapy projektu odbywały się zgodnie ze standardowym planem wdrożenia produktu SAP, jak widać na poniższym obrazku:

Etap przygotowania był wspólny dla obydwu wdrożeń, ponieważ jeszcze na tym etapie nie planowano rozbicia projektu. Dopiero w fazie business blueprint zdecydowano się na dwa oddzielne terminy wdrożeń. Oznacza to, że po zakończeniu pierwszego wdrożenia ponownie wrócono do fazy realizacji w celu implementacji systemu w drugim zakładzie.

Faza przygotowania


A więc do rzeczy: jak to bywa w tego typu projektach rozpoczęto od fazy przygotowania. Zakład, będący oddziałem potężnej firmy, posiadającej swoje filie na wszystkich kontynentach i w kilkudziesięciu krajach, podjął decyzję o wdrożeniu SAP EWM. Zarząd firmy-matki przychylnie zareagował na ten fakt z podejściem “jak pójdzie dobrze to wdrożymy to cacko w innych oddziałach“. Naturalnym więc jest fakt, iż byliśmy obserwowani przez “cały świat” czyli wszystkie zakłady korporacji. Przypomnę jeszcze raz, że firma ta nie prowadziła działalności związanej z logistyką czy magazynowaniem, lecz typowo produkcyjną w sektorze przemysłowym (w SAP: inżynieria/konstrukcje). Już przy tym etapie, rozmawiając z ekspertem z zewnątrz usłyszałem opinię, że EWM dla takiej firmy jest niczym “armata skierowana na muchę“. Mało tego, wszystkie wymagania biznesowe, którym chcielibyśmy sprostać byłyby do spełnienia w posiadanym już komponencie WM systemu SAP ERP. Ale do rzeczy: przygotowano plan projektu, ustalono budżet oraz skład zespołu wdrożeniowego. Zespół IT pochodził wyłącznie z siedziby głównej, ponieważ firma, w której odbywało się wdrożenie nie posiadała własnej komórki IT – SAP. Oczywiście zaproszono kilka firm wdrożeniowych na prezentację i z niedowierzaniem słuchaliśmy o korzyściach jakie są w stanie nam zaoferować. Jak nie trudno się domyślić wybrano firmę niemiecką (budziła największe zaufanie wśród niemieckojęzycznego zespołu IT) i zdecydowano aby wdrożenie przebiegało właśnie w tym języku.

Pierwsza przestroga – Bariera językowa

I tutaj pojawia się pierwsza przestroga! 80% problemów w trakcie wdrożenia wynikało z naturalnej bariery językowej między polskim oddziałem firmy a niemieckimi konsultantami. Dlaczego? Informacje otrzymane od firmy wdrożeniowej były filtrowane przez SAPowców wewnętrznych, tzn. mówili tylko o tym co ich zdaniem mogłoby być dla nas zrozumiałe, pomijając szczegóły techniczne. Nawet jeśli chcieliby nas w nie zagłębić – zapewne nikt by tego nie zrozumiał. Pamiętaj. Choćby pracownicy polskiej firmy znali język obcy na bardzo zaawansowanym poziomie to nie jest to język SAP-owy. Bariera językowa powodowała również wiele problemów z czytaniem map nowych procesów w języku niemieckim. Chcieliśmy je przedstawiać pracownikom w celu zebrania uwag. W związku z tym dokumenty te były czasami przekazywane do tłumaczenia firmie zewnętrznej, ale ich struktura zmieniała się tak często, że dalsze tłumaczenia mijały się z celem. Poza tym, proszę mi wierzyć tłumaczenia eksperta od języka niemieckiego, naprawdę czasami bywały po prostu śmieszne, z powodu braku znajomości pojęć SAP-owych. Mimo, że oryginalne dokumenty znajdowały się w folderze wewnętrznego firmowego intranetu to tworzyliśmy swoje własne. W pewnym momencie gubiliśmy się w tym, które wersje były aktualne bo było ich zbyt wiele. Dobrym rozwiązaniem byłoby wynajęcie konsultanta SAP (być może z innej firmy) z kraju w którym odbywa się wdrożenie. Ów konsultant może być łącznikiem pomiędzy polskimi użytkownikami a obcojęzycznym teamem wdrożeniowym. Trudno jest rozmawiać w obcym języku technicznym o produkcie, którego w ogóle nie znasz. Przykładem może być sytuacja w której konsultant proponuje rozwiązanie: “po wdrożeniu pracownicy magazynu będą musieli tylko zameldować do stacji dekonsolidacji i utworzą się zadania na umieszczanie produktów w magazynie”. Brzmi fajnie więc się zgadzamy, nie rozumiejąc szczegółów technicznych (jedyna osoba w polskiej części zespołu, która w miarę rozumiała SAP, nie znała języka niemieckiego). Ale jak się później okazuje trzeba oprócz terminala RF skorzystać również ze standardowego SAP GUI. Później w odpowiedniej transakcji ręcznie tworzyć HU, przepakowywać (paletyzować) materiały w zależności od ilości. Przecież w “starym SAP” mieliśmy dane paletyzacji i system sam decydował na ile miejsc składowania czy kwantów przyjmowany materiał będzie rozbity. Tutaj trzeba decydować o tym samemu, ponieważ implementacja programu do czytania takich danych (specyfikacji pakowania) wymagałaby dodatkowych nakładów pieniężnych. W fazie testów nagle okazuje się, ze to nie robi się automatycznie. I co teraz? Chcieliśmy mieć automat, a wiele czynności trzeba wykonywać ręcznie stojąc przed komputerem. Na tym etapie zmiana czegokolwiek jest prawie niemożliwa lub wymagała by ogromnych dodatkowych kosztów. Nie trudno jest się domyślić, że w takim przypadku już nie wraca się do zmiany procesów drugi raz. Przecież ostatecznie na to się zgodziliśmy (nie wiedząc nawet kiedy). Teraz trzeba iść do przodu z nastawieniem “jakoś to będzie”.

Druga przestroga – odpowiedzialność za wdrożenie IT vs. właściciele procesów

I tutaj pojawia się kolejna przestroga. Jeśli w trakcie wdrożenia firma, pełna ufności, z nadzieją oddaje swoje procesy pod opiekę IT – to również dobrze nie wróży. Myślenie typu: “przecież nikt z IT nie pozwoli na to, aby zakład miał zostać zamknięty czy miało dojść do zatrzymania produkcji. Przecież cały zarząd na nich patrzy” – jest tylko złudną nadzieją. Prawda jest taka, że tylko i wyłącznie pracownicy czy przedstawiciele działów firmy, w której odbywa się wdrożenie będą w stanie wpłynąć na idealną implementację systemu. Ostatecznie to pracownicy pracują na hali produkcyjnej i wiedzą (choć nie zawsze mówią na głos) jak przebiega obecny proces i co można w nim zmienić. To prawda, że team wdrożeniowy, będzie się starał by wdrożenie przebiegło jak najlepiej, ale w przypadku niepowodzeń zawsze mogą powiedzieć, że o czymś nie wiedzieli bo my jako użytkownicy czy właściciele procesów nie uwzględniliśmy jakiegoś scenariusza w katalogu testów. Jednym słowem, o czymś im nie powiedzieliśmy bo myśleliśmy, że oni o tym wiedzą i na pewno mają to na uwadze. Niestety, choć posiadają ogromną wiedzę jakiej im zazdroszczę, to jednak jeszcze nie potrafią wróżyć z fusów 🙂 Dlatego kolejna przestroga!

Trzecia przestroga – skład zespołu projektowego

Zadbaj o to, aby w projekcie uczestniczył co najmniej jeden ekspert (najbardziej doświadczony pracownik) z każdego działu, a nawet nie tylko działu, ale ekspert od każdego procesu. Ważnym jest też, aby był on uczestnikiem projektu od samego początku, wtedy kiedy planuje się skład teamu wdrożeniowego. Dlaczego? Po pierwsze każdy człowiek, jeśli czuje że ma wpływ na projekt zaczyna się angażować i wkładać w niego swoją energię a później dąży do tego aby założenia projektu były realizowane nawet po go-live. W przeciwnym przypadku, zawsze odczuwa przymus pracowania z nowym systemem, na którego wdrożenie nie miał wpływu. Choćby nie wiem jak było dobrze to ostatecznie i tak powie, że on zrobiłby to inaczej. Drugim powodem jest fakt, że jeśli owi eksperci nie zostaną wdrożeni od początku to stracą bardzo dużo czasu na nadrobienie wiedzy o nowym systemie. W pierwszej fazie wdrożenia odbyłem 5-dniowe szkolenie SAP EWM100 zorganizowane przez firmę wdrożeniową. Pomimo, że był to ogrom wiedzy, z której i tak nic nie zapamiętałem to otrzymałem dużo materiałów, do których w każdym momencie mogłem powrócić a ziarno wiedzy w głowie zostało zasiane. Początkowe odczucie straty czasu szybko zostało zastąpione olśnieniem, gdyż dopiero w fazie blueprint a później testów, wiedza ta przypominała się sama. Wtedy miałem przewagę nad tymi, którzy szkolenia nie odbyli. Efekt jest taki, że do dzisiejszego dnia nie korzystają oni z SAP świadomie, a na szkolenie pogłębiające zrozumienie nie ma już po prostu czasu. Praktyka, praktyką, ale nie ma się co oszukiwać – teoria również jest niezbędna. Nie daleko trzeba szukać potwierdzenia tej opinii. Czytając “Warehouse Management with SAP EWM” wydawnictwa SAP PRESS (Rozdział: ASAP 8 implementation Methodology and SAP EWM) , wielokrotnie można natrafić na zdanie typu:

W projekcie SAP EWM sprawą najwyższej wagi jest zapewnienie wyrównania między zespołami IT a użytkownikami końcowymi magazynu. Dlatego bardzo ważne jest posiadanie 

użytkownika końcowego w zespole projektowym SAP EWM .

Faza blueprint


Business Blueprint to faza, w której dokonuje się szczegółowego opis procesów biznesowych firmy i wymagań systemowych. Tworzy się kluczowy dokument wdrożeniowy. Jest on szkieletem całego projektu, ponieważ zawiera zapis niezbędnych ustawień konfiguracji w sposób ułatwiający fazę realizacji. Mówi się, że dobrze przygotowany Blueprint stanowi podstawę udanego wdrożenia systemu. Jak się okazało, jest to 100% prawda. Powodzenie projektu zależy od tego jak mocno będziemy trzymać się ustaleń zdefiniowanych w tej fazie, a także od tego czy o wszystkim pamiętaliśmy podczas mapowania procesów. 

Czwarta przestroga – odpowiednie nastawienie

Kolejną wskazówką istotną dla tej fazy jest zmiana nastawienia i porzucenie tego co było kiedyś. Podczas mapowania procesów bardzo częstym błędem było branie pod uwagę czegoś co wykonuje się obecnie. Jeśli w obecnym procesie wykonujemy jakieś kroki niepotrzebnie to teraz jest jedyna okazja by je wyeliminować lub usprawnić. Nie ważne jak robimy to teraz, trzeba myśleć o tym jak to będzie w przyszłości, nawet gdy początkowo wydaje się to dla nas niemożliwe. Trzeba pozbyć się granic i przysłowiowych “klapek na oczy”. Podczas analizy procesów zdasz sobie sprawę, że w starych procesach wiele kroków robionych było bez sensu i można było je skrócić ale nikt tego nie robił “bo tak było zawsze”. Po co to kontynuować? Użytkownicy końcowi powiedzieliby, że nie chcą nic zmieniać, tylko pracować jak dotychczas, bo trudno im się przestawić na przyszłościowe myślenie.

 

Faza realizacji


Jak nie trudno się domyślić celem tej fazy projektu jest konfiguracja systemu pod wymagania biznesowe ustalone w poprzedniej fazie. W fazie tej przygotowuje się dane podstawowe, integruje się obydwa systemy, pisze rozszerzenia i przede wszystkim testuje. Każda konfiguracja musi zostać porządnie przetestowana w czasie umożliwiającym jej poprawkę. Oczywiście konfiguracji dokonuje się w serwerze testowym, a po solidnym przetestowaniu wszystkie ustawienia eksportuje się do serwera produkcyjnego (w fazie go-live). Jak się zdążyliśmy przekonać jest to najdłuższa faza w projekcie. Konfiguracja odbywa się w dwóch pakietach: konfiguracja główna (baseline configuration) i końcowa konfiguracja (final configuration). W fazie tej również przygotowywana jest dokumentacja szkoleniowa dla key-userów i użytkowników końcowych (tworzenie instrukcji jest dobrą okazją do testowania systemu). Jednocześnie jest to faza, która najbardziej daje w kość 🙂 Na tym etapie również można popełnić wiele (jak nie najwięcej) błędów, w związku z tym pojawia się tutaj solidna porcja aspektów, na które należy zwrócić uwagę. Jednakże z powodu długiej treści niniejszego wpisu zdecydowałem się na podzielenie go na dwie części. Zatem dziękuje bardzo za uwagę i zapraszam do kolejnej części wpisu.

Zostaw komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.