Architektura procesów biznesowych a modelowanie procesów biznesowych – poziomy modelowania

W poprzednim wpisie Modelowanie procesów biznesowych w procesie wytwórczym oprogramowania opisałem znaczenie modelowania procesów biznesowych.

W moim odczuciu, modelowanie procesów biznesowych w procesie wytwórczym oprogramowania to podstawa, do której odnoszą się kolejne etapy tego procesu. Analitycy systemowi na podstawie procesów biznesowych i wymagań biznesowych identyfikują przypadki użycia i wymagania na system. Testerzy budują plany testów i scenariusze testów (zwłaszcza jeśli chodzi o testy integracyjne). Programiści mają ułatwione zadanie w planowaniu kolejności implementacji poszczególnych funkcji.

Modelowanie procesów biznesowych w procesie wytwórczym oprogramowania będzie miało sens, gdy wybierze się dobrze poziomy abstrakcji opisu modeli. Poziom abstrakcji określa jak wiele szczegółów ma być zaprezentowane na danym diagramie. Innymi słowy, poziom abstrakcji nie określa nam ilości informacji a ich zakres.

Dobra wiadomość jest taka, że to my wybieramy poziom złożoności diagramów procesów biznesowych. Zła, że każdy z nas ma inny poziom postrzegania detali. Reprezentuje inny punkt widzenia i to co dla jednej z osób będzie zbyt detaliczne dla drugiej zbyt ogólne.
Z tego też powodu zalecam by zespoły analityków na wspólnym warsztacie lub warsztatach ustaliły standard modelowania procesów biznesowych. Należy na warsztatach omówić nie jeden a kilka modeli tak by ustalić sposób patrzenia na podobne procesy wśród analityków był podobny.

Druga sprawa to połączenie modeli procesów biznesowych ze światem architektury procesów biznesowych.
W moim rozumieniu architektura procesów biznesowych nie jest tym samym co  architektura biznesowa czyli „formalny opis sposobu działania biznesowej części organizacji, na poziomie kluczowych jej składowych i relacji między nimi, pokazujący jak organizacja wykorzystuje swój potencjał (obecny i planowany) do realizacji celów strategicznych oraz mechanizmy pozwalające na wykorzystanie tego opisu w procesie podejmowania kluczowych decyzji w organizacji” (Andrzej Sobczak – Architektura Biznesowa – Jak ją wdrożyć w organizacji?)

Moja robocza definicja brzmi :

Architektura procesów biznesowych to zestaw powiązanych ze sobą procesów biznesowych dostarczających korelujące ze sobą produkty lub wspierających ten sam cel biznesowy.

Architektura procesów biznesowych może mniej lub bardziej szczegółowa.

Poziomy modelowania doskonale uwidacznia hierarchia, którą zaproponował  Artie Mahal w książce „How Work Gets Done: Business Process Management, Basics & Beyond, Technics Publications LLC (2010)”

źródło: https://www.slideshare.net/Dataversity/anatomy-of-a-business-process-how-work-gets-done

Na najwyższym poziomie jest „łańcuch wartości” czyli najbardziej ogólny poziom procesów. Na samym dole znajdują się poziom systemów. Dość dokładnie opisał to Jarek Żeliński w tekście Poziomy modelowania c.d. czyli How work gets done.

W swojej pracy stosuję trochę bardziej uproszczony model warstwowy. W zależności od klienta jest on inny, ale zasadniczo rama jest bardzo podobna.

Mój model składa się z 4 warstw, które nazywam poziomami:

• poziom N – obszary biznesowe  lub proces biznesowy najwyższego poziomu (notacja Archimate) np.: Sprzedaż
• poziom N-1 – procesy biznesowe, które reprezentują agregat minimum jednego a zazwyczaj wielu procesów, które dostarczają konkretnej wartości np.: Obsługa reklamacji (Archimate)
• poziom N-2 – zestaw czynności prowadzących do konkretnego rezultatu np.: przyjęcie reklamacji telefonicznej (BPMN)
• poziom N-3 – zestaw czynności prowadzących do konkretnego rezultatu opisany z wykorzystaniem systemu informatycznego np.: przyjęcie reklamacji telefonicznej w systemie CallCenter

Poziomy N-2 i N-3 rzadko występują razem, ale zdarza się.  Poziom N-1 można zastosować tylko w BPMN za pomocą pakietu.

Na załączonym poniżej przykładzie na poziomie N są duże obszary biznesowe takie jak Sprzedaż, Produkcja, Windykacja. Każdy z nich może reprezentować i proces sprzedaż i pewien obszar biznesowy firmy.

Na Sprzedaż składają się takie procesy jak Reklamacja dot. produktu, Realizacja transakcji, Przyjęcie zamówienia i Logistyka. Są to procesy poziomu N-1. Na poniższym diagramie zamiast kompozycji można użyć zwykłej agregacji.

Te procesy z poziomu N-1 mogą być uszczegółowione przez procesy BPMN z poziomu N-2. I tak Przyjecie zamówienia może być zrealizowane przez stronę www, handlowca, sklep partnerski, itd. Rozwiązań jest wiele. Tutaj przykładowa dekompozycja:

Należy jednak zauważyć, że na tym poziomie zamiast BPMN może być pakiet z listą procesów.

Zidentyfikowane procesy BPMN to poziom N-2 lub N-3. W tym przykładzie zdekomponowałem proces reklamacji (dość prosty i ogólny). Poziom N-2 nie zwiera informacji o systemach.

a poniżej proces w wariancie z poziomu N-3 – już z systemami.

Tak skonstruowana architektura procesów biznesowych jest tylko przykładową dekompozycją złożonego świata jakim jest biznes.
Świat w Twojej organizacji może być bardziej lub mniej złożony. (Zazwyczaj bardziej :-))

W procesie wytwórczym oprogramowania, każda z tych warstw może i znajduje odpowiednie zastosowanie.
Modele na poziomie N i N-1 zazwyczaj, wraz z usługami aplikacyjnymi i systemami,  przydają się do opisania koncepcji rozwiązania. Poziom N-2 i N-3 to koncepcja rozwiązania, specyfikacja wymagań biznesowych lub wymagań systemowych.

Jak widać z powyższego w zależności od poziomu modelowania procesu biznesowego przekazujemy inny zakres informacji. Dzięki odpowiedniej architekturze procesów biznesowych łatwiej jest tworzyć nowe i modyfikować istniejące oprogramowanie.

Reklama