W poprzednim artykule, Czy system pełni rolę w procesie?, pojawiła się polemika, która jest dość powszechnym problemem:
[czytelnik] Są to procesy (lub podprocesy), które zostały zastąpione w 100% i alternatywna ich obsługa będzie możliwa tylko w przypadku wystąpienia jakiegoś błędu.
Przykładem takiego procesu jest zautomatyzowanie rejestracji dokumentów (wprowadzenie kanału mailowego, odcięcie całkowite możliwości wykorzystania papierowych dokumentów). Test odłączenia prądu odetnie organizację od świata zewnętrznego. Wyobrażam sobie wiele biznesów opierających się w większości o chmury, usługi, których wycięcie sprowadzi ten akurat biznes do poziomu średniowiecznego.
[moja odpowiedź] odłączenie prądu spowoduje zmuszenie do przemyślenia i nazwania procesu ?przyjmowanie dokumentów? a mail to tylko przyjęta metoda, tu błędem było nazwanie procesu biznesowego ?odbierani maili? zamiast nazwanie go ?tym czym jest? czyli ?przyjmowanie korespondencji?.
Jest to klasyczny przykład braku uogólnień i abstrakcji w modelach, co prowadzi do “zamulania” ich nadmiarem szczegółów, maskowania prawdziwego sensu (istoty) zjawiska. Problem stosowania abstrakcji w modelowaniu a konkretnie, problem nie radzenia sobie z abstrakcją, jest często w literaturze nazywany “utratą panowania nad szczegółowością projektu”. Monstrualne ilości diagramów procesów, monstrualne ilości detali na diagramach, to efekt braku abstrakcji.
Warto pamiętać, że modele procesów biznesowych to element opisu architektury biznesowej. Po raz kolejny przypomnę diagram:
Najniższa warstwa to implementacja procesów, tu dopiero mamy wszelkie szczegóły takie jak: zakresy obowiązków, instrukcje stanowiskowe i podręczniki użytkowników, procedury, wymagane umiejętności, konkretne rozwiązania np. oprogramowanie. Są to te elementy, których nie umieszczamy na modelu procesów, bo procesy biznesowe to “czynności przekształcające stan wejścia w stan wyjścia”. Proces biznesowy to jeden “bloczek” wraz z jego wejściem i wyjściem (proces definiują te trzy elementy) na schemacie blokowym będącym modelem (mapą) procesów. Bloczek reprezentujący czynność (aktywność, kwestia nazewnictwa), jest abstrakcją procedury, umiejętności, instrukcji obsługi, itp. W dokumentacji więc powołujemy się na te np. procedury (stosowne dokumenty), a nie odtwarzamy ich “obrazkowo” na modelu procesów, bo to prowadzi po pierwsze do dublowania istniejącej dokumentacji oraz do strasznej komplikacji diagramów obrazujących procesy.
Problem ten dobrze opisuje autor tego artykułu:
One of the key characteristics of architecture is looking at the ?big picture?, but a major challenge is that we can?t present the big picture on one great big piece of paper ? it has to fit on a single sheet or model. In order to do that, we have to come up with new concepts that summarize the overall picture into a small number of elements and relationships. We can do this through a variety of techniques, like divide-and-conquer, categorization, generalization, and so on. (BPTrends | Business Archicture: Abstraction in Business Architecture).
Tak więc brak (umiejętności) stosowania abstrakcji w modelowaniu czyni te i inne modele (także UMl itp.) nieczytelnymi, trudnymi do interpretacji, kosztownymi w wytworzeniu i potem w utrzymaniu. To ostatnie powoduje, że większość takich dokumentów szybko kończy życie na półkach, bo dezaktualizują się jak tylko dojdzie do jakiejkolwiek, nawet najdrobniejszej, zmiany w organizacji. Co ciekawe, biorąc pod uwagę czas trwania przeciętnego wdrożenia oprogramowania, taki zbyt szczegółowy model nie ma szans być przydatnym w toku takiego projektu, tu rację mają developerzy, którzy twierdzą, że im takie dokumenty im w niczym nie pomagają.
No ale te szczegóły są potrzebne. Owszem pytanie: które oraz czy na pewno musimy je obrazkowo przepisywać np. z dokumentów działu HR czy jakości. W dokumentowaniu (modelowaniu) organizacji stosujemy różne “perspektywy”, kilka prostych schematów lepiej modeluje organizację niż jedne, na których ktoś upycha “wszystko co wie” (jak to robić lepiej opisałem w artykule Gdzie są te … szczegóły).
Tak więc dokumentowanie “szczegółów” owszem jest potrzebne, ale nie na diagramie procesu. Umiejętności i wiedza wykonawcy to rola w procesie: każda powinna mieć osobną dokumentację (lub odwołanie do dokumentów w HR). Szczegóły realizacji zadań (czynności, aktywności) to procedury, na które znowu się powołujemy, lub takie dokumenty jak macierz RACI i specyfikacja polityk i reguł biznesowych (opisałem to w artykule RACI … i wcześniejszym RACI i SIPOC).
I tu mały prztyczek dla sponsorów projektów zlecających takie analizy: żądania wobec analityka w rodzaju “a ja chcę zobaczyć jeszcze to … na tym schemacie” to zabijanie projektu. Są uznane dobre praktyki, między innymi modelowanie od ogółu do szczegółu, stosowanie abstrakcji i perspektyw. Nikt rozsądny nie będzie podejmował prób tworzenia planu miasta, na którym będą wszystkie te rzeczy, które w danym mieście są np. przystanki środków komunikacji publicznej, podmioty gospodarcze, ale także wysokość gruntu, znaki drogowe, sklepy itp. Taka mapa, zakładając jej rozsądną wielkość, była by nieprzydatna, więc żądanie takiej od analityka także nie ma żadnego sensu.
