Analityczno-jeździecka refleksja

Falkor pod Dorotą.

Falkor pod Dorotą.

Obserwując dzisiejszą pracę ze świeżo zajeżdżanym młodym wałachem fryzyjskim Falkorem nasunęła mi się refleksja, iż z zajeżdżaniem koni jest jak z analizą biznesową. Można się umówić ze zlecającym pracę na stałą cenę, a nawet określony termin; można się nawet z ceny i terminu wywiązać. Istnieje jednakże spore ryzyko, iż początkowy, szybki sukces zamieni się w dłuższej perspektywie w dotkliwą porażkę. Koń, przymuszony do pracy pod siodłem, z pominięciem jego potrzeb, charakteru, specyfiki dnia, kiedyś to pokaże. Zacznie się płoszyć, uciekać od właściciela, przeszkód, wędzidła, ręki…. Będzie do tzw. odróbki, która jest długa, niemiła i … do uniknięcia. Dużo lepiej poświęcić więcej czasu na ten początkowy etap, który może trwać 3, 5, 12 miesięcy, by przez kolejne naście lat cieszyć się z relacji z przyjaznym i szczęśliwym koniem.

Z analizą biznesową jest podobnie. Prowadzone warsztaty analityczne często wykazują, iż w organizacji istnieje głębszy problem, który należny rozwiązać, by można się było docelowo cieszyć jej pożądaną witalnością. Jest jednakże narzucony tajming, fikst prajs, więc wszystkie strony dążą do tego, by się z założeń i zobowiązań wywiązać. Determinacja jest tak silna, iż pomimo zdrowego rozsądku, nakazującego rozszerzenie zakresu prac, zwycięża fokus na targecie. Efekt…wdrożenie, zmian, których nie należało wdrażać, poniesienie kosztów, których nie należało ponosić, akceptacja  frustracji, której można było uniknąć.

Organizacja kiedyś ten błąd pokaże. Pewnie znajdzie się to w innym budżecie, u innego menedżera. Ale to już będzie tzw. odróbka.

Problem Business Process Management (BPM)

Pod koniec lat 90-tych miałem okazję uczestniczyć w programie szkoleniowym i certyfikacyjnym metodyki Geary’ego Rummlera. Firma przez niego prowadzona stawiała sobie między innymi za cel promowanie procesowego podejścia do usprawniania organizacji, z angielska nazywanego Business Process Improvement (BPI).

BPI, stanowiło już wówczas w metodyce Rummlera, element bardziej ogólnej filozofii zarządzania organizacją – Business Process Managament (BPM). Upłynęło naście lat, i wydawałoby się, że koncepcje te powinny już okrzepnąć i dobrze osadzić się w codzienności zarządczej, albo zostać odrzucone i zastąpione Jakimś Nowym-Lepszym. Mam wrażenie, że żaden z tych scenariuszy nie wystąpił. A jaki nastąpił? No właśnie…

Modelowanie procesów w dalszym ciągu jest realizowane. Bardzo często jako etap prowadzonych przedsięwzięć informatycznych. To dobrze, ale i źle, gdyż stworzone Modele Realizacji Prac (zwane, modelami procesowymi), służą wyspecyfikowaniu wymagań, po czym są odkładane Na Półkę, jako jeden z artefaktów Procesu Wytwórczego Oprogramowania. Modele (zwane, modelami procesowymi) są także tworzone w ramach inicjatyw usprawniania działań organizacji, dostarczając najczęściej efemeryczną wartość zespołom, które zmienią zasady pracy i…odłożą modele Na Półkę.

Ze świecą szukać organizacji, w których wszystkie wymienione działania stanowią element planowanego podejścia do zarządzania organizacją w sposób procesowy. Z przykrością stwierdzam, na bazie dotychczasowych spostrzeżeń, iż idea BPM w Polsce jest wiecznie żywa, ale wiecznie nierealizowana. Co gorsza, często ograniczona do wdrożenia narzędzi klasy BPMS, jest krytykowana za swoją złożoność i pracochłonność. Dlaczego, co gorsza? Powód jest trywialny – na pytanie, jaka jest stosowana metodyka zarządzania procesami biznesowymi, najczęściej pada odpowiedź „jaka metodyka?”. A jeśli już pada coś bardziej konkretnego, to jest to „własna metodyka” (czytaj:…no właśnie…). Na pytanie „czy oparta, na jakiejś dobrze znanej”, odpowiedź najczęściej nie jest udzielana.

Zastanawiające jest to, jak mało chcemy wkładać pracy w nauczenie się i wdrożenie jakiegoś spójnego mechanizmu zarządczego. jak bardzo chcemy szybko osiągnąć spektakularny sukces. Jak szybko negatywnie oceniamy rzeczy, których dobrze nie poznaliśmy. I jak łatwo podejmujemy decyzję o zarzuceniu Tego Co Zaczęte I Nie Ukończone i rozpoczęciu Tego Co Obiecujące.

Reguły biznesowe a reguły decyzyjne

DecyzjaPojęcia te, jak zauważam, są stosowane zamiennie. A nie powinny. Można uznać, iż reguła decyzyjna, rozumiana jako wiedza potrzebna do podjęcia określonej decyzji w określonym miejscu funkcjonowania organizacji, jest szczególnym rodzajem reguły biznesowej. Aczkolwiek, pojęcie reguły biznesowej jest dużo szersze.

Próbując zarysować różnicę pomiędzy pojęciami, warto przypomnieć sobie wpływ reguły biznesowej na przebieg procesu biznesowego, opisany we wpisie RuleSpeak: behawioralne reguły biznesowe a model procesów. Omawiany w nim przykład pokazywał, iż konieczność przypisania dedykowanego sprzedawcy do obsługi zamówienia priorytetowego może sprawić problem przy: obsłudze zamówienia, obsłudze zatrudnienia pracowników (rozstanie się z pracownikiem pełniącym taką rolę wobec zamówień, długotrwała nieobecność pracownika, itd.). Fakt złamania reguły biznesowej i wynikająca z niego konieczność wykonania określonych działań korekcyjnych nie jest decyzją sensu stricte, lecz obsługą wystąpienia, przewidzianego w modelu organizacji, zdarzenia.

Reguły decyzyjne mają inne zastosowanie. Ich celem jest opisanie wiedzy potrzebnej do podjęcia określonej decyzji w określonym miejscu przebiegu procesu biznesowego (na potrzeby wpisu, ograniczę rozważania do organizacji zarządzanej procesowo). Zakłada się, iż decyzja taka ma charakter powtarzalny (czyli, powołanych zostanie wiele instancji procesu, zawierającego odwołanie do reguły decyzyjnej) i bardziej operacyjny, niźli strategiczny (aczkolwiek tak być nie musi). Przykład procesu, który mógłby być uzupełniony o regułę decyzyjną, przedstawia poniższy diagram.

Przykład przebiegu procesu zawierającego miejsce podejmowania decyzji

Przykład przebiegu procesu zawierającego miejsce podejmowania decyzji

W zależności od liczby kryteriów branych pod uwagę przy wyznaczaniu sposobu obsługi Zamówienia, liczby przypadków decyzyjnych oraz ustalonych standardów architektury biznesowej, logika decyzyjna mogłaby się znaleźć na przepływach warunkowych bądź też zostać ukryta w regułach decyzyjnych (opisanych, na przykład, tabelami decyzyjnymi), skutkując umieszczeniem na przepływach warunkowych wyników procesu decyzyjnego; takie podejście zostało zilustrowane na prezentowanym diagramie.

Ustanawiając docelowy sposób opisywania logiki decyzyjnej, warto brać pod uwagę nie tylko aspekt dokumentacyjny, ale w co najmniej równym stopniu, również aspekt facylitacyjny. Z mojego doświadczenia wynika, iż umiejętne stosowanie na przykład tabel decyzyjnych, w zauważalny sposób może przyczynić się do zwiększenia efektywności i skuteczności prac analitycznych dając w efekcie dobry jakościowo produkt.

Więcej o współczesnych metodach tworzenia modeli decyzyjnych, w tym między innymi o DecisionSpeak™ oraz The Decision Model,  będzie można poczytać w kolejnych wpisach.

RuleSpeak: Reguły definicyjne

RSRozpatrzmy dwie reguły biznesowe:

  1. Zamówienie musi być uznane za priorytetowe jeśli zamówienie zostało złożone przez Klienta strategicznego.
  2. Całkowita wartość zamówienia musi być obliczana jako suma wartości jego pozycji.

W przypadku pierwszej reguły, na bazie określonego zestawu informacji (koncepcji rzeczownikowych oraz czasownikowych) nakazano określone wnioskowanie. W drugim przypadku, nie tyle wywnioskowano, co podano obowiązkowy sposób wyliczania określonej wartości. Reguły biznesowe tych dwóch typów nazywane są regułami definicyjnymi.

Model koncepcji dla rozważanego przykładu

Model koncepcji dla rozważanego przykładu

Definicja a reguła definicyjna.

Elementem zbliżonym koncepcyjnie do reguły definicyjnej jest…definicja. Słownik języka polskiego PWN definiuje pojęcie definicja następująco:

Definicja – objaśnienie znaczenia wyrazu, wyrażenia lub pojęcia.

W przeciwieństwie do reguły biznesowej, definicja koncentruje się więc na wyjaśnieniu znaczenia, abstrahując od jakiejkolwiek nakazowości. Definicja pojęcia Zamówienie priorytetowe, mogłaby wyglądać następująco: Zamówienie priorytetowe – zamówienie, złożone przez Klienta strategicznego.

Z punktu widzenia chronologii powstawania elementów architektury biznesowej, pierwotnym pojęciem wydaje się być definicja, a pojęciem wtórnym – reguła definicyjna, jawnie zmniejszająca stopień swobody osób uczestniczących w życiu organizacji. Warto też zauważyć, iż reguła definicyjna może być w pełni wnioskowana na podstawie definicji.

Istnienie zarówno definicji, jak i reguły definicyjnej ma swoje uzasadnienie. Definicja stanowi informację, pozwalającą zrozumieć rzeczywistość biznesową. Ponadto, definicji nie można złamać, gdyż nie skutkuje ona powstaniem jakiegokolwiek obowiązku. Reguła definicyjna, z natury swojej, ma na celu nakazanie uznania czegoś za fakt. Skoro niesie obowiązek, to, podobnie jak reguła behawioralna, może zostać złamana poprzez niezastosowanie się doń. Aczkolwiek, w przypadku reguły definicyjnej, nie tyle groźne są konsekwencje jej złamania, co niezastosowania się do  reguł behawioralnych, bazujących na nakazanym wnioskowaniu, czy wyliczeniu.

Na zakończenie

Zwierzę musi być uznane za ptaka jeśli wszystkie następujące warunki są prawdziwe. Zwierzę:

  • ma ciało pokryte piórami,
  • ma dwie nogi,
  • ma jeden dziób,
  • ma dwa skrzydła, dzięki którym potrafi latać.

Czy jest to reguła biznesowa? Według SBVR:

Business rule – rule that is under business jurisdiction.

Dla większości znanych mi  organizacji, reguła definiująca ptaka nie podlega jej jurysdykcji, więc za regułę biznesową uznawać jej nie należy. Można uznać, że ptak jest ogólną koncepcją, która we wszystkich biznesowych okolicznościach posiada to samo znaczenie. Czym wobec tego jest? SBVR definiuje bazowe pojęcie reguły (rule), jako:

Rule – proposition that is a claim of obligation or of necessity.

Wydaje się, iż rozważane stwierdzenie należy zaklasyfikować właśnie jako regułę. Warto o tym pamiętać, by opracowując zestaw reguł biznesowych organizacji, koncertować się przede wszystkim na regułach biznesowych. Do reguł można się odwoływać, natomiast nie trzeba ich katalogować jako specyficznych dla organizacji.

RuleSpeak: behawioralne reguły biznesowe a model procesów

RSRuleSpeak oraz SBVR (w tej kolejności należy chyba wymieniać te standardy, z racji na czas ukazania się na rynku) definiują behawioralną regułę biznesową jako typowe zdanie deontyczne, w którym normą jest wewnątrzorganizacyjne (biznesowe) ustalenie. Reguła behawioralna stanowi więc nakaz, zakaz lub przyzwolenie dla określonego stanu. Przykładem zapisu reguły behawioralnej może być zdanie Zamówienie priorytetowe musi mieć przypisanego dedykowanego sprzedawcę.

Reguła biznesowa, jak widać na powyższym przykładzie, ma wartość samą w sobie, stanowiąc pełnoprawny element opisu architektury biznesowej, bazującej na określonym modelu koncepcji (patrz niżej).

Model koncepcji

Model koncepcji

Pomimo swojej integralności, wartościowe z punktu widzenia architektury biznesowej, byłoby powiązanie behawioralnej reguły biznesowej z elementami opisu organizacji, które w jakikolwiek sposób są od reguły uzależnione. W przypadku organizacji opisanej  procesami (co oczywiście jeszcze nie oznacza, zarządzanej procesowo), takimi elementami mogą być procesy biznesowe, kroki procesów biznesowych oraz jednostki organizacyjne pełniące role opisane w przebiegach procesów. Przyglądając się opisom procesów, łatwo zauważyć, iż wspomniana reguła biznesowa powinna być brana pod uwagę w obszarach przyjmowania zamówienia oraz…zarządzania sprzedawcami. Dlaczego? Jak łatwo się domyślić, powody są dwa:

  • w tych obszarach istotna jest wiedza o regule, pozwalająca na zachowanie zgodności z ustalonym ładem, oraz
  • w tych obszarach możliwe jest niezastosowanie się do ograniczenia (a co za tym idzie, zainicjowania ewentualnych działań będących konsekwencją niedostosowania się do ustalonego ładu).

Powiązanie reguły biznesowej z krokiem w procesie przedstawia poniższy rysunek. Można z niego literalnie przeczytać, iż krok Przyjęcie zamówienia, jest uzależniony od reguły biznesowej Sprzedawca dedykowany dla zamówienia priorytetowego. Co jednakże należy wykonać w sytuacji, gdy taka reguła zostanie złamana?

Reguła biznesowa wkomponowana w przebieg procesu biznesowego

Reguła biznesowa wkomponowana w przebieg procesu biznesowego

Graficzna reprezentacja reguły biznesowej nie daje odpowiedzi na pytanie. Szukać jej należy w definicji reguły biznesowej, a dokładniej w cesze enforcement level, określającej konsekwencje niedostosowania się do reguły. Standard SBVR nie określa poziomów cechy, natomiast odwołuje się do standardu BMM (Business Motivation Model), w którym określono pięć poziomów, począwszy od najbardziej restrykcyjnego – strictly enforced, na najmniej restrykcyjnym zakończywszy – guideline. Zakładając w rozważanym przypadku najbardziej restrykcyjną politykę, można sobie wyobrazić, iż rozwiązanie umowy z osobą pełniącą rolę dedykowanego sprzedawcy w stosunku do zamówień priorytetowych, bez zadbania o przekazanie prowadzonych zamówień innej osobie, może skutkować złamaniem reguły.

Obsługa zdarzenia reprezentującego fakt złamania reguły biznesowej

Obsługa zdarzenia reprezentującego fakt złamania reguły biznesowej

Powyższy diagram prezentuje przykładowe działania będące efektem takiej sytuacji. Zdarzenie warunkowe Zamówienie priorytetowe bez dedykowanego sprzedawcy zostało jawnie skojarzone z regułą biznesową, gdyż fakt jego wystąpienia jest efektem istnienia reguły. Efektem wystąpienia zdarzenia jest podjęcie działań przez określoną rolę, w ramach określonego procesu.

Potencjalny, bardziej elastyczny, model obsługi zdarzenia można byłoby stworzyć, wykorzystując zalecenia nowo powstającej techniki The Event Model. Ale o tym, w osobnym wpisie.

Podsumowanie

Biznesowe reguły behawioralne stanowią integralny i bardzo istotny element architektury biznesowej. Z punktu widzenia procesowego podejścia do opisu pracy realizowanej w organizacji, istotną cechą tego rodzaju reguł jest potencjalne generowanie zdarzeń reprezentujących fakt ich złamania, a co za tym idzie, opisania, w ramach procesowego modelu organizacji, działań usuwających powstały problem. Z punktu widzenia artefaktów architektonicznych, skutkuje to stworzeniem jednej reprezentacji reguły biznesowej oraz wielu związków łączących regułę z innymi elementami architektury biznesowej.

A skąd wiadomo, kiedy Zamówienie jest priorytetowe? O tym, przy okazji kolejnego wpisu o regułach biznesowych.