PRZEBIEGI PROCESÓW BIZNESOWYCH

WPROWADZENIE

Opisywanie przebiegi procesów biznesowych stanowi fundament analizy biznesowej w metodyce OMNIS. Przebiegi procesów biznesowych są bowiem techniką, którą przede wszystkim wykorzystuje się do usprawniania procesów w organizacji a patrząc szerzej – do poprawy wykonania (ang. performance management). Procesy biznesowe w naszej metodyce stanowią także kontekst dla specyfikowania reguł biznesowych, reguł decyzyjnych oraz wymagań wobec IT. 

Metodyka OMNIS w zakresie usprawniania procesów biznesowych bazuje na zaleceniach podejścia popularyzowanego przez Geary’ego Rummlera.  W podejściu tym, punktem wyjścia są aktualne procesy oraz zidentyfikowane problemy (tzw. punkty nieciągłości, ang. disconnect). Na podstawie znajomości problemów oraz technik usuwania ich przyczyn źródłowych powstają docelowe przebiegi procesów. W przypadku metodyki OMNIS, przebiegi procesów są tworzone zgodnie z określoną „filozofią” z wykorzystaniem notacji BPMN.

Ostro zdefiniowane w ramach architektury procesów biznesowych granice procesów w dużym stopniu przyczyniają się do ułatwienia konstruowania opisów ich przebiegów. W praktyce, zaobserwować to można między innymi podczas dyskusji odnośnie: zdarzeń rozpoczynających proces biznesowy, zasadności umieszczania określonych działań w ramach danego procesu czy też momentu, w którym proces należy uznać za zakończony. Przyjęta w metodyce OMNIS interpretacja procesów i tworzenia ich architektury, pochodząca wprost z prac Martyna Ould’a, znajduje kontynuację w interpretacji uczestników procesów biznesowych, umieszczanych na przebiegach procesów biznesowych. Podobnie jak to miało miejsce w przypadku architektury procesów biznesowych, w ramach prac nad metodyką dostosowaliśmy notację BPMN do wspomnianej interpretacji, wprowadzając określone stereotypy, metki oraz konwencje. Przykłady takich konwencji prezentuje poniższy rysunek, zawierający fragment opisu przebiegu procesu biznesowego. Pierwszą rzeczą, która rzuca się w oczy praktykom BPMN jest wykorzystanie wielu basenów (ang. pool) w ramach opisu przebiegu jednego procesu biznesowego przy jednoczesnym braku torów (ang. lane). Podejście takie jest bezpośrednim efektem postrzegania procesu biznesowego jako zestawu działań realizowanych przez niezależnie od siebie funkcjonujące role, wymieniające między sobą komunikaty w celu koordynacji prac. Przy tego typu podejściu nieistotne jest, czy komunikacja odbywa się wewnątrz procesu czy pomiędzy procesami – w każdym przypadku sprowadza się ona do wymiany komunikatów pomiędzy rolami.

Przykład komunikacji wewnętrznej pomiędzy rolami procesu prezentuje poniższy diagram. Dwie role: Spedytor oraz Pakowacz komunikują się ze sobą poprzez wysłanie komunikatu (w rzeczywistości mogą to być na przykład mejl, telefon). 

Przykład tego typu sytuacji prezentuje rysunek powyżej, na którym Kierownik zmiany, reprezentujący jeden proces, komunikuje się z Pakowaczem, uczestniczącym w realizacji drugiego procesu, będącego przedmiotem diagramu. Charakter komunikacji nakazuje reprezentowanie Kierownika zmiany w formie czarnej skrzynki (ang. black box); szczegóły jego działań będą opisane na diagramie prezentującym przebieg procesu, w którego realizacji uczestniczy.

Podane powyżej przykłady konwencji dostosowujących standardy do potrzeb procesów wytwórczych mogłyby być interpretowane jako argument przeciwko standardom – z uwagi na brak bezpośredniego wsparcia językowego dla określonego rodzaju sytuacji – albo procesom wytwórczym, w których wykorzystano elementy nieopisane żadnymi standardami. Dotychczasowe doświadczenie firmy AION w dostosowywaniu dostępnych języków do potrzeb metodyki nakazuje jednakże zinterpretować taką sytuację jako naturalną. Z jednej bowiem strony, bogate w środki wyrazu języki oraz mechanizmy ich rozszerzeń (np. stereotypy) pozwalają na dostosowanie notacji do potrzeb określonego podejścia, co może znaleźć odzwierciedlenie, czy to w formalnym profilu języka, czy też, mniej formalnym z punktu widzenia inżynierskiego, ale właściwym z punktu widzenia zastosowań biznesowych, dokumencie standaryzującym, opisującym rekomendowane rozszerzenia i konwencje, z drugiej, identyfikowana zostaje potrzeba w zakresie języka modelowania, mogąca znaleźć odzwierciedlenie w wersjach nowszych.

Istotne z punktu widzenia przeniesiania sposobu modelowania procesów z notacji występującej w metodzie RIVA na BPMN będą systematycznie omawiane we wpisach znajdujących się pod niniejszym wprowadzeniem.

Reguły biznesowe wkomponowane w przebiegi procesów

Logika podejmowanych decyzji oraz skutki ich podjęcia, rozumiane jako praca do wykonania, stanowią dwa wyraźne, aczkolwiek ściśle związane ze sobą, aspekty funkcjonowania każdej organizacji. Aktualnie, jednym z najczęściej spotykanych podejść do opisywania tej synergii jest rozbudowywanie modeli przebiegów procesów biznesowych o rozwidlenia i warunki wynikające z logiki decyzyjnej oraz uwzględnianie, najczęściej w tekstowych komentarzach związanych z poszczególnymi krokami, zasad, do jakich powinny się stosować osoby uczestniczące w realizacji procesów. Podejścia takie, pomimo swojej, wydawałoby się, prostoty, docelowo prowadzić mogą do uzyskania nadmiernie rozbudowanych, mało czytelnych i trudnych do analizy modeli.

Opublikowane standardy Semantics of Business Vocabulary and Business Rules (SBVR) oraz wersja beta Decision Model and Notation [DMN] nakreślają kierunki, w jakich powinny być tworzone modele architektury biznesowej, by z jednej strony precyzyjnie oddać logikę biznesową, a z drugiej umiejscowić ją w kontekście opracowywanych modeli procesów biznesowych. Z uwagi na fakt, iż stanowią one integralną część architektury biznesowej, mogą być tworzone niezależnie od modelu procesowego organizacji, stanowiąc wartościowy element opisujący biznes. SBVR swoim zakresem obejmuje zarówno tworzenie modelu pojęć jak i reguł biznesowych, rozumianych jako ograniczenie stopnia swobody postępowania osób uczestniczących w pracy realizowanej w organizacji. Zgodnie z teorią, i stojącymi za nią zaleceniami praktycznymi (w szczególności opisanych w publikacjach dotyczących języka RuleSpeak [RSP]), reguły biznesowe są definiowane niezależnie od miejsca ich wykorzystania; w szczególności uwaga ta dotyczy reguł operacyjnych (ang. operative business rule), rozumianych jako element ustanowionego ładu organizacyjnego, który może być przez ludzi złamany. Zaproponowanie wyraźnego rozgraniczenia pomiędzy działaniami realizowanymi przez organizację, a narzuconymi na to działanie ograniczeniami powoduje, iż każdym z wymienionych rodzajów artefaktów należy zarządzać osobno, dbając jednocześnie o utrzymywanie wzajemnych relacji.

SBVR nie precyzuje notacji dla reguł biznesowych umieszczanych w modelach architektury biznesowej. W gestii metodyki oraz wykorzystywanych narzędzi do modelowania leży więc zaproponowanie sposobu prezentacji reguł oraz relacji z innymi artefaktami. Poniższy diagram ilustruje notację dla reguł biznesowych umieszczanych na diagramie przebiegu procesów biznesowych BPMN, zaproponowaną przez producenta narzędzia Visual Paradigm. Zgodnie z zaleceniami SBVR oraz RuleSpeak, reguła operacyjna o treści Produkt może być zapakowany tyko wówczas, gdy posiada kod kreskowy została powiązana z tym miejscem przebiegu procesu, w którym reguła może zostać złamana.

Umiejscowienie reguł biznesowych w opisie biznesu, a nie wspierających biznes rozwiązań informatycznych, jasno wskazuje, iż wszelkie inicjatywy mające na celu wdrożenie maszyn regułowych (ang. business rules management system, BRMS) powinny być realizowane na poziomie biznesowym a automatyzowane reguły biznesowe winny pochodzić ze zdefiniowanych modeli biznesowych, zachowując jednocześnie wyraźne śladowanie pomiędzy warstwą logiki biznesowej a warstwą automatyzowanych reguł biznesowych.

Reguły decyzyjne (ang. decision rule), w odróżnieniu do operacyjnych reguł biznesowych, mają na celu opisanie kryteriów wyboru najlepszej / rekomendowanej opcji w kontekście wykonywanych rutynowych działań operacyjnych. Standard DMN określa obowiązkowe cechy decyzji operacyjnej oraz wskazuje rekomendowane metody jej specyfikowania. Każda ze wskazanych metod całkowicie uniezależnią opis decyzji od miejsca, w jakim decyzja zostanie wykorzystana, aczkolwiek, w przypadku stosowania procesowego paradygmatu opisu realizowanych w organizacji prac z wykorzystaniem BPMN, DMN wskazuje możliwe związki modelu decyzyjnego oraz modelu procesów.

Zarówno reguły biznesowe jak i decyzyjne, wraz z wprowadzeniem stosownych standardów sankcjonujących ich istnienie oraz znaczenie, mają szansę stać się pełnoprawnym produktem zarządczym organizacji, pozwalającym na zwiększenie jednoznaczności proponowanych metod pracy oraz mogącym przyczynić się do tworzenia spójnego ładu organizacyjnego. Uzupełniając standardy o najlepsze praktyki branżowe, takie jak RuleSpeak^TM, czy The Decision Model^TM [TDM], możliwie będzie zwiększenie jednolitości reguł oraz uproszczenie reguł decyzyjnych, tym samym zmniejszając zarówno koszty wprowadzania nowych rozwiązań menedżerskich jak i ich późniejszej aktualizacji.

Rola techniki w metodyce OMNIS

Modelowanie procesów biznesowych pełni w biznesowej części metodyki OMNIS kluczową rolę. Przede wszystkim jest to technika służąca do zaprojektowania bądź usprawniania procesów biznesowych. Zamodelowane procesy stanowią także bazę do łączenia reguł biznesowych oraz decyzyjnych z projektowanym przebiegiem działań. Technika będzie także użyteczna przy specyfikowaniu wymagań wobec rozwiązań IT.

Wykorzystywane języki i narzędzia

Wykorzystywanym w OMNIS środkiem wyrazu, umożliwiającym zapis przebiegów procesów biznesowych jest BPMN.

Pliki do pobrania

Poniżej została umieszczona do pobrania książka Martyna Ould’a. Upublicznienie tej wersji jest efektem oświadczenia autora o możliwości darmowej dystrybucji w ramach krzewienia wiedzy z zakresu procesowości.

Polecana literatura

1. [RIVA] Martyn Ould. Business Process Management – A rigorous approach., Meghan Kiffer Press, 30 Styczneń, 2005
2. [TDM] Barbara von Halle, Larry Goldberg. The Decision Model: A Business Logic Framework Linking Business and Technology (IT Management), Auerbach Publications; 1st edition (October 27, 2009)
3. [RSP] RuleSpeak – specyfikacja.

UŻYTECZNE TECHNIKI