Od czasu do czasu spotykam się z zaskoczeniem, gdy mówię, że pewne słowa kluczowe w specyfikacjach są "standaryzowane". Otóż specyfikacje notacji na OMG.org mają narzucone pewne słownictwo. Przykładem niech będzie specyfikacja notacji BPMN v.2.0.2, zawiera ona taki oto rozdział : 3.2 Normative OMG UML ? OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2 - (jest już UML 2.5.) OMG MOF ? Object Management Group - Meta Object Facility (MOF) Core Specification, V2.0 https://www.omg.org/spec/MOF/2.0 RFC-2119 ? Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, IETF RFC 2119,…
Tę recenzje książki zacznę nieco inaczej. Swego czasu pisałem, że warto stosować reguły biznesowe w modelowaniu procesów. Zwracałem uwagę na to, że nie ma sensu modelowanie decyzji w BPMN... ... 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):Proces biznesowy w notacji BPMN z wydzielonymi procedurą i reguła biznesową. Proces biznesowy w…
Kolejne projekty IT zaliczają kolejne wpadki i wśród przyczyn prawie zawsze pojawia się utrata panowania nad złożonością projektu. Jednym z kluczowych elementów analizy, także systemowej, jest redukowanie złożoności. Robi się to budując modele i metamodele analizowanej rzeczywistości, a na wstępnych etapach projektowania abstrahuje się od szczegółów. Jak? Operując właśnie modelami i metamodelami. Od dawna noszę się z zamiarem napisania czegoś o zarządzaniu złożonością i spójnością dokumentów. W końcu "nawinął" się dokument, na którym moim zdaniem warto "poćwiczyć". Jest to ciekawy dokument zatytułowany: Metareguły i zasady budowy cyfrowych usług publicznych We wstępie poznajemy cel i…
Wstęp
Niedawno pisałem o regułach biznesowych i politykach postępowania w zarządzaniu:
…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. (Reguły biznesowe i polityki jako mechanizm działania organizacji | | Jarosław Żeliński IT-Consulting)
W powyższym cytacie wytłuściłem klucz dzisiejszego wpisu: mechanizm (ale nie ma tego słowa w powyższym cytacie).
(więcej…)
Jeżeli uznamy, że modelowanie zachowania organizacji w postaci modelu procesów polega wyłącznie na tworzeniu diagramów zawierających kolejno wykonywane detaliczne czynności, to znaczy że wszelkie powyżej opisane zachowania znajdą się jako "równoprawne" aktywności na tych diagramach. Powstają monstrualne nieczytelne schematy blokowe, zawierające setki detali, trudne do interpretacji, trudne i kosztowne w utrzymaniu (aktualizacja), i przede wszystkim nie pozwalające na wyprowadzenie wprost z nich wymagań na oprogramowanie. Można w zasadzie zaryzykować tezę, że tak tworzone modele, w których cała wiedza o organizacji została zapisana jako łańcuchy detalicznie zobrazowanych czynności, tak na prawdę do niczego nie są przydatne. [...] Czemu więc służą żmudne wywiady, warsztaty, burze mózgów w toku analiz firm? Zaryzykuję, tezę, że niczemu nie służą.
źr. http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471
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…
Równo 10 lat temu napisałem: Model firmy powinien w sposób jasny i zrozumiały dla pracowników firmy opisywać firmę, jej cel rynkowy oraz wszelkie jej wewnętrzne i zewnętrzne zachowania oraz reakcje. Poza tym, jest niezbędny do przewidywania zachowań firmy w tym także do przygotowania jej do wdrożenia systemów informacyjnych. Wiele firm doradczych i informatycznych pod pojęciem mapy i modelu procesów biznesowych dostarcza nieprzydatne, utrwalone na dziesiątkach diagramów opisy czynności realizowanych przez ankietowanych pracowników, które nie wiele mają wspólnego z planowanymi zmianami na lepsze.Większość modeli firm jakie widziałem to obrazki nie mające…
SBVR to specyfikacja opisująca tworzenie modeli pojęciowych, słowników pojęć i reguł biznesowych. Aktualną wersje specyfikacji można pobrać tu: Semantics Of Business Vocabulary And Rules (SBVR)The current version is found at Formal Versions Of SBVR (Źródło: SBVR) A dzisiaj kilka słów na temat aneksu: Annex F - The Business Rules Approach i związku modeli pojęciowych z regułami biznesowymi. Aneks zawiera wyciąg kluczowych punktów Manifestu Reguł Biznesowych (kluczowe punkty): Pierwszoplanowe, a nie wtórne, wymagania 1.1. Reguły są pierwszoplanowymi obywatelami świata wymagań. 1.2. Reguły są kluczowe dla modeli biznesowych oraz technologicznych, stanowiąc jednocześnie ich autonomiczną część. Oddzielone od procesów, a nie…
Wprowadzenie Regularnie widuję monstrualne diagramy, na których ich autorzy usiłują modelować decyzje podejmowane w toku przepływu pracy. Pierwsze nieporozumienie (i duży błąd pojęciowy) na tych diagramach, to łączenie na jednym diagramie elementów procesu biznesowego, z tym jaka "praca myślowa" wykonawcy ma być w danym procesie (aktywności) wykonana. Drugi błąd to mieszanie poziomów abstrakcji: proces biznesowy to dość duży poziom ogólności (uogólnienia), jego celem jest pokazanie celowości łańcucha pracy (procesy biznesowe to aktywności tworzące produkty) a nie tego, jak jest w detalach wykonywana: wnętrze tych aktywności - ich szczegóły - na…
źr. http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471
Kolejny artykuł z gatunku "przemyślenia i rady na koniec roku" :) Często spotykam się traktowaniem reguł biznesowych jak jakiegoś piątego koła u wozu (o ile w ogóle się ktoś nimi zajmuje w projekcie). Pół roku temu pisałem, że reguły biznesowe to, jeżeli stają się wymaganiem, stanowią kluczowy element realizowanej logiki biznesowej: Sprawdzoną metodą skutecznego (spójność, kompletność, niesprzeczność) zapisywania wymagań dziedzinowych (w tym ?walidacje?) jest wydzielenie w dokumentacji: słownika pojęć słownika reguł biznesowych specyfikacji tablic decyzyjnych jako uzupełnienia reguł biznesowych. (Gdzie są te cholerne szczegóły). Jest jednak drugi, nie mniej ważny, element każdego…
Tak więc brak (umiejętności) stosowania abstrakcji w modelowaniu czyni te i inne modele (schematy blokowe) nieczytelnymi, trudnymi do interpretacji, kosztownymi w wytworzeniu i utrzymaniu. To ostatnie powoduje, że większość takich dokumentów szybko kończy życie na półkach, bo dezaktualizują się jak tylko dojdzie do jakiejkolwiek, nawet najdrobniejszej, zmiany w organizacji. Co ciekawe, biorąc pod uwagę czas trwania przeciętnego wdrożenia oprogramowania, taki zbyt szczegółowy model nie ma szans być przydatnym w toku takiego projektu, tu rację mają developerzy, którzy twierdzą, że im takie dokumenty im w niczym nie pomagają.
Tak więc, warto rozważyć stosowanie reguł biznesowych i słowników pojęć (Semantics Of Business Vocabulary And Rules), gdyż jest to sprawdzona i bardzo przydatna technika analizy i dokumentowania logiki biznesowej. Polecam także stronę The Business Rules Group i zamieszczony tam Manifest Reguł Biznesowych. Tworzenie monstrualnych dokumentów wymagań, zawierających dziesiątki razy powielane "walidacje" prowadzi do wielu kłopotów z utrzymaniem spójności i kompletności takich specyfikacji. Pomijam już ich uciążliwą objętość. Jako materiał dla programisty są one wtedy trudne w użyciu, do tego skłaniają do najgorszych praktyk, jakimi jest między innymi umieszczanie logiki biznesowej w kodzie formatek ekranowych.
