Po ukazaniu się artykułu Reguły biznesowe jako motor..  często jestem pytany dlaczego restrykcyjnie pilnuję formalnych zasad analizy w projekcie. Powód jest tylko jeden: to jedyny sposób na osiągniecie spójności i kompletności w pierwszym podejściu.

Iteracyjne doprowadzanie dokumentu (opracowania) do wymaganego poziomu jego jakości jest bardzo kosztowne. Zaryzykuje tezę, że jeden dobry analityk (na umowę o dzieło ;)) wykona tę samą prace znacznie szybciej, taniej i lepiej niż “przeciętny zespół z procesem kontroli jakości w postaci recenzentów”. Nawet jeden analityk z tradycyjnym podejściem plus jeden recenzent to proces kosztowniejszy (druga osoba w projekcie) i trwający znacznie dłużej (kolejne iteracje recenzji, to także koszt). Dyskusje pozostawiam Państwu, ja nie znam przypadku by powyższe się nie sprawdziło. Warunek: właściwe stosowanie właściwych narzędzi analitycznych.

Typowe zadanie: model organizacji

Model organizacji to dokument opisujący ją w sposób pozwalający na zrozumienie przyczyn tego co i jak sie w niej dzieje oraz na przewidywanie skutków planowanych działań (np. organizacyjnych). Kluczowym, ostatecznym narzędziem pracy jest model procesów biznesowych ale on jest efektem wielu rzeczy, w tym reguł biznesowych (z reguły forma zarządzeń itp.), kompetencji pracowników. Reguły i kompetencje powinny być spójne i jednoznaczne stąd pojawia się potrzeba posiadania w organizacji wspólnego słownika terminów (ostatnio spotkałem firmę, w której nowe projekty mają formalną wewnętrzną nazwę Temat a nie Projekt) .

Model taki to także jedyny sposób za udokumentowanie i zatrzymanie w firmie Wiedzy o tym jak funkcjonuje i dlaczego akurat tak, mimo rotacji pracowników, od której nie jest wolna żadna firma. Na początek mała burza mózgów, czyli czego obawiają się zarządy firm:

Biblioteka

Jak rozwiązać te problemy?

Zakres projektu analitycznego

Jak wspomniano model procesów jest końcowym efektem pracy jednak nie jest on “zawieszony w powietrzu”. Aby wykonać go poprawnie i “skutecznie” (mieć możliwość autoaudytu i weryfikacji) należy mieć: słownik pojęć biznesowych (ang. glossary, obejmuje swoim zasięgiem obiekty biznesowe np. kluczowe dokumenty), model struktury organizacyjnej oraz specyfikacje reguł biznesowych.

Metamodel projektu

Słownik pojęć

Jest podstawowym weryfikatorem i gwarantem jednoznaczności wszelkich zapisów, w tym nazw na modelach procesów, pojęć użytych w regułach biznesowych (w tym np. w wewnętrznych zarządzeniach, procedurach itp.), nazw użytych w strukturze organizacyjnej . Pojęcia te nie powinny być wzajemnie sprzeczne ani “zazębiające się” (każda rzecz w firmie powinna pasować tylko do jednej definicji), nie powinny być definiowane przez siebie same (jedno z pomocą drugiego). Zbudowanie poprawnego (czytaj bezpiecznego dla projektu) słownika jest trudnym zadaniem. Tu formalizmem jest utrzymanie powyższych zasad oraz stosowanie odpowiednich narzędzi analitycznych (sposobów identyfikacji i weryfikacji).

Słownik reguł biznesowych

To kolejny element, któremu pomagają formalizmy. Zgodnie z definicją Reguła biznesowa to ograniczenie obejmujące całą organizację, reguła nie jest procesem ani procedurą. Reguły (ich treść i sposób zapisu) muszą być jasne (zrozumiałe), spójne i weryfikowalne. Ich tworzenie, kontrola niesprzeczności i kompletności wymaga także przestrzegania pewnych zasad (formalizów). W przeciwnym wypadku skazani jesteśmy na ich weryfikację poprzez wdrożenie i obserwowanie skutków czyli efektów ubocznych w organizacji po wprowadzeniu np. nowych zakazów lub obowiązków, co jest długotrwałe i bardzo kosztowne.

Narzędziem do “wychwytywania” i weryfikacji logiki pojęciowej reguł biznesowych (te są formułowane z użyciem słownika pojęć) jest tak zwany diagram faktów:

Model faktow Biblioteka

Diagram ten  (nie da się go zastąpić ani diagramem klas UML ani modelem danych!) ma pewną specyfikę pojęciową: składa się  wyłącznie z pojęć zdefiniowanych w słowniku (prostokąty) oraz ze zdarzeń zwanych faktami, które je opisują (a nie wiążą!) zdefiniowane pojęcia. W ten sposób opisujemy (testujemy, analizujemy) kluczową, specyficzną, sferę działania organizacji. Powyższe nie zastępuje modelu procesów, który opisuje powstawanie wartości jako przepływ pracy. Tu mamy do czynienia z elementarnymi faktami opisującymi podstawowe działania w organizacji (model ten nie operuje pojęciem klasa, zdarzenie ani produkt).

Po wykonaniu i przetestowaniu powyższego dysponujemy słownikiem pojęć i specyfikacją reguł biznesowych spełniającą powyższe wymagania:

Zestawienie regul i pojec

Struktura organizacyjna

W brew pozorom jej opracowanie nie jest łatwe. Struktura organizacyjna określa podległość i zarazem odpowiedzialność.  Powinna być jednoznaczna. Jako model stanowi pewną hierarchię, której szczytem jest podmiot modelowany (na szczycie jest to organizacja, w pewnym sensie obrazuje to osobę prawną). Celem jest określenie jednoznacznej podległości i odpowiedzialności każdego pracownika. Pracownik pełni funkcje zdefiniowaną przez jego umocowanie w tej strukturze, dopuszczalne jest to, że jakaś osoba zajmuje więcej niż jedno stanowisko (wtedy nazywamy to PO czyli pełniący obowiązki). W efekcie pozwala to na jednoznaczne przyporządkowanie osoby do roli w procesie (o tym w dalszej części).

Model struktury organizacyjnej

Powyższy diagram jest trywialny ale obrazuje tę hierarchię. Gdyby z jakiegoś powodu Kierownik biblioteki miał wypożyczać jeden dzień książki, to znaczy, że konkretny Kowalski (ten kierownik) tego dnia będzie pełnił obowiązki (rolę) Bibliotekarza.  System “pełniącego obowiązki” pomaga w utrzymaniu prządku organizacyjnego.

Każdy element na takim diagramie (element struktury organizacyjnej) powinien mieć określone: wymagane umiejętności oraz zakres obowiązków. Zakres obowiązków to odpowiedzialność, zaś umiejętności określają co konkretna osoba musi umieć albo innymi słowy czego konkretnej osobie nie trzeba mówić (instruować jej) by wykonała swoją pracę poprawnie. Poprawnie oznacza tu: w oczekiwany sposób. Im mniejsze umiejętności tym bardziej szczegółowy musi być opis pracy jaką dana osoba ma wykonywać by robiła to zgodnie z oczekiwaniami (jest to ścisła zależność).

Jak widać jest to obszar analizy, który przy okazji porządkuje kwestie zarządzania zasobami ludzkimi. 

W wielu firmach obserwuję w tej sferze bałagan i z jednej strony Zarząd nie dopuszcza myśli o “naprawieniu” struktury organizacyjnej, a z drugiej w nieskończoność szuka przyczyn kłopotów organizacyjnych wymyślając kolejne nowe, nie rozwiązujące problemu, zarządzenia.

Model procesów biznesowych

Pora na konkrety. Model (mapa) procesów biznesowych to efekt powyższych ograniczeń (tak: reguły biznesowe oraz struktury organizacyjne i zakresy obowiązków to ograniczenia). Dobrze opracowany model procesu jest konkretny, nie rozwlekły i czytelny. Opisuje (obrazuje) przepływ pracy:

Model procesow

Model procesów biznesowych bywa nazywany (zgodnie z teorią łańcucha wartości M.E.Portera) modelem wewnętrznego (firmowego) łańcucha wartości. Model taki powinien być w 100% zgodny z definicją procesu biznesowego, najczęściej przytaczaną jest: proces biznesowy to czynność lub łańcuch czynności, zamieniający informacje – stan wejścia w stan wyjścia, tworząc wartość dodaną.  Model taki powinien wiec obligatoryjnie zawierać: opis i stan wejścia, wyjścia, listę czynności. Czynnikami opisującymi szczegóły wykonania każdej czynności są: reguły biznesowe (w tym procedury) oraz kompetencje wykonawcy.

W efekcie otrzymujemy spójny i czytelny model procesu, nie przeładowany zbędnymi szczegółami, zarządzany i łatwy w użyciu. Korzyści z takiego modelu:

  1. zmiany zakresów obowiązków nie wymagają jego aktualizacji
  2. zmiany reguł biznesowych nie wymagają jego aktualizacji
  3. zmiana przyporządkowania konkretnej osobie pełnionych obowiązków nie wymaga jego aktualizacji
  4. jest doskonałym narzędziem do analizy wymagań na systemy IT

To efekty utrzymania formalnej zasady mówiącej, że każda informacja jest utrzymywana w jednym miejscu ze wskazaniem gdzie jest wykorzystywana. Pozwala to także wykonać szybko tak zwana analizę wpływu (ryzyk) czyli na co ma wpływ potencjalna ingerencja w jakiś element modelu:

wypozyczenie-ksiazki-analysis-diagram

Na zakończenie

Źródła standardów na etapie analizy biznesowej czyli modelowania struktur zarządczych organizacji:

  1. Semantics Of Business Vocabulary And Business Rules
  2. RuleSpeak
  3. BPMN
  4. Business Rules Group (w tym Business Motivation Model)

Stosowanie opisanych tu formalizmów to uznanie, że dobre i sprawdzone standardy pozwalają zminimalizować ryzyko projektów analitycznych.

Analiza to nie zbieranie danych o firmie i ich sortowanie, bo czy to nie brzmi jak ekologiczne zbieranie śmieci? Analiza to porządkowanie zebranej wiedzy o organizacji,  korzystając z wypracowanych systemów pojęciowych, czyli przyporządkowywanie wszystkiego co wiemy do skończonej liczby pojęć, oraz uzupełnianie lub naprawianie wszystkiego czego zabranie w tak opracowanym modelu. Kluczem dobrej analizy jest uogólnianie czyli wychwytywanie rzeczy istotnych oraz odsiewanie informacji zbędnych, nie mających wpływu na cel projektu a zaciemniających go. Analiza to odkrywanie i rozumienie reguł, panowanie nad złożonością organizacji.

Większość projektów takich jak np. wdrażanie nowych metod kontrolingu, zrównoważonej karty wyników, nowych systemów IT itp. cierpi głównie z powodu posiadania nadmiaru informacji z jednej strony i kompletnego jej niezrozumienia z drugiej. Sławne już w badaniach “złe i niekompletne wymagania” czy “zmiany zakresu projektu w trakcie jego trwania” to klasyczne skutki złej (a często pomijania!) analizy biznesowej. Koszty tych porażek wielokrotnie przewyższają koszt takich analiz.

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).