Jednym z zabójców projektów związanych z modelowaniem procesów biznesowych, jest ich nadmierna szczegółowość. Ktoś może powiedzieć, że „o te szczegóły właśnie chodzi”. Jeżeli tak mówi, to nie rozumie czym jest model procesów biznesowych, bo taki model to nie miejsce na takie szczegóły w analizie. Jeżeli jednak przeforsowana zostanie w projekcie teza mówiąca, że „modele procesów mają zawierać wszystkie szczegóły”, otrzymujemy sterty nieczytelnych diagramów, nie poddających się jakiejkolwiek dalszej obróbce.
W artykule Poziomy modelowania… opisałem hierarchię szczegółowości modeli procesów. Tu skupiłem się na walce z nadmiarem szczegółów na nich.
Diabeł tkwi w szczegółach
To częsty argument za tym, by te szczegóły umieszczać na diagramach. Czym są te szczegóły?
Pojęcie procedury. W popularnym polskim WIKI nie ma niestety rozwiniętej definicji pojęcia procedura (stan na 24.09.2013):
Pozostaje mi więc przyjąć nieco ściślejszą niż powyższa, definicję ze sł. j. polskiego PWN jako bazę do dalszych dywagacji (ważna uwaga: słownik pojęć w dokumentacji projektowej pisanej po polsku, nie może być niezgodny ze słownikiem języka polskiego, może być co najwyżej uszczegółowieniem):
Procedura: 1. określone reguły postępowania w jakiejś sprawie, zwykle o charakterze urzędowym lub prawnym, 2. w językach programowania: wydzielony fragment algorytmu.
Ważne jest tu to, że procedura to generalnie określone reguły postępowania (przypominam, że regułą postępowania jest także lista czynności i sama kolejność ich wykonania). Wskazówką by tę definicję doprecyzować jest także nawiązanie (2. znaczenie) to programowania: wydzielony fragment algorytmu. Powyższe pozwala uznać, że konkretna procedura to postępowanie w jednej sprawie (jednym celu). Czy postępowanie w sprawie (albo wydzielony fragment algorytmu) da oczekiwany rezultat jeżeli je przerwiemy? Nie. Tak więc definicja procedury, która się tu sama wręcz narzuca (i taką przyjmuję w projektach) brzmi:
procedura – ciąg czynności (kroków postępowania), którego przerwanie prowadzi do utraty celowości wykonywania tych czynności
Popatrzmy też jak procedurę definiuję norma technologiczna ISO9000:
procedura: określony sposób realizacji działań lub procesów
Model procesów biznesowych
Czy przypadkiem nie dzielę włosa na czworo? Moim zdaniem nie. Dzięki powyższemu możliwe jest zapanowanie nad szczegółowością projektu analizy procesów biznesowych. Mając definicję pojęć proces biznesowy, podproces (dekompozycja procesu) oraz procedura mam doskonałe narzędzie do kwalifikowania elementów wiedzy o tym „co się dzieje” jako procesy, pod-procesy czy własnie procedury.
Zwróćmy uwagę, proces biznesowy najwyższego poziomu to tak zwany proces end-to-end. Jego dekompozycja (kolejne dekompozycje) doprowadzą nas do elementarnych (atomowych) procesów biznesowych. Atomowy proces biznesowy jest dokumentowany (to jak przebiega) jako procedura. Procedury, z reguły, nie są już diagramami a wypunktowanymi listami, „receptami” działania. Wszystkie szczegóły wykonywanych czynności są zawarte, nie na diagramie procesu, a właśnie w treści procedury (tu polecam artykuł: Co to jest proces biznesowy).
Mając więc powyższą definicję procedury, łatwiej nam teraz jest zakwalifikować informację to tym, że należy zeskanować przychodzący dokument, jako element (krok) procedury a nie jako proces biznesowy. Samo skanowanie, bez następujących po nim dalszych kroków postępowania z dokumentem, do niczego nie służy, więc nie może być (w myśl powyższych definicji) procesem biznesowym. Jest zapisem w treści procedury opisującej sposób realizacji procesu przyjęcia dokumentu.
Bez tej formalizacji (ścisłe stosowanie zdefiniowanych pojęć, także tych z użytej notacji) próby modelowania procesów prowadzą najczęściej do powstawania monstrualnych ilości nieczytelnych diagramów (widywałem dokumentacje, gdzie było dla jednej firmy powstałe blisko tysiąc stron! Masakra). To kompletnie nieprzydatne dokumenty.
Co jeszcze nam daje stosowanie powyższych definicji? Możliwość jednoznacznego „przejścia” (śladowanie) z modeli procesów biznesowych na modele przypadków użycia bo atomowy proces, zakwalifikowany do zakresu projektu jako wymagana usługa oprogramowania, to przypadek użycia nowego oprogramowania, zaś procedura tego procesu to nic innego jak scenariusz tego przypadku użycia lub jak ktoś woli: user story. Z innej strony: jeżeli mamy wdrożoną procesową normę np. ISO9000, to modelując procesy biznesowe i „podpinając” do nich procedury z księgi jakości, szybko się przekonamy, czy nasze ISO to nie jest przypadkiem fikcją.
