Zarządzanie zmianą w transformacji: system przeszedł test, a magazyn i tak nie ruszył

Niedziela, wieczór. Kierownik magazynu dostaje wiadomość od nocnej zmiany: podczas ostatniej próby część zleceń pojawiła się w WMS z błędnymi danymi, a procedura po przerwaniu połączenia nie zadziałała tak, jak pokazano na szkoleniu. Rano ma ruszyć nowy system. Dostawca potwierdził wykonanie swojego zakresu, kierownik projektu zamknął większość zadań, a termin uruchomienia zna już cała firma.

Rano na spotkaniu padają dwa zdania, które brzmią jak sprzeczność, a wcale nią nie są. Dostawca mówi, że system działa. Kierownik magazynu mówi, że magazyn nie może pracować. Obie odpowiedzi dotyczą tego samego uruchomienia. Różnica polega na tym, że pierwsza dotyczy konfiguracji, a druga człowieka, który po pierwszym wyjątku nie wie, co wolno mu zrobić.

Zarządzanie zmianą w projektach systemowych, organizacyjnych i automatyzacyjnych polega właśnie na pilnowaniu tej różnicy. Nie na wysyłaniu komunikatów o korzyściach. Nie na plakacie z hasłem o transformacji. Na sprawdzeniu, czy proces, dane, uprawnienia i decyzje trzymają się razem w momencie, w którym coś pójdzie nie tak. W tym artykule rozkładam to na części, korzystając z przebiegu jednego wdrożenia WMS połączonego z reorganizacją i automatyzacją.

Zarządzanie zmianą zaczyna się od punktu zero, nie od harmonogramu

Zarząd zatwierdził wdrożenie WMS, ponieważ magazyn coraz częściej poprawiał zlecenia ręcznie, a kierownicy nie mieli wspólnego obrazu pracy. W dokumentach zapisano usprawnienie magazynu. Bardzo ładne zdanie, kompletnie niemierzalne.

Punkt zero to nie slajd wprowadzający. To opis rzeczywistego przebiegu pracy, wykonany razem z ludźmi, którzy ten przebieg realizują. Ja proszę o opisanie procesu AS-IS w kilkunastu do dwudziestu kilku krokach, z podaniem, gdzie powstaje decyzja, kto ją podejmuje i skąd bierze dane. W tym projekcie takie ćwiczenie wywróciło założenia w kilkanaście minut. Kierownik projektu poprosił operatora nocnej zmiany o pokazanie prawdziwego przebiegu. Operator otworzył dodatkowy arkusz, w którym zapisywano informacje potrzebne do ustawienia kolejności zleceń. ERP ich nie udostępniał, a nowy WMS ich nie przejmował.

Ktoś od razu powiedział, że arkusz trzeba usunąć, skoro firma kupuje WMS właśnie po to, żeby skończyć z pracą poza systemem. Operator zapytał, skąd po uruchomieniu dostanie kolejność na rano. Nikt nie odpowiedział. I to jest moment, w którym rozstrzyga się los projektu, a nie na komitecie sterującym trzy miesiące później.

W praktyce oznacza to, że arkusz nie był bałaganem. Arkusz był procesem. Zapisaną poza systemem decyzją, której nikt nie opisał, nie zatwierdził i nie przypisał do właściciela. Bez tej decyzji operator może wykonać każde zlecenie poprawnie, tylko w złej kolejności. Rano transport czeka na wysyłki, które nadal stoją w magazynie, sprzedaż dzwoni z pytaniem o opóźnienia, a ludzie wracają do telefonów i ręcznego poprawiania planu. Czyli dokładnie do tego, co miało zniknąć.

Pytanie kontrolne dla każdej firmy, która startuje z transformacją: ile arkuszy, kartek przy stanowisku i wiadomości na komunikatorze zastępuje u was oficjalny proces? Jeżeli nie potraficie ich wymienić, nie macie punktu zero, tylko wyobrażenie o nim. Więcej o tym, jak rozpoznać rzeczywisty stan wyjściowy przed inwestycją, piszę przy okazji audytów logistycznych.

Jeden projekt, pięć definicji sukcesu

Na pierwszym spotkaniu wyszło, że usprawnienie magazynu oznacza dla każdego coś innego. Prezes oczekiwał niższego kosztu. Dyrektor logistyki chciał zwiększyć przepustowość. Sprzedaż liczyła na szybszą obsługę pilnych zamówień. Kierownik magazynu chciał ograniczyć poprawki wykonywane przez operatorów. Dostawca dostał jeden projekt i kilka różnych odpowiedzi na pytanie, po czym firma pozna, że wdrożenie się udało.

To nie jest problem komunikacji. To jest brak rozstrzygnięcia. Dopóki nikt nie ustali hierarchii celów, każda decyzja projektowa będzie negocjowana od nowa, przez te same osoby, z tymi samymi argumentami. Rozjazd ujawnił się przy rozmowie o kolejności pracy. Sprzedaż chciała zmieniać priorytet zamówienia niemal do chwili wysyłki. Magazyn potrzebował stabilnej kolejki. Transport chciał wcześniej wiedzieć, co ma odebrać. Finanse nie zgadzały się, żeby oznaczenie pilnego zlecenia omijało blokadę klienta.

Dostawca robił to, co robi każdy dostawca postawiony przed czterema sprzecznymi oczekiwaniami: próbował je wszystkie przełożyć na konfigurację. Po jednej stronie ekranu rosła liczba wyjątków, po drugiej nadal nie było odpowiedzi, co zrobić ze zleceniem przyspieszonym po rozpoczęciu kompletacji.

Przełom przyszedł wtedy, gdy właściciel procesu przerwał rozmowę o likwidacji arkusza i wyznaczył osobę, która miała opisać regułę kolejności razem z magazynem, sprzedażą i transportem. Sam zobowiązał się zatwierdzić wynik. Dopiero po tej decyzji IT mogło sprawdzić źródło danych, a dostawca przygotować konfigurację. Kolejność jest tu nieprzypadkowa: najpierw rozstrzygnięcie biznesowe, potem dane, potem system. Odwrotna kolejność kosztuje w tym projekcie tyle, ile poprawki konfiguracji i powtórzone testy.

Ostatecznie reguła brzmiała prosto. Magazyn i transport korzystają z jednej reguły. Sprzedaż może zgłosić pilne zamówienie, ale rozpoczęta praca nie zmienia się automatycznie. Potrzebna jest zgoda kierownika magazynu i potwierdzenie, że transport może jeszcze zmienić plan. Blokada finansowa obowiązuje zawsze. Źródłem informacji zostaje ERP, a nie osobne wyliczanie w WMS, żeby magazyn i transport nie pracowały znów na różnych podstawach. Arkusz zostaje wyłącznie na czas przejścia, z właścicielem i terminem wycofania.

Kto decyduje i kto płaci za zwłokę

Drugi spór dotyczył potwierdzania terminu klientowi. Sprzedaż chciała odpowiadać od razu po przyjęciu zgłoszenia. Kierownik operacji odpowiadał, że najpierw musi sprawdzić dostępność towaru i obciążenie. Dyrektor finansowy wymagał kontroli blokad. Dostawca czekał na jedną regułę, którą mógł zapisać w systemie.

Pierwsze spotkanie zakończyło się zdaniem, że temat wymaga dalszych uzgodnień. Drugie przyniosło te same stanowiska. Właściciel procesu obiecał odpowiedź po rozmowie z transportem i finansami. Termin minął, decyzji nie było.

I tutaj uwaga, praktyczna: brak decyzji nigdy nie oznacza, że nic się nie dzieje. Dostawca nie chciał trzymać zespołu bez pracy, więc skonfigurował wariant, który uznał za najbardziej prawdopodobny. Sprzedaż przygotowała komunikację, w której termin trafiał do klienta wcześniej. Operacja opisała własny przebieg, zakładający potwierdzenie dopiero po sprawdzeniu możliwości wykonania. Po kilku dniach istniały trzy wersje jednego procesu, każda pochodząca z rozmowy z innym działem.

Zwłoka decyzyjna ma cenę i tę cenę zawsze ktoś płaci. W tym przypadku: poprawa konfiguracji, powtórzenie części testów, przepisanie materiału szkoleniowego i korekta komunikatu do klienta, ponieważ sprzedaż potwierdzała termin według innej reguły niż ta, według której operacja planowała realizację.

Sponsor rozwiązał to jednym zdaniem, które warto zapamiętać: konsultacja nie oznacza prawa weta dla każdego działu. Właściciel procesu miał zebrać skutki wariantów, wskazać jeden i przyjąć odpowiedzialność za regułę. Jeżeli nie zrobi tego w ustalonym czasie, decyzja przechodzi do sponsora. To jest realne zarządzanie zmianą: nie zbieranie zgód, tylko wskazanie osoby, która rozstrzyga, i terminu, po którym sprawa idzie wyżej.

Rozwiązanie okazało się wykonalne dla wszystkich. Sprzedaż może przekazać klientowi informację wstępną. Potwierdzenie terminu następuje po sprawdzeniu towaru, zdolności operacji i blokady finansowej. System pokazuje, na jakim etapie jest zamówienie i kto wykonuje następny krok. Prawnik usunął z komunikatu zapis brzmiący jak bezwarunkowa obietnica. Osoba odpowiedzialna za bezpieczeństwo zauważyła, że ręczne zwolnienie zamówienia nie może wymagać korzystania z uprawnień innego pracownika, więc IT przygotowało osobną rolę.

Drobiazg, który pokazuje różnicę między procesem opisanym a procesem działającym: podczas próby użytkownik ze sprzedaży zobaczył status oczekiwania na finanse i utknął. Nie wiedział, czy ma ponowić zgłoszenie, zadzwonić do operacji, czy czekać. Reguła istniała, ale nie była widoczna w miejscu pracy. Dopiero powiadomienie z terminem dla finansów, wskazanie osoby prowadzącej sprawę i blokada rozpoczęcia pracy przed zwolnieniem zamówienia zamknęły temat. Dostawca poprawił ekran, ale nie tworzył nowej zasady. Pokazał decyzję, która już zapadła. Tak wygląda dobrze poprowadzone wdrożenie systemu WMS: konfiguracja odwzorowuje rozstrzygnięcia, a nie je zastępuje.

Opór, który jest racjonalny

Równolegle firma zmieniała podział odpowiedzialności między centralnym planowaniem a kierownikami operacyjnymi. Dotąd doświadczeni kierownicy sami układali pracę swoich zespołów. Po reorganizacji plan miał powstawać centralnie, a lokalni kierownicy odpowiadali za wykonanie i zgłaszanie odchyleń.

Podczas próby jeden zespół czekał na zgodę planisty, choć kierownik mógł rozwiązać sprawę na miejscu. Inny kierownik zmienił plan bez zgłoszenia, więc centrala pracowała na nieaktualnych danych. Oba zespoły uważały, że postępują prawidłowo. Sponsor zapytał, dlaczego reorganizacja nie działa. Pierwsza odpowiedź brzmiała: kierownicy nie akceptują zmiany.

Tę diagnozę słyszę w co drugim projekcie i prawie zawsze jest nieprawdziwa. Lider zmiany nie przyjął jej bez sprawdzenia. Usiadł z najbardziej doświadczonym kierownikiem i poprosił o pokazanie sytuacji, w których nowy podział odpowiedzialności zatrzymuje pracę. Kierownik wskazał dwie. Tracił prawo do samodzielnego ustawiania planu, ale nadal odpowiadał za wynik zespołu. Miał zgłaszać odchylenia do centrali, choć jego ocena była prowadzona według starego czasu realizacji. Jeżeli czekał na decyzję, wynik spadał. Jeżeli działał sam, łamał nową zasadę.

To nie jest opór wobec zmiany. To jest racjonalna reakcja na sprzeczne warunki pracy. Człowiek odpowiada za rezultat, na który wpływ ma ktoś inny, a system oceny nadal traktuje go jak jedynego właściciela wyniku. Dopóki firma nie poprawi tego układu, żaden komunikat o korzyściach niczego nie zmieni.

Naprawa wymagała trzech rzeczy naraz. Właściciel procesu opisał granicę decyzji lokalnej: kierownik może zmienić kolejność zadań w swoim zespole, jeżeli nie wpływa to na inne obszary, zmiana obciążenia między zespołami wymaga decyzji centralnego planisty, a przy zatrzymaniu pracy kierownik działa od razu i zapisuje przyczynę. HR poprawił zasady oceny na okres przejściowy, tak aby czas oczekiwania na decyzję centrali nie obciążał kierownika lokalnego. Planista dostał określony czas na odpowiedź, a po jego przekroczeniu sprawa trafiała do dyżurnego menedżera.

Doświadczony kierownik nadal nie był zachwycony. Stracił część wpływu. Dostał jednak odpowiedź, za co odpowiada, gdzie kończy się jego decyzja i jak będzie oceniany. Włączył się w kolejną próbę, ponieważ mógł sprawdzić konkretny podział odpowiedzialności zamiast ogólnej zapowiedzi centralizacji. Jeżeli zmieniacie strukturę i jednocześnie zostawiacie stare wskaźniki oceny, warto najpierw uporządkować wskaźniki logistyczne i system premiowania, bo to one w praktyce mówią ludziom, co naprawdę mają robić.

Czas ekspertów jest zasobem projektu, nie dobrą wolą

Na papierze role wyglądały jasno. W praktyce te same osoby miały prowadzić normalną zmianę, uczestniczyć w warsztatach, opisywać wyjątki, sprawdzać nowy podział zadań i tłumaczyć go pracownikom.

Pierwszy warsztat odwołano, bo kierownik operacyjny musiał zastąpić nieobecnego pracownika. Z drugiego wyszedł przed końcem, gdy zatrzymała się bieżąca praca. Na trzecim pojawił się bez danych, ponieważ dzień wcześniej przygotowywał plan dla zespołu. Spotkania się odbywały, ustalenia trafiały do notatek, a pytania o wyjątki zostawały otwarte. Zespół centralny wypełnił tę lukę własnymi założeniami i tak powstał rozjazd, który wyszedł dopiero podczas próby.

Rozwiązanie nie jest efektowne, za to działa. Sponsor uznał udział kierowników w projekcie za część ich pracy, a nie dodatek po godzinach. Kierownik operacji wyznaczył zastępstwa na czas prób. Kierownik projektu przestał planować warsztaty w godzinach największego obciążenia tych samych osób. Ze spotkań zniknęli ludzie zaproszeni na wszelki wypadek. Ekspert dołączał wtedy, gdy zespół potrzebował jego danych albo decyzji, materiały szły wcześniej, a warsztat kończył się zatwierdzonym wynikiem albo jasno opisanym brakiem.

Pytanie kontrolne: ile godzin miesięcznie waszych kluczowych kierowników jest formalnie zarezerwowane na projekt i kto przejmuje w tym czasie ich obowiązki? Jeżeli odpowiedź brzmi "jakoś się dogadają", harmonogram projektu jest fikcją od pierwszego tygodnia.

Budżet przejścia przez zmianę, czyli pozycja, której nikt nie planuje

Budżet automatyzacji powstał na podstawie sprzętu, konfiguracji i integracji. Gdy kierownik operacji poprosił o zastępstwo dla pracowników uczestniczących w próbach, dyrektor finansowy odpowiedział, że projekt nie ma takiej pozycji. Klasyka.

Na nocny test miał zejść z hali doświadczony operator. Znał momenty, w których urządzenie dostaje poprawne polecenie, a mimo to zatrzymuje przepływ. Bez zastępstwa kierownik zmiany musiał wybierać między obsadą produkcji a udziałem eksperta w próbie. Wybrano wariant tańszy: dostawca przeprowadza podstawowy przebieg, operator pojawia się na końcu i potwierdza wynik.

Z planu próby wypadł wtedy przypadek, w którym materiał zatrzymuje się między dwoma etapami, a pracownik musi zdecydować, czy wznowić pracę, wycofać zadanie, czy wezwać wsparcie. Test zakończył się zgodnie z planem, bo sprawdzono prawidłowy przepływ. Po uruchomieniu to samo zatrzymanie wydarzyło się przy pełnym obciążeniu. Jeden pracownik ponowił zadanie, drugi czekał na kierownika, a system pokazywał operację jako rozpoczętą. Zespół zatrzymał fragment pracy i ręcznie sprawdzał stan materiału.

Oszczędność na zastępstwie wróciła jako przestój w normalnej pracy. Za drugim razem finanse dostały wyliczenie kosztu obsady zastępczej oraz opis skutku rezygnacji: kolejna próba nie obejmie zatrzymania przepływu. Przy takim postawieniu sprawy decyzja zapadła w pięć minut. Test odbył się w warunkach zbliżonych do normalnej pracy, operator zatrzymał proces, rozpoznał stan zadania i wskazał brak informacji potrzebnej do wznowienia. Dostawca poprawił komunikat, IT sprawdziło zapis zdarzenia w integracji.

Druga pozycja, o której trzeba rozmawiać przed startem, to wydajność pierwszych zmian. Plan operacyjny zakładał zwykłą przepustowość, choć te same osoby miały jednocześnie wspierać pracowników, kontrolować dane i zgłaszać błędy. Kierownik operacji rozpisał obsadę przy tablicy i wyszło, że po przydzieleniu ludzi do wsparcia, kontroli danych i kontaktu z dostawcą nie ma pełnej obsady do realizacji bieżących wysyłek. Finanse porównały koszt dodatkowej obsady z czasem potrzebnym na ręczne odtworzenie procesu po zatrzymaniu. Sponsor zatwierdził niższy plan wysyłek podczas pierwszych zmian i wsparcie poza zwykłymi godzinami. Sprzedaż musiała poprawić wcześniejsze uzgodnienia z odbiorcami.

Trzecia rzecz: rezerwa budżetowa. Sprzedaż chciała przeznaczyć ją na dodatkową funkcję zgłoszoną podczas testów. Sponsor odmówił. Pieniądze miały pokryć zdarzenia związane z uruchomieniem, a nie rozszerzenie zakresu przed potwierdzeniem działania podstawowego procesu. Bez tej dyscypliny rezerwa znika na tydzień przed startem, dokładnie wtedy, gdy jest najbardziej potrzebna. Przy planowaniu takich pozycji pomagamy w ramach doradztwa logistycznego i projektów automatyzacji magazynu, ponieważ to właśnie tutaj najczęściej rozjeżdża się uzasadnienie biznesowe policzone rok wcześniej.

Dane: trzy pliki zamiast jednego źródła

Przed rozszerzeniem zmiany na kolejny obszar zespół uruchomił próbę na pełnym zestawie danych. Pierwsze rekordy przeszły poprawnie, potem pojawiła się grupa spraw, których nowy proces nie potrafił przypisać do właściciela.

Zespół danych uznał, że brakuje informacji w systemie źródłowym. Operacja odpowiedziała, że od lat uzupełnia ją w osobnym pliku. Kierownik lokalny miał własną wersję, a drugi obszar korzystał z kopii przesyłanej pocztą. Każda wersja zawierała trochę inne dane. Trzy lokalne pliki zastępowały jedno źródło i wskazanego właściciela. Dopóki pracowała przy nich doświadczona osoba, rozbieżności były poprawiane z pamięci. Nowy system nie znał tych uzgodnień i nie miał skąd ich poznać.

Odruch jest zawsze ten sam: zaimportujmy szybko zawartość plików do systemu. Zespół danych odmówił bez wskazania, która wersja jest poprawna, i miał rację. Analiza jednego przypadku pokazała, dlaczego nie da się po prostu wybrać najnowszego pliku. Jeden był aktualizowany po rozmowie z klientem, drugi po wykonaniu pracy, trzeci służył do planowania kolejnego dnia. Każdy opisywał inny moment procesu. Właściciel procesu rozdzielił informacje, wskazał system, w którym mają powstawać, i moment, od którego zmiana obowiązuje pozostałe zespoły. Prawnik sprawdził, które dane wolno przechowywać i komu udostępniać. Bezpieczeństwo ograniczyło dostęp do funkcji korekty. IT przygotowało historię zmian z autorem i czasem aktualizacji.

Przy okazji wyszła rzecz, którą widzę regularnie. Jeden z wyjątków, który dostawca chciał zaszyć w konfiguracji, powstał po dawnym błędzie i od lat nie był potrzebny. Nie trafił do systemu. Operacja usunęła go z instrukcji, zespół danych poprawił rekordy. Migracja to dobry moment na usuwanie takich pozostałości, ale tylko wtedy, gdy ktoś pyta o źródło reguły zamiast ją odtwarzać.

Pytanie kontrolne przed każdym uruchomieniem: dla każdej informacji sterującej pracą magazynu potraficie wskazać system źródłowy, osobę zatwierdzającą i moment, od którego zmiana obowiązuje? Jeżeli nie, wdrożenie przeniesie do systemu nie proces, tylko rozbieżności.

Kryteria gotowości: odbiór dostawcy to nie gotowość operacji

Podczas odbioru dostawca potwierdził zgodność konfiguracji z zakresem, a kierownik magazynu odmówił zgody, ponieważ operator utknął po przerwaniu połączenia. IT sprawdzało wymianę danych, właściciel procesu regułę postępowania, magazyn zdolność ludzi do samodzielnej pracy. Każda ocena dotyczyła innego fragmentu gotowości i wszystkie były potrzebne.

Ja w takiej sytuacji nie odbieram integracji jako gotowego procesu. Jeżeli operator przy pierwszym błędzie czeka na konsultanta, magazyn nie jest gotowy do samodzielnej pracy, nawet gdy logi są czyste. Wcześniej w tym samym projekcie zdarzył się przypadek podręcznikowy: komunikat poszedł, WMS go odebrał, odpowiedź wróciła do ERP, logi poprawne. Kierownik magazynu poprosił jednak operatora o zmianę zlecenia w chwili, gdy część towaru była już skompletowana. System przyjął zmianę, osoba rozpoczynająca kolejną czynność zobaczyła nową kolejność, a pracownik kończący pakowanie nadal widział starą. Integracja działała, a dwóch pracowników dostało sprzeczne polecenia.

Dostawca uznał, że taki przypadek nie znalazł się w uzgodnionym scenariuszu. Kierownik projektu otworzył zapis decyzji z warsztatu, gdzie zmiana po rozpoczęciu kompletacji oraz wymóg przekazania wyniku do pakowania i transportu były zapisane. Nie trzeba było odtwarzać rozmowy z pamięci ani ustalać, kto co obiecał. Wystarczyło porównać działanie systemu z zatwierdzonym przebiegiem. Dokumentacja decyzji to nie biurokracja, to najtańsze narzędzie rozstrzygania sporów z dostawcą.

Kryterium gotowości, które stosuję najczęściej, brzmi tak: użytkownik z docelowej zmiany wykonuje pełny przebieg na danych produkcyjnych, sam rozpoznaje wyjątek, zatrzymuje błędny proces i wie, komu przekazać sprawę. Bez konsultanta stojącego za plecami. Bez podpowiedzi zespołu projektowego. Jeżeli tego nie ma, nie ma startu, choćby harmonogram pokazywał komplet zamkniętych zadań.

Sponsor w tym projekcie poszedł krok dalej i ustalił, że kierownik magazynu może zatrzymać start, jeżeli operator nie przejdzie samodzielnie normalnego przebiegu i obsługi błędu. IT potwierdza poprawność danych, właściciel procesu zgodność reguły, dostawca działanie konfiguracji, a ostateczna decyzja pozostaje po stronie sponsora. Cztery różne odpowiedzialności, jedna decyzja.

Gdy plan się rozjeżdża: nowa linia bazowa zamiast nowej daty

Na kilka dni przed uruchomieniem harmonogram nadal pokazywał poniedziałek. Konfiguracja była opóźniona, część danych nie przeszła kontroli, a użytkownicy ćwiczyli na starszej wersji systemu. Każda sprawa miała właściciela, lecz razem oznaczały, że plan powstał na założeniach, które przestały być prawdziwe.

Kiedy plan się rozjeżdża, nie zaczynam od nowej daty. Najpierw pytam, które założenie przestało być prawdziwe, kto podejmuje nową decyzję i kto odpowie za jej konsekwencje. Zespół tymczasem robił to, co zwykle: dostawca proponował dłuższą pracę, kierownik projektu zwoływał dodatkowe spotkania, ktoś chciał skrócić ponowną próbę. Liczba aktualizacji statusu rosła, a odpowiedzi na jedno pytanie nadal nie było. Czy firma obsłuży konkretne zamówienie od przyjęcia do zakończenia?

Sponsor odwołał decyzję o starcie do czasu przedstawienia wariantów i warunków każdego z nich. Na komitecie poprosił, żeby wszystkie strony odniosły się do jednego zamówienia, które wpłynie w pierwszym dniu pracy. To najlepsza technika porządkowania takich dyskusji, jaką znam. Dyskusja o gotowości w ogólności trwa godzinami. Dyskusja o jednym zamówieniu kończy się konkretem.

Warianty ułożyły się szybko. Pełny start w poniedziałek wymagałby ręcznej kontroli danych przed każdym przypadkiem objętego ryzykiem, gotowości zespołu dostawcy i dodatkowych ludzi w operacji, bo część pracowników sprawdzałaby i poprawiała zamiast pracować. Finanse potwierdziły, że taki wariant kosztuje więcej niż plan, a kierownik magazynu nie gwarantował zwykłej wydajności. Data zostałaby zachowana, tylko organizacja pracy, koszt i ryzyko byłyby inne. Start ograniczony do standardowego przebiegu oznaczał dwa równoległe sposoby pracy, dwa źródła informacji dla transportu i konieczność utrzymania kontroli uprawnień w starym obejściu.

Sponsor wybrał przesunięcie. Nie kierował się liczbą otwartych zadań. Dane potrzebne do obsługi wskazanego zamówienia nie przeszły kontroli, a użytkownik nie wykonał aktualnego procesu bez pomocy zespołu projektowego. Nowej daty nie ustalono przez dodanie tygodnia do starego harmonogramu. Kierownik projektu zaczął od warunków uruchomienia: właściciel procesu zamyka brakujące reguły, zespół danych poprawia rekordy, IT i dostawca przygotowują kolejną próbę, użytkownicy wykonują proces w wersji przeznaczonej do uruchomienia, kierownik operacji sprawdza, czy mogą pracować przy planowanym obciążeniu. Szkolenie przygotowane na wcześniejszej wersji wycofano, ponieważ zmieniły się nie tylko ekrany, ale też decyzje i moment przekazania odpowiedzialności.

Przesunięcie miało koszt: powtórzona praca dostawcy, kolejne próby użytkowników, zmiana ustaleń ze sprzedażą. Ten koszt zatwierdził sponsor, zamiast przekazać go po uruchomieniu operacji w postaci dodatkowej pracy ręcznej. To jest cała różnica między świadomą korektą planu a przerzuceniem problemu na magazyn.

Stabilizacja, czyli dowód, że zmiana coś dała

Sponsor zatwierdził uruchomienie przy mniejszym planie wysyłek, dodatkowej obsadzie i codziennej kontroli otwartych spraw. Powrót do zwykłej wydajności zależał od wyników normalnej pracy, a nie od upływu kalendarza. Dodatkowy arkusz został jeszcze na krótko jako zabezpieczenie, z właścicielem, terminem kontroli i warunkiem wycofania. Nie mógł służyć do cichego poprawiania błędów poza WMS, a każda rozbieżność miała być zapisana i skierowana do osoby odpowiedzialnej za dane albo proces.

Osobny wątek to uniezależnienie się od dostawcy. Wewnętrzny zespół na początku dzwonił do niego przy każdym błędzie. Sponsor poprosił, żeby część okresu wsparcia wykorzystać na wspólne diagnozy. IT uczyło się odróżniać problem integracji od konfiguracji, właściciel procesu rozpoznawał, kiedy potrzebna jest decyzja biznesowa, zespół danych sprawdzał rekordy przed przekazaniem zgłoszenia dalej. Po kilku tygodniach lokalny kierownik prowadził codzienny przegląd błędów i pytał, czy przyczyna leży w danych, uprawnieniach, przebiegu pracy czy konfiguracji. Gdy użytkownik zgłosił, że system nie pozwala zakończyć sprawy, kierownik odtworzył przebieg, zobaczył brak zatwierdzenia danych i przekazał sprawę właścicielowi danych. Rekord poprawiono tego samego dnia, bez oczekiwania na analizę dostawcy.

Pomiar efektu też został zaplanowany, a nie dopisany jako deklaracja na koniec projektu. Kierownik magazynu miał przedstawić liczbę ręcznych korekt, czas przekazania informacji do transportu oraz zgłoszenia, przy których wewnętrzny zespół nadal potrzebował dostawcy. Trzy wskaźniki, każdy z terminem, źródłem danych i osobą prezentującą wynik sponsorowi. Zarząd zobaczy dzięki temu, czy zmiana usunęła problem, od którego zaczął się projekt, czyli ręczne poprawianie zleceń i brak wspólnego obrazu pracy. Jeżeli szukacie sposobu na trwałe pilnowanie takich mierników po zakończeniu wdrożenia, warto ustawić kontroling logistyczny jeszcze przed startem, a nie kwartał po nim.

Lista kontrolna przed uruchomieniem

Zestaw pytań, które zadaję przed każdą decyzją o starcie. Jeżeli na którekolwiek nie ma odpowiedzi z nazwiskiem i datą, mamy ryzyko, nie plan.

• Czy opisany jest rzeczywisty proces AS-IS razem z decyzjami podejmowanymi poza systemem, w arkuszach i notatkach?
• Kto jest właścicielem każdej reguły sterującej pracą i w jakim czasie ma obowiązek rozstrzygnąć sporną kwestię?
• Co się dzieje, gdy właściciel procesu nie zdecyduje w terminie? Do kogo przechodzi decyzja?
• Czy dla każdej informacji sterującej pracą wskazano jedno źródło, osobę zatwierdzającą i moment obowiązywania?
• Czy w budżecie jest pozycja na zastępstwa ekspertów schodzących z operacji na czas prób?
• Czy plan pierwszych zmian uwzględnia niższą wydajność, wsparcie i kontrolę danych, a sprzedaż o tym wie?
• Czy użytkownik z docelowej zmiany przeszedł pełny przebieg na danych produkcyjnych, w tym obsługę wyjątku, bez pomocy konsultanta?
• Czy zasady oceny pracowników są spójne z nowym podziałem odpowiedzialności, także w okresie przejściowym?
• Kto ma prawo zatrzymać start i jak wygląda ścieżka eskalacji w pierwszym dniu pracy?
• Które obejścia zostają na czas przejścia, kto nimi zarządza i kiedy zostaną wycofane?
• Jakie trzy mierniki pokażą po stabilizacji, czy zmiana usunęła pierwotny problem?

Materiały rozwijające poszczególne wątki znajdziecie w artykułach eksperckich LOCURA, a przykłady z projektów magazynowych omawiam też w cyklu analiz operacyjnych na blogu. Nagrania z komentarzem publikuję na kanale YouTube LOCURA Consulting, a krótsze wnioski z projektów na moim profilu LinkedIn. Jeżeli potrzebujecie kogoś z zewnątrz do ustawienia ról, kryteriów gotowości i planu przejścia, zajmujemy się tym w ramach wsparcia operacyjnego dla firm logistycznych.

Podsumowanie

Zarządzanie zmianą nie jest miękkim dodatkiem do projektu technicznego. To zestaw twardych rozstrzygnięć, bez których konfiguracja nie zamienia się w działającą operację.

• Gotowość systemu i gotowość procesu to dwie różne rzeczy. Dostawca odpowiada za konfigurację, operacja za zdolność ludzi do samodzielnej pracy po pierwszym wyjątku.
• Punkt zero to opis rzeczywistego przebiegu razem z decyzjami zapisanymi poza systemem. Arkusz przy stanowisku zwykle nie jest bałaganem, tylko procesem bez właściciela.
• Konsultacja nie jest prawem weta. Właściciel procesu ma zebrać skutki wariantów, wskazać jeden i przyjąć odpowiedzialność, a po przekroczeniu terminu decyzja idzie do sponsora.
• Brak decyzji nie zatrzymuje projektu, tylko mnoży jego wersje. Trzy równoległe interpretacje jednego procesu to koszt poprawek konfiguracji, powtórzonych testów i korekty komunikacji do klientów.
• Opór ludzi jest najczęściej racjonalną reakcją na sprzeczne zasady: odpowiedzialność za wynik przy odebranym prawie decyzji i ocenie według starych reguł.
• Budżet przejścia to osobna pozycja: zastępstwa na czas prób, niższa wydajność pierwszych zmian, wsparcie poza standardowymi godzinami. Oszczędność w tym miejscu wraca jako przestój po uruchomieniu.
• Kryterium startu ma brzmieć operacyjnie: użytkownik z docelowej zmiany przechodzi pełny przebieg i obsługuje wyjątek bez konsultanta.
• Gdy plan się rozjeżdża, buduje się nową linię bazową na warunkach uruchomienia, a nie przesuwa kalendarz o kilka dni.
• Efekt zmiany trzeba udowodnić liczbami: ręczne korekty, czas przekazania informacji do transportu, zgłoszenia wymagające dostawcy. Bez pomiaru zostaje wrażenie, że jest lepiej.

Przed startem warto zadać jedno pytanie, które porządkuje całą resztę: kto zatrzyma pracę, jeżeli pierwszy operator zobaczy inny wynik niż ten zatwierdzony na komitecie? Tę osobę, jej uprawnienia i sposób eskalacji trzeba ustalić przed uruchomieniem, nie w poniedziałek rano.