Tym razem książka i koncepcja, którą ona opisuje.
Od lat spotykam się z problemem utraty panowania nad szczegółowością analiz (ilością diagramów i ich złożonością), których celem jest modelowanie organizacji. Na konferencjach pojawiają nawet się prelegenci, którzy przekonują, że model taki to właśnie dziesiątki i setki wielkich diagramów. Gdyby przez chwilę założyć, że “tak ma być” to zasadne stają się pytania: ile kosztuje utrzymanie takiej dokumentacji? Czy ma sens jej tworzenie?
Jeżeli jednak ustawić się w gronie sceptyków, wierzących, że siła w zrozumieniu a nie w ilości danych, to słońce zaczyna wyzierać z za horyzontu benedyktyńskiej pracy tej frakcji “modelarzy bosych”.
Ogólnie “to co się dzieje w organizacji” zależy od: obowiązującego prawa, wewnętrznych ograniczeń (procedury, zarządzenia itp.), kompetencji (umiejętności, wiedzy) wykonawców poszczególnych prac oraz ich zakresów obowiązków (to do czego zostali zatrudnieni). Ogólnie obrazuje to poniższy diagram, który pomaga mi w projektach i kontaktach z klientami już od ponad pięciu lat.
Co tu mamy? Mamy obraz tego, że proces – jego “kształt” – jest skutkiem tych ograniczeń a nie źródłem. Tą metodą zbudowałem swego czasu jeden diagram procesu (strona A4), który modelował całą biurowość w pewnym urzędzie (jego opracowanie zajęło dwa tygodnie studiów instrukcji kancelaryjnych i ustaw). Jak nie trudno się domyśleć, został “wyśmiany” (poprzednicy wysmarowali ponad 300 procesów na koszt tego urzędu!). Problem w tym, że nikt (NIKT!) nie potrafił podać przykładu sprawy, która nie dała by się na tym modelu “przeprocesować”. Lepiej, model radził sobie nawet z wymyślonymi, nie zaistniałymi nigdy przypadkami.
Model organizacji to nie “dokumentacja”, która opisuje wszystkie działania a dokumentacja – modele, która symuluje tę organizację. Wtedy możemy powiedzieć nie tylko jak ona pracuje, ale także DLACZEGO WŁAŚNIE TAK.
Gorąco polecam dwie książki autorstwa Ronalda G. Ross’a, ich okładki tu widzicie. Wydane zostały przez Business Rule Solutions, LLC. Pierwsza skupia się na regułach biznesowych jako koncepcji. Metody i system pojęciowy w niej opisany znalazły się na liście otwartych standardów OMG jako SBVR. W ubiegłym roku ukazało się już trzecie wydanie tej książki.
Druga to pozycja nowa, całościowo opisująca podejście polegająca na modelowaniu organizacji w analizie biznesowej (zawiera część materiału pierwszej) . Zwraca uwagę na fakt, że nie chodzi w analizie o tworzenie mnóstwa diagramów a o to, by zrozumieć jak organizacja funkcjonuje opisując to, oraz stworzyć model, który pozwoli na prognozowanie zachowania organizacji w odpowiedzi na bodźce, nawet te które jeszcze nie zaistniały. Prognoza? A jak Państwo chcecie ocenić ryzyko i skutki utraty członka zarządu (np. złamał nogę na nartach…;)) lub jednego z kluczowych dyrektorów? Jak chcecie ocenić skutki i ryzyko wdrożenia nowego systemu systemu ERP?
Da się… ale model organizacji to nie trawnik boiska z wydeptanymi ścieżkami, bo trwa rośnie a kolejne rozgrywki to nowe ścieżki, nie narysujemy wszystkich możliwych! Model to reguły gry w piłkę nożną, umiejętności poszczególnych piłkarzy, granice boiska, obie połowy, pola karne i bramki. To decyduje o tym ja wygląda gra. Co jest ważne? Odkryć i jednoznacznie udokumentować obowiązujące zasady.
Building Business Solutions: Business Analysis with Business Rules Perfect Paperback ? October 15, 2011
by Ronald G. Ross (Author), Gladys S.W. Lam (Author)
Diagram bardzo fajny i co najmniej jeden podobny wytworzyłem 🙂
To taki “common” diagram, najwyższego poziomu. Właściwie można odnieść go do każdej działalności człowieka – z pewnymi umownymi korektami, np. zastępując dokumenty poleceniami ustnymi. Np. pasuje do procesu “wyniesienie śmieci” 😀
Ciekawe jest pytanie, które się nasuwa: dlaczego administracja tak komplikuje takie proste procesy :)?
Odpowiedź jest prosta ale trudna do akceptacji (nie tylko przez administrację bo nie tylko administracja komplikuje): ludzie w większości nie nie potrafią myśleć abstrakcyjnie oraz szukają prostych rozwiązań, ludzie (w większości) łatwej akceptują ciężką żmudną pracę pod dyktando niż prace bez poleceń wymagającą inwencji… starają się minimalizować ryzyko… (typowa heurystyka prawdopodobieństwa przeżycia: naśladowanie otoczenia, które przeżyło powinno pozwolić też przeżyć, żywe stworzenia są z natury konformistyczne)
Co do abstrakcyjnego myślenia i nastawienia na “przeżycie” to zgadzam się – naśladowanie innych to takie zachowanie z gatunku stadnych i pochodnych “owczego pędu” 🙂
Nie zgodzę się co do “szukania prostych rozwiązań”. Raczej miłośnicy biurokracji (i nie tylko :)) szukają konformistycznych rozwiązań, a to w większości przypadków nie oznacza prostych rozwiązań. Wracając do tematu Business Rules, konformistyczne budowane są wg schematu: bierzemy jak robiliśmy to kiedyś i dodajemy jednego urzędnika więcej, jedną pieczątkę więcej, jeden papierek więcej – będzie bardziej URZĘDOWO 🙂 Chociaż zgadzam się, że na pierwszy rzut oka sam proces budowania właściwego procesu wydaje się prosty, ale tylko wydaje się 🙂 Potem wychodzą różnego rodzaju zapętlone i idiotyczne “potworki” , straszące normalnych ludzi.
@”modelowanie procesu jest szkodliwe”
szkodliwe dla głupoty 🙂
A masz jakiś mądry pomysł na opis reguł biznesowych? Zauważyłem, że skomplikowanie i błędy w wielu modelach wynikają z tego, że próbuje się zrobić model procesu dla pojedynczego zadania – a to przecież nie jest rozwiązanie.
Jedno z rozsądniejszych i czytelniejszych rozwiązań z jakimi się spotykam to schematy blokowe uzupełnione komentarzami, ale dla mnie to powrót do epoki “każdy sobie rzepkę skrobie” czyli modelowania procesów w Visio, czy paincie:)
Nie ja, mam na tapecie te książki Ronalda Rossa, stosuje Rule Speak i system Fact diagram do “analizy”. Po polsku da się to “opracować”, właśnie nad tym siedzę. Zaczynam “wdrażać” u siebie metody z BusinessRulesGroup.org
Jeszcze jedna uwaga: ważne by powiedzieć sobie co to jest “reguła biznesowa” (tu polecam businessrulessgroup.org). Prawda jest taka, że algorytmizacja (próby) pracy w postaci diagramu procesu to ślepa uliczka, kończy się setkami “ifów” (a podobno czasami nawet tysiącami…) w tworzonych na podstawie takich diagramów programach. Decyzje podejmowane w toku pracy zawsze mają dwojaki charakter: są efektem wiedzy i kompetencji osoby decydującej. Klasyka to jury np. na zawodach ale tak samo są np. robione opinie prawne w firmach, nazywa się w literaturze POK “point of knowldge”. w ramach ćwiczeń proponuję wykonać model procesu oceny łyżwiarzy. Albo reguła jest “sztywna” i wtedy mamy dopiero “regułę biznesową” czyli logikę “zerojedynkową”, np. “nie wolno podawać alkoholu osobom nie mającym dowodu osobistego”. Tak więc proces biznesowy to prosty diagram zawierający: model przepływu pracy (łańcucha czynności, workflow) niemalże bez rombów decyzyjnych, zawierający prace (czynności) i wymagane dla nich minimalne kompetencje (POK) albo “reguły” powiązane z każdym takim etapem pracy. W tworzonym (projektowanym) oprogramowaniu reguły biznesowe to elementy modelu dziedziny. Operacje w klasach to między innymi reguły rządzące logiką zachowań konkretnych klas (ich metody), nie może to być anemiczny model dziedziny)…