6 miesięcy wcześniej
Sześć miesięcy wcześniej odebrałem telefon. Dzwonił znajomy, prosząc o przysługę. Dwa lata wcześniej stworzyliśmy modelowe wdrożenie WMS na podstawie wdrożenia pełnego procesu Quality Assurance i supportu.
Pojedziesz na miesiąc, góra dwa. Pomożesz uruchomić na magazynie WMS. Wyłączyliśmy go po nieudanym wdrożeniu.
Osiem tysięcy pracowników z trzech zmian pracowało aktualnie siedem dni w tygodniu przy użyciu papieru i excela.
Wylot za 7 dni. Zgadzasz się? To super!
Na lotnisku przesiedziałem siedemdziesiąt dwie godziny, przebookowując loty i czekając na wizę. W końcu wsiadam do samolotu. W powietrzu ratuje mnie satelitarne Wi-Fi. Dostaję maile z adresami i danymi kontaktowymi. Dociera do mnie, że lecę na drugi koniec świata, a nie znam żadnych szczegółów. Zdarza się.
Bagaż doleciał. Ja jestem w jednym kawałku. Taksówka. Hotel. Rezerwacja dalej na mnie czekała. Odbieram kartę do małego, serwisowanego mieszkania. Po 20 godzinach lotów i przesiadek padam ze zmęczenia. Następnego dnia łapię za telefon i próbuję zadzwonić na numer kontaktowy. Nikt nie odbiera. Jest niedziela. Może dostałem wolne. To nie jest oczywiste. Działamy w „hypercare”. W tej branży to słowo klucz. Znaczy – „Do oporu” i „kasa nie gra roli”. Spora gaża, pełne pokrycie kosztów pobytu, serwisowane mieszkanie w dobrej dzielnicy ale też praca 6 dni w tygodniu w nielimitowanych godzinach.
Pierwsza wizyta w magazynie
W poniedziałek docieram na magazyn. Przechodzę trzy kontrole bezpieczeństwa. Po drodze wyrabiają mi identyfikator, znakują moje urządzenia. Zalepiają plombami. Po godzinie trafiam do małego, biurowego openspace na końcu ogromnej hali magazynowej. Wchodzę. Pokój wypełniony po brzegi. Przedstawiam się. Pytam gdzie mogę usiąść. Jesteś z IT? Dla świata wszyscy jesteśmy z IT. Pokazują salę konferencyjną. Opuszczone żaluzje, na środku stół i pięciu ludzi stukających w klawiatury. Szklane ściany zapisane markerami. Siadam. Przyglądam się notatkom. Dopiero kiedy pytam, czy mają problemy z alokacją produktów ktoś potwierdza, że zauważył moją obecność. Mark mówi, że sprzątają po nieudanym go-live. Ludzie przenosili produkty bez użycia systemu. System kierował więc ludzi do lokacji, które okazywały się puste. Ktoś pobrał palety fizycznie, ale nie cyfrowo. System o tym nie wie. Ludzie też nie. W efekcie oznaczają „systemowe” palety jako zagubione i biorą te leżące najbliżej. W końcu potrzebują tej części do skompletowania zamówienia.
Tak powstaje chaos i 250 mln dolarów teoretycznie zagubionych palet… W końcu ktoś pyta, co ja tu robię. Zajmuję się Quality Assurance, mam duże doświadczenie we wspieraniu wdrożeń WMS. Znajomy prosił, żebym przyjechał. To w sumie nie jesteś potrzebny, bo system działa. Ludzie nie przestrzegają procedur. Czyli w tę grę gramy! Przekonać użytkowników do systemu jest ciężko. Rozmawialiście z nimi? Jakie są ich odczucia? Nikt nie rozmawiał. Notuję, analizuję. Chcę iść na magazyn.
Problem pierwszy: lokacja
Oprowadza mnie Gary z OPSów. Według IT wystarczy tylko przestrzegać procedur i byłoby wszystko dobrze. Gary uważa inaczej – system nie działa. Próbuję rozmawiać z ludźmi. W większości nie mówią po angielsku. Czasem jakieś hello. Moją uwagę zwracają filary między regałami. Wracam do komputera. Przeczucie nie zawodzi. W systemie filary widnieją jako lokacje. To znaczy, że system może tam „składować” palety. Wołam Marka. Pokazuję, co znalazłem. Wkrótce wszyscy wychodzimy z pokoju. Laptop. Kamizelka. Wymarsz. Sprawdzamy wszystkie lokalizacje „filarowe”. Poprawiamy konfigurację systemu. Usuwamy nieistniejące lokalizacje. Ktoś może by powiedział – jestem z QA, konfiguracja to nie moja rola. Ale jeśli trzeba, to robisz. Znam systemy Blue Yonder (kiedyś RedPrairie), więc to żaden problem. Na tym poziomie nie ma zakresu obowiązków. Zakres kompetencji ustala potrzeba. Jeśli czegoś nie umiesz – dowiadujesz się. Jeśl nie rozumiesz – siedzisz nad tym do skutku. Ważne, że naprawiliśmy problem lokacji. Rozbieżność zmalała.
Problem drugi: system nie odzwierciedla rzeczywistości
Druga rzecz za którą się biorę, to palety porozstawiane na podłodze. Nie potrafię znaleźć wirtualnych lokalizacji, które by im odpowiadały. Rozmawiamy z ludźmi, tworzymy dodatkowe lokalizacje, bo fizycznie i tak ich używają. To system ma przystawać do rzeczywistości, a nie inaczej. Kolejny mały sukces.
Drugi go-live i kolejne problemy
W połowie sierpnia przeżywamy drugi go-live. OPSi nie mają wiary w system. Ludzie nie pamiętają szkoleń. IT nie rozmawia z pracownikami. Jest wiele niebezpiecznych zmiennych, a wszystko dąży do nowej tragedii. Niestety deadline to deadline. Na razie nikt mnie nie słucha. Przynajmniej udało nam się wyrównać stock w systemie. Palety są na miejscach. System odzwierciedla rzeczywistość. Odpalamy. Start. Zanim się zorientowałem siedzę na magazynie, obsługując system.
Zamówienia się nie drukują! System nie działa!
Co z tego, że nauczyliśmy ludzi obsługi skanerów, skoro mistrzowie zmian nie znają systemu. Ktoś zapomniał usunąć zamówień sprzed pierwszego go-live. Teraz ktoś je wszystkie zaalokował. System rzęzi, wypluwa najstarsze zamówienia, które są niepotrzebne. Fabryka otrzymuje wózki nieprzydatnych komponentów. Zanim ktoś nas o tym zdążył poinformować, na hali rządzi już panika. Biznes kazał ludziom po prostu zbierać zamówienia. Zaczynają krążyć kartki. Część ludzi pracuje z systemem, część bez. Nie ma planu.
Kolejne dwa miesiące: sprzątanie
Zostaję jeszcze na dwa miesiące. Sprzątam bałagan. W końcu ktoś słucha i ściągamy tłumacza. Ludzie zaczynają mi ufać. Piszemy nowe podręczniki użytkownika. Plany szkoleń. Rozrysowujemy procesy w oparciu o wiedzę pracowników i klienta. Identyfikujemy wiele luk w procesie i w konfiguracji systemu. Dłubię przy analizie ryzyka. Robi się nerwowo. Przecież zbliżają się święta. Elektronika i święta to pieniądze.
Końcem października angażujemy maksymalnie lokalny zespół IT. Włączamy ich do teamu wdrożeniowego. Zostają testerami i supportem. Wdrażamy proces QA. Pokazuję, co mogę. Najczęstsze błędy i jak je naprawić. Jak testować. Co to jest przypadek testowy. To nienajlepszy pomysł, żeby Amerykanin, który dostaje dwa i pół tysiąca dolarów za dzień pracy zajmował się wyciąganiem raportów do excela i przestawianiem palet w systemie. Potrzebowaliśmy kogoś od brudnej roboty. My zaczynamy uzupełniać konfigurację. Tym razem nalegam na odpowiedni proces. Wszystko jest testowane w oparciu o formalne wymagania. Dostosowujemy system i procedury do faktycznego życia magazynu.
Grudzień: szkolenia i wdrożenie
Siedzimy po 14 godzin. Jemy na zmianę pizzę i ryż. Zostaję do grudnia. Organizuję UATy z biznesem, z klientem, z operatorami. Na żywo, na magazynie. Właściwie jest to pilotaż. Odbudowanie zaufania poprzez prowadzenie za rękę, pokazywanie, tłumaczenie. Wkrótce zaczynamy terminową wysyłkę. Jest lepiej. Trapią nas błędy użytkownika, nierówne stany magazynowe i kłopoty z nowymi procedurami. Opisuję jasno procedurę wdrażania zmian. Zostawiam procesy i instrukcje. Jest końcówka grudnia. Z duszą na ramieniu lecę do domu. Potrzebuję długich wakacji. W samolocie dużo myślę o implementacji. Bez wątpienia, to było intrygujące doświadczenie. Kiedy je wspominam, wiem, że zawsze może pójść łatwiej. Dlatego postanowiłem przekazać Wam kilka myśli, które pomogą uniknąć tylu problemów podczas wdrożenia.
Jak uniknąć takiego chaosu?
- Wymagania i dokumentacja – są potrzebne. Ale mają odzwierciedlać rzeczywistą sytuację. Muszą być stworzone na podstawie użytkowników końcowych, schematów procesów, rozmów.
- Zarządzanie zasobami – zdefiniuj, kogo potrzebujesz i kto będzie tymi osobami zarządzać. Przez opisywane wdrożenie przeszło osiemdziesięciu różnych specjalistów z całego świata. Tak dużo, że zaczęto odmawiać wydawania wiz. Każdy przylatywał na miesiąc z super pomysłami, ale ostatecznie nic się nie działo. Jeśli jest jedna osoba, której na pewno potrzebujesz, to dobry QA. Kropka.
- Uczestniczysz we wdrożeniu IT – trzeba sobie powiedzieć wprost. W obecnych czasach uruchomienie magazynu to wdrożenie systemu. Uruchomienie szpitala to wdrożenie systemu. Otwarcie osiedlowego sklepu to też wdrożenie systemu. Wszystko opiera się na systemach informatycznych i choćbyśmy mieli najlepszych specjalistów, jeśli nie potrafią korzystać z systemu albo system jest źle skonfigurowany, to nic nie wskórają.
- Analiza ryzyka i plany awaryjne – z perspektywy QA. Zobacz, co może pójść nie tak w systemie, żeby wiedzieć, jak temu zaradzić na przykład na magazynie i działać bez szkody nawet z niedziałającym modułem lub systemem
- Odpowiedni proces wdrożenia – tutaj mógłbym napisać książkę. Pamiętajcie o dwóch zasadach. Testy zaczynamy na jak najwcześniejszym etapie – testować można nawet sam koncept. Testy muszą być udokumentowane i przeprowadzane przy użyciu rzeczywistych danych. Bez nich nie można niczego wdrożyć.
- Komunikacja – problemem wdrożeń jest to, że IT nie rozumie OPSów, a OPSI nie rozumieją IT. Być może jestem monotematyczny, ale rozwiązanie to dobry QA. Zrozumie system i potrzeby użytkowników, a na koniec wszystkim wytłumaczy, że każdy się myli i nawet pokaże dlaczego.
- Szkolenia – nie ma nic gorszego niż szkolenie użytkowników prowadzone przez developera. Szkolenie musi się odbyć z rzeczywistymi scenariuszami i musi być powtórzone kilkukrotnie
- Support – kiedy coś się psuje tu i teraz, nikt nie chce wdzwaniać się na infolinię i czekać. Jeśli nie ma prostego rozwiązania i jasnych procedur, można być pewnym, że użytkownik spróbuje, w jak najłatwiejszy sposób pozbyć się problemu. To znaczy, że gdyby mu pomóc tu i teraz, byłoby dziesięć razy mniej problemów.
Autorem artykułu jest Habib Moskin CEO Testspring