Mamy dwa osobne rodzaje dokumentów: mapy/modele procesów biznesowych czyli łańcuchy aktywności i dokumentów (oraz ich treść) opisujące to jak działa firma, procedury czyli opisy realizacji aktywności w procesach, czyli opisy co konkretnie i jak robią ludzie. Nie należy tego mieszać na tych samych diagramach, bo wychodzą potwory sphaghetti :) Wstęp Od 2003 roku normy serii ISO wymagają, by procedury tworzyły razem logiczny ciąg aktywności (procesy biznesowe). Dotyczy to wielu różnych norm i zaleceń. Testem spełnienia tego warunku jest poprawny, analityczny, model procesów biznesowych w organizacji. Jaki to jest poprawny? Taki,…
Warstwa procesów, usług aplikacyjnych/przypadków użycia i komponentów to odrębne warstwy i perspektywy. Nie mieszamy więc ani poziomów abstrakcji ani perspektyw modeli. W przeciwnym razie, ulegając sugestiom w rodzaju "ale ja chcę zobaczyć to wszystko na jednym diagramie" pchamy projekt w kierunku "utraty panowania nad złożonością"... To prosta droga do klęski projektu.
(źr. http://www.bptrendsassociates.com/)
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, 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żona normę 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 fikcja.
