Cztery lata temu,  pisałem o regułach biznesowych jako elemencie modelu biznesowego i ich roli w zarządzaniu:

Na czym więc polega skuteczne zarządzanie? Na zrozumieniu, posiadaniu planu działania i przemyślanym tworzeniu ograniczeń.Robi tak każda większa firma: powstają zakresy obowiązków, wewnętrzne zarządzenia i procedury. To wszystko to nic innego jak ograniczenia.Opracowanie modelu organizacji więc, to nie  tylko opisanie procesów bo te są jedynie efektem istniejących ograniczeń. Pełny model organizacji, dający zrozumienie tego jak ona działa, to kompletny model pojęciowy ? nazwy i definicje podstawowych pojęć opisujących jej działanie (co to jest klient, produkt, kontrahent, ?), specyfikacja wszelkich ograniczeń czyli reguł biznesowych oraz specyfikacji stanowisk i wymaganych na każdym z nich umiejętności (pamiętamy, że ograniczeniem jest także obowiązujące prawo). (Źródło: Reguły biznesowe jako motor sterujący organizacji: fakty + definicje pojęć | Jarosław Żeliński IT-Consulting)

Dzisiaj o zarządzaniu zorientowanym na reguły biznesowe. Temat, z którym pierwszy raz zetknąłem się jakieś 15 lat temu w jednym z wydawnictw Harvard Business Review. Nie będę tu streszczał tego tekstu (pewnie nawet nie mogę ;)), generalnie przesłanie brzmiało:

organizacją można zarządzać tworząc reguły a nie wydając polecenia przy każdym zdarzeniu.

Manifest reguł biznesowych

Poniżej fragmenty Manifestu Reguł Biznesowych (link do oryginału)

Manifest reguł biznesowych, kilka kluczowych elementów wyróżniłem podkreśleniem:

Artykuł 2. [reguły biznesowe] Oddzielone od procesów, a nie zawierające się w nich
2.1. Reguły są bezpośrednimi ograniczeniami narzuconymi na funkcjonowanie organizacji jak również mogą stanowić wsparcie dla jej funkcjonowania.
2.2. Reguły nie są procesami ani procedurami. Nie powinny być w nich zawarte.
2.3. Reguły mają zastosowanie ponad i pomiędzy procesami i procedurami. Powinny stanowić jeden spójny organizm, stosowany konsekwentnie w odpowiednich obszarach aktywności biznesowej.
Artykuł 3. Świadomie rozwijana dziedzina wiedzy, nie produkt uboczny
3.1. Reguły budowane są na faktach, a fakty budowane są na koncepcjach wyrażonych poprzez terminy [błąd tłumaczenia, zamaist “koncepcjach” powinno być “pojęciach wyrażonych odpowiednimi słowami”].
3.2. Terminy wyrażają koncepcje biznesowe [tu niestety także mamy błąd tłumaczenia, chodzi pojęcia biznesowe a nie “koncepcje”, w oryginale jest słowo “concept”]; fakty dostarczają stwierdzeń odnośnie tych koncepcji, reguły ograniczają oraz wzbogacają te fakty.
3.3. Reguły muszą być wyrażone explicite. Reguły nie stanowią domniemań odnośnie koncepcji, czy faktów.
3.4. Reguły stanowią podstawę tego, co biznes wie o sobie ? to znaczy, podstawę wiedzy biznesowej.
Artykuł 4. Deklaratywne, nie imperatywne
4.1. Reguły powinny być wyrażane deklaratywnie w formie zdań w języku naturalnym dla docelowego odbiorcy biznesowego.
4.2. Jeżeli coś nie może być wyrażone, nie jest regułą.
4.3. Zbiór wyrażeń uznaje się za deklaratywny, gdy wyrażenia w zbiorze nie zależne od jakiegokolwiek uporządkowania.
4.4. Dowolne wyrażenie dotyczące reguł, które wymaga konstrukcji różnych od pojęć i faktów implikuje założenia odnośnie systemowej implementacji.
4.5. Reguła jest różna od jakiegokolwiek zastosowania dla niej zdefiniowanego. Reguła oraz jej zastosowanie powinny być rozważane oddzielnie.
4.6. Reguły powinny być definiowane niezależnie od tego kto, gdzie, kiedy i jak je zastosuje.
4.7. Wyjątki od reguł są wyrażane innymi regułami.
5.3. Logiki formalne, takie jak logika predykatów, są fundamentem dobrze wyrażonych reguł, wykorzystujących terminy biznesowe oraz technologii implementujących reguły.
Artykuł 10. Zarządzanie logiką biznesu, nie platformami informatycznymi 
10.1. Reguły biznesowe są wartościowym zasobem biznesowym.
10.2. W perspektywie długoterminowej, reguły są dużo ważniejsze dla biznesu od platform sprzętowych i programowych.
10.3. Reguły biznesowe powinny być organizowane i przechowywane w sposób umożliwiający ich późniejsze łatwe osadzenie na nowych platformach programowych i sprzętowych.
10.4. Reguły oraz możliwość efektywnego zarządzania ich zmianami są podstawą do usprawnienia zdolności organizacji do adaptacji do nowych warunków.

Warto zwrócić uwagę na kluczowe dla zarządzania organizacją i kluczowe dla tworzenia modeli biznesowych elementy:

1. Reguły biznesowe to ograniczenia zachowań (pożądane, dopuszczalne i niedopuszczalne fakty).
2. Reguły nie są ani procesami ani procedurami.
3. Reguły budowane są w oparciu o fakty.
4. Reguły wyrażane są zdaniami w języku naturalnym (muszą być zrozumiałe dla ich wykonawców).
5. Reguły są od siebie niezależne (nie ma znaczenia kolejność ich użycia).
6. Wyjątki są także regułami (tu niestety należy wystrzegać się bardzo głupiego przysłowia o “wyjątku potwierdzającym regułę”)

Zarządzanie zorientowane na reguły

Generalnie reguły biznesowe wyznaczają pożądane zachowania (coś nakazują, czegoś zakazują). W firmach są zawarte (ukryte) w regulaminach, statutach, zakresach obowiązków, bieżących zarządzeniach, innych dokumentach o podobnych charakterze. Wyzwaniem jest ich zebranie i uporządkowanie, gdyż to one tak na prawdę stanowią LOGIKĘ BIZNESOWĄ danej organizacji. Reguł tych w organizacji mogę być nie raz setki, dlatego bardzo ważne jest ich porządkowanie. W notacji BMM mamy dwa pojęcia z tym związane:  polityka i reguła biznesowa. Polityka to nic innego jak określony kontekstowo zbiór reguł biznesowych (np. Polityka Bezpieczeństwa), tak więc reguły biznesowe grupujemy w tak zwane Polityki. Np. w ramach tworzenia Polityki Obsługi Klientów, można stworzyć regułę biznesową:

AKME Sp. z o.o. udziela odpowiedzi na każde otrzymane pismo nie zaklasyfikowane jako spam.

Kursywą zaznaczono nazwę własną nie wymagającą definicji. Podkreśleniem oznaczono fakty, pogrubieniem oznaczono pojęcia w słowniku (predykaty). Określenie “każde” jest funkcją zdaniową. Jak widać np. słowo spam jest pewnym klasyfikatorem, definicja tego pojęcia powinna być w słowniku, będzie narzędziem odróżniania (klasyfikacji) pism wartościowych od bezwartościowych. Definicja pojęcia to atrybuty pozwalające uznać dane “coś” za przynależne do tego pojęcia, np. spam to “każdy list mający mający w polu nadawca wartość “reklamy.pl” (definicja pojęcia może być długą listą wartości atrybutów – cech). Definicja pojęcia to cechy jakie musi spełnić coś by zostało uznane za “to”. Reguły biznesowe to sądy czyli logiczne dania, pojęcia połączone faktami. Sądem jest także uznanie czegoś za zgodne z definicją (że ma określone cechy). Przypominam, że reguła biznesowa opisuje zachowania a nie pojęcia, te są tu jedynie narzędziem opisu rzeczywistości dla tego zdarzenia.

Tak więc zamiast brać na siebie, jako prezes firmy, menedżer średniego szczebla itd. ogrom zdarzeń w postaci podejmowania decyzji za każdym razem, gdy jest taka wymagana, można stworzyć system polityk, zestawów reguł biznesowych, skutkiem czego firma będzie sprawnie funkcjonowała nie angażując, nawet do bardzo trywialnych zadań, wysokich rangą pracowników. Nie jest to delegowanie uprawnień, polityki i reguły biznesowe to rodzaj z góry podjętych decyzji. Owszem żadnej firmy nie da się zalgorytmizować, dlatego zawsze wyższe kadry będą potrzebne jednak ich kluczową rolą jest ustalanie zasad i zarządzanie nimi a bezpośrednie reagowanie powinno dotyczyć tego “niezalgorytmizowanego” zakresu zdarzeń (op. 20% :), reguła Pareto).

Zarządzanie zorientowane na reguły biznesowe to właśnie takie podejście: to czego można się spodziewać, opisujemy regułami, zdarzenia wyjątkowe obsługujemy osobiście. Reguły biznesowe warto zebrać w jedno miejsce, “wyjąć” je z przerośniętych opisów zakresów obowiązków i kompetencji, uporządkować zarządzenia zarządu.

Tu ktoś może powiedzieć, że mało która firma taki “porządek” ma i mimo to całkiem sprawnie one funkcjonują, i będzie miała rację. Ludzie doskonale sobie radzą z niejednoznacznością i zaskakującymi zdarzeniami. problem pojawia się, gdy trzeba spisać wymagania na oprogramowanie, i pojawi się rozdział o nazwie “Logika biznesowa”. Tu niestety albo pojawi się spójny opis jednoznacznych reguł, albo

wdrożenie czekają potężne kłopoty bo żadne oprogramowanie nie poradzi sobie z niejednoznacznością. 

Procesy biznesowe

O nich napisałem wiele, tu tylko skupię się na jednym: 2.2. Reguły nie są procesami ani procedurami. Nie powinny być w nich zawarte (Manifest). To kluczowa teza w modelowaniu procesów. Innymi słowy, przytoczonej reguły:

AKME Sp. z o.o. udziela odpowiedzi na każde otrzymane pismo nie zaklasyfikowane jako spam.

nie “rysujemy” na diagramie BPMN jako sekwencji kroków w rodzaju:

“weź pismo, sprawdź czy nie zawiera domeny reklamy.pl w adresie nadawcy, jeżeli tak to wyrzuć do kosza, jeżeli nie to opracuj odpowiedź”.

bo to prowadzi do masakrycznej złożoności diagramów. Po drugie w każdym procesie mającym “w sobie” zdarzenie związane z odpisaniem na pismo musielibyśmy  “narysować” powyższy ciąg czynności. Zarządzanie zmianą w takiej dokumentacji to koszmar. Model procesu powinien zawierać wyłącznie elementarne procesy biznesowe (aktywności z ich wejściem i wyjściem):

Wtedy będzie to bardzo treściwy i zrozumiały diagram. Tworzenie monstrualnych, nafaszerowanych szczegółami diagramów praktycznie niczemu i nikomu nie służy. Modele zawierające wrysowane “obrazkowo”  reguły biznesowe i procedury to niestety bardzo kosztowne i całkowicie nieprzydatne dokumenty. Jeżeli mają być “wsadem” do analizy wymagań są wręcz szkodliwe bo ukrywają sens logiki biznesowej w masie nadmiarowych szczegółów.

[przyp. 13.12.2015: bardzo ciekawie o “zaszumieniu modeli procesów” napisał Girish K C (Vice President, Process Reengineering and Implementation at HSBC) w artykule Reducing ‘Noise’ in a Business Process]

Kilka słów o logice dla zainteresowanych

Ważnym elementem jest tu “niestety” pojęcie predykatu,  które jest fundamentem tworzenia reguł biznesowych  (patrz pkt 5.3 Manifestu). W zdaniu “Jarek Żeliński jest człowiekiem” pojęcie “człowiek” jest predykatem, słowo “jest” jest funkcją zdaniową, zaś “Jarek Żeliński” jej argumentem. Predykat jest (może być) także nazwą klasy (klasyfikator: desygnuje grupę bytów mających wspólne cechy, to  zgodne z pojęciem klasy w UML, cecha także może być predykatem, podobnie jak atrybut klasy może być osobną klasą).

Możliwe są zdania z dwoma predykatami, np. “Każdy pracownik firmy XXX jest prawnikiem”. Mamy to dwa predykaty wymagające zdefiniowania w słowniku pojęć: “pracownik” i “prawnik”. Słowo “jest” to funkcja zdaniowa, słowo każdy to kwantyfikator.

To dlatego bardzo ważne jet tworzenie słownika pojęć biznesowych. Pojęcie to jest “to coś” o co nam w danym momencie chodzi, słowo takie jest desygnatem (nazwą tego czegoś), użycie słowa wskazuje, że “właśnie to pojęcie mam na myśli”. Jak widać kluczem jest tu model pojęciowy, czyli zbiór predykatów i ich znaczeń. Ważne jest także to, że poprawny model pojęciowy ma kontekst, tu biznesowy, dlatego definicje pojęć powinny być tworzone w tym kontekście np. definicja: człowiek to “osoba dorosła” zamiast ?istota żywa wyróżniająca się najwyższym stopniem rozwoju psychiki i życia społecznego? (sł. j.polskiego). Bardzo ważnym elementem jest tu także prawo “wyłączonego środka” w logice, wyrażone językiem naturalnym brzmi: “jeżeli coś jest czymś, to nie jest niczym innym”. Innymi słowy, jeżeli coś “pasuje” do określonej definicji pojęcia, nie może pasować do żadnej innej (jeżeli definicje są poprawnie zbudowane, tak się zresztą testuje, tu polecam specyfikację SBVR OMG (Semantics Of Business Vocabulary And Rules).

Jeżeli to zdanie jest tak zwanym sądem, to znaczy, że “prawdą jest, że Jarek Żeliński jest człowiekiem” (to zdanie zawiera jeden predykat i jeden argument). Sądy, dla ich tworzenia, muszą być oparta na obserwowalnych fatach (porównaj z Manifest pkt. 3.1.). Reguły biznesowe to właśnie tak zwane “sądy bazowe” opisujące daną organizację (jej zachowanie się). O sądach bazowych i ich budowaniu pisze [[Bertrand Russell]]:

To dlatego między innymi [[logika]] i [[epistemologia]] nie powinny być obce dobremu analitykowi.