Siedem sygnałów, że wdrożenie IT w zakładzie utknęło i trzeba je ratować

Pamiętam wdrożenie systemu do planowania produkcji, które według harmonogramu miało trwać pół roku. Po roku system działał w dwóch z pięciu działów, planiści nadal układali plan w arkuszu, a potem przepisywali go do systemu, „żeby się zgadzało”. Na każdym spotkaniu projektowym padało zdanie, że jesteśmy „prawie na końcu”. Nikt nie powiedział na głos, że projekt utknął, bo nikt nie chciał być tym, który to powie.

Projekty IT w zakładach produkcyjnych rzadko kończą się spektakularną porażką. Częściej przechodzą w stan zawieszenia: system jest, licencje są opłacone, ale nikt z niego naprawdę nie korzysta. Poniżej siedem sygnałów, które z mojego doświadczenia najlepiej to zapowiadają. Jeśli widzicie trzy lub więcej, czas na rozmowę.

1. Ludzie prowadzą równoległą ewidencję

To najpewniejszy sygnał. System teoretycznie działa, ale magazynier ma swój zeszyt, planista swój arkusz, a kierownik zmiany swoją tablicę. Dane w systemie są uzupełniane „po fakcie”, przepisywane z papieru na koniec dnia.

Równoległa ewidencja oznacza, że ludzie nie ufają systemowi albo że system nie pozwala im wykonać pracy tak szybko, jak potrzebują. Oba powody da się usunąć, ale najpierw trzeba je nazwać. Zapytajcie wprost: dlaczego prowadzisz arkusz? Odpowiedzi bywają zaskakująco konkretne: „bo nie widzę w systemie, co jest na następnej zmianie”, „bo wprowadzenie przyjęcia trwa trzy razy dłużej niż wpis w zeszycie”.

O tym, jak trudno rozstać się z arkuszem, pisałem w wydaniu o magazynie w Excelu. Arkusz nie znika, kiedy kupimy system. Znika dopiero wtedy, gdy system jest wygodniejszy.

2. Projekt nie ma właściciela po stronie zakładu

Każde wdrożenie ma kierownika projektu po stronie dostawcy. Pytanie, kto jest właścicielem po stronie zakładu. Jeśli odpowiedź brzmi „informatyk”, „dział IT” albo „wszyscy”, to problem.

Właścicielem projektu wdrożenia systemu produkcyjnego czy magazynowego powinna być osoba z biznesu: kierownik produkcji, logistyki, szef operacji. Ktoś, kto ma władzę, żeby zmienić sposób pracy w dziale, i kto odpowiada za wynik tego działu. Informatyk jest niezbędny, ale nie zmieni procesu, w którym nie pracuje.

W projekcie, o którym wspomniałem na początku, właścicielem był informatyk, który uczciwie się starał. Ale kiedy planiści mówili, że „tak nie da się pracować”, nie miał narzędzi, żeby rozstrzygnąć, czy mają rację.

3. Lista zmian rośnie szybciej, niż maleje

W każdym wdrożeniu pojawiają się prośby o zmiany: dodatkowe pole, inny raport, inny sposób wyświetlania. To normalne. Niepokojące jest wtedy, gdy lista rośnie z tygodnia na tydzień, a każda nowa funkcja rodzi trzy kolejne prośby.

Zwykle oznacza to, że zakład próbuje odtworzyć w nowym systemie dokładnie to, co miał w starym, łącznie z obejściami i nawykami. Zamiast dopasować proces do standardowych funkcji systemu, dopasowuje system do każdego wyjątku. Koszt rośnie, termin się oddala, a system staje się coraz trudniejszy w utrzymaniu.

4. Testy robi się na przykładach, nie na prawdziwych danych

„Przetestowaliśmy na trzech zleceniach i działa.” Prawdziwy zakład ma kilkaset aktywnych indeksów, zlecenia z wyjątkami, zamienniki materiałów, braki, reklamacje. System, który działa na trzech wzorcowych przykładach, może się wyłożyć pierwszego dnia pracy na pełnych danych.

Dobre testy odbywają się na kopii prawdziwych danych, z prawdziwymi, trudnymi przypadkami. Najlepiej, żeby przypadki testowe przygotowali ludzie z hali, a nie konsultanci. Oni wiedzą, co się naprawdę zdarza w piątek o czternastej.

5. Dane podstawowe są „do uzupełnienia później”

Indeksy materiałowe bez jednostek, marszruty bez czasów, lokalizacje bez przypisania, struktury wyrobów niekompletne. System stoi na danych podstawowych. Jeśli są słabe, każdy wynik systemu będzie słaby, a ludzie szybko przestaną mu ufać.

Porządkowanie danych jest najbardziej nudną i najbardziej niedocenianą częścią wdrożenia. Często zostaje zepchnięte na koniec, „bo najpierw skonfigurujemy”. Tymczasem wymaga dużo pracy ludzi z zakładu, i to tych, którzy znają produkty, a nie tych, którzy akurat mają wolne.

6. Szkolenia odbyły się raz, dawno temu

Szkolenie użytkowników trzy miesiące przed startem, potem przesunięcie terminu, potem kolejne. W dniu uruchomienia ludzie pamiętają z niego niewiele. Do tego szkolenie było często prowadzone na ekranie projektora, a nie przy stanowisku pracy.

Działa inne podejście: krótkie szkolenia tuż przed startem, na stanowisku pracy, prowadzone przez kluczowych użytkowników z danego działu. Do tego jedna osoba na zmianie, która „umie system” i do której można podejść z pytaniem. I proste instrukcje przy stanowisku, jednostronicowe, ze zrzutami ekranu.

7. Nikt nie potrafi powiedzieć, co się poprawiło

Ostatni sygnał jest najbardziej ogólny. Zapytajcie zespół projektowy: co konkretnie poprawiło się w zakładzie dzięki temu systemowi? Nie „mamy lepszą widoczność”, tylko: skrócił się czas kompletacji, zmniejszyły się różnice inwentaryzacyjne, planista oszczędza dwie godziny dziennie.

Jeśli nikt nie umie odpowiedzieć, to znaczy, że projekt nie miał mierzalnych celów albo że o nich zapomniano. Bez nich trudno ocenić, czy projekt idzie dobrze, i trudno uzasadnić dalsze wydatki.

Co zrobić, gdy projekt utknął

Zatrzymanie i uczciwa ocena są lepsze niż dalsze brnięcie. Z mojego doświadczenia pomagają następujące kroki:

1. Przegląd stanu bez szukania winnych. Spotkanie dostawcy, właściciela biznesowego i kluczowych użytkowników. Co działa, co nie, dlaczego.
2. Zawężenie zakresu. Zamiast wdrażać wszystko naraz, wybrać jeden obszar, który uruchomi się w pełni i zacznie przynosić korzyści. Reszta później.
3. Wyznaczenie właściciela z biznesu, z czasem przeznaczonym na projekt, a nie „przy okazji”.
4. Zamrożenie listy zmian. Nowe prośby tylko wtedy, gdy bez nich nie da się pracować. Reszta na listę po uruchomieniu.
5. Porządek w danych podstawowych dla wybranego obszaru, zanim ruszy cokolwiek innego.
6. Mierzalny cel na najbliższe trzy miesiące, jedna lub dwie liczby.

Czasem ocena prowadzi do wniosku, że system nie pasuje do zakładu i trzeba go zmienić. To bolesne, bo pieniądze zostały wydane. Ale dalsze inwestowanie w coś, czego nikt nie używa, to wydawanie kolejnych pieniędzy na to samo rozczarowanie.

Na koniec uwaga, która wraca przy każdym modnym narzędziu. Rozważania o tym, czy zakład potrzebuje sztucznej inteligencji, mają sens dopiero wtedy, gdy podstawowe systemy działają i mają dobre dane. Nowa warstwa na nieuruchomionym wdrożeniu nie ratuje projektu, tylko go komplikuje.

Jeśli chcecie sprawdzić własny projekt, zacznijcie od dwóch rzeczy: policzcie, ile z siedmiu sygnałów widzicie u siebie, i zapytajcie trzech użytkowników z hali, czy prowadzą coś poza systemem. Gdy sygnałów jest trzy lub więcej, a na pytanie o właściciela projektu po stronie zakładu nikt nie odpowiada imieniem i nazwiskiem, przegląd stanu projektu nie powinien czekać do przyszłego kwartału.

Projekt, który utknął, da się uratować, ale im później ktoś powie to głośno, tym więcej będzie to kosztować.