Skróty te oznaczają odpowiednio (w j.ang): Business Process Management oraz Business Process Management Software. Budzą one wiele nieporozumień i niezrozumienia. Pierwsze to „Zarządzanie procesami biznesowymi” rozumiane jako działalność związana z zarządzaniem organizacją. Drugie to „Oprogramowanie [służące] do zarządzania procesami biznesowymi” czyli jakaś aplikacja, której wewnętrzne działanie jest opisane procesami.

Ten wpis zapewne wywoła wiele kontrowersji, gdyż opisuję tu przyczyny, dla których moim zdaniem, systemy BPMS nie tworzą wartości dodanej. Nie widzę sensu ich stosowania w wersji „process engine”, moim zdaniem nie zastąpią nawet części „typowych aplikacji”.

Ale po kolei… Niedawno po raz kolejny zostałem zapytany o… no własnie. O co?

[czytelnik]:
Panie Jarosławie,
ostatnio zdarzyło mi się przejść przez parę elementarnych pytań, które przez wielu są pomijane. Wszyscy mówią o szerokim spojrzeniu na biznes, o projektowaniu procesów, zależności pomiędzy nimi. Racja. To wszystko da się zrobić np. w Visual Paradigm. Później jednak chciałbym przejść do BPMS i powołać do życia jeden z opisanych wcześniej procesów. Jak utrzymać relację pomiędzy modelem procesów np. w Visual Paradigm, a tym co się dzieje w silnikach procesowych?

Jarosław Żeliński:
Przede wszystkim warto pamiętać, że:
– środowiskiem (kontekstem) dla modeli analitycznych procesów  (non-executable w BPMN) jest modelowana organizacja (w tym kontekście pule na modelu współpracy są organizacjami),
– środowiskiem (kontekstem) dla maszynowych modeli procesów (executable) jest serwer BPMS (tu na modelu współpracy pulami są serwery BPMS, „motory procesów”).

Powyższe powoduje, że dany model albo jest biznesowy albo maszynowy (wykonywalny). Często jest tak, że jedna firma (organizacja) ma tylko jeden serwer BPMS, ale im większa firma tym bardziej prawdopodobne, że będzie ich więcej (np. oddziałowe).

Tak więc pierwszy krok to zadeklarowanie jaki kontekst mają dane modele (ich system z dekompozycją). Jeżeli zadeklarujemy, że tworzymy modele wykonywalne, to w strukturze modeli trzeba trzymać dyscyplinę precyzji modelowania by ich eksport np. do XPDL generował poprawne pliki.

[czytelnik]:
Chodziło mi o podejście BPM (jako sposób zarządzania firmą) i o wykorzystanie narzędzi informatycznych. W narzędziach BPMS nie ma możliwości zobrazowania wielu modeli procesów oraz śledzenie zależności między nimi. Musimy to robić w innym narzędziu. Z Pana wypowiedzi wynika, że jeżeli nie wykorzystujemy żadnego innego narzędzia oprócz BPMS, to nie jest możliwe modelowanie całościowego obrazu przedsiębiorstwa. Co jeżeli klient chce wprowadzać BPM (świadomie) i zaczyna od 1,2 procesów – kończy na 50 procesach. Powinienem utrzymywać dodatkowo architekturę w VP? Czy trzymać po prostu odrębne procesy w BPMS?

Jarosław Żeliński:
Teraz (chyba) rozumiem, pozostaje podzielić to na dwa projekty (modele):
– analiza i modelowanie procesów w firmie (tu BPM rozumiany jako zarządzanie),
– wymagania na oprogramowanie worlflow (tu BPMS jak aplikacja).

Pierwsze to modele analityczne, wielopoziomowe itp.. procesów biznesowych. Drugie to diagramy przypadków użycia (UC) dla BPMS i procesowo (modele wykonywalne) opisana implementacja tych UC z użyciem BPMS.

Nie da się tego semantycznie modelować na jednym spójnym modelu procesów.

[czytelnik]:
Jeżeli chcę modelować szerszy kontekst organizacji (wiele powiązanych procesów, top-down), to muszę użyć CASE i nic innego. Czyli do wdrożenia BPM (jako stylu zarządzania firmą) muszę wykorzystać CASE (bo chcę i muszę mieć szeroki obraz). Błędem jest myślenie i pisanie o wykorzystaniu w tym celu BPMS – widziałem dziesiątki artykułów o tym, że prawdziwy BPM bez BPMS nie istnieje, że są nierozłączne. BPMS jako tworzenie konkretnej aplikacji opartej na wybranej perspektywie procesowej jest po prostu wynikiem analizy wykonanej przy użyciu CASE. Nie ma relacji ani bezpośredniego przełożenia CASE na BPMS. Można oczywiście próbować importować, exportować, ale to zawsze wiąże się z ryzykiem pogubienia informacji bądź przyrządzenia pięknego spaghetti. Sprowadza się to do tego, że aktualizacja i utrzymanie procesów w dwóch narzędziach jest bardzo pracochłonne i nikt zapewne tego nie robi:). Wizerunek CASE-owych narzędzi traci trochę uroku w tym kontekście 😉

Jarosław Żeliński:
Nie tylko moim zdaniem błędem jest utożsamianie BPM z BPMS, pierwsze to strategia wewnętrzna firmy drugie to aplikacja. Zresztą, każda aplikacja realizuje jakieś swoje wewnętrzne scenariusze, drugorzędne znaczenie ma to czy to motor BPMN czy nie… (wiele systemów BPMS korzysta z własnych, innych innych niż BPMN, notacji).

Co do uwagi o przydatności narzędzi CASE, nie zgodzę się. Jest bezpośrednia relacja BPM a BPMS: aktywności w modelach procesów organizacji (BPM) to przypadki użycia aplikacji BPMS, te są niczym innym jak „zadaniami użytkownika” w BPMN. VP radzi sobie z tym bardzo dobre, jednak wymaga to poprawnego modelu systemowego a konkretnie oddzielnego modelowania organizacji i oddzielnego aplikacji i jej wewnętrznego mechanizmu działania. To razem można „śladować” ale trzeba zbudować sobie dobry szkielet dla całości.

Tyle dyskusja. W czym problem? Najpierw po raz kolejny model warstwowy SOA:

Na najwyższym poziomie mamy modele procesów biznesowych (Business Proces, obecnie modelowane z reguły z użyciem diagramu procesów notacji BPMN i reguł biznesowych), niżej abstrakcje usług (Business Services, modelowane z użyciem przypadków użycia UML), dalej komponenty aplikacyjne (Components, obecnie modelowane z użyciem diagramu komponentów UML). Zasoby operacyjne (Operational Resources, na samym dole), obecnie modeluje się je z użyciem diagramów wdrożenia UML.

Tak więc to co nazywamy BPM, to zarządzanie organizacją. Tu modelujemy procesy biznesowe w rozumieniu „modelujemy mechanizm działania organizacji”. Część aktywności w tych procesach będzie (jest) wspierana aplikacją (jej usługami). Od tego momentu możemy, rozpoczynając od przypadków użycia, zacząć modelować aplikację (wymagania na nią) idąc przez modele dziedziny, scenariusze aż do podziału na komponenty. Możemy także wybrać inną drogę: oprogramowanie BPMS i zacząć modelować logikę wymaganej aplikacji z użyciem notacji BPMN i tak zwanych diagramów wykonywalnych. Na tych diagramach pojawią się „niskopoziomowe” zadania (skrypt, wysłane komunikatu, itp.) oraz „zadania użytkownika” (user task w BPMN), ktore są interakcją tej aplikacji z jej użytkownikiem.

Drugie podejście ma pewną wadę: absolutnie nie usuwa potrzeby napisania kodu logiki biznesowej (np. naliczenie upustu, scoring kredytobiorcy itp.) dla zadań BPMN typu „business rule”. Dlatego nie wróżę sukcesu rynkowego tego typu aplikacjom (BPMS). Stawiam raczej na dalszy rozwój typowych aplikacji biznesowych oraz systemów typu „task management” z wbudowanymi „motorami reguł biznesowych”. Niestety systemy BPMS nie zwalniają z konieczności napisania kodu logiki biznesowej i przechowywania danych, za to dodatkowo komplikują cały proces dostarczenia oprogramowania potrzebą pośredniego tworzenia wykonywalnych modeli BPMN.

Owszem można podejmować próby by pierwsze trzy warstwy SOA ująć „w jednym modelu”, jednak pojawi się problem zarządzania kontekstami (biznesowy i maszynowy) w ramach jednego modelu. Opis tego podejścia można znaleźć na blogu Bruce Silver’a:

One of the singular successes of BPM technology is a common language ? BPMN ? used both for process modeling and executable design.  At least in theory?. (Źródło: Process-Driven Applications: A New Approach to Executable BPMN – Business Process Watch)

Co do tego czy aplikacje CASE radzą sobie z tym… aplikacje te bez problemu, ale każdy projekt wymaga niestety indywidualnego podejścia.