Najbardziej dramatyczna różnica między aplikacją BPM a aplikacją Customową....

Aplikacja BPM to funkcjonalność w całości oparta o proces BPM zdeployowany na platformie BPM.
Aplikacja Customowa to funkcjonalności w całości oparta o wybrany framework developerski.

Paradoksalnie owa różnica wynika z największej zalety BPM, jaką jest elastyczność.

Gdy piszemy aplikację customową, to następuję wyraźny rozdział pomiędzy formą a treścią.
Forma ukryta jest w kodzie, treść zapisana jest w bazie danych.
Tak osiągnięta niezależność sprawia, że można zmieniać formę bez wpływu na historyczne dane.
Dzięki czemu zmiana wynikająca ze dynamiki zakresu, czy też zmiana wynikająca z naprawy błędu,
ma niewielki wpływ na już zgromadzone dane.

Powyższa obserwacja może kłócić się z pojęciem testów regresji.

Jednak:
"Regresja – zjawisko niezamierzonej utraty jakiejś funkcjonalności powstałe w nowej wersji programu i zwykle skutkujące komunikatem o błędzie lub brakiem działania. Do regresji dochodzi wskutek wprowadzania zmian w jakiejś części kodu programu. Skutkiem tych zmian jest błędne działanie innej funkcji programu, która w poprzednich wersjach działała prawidłowo."

Zatem regresja dotyczy tylko formy.

Inaczej jest w aplikacjach BPM. Tutaj forma i treść zawarta jest w instancji procesu. Można by powiedzieć, że 200 instancji to 200 aplikacji customowych. Nawet gdy obiekt biznesowy utrzymujemy w zewnętrznej bazie danych, to kluczowe informacje BPM, czyli maszyna stanów zawarte są w instancji.

Można tego uniknąć, poprzez stosowanie krótkich procesów kartotekowych, czyli takich które sterują odczytem i zapisem w zewnętrznej bazie danych, czyli przenieść maszynę stanów poza BPM, tylko po co wtedy stosować BPM?

No i dochodzimy do wspomnianego w tytule dramatu, którym jest migrowanie instancji procesów.
Gdy używana platforma BPM tego nie oferuje, to przy każdej zmianie, stajemy przed krytyczną decyzją:

Jak dokończyć trwające instancje procesów, jak w procesie jest błąd techniczny lub biznesowy?

Mamy dwie opcje:
1. Zamykamy instancje i zmuszamy użytkowników do ponownego uruchomienia procesu w nowej wersji (wzrost czarnego PR gwarantowany)
2. Piszemy aplikację customową, która po kolei każdą instancję skopiuje do nowszej wersji procesu z użyciem API REST (lub zrobi to administrator ręcznie w ramach konserwacji)

Oczywiście Vendorzy BPM zauważyli ten problem i tworzą mechanizmy migracji, ale nie potrafią one:
1. Zmienić danych w migrowanej instancji 
2. Zmienić przebiegu w tej części instancji, która jest historyczna
3. Gubią się, gdy usuniemy lub przesuniemy zadanie, w którym oczekuje instancja

Prędzej niż później aplikacja BPM wymaga opracowania mechanizmu migracji w modelu BPM (a nie na platformie BPM), który wesprze i uzupełni wbudowane w platformę BPM mechanizmy migracji, tak by było możliwe skopiowanie instancji z jej historią, obiektem biznesowym oraz dokonanie w nich stosownych wymaganych przez nową wersję zmian.

Jeżeli tego nie zrobimy, każda zmiana stanie się koszmarem, którego i Biznes i Wykonawca będą za wszelką cenę unikać, a patos elastyczności stanie się praktycznym mitem.

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