W ramach krótkiego przypomnienia, streśćmy na wstępie poprzednią część wpisu. Wiemy już z jakich etapów składa się proces implementacji SAP EWM, a także na jakie rzeczy trzeba zwrócić uwagę, aby nie popełnić błędów przy wdrożeniu. Wiemy już, że odpowiedzialność za projekt leży nie tylko po stronie firmy wdrożeniowej ale wiele zależy od nas jako właścicieli procesów biznesowych. Okazało się również, że niezbędna jest obecność użytkowników końcowych w całym projekcie, ponieważ to oni posiadają największą wiedzę na temat wykonywanych procesów. Wiedza ta przyda się zwłaszcza w fazie blueprint, w której to definiujemy nowe procesy przy uwzględnieniu aktualnych jak i przyszłych wymagań biznesowych. Od tego właśnie etapu zależeć będzie powodzenie fazy realizacji a także go-live.
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ść 🙂
Piąta przestroga – zadbaj o dane podstawowe w starym systemie
Tu nie ma co owijać w bawełnę, po prostu zrób porządek w danych podstawowych starego systemu – nie pchaj śmieci do nowego. Największym możliwym błędem jest myślenie, że jest to idealny moment na “posprzątanie” w danych podstawowych, bez ingerencji w dane posiadane już w dotychczasowym systemie. Jednym słowem, startujemy z czystą kartą więc przygotujmy elegancko dane podstawowe w EWM a o ERP zapomnijmy. Tak się nie da. Szkoda, że nie dbaliśmy o dane podstawowe wcześniej. Podczas migracji zapasów pojawiały się pytania: “co mamy zrobić z zapasami, które pozostały w starym magazynie, ale nie mają żadnego miejsca w nowym”. Okazało się, że w SAP ERP było mnóstwo miejsc składowania o których nie mieliśmy pojęcia. Przyczyną było, że Pan Kowalski utworzył sobie miejsce składowania o nazwie “korki”, które całkowicie odbiegało od kodyfikacji stosowanej w firmie. Teraz pytanie: gdzie to miejsce jest? 🙂 Pan Kowalski już tu nie pracuje, ale miejsce składowania pozostało, a nawet jest na nim zapas! Jak się okazało, ów użytkownik umieszczał w tym miejscu (w procesie przyjęcia towarów) zatyczki do uszu używane przez pracowników 🙂 Pytając innych użytkowników o lokalizację tajemniczego miejsca, otrzymaliśmy odpowiedź, że tak naprawdę nie ma go nigdzie, ale podobno “korki” trzymane są przez kogoś w szufladzie biurka. Przypuśćmy, że jednak zgodzilibyśmy się na utworzenie takiego miejsca. Nie wyobrażam sobie wtedy, że pracownik przyjmujący transport (na zmianie nocnej) stoi z robotą bo musiałby włamać się do biura, żeby zeskanować czyjąś szufladę, a już nie wspomnę o problemach przy definiowaniu dla niej maksymalnej wagi i pojemności. Jedynym plusem tego zamieszania była porządna nauka, dotycząca tego, żeby dbać o dane podstawowe i wyznaczyć osoby odpowiedzialne za ich tworzenie. Jednym słowem “koniec samowolki”. Sytuacja fizyczna musi (i to koniecznie) odzwierciedlać sytuację systemową!! Poza tym bardzo krytycznym momentem (po Go-Live) były lekkie opóźnienia w wysyłce z powodu niepoprawnie zdefiniowanego profilu numeru seryjnego w danych podstawowych materiałów. Dostawy wychodzące w EWM uniemożliwiały wydanie towarów dla dokumentów dostaw wychodzących w SAP ERP. Były to tylko chwilowe problemy, ale przysporzyły troszkę stresu i można by ich uniknąć gdyby dane podstawowe były prawidłowe. Kolejnym przykładem mogą być cykle sterowania, które również przysporzyły nam wiele problemów. Rekordy te nie były prawie nigdy aktualizowane, ani usuwane tylko po prostu tworzone nowe. Cykle sterujące ERP miały posłużyć jako szkielet do zdefiniowania w EWM stałych miejsc składowania przy stanowiskach produkcyjnych. Definiowano nowe, oddzielne obszary zaopatrzenia produkcji, (OZP) dla każdego stanowiska roboczego w ERP. Tworzono nowe typy magazynów w EWM, które były przypisane do wspomnianych OZP. Miały one służyć do uzupełnienia materiałów kanban dla przynależnych stanowisk roboczych. Wszystkie produkty, które w procesie uzupełnienia (replenisment) zostaną dostarczone do tych typów magazynu miały być automatycznie zużywane w miejsca powstawania kosztów (MPK). Mówiąc prościej: dla każdego stanowiska roboczego w ERP, zdefiniowany został nowy typ magazynu EWM, dla którego z kolei opracowano stałe miejsca składowania z przypisanymi materiałami. To było tysiące miejsc, więc jako wzór posłużyły cykle sterujące z SAP ERP. Gdy zostały skopiowane okazało się, że sporo materiałów nie było już od lat używanych, lub miały zdefiniowane złe wartości uzupełnień. Aby sytuacja wyglądała identycznie jak w rzeczywistości trzeba było spisać wszystkie kontenery kanban na każdym stanowisku produkcyjnym a niekiedy na nowo definiować wartości uzupełnień – to jest kilka tysięcy indeksów. Wbrew pozorom nie było to wcale takie proste a tym bardziej bez zatrzymania produkcji, ponieważ kontenery były cały czas w obiegu. Jest jeden duży plus! Dopiero w takich momentach wielu użytkowników końcowych przekonało się jak ważne jest dbanie o dane podstawowe SAP ERP. Praktycznie zaczęliśmy uczyć się SAP od nowa! W miarę nauki i pogłębiania wiedzy o ERP powoli dochodziło się do wniosku, że jednak może nie jest on taki zły. Może zamiast myśleć o nowym systemie, wystarczyłoby zrobić porządek w danych podstawowych ERP?
Szósta przestroga – odłóż inne projekty na bok
A teraz przyjrzyjmy się wspomnianym cyklom sterującym ale pod kątem znakowania (etykietowania). Biorąc pod uwagę, że dla każdego cyklu sterującego kanban zdefiniowano po dwa kontenery to podczas etykietowania, trzeba ich liczbę przemnożyć przez 2. Daje nam to około 8000 etykiet tylko na same pojemniki. Nie wspomnę jeszcze o znakowaniu miejsc, na którym te pojemniki się znajdują. Wszystkie te etykiety muszą zostać wymienione w jak najkrótszym czasie, aby zachować ciągłość produkcji. Żeby to zapewnić najlepsza byłaby możliwość używania etykiet starych, przy jednoczesnym znakowaniu nowych. Powstał plan wykonania tego w miarę szybkim czasie, ale podczas etykietowania okazało się, że fizyczna sytuacja jest totalnie inna niż w systemie (mimo, że zaktualizowaliśmy już dane opisane w punkcie poprzednim). Dlaczego? Dlatego, że w trakcie przygotowywania plików do importu do nowego systemu, były prowadzone różne projekty przebudowy stanowisk roboczych, o których team wdrożeniowy nie wiedział. Wszystkie pliki nadawały się do usunięcia a czas gonił, praca oddelegowanych osób również poszła na marne. Okazało się również, że 30% cykli sterujących w SAP ERP ponownie kwalifikuje się do usunięcia (znowu!!!!) i nie powinny być uwzględniane podczas migracji przypisań produktów do stałych miejsc składowania w SAP EWM. Dane te były poprawiane chyba z cztery razy! Jestem pełen szacunku dla Pana od migracji – najbardziej cierpliwy człowiek na świecie. Kilkakrotnie po prostu kopiował dane ze starego systemu, jednak gdy wreszcie pojął, że dane w systemie mijają się z rzeczywistością, coś w nim pękło i zrzucił przygotowanie plików do migracji na nas. To była słuszna kara – tym razem zadbaliśmy o to by wszystko było dobrze. Tutaj pojawia się kolejna przestroga! Odłóż wszystkie projekty optymalizacyjne na bok. Uświadom cały zakład, że implementacja nowego systemu to bardzo ważny projekt – wszyscy pracownicy firmy muszą być na bieżąco informowani o jego statusie i wszelkie zmiany w starym systemie muszą być zgłaszane (oczywiście przed ich wprowadzeniem a nie po fakcie), a najlepiej jakby były wstrzymane aż do go-live.
Siódma przestroga – etykietowanie i dobór terminu
Po oznakowaniu regałów nadszedł czas na kolejną niespodziankę jaką tym razem przygotował nam MS-excel. Jako, że kompletacja zleceń miała odbywać się na urządzeniach typu “pick-by-voice” każde miejsce posiadało tak zwaną cyfrę weryfikacyjną. Jest to losowo wybrana cyfra weryfikacyjna przypisana na stałe do miejsca składowania. Jej celem jest uniknięcie sytuacji, w której pracownik potwierdza iż pobrał produkt z miejsca A ale fizycznie pobiera z miejsca B. Musi podać prawidłową cyfrę weryfikacyjną. Cyfry weryfikacyjne mogą być masowo importowane do EWM przy użyciu odpowiedniej transakcji oraz uprzednio przygotowanego pliku csv. Każda aktualizacja, nawet pojedynczego miejsca wymagała otwarcia pliku excela, naniesienia zmian i importu do SAP. Problem w tym, że nikt nie zauważył, że w kolumnie odpowiedzialnej za cyfrę weryfikacyjną zastosowano funkcję, która powoduje automatyczne wygenerowanie losowych liczb i przy każdym otwarciu pliku – Excel te liczby zmieniał :). Teraz proszę sobie wyobrazić, że chcemy dodać jeszcze kilka miejsc składowania. Otwieramy stary plik w celu naniesienia zmian i po nadpisaniu importujemy go w SAP EWM. Przekonani, że dodajemy kilka miejsc składowania w rzeczywistości zmieniamy wszystkie cyfry weryfikacyjne w typie magazynu, dla którego okleiliśmy już regały 🙂 W związku z tym po oznakowaniu kilku-tysięcy miejsc składowania, w wyniku takiego importu plików do SAP, większość etykiet kwalifikowała się do wymiany. Ale spokojnie! Udało się! Oczywiście stare dane pozostały jeszcze na serwerze testowym, więc po prostu je skopiowano, ale było naprawdę stresująco. To było kolejną lekcją na temat doboru terminu etykietowania – nie można robić tego zbyt wcześnie, a nawet jeśli to nie nanosić później żadnych zmian.
Ósma przestroga – import danych podstawowych z pliku CSV
Proszę sobie teraz wyobrazić podobną sytuację w której stwierdzamy, że nie możemy w magazynie umieścić produktu czy HU na żadnym miejscu składowania ponieważ system zgłasza błąd “maksymalna waga przekroczona”. Przyczyną okazał się banalny błąd Excela (tak, tak to już drugi raz!), który SAP-ową kropkę zamienił na przecinek i w danych podstawowych miejsc składowania maksymalna waga została zdefiniowana jako 2,5 kg zamiast 2500 kg. Wszystkie zmiany danych podstawowych i kilkukrotne przerabianie plików były spowodowane realizacją innych projektów. Czas gonił a dane trzeba było zmienić na szybkiego.
Dziewiąta przestroga – zmiana koncepcji
Na uwagę również zasługuje fakt, że zwlekanie z czymkolwiek powoduje tylko nadmierne piętrzenie się problemów w końcowym etapie wdrożenia. Dlaczego? Otóż wystosowaliśmy prośbę do osób odpowiedzialnych za migrację aby wstrzymali się na jakiś czas z masowym importem danych, ponieważ chcielibyśmy wyjaśnić sprawę z aktualnym projektem przebudowy stanowisk roboczych i magazynu, a także rozplanować przypisanie materiałów do stałych miejsc nieco dokładniej. Pojawiały się myśli typu: “Jeśli po wdrożeniu mielibyśmy kontynuować projekty rozbudowy, to może spróbujmy zrobić to wcześniej a osoba od migracji danych przygotuje nam strukturę i później będziemy mieli mniej roboty”. Niestety to nie działa w tą stronę. Ot to jest właśnie natura Polaka! Zawsze wykombinuje by upiec dwie pieczenie na jednym ogniu, ale w końcu przyjdzie chwila, gdy czas zacieśni swoje kręgi i cały zarząd firmy oraz IT będzie czekać na Ciebie, a wtedy już nie jest przyjemnie bo to Ty jesteś przyczyną opóźnienia! Jednym słowem, nigdy nie wybiegaj poza plan tylko realizuj go na podstawie procesów i danych przygotowanych w fazie blueprint. Nic nie zmieniaj! Realizuj plan zgodnie z wytycznymi ustalonymi na początku projektu. Chcesz coś zmienić? Zrobisz to później!
Dziesiąta przestroga – zwlekanie i przesuwanie terminu
Wracając do zwlekania, im bliżej było do fazy wdrożenia tym wydawało się być więcej problemów. Do tego doszedł stres i brak czasu na przeszkolenie ludzi. W związku z tym zdecydowano nieco przesunąć termin wdrożenia. Problem w tym, iż to wcale nie spowodowało że w bonusowym czasie zrobiło się coś więcej a termin przesuwany był kilkakrotnie co ostatecznie wydłużyło projekt o 10 miesięcy. Człowiek troszkę odsapnął i poczuł chwilę spokoju a dodatkowy czas wykorzystał na wyjaśnianie problemów bieżących nie mających nic wspólnego z projektem implementacji. Z jednej strony chciało się to odwlec na jak najdłużej a z drugiej chciało się to już mieć za sobą, chociażby miałoby być wdrożone źle. Ale doszliśmy już do takiego momentu, w którym do głowy nasuwała się złotą myśl: “Nigdy nie będziesz w 100% gotów aby zacząć. Po prostu zrób to teraz” Dodam jeszcze, ze przesuwanie terminu było jedną z przyczyn przekroczenia budżetu projektu o 27%!
Faza Go-Live
Celem tej fazy jest zapewnienie wsparcia po uruchomieniu systemu na serwerze produkcyjnym. Wydawać by się mogło, że jest to faza najprzyjemniejsza, jednakże zapobieganie sytuacjom zagrażającym ciągłości produkcji pochłonęło całą energię wszystkich członków projektu. Również dzień przed go-live nie należał do przyjemnych. Największym wyzwaniem jest uruchomić system w sposób umożliwiający ciągłość, czyli w systemie nie mogą istnieć żadne otwarte zlecenia czy zadania, ponieważ trzeba wgrać wszystkie dane podstawowe i zaktualizować wszelkie zamówienia, rezerwacje, zlecenia itp. Z tego względu faza to rozpoczęła się w dzień wolny od pracy (w niedzielę).
Jedenasta przestroga – dobór odpowiedniego terminu
Okazuje się, że dobranie dobrego momentu jest bardzo ważne. Powinien to być termin nie zbyt długi ani nie za krótki. Większość firm ma specyficzny, krótki okres w roku, w którym poziom produkcji nieco spada i dobrze jest wpasować termin implementacji właśnie w te dni. Oczywiście należy pamiętać, że nie może to być również sezon urlopowy, wręcz przeciwnie, trzeba przygotować się na wzrost liczby nadgodzin. Ogólny czas całego projektu od fazy przygotowawczej do go-live (w obydwu zakładach) trwał nieco ponad 2 lata a projekt optymalizacji EWM wciąż trwa (na dzień dzisiejszy). Co do terminu implementacji to kolejna ważna wskazówka. Warto termin ten zaplanować na świeżo po wykonanej inwentaryzacji. Dlaczego? Ponieważ może się zdarzyć, iż do EWM zostaną zmigrowane nieistniejące zapasy. Oczywiście można wykonać inwentaryzację później, ale proszę mi wierzyć, że praca ze świeżo zmienionym systemem nie jest wcale łatwa, a utrudnia się ją jeszcze bardziej kiedy trzeba zastosować sytuacje wyjątkowe (niecodzienne). Dobrze jest zostawić troszkę czasu na “oswojenie się” ludzi z systemem, tak by poczuli się w nim pewniej, wtedy łatwiej będzie im radzić sobie z problemami. SAP EWM posiada funkcjonalność stosowania kodów wyjątku, podczas wykonywania zadań magazynowych na urządzeniach skanerowych czy pick-by-voice. Ma to na celu uniknięcie postojów i zachowanie płynności procesu, nawet w przypadku stwierdzenia jakiejś anomalii (np. braku części na magazynie). Lepiej jest ćwiczyć ich wykorzystanie w spokoju, jak opadnie wdrożeniowy pył i wszyscy otrząsną się z szoku, niż używać takich funkcjonalności w pierwszym dniu go-live.
Dwunasta przestroga – szkolenia na hali, nie w biurze
Kolejną wartą zapamiętania wskazówką jest to aby testować system na żywym organizmie, nie w biurze. Kilka urządzeń skanerowych czy pick-by-voice skonfigurowaliśmy tylko na serwer testowy. Struktura miejsc składowania w serwerze testowym powinna być identyczna jak w serwerze produkcyjnym. Jest taki krótki moment, w którym magazyn już jest odpowiednio zaetykietowany i przygotowany pod go-live i ten okres jest idealny do tego aby przeprowadzić testy i szkolenia użytkowników końcowych na “żywym organizmie”. Dobrze jest poświęcić np. jedną sobotę (nawet w ramach nadgodzin) na taki masowy test i uruchomić wirtualną produkcję w taki sposób, aby każdy wykonywał swoją codzienną pracę na serwerze testowym ale w prawdziwym magazynie. Taki test pozwolił wyłapać jeszcze kilka niezgodności typu brak uprawnień do tworzenia HU, czy braku zdefiniowanych parametrów użytkownika niezbędnych do prawidłowego uruchomienia jakiejś z-transakcji, czy chociażby jakiejś niezgodności na etykietach z barcodami. Przy takim teście dopiero okazuje się, że ludzie w ogóle nie pamiętają szkoleń przeprowadzonych na “sucho” w biurze. Później każde niepowodzenie tłumaczą tym, że zostali źle przeszkoleni lub w ogóle a listę potwierdzającą odbycie szkolenia podpisali bo ktoś im kazał.
Idealny przepis na wdrożenie
Pozwolę sobie jeszcze na krótką refleksję na koniec. Czy można było zrobić to lepiej? W fazie blueprint wzięliśmy udział w profesjonalnych warsztatach magazynowych organizowanych przez wydawnictwo Nowoczesny Magazyn oraz Volskwagen Group Polska, gdzie bardzo szczegółowo opowiadano o blaskach i cieniach EWMki. Prowadzący wyraźnie podkreślali na co zwracać uwagę i jakich błędów nie popełnić. Niestety muszę stwierdzić, iż mimo, że wyjechaliśmy stamtąd z notatnikiem pełnym zapisków to wiele błędów powieliliśmy. Dlaczego? Dlatego, że człowiek zawsze sobie myśli, że jego to nie dotyczy i zrobi to lepiej. Ale prawda jest taka, że nie ma złotego środka na idealne wdrożenie, zawsze pojawi się jakiś problem, którego nie jest się w stanie przewidzieć i zawsze reakcja pracowników będzie na “nie”. Jest to spowodowane strachem przed nowym, przed zmianą. Nawet ośmielę się na stwierdzenie, że pracownicy hali magazynowej (nie wszyscy ale część na pewno) będą cieszyć się każdym niepowodzeniem i tym, że mają powód do narzekań. Słuchając głosów pracowników, przed samym go-live stanęliśmy przed dylematem: “jak powiedzieć ludziom, że będzie jeszcze gorzej i trudniej niż wcześniej”. Była to naturalna obawa przed zmianą i przed reakcją innych współpracowników, ale czy była słuszna? Czy implementacja SAP EWM była strzałem w dziesiątkę, czy może jednak niepotrzebnym projektem? Teraz po kilkunastu miesiącach obsługi systemu można obiektywnie odpowiedzieć na to pytanie i to właśnie będzie tematem kolejnego artykułu.
Wow, jestem pod wrażeniem. Świetny artykuł. Czekam z niecierpliwością na 3 cześć. Brawo
Dziękuje pięknie za miły komentarz! Podsumowanie wdrożenia i recenzja opinii użytkowników już wkrótce!
Pozdrawiam