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".

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

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.