Jarosław Badurek
Nowy paradygmat zarządzania procesami w przedsiębiorstwie odchodzi od klasycznego podejścia diagnostycznego na rzecz prognostycznego. W tym nurcie mieści się model BPM, którego efektywne stosowanie wymaga nie tylko określonych technologii, ale także uwzględnienia szeregu pozatechnicznych czynników organizacyjnych.
Pojęcie BPM (Business Process Management) ma swojego prekursora - BPR (Business Process Reengineering) - zdefiniowanego w fundamentalnej pracy Hammera i Champy'ego z roku 1993, pod znamiennym tytułem "Reengineering the Corporation: A Manifesto for Business Revolution". Dodajmy, że książka dostępna jest również w języku polskim (Reengineering w przedsiębiorstwie, 1996 r.), a jej autorzy proponują obecnie nowsze koncepcje, uwzględniające także technologie internetowe ("X-engineering przedsiębiorstwa. Przemyśl swój biznes w erze cyfrowej", 2003 r.). Aktualnym pozostaje wszakże ich motto, którym często rozpoczynali swoje seminaria z zakresu organizacji i zarządzania: "zapomnij o tym, co wiesz odnośnie tego, jak powinno funkcjonować przedsiębiorstwo - większość z tych prawd w nowych warunkach rewolucji informatycznej jest po prostu fałszem". Sam skrót BPM używany jest także w znaczeniu Business Process Modeling oraz Business Performance Measurement, a wszystkie te pojęcia można powiązać cykliczną triadą: modelowanie . zarządzanie . mierzenie. Innymi słowy, mówiąc: modelowanie (mapowanie) procesów w przedsiębiorstwie jest podstawą efektywnego zarządzania nimi, pod warunkiem, że pamiętamy o regule "co nie może być zmierzone, nie może być poprawione".
Rys. 1 Cele i metryki wybranego procesu- zasada "niemierzalne jest niepoprawialne"
W nurcie ładu korporacyjnego
Widzimy zatem, że podejście BPM nasuwa skojarzenia z zasadami Deminga i metodologią stosowaną np. w strategii SixSigma, tj. cyklem organizatorskim DMAIC - Definiuj, Mierz, Analizuj, Implementuj poprawę, Kontroluj (Define, Measure, Analyse, Improve, Control). Nie jest tak przypadkiem, gdyż BPM mieści się w nurcie modeli referencyjnych ładu korporacyjnego. Wskażmy tu choćby na COBIT (Control Objectives for Information and Related Technology) - patrz przykład praktyczny, rys. 1.
Trzeba przy tym pamiętać, że BPM jest projektem odnoszącym się do procesów przedsiębiorstwa. Warto więc przypomnieć różnice między tymi dwoma podstawowymi typami działań. Projekt jest przedsięwzięciem innowacyjnym i unikatowym, ukierunkowanym na zmiany, w tym radykalne, dla osiągnięcia nowych celów w przyszłości, związanym z podwyższonym ryzykiem oraz częstymi konfliktami wymagającymi zaangażowania kierownictwa, względnie doradców. Z kolei proces, to stabilne czy rutynowe operacje nakierowane na cele bieżące, podlegające ewolucyjnym zmianom o niewielkich zagrożeniach, w warunkach stabilnych relacji międzyludzkich oraz mniejszego zaangażowania kierownictwa.
W tym miejscu nasuwa się pytanie o korzyści stosowania BPM i możliwości ich pomiaru. Odpowiedź może być trudna, ponieważ mówimy o technologii systemowej, tj. przenikającej całość przedsiębiorstwa. Mówiąc obrazowo, BPM ma charakter dyfuzyjny, co nasuwa skojarzenia z aspektami infrastrukturalnymi: nie wątpimy w potrzebę posiadania infrastruktury, choć niełatwo wykazać wymierne zyski przez nią generowane. Przykładowo: znamy koszty zakupu komputerów dla firmy, ale czy wiemy, jakie zyski osiągamy dzięki nim.
Próby ustalenia korzyści są jednak podejmowane przez instytucje badawcze czy firmy doradcze i pozwalają na kwalifikowane oszacowanie oszczędności wynikających ze stosowania BPM, na podstawie doświadczeń praktycznych:
- obniżenie kosztów projektowych na poziomie 5-10% budżetu;
- skrócenie czasów projektowych o ok. 15-20%;
- zmniejszenie bezpośrednich kosztów procesowych rzędu 10-15%.
Wymienione efekty ilościowe korespondują z ich jakościowymi przyczynami:
- zmniejszenie złożoności problemów projektowych dzięki podejściu systemowemu;
- przejrzystość procesów w całości i w rozbiciu na fragmenty żądanej wielkości;
- jasne zdefiniowanie celów i zakresów odpowiedzialności;
- spełnienie wymagań prawnych i rewizyjnych;
- mało redundantna dokumentacja procesowa, dostępna także dla partnerów;
- ustalenie miar pozwalających na optymalizacje procesów;
- jednolita terminologia dla wykonawców, użytkowników, klientów i dostawców.
Konsekwentne stosowanie BPM pozwala uniknąć "huśtawki" popadania w skrajności podczas kolejnych etapów projektu (rys. 2), dając szansę na systematyczne uzyskanie optimum wydajności procesów.
Wspólny język
Rys. 2 Fazy realizacji projektu na przykładzie cyklu technologicznego.
Przyjrzyjmy się bliżej wymienionym czynnikom jakościowym BPM, rozważając przykładowo ostatni z nich: jednolite nazewnictwo. Konwencje terminologiczne są doskonale znane każdemu programiście i biada temu, który ich nie stosuje. W trywialnym przypadku prowadzi to do "niekompilowalności" programu, a na poziomie wykonawczym do jego nieczytelności, nawet dla samego autora. Jednolite nazewnictwo wymuszane jest tu głównie przez słowniki i gramatyki sztucznych języków, ale także w oparciu o normatywy zespołowe. W obszarze projektowym BPM, na styku IT/użytkownicy, problem jest poważniejszy, a jego ignorowanie obniża efektywność komunikowania się w grupie, rzutując negatywnie na całość przedsięwzięcia.
Trudno jest precyzyjnie modelować, optymalizować i mierzyć coś, czego nie można precyzyjnie opisać. Problem był znany już Leibnizowi, który próbował stworzyć język uniwersalny z matematyczną gramatyką. Myśliciel wpadł zresztą sam we własnoręcznie zastawioną pułapkę, formułując "środki zaradcze przeciw wieloznaczności językowej" (Leibniz W.G., Nowe rozważania dotyczące rozumu ludzkiego, PWN, 1955). Jednym z nich miałoby być "używanie terminów zgodnie z przyjętym zwyczajem", a innym "oświadczanie, w jakim sensie bierze się słowa". Także inne postulaty Leibniza, dotyczące większej precyzji wyrażania myśli, formułowane zapewne w dobrej wierze, są równie ogólne i nieprecyzyjne, bo takowym jest często język naturalny, jakim się posługujemy.
Przykładowo: jeśli w przedsiębiorstwie używamy słowa "partia" i w związku z tym "śledzenie partii" (tracing), to można pod tym pojęciem rozumieć zarówno partię produkcyjną, jak i dostawczą. Z kolei, w samym obszarze wytwórczym ktoś może żargonowo posługiwać się oryginalnie angielskim terminem ERP "shop order", czyli "zlecenie produkcyjne", z którym wiąże się wyprodukowanie partii towaru, ale związki między tymi pojęciami nie zawsze są jednoznaczne i muszą zostać sprecyzowane w dokumentacji procesowej. W szczególności, jedno zlecenie produkcyjne może dotyczyć wielu partii produkcyjnych, jeśli to ostatnie pojęcie używane jest w znaczeniu technologicznym, związanym z parametrami linii wytwórczej (wsad). I dalej: wiele "partii produkcyjnych" może otrzymać ten sam symbol partii (Lot Code) dla wielu palet wyrobu gotowego. Owszem, standardy EAN nakazują jednoznaczne nadawanie paletom numeru SSCC (Serial Shipping Container Code), ale co zrobić, kiedy konkretny klient zechce np. ich powiązania z "partiami surowców" użytych do produkcji? Widzimy zatem, że precyzyjne opisanie wieloaspektowości jednego tylko zagadnienia procesowego, jakim jest śledzenie partii, wymaga precyzji terminologicznej.
Modelowanie warstwowe
Możemy oczywiście założyć, że kontekst dokumentacji wystarczy, aby w każdej sytuacji zidentyfikować znaczenie terminu. Można także poprosić określone osoby o komentarz, ale to wiąże się z dodatkowym czasem. Z drugiej strony, chcemy uzyskać wspomniany efekt zmniejszenia nadmiarowości opisów procesów. Warto więc zdefiniować określone konwencje terminologiczne, pozwalające na oszczędność słów bez strat precyzji przekazu. Jedną z nich jest stosowanie warstwowości w modelowaniu procesu biznesowego. Przykładowo: na najwyższym poziomie modelowania używamy liczby mnogiej, stosując konstrukcje typu "procesy produkcji"; na kolejnym, niższym poziomie, umawiamy się, że stosujemy liczbę pojedynczą, w zwrotach o postaci "proces pakowania". Wreszcie, na najniższej warstwie modelowania (tutaj w modelu trójpoziomowym) posługujemy się złożeniami czasownik+rzeczownik, np. "konfekcjonowanie wyrobów", przy czym w idealnym wariancie występujące tu pojęcia pochodzą z ich zdefiniowanego katalogu.
O czym musimy jeszcze pamiętać, aby nasz projekt zakończył się powodzeniem? Warto tu wskazać na wieloletnie statystyki projektów IT (Standish Group), pozwalające na identyfikację kilku głównych czynników sukcesu:
- Wsparcie kierownictwa (18%),
- Zaangażowanie użytkowników (16%),
- Doświadczenie wykonawców projektu (14%),
- Jasne cele biznesowe (12%),
- Minimalizacja zakresu projektu (10%),
- Inne (30%): użycie standardów informatycznych, niezmienność podstawowych wymagań, formalna metodologia, wiarygodne oszacowania.
Widzimy zatem, że jeśli tylko zdecydujemy się na projekt z zaangażowanym kierownictwem i użytkownikami oraz doświadczonymi wykonawcami (doradcami), to mamy statystyczną gwarancję ponad połowy sukcesu. Zawsze warto jednak używać standardów referencyjnych lub choćby prostych narzędzi do "samodzielnego" użytku (w przypadku mniejszych przedsięwzięć, aby minimalizować ryzyko inwestycyjne).
Do tej pory mówiliśmy o zaletach BPM - a co z wadami takiego podejścia? Minusy modelu BPM z reguły nie dotyczą jego samego, ale wadliwych metod jego stosowania, tj. syndromu BINO (BPM In Name Only), czyli modelu tylko z nazwy, tzn. wybiórczego stosowania tej strategii w odniesieniu do jej pojedynczych składników, bez głębszej analizy i zwracania uwagi na całość metodyki. W takiej sytuacji mamy do czynienia z następującymi zjawiskami:
- konieczność regularnej wymiany informacji między uczestnikami projektu prowokuje niekończące się ciągi bezproduktywnych spotkań, ograniczające ilość czasu na rzeczywiste implementacje;
- dla małych projektów, zbyt ścisłe przestrzeganie procedur referencyjnych może być bardzo pracochłonne i w takim przypadku niezbędna jest adaptacja modelu uwzględniająca lokalne realia biznesowe;
- dokumentacja, która jest nieodzowna podczas stosowania modelu referencyjnego, staje się celem samym w sobie, prowadząc nawet do niepowodzeń projektowych, wskutek przerostów biurokracji organizacyjnej (problem bardzo dużych firm).
