Narzędzia zarządzania procesowego

Data: 2019-12-10
Autor: Sebastian Konkol
Narzędzia zarządzania procesowego

W prostych skojarzeniach, zarządzanie procesowe = BPMS, wydawałoby się, temat znany i ograny. Wydawałoby się. Wpadłem ostatnio w środek dość już „nabrzmiałego wyzwaniami” projektu wyboru „platformy BPMS”. Projekt przeprowadził RFI, RFP i nadal nie było wiadomo, co wybrać. Pierwsza diagnoza polegała na tym, że pomylone zostały pakiety komercyjnych środowisk z BPMS w nazwie, z koncepcjami narzędzi zarządzania procesowego. To pomieszanie doprowadziło do serii nieporozumień, kilku awantur i braku decyzji. Ale udało się wyprostować, a przepis na to poniżej.

Do wyprostowania doprowadziło pokazanie, że zadanie wsparcia zarządzania procesowego ma co najmniej trzy kluczowe składowe: używane „narzędzia”, koncepcje zarządzania procesowego, różne perspektywy spojrzenia na działalność zarządzania procesowego oraz UX środowiska pracy użytkowników.

Wyjaśnienie tych zawiłości to podróż wehikułem czasu. Pierwsze produkcyjne narzędzia zarządzania procesowego zaczęły być użytkowane w latach 80-tych i 90-tych ubiegłego wieku. Opierały się one o koncepcje Worflow & Workforce Management (W&WfM), której esencja polegała na – infantylnej z perspektywy czasu – informatyzacji, czyli przeniesieniu do komputera sposobu działania ludzi. Ówczesne zasady współpracy ludzi opierały się na tym, że praca była wykonywana na konkretnych stanowiskach przez konkretnych ludzi, a żeby ktoś coś zrobił trzeba było o to go poprosić, zwykle pisząc jakiś dokument. W efekcie przeniesienia tego świata do komputera mieliśmy systemy, których celem było zapewnienie przekazywania dokumentów (nośnik zlecenia pracy, nośnik raportu wykonania pracy) między ludźmi (jednostka wykonywania pracy) lub grupami ludzi (zarządzanie wieloma stanowiskami o takich samych możliwościach wykonania pracy). Każdy wykonawca miał więc „w systemie” skrzynkę zadań do wykonania i skrzynkę zadań wykonanych. System informatyczny pełnił zadania przenoszenia dokumentów pomiędzy stanowiskami pracy – w tym znaczeniu wypierał posłańców i pocztę pneumatyczną. I nic więcej. W dzisiejszych warunkach „czysty” system W&WfM byłby niesprzedawalny.

Po okresie fascynacji automatyzacją posłańca, czyli gdzieś w połowie lat 90-tych, ktoś przyznał, że fajnie jest kontrolować przepływ prac, ale jeszcze fajniej byłoby kontrolować proces (w znaczeniu end-to-end). Karierę zaczęły więc robić koncepcje Business Process Management (BPM) i Business Process Reingeneering. Rynek szybko dostrzegł potencjał „upgrade’u” platform W&WfM do BPMS i wypełnił ją ściśle. I jakoś nie działało, a przedsięwzięcia reinżynierii procesów biznesowych należały do grupy najbardziej nieudanych (chyba nawet częściej, niż CRM). Kilka lat minęło, zanim do świadomości dotarły fakty. Proces bowiem a proces to zupełnie inne sprawy. Z punktu widzenia analityka biznesowego proces to bardziej lub mniej złożony graf kroków – zadań dla człowieka, wykonywanych automatycznie, decyzji, sterowania – zaczynający się i kończący. Implementacja tego operacyjnie jest dobra dla pojedynczych procesów, ale kiedy jest ich więcej, bezpośrednie przeniesienie procesu opisanego z punktu widzenia analityka biznesowego do działania operacyjnego skutkuje wywrotką – operacyjnie ludzie nie wiedzieliby czym się zająć, a żaden menedżer nie byłby w stanie ustalić, co nie działa. No właśnie, bo – poza punktem widzenia analityka biznesowego i uczestnika procesu – ważna jest perspektywa menedżera. A ta perspektywa to właśnie potrzeba rozumienia co i dlaczego nie działa – na tle zagregowanego, znacząco uproszczonego modelu procesu. Mamy więc przynajmniej trzy punkt widzenia na każdy proces. Pakiety BPMS były później uzupełniane o Business Activity Monitoring (BAM), wypełniając podstawowe potrzeby menedżerów operacyjnych, ale to także nie wystarczało.

Prawda jest bowiem taka, że jednorodna implementacja procesu end-to-end jest w większości przypadków fikcją, gdyż – od wielu już lat – poszczególne systemy zintegrowane (np. klas ERP, CRM, WMS, CC) implementują jakieś procesy, które po prostu są segmentami procesów end-to-end. Nie bez znaczenia jest także możne skupianie się na użyteczności aplikacji (UX) i minimalizacji liczby aplikacji, w których użytkownicy pracują (a raczej ich konsolidacji w intranetowych środowiskach webowych). Z tych dwóch powodów BPMS to Rule Them All to utopia. Po pierwsze trzeba oddzielić zagadnienia zarządzania procesowego od zagadnień interakcji użytkownika ze środowiskiem informatycznym i rozwiązywać te zagadnienia świadomie oddzielając je. Po drugie podstawową metodą organizacji pracy na poziomie implementacji w środowisku informatycznym opiera się na platformach orkiestracji procesów (słowo kluczowe to BPEL), a nie na platformie procesowej end-to-end (osławiony już BPMN).

Ale to jeszcze nie koniec podróży w czasie, bo właśnie docieramy do współczesności. Szybkość zmian otoczenia działania firmy, a przez to i każdej jej jednostki organizacyjnej, zwiększa się tak znacząco, że utrzymanie zarządzania procesowego w trybie operacyjnym w oparciu o procesy end-to-end staje się zbyt kosztowną ekstrawagancją. W praktyce jest tak, że utrzymywany jest pozór zarządzania procesami end-to-end, ale są one nieaktualne już w momencie ich publikacji i nikt się tym nie przejmuje. Dzisiejsze zarządzanie procesowe – to praktykowane, nie zaś oficjalnie głoszone – opiera się na określaniu reguł obowiązujących globalnie lub w danym miejscu organizacji. Podstawowa zaleta reguły jest taka, że jest ona jasna, przejrzysta i zrozumiała. Menedżerowie określają reguły i akceptują, że ostateczna postać procesu „wyłoni się” w efekcie działania reguł. Taką postać wyłaniającego się procesu obserwują na podstawie objawów (dokładnie tak samo, jak w przypadku teoretycznych procesów end-to-end) i wnioskują o zmianie reguł. Na szczęście informatyka dostarcza platform do realizacji takiego spojrzenia na zarządzanie procesowe: Business Rules Management (BRM) dla implementacji reguł i BAM dla nadzoru „objawów” stosowania reguł. Ergo, na dziś zarządzanie procesowe w organizacji to orkiestracja procesów, operacyjne działanie na regułach (BRM, CEP) oraz nadzór efektów (BAM).

Zagadnieniem komplementarnym do powyższego jest portfelowe zarządzanie aplikacjami (minimalizacja aplikacji dla jednego użytkownika i konsolidacja funkcji w pojedynczym środowisku interakcji użytkownika z systemami informatycznymi). Tu także przejawia się „myślenie pakietami oprogramowania” zamiast dojścia do sedna zagadnienia, którym jest po prostu spójne, pojedyncze środowisko działania użytkowników systemów informatycznych. Pomijając przypadki „obiegu faktur” czy „zatwierdzenia wniosku urlopowego”, niezwykle rzadko mamy do czynienia z „czystą” aplikacją procesową. Najczęściej aplikacja wymaga całkiem złożonych struktur danych, dokumentów, komunikacji i kilku innych grup funkcji, pośród których „jedną z” jest zdolność poddania jakiegoś obiektu w aplikacji z zarządzaniu procesowemu. Decyzja o oparciu implementacji obiektów podlegających zarządzaniu procesowemu środowisku BPMS jest równoznaczne z decyzją o drastycznym ograniczeniu wachlarza środków informatycznych wykorzystywanych dla implementacji.

Teraz możemy wreszcie wrócić do pakietów oprogramowania i przeprowadzania różnych wyborów. Prawda, że inaczej wyglądają teraz wymagania na takie środowisko? W mojej ocenie rozwiązanie takiego zagadnienia wcale nie jest tematem znanym i ogranym, a wręcz wymaga chyba nowego otwarcia. A najważniejsze jest wcale nie to, czym technicznie chcemy się posługiwać – ważne jest to, w jakich kategoriach prawdziwy biznes (nie analityk biznesowy) opowiada o potrzebach zarządzania. To jest bowiem właśnie formuła oczekiwanego zarządzania działalnością organizacji, do której szybkiego i efektywnego wdrażania trzeba być przygotowanym.

komentarze 2 dla

  1. Rafał pisze:

    Sebastian,
    Może – nie wiem czy na pewno, ale może właśnie jeśli mielibyście w tej inicjatywie analityka biznesowego – a wiem, że go w tej inicjatywie nie było to prace mogłyby przebiegać inaczej tj. sprawniej z określonym celem i zakresem pozyskanym z biznesu. Reprezentantów prawdziwego biznesu, o których piszesz w tym przedsięwzięciu też za wielu nie było.
    Ale potwierdzam, to reprezentant biznesu powinien decydować w jaki sposób chce prowadzić swój biznes, a każdy ze wsparcia biznesu powinien rozumieć gdzie może pomóc a nie przeszkadzać.
    Pozdrawiam

  2. Dzięki za komentarz!

    W tym projekcie było kilka wyników analiz biznesowych i wcale to nie pomogło, a powiedziałbym, że wręcz przeciwnie – nic nie było możliwe do zdecydowania, dokąd projekt opierał się literalnie na wynikach analiz i posiadanych wymaganiach. “Przełom” nastąpił wtedy, kiedy zaczęliśmy operować narzędziami syntezy, a nie analizy – szukaliśmy wzorców, schematów i właściwego kojarzenia koncepcji.

    Patrząc szerzej na to doświadczenie, biznesowi trzeba pomóc zrozumieć (a czasami poprawnie zidentyfikować) problem do rozwiązania, pokazać przestrzeń rozwiązań i nauczyć nowych pojęć, naprowadzić na możliwości, prawdopodobnie w kilku wspólnych z nim przejściach przez te same obszary. Taka działalność, bo to już chyba nie analiza biznesowa, niesie znaczącą wartość i realną pomoc. I zdaję sobie doskonale sprawę, że to kosztuje znacznie więcej wysiłku, niż narysowanie procesu i spisanie wymagań “na system”.

    Tak próbuję sobie wyobrazić, jak wyglądałaby praca analityka biznesowego w takim projekcie. Wszak nie chodziło tu o narysowanie konkretnych procesów, ale o “jeden poziom meta wyżej”. W jaki sposób analityk biznesowy w takim projekcie mógłby pomóc w ustaleniu z biznesem jakimi narzędziami zarządzania procesowego biznes chciałby się posługiwać? Bo moim zdaniem uzyskać mógłby tylko odpowiedź “wszystkimi”. ;-)

Pozostaw komentarz