Autor ANDRZEJ BOGUSZ
Co (było) pierwsze: procesy czy systemy IT? Jak pogodzić wdrożenie ERP, CRM, WMS, Workflow... i innych systemów informatycznych z optymalizacją (porządkowaniem) procesów biznesowych?
Jak z sukcesem wdrożyć system informatyczny? Brak odniesienia do procesu biznesowego podczas wdrażania np. 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 i uporządkowania procesów i zamodelować je w systemie?
Znak zapytania w tytule nie jest przypadkowy. Odpowiedź na to pytanie wcale nie jest oczywista. Dla wielu fanów (fanatyków?) informatyzacji wszystkiego co się rusza w biznesie nawet nawias nie jest ironiczny – bo przecież „Business is IT”. Niezależnie od branży J.
Zacznijmy od odrobiny historii.
Pierwsze koncepcje oparte na procesowości
Można snuć teorie na temat procesów biznesowych w cywilizacjach starożytnych (kilka tysięcy lat wstecz). Współcześnie 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 systemy 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 systemów IT bez nawiasu, to tylko teoretyczna odpowiedź będzie oczywista. „Proces” ma tradycję dziesięciokrotnie (nowożytnie) lub stukrotnie (starożytnie) większą niż „system”.
Ale bez słowa w nawiasie? Jeśli zgodzimy się z tym, że wszystko, co robimy w biznesie, jest jakimś procesem, to oczywiście, systemy mogą nam pomóc zarządzać naszymi procesami sprawniej, szybciej, efektywniej… Ale tylko mogą – bo nie muszą.
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”. Albo dosadniej…
Praktyka wdrożeń systemów informatycznych
Historia wdrożeń systemów IT 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. Pomijam tu wszelkie aspekty związane z oporem ludzi, brakiem zaangażowania lub zainteresowania kierownictwa czy brakiem testów wdrażanych systemów.
Zacznijmy od systemu. Oprogramowanie wspomagające zarządzanie — 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 systemu IT
A gdyby tak odwrócić sytuację? I zacząć od określenia:
- jak przebiega proces — jeden, drugi, trzeci… Namalować (lub zapisać) je w postaci bardzo prostej mapy, używając najprostszych symboli
- co jest na wejściu do każdego procesu, a co jest na jego wyjściu
- do kogo lub do 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.
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 IT — 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ń.
Dzięki wdrażaniu systemu mamy kolejną okazję do doskonalenia naszych procesów i eliminacji „śmieci”.
Bo często 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. 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 systemu.
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. Gdy używasz pilota od telewizora, to nie interesuje Cię, co w nim (pilocie) się dzieje po naciśnięciu przycisku „4”, ale to, że po akcji Twojego palca na wybrzuszeniu z napisem „4” telewizor zacznie wyświetlać program zakodowany na kanale czwartym… Jeśli wszystko jest prawidłowo zaprojektowane, to powstały obraz systemu pokrywa się — w warstwie przepływu i przetwarzania informacji — z logiką procesu biznesowego. Jeśli nie, to znowu mamy „śmieci” lub konieczność dostosowania systemu do naszych wymagań.
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.
Czy 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 i akceptowalny sposób (do którego możemy się dostosować) odzwierciedla on nasz proces biznesowy? 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. Tak więc tą alternatywą jest dostosowanie się do systemu…
A czy można wdrażać system IT bez porządkowania procesów biznesowych? Można. Podobno czasem się to udaje. Ale czy warto ryzykować?
Autor: Andrzej Bogusz
Artykuły tego Autora
