Na temat reguł biznesowych mówiłem także w referacie na konferencji BPM GigaCon rok temu. Definicja reguły biznesowej na bazie Business Rules Manifesto (zapraszam do letury artykułu z przed roku: Reguły biznesowe ? czym są?):
Regułą biznesową jest ograniczenie specyficzne dla danej organizacji, zdefiniowane dla całego jej obszaru funkcjonowania.
Reguły biznesowe są jak kodeks drogowy: działają w całym kraju na wszystkich drogach a nie tylko w konkretnych miejscach.
Po kolei
O procesach biznesowych mówi się wiele, ja w tym blogu także nie mało napisałem. Jednak jest coś ciekawego: firmy doradcze twierdzą, że bez procesów nie da się dobrze zarządzać, a jak spojrzeć na firmy, nawet na liderów rynku, mało która ma “te procesy” udokumentowane, a kiedyś żadna nie miała i żyło im się całkiem nieźle… Jak to jest?
Gdzie podstęp? Proces, jego przebieg, jest efektem a nie przyczyną! Próby reformowania firm poprzez modelowanie ich obecnych procesów i narzucanie nowych ich wersji po “optymalizacji” są z góry skazane na niepowiedzenie (mimo, że być może gdzieś się przypadkiem udało). Dotyczy to między innymi wdrożeń system workflow z narzuconymi (predefiniowanymi) przepływami pracy.
Wyobraźmy sobie, że wysyłamy jedną osobę z zadaniem dotarcia w konkretne miejsce. Mamy więc tylko jednego wykonawcę, możemy go precyzyjnie poinstruować, spokojnie możemy nadzorować to co robi. W zasadzie problemu z zarządzaniem tym co robi nie mamy.
Firmy kilkuosobowe funkcjonują w pełnym “wzrokowym kontakcie” i w stałej komunikacji, jej pracownicy nie potrzebują innego nadzoru.
Problem zaczyna się gdy takich osób jest nie jedna czy kilka, a dziesiątki lub setki, w dużych organizacjach pojedyncze tysiące. Tu już nie mamy możliwości indywidualnego pokierowania zachowaniem (pracą) każdej osoby, udzielania wskazówek i obserwacji. Owszem, możemy udzielić stosownego instruktarzu każdej, to jednak wymaga dużej dyscypliny tego instruowanego, jeżeli czuje on “wzrok” nadzorcy realizuje zadania, jeżeli nie, pozostaje wierzyć w jego zaangażowanie i uczciwość. Proszę sobie wyobrazić nienadzorowaną manifestację, której uczestnicy zostali jedynie poinstruowani, którędy maja iść i jak się zachowywać.
Początkowo, rozrastające się organizacje starają się panować na zatrudnionymi, starają się zatrudniać ludzi zdyscyplinowanych i wykwalifikowanych. Tak jednak można rozwijać się do czasu, jest to także bardzo kosztowny rozwój (drogie zasoby). Po trzecie każdy zatrudniony musi nauczyć się od przełożonego (właściciela) tego jak ma pracować. Każdorazowe angażowanie kadr właścicielskich do nauki pacy prowadzi do sytuacji, w której nie mają czasu już na nic innego poza uczeniem nowych pracowników i nadzorowaniem pracy pozostałych. To punkt krytyczny rozwoju firmy. Zarządzanie zaczyna zamieniać się w “ręczne zaganianie to zajęć”. W skrajnym przypadku wygląda to jak permanentna akcja porządkowania manifestacji. W zasadzie dochodzi to utraty pełnego panowania nad osiąganiem celu, zarządzanie zamienia się w zaganianie. Jeżeli nic się sposób zarządzania firma pozostaje w stagnacji rozwojowej, nie jest w stanie osiągnąć większej sprawności.
Pojawia się idea: ustalmy spisaną listę obowiązków dla każdego. Zaczyna się formalizacja. Powstają zakresy obowiązków, ustalanie reguł. Nadal każdy wie CO ma robić, ma pewną swobodę ale wiadomy jest cel pracy (postawione zadanie). pojawia się jednak ryzyko. Wiemy gdzie pójdą ale nie mamy pewności którędy, a bywa, że jest to bardzo istotne. Po drugie może się okazać, że każdy obrał inną drogę, nie koniecznie optymalną.
Pojawia się pomysł: regulaminy i procedury czyli ograniczenia! Przyrównując firmę do ludzi w mieście, panowanie nad trasą jaka pokona tłum to barierki (ograniczenia). Są uniwersalne, stawiamy je tam, gdzie chcemy wymusić pokonywaną trasę.
Tą metodą możemy spokojnie obmyślić plan działania, opracować strategię, czyli drogę dojścia do celu, ogłosić ją i dla pewności jednak postawić barierki. Wielkość terenu nie pozwala nam niestety na ogarnięcie wzrokiem całości, po drugie jak skupimy się na stałej obserwacji przestaniemy wykonywać podstawowy obowiązek: zarządzanie całością. Co robimy? Instalujemy system kamer monitoringu. Jednak błędem było by montowanie ich na całej tracie, śledzenie tylu obrazów zje nam cały czas. Dlatego monitorujemy tylko specjalnie wybrane punkty, interesuje na nie to, co wszyscy robią na całej trasie (to zwykłe podglądanie ;)). Interesuje nas to, czy w newralgicznych, najbardziej ryzykownych punkach, nie dochodzi to łamania zasad.
Sprawny i skuteczny nadzór nad organizacją to nic innego znane nam KPI (Kluczowe wskaźniki wydajności, ang. [[Key performance Indicator]]). Powinno ich być jak najmniej, by koszty nadzoru były możliwie najniższe, a one same powinny “pokrywać” swoim “nadzorczym” działaniem całą organizację.
A gdzie procesy?
Wracamy do masowych wycieczek. Proces, czyli to “jak to się dzieje” to jest to, co postało wykonawcom: trasa do pokonania, ograniczana barierkami. Procesem jest trasa, bez tych barierek, ale pamiętamy: mamy nie jednego człowieka do przeprowadzenia a dużą grupę, której członków w większości nie znamy osobiście. Określenie im celu jest dobrym pomysłem, ale jeżeli tylko istnieje ryzyko , że mogą gdzieś zboczyć stawiamy barierki. Po trzecie, barierki rozwiązują podstawowy problem: zatrudnieni ludzie nie muszą mieć pełnej wiedzy o mieście by dotrzeć do celu.
Proces biznesowy to nie przyczyna, to skutek, formalnie lub nieformalnie, funkcjonujących w organizacji ograniczeń.
Modelowanie organizacji
Jaką więc wiedzę musimy mieć by zrozumieć organizacje i świadomie nią zarządzać? Przypomnę, że świadome zarządzanie firmą to podejmowanie decyzji organizacyjnych o wysoko przewidywalnych skutkach.
Żeby było to możliwe musimy rozumieć dla czego organizacja właśnie tak a nie inaczej się zachowuje. Proste mapowanie procesów, rysowanie diagramów przypływu pracy, to praca porównywalna z fotografowaniem rzeki z lotu ptaka: wiemy którędy płynie woda ale nie rozumiemy dlaczego akurat tak.
Pozostaje nam jedno: poznanie i zrozumienie ukształtowania terenu a potem zabranie się za tworzenie sztucznych wzniesień i zagłębień. To jedyny sposób na zapanowanie nad korytem rzeki czy nawet tylko małego strumienia. 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).
Przykładem takiej reguły jest np. “każdy klient, który złoży zapytanie musi mieć przydzielonego opiekuna klienta”. Aby taka reguła mogła jednak skutecznie funkcjonować kluczowe pojęcia takie jak klient, opiekun czy zapytanie muszą zostać precyzyjnie zdefiniowane. Bez tego zachodzi poważne ryzyko problemów z komunikacją wewnątrz firmy, a już prawie na pewno z jej otoczeniem.
Narzędzia modelowania organizacji
Modelowanie organizacji to element analizy biznesowej (jest to w procesie [[MDA]] dostarczania oprogramowania model [[Model niezależny od systemu IT, CIM ang. [[Computation Independent Model]]). Model taki opisuje sedno systemu jakim są ludzie, cele ich pracy oraz informacje jakie im są do tego potrzebne. Mamy tu listę narzędzi do biznesowego modelowania organizacji w konwencji CIM:
- specyfikacja reguł biznesowych,
- słownik pojęć,
- mapa procesów,
- struktura organizacyjna i specyfikacja zakresów obowiązków i kompetencji.
Jednak wykonanie powyższych specyfikacji w sposób zbyt swobodny (nieformalny) doprowadzi do małej ich przydatności. Pojęcia zdefiniowane w słowniku muszą spełniać pewne wymagania formalne: każde pojęcie powinno być fundamentalnym prostym i niezależnym od innych pojęciem, nie może być definiowane z pomocą innych pojęć (definicje pojęć nie mogą się wzajemnie do siebie odwoływać i w sobie zagnieżdżać). Pojęcia musza być proste i policzalne (określają byty biznesowe). Pojęcie nie może być definiowane przez procedurę lub proces, nie może być czynnością. Formalizacja dotyczy szczególnie punktów 3. i 4.
Bardzo dużym wyzwaniem jest zdefiniowanie systemu pojęć dla mapy procesów (proces, czynność, zdarzenie, dokument…). Mapa (model) procesów oraz struktura organizacyjna, by były jednoznaczne, muszą być także zestawem zdefiniowanych pojęć.
Tworząc model struktury organizacyjnej musimy wiedzieć co znaczy słowo: przełożony, podwładny, komórka organizacyjna czy jej kierownik. Struktura ta jest integrowana z modele procesów: role w procesie to stanowiska służbowe.
Budowanie systemów pojęciowych spełniających powyższe warunki jest bardzo trudne dlatego dla modeli procesów biznesowych najlepiej wykorzystać gotowy model pojęciowy. Najlepiej obecnie opracowanym takim modelem pojęciowym jest dostępna notacja [[BPMN]]. Tworzenie własnych notacji jest kosztowne (czas i wiedza osoby opracowującej) i bardzo ryzykowne (może się nie udać). Dlatego używanie dzisiaj własnych lub dostosowywanych notacji (np. dostosowywane profilami diagramy UML) jest w moich oczach nieracjonalnym podejściem.
Model pojęć specyficzny dla danej organizacji (tak zwany “[[business vovabulary]]”) niestety musi powstać “od zera”, podobnie jak powiązana z nim specyfiakcja reguł biznesowych. Jest to trudne bo tworzenie przestrzeni nazw wymaga utrzymania niezależności poszczególnych definicji, ich spójności i zupełności całego ich systemu. Niedochowanie tych wymagań prowadzi nawet sprzeczności reguł biznesowych, które w końcu są budowane (odkrywane i dokumentowane) z pomocą tych pojęć.
Narzędziem analitycznym pomagającym w analizie pojęciowej firm jest tak zwany diagram faktów. Ale o nim innym razem :), tu tylko mała zapowiedź:
Każda pojęcie (prostokąt) musi mieć ścisłą definicję, definicje muszą się wzajemnie wykluczać, a słownik musi pokrywać znaczeniowo cały definiowany obszar pojęciowy. Zdefiniowane pojęcia służą nie tylko do kumunikacji ale także do budowy reguł biznesowych: np.
- definicja pojęcia: Czytelnik – osoba uprawniona do korzystania z zasobów biblioteki,
- reguła biznesowa: Czytelnikowi wolno posiadać wyłącznie jedną książkę.
Uprzedzając pytania: powyższy diagram to nie gram klas UML, gdyż pojęcie jest jedynie definicją (nie ma operacji jak klasa) zaś Fakt, jako forma czasownikowa opisuje to co może się dziać z definiowanym pojęciem, nie ma ten zapis pojęciowy odpowiednika w modelu UML (operacja na pojęciu to nie to samo co odpowiedzialność klasy). Po trzecie obiektowy [[paradygmat]] pojęciowy notacji UML nie przystaje do sterowanego regułami systemu pojęciowego obszaru zarządzania przedsiębiorstwami: procesów biznesowych.
Widać to zresztą w na stronie OMG.ORG gdzie system reguł biznesowych (źr. specyfikacja Semantics of Business Vocabulary and Business Rules) jest traktowany jako element analizy biznesowej CIM:
Jak widać OMG, organizacja standaryzująca notację UML, zaleca jednak na poziomie analizy biznesowej stosowanie innych niż UML systemów pojęciowych i notacji. Polecam także artykuł Dlaczego tylko metody formalne…
Zanim wiec zaangażujesz kogoś do modelowania własnej firmy, upewnij się, komu zlecasz tę pracę…
Wersja mniej niszowa
Artykuł ten przeczytał pewien znajomy, i uznał, że powyższa wersja artykułu jest zbyt niszowa, rozwlekła i trudna. Jeżeli ma troszkę racji to tu w bardzo dużym więc skrócie:
- procesy biznesowe to faktyczny, widoczny sposób pracy firm (ludzi w nich zatrudnionych),
- procesy to efekt funkcjonowania ludzi w środowisku ograniczeń,
- należy poznać tych ludzi,
- ograniczenia to: procedury, prawo, zarządzenia wewnętrzne oraz specyficzne dla firmy wewnętrzne normy zwane regułami biznesowymi,
- opracowanie biznesowego modelu firmy wymaga zrozumienia i opisania tego co powyżej opisałem,
- nie istnieje droga na skróty.
- …
Za niedługo dalszy ciąg tego artykułu w postaci przykładu. Wyobraźmy sobie niedużą bibliotekę….
Trudno mi się zgodzić ze sformułowaniem “role w procesie to stanowiska służbowe”. Dla mnie bardziej pasowałoby, że role w procesie są realizowane przez stanowiska służbowe, ale nimi nie muszą być. To trochę jakby powiedzieć, że dane stanowisko musi pełnić zawsze taką samą rolę w procesie. Z czego wynika takie stwierdzenie? A może chodzi o coś innego?
Był to chyba zbyt szybki skrót myślowy, przepraszam. Chodziło mi o to, że rola w procesie to “osoba”, którą w organizacji można wskazać, mająca konkretne umiejętności i obowiązki. Faktycznie możliwe jest także, że rola to dodatkowe dedykowane stanowisko lub zestaw specjalnych uprawnień, ale nie przeczy temu, że opis takiego stanowiska powinien istnieć. Proces (ciąg czynności) i szczegółowość jego opisu (modelowania) to efekt: tego co: wykonawca potrafi, tego co musi umieć i tego czego się od niego wymaga w procesie. Modelując proces biznesowy, diagram powinien zawierać tylko to ostatnie (dlatego bardzo dobrą nazwą jest workflow lub po prostu wewnętrzny łańcuch wartości). Jest to oczywiście kwestia użytej pragmatyki. Ja “łączę się” z tymi, którzy uważają, że model procesu nie powinien zawierać (dublować): zakresów obowiązków, kompetencji, reguł biznesowych (tych w szczególności). Bez tego założenia mapy procesów osiągają monstrualne rozmiary i jako dokumenty, są praktycznie bezużyteczne z powodu swej megazłożoności (no chyba, ze ktoś sobie liczy od strony papieru ;)).
> 1. specyfikacja reguł biznesowych,
> 2. słownik pojęć,
> 3. mapa procesów,
> 4. struktura organizacyjna i specyfikacja zakresów obowiązków i kompetencji.
Kolejność korzystania z wymienionych narzędzi również nie powinna być przypadkowa. Trudno modelować procesy firmy nie znając np. jej struktury organizacyjnej czy też panujących w niej reguł biznesowych (chciaż tym przypadku reguły często identyfikuje się właśnie podczas modelowania procesu).
Uważam również, że bardzo pomocnym, aczkolwiek trudnym narzędziem jest Business Motivation Model, dzięki któremu można w sposób sformalizowany opisać cele przedsiębiorstwa oraz sposby ich osiągnięcia.
Jeśli chodzi o model pojęciowy organizacji i jego zamodelowanie przy pomocy modelu faktów, muszę przyznać, że nie jest to proste zadanie, głównie ze wzgledu na problemy z uzgodnieniem definicji. W większych przedsiębiorstwach może to być ogromnym problem.
Z powyższym wypada się tylko zgodzić :), dodam jednak, że brak słownika pojęć (mimo, że wbrew pozorom jest faktycznie trudny do opracowania) prowadzi często do grubych nieporozumień a bywa, że do krachu projektu, często dotyczy to wdrażania systemów ERP. Co do kolejności mogła by być inna jednak doświadczenie uczy, że one wszystkie niejako powstają (są weryfikowane) jednocześnie a elementem spajającym jest tu modelowanie procesów i ich testowanie, które wymusza uzupełnianie braków posiadanej wiedzy o firmie.
Szanowny Panie,
mam pytanie odnośnie przedstawionych przez Pana ograniczeń (tudzież zasad) konstruowania słownika pojęć. Mianowicie, napisał Pan, iż definicje w słowniku nie mogą się pokrywać, nie mogą się odwoływać do siebie nawzajem, ani zawierać zagnieżdżonych definicji. Jak najbardziej trzeba się z tym zgodzić, ale…
Jak radzi Pan traktować to w praktyce, żeby nie doprowadzić do nieporozumień i zapętleń. Przecież definicja książki jest silnie powiązana z czytelnikiem (który czyta książki), wypożycza je w bibliotece(która udostępnia książki) itd. itp. Chcąc nie chcąc mamy tutaj odwołania książki do innych definicji, a podobnych zestawień można pewnie przytoczyć dziesiątki.
Jak w takim razie zachować opisane przez Pana reguły tworzenia słownika pojęć?
Zasady o jakich pisałem dotyczą tworzenia przestrzeni nazw (przestrzeni pojęciowych w językach). Widzę często próby podejścia do słownika pojęć jak do relacyjnego modelu pojęciowego co jest błędem. Co do zasady np. książka jest bytem niezależnym od czytelnika i biblioteki: może być nieczytana i może istnieć poza biblioteką. Błędem jest trwałe wiązanie tych pojęć. Przestrzeń nazw nie jest “modelem encji danych”. Związki pomiędzy pojęciami (na tego typu modelu) to fakty jakie czynią, że mają one (te pojęcia) wspólny kontekst (interesuje nas tu książka w bibliotece, czytana przez czytelnika) i “kwalifikują” się do tworzonej na potrzeby danej analizy przestrzeni nazw.
Tak więc to, że czytelnik książki czyta (może to zrobić) nie jest żadnym połączeniem a kontekstem. Związek “relacyjny” znany z baz danych relacyjnych nie jest definicją pojęcia. Tu widać moim zdaniem “siłę” podejścia: nie definiujemy książki jako “coś co czyta czytelnik” bo to strasznie fałszuje rzeczywistość i po pierwsze prowadzi do nieporozumień, po drugie zamyka rozwój systemu np. na obsługę prasy…
Tak więc zachowanie tych reguł polega na ich restrykcyjnym stosowaniu bo to zmusza do zrozumienia np. czym jest książką (bo raczej nie jest “czymś co czyta czytelnik”). Jeżeli pojawi się jakieś “zapętlenie” to raczej sygnał, że płyniemy w stronę relacyjnego modelu związków encji a to błąd. Fakty wiążące pojęcia na diagramie faktów to kontekst ich istnienia a nie relacje. Przy okazji przestrzegam przez traktowaniem diagramów klas tak jak modeli ERD.
Czy tak (jak opisałem) tworzony słownik pojęć pomaga? Tak, bo nie fałszuje rzeczywistego znaczenia tych pojęć a nawet zmusza do ich uporządkowania przed projektowaniem czegokolwiek na nich opartego. Należy unikać sytuacji, w której te same pojęcia znaczą co innego w oprogramowaniu, w dokumentacji czy w prawie regulującym dana branżę.