Czy reguła biznesowa to wymaganie?

Wielokrotnie spotkałem się z sytuacjami, w których reguły biznesowe oraz wymagania wobec IT były traktowane jako różne rodzaje tej samej koncepcji. A to niedobrze, gdyż z wielu powodów nie powinno się tych pojęć tak traktować, jako że prowadzi to do…o czym poniżej.

Definicji reguł biznesowych jest całkiem sporo. Co ciekawe, nawet wśród tych samych autorów, definicje zmieniają się z czasem. Mi najbardziej odpowiada ta, zaproponowana przez Business Rules Group.

Business Rule is a directive that is intended to influence or guide business behavior. 

Business Rules Group, 1998

Definicja wyraźnie wskazuje, że celem specyfikowania reguł biznesowych jest jawne określenie zasad, które powinny być brane pod uwagę podczas prowadzenia działań biznesowych. Rozpatrując reguły biznesowe z punktu widzenia siatki Zachmana, należy uznać, iż stanowią element drugiej z perspektyw, na równi z modelem pojęć, czy modelem przebiegów procesów biznesowych.

Spróbujmy przeanalizować zależności łączące reguły biznesowe z innymi aspektami architektury biznesowej, w tym architektury IT. Załóżmy, że zajmujemy się tematem zakładania rachunku bankowego w instytucji finansowej. Hipotetycznie, możemy przyjąć, że o założenie rachunku bankowego może wnioskować tylko osoba pełnoletnia. Aby to założenie biznesowe zapisać w terminach reguł biznesowych, posłużymy się stylistyką RuleSpeak. Reguła mogłaby wówczas przyjąć brzmienie:

Wniosek o założnie rachunku bankowego MOŻE złożyć TYLKO osoba, która jest pełnoletnia.

Co taka reguła oznacza z punktu widzenia architektury biznesowej. Po pierwsze, mamy tutaj odwołania do dwóch pojęć oraz jednego faktu je łączącego. Pojęcia to Wniosek o założenie rachunku bankowego oraz Osoba. Fakt, to składa. Dbając o porządek w repozytorium architektury biznesowej, powinniśmy mieć odnotowane te zależności, co mogłoby przyjąć następującą postać.

Przykładowy model pojęć
Rysunek 2 Reguła biznesowa odwołująca się do modelu pojęć

Niektóre narzędzia służące do tworzenia modeli architektury biznesowej automatycznie rozpoznają, czy we wprowadzanej treści reguły biznesowej znajdują się odwołania do modelu pojęć i łączą zidentyfikowane frazy z pojęciami. Przykłd tego typu funkcjonalności dostępnej w narzędziu Visual Paradigm prezentuje Rysunek 2.

Mając już regułę biznesową opartą o model pojęć, możemy zastanowić się, co w praktyce mogłaby oznaczać część definicji reguły biznesowej, nawiązująca do jej wpływu na działania biznesowe. Spójrzmy najpierw na jeden z najbardziej typowych elementów architektury biznesowej – modele procesów biznesowych. Zwykle prezentują one działania realizowane przez ich uczestników oraz kolejność realizacji działań. Dla przykładu, Rysunek 3 prezentuje początek hipotetycznego procesu biznesowego, mającego na celu założenie rachunku bankowego. Proces jest inicjowany przedłożeniem przez osobę wnioskującą wypełnionego wniosku. Pracownik Biura Obsługi Klienta następnie weryfikuje ten wniosek i jeśli wszystko jest poprawnie wypełnione przekazuje go do dalszej realizacji. Zakładając na początek, że nie posiłkuje się tutaj żadnym systemem, obowiązkiem pracownika będzie zdobycie kompetencji pozwalających na pełną weryfikację wniosku. Między innymi pod kątem pełnoletniości.

Jak można byłoby zinterpretować to z punktu widzenia tworzonego modelu? Na przykład, tak jak na poniższym rysunku – możemy uznać, iż wprowadzona przez nas reguła biznesowa powinna być powiązana z tym krokiem procesu, gdyż w jego ramach może zostać … złamana. Wprawdzie reguły istnieją niezależnie od kroków procesów, aczkolwiek warto je łączyć tylko z tymi, w których mają jakiekolwiek znaczenie.

Rysunek 3 Reguła biznesowa powiązana z krokiem procesu biznesowego

A co w sytuacji, gdybyśmy wraz z planowaniem nowego przebiegu procesu zamierzali wdrożyć system informatyczny, który wesprze pracę uczestników procesu? Musielibyśmy jakoś umieć wkomponować w powstający, docelowy model funkcjonowania organizacji oczekiwania wobec IT. W metodyce AION, pierwszy etapem specyfikowania tego typu wymagań, jest ich zogniskowanie wokół tych kroków procesu, które wymagają wsparcia. Rysunek 4 prezentuje diagram wymagań, zgodny z podejściem AION dla omawianego przykładu. Na bazie kroku biznesowego, w którym miałaby nastąpić rejestracja wniosku w systemie, zdefiniowane zostało wymaganie dotyczące konieczności weryfikacji wniosku względem reguł biznesowych. Warto zwrócić uwagę, iż w treści wymaganie nie zostały wprowadzone warunki, względem których wniosek należy zweryfikować. Zamiast takiego zabiegu (wprowadzałby on redundancje informacji do modelu), wprowadzono zależność łączącą wymaganie z istniejącą regułą biznesową. Gdyby reguł było więcej, w dalszym ciągu pozostałoby jedno wymaganie, które byłoby skojarzone z większa liczbą reguł biznesowych. Tak wyspecyfikowane wymaganie jest następnie powiązane relacją <<satisfy>> z przypadkiem użycia, który w analizie systemowej będzie prezentował sposób realizacji wymagania. Oczywiście, aby przykład był kompletny, do modelu powinno się wprowadzić więcej wymagań związanych z krokiem. W przypadku niniejszego wpisu koncentrujemy się jednakże jedynie na zależnościach pomiędzy wymaganiem a regułą biznesową, więc uzupełnianie nie wydaje się być konieczne.

Rysunek 4 Diagram wymagań prezentujący zależności pomiędzy elementami architektury biznesowej oraz systemowej w omawianym przykładzie
Rysunek 5 Diagram przypadków użycia dla omawianego przykładu

Jak należałoby rozszerzyć model, gdyby się okazało, iż funkcjonalność związaną z wprowadzaniem wniosku chcielibyśmy udostępnić w kanałach elektronicznych, przerzucając ciężar prac z pracownika BOK na Klienta instytucji? Z pewnością należałoby uzupełnić model procesów o scenariusz, w którym Klient wykorzystuje dobrodziejstwa IT, dzięki czemu w procesie nie występuje już Pracownik BOK. Zapewne, w dalszym ciągu obowiązek pełnoletności powinien być spełniony, więc, wykorzystamy już istniejącą regułę biznesową do tego, by skojarzyć ją z nowym krokiem biznesowym. Wyprowadzając z kroku wymagania dla nowego systemu, zdefiniujemy nowe wymaganie do weryfikacji, ale powiążemy je z istniejąca regułą, gdyż ona się nie zmieniła. Dzięki takim zabiegom, mamy jedną regułę biznesową i wiele miejsc w modelu, które się w różnych kontekstach do niej odwołują. Utrzymywanie powiązań pomiędzy elemenatmi w modelu znacząco ułatwi analizę wpływu zmiany reguły biznesowej na architekturę biznesową i IT.

Czy reguły biznesowe to wymagania? Nie. Czy są z nimi związane? Mogą być.

Ad vocem: IT czy nie IT, oto jest pytanie.

RulesPanie Pawle, przede wszystkim dziękuję za tak obszerne odniesienie się do wpisu. Mam nadzieję, że poruszenie tej tematyki stanowi zwiastun obszerniejszej dyskusji na temat efektywności i skuteczności dostępnych technik analitycznych.

Przechodząc do meritum, reguły biznesowe, stojące za nimi polityki, procesy biznesowe od nich zależne, cele biznesowe oraz środki ich osiągania stanowią elementy architektury biznesowej, a z punktu wiedzenia procesów wytwórczych oprogramowania, do jakich Pan nawiązuje, składowe warstwy CIM (Computation Independent Model) w terminologi MDA (Model Driven Architecture).  Kluczowe przesądzenia dokonane w warstwie opisu biznesowego otoczenia rozwiązania informatycznego, w części związanej z regułami biznesowymi, stanowić powinny wsad do zasilania maszyn regułowych; a zgodnie z zaleceniami MDA, zachowane winno zostać śladowanie pomiędzy elementami warstwy wyższej a ich reprezentacją w warstwach niższych (PIM, PSM).

Z tego punktu widzenia, reprezentacja reguł biznesowych, czy decyzyjnych w narzędziach służących do ich automatyzacji stanowi jeden z wielu aspektów opracowywania rozwiązań informatycznych wspierających określony obszar biznesowy. Warstwa ta może wspierać opracowane wcześniej zasady funkcjonowania organizacji, aczkolwiek wsparcie takie nie zawsze jest wymagane. Jako przykład można podać ośrodek jeździecki. Łatwo sobie wyobrazić, iż jedną z nadrzędnych polityk w takim miejscu jest nieustanna troska o bezpieczeństwo osób korzystających z usług ośrodka. Mówimy w tym przypadku o polityce, a nie regule biznesowej, gdyż tak ogólne sformułowanie jest nieegzekwowalne w praktyce i powinno zostać doprecyzowane. Z polityki można wyprowadzić regułę biznesową, której można nadać brzmienie Jeździec korzystający z ujeżdżalni musi mieć założony kask. Poniższy rysunek prezentuje opisywane fragment modelu biznesu z wykorzystaniem terminologii Business Motivation Model.

Polityka i wynikająca z niej reguła biznesowa

Polityka i wynikająca z niej reguła biznesowa

W kontekście prowadzonej dyskusji w oczy rzuca się fakt, iż odnotowana reguła biznesowa, stanowiąca opis funkcjonowania organizacji, jest wyspecyfikowana niezależnie od jakiegokolwiek wsparcia rozwiązaniem informatycznym. Z bardzo dużym prawdopodobieństwem, nigdy takim rozwiązaniem nie będzie wsparta, natomiast jej obecność powinna być znana wybranym pracownikom ośrodka jeździeckiego wraz ze stopniem oraz sposobami jej egzekwowania.

W swoim wpisie, do którego Pan nawiązał, odwołuję się do tego poziomu opisu reguł biznesowych. W moim przekonaniu, to za nie odpowiedzialność powinien brać tzw. Biznes, począwszy od określenia zapotrzebowania na nie, a na jednoznacznym wyspecyfikowaniu zakończywszy (prawdopodobnie, korzystając z pomocy analityków biznesowych). Sposób ewentualnego wsparcia dokonanych ustaleń biznesowych rozwiązaniem informatycznym, jego architektura i konfiguracja stanowią osobne zagadnienie, którego kluczowe przesądzenia zostaną zapisane w warstwie PIM. Jaki będzie udział specjalistów dziedzinowych w utrzymaniu systemu – to kwestia do każdorazowego ustalenia. Nie jestem jednakże przekonany, iż optymalnym rozwiązaniem jest delegowanie ludzi biznesu do konfigurowania maszyn regułowych; lepszym rozwiązaniem byłoby posłużenie się wyspecjalizowanym w tym kierunku analitykiem biznesowym.

 

IT czy nie IT, oto jest pytanie.

RulesSurfując po sieci, natrafiłem na post zamieszczony na niniejszym blogu, którego fragment przykuł moją uwagę na dłuższą chwilę:

Wydaje się, iż delegowanie ludzi Biznesu do pracy z typowo informatycznymi narzędziami, jakimi są maszyny regułowe, nie jest działaniem optymalnym z punktu widzenia skuteczności i efektywności prac w ramach architektury biznesowej.„  źródło

Pomyślałem, że często, spotykając się z klientami biznesowymi, stykam się z takim przekonaniem, że zmiany w systemach informatycznych powinny robić osoby, które się na tych systemach znają. Zazwyczaj zaraz za taką tezą pada kolejna:

„…niestety nawet proste zmiany trwają strasznie długo i czasem kosztują absurdalnie dużo”.

Moim zdaniem myślenie w ten sposób jest spowodowane przyzwyczajeniem do tego, że w technologiach i przy architekturze systemów sprzed kilku lub kilkunastu lat zmiany były możliwe tylko w kodzie przez programistów – magików. Nie ma to najczęściej nic wspólnego z możliwościami współczesnych systemów informatycznych.

Już jakiś czas temu rozpoczęła się lekka odwilż w takim myśleniu o temacie i przy tworzeniu specyfikacji rozwiązania informatycznego coraz częściej pojawiają się zapisy o „konfiguracji biznesowej”. Najczęściej ma ona postać listy parametrów, które użytkownik z odpowiednimi uprawnieniami może zmienić bezpośrednio w aplikacji.

Nie zawsze tak musi być

Dwa lata temu miałem przyjemność uczestniczyć w projekcie, w którego wymaganiach pojawiło się coś więcej – możliwość zmiany algorytmów decyzyjnych przez zamawiającego.

Całą  wymaganą „konfigurację biznesową” oraz wszystkie reguły biznesowe, tablice decyzyjne czy algorytmy przenieśliśmy do osobnego rozwiązania, które umożliwiło w sposób graficzny modyfikować te elementy systemu (kilka informacji na temat jego architektury można znaleźć tutaj „Zastosowanie zewnętrznego silnika obliczeniowego w systemie IT”). Przy realizacji tego zamówienia cały czas zastanawialiśmy się, czy rzeczywiście klient weźmie na siebie odpowiedzialność za zmiany i będzie w stanie  je realizować we własnym zakresie.

System został wdrożony. Na początku wyznaczony analityk klienta realizował drobne zmiany, głównie dotyczące pojedynczych wartości liczbowych: stawek, wartości procentowych, wysokości limitów, itp. Zmiany w algorytmach, nawet te najprostsze, trafiały do nas.

Po pół roku funkcjonowania systemu zostaliśmy poproszeni o przeprowadzenie szkolenia z konfiguracji silnika obliczeniowego na poziomie zaawansowanym dla kilku pracowników. Obecnie, to właśnie osoby biznesowe zarządzają pełną konfiguracją w tym obszarze.

To właśnie „ludzie biznesu” dostrzegli potencjał, jaki daje im takie podejście:

  • nie trzeba czekać na dostępność „zasobów” zewnętrznych działów,
  • nie trzeba nikomu tłumaczyć, co należy zmienić,
  • nie trzeba spisywać dokumentacji,
  • nie trzeba podpisywać dodatkowych umów CR,
  • koszt zmiany jest praktycznie zerowy, a niektóre pojedyncze, drobne zmiany można przeprowadzić w kilkanaście minut.

Takie podejście pozwala im na samodzielne i dynamiczne sterowanie procesami i logiką działania wielu obszarów aplikacji końcowej: funkcjonalności sprzedażowych, windykacyjnych, przydzielania prowizji czy oceny klienta. Pozwala to na szybkie reagowanie na to, co dzieje się aktualnie na rynku (więcej o tym projekcie można znaleźć „Elastyczne reguły – elastyczny biznes”).

Podsumowanie

Najważniejszym krokiem i zmianą, która była potrzebna w organizacji nie jest system informatyczny – klient już go miał. Zmianie musiał ulec sposób postrzegania tego, czym jest konfiguracja biznesowa i co tak naprawdę współczesne systemy informatyczne pozwalają bezpiecznie modyfikować bez konieczności zmian w kodzie. Gdy klient zna biznes, zmiana wielu elementów, przy zachowaniu odpowiednich zasad, jest bezpieczna.

Z roku na rok dostrzegam wzrost świadomości możliwości technologii i wzrost kompetencji w firmach wspierających swoją działalność systemami informatycznymi. Dzięki temu, że rozwiązania informatyczne mają coraz większe możliwości konfiguracji, zadania, które kiedyś były możliwe do wykonania przez programistów stają się możliwe do wykonania przez osoby z wiedzą biznesową. Zyski z takiego podejścia zachęcają kolejne firmy do inwestowania w technologie, które im to umożliwiają.

Autor: Paweł Ociepka, http:/www.algorithmssystem.com/blog/

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.

RuleSpeak a implementacja w narzędziach

RSPodczas jednej z rozmów z analitykami biznesowymi dużej instytucji finansowej dyskutowaliśmy temat sposobu integracji reguł biznesowych z modelem procesów biznesowych. Temat wyszedł zupełnie przy, tak zwanej, okazji i przy tej samej okazji zdominował całe spotkanie. Punktem wyjścia było zapytanie, czy i w jaki sposób biznes ma specyfikować reguły w maszynie regułowej, która będzie następnie wykorzystana do implementacji zautomatyzowanych procesów podczas udzielania kredytów hipotecznych. Przyczynkiem do zapytania były zaś planowane szkolenia dla specjalistów dziedzinowych banku z zakresu obsługi maszyny regułowej w zakresie specyfikowania reguł. Na pytanie, skąd pomysł, aby specjaliści dziedzinowi mieliby być odpowiedzialni za zasilanie maszyny regułowej regułami, padła odpowiedź, iż taka jest decyzja IT, uzasadniona tym, iż reguły biznesowe, jak sama nazwa wskazuje, są regułami biznesu i to właśnie Ludzie Biznesu, powinni nimi zarządzać.

Z ostatnią częścią zdania należy się zgodzić, natomiast nie wydaje się, by specjaliści dziedzinowi byli odpowiednimi osobami do zasilania maszyn regułowych informacjami, gdyż podobnie jak narzędzia do automatyzacji procesów, są to składniki wykonawczo-uruchomieniowej platformy informatycznej. Osoby odpowiedzialne za kształt reguł biznesowych i przyświecających im polityk (nomenklatura Business Motivation Model), powinni dysponować narzędziami, które wspierają ich w tym działaniu i abstrahują od ich wsparcia technologiami informatycznymi. Najprościej uargumentować tę tezę faktem, iż w każdej organizacji istnieje spora liczba reguł biznesowych, które nigdy nie będą wspierane bezpośrednio rozwiązaniami informatycznymi, a jednocześnie ich istnienie w zasobach informacyjnych firmy jest istotne (najczęściej, reguły takie są specyfikowane w różnej maści procedurach i rozporządzeniach, stanowiąc bardzo rozproszone repozytorium architektury biznesowej). Innym argumentem jest spory dysonans pomiędzy naturalnym językiem specjalistów dziedzinowych, a językiem maszyn regułowych.

Skoro jednak nie w maszynach, nie w procedurach (czytaj: edytorach tekstu), to gdzie?

Reguła biznesowa

Nim odpowiem na pytanie „gdzie”, przypomnę definicję reguły biznesowej, zamieszczoną w specyfikacji SBVR.

Business rule – rule that is under business jurisdiction.

Oznacza to, iż Biznes (specjalista dziedzinowy) odpowiada za specyfikowanie i utrzymanie w aktualnej postaci zasad przezeń ustanawianych.

Czym jest rule?

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

Innymi słowy, rule, jest ograniczeniem swobody postępowania, podczas gdy, reguła biznesowa, jest ograniczeniem wynikającym z decyzji określonego Biznesu. Decyzji Biznesu, określonej przez Biznes.

Dedykowane narzędzia do zarządzania regułami biznesowymi

Idealnym miejscem na repozytorium tego rodzaju informacji są dedykowane narzędzia, pozwalające na specyfikowanie precyzyjnych, jednoznacznie zrozumiałych reguł biznesowych w języku naturalnym, albo bardzo do niego zbliżonym. Najbardziej zaawansowanym, spośród znanych mi produktów jest RuleXpress (url), rozwijany w ścisłej współpracy z Ronaldem Rossem oraz Silvie Spreeuwenberg, oparty o język RuleSpeak – zgodny ze standardem SBVR. Integralną częścią narzędzia jest produkt o nazwie FactXpress (url), umożliwiający tworzenie modelu koncepcji, na którym bazują specyfikacje reguł biznesowych. Z uwagi na brak doświadczenia w stosowaniu produktu, nie będe zagłębiaj sie w jego funkcjonalność; pozwolę sobie natomiast napisać ciut więcej na temat innego produktu, który od wielu lat mam okazję wykorzystywać.

Visual Paradigm

Visual Paradigm (url) jest zaawansowanym narzędziem do tworzenia modeli zarówno na poziomie architektury biznesowej jak i rozwiązań informatycznych wspierających funkcjonowanie organizacji. Jest jednocześnie jedynym znanym mi narzędziem tej klasy, które w tak zaawansowany sposób wspiera definiowanie reguł biznesowych

Podobnie, jak w przypadku wspomnianego produktu RuleXpress, Visual Paradigm umożliwia tworzenie modelu koncepcji według zasad określonych przez Ronalda Rossa. Więcej o języku napiszę w kolejnych wpisach dotyczących modelu koncepcji, natomiast teraz ograniczę się jedynie do zamieszczenia mini modelu, którym chciałbym się odwołać do intuicji.

 

Model koncepcji

Model koncepcji

Rozkładając rysunek na SBVR’owe składowe, widać, iż zdefiniowane(1) zostały dwie ogólne koncepcje rzeczownikowe (Klient, Zamówienie), oraz jedna koncepcja czasownikowa (złożone przez). Stosowana w treści wpisu terminologia metamodelu SBVR pochodzi z autorskiego jego przełożenia na język polski przez firmę AION. Fragment metamodelu dotyczący omawianego zakresu prezentuje poniższy rysunek.

Fragment metamodelu SBVR

Fragment metamodelu SBVR

Utworzony model koncepcji stanowi fundament dla definiowania reguł biznesowych, które powinny się doń odnosić. Zgodnie z zasadami opisanymi w języku RuleSpeak (patrz: wpis o polskiej wersji języka RuleSpeak), definiując reguły biznesowe powinno się wykorzystywać zarówno określony szyk zdania, jak i słowa kluczowe, o jasno określonym znaczeniu.

Powracając do narzędziowego aspektu zarządzania regułami biznesowymi, poniższy rysunek prezentuje graficzną reprezentację reguły biznesowej w Visual Paradigm, będącą autorska propozycją producenta produktu. Standardowo, reguła biznesowa jest reprezentowana jako prostokąt o ściętym lewym, dolnym roku z nazwą oraz identyfikatorem umieszczonym wewnątrz.

Symbol reguły biznesowej

Symbol reguły biznesowej

Treść reguły biznesowej, jest opisywana w edytorze reguł, którego główną wartością jest wykrywanie w treści wyrażeń pisanych w języku naturalnym odwołań do koncepcji oraz słów kluczowych i tworzenia fizycznych doń odwołań. Dla przykładu, reguła biznesowa Zamówienie klienta, została wyspecyfikowana jako Zamówienie musi być złożone przez dokładnie jednego Klienta. Z treści reguły biznesowej jasno wynika, iż odwołano się w niej do koncepcji: Zamówienie, Klient oraz złożone przez. Odwołana te zostały wykryte przez narzędzie i odpowiednio wyróżnione, co prezentuje poniższy rysunek.

Reguła biznesowa w narzędziu Visual Paradigm

Reguła biznesowa w narzędziu Visual Paradigm

Wnikliwy czytelnik z pewnością zauważy, iż koncepcją która została zdefiniowana w modelu jest Klient, podczas gdy w treści reguły biznesowej dokonano odmiany słowa, umieszczając w niej słowa Klienta. Niestety, narzędzie nie wykrywa automatycznie odmiany przez przypadki, natomiast udostępnia mechanizm, przy pomocy którego problem można rozwiązać. Z każdą koncepcją można bowiem skojarzyć synonimy (w narzędziu: Alias), i jako synonim potraktować..odmieniony wyraz, tym sposobem uzyskując oczekiwany rezultat.

Synonimy

Synonimy

Druga z obserwacji, jaką można poczynić analizując treść reguły biznesowej, jest fakt wyróżnienia wyrażenia musi. To z kolei wynika z wykrycia zdefiniowanego słowa kluczowego języka RuleSpeak, stanowiącego element konfiguracyjny produktu. Zgodnie z zaleceniami polskiej wersji tłumaczenia RuleSpeak, wyrażenie musi – będąc odpowiednikiem angielskiego must –  stanowi słowo kluczowe, wskazujące na obligatoryjność warunku po nim następującego. Poniższy rysunek przedstawia omawianą funkcjonalność pakietu Visual Paradigm. Oprócz słów kluczowych wprowadzono do narzędzia także zalecane sformułowania, dzięki czemu weryfikowana jest zgodność tworzonych specyfikacji reguł biznesowych z szerszym aspektem zaleceń RuleSpeak.

Konfiguracja słów kluczowych RuleSpeak

Konfiguracja słów kluczowych RuleSpeak

Podsumowanie

Wydaje się, iż delegowanie ludzi Biznesu do pracy z typowo informatycznymi narzędziami, jakimi są maszyny regułowe, nie jest działaniem optymalnym z punktu widzenia skuteczności i efektywności prac w ramach architektury biznesowej. Wykorzystanie dedykowanych języków i narzędzi do tego celu pozytywnie wpłynie zarówno na skuteczność jak i efektywność tych prac, pozostawiając w rękach poszczególnych interesariuszy działań analitycznych adekwatne do ich kompetencji oraz zakresu odpowiedzialności środki.

Oczywiście, z wpisu niniejszego nie należy wyciągać pochopnych wniosków, iż zarządzanie regułami biznesowymi na poziomie architektury biznesowej jest tak trywialne, jak tu opisano a narzędzia nie wymagają żadnych dodatkowych rozszerzeń. Tak nie jest. Celem natomiast było wskazanie potencjalnych kierunków poszukiwań oraz zainteresowanie RuleSpeak, bez względu na to, czy dedykowane narzędzia zostaną zastosowane, czy też reguły będą opisywany tylko i wyłącznie w edytorach tekstowych, czy arkuszach kalkulacyjnych. W każdym z tych przypadków, RuleSpeak przyniesie wymierne korzyści.

(1) Oczywiście, za nazwą kryje się jej definicja, co zostało pominięte w tekście.

RuleSpeak Sentence Forms w wersji polskiej

Wygląda na to, że dzisiaj mamy polski dzień analizy biznesowej. Na na naszych stronach udostępniliśmy polską wersję dokumentu RuleSpeak® Sentence Forms, opracowanego wspólnie przez pracowników Politechniki Wrocławskiej oraz AION. W przygotowaniu są polskie wersje pozostałych dokumentów metody IPSpeak, mających na celu ułatwienie zarządzania regułami biznesowymi w ramach architektury biznesowej.

Dokument znajduje się na stronie bazy wiedzy. Serdecznie zapraszamy do lektury.