Dlaczego samo wdrożenie systemu nie rozwiąże twoich problemów?

Firmy wydają setki tysięcy złotych na systemy IT, automatyzację i cyfryzację. Rezultat? Często żaden. Problem nie w systemach, ale w tym, że próbujemy zautomatyzować chaos. A żaden system – nieważne jak drogi i zaawansowany – nie naprawi złego procesu. Wręcz przeciwnie: często utrwali go na lata.

Rozwój technologiczny i cyfryzacja to coś, czego żadna firma nie może dziś uniknąć. I to dobrze. Ale obserwuję pewien powtarzający się błąd, który pochłania budżety, frustruje zespoły i ostatecznie… niczego nie zmienia. Co gorsza, w tym błędzie udział mają też sprzedawcy i marketingowcy firm technologicznych, którzy obiecują, że ich system „rozwiąże wszystkie problemy".

Największą czerwoną lampką jest moment, kiedy w firmie pada stwierdzenie: „Musimy wdrożyć system, który rozwiąże nasze problemy z…" – i tutaj możesz wstawić dowolne słowo: planowaniem, magazynem, sprzedażą, obsługą klienta.

Typowy scenariusz porażki

Przeanalizujmy to na konkretnym przykładzie z mojego podwórka – planowaniu produkcji.

Firma odkrywa problem: planowanie nie działa albo w ogóle nie istnieje. Objawy? Opóźnienia w produkcji, brak transparentności dat dostaw dla klientów, brak kontroli nad produkcją w toku, rosnące zapasy, chaos w komunikacji między sprzedażą, produkcją i zakupami.

Diagnoza pada szybko: „Potrzebujemy systemu do planowania! Przecież nie będziemy tego robić ręcznie czy w ERP-ie."

Firma wdraża system. I faktycznie – jest super. Jest plan produkcji, widać co się dzieje i gdzie jest jakie zlecenie. Wprawdzie trzeba było dotrudnić jeszcze dwie osoby, żeby utrzymywać dane niezbędne do funkcjonowania systemu, ale system działa.

Efekt?

Nadal mamy opóźnienia w produkcji. Nadal do końca nie wiadomo, co kiedy będzie dostępne, bo daty w planie słabo się sprawdzają. Zapasy dalej rosną, a chaos nadal trwa.

Co poszło nie tak?

Firma wdrożyła system, który robi plan. Ale w żaden sposób nie wdrożyła procesu, który ten plan obsługuje, kontroluje i wykorzystuje go do planowania pracy na produkcji

System działa i planuje poprawnie – na podstawie danych, które ma dostępne.

Zamówienia nadal są wrzucane na jedną datę w miesiącu, więc system je rozplanowuje według swojego algorytmu bez wyraźnych priorytetów. Rozliczenie produkcji nadal nie jest z realizacji harmonogramu produkcji – tylko na koniec miesiąca prezes pyta się, jak zamknęliśmy miesiąc w wolumenie i wartości sprzedaży. Jeśli się zgadza, nie drąży dalej.

System jest. System działa. System kosztował. Ale nic się nie zmieniło (poza tym, że mamy system, który trzeba obsługiwać).

Automatyzacja chaosu to nadal chaos

Samo wdrożenie systemu, robotów czy automatyzacji nie przyniesie efektów, jeśli te rozwiązania nie są wkomponowane w cały system, jakim jest firma. Jeśli nie zostaną odpowiednio sprzężone z procesem.

I tutaj dochodzimy do kluczowej zasady: najpierw proces, potem automatyzacja. Tam, gdzie to możliwe, powinniśmy najpierw przetestować proces ręcznie, nawet na zasadzie trial-and-error, a dopiero później go automatyzować.

Ale życie nie zawsze jest tak proste.

Kiedy wdrożenie musi być równoległe?

Są sytuacje, w których nie możemy sobie pozwolić na luksus wdrożenia procesu, przetestowania go i dopiero później jego automatyzacji. I są to sytuacje całkowicie uzasadnione.

Pierwszy przypadek: system jako katalizator zmian

Bardzo często – szczególnie w dużych firmach – wdrożenie systemu jest niezbędnym katalizatorem zmian procesowych. Bez tego impulsu firma by tych zmian po prostu nie wdrożyła.

Dlaczego? Bo w dużych organizacjach zmiana jest trudna. Są struktury, nawyki, polityka wewnętrzna. „Zawsze tak robiliśmy" to argument, który paraliżuje. A wtedy pojawia się wdrożenie systemu jako event, który wymusza zmianę. Prezes podpisał umowę, budżet został zatwierdzony, firma wdrożeniowa jest już na miejscu – teraz nie ma odwrotu. I to właśnie ta presja, ten deadline, ten wydatek sprawia, że nagle okazuje się, że można zmienić procesy, które latami były nietykalne.

Z moich obserwacji wynika, że przy wdrożeniu różnego rodzaju systemów najczęściej osiągane wyniki – pod którymi podpisują się firmy wdrożeniowe – nie wynikają z samego systemu, a właśnie z poprawy procesów, które to wdrożenie wymusiło. System staje się pretekstem. I to jest w porządku, jeśli zdajemy sobie z tego sprawę.

Drugi przypadek: system jako warunek realizacji procesu

Są procesy, które w ogóle nie mogą funkcjonować bez systemu. Nie dlatego, że nie chcemy ich robić ręcznie, ale dlatego, że to fizycznie niemożliwe.

Weźmy przykład: bardzo szczegółowe planowanie i przeplanowywanie produkcji po każdej potwierdzonej operacji przy 300 maszynach, produkcji gniazdowej i 1500 zleceniach produkcyjnych w toku. To nie jest kwestia tego, że „nie chce nam się" robić tego ręcznie. To jest kwestia tego, że potrzebowalibyśmy nieskończonej liczby studentów z kalkulatorami, a i tak by nie nadążyli.

W takich sytuacjach wdrożenie systemu i budowa procesu muszą iść równolegle. Nie ma innej opcji. Ale – i to jest kluczowe – nadal musimy zadbać o proces. Nadal musimy wiedzieć, kto, co, kiedy i jak z tym systemem będzie robił. Nadal musimy zdefiniować przepływ informacji, punkty kontrolne, zasady eskalacji.

Zasada, której nie ruszamy

Niezależnie od tego, czy wdrażamy proces najpierw, czy równolegle z systemem, jedna zasada musi być niezłomna:

Nie ma automatyzacji bez zadbania o proces. To się nie uda.

Możesz wdrożyć system jako katalizator. Możesz wdrażać system i proces równolegle, bo inaczej się nie da. Ale nie możesz wdrożyć systemu, mając nadzieję, że proces się jakoś sam ułoży. Bo się nie ułoży.

System bez procesu to drogi gadżet, który pokazuje ładne dashboardy (i w ogóle jest czymś czym można się pochwalić), ale nie zmienia rzeczywistości. A czasem nawet ją pogarsza, bo teraz masz dodatkowy system do utrzymania, dodatkowe dane do wprowadzania i dodatkową frustrację, że „przecież wdrożyliśmy system, a nic się nie zmieniło".

Jak nie wpaść w pułapkę?

Kilka kroków, które warto przejść, zanim zainwestujesz w kolejny system:

1. Dobrze zdefiniuj problem, który chcesz rozwiązać (punkt A)

Nie „mamy chaos w planowaniu", ale konkretnie: „Klienci dostają potwierdzenia terminów z opóźnieniem 2 tygodni, a 40% zamówień jest realizowanych z opóźnieniem powyżej 5 dni, co wynika z braku ustrukturyzowanego planu produkcji i odpowiednio ustrukturyzowanej komunikacji dotyczącej terminów realizacji, oraz braku kontroli realizacji produkcji".

2. Określ, po czym widać, że ten problem istnieje

Najlepiej na danych. Mierz to. Jeśli nie mierzysz, nie wiesz, czy problem faktycznie rozwiązałeś.

3. Opisz, jak wygląda rzeczywistość po rozwiązaniu problemu (punkt B)

Nie „będzie lepiej", ale: „Klient dostaje potwierdzenie terminu w ciągu 24 godzin, 95% zamówień realizujemy w terminie z dokładnością +/- 2 dni".

4. Zastanów się, co musiałoby się zadziać, żebyście mogli przenieść się z punktu A do punktu B

Najlepiej kilka możliwych rozwiązań. System to często tylko jedno z nich.

Jeśli w tych rozwiązaniach znajdzie się system, zapytaj:

5. Jaka jest alternatywa do systemu?

Co, jeśli nie system? Czasem okazuje się, że dobrze zaprojektowany Excel i prosty proces dają 80% efektu za 5% kosztu.

6. Jeśli jednak system, to:

• Co musimy zapewnić w firmie, żeby ten system działał? (dane, kompetencje, proces, infrastrukturę)
• Co robimy z wynikami systemu? (np. z planem – kto go weryfikuje, zatwierdza, komunikuje?)
• Opisz możliwie dokładnie, jak będzie wyglądać rzeczywistość po wdrożeniu. Np.: „Wychodzi plan, weryfikuje go planista, przesyła do produkcji, sprzedaż dostaje raport z realizacji…"

7. Teraz kluczowe pytanie: czy mamy zdefiniowane procesy, które będą te elementy obsługiwać?

Jeśli nie, trzeba stworzyć plan stworzenia tych procesów. I zdecydować: czy możemy je przetestować najpierw ręcznie (nawet w uproszczonej formie), czy musimy iść równolegle z wdrożeniem systemu?

Jeśli równolegle – to w porządku, ale wtedy projekt musi obejmować zarówno wdrożenie systemu, jak i budowę procesów. Nie możemy zakładać, że procesy „się jakoś ułożą".

8. Czy ta przyszła sytuacja z systemem faktycznie odzwierciedla nasz punkt B?

Czy naprawdę rozwiązuje problem, który zdefiniowaliśmy na początku?

9. Co może się zadziać, że mimo wdrożenia systemu nasze problemy nie zostaną rozwiązane?

Lista ryzyk. Co musimy zrobić, żeby te ryzyka nie wystąpiły?

A co z danymi?

Słyszę pytanie: „A gdzie jest coś o danych? Przecież przygotowanie danych jest najważniejsze, żeby system działał!"

Prawda. Ale w tym artykule nie skupiamy się na tym, żeby system działał, tylko żeby był rozwiązaniem, które faktycznie przyniesie efekty. O jakość danych – w sensie technicznym – świetnie potrafią zadbać firmy wdrożeniowe, bo potrzebują ich, żeby pokazać, że system „działa". To nie znaczy, że dane nie są wyzwaniem biznesowym – są, i to dużym. Ale da się je przygotować.

Problem jest wtedy, gdy system działa, dane są dobre, ale… nic się nie zmienia. Bo nikt nie zadbał o proces, który te dane i wyniki systemu wykorzysta.

Podsumowanie

System jest tylko narzędziem do automatyzacji naszych procesów. Najpierw musimy zadbać o dobre procesy, żeby w ogóle wiedzieć, co automatyzować. Tam, gdzie to możliwe, testujemy proces ręcznie, a dopiero potem automatyzujemy.

Są sytuacje, kiedy wdrożenie systemu musi iść równolegle z budową procesu – albo dlatego, że system jest katalizatorem zmian (szczególnie w dużych firmach), albo dlatego, że proces bez systemu po prostu nie może działać (skala, złożoność). To jest OK. Ale nawet wtedy nie możemy pominąć etapu projektowania i wdrażania procesów.

Zasada jest jedna i niezłomna: nie ma automatyzacji bez zadbania o proces. To się nie uda.

Żaden system nie jest nigdy magicznym rozwiązaniem, które rozwiąże nasze problemy. System może tylko usprawnić to, co już działa, albo umożliwić skalowanie tego, co jest dobrze zaprojektowane.

Jeśli automatyzujesz chaos, otrzymasz zautomatyzowany chaos. I to drogi zautomatyzowany chaos, który będzie jeszcze trudniej zmienić, bo „przecież wdrożyliśmy system".

Pamiętajmy o tym, zanim podpiszemy kolejną umowę z obietnicą, że „ten system rozwiąże wszystkie nasze problemy".