Po co Komu BPM?

Po co Komu BPM?
Jedna błędna odpowiedź i porażka gwarantowana.

Dla zamawiającego, bo otrzyma nie to co potrzebuje, a raczej dostanie zgniłe jajo trudne w utrzymaniu i rozwoju.
Dla wykonawcy, bo projekt będzie pod wodą, a i czarny PR raczej go skreśli z listy zaufanych dostawców.

Co sprawia, że to pytanie jest pomijane ... ?
Wiedza dostawcy, z którym relacje ma zamawiający.
A także to, że odpowiedź jest nietrywialna.

Poziom entropii podnosi fakt, że BPM jest zbiorem dedykowanych do różnych funkcjonalności silników licencjonowanych na różne sposoby.

Podział historyczny:
- lekkie silniki BPM - to te w których z poziomu modelera można uruchomić proces (zaleta: szybka realizacja, wada: brak standaryzacji developementu)
- ciężkie silniki BPM - to te w których należy skompilować model i zainstalować go na silniku (zaleta: standaryzacji developementu, wada: długa realizacja)

Podział dziedzinowy (by IBM):
- human centric - procesy zorientowane na Human Taski
- document centric - procesy zorientowane na dokumenty
- integration centric - procesy zorientowane na integrację

Podział licencyjny:
- per użytkownik
- per procesor
- open source
- okresowa subskrybcja

Podział ze względu na wymagania Zamawiającego:

- zgoda na ograniczoną wydajność

- wymaganie skalowalności

- zgoda na ograniczenia platformy

- wymaganie pełnej realizacji wymagań biznesowych

- wymaganie wysokiej ergonomii formatek

- wymaganie wysokiej ergonomii skrzynki zadań

W efekcie to Zamawiający musi podjąć szereg kluczowych decyzji cząstkowych,

które na zasadzie eliminacji wskażą właściwy silnik.

Problem 1.

Trafną decyzję można podjąć wyłącznie w oparciu o istniejące doświadczenia (choć nie są one gwarancją).

Klient wybierając BPM'a nie ma jeszcze doświadczeń z BPM'a. 

Zatem musi zaufać dostawcy, w ten sposób koło się zamyka.

Wyjściem z tej patologii, mogło by być zapraszanie dostawców, którzy mają zrealizowane projekty w każdej kategorii, ale takich jeszcze w Polsce nie ma.

Problem 2 

Mimo rozwijającego się rynku BPM, nie ma takiej opcji, która spełni wszystkie potrzeby Zamawiającego, a to w prostej linii prowadzi do modelu BPM + Custom.

Niestety BPM i Custom to dwa równoległe światy, w których zarządzą zupełnie różne prawa zarządzania.

BPM to jednak już prawie świat konsultingu,

Custom to świat analityków i programistów.

Para (A+P) potraja koszt wdrożenia BPM, a konsultant jeżeli już zrobi Custom to z olbrzymim długiem technologicznym.

Odpowiedzią jest AGILE z umowy ramowej i robienie BPM przez Konsultantów a Customa przez Analityków i Programistów.

Trzymam kciuki za Zamawiających by jak najszybciej mogli tak kupować....

Co założyć by oferta była bezpieczna i nie została odrzucona przez Zamawiającego

1. 
   
   1.      Zakładamy, że wszystkie niespisane w ofercie założenia nie obligują nas do wykonania prac mających na celu ich realizację.
   2.      Zakładamy, że niniejsza oferta jest odpowiedzią na realizację wszystkich funkcjonalności określonych w zapytaniu za wyjątkiem wyspecyfikowanych w ofercie wyłączeń.
   3.      Zakładamy, że ogólny kierunek realizacji funkcjonalności biznesowych jest wyznaczony przez określoną przez zamawiającego architekturę IT. Natomiast sposób ich realizacji, jest w gestii dowolnej interpretacji, zgodnej z dobrymi praktykami Wykonawcy,
   4.      Zakładamy, że do realizacji wymagań Zamawiającego zostaną wykorzystane platformy programistyczne dedykowane do poszczególnych obszarów: OCR, BPM, BAM, BI, BD, Repozytorium dokumentów,
   5.      Do realizacji wymagań biznesowych zamawiającego Zakładamy wykorzystanie możliwości out of the box platform wchodzących w poszczególne elementy zaoferowanej architektury,
   6.      Zakładamy, że dopasowanie platform do szczegółowych wymagań zamawiającego wymagające dodatkowych rozszerzeń narzędzi, jest możliwe ale w ramach rozszerzenia zakresu i budżetu projektu,
   7.      Zakładamy, że stroną rozstrzygającą czy dana możliwość jest w danej platformie, czy też wymaga dodatkowego rozwiązania programistycznego jest Vendor danej platformy.

Zaraza, która zwie się kombinatoryka

Zwykle zamodelowany proces w narzędziu klasy BPA jest bardzo skomplikowany.

Ma bardzo dużo decyzji (więcej niż 5),
Ma bardzo dużo elementów w linii (więcej niż 5),
Ma bardzo dużo linii (więcej niź 5),
I ma bardzo mało basen (zwykle 1).

Do tego dochodzi zamęt Informatyczny w biznesowej notacji, który przybiera formę stawiania na równi z działem biznesowym nazwy systemu.
No i jeszcze kwestia notacji dla interfejsów, co wdrożenie to inaczej się to zapisuje.

Skąd to się bierze?
Według mnie jest to próba odwzorowania biznesu i jego wszystkich ścieżek alternatywnych.
Wystarczy spojrzeć na proces logowania, klasyka przypadku, w którym każdy polski programista, może udowodnić, że w BPMN nie można opisać każdego procesu.

Ale czy rzeczywiście biznes jest tak bardzo skomplikowany?
Gdyby tak było, to nawet przy darze kombinowania, w jaki obdażony jest prawie każdy Polak, ten biznes po prostu by nie działał.

Znacznie bardziej ciekawa przyczyna powyższego stanu wynika z psychologii.
Otóż istnieją dwa dobrze zbadane prawa, które tłumaczą powody, przez które komplikujemy opis codziennych praktycznych metod postępowania.

Pierwsze to prawo koleracji, według którego nieświadomie naciągamy rzeczywistość (symptomy i fakty) do jednostkowego przypadku, który nie jest dojrzały statystycznie, ale który przeżyliśmy z dużą dawką emocji. W efekcie modelujemy alternatywne ścieżki (które same w sobie są często bardziej złożone, niż ścieżka główna) dla funkcjonalności, które najprościej by było zablokować lub obsłużyć mechanizmem wyjątków biznesowych.

Drugie prawo to prawo perspektywy według, którego każdy inaczej interpretuje te same liczby, dla mnie 5 to bardzo dużo, a dla innej osoby to śmiech na sali. Ta interpretacja wynika z doświadczeń, ale nie tylko tych bezpośrednich i biznesowych, ale szeroko kontekstowych (dla osoby, która w szkole dostawała zwykle 3  i była z tej oceny zadowolona to i 4 będzie bardzo dużo).

Wracając do modelowania...
Niestety nie da się modelować symultanicznie (mam tu na myśli automatyczne odtwarzania rzeczywistości), zatem do modelowania wybierane są kluczowe osoby i to ich magię koleracji według ich indywidualnej perspektywy odtwarzamy w modelu. Naturalnie każdy taki proces będzie oderwany od biznesowej rzeczywistości.

Taki ułomny model (mimo poniesienia znaczych środków w jego wytworzenie), staje się wsadem do procesu BPM, który bezdusznie obnaża koleracje i perspektywę. Niestety robi to w  pierwszym okresie po wdrożeniu. Ocena jest oczywista: jakość procesu jest fatalna....

Dostrzegam tylko jedno sesnsowne rozwiązanie:

W ramach BPM wdrażamy tylko ścieżkę główna, cała reszta jest generycznym biznesowym wyjątkiem. Takie rozwiązanie wdrażamy na produkcję, tak by biznesowa społeczność mogła je poddać systemowej ocenie. Po krótkim okresie użytkowania zmierzymy skalę najczęstrzych wyjątków.

W ten sposób zamienimy indywidualną kolerację i perspektywę na obiektywną statystykę. To ona będzie definiować priorytety i kolejne przyrosty lub sprinty dalszych prac.

Biznesowy sprzeciw
Naturalny jest opór i sprzeciw użytkowników biznesowych. Wynika on z odkrycia biznesowych patologii i powiedzeniu "nie" dla ich implementacji  (gdybyśmy zrobili ścieżki alternatywne, to reaktywnie byśmy się na to zgodzili).

Do wyboru mamy jednak dwie opcje:
1. Konflikt na początku projektu, który grozi nam wykluczeniem.
2. Zgodę na patologię i kiepski PR na końcu projektu, który grozi nam wyłączeniem naszego rozwiązania.

Ja wybieram opcję 1. Zdrowy sens zawszę prędzej czy później wypłynie na wierzch.

A i jeszcze jedno, wygrać tą batalię może tylko ta osoba, która wierzy w to o co walczy ...

BPM chyba jest jednak BI'em

BPM potrafi zmierzyć tylko dwa rodzaje KPI:
- ilościowe, czyli jest w stanie na bieżąco podawać liczby wystąpień danych kroków
- czasowe, czyli jest w stanie na bieżąco podawać czasy realizacji human tasków
oczywiście, zwykle jest w stanie zrobić to rozbiciu na używaną strukturę operacyjną.

Co to oznacza?

Nie dowiemy się na jaką kwotę opiewają przyjęte faktury, w procesie kancelaryjnym.
Nie dowiemy się ile dni nieobecności ma dany pracownik, w procesie inwestycyjnym.
Nie dowiemy się jaka jest bieżąca wartość realizowanych inwestycji, w procesie zarządzania majątkiem.
Etc ...

Problem polega na tym, że organizacja zamawiając proces kupuje coś więcej niż tylko opanowanie, ogarnięcie czy też optymalizację aktywności biznesowej.

Kupując BPM kupuje dostęp do wyników.
Czyli, prędzej czy później skończy się na raportach.

Wygląda na to, że wdrażając silnik BPM warto od razu zrzucać obiekt biznesowy przy każdej zmianie stanu do zewnętrznej bazy danych, a do niej podłączyć silnik BI, tak by móc tworzyć dynamiczne raporty.

Tworzenie raportów w BPM jest dużym customem i kończy się ograniczeniem możliwości analitycznych.

Jeżeli powyższy obraz rozszerzymy o repozytorium dokumentów z BPM zaczyna się tworzyć złożona architektura.

Może to jest powodem, że BPM z trudem się przebija, a nawet jak mu się uda to ma tak liczne nawroty do aplikacji silosowych, w których wszystko można oprogramować w jednym miejscu.

Pierwszorzędnie drugorzędna rola BPM

Rozwiązania BPM muszą zapłacić słoną cenę za wejście i zadomowienie się w architekturach IT.

Taką samą cenę zapłaciły platformy dziedzinowe (ERP, CRM, etc...).

Chodzi o to, że zanim procesy BPM, zajmą należną im rolę, czyli staną się sposobem na spinanie i sterowanie rdzeniowymi procesami przechodzącymi przez całą organizację, muszą udowodnić swoją przydatność.

A mogą to zrobić jedynie poprzez tzw księgi pomocnicze, czyli aplikacje które rozszerzają rozwiązania platformowe lub zastępują niekoszerne funkcjonalności. Zwykle są odpowiedzią na model licencjonowania, ciężkiego klienta, czy duży koszt dopasowania platformy.

Bycie księgą pomocniczą sprawia jednak, że to w procesie BPM objawiają się błędy, wynikające z:

• biznesowych patologii rozwiązania z platformy,
• słabej lub braku procedury zarządzania zmianą,
• głuchego telefonu pomiędzy biznesem - IT - dostawcy platform - dostawca BPM,
• braku stabilności rozwiązań integracyjnych,
• słabości mechanizmów testowania.

Zatem na dostawcy BPM spoczywa obowiązek wytworzenia procesów ale też (może nawet zwłaszcza też) koordynowanie całej edycji zmiany.

Problem w tym, że o ile rola integratora jest już powszechna i znana,
to rola integratora BPM, to ciągle nowość, w dodatku nowość taka, która na pierwszy rzut oka jest niepotrzebna.

Wystarczy zapytać się dowolnego biznesu, czy diagram BPMN stworzony na warsztatach analitycznych jest  kompletny, czyli:
- zawiera wszystkie ścieżki?
- obejmuje wszystkie obiekty biznesowe?
- zawiera docelowy proces?

Odpowiedź jest oczywista TAK i 3xTAK.

Podczas gdy biznes (i konsultanci BPA) wpadają w zakłopotanie, po uszczegóławiających pytaniach:
- czy model zawiera ścieżki: główną, krytyczne, alternatywne i przechwytywanie wyjątków biznesowych?
- czy model opisuje atrybuty obiektów biznesowych, ma obiekt kierowania procesem i definiuje mapowanie na obiekty zewnętrzne?
- czy model opisuje stan TOBE? Jeżeli tak to jakim cudem, jeżeli na ten moment dostępna jest tylko subiektywna wiedza wybranych użytkowników (nie ma danych statystycznych)?

BPM z perspektywy użytkownika wygląda zupełnie inaczej!

BPM z perspektywy użytkownika wygląda zupełnie inaczej!

Zacząłem tworzyć na własne potrzeby procesy BPM.

Po uzyskaniu pewnej płynności wytwórczej,
czyli opanowaniu platformy na tyle by się nie douczać w trakcie realizacji,
mogę wdrażać całkiem złożone potrzeby w kilka godzin.

Dzięki temu konsekwentnie przestaje używać Excela do zarządzania pracą.
W BPM staje się to znacznie łatwiejsze.

To jednak pozwala mi doświadczyć tego co doświadcza użytkownik dla własnego biznesowego procesu.
Tak, żadne testy nie oddadzą realnej pracy i to takiej od której zależą decyzje w realnym świecie.

Z przerażaniem odkryłem,
że dla użytkownika cała BPM'owa wartość dodana (modelowanie, konfiguracja, środowiska, elastyczność, etc...) jest bezużyteczna i niezauważalna, jeżeli nie może on zrealizować ścieżki głównej dla swojej potrzeby.

Do tego pojawiają się "strachy", wynikające z doświadczenia z BPM:
- może się nie dać zmigrować danych do nowej wersji procesu (a te są liczne, choć drobne)
- nie wiadomo co się będzie działo w następnym tasku (diagram BPMN jest kompletnie niezrozumiały, pokazuje tylko czubek góry lodowej, a cały sens i tak dzieje się wewnątrz tasków).

No i na koniec pojawia się poczucie bezsensu: "Zaraz ..., przecież to miało mi pomóc..., tymczasem wprowadza dodatkową biurokrację i masę ograniczeń..., po co mi to?"

PS:
Ja cały czas jestem entuzjastą BPM, należy jednak pomyśleć jak zmniejszyć powyższe negatywne emocje lub jak zamienić je pozytywną energię do działania, ale to już zupełnie inna bajka...

Ciężar ścieżek alternatywnych

W trakcie tworzenia funkcjonalności procesowych,
istnieje wielka pokusa by zrobić proces dobrze,
czyli obsłużyć wszystkie możliwe przypadki,
ułatwić wprowadzanie informacji na wszystkie możliwe sposoby,
zoptymalizować dane do co najmniej 3 postaci normalnej,
zadbać o wszelkie możliwe wyjątki techniczne
i ująć wszystkie możliwe komponenty (silnik BPM, silnik BI, silnik DMS, silnik RR, ESB).

Problem tkwi w tym,
że im więcej z powyższego zrobimy,
to tym więcej artefaktów będziemy mieli do zmiany,
jeżeli będzie zmiana biznesowa.

Zmiany biznesowe wynikają
z kreatywności i twórczości,
jaka jest wzbudzana,
w trakcie pracy w uporządkowanych założeniach,
które są wynikiem automatyzacji przebiegu pracy.

Jest tak, bo już nie trzeba używać wyobraźni,
by zdefiniować jak ma działać biznes,
bo widać braki, patologie i utrudnienia.

Kluczem jest zupełnie inna kolejność niż przy podejściu do aplikacji silosowych.

Poziomy implementacji BPM

W jednym z moich pierwszych projektów BPM kierownikiem był fan wzorców projektowych w obszarze dobrego programowania.

Jednym z głównych założeń dobrego kodu jest wytwarzania kawałków funkcjonalnych, tak by miały zakodowane wszystkie docelowe mechanizmy.

W efekcie gdy mieliśmy ok 40% funkcjonalności biznesowych, które zostały dobrze oprogramowane, skończył się czas i budżet. Niestety bez brakujących 60% cały proces nie zadziałał (KP, jeżeli to czytasz to przepraszam Cię za sarkazm).

Problem polega na tym, że jak zwykle musieliśmy jak najszybciej i jak najtaniej zrealizować te braki (tak pominęliśmy zasady dobrego programowania).

No i te 60% funkcjonalności cały czas generuje błędy i sprawia, że rozwiązanie jest bardzo niestabilne.

Gdzie został popełniony błąd.

Otóż w rozwiązaniach BPM istnieje macierz funkcjonalności, poziomo są funkcjonalności biznesowo pionowo funkcjonalności technologiczne.

W ramach danego sprintu powinniśmy określić, które kwadraty będziemy realizować, a każdy kwadrat powinien być objęty zasadami dobrego programowania.

Uwaga, kolejność jest nieprzypadkowa, choć w zależności od priorytetów może ulec zamianie!

Oto funkcjonalności biznesowe (wiersze):
1. Ścieżka główna
2. Wyjątki główne
3. Ścieżki krytyczne
4. Wyjątki krytyczne
5. Ścieżki alternatywne
6. Wyjątki niezidentyfikowane


Oto funkcjonalności technologiczne (kolumny):
1. Obsługa struktury operacyjnej
2. Kierowanie procesem
3. Obiekt biznesowy
4. Obiekt kierowania procesem
5. Wsparcie diagnozy patologii
6. Wsparcie konserwacji środowiska produkcyjnego
7. Testy automatyczne
8. Wsparcie migracji instancji
9. Wsparcie wznawiania procesów
10. Przygotowanie danych BI
11. Raportowanie jakościowe i strategiczne
12. Raportowanie ilościowe i operacyjne
13. BAM
14. Archiwum dokumentów

Dla przykładu zrobienie ścieżki głównej z 14 funkcjonalnościami technologicznymi, sprawi że biznes zapomni o tym, że dla niego realizujemy projekt.

Proces BPM, a polska kombinatoryka

Nie wnikam, w to dlaczego tak jest, ale polski biznes cechuje duży poziom kombinatoryki.

Z pewnością wielu menadżerów uznaję ją za coś co trzeba zwalczać, jednak ona pozwala nam szybko reagować na zmieniający się kontekst biznesowy.

Proces BPM zamraża ścieżki główne, krytyczne a także definiuje katalog ścieżek alternatywnych. Zatem wydawałoby się, że kombinatoryka została opanowana. 

Niestety obietnice elastyczności rozwiązań BPM nie spełniają się w naszym kraju, bo:

- procesy są skomplikowane, a wynika to z próby opisania naszej kombinatoryki

- w takich procesach instancje są niemigrowalne

- cały czas mamy problem z architekturą i bardzo często wykorzystujemy BPM do analityki strategicznej (raportowanie)

Wszystko powyższe sprawia, że drobna zmiana ciągnie się tygodniami i trwa dłużej niż zmiana w aplikacji silosowej.

Co więcej na koniec dnia okazuje się, że kombinatoryka jest w stanie przebić się przez BPM. Jeżeli może to używa do tego powrotu w wyjątkowych sytuacjach do Excella i papieru, a jeżeli jest to zakazana używa administratorów IT do zmian danych w procesach z użyciem API REST lub bezpośredniej zmiany w bazie BPM.

Od strony technologicznej to tykająca bomba.

Może jednak warto zawrzeć pokój z kombinatoryką, a można to zrobić za pomocą następujących założeń:

1. Po każdym HT i kroku wyliczeniowym ustawiamy task systemowy, w którym zrzucamy obiekt biznesowy do dedykowanej dla procesu struktury w pomocniczej bazie danych.

2. Budujemy mechanizm automatycznych testów, w którym każdy HT i krok wyliczeniowy jest zrównoleglony i pobiera on dane z bazy dla danego kroku dla wskazanego procesu (wcześniej zapisanego przez mechanizm z kroku 1)

W ten sposób otrzymujemy możliwość automatycznego testowania, automatycznego doprowadzania procesu do określonego kroku oraz możliwość sklonowania procesu (i odwzorowania w bazie kombinatoryki).

W ten sposób na jednym ogniu pieczemy, aż trzy pieczenie:

1. Automatyczne testy

2. Zbieranie danych dla zewnętrznego BI

3. Wznawianie procesów wzbogaconych kombinatoryką

Warto jest dodać więcej zadań systemowych…