Kolejne szkolenia za mną, projekty także. Od czasu do czasu audyt (lub ciche opinie) cudzych projektów. Stale widzę dwa poważne problemy w wielu tych dokumentach:

1. utrata panowania nad złożonością,
2. algorytmizacja.

W 2005 roku napisałem na zakończenie artykułu dot. modelowania:

Artykuł ten napisałem głównie po to by mogli Państwo także sami ocenić pracę firm, którym płacicie za tego typu usługi. Na pewno modelowanie wymaga długich studiów i doświadczenia ale efekty muszą być zrozumiałe. Nie jest ono możliwe bez udziału wyższej kadry firmy. Bieganie z ankietami po firmie to dokumentowanie stanu obecnego a nie modelowanie. Dokumentowanie procedur jest przydatne jako kolejny etap przygotowań do napisania dedykowanego oprogramowania ale jest nie potrzebne przed wdrożeniem gotowego systemu, który tylko podlega parametryzacji. Po drugie przed wdrożeniem czy napisaniem systemu konieczne jest zbudowanie modelu firmy choćby po to by upewnić się, że jest on optymalny. W przeciwnym wypadku możemy doprowadzić do utrwalenia w systemie złych i nieefektywnych procesów a w skrajnym przypadku panującego w niej bałaganu. ( Modelowanie biznesowe czyli pilnowanie hochsztaplerów).

od tamtej pory niestety w zasadzie nic sie nie zmieniło na rynku.

Pierwszy problem objawia się lawinowo rosnącą liczbą detali na diagramach i liczbą diagramów. Są nawet tacy, którzy uważają, że  poprawny model procesów biznesowych całej firmy, to setki diagramów. Bzdura. Dlaczego?

Czym jest model?

Model [łac. modulus ?miara?, ?wzór?], metodol. pojęcie oznaczające zarówno teoretyczny, jak i fizyczny obiekt, którego analiza lub obserwacja umożliwia poznawanie cech innego badanego (modelowanego) zjawiska, procesu lub obiektu. (źr. słownik j.p. PWN).

Tak więc cechą dobrego modelu jest możliwość jego testowania. Dobry model to uproszczenie rzeczywistości odwzorowujące jej ograniczenia w wybranym aspekcie. Jeżeli więc testujemy np. współczynnik oporu powietrza projektowanego samochodu, wymagany (i wystarczający) model, to reprezentacja kształtu karoserii a nie kompletna miniatura z silnikiem i siedzeniami.

Analizując organizację, tworzymy model w celu… i tu powinna paść nazwa konkretnego aspektu, perspektywy, którą chcemy badać. Analiza organizacji to element np.:

1. planu budowy nowego systemu zarządzania kosztami (np. [[metoda ABC t.j. zarządzania kosztami działań]]),
2. planu wdrożenia systemu Business Inteligence ([[model biznesowy jako narzędzie projektowania wielowymiarowego modelu hurtowni danych]]),
3. [[opracowania wymagań na oprogramowanie wspomagające zarządzanie]] (ma dwa główne aspekty: [[wybór gotowego oprogramowanie]] oraz [[specyfikacja wymagań na oprogramowanie dedykowane]]).

Podstawową decyzją jaką należy podjąć jest to, czego nie ujmować na tych modelach, a każdy powyżej ma inny kontekst. Każdy projekt, zawierający etap modelowania (modelowanie nie jest celem samym w sobie!) warto rozpoczynać od audytu.  Jego celem jest sprawdzenie jaką wiedzę o sobie samej posiada organizacja czyli ile z tego, co się dzieje w organizacji, jest udokumentowane. Nie musi to być wszystko. Dobrze zarządzana organizacja panuje nad swoją “ciągłością działania”, to jest rozumie jak działa i nie posiada punktu, który jako jeden decyduje o być albo nie być firmy. Typowym przykładem takiego punku jest jeden człowiek, skupiający na sobie kluczowe dla funkcjonowania firmy, kompetencje (np. szef produkcji). Z natury rzeczy ma to miejsce w każdej małej firmie, jednak im większa firma tym ryzyko jej funkcjonowania powinno być mniejsze. Podstawowym elementem zrozumienia mechanizmu funkcjonowania organizacji są reguły biznesowe i zdolności (wiedza) posiadanych zasobów. Opisałem to także w artykule Jak wyłuskać istotę rzeczy.

Złożoność i algorytmizacja. Typowy anty-przykład: proces zawarcia umowy, w którym udział bierze między innymi prawnik oraz Zarząd. Celem jest (między innymi) opinia prawna o treści umowy, uzgodnienie jej treści, na końcu pozyskanie właściwych podpisów (np. wymagane dwa a mamy pięciu członków zarządu). W tym miejscu pojawiają się zawiłe diagramy opisujące jakimi to ścieżkami przemieszcza się dokument (nie ma uwag – OK, są uwagi, odeślij do prawnika, uzupełnij, prześlij znowu do Zarządu, …, następnie pozyskaj podpis Prezesa, jeżeli prezes jest niedostępny, to…). Nawet nie mam ambicji narysowania tego potwora, jakim byłby taki diagram. Jak to mogło by wyglądać? Po pierwsze potrzebna jest specyfikacja stanowisk (ról w procesach) i kompetencji tych ludzi. Po drugie lista reguł (prawo, zarządzania wewnętrzne, procedury itp.). W efekcie powyższy proces to prosty przepływ: konsultacja treści umowy (prawnik ma wiedzę prawniczą, w ramach swoich uprawnień ma prawo do spotkań z Zarządem np. w celu skonsultowania treści umowy. Po uzgodnieniu treści umowy, np. Asystent Zarządu, który(a)  zna procedury i prawo (kolejna rola i kompetencje) zdobywa właściwe podpisy na umowie. Koniec! Gdzie szczegóły? Są! Proces jest, zakresy kompetencji są, prawo i zarządzenia są. Tą metodą, wtedy jest to audyt, można sprawdzić spójność zakresów obowiązków i zarządzeń wewnętrznych  z prawem oraz strategią firmy.

W wielu firmach system zarządzania jest tak niespójny, że jedynym sposobem funkcjonowania tych firm, jest łamanie zasad przez jej pracowników. Niestety pierwsza wpadka często powoduje załamanie się całego systemu (a nie raz i firmy). Wiele Zarządów firm nie zdaje sobie nawet sprawy z tego, jak duże jest ryzyko ciągłości funkcjonowania ich firm. 

Tak więc model procesu to nie algorytm działania firmy, wykazano nie raz, że algorytmizacja pracy ludzi jest niecelowa (wtedy stosujemy roboty).

Znaczna część tego co robią ludzie to efekt ich kompetencji, wiedzy i doświadczenia, a nie dyktowania im jak mają wykonywać swoja pracę.

Jeżeli wybierzemy drogę modelowania tego wszystkiego diagramami, to ilość tych diagramów szybko przekroczy granicę sensy całego projektu: nie będą czytane. Ich wartość będzie żadna.

W procesie dobrze przygotowanej analizy (jakiejkolwiek) modele tworzy się by je badać, a nie tylko po to by powstały za pieniądze sponsora projektu.

Na koniec ciekawy artykuł, opisujący jak stosować reguły biznesowe w modelowaniu procesów.

In creating a viable business solution, you need both a business process model and business rules ? not just one or the other. The trick is not to get them entangled, to remain clear about which is which. The good news is that by separating them you can simplify your business process models dramatically ? often by an order of magnitude or more. This discussion explains how. (za  Business Processes: Better with Business Rules).

P.S.

Widzę pewną korelację: najczęściej obecni lub dawni programiści robią najgorsze modele organizacji: mają tendencje to technokratycznej algorytmizacji opisu pracy ludzi, ignorują czynnik ludzki w modelach, patrzą na procesy w firmach przez pryzmat ograniczeń rozwiązań i technologii, które oferują ich pracodawcy. Podobne tendencje mają także ci, którzy podchodzą do tworzenia modeli procesów jak do “spisania metodami obrazkowymi tego co mówią pracownicy podczas wywiadów”. To także bardzo złe modele, zaryzykuję tezę, że gorsze od tych z rąk programistów.

Należy też nabrać pokory: większość organizacji sprawnie funkcjonuje nie mając żadnych modeli procesów, więc teza, że ich brak szkodzi jest nie do obrony. Po co więc te modele? Żeby zrozumieć dlaczego tak jest i co się stanie, gdy zechcemy wprowadzać zmiany.