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, w którym (zgodnie z ISO) procedury mają unikalne nazwy, każda ma wejście i wyjście (z reguły jest to dokument) i razem (połączenie wyjścia aktywności zakończonej do wejścia następnej) tworzą logiczne łańcuchy zadań zwane mapami i modelami procesów biznesowych. Niestety często widuję w audytach, że warunek ten nie jest spełniony,…
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.
