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.

Należy stwierdzić jedną rzecz: moim zdaniem panuje straszny bałagan pojęciowy wywołany tym, że mamy do czynienia niestety z modą na procesy i wielu producentów aplikacji ma ambicję użyć magicznej sekwencji słów “business process management” nawet, jeżeli to nie ma sensu.

W czym problem?

Po pierwsze proces biznesowych to sekwencja zdarzeń (czynności) w firmie a nie w systemie IT. System co najwyżej może pomagać je śledzić i kontrolować. Po drugie: nie należy mylić trzech rzeczy: modelowania, zarządzania i informatycznego wspomagania procesów biznesowych.

Modelowanie lub mapowanie procesów: polega na stworzeniu np. w postaci diagramów (można także je opisać tekstem) dokumentacji procesów w firmie t.j. graficznej reprezentacji w celu utrwalenia ich na papierze. Zarządzanie procesami: to stałe śledzenie modelu procesowego firmy i ulepszanie go tak by firma postępująca zgodnie z tym modelem możliwie najefektywniej realizowała swoją strategię rozwoju. Informatyczne wspomaganie procesów biznesowych to po prostu wykorzystywanie narzędzi wspierających powyższe procesy.

Na rynku, niezależnie od tego jak same się określają, mamy do czynienia z rozwiązaniami wspomagającymi modelowanie procesów i zarządzanie procesami, są to takie pakiety jak MS Visio, iGrafx, ARIS i wiele innych. Pakiety takie jak Ultimus czy FileNet to systemy zarządzania obiegiem informacji (w tym dokumentów) w firmach, choć same o sobie często mówią, że zarządzają procesami biznesowymi.

Pamiętajmy, że proces to czynności a nie papier ani jego elektroniczna reprezentacja. Dokument lub plik, rekord bazy danych to co najwyżej “namacalne” produkty procesów.

Zintegrowane systemy informatyczne coraz częściej mają w nazwie słowa “zorientowane procesowo” lub “zorientowane na procesy”. To już bliższe prawdy stwierdzenia, gdyż są one właśnie tak zbudowane by implementacja systemu polegała niemalże wprost na “przepisaniu” do nich modeli procesowych (map procesów).

Tak więc zorientowane na procesy są: Ultimus, FileNet, SAP BusinessOne i inne. Wdrożenie tych systemów polega (w dużym uproszczeniu) na “wpisaniu” do nich map procesów.  Po tej czynności system taki jest dopasowany do stylu pracy firmy. Różnica między nimi polega np. na tym, ża system SAP to system ERPII, FileNet to system typu “document flow management” itp. czyli każdy z nich wspiera nieco inny obszar pracy w firmie.

A gdzie systemy typu IBM WebSphere czy BizTalk? To są systemy będące w pewnym sensie “generatorem aplikacji”. Mając model procesowy firmy można go “ucieleśnić” właśnie z pomocą jednego z tych (są jeszcze inne) systemów. Systemy tego typu są też używane jako narzędzie do integracji innych systemów. W takim przypadku spełniają rolę systemów midlleware. Dlaczego? Systemy takie to motory aplikacyjne. Zdefiniowane procesy “ubierają” w ciało w ten sposób, że definiuje się proces (regułę), dane wejściowe i ich źródło, dane wyjściowe i ich cel. Jak widać definicja bardzo ogólna ale tak to właśnie wygląda.

Jak nie trudno się domyślić mam dużo do powiedzenia po konferencji o procesach biznesowych 🙂

Tym razem będzie to zestaw “dygresji”, postaram się by stanowiły spójną całość. Nie zastąpi to co prawda Państwu obecności na takich konferencjach ale pozwoli za to uzupełnić wiedzę, o rzeczy, których na nich nie powiedziano wprost lub w ogóle.

Nie było mowy o procesach biznesowych w kontekście biznesu, tylko firma Andersen Business Consulting zauważyła, że są jeszcze na świecie nasi klienci i dostawcy. Otóż generalne moje spostrzeżenie: prelegenci mówili o procesach biznesowych w kontekście narzędzi informatycznych (programów) do ich modelowania, symulacji, optymalizacji. Nie znalazłem żadnej prezentacji na temat stylistyki modelowania, kontekstu biznesowego i otoczenia.  Ku mojemu zaskoczeniu byłem chyba jedyną osobą, która w kwestii modelowania zauważyła istnienie nadrzędnego łańcucha wartości. Po drugie modelowanie to sztuka osoby modelującej a nie stopień skomplikowania programu wspierającego modelowanie. To tak jak by na kongresie malarstwa nowożytnego mówiono tylko o farbkach i pędzelkach.

Okazuje się, że użytkownikami narzędzi do modelowania są głównie konsultanci a nie pracownicy firm. Dlaczego?  Hm.. to jest dla mnie tajemnica ale jako zwolennik godzenia się z faktami uważam, że czas jest taki, że konsultanci mają do spełnienia także misje edukacyjną. I to nie dlatego, że biznes się nie uczy ale dlatego, że biznes musi mieć najpierw od kogo się uczyć. Jako konsultant zrobię więc co w mojej mocy by i tej roli sprostać. Po drugie narzędzia tego rodzaju są często narzędziami do wyprodukowania setek stron schematów. Jak zauważył to jeden z prelegentów, przedstawiciel biznesu, prawie nikt tego i tak nie rozumie i nie czyta. Dlatego nie taki model jest dobry, który jest szczegółowy aż do bólu. Dobry model to taki, który jest czytany przez kadrę i  rozumiany przez nią. Dlatego nie 500 stron a 50 poprosimy. Ale proszę Państwa, to wcale nie znaczy że wykonanie takiego modelu trwa krócej!

Mam dziwne przeczucie, że w ciągu kilku najbliższych lat na rynku zostaną narzędzia do wspomagania modelowania na poziomie biznesowym oraz dojrzałe systemy bazujące na procesowych fundamentach.  Systemy typu BPMS  (Business Process Management System) produkujące dziesiątki stron diagramów znikną. Jednym z głównych problemów wskazywanych na salach był obecny brak kompatybilności pomiędzy systemami do modelowania procesów a aplikacjami o strukturze procesowej. Czy tu pojawią się jakieś standardy? Nie sadzę, gdyż właśnie różnice między producentami tych systemów budują ich przewagę konkurencyjną (jestem lepszy bo odróżniam się od konkurencji czymś dobrym). Konsolidacja na tym rynku moim zdaniem nie będzie polegała na wzajemnym przejmowaniu się firm oferujących produkty typu BPMS a na przejmowaniu  dostawców BPMS przez dostawców systemów ERP, SCM, CRM, WfM (Workflow Management) itp. i tworzeniu kompletnych środowisk do modelowania i implementacji procesów biznesowych w postaci zintegrowanych systemów np. ERPII.

Problem z wdrożeniami BPM i systemów zintegrowanych np. typu ERP polega na próbie wmuszenia w organizacji nowego zwyczaju (procesowego podejścia) bez wcześniejszego procesu edukacji tych pracowników. Oni (pracownicy) przy całej swojej dobrej woli często nie widzą kontekstu swojej pracy na tle reszty  firmy dlatego nie przyjmują działań, których nie rozumieją. Rozpoczęcie wdrożenia systemu ERP bez przeprowadzenia edukacji wśród kadry i ewentualnie reorganizacji na ich własna prośbę (a to się udaje) z góry skazane jest na klęskę lub poważne trudności. Sposobem uniknięcia tego jest wdrożenie metod zarządzania zorientowanych na procesy a dopiero potem wdrażanie jakiegokolwiek systemu bazującego na procesach biznesowych. Proponuje zacząć od zdefiniowania i wdrożenia śledzenia mierników pracy w każdym punkcie współpracy (wymiany efektów pracy) pomiędzy komórkami organizacyjnymi w firmie. To się sprawdza!

Moja metoda modelowania i wdrażania systemu zorientowanego na procesy:

• skupić się na metodzie top-down (od ogółu do szczegółu, z góry w dół firmy): modelować firmę od góry, w trakcie modelowania przyporządkowywać zasoby do każdego procesu, po zakończeniu modelowania sprawdzić czy i jakie zasoby (komórki organizacyjne) nam “zostały”,
• Jeżeli cos “zostało” należy zidentyfikować przyczynę i doprowadzić do sytuacji gdzie nie ma “niepotrzebnych zasobów”,
• Otrzymany model zoptymalizować
• Zdefiniować “produkty” i “zamówienia” na wejściach i wyjściach procesów, zdefiniować ich miary,
• Wprowadzić etapami w życie tak opisany model,

Teraz można zacząć wdrażać procesowo zorientowane systemy IT bez ryzyka, że nikt ich tak na prawdę nie chce.