Jak z sukcesem wdrożyć ERP? Brak odniesienia do procesu biznesowego podczas wdrażania ERP może spowodować, że w codziennej pracy pojawią się czynności wymuszone przez system i nieprzydatne do zarządzania naszą firmą lub — co gorsza — że system nie będzie adekwatny do naszego biznesu, a wtedy całe jego wdrożenie stanie się nieuzasadnionym kosztem.
Dlatego może lepiej zacząć od zdefiniowania procesów i zamodelować je w systemie? Nie przez przypadek stawiam tu znak zapytania. Nawias w tytule też nie jest przypadkowy…
Pytanie w tytule ma prowokować. Nie jest ono bezsensowne, a odpowiedź na nie wcale nie jest oczywista. W tym tekście zmierzymy się z tym zagadnieniem. Najpierw jednak trochę historii.
Pierwsze koncepcje oparte na procesowości
Początek procesowego rozumienia biznesu należałoby umieścić pod koniec XVII wieku, kiedy Adam Smith użył sekwencji czynności do opisu produkcji szpilek jako podstawy swoich rozważań o organizacji pracy. Nawet jeśli nie był w tym rozumieniu pierwszy, to z pewnością był jednym z najważniejszych. Wiek później był Frederic Taylor ze swoimi „Zasadami naukowego zarządzania” (słynny „tayloryzm”). Od połowy XX wieku nastąpiła wręcz eksplozja koncepcji opartych na procesach biznesowych (TQM, outsourcing, re-enigeering, SixSigma itd.), aż do uznania zarządzania procesowego jako pewnej normy, niezależnie od jej ogólności i różnorodności stosowania. Warto nadmienić, że najnowsza norma ISO 9001 już nie zaleca, ale wymaga zastosowania podejścia procesowego.
Wspomaganie biznesu przez systemy informatyczne ma znacznie krótszą historię, niewiele ponad półwieczną, a o systemach klasy ERP, które wspomagają zarządzanie przedsiębiorstwem można mówić dopiero od około 30 lat.
Jeśli zostawimy pytanie o pierwszeństwo procesów czy ERP bez nawiasu, to tylko teoretyczna odpowiedź będzie oczywista. Bo jeśli zgodzimy się z tym, że wszystko, co robimy w biznesie, jest jakimś procesem, to chyba nie ma nikogo, kto nie zgodziłby się z twierdzeniem, że jeśli mamy bałagan i go zinformatyzujemy to otrzymamy zinformatyzowany bałagan, a nie system zarządczy. Za oceanem mówią na to „GIGO”, czyli „Garbage In, Garbage Out”.
Praktyka wdrożeń systemów ERP
Brak odniesienia do procesu biznesowego podczas wdrażania systemu może spowodować, że w codziennej pracy pojawią się czynności niejako wymuszone przez system, który będzie wymagać zasilania go danymi.
Historia wdrożeń ERP zna mnóstwo niepowodzeń, których efektem są systemy działające częściowo, wadliwie lub wcale. Zastanówmy się, czy i jak dzięki procesom można uprawdopodobnić sukces wdrożenia ERP. Pomijam tu wszelkie aspekty związane z oporem ludzi, brakiem zaangażowania lub zainteresowania kierownictwa czy brakiem testów.
Zacznijmy od systemu. Oprogramowanie ERP — nie mówimy tu o systemach graficznych czy sterowania numerycznego ruchem urządzeń — realizuje trzy główne funkcje: rejestrację danych (wprowadzenie, zaczytanie, import), ich przetworzenie (zapis, przesył, przeliczenie) i możliwość uzyskania danych po przetworzeniu (wyświetlenie, zaraportowanie lub eksport). Są to operacje na danych reprezentujących pewne informacje, ale zazwyczaj nie są to procesy biznesowe.
Takim procesem jest np. fizyczne przetworzenie surowca podczas produkcji, negocjacje z klientem zakończone umową, wystawienie i dostarczenie do klienta faktury za usługę itp. Czasami proces może mieć dokładną reprezentację w systemie informatycznym (np. obsługa zamówienia w sklepie internetowym), ale nie są to częste sytuacje. Brak odniesienia do procesu biznesowego podczas wdrażania systemu może spowodować, że w codziennej pracy pojawią się czynności niejako wymuszone przez system, który będzie wymagać zasilania go danymi. I wtedy prawdopodobnie okaże się, że dane te są zerowej jakości lub przestają funkcjonować, zaś wdrożenie polegało właściwie na wymuszeniu na kliencie dostosowania swoich praktyk do wymagań systemu.
Podejście procesowe podczas wdrożenia ERP
A gdyby tak odwrócić sytuację? I zacząć od określenia, jak przebiega proces — jeden, drugi, trzeci… Namalować je w postaci bardzo prostej mapy, używając najprostszych symboli. Potem określić, co jest na wejściu do każdego procesu, a co jest na jego wyjściu. I do kogo lub czego jest to wyjście dostarczane. Taka analiza da obraz tego, czym się zajmujemy i pozwoli ocenić, czy powstały obraz jest sensowny. Jeśli nie jest, to najwyraźniej potrzeba dokonać pewnej rewizji naszego biznesu, czyli wziąć się za porządki. Tak, by wyodrębnione, kluczowe dla naszego biznesu informacje zostały odwzorowane w postaci danych w systemie.
Zazwyczaj konstrukcja systemu jest wynikiem wielu doświadczeń jego dostawcy i ma swoje uzasadnienie. Dzięki wdrażaniu ERP mamy kolejną okazję do doskonalenia naszych procesów i eliminacji „śmieci”.
Niektóre z danych będą mieć bardzo konkretne wymogi co do postaci, formatu, poprawności itp. I tu dochodzi do pierwszego styku z systemem ERP — bo w nim są predefiniowane formaty danych i sposoby ich przetwarzania w postaci funkcji systemu. Powinniśmy zweryfikować, czy system umożliwia rejestrację i przetwarzanie naszych danych zgodnie z wymaganiami procesu oraz czy nie narzuca nam dodatkowych wymagań. Bo zazwyczaj konstrukcja systemu jest wynikiem wielu doświadczeń jego dostawcy i ma swoje uzasadnienie. Warto się jej przyjrzeć, bo być może podczas naszej analizy procesów biznesowych nie pomyśleliśmy o pewnych uwarunkowaniach. A dzięki wdrażaniu ERP mamy kolejną okazję do doskonalenia naszych procesów i eliminacji „śmieci”. Oczywiście, często wnioski będą odwrotne: to system zawiera zbędne dla nas elementy lub wymaga dostosowania i uzupełnienia. Czyli znowu omijamy niebezpieczeństwo nieoptymalnego wdrożenia ERP.
Ostatnim elementem jest zrozumienie procesów zachodzących w samym systemie. Oczywiście nie na poziomie algorytmów programistycznych, ale możliwych akcji użytkowników w systemie i reakcji systemu na nie. Jest to również pewien obraz blokowy procesu, ale nie biznesowego lecz informatycznego, z aspektem użytkownika. Idealnie, jeśli system umożliwia niejako „rysowanie” procesu przy użyciu funkcji i modułów systemu jako elementów takiego diagramu. Jeśli wszystko jest prawidłowo zaprojektowane, to powstały obraz pokrywa się — w warstwie przepływu i przetwarzania informacji — z diagramem procesu biznesowego. Jeśli nie, to znowu mamy „śmieci” lub konieczność dostosowania systemu do naszych wymagań.
W tym miejscu powinniśmy też zobaczyć, czy sposób działania naszej organizacji umożliwia taką obsługę systemu, jaka jest przez niego wymagana. Bo być może niektóre funkcje nie będą nigdy używane, a niektóre dane nie będą miały użytkownika, który będzie w stanie je odpowiednio wprowadzać. Przykładem mogą być bieżące dane produkcyjne, planowane do wprowadzania przez pracowników liniowych, którzy nigdy nie rejestrowali — choćby na papierze — żadnej informacji i nie mają do tego warunków, np. bo nie mają dostępu do komputera.
Jaka jest alternatywa?
Oczywiście można, choć według mnie jest to znacznie mniej efektywne, wychodząc od procesu zamodelowanego w systemie oraz od postaci i zawartości danych w nim przewidzianych, podążać w stronę weryfikacji, czy w prawidłowy albo w akceptowalny sposób (do którego możemy się dostosować) odzwierciedla on nasz proces biznesowy. I czy dane zapewniane przez system spełniają nasze wymagania raportowe i kontrolingowe. Oczywiście łatwiejsze to będzie w księgowości czy w kadrach, a nieco trudniejsze na produkcji czy sprzedaży.
A czy można wdrażać ERP bez porządkowania procesów biznesowych? Można. Podobno czasem się to udaje. Ale czy warto ryzykować? Na pytanie postawione w tytule artykułu (bez nawiasu) nie odpowiem. Pozostawiam to Tobie, Czytelniku. I zapraszam do dyskusji.
Chcesz skomentować, podyskutować lub nawiązać kontakt z autorem? Napisz: [email protected]
Czytaj też: Proces a projekt >>>
Manager i konsultant z szerokim doświadczeniem (bankowość, informatyka, konsulting). Ekspert z zakresu zarządzania i optymalizacji procesów biznesowych, zarządzania projektami, bezpieczeństwa teleinformatycznego, zarządzania ryzykiem. Szef projektów zmian organizacyjnych i projektów informatycznych. Właściciel firmy AB CONSULT, zajmującej się doradztwem operacyjnym i strategicznym.
