Na ratunek Metodyka

Metodyka to takie słowo, które aktualnie budzi strach i odrazę, gdyż kojarzy się z tak zwanym Łoterfolem. Może nie u wszytskich, gdyż żyją jeszcze ludzie, którzy z Metodykami mieli praktyczne do czynienia. I od czasu, do czasu o tym wnukom swym opowiadają. A króluje…nie metodyczność a zwinność.

A dlaczego miałoby być inaczej?

Planowanie

Metodyka to usystematyzowana propozycja sposobu pracy. Jeśli przystępujemy do jakiegoś przedsięwzięcia, to na bazie naszej wiedzy o nim staramy się z Metodyki wybrać te działania, które w tym przedsięwzięciu będą uzasadnione. Proste? Proste. Jaka z tego wynika wartość?

Ano taka, że jeśli metodyka uwzględnia tego typu przedsięwzięcie, to wybierzemy z niej fragment, który będzie logicznie spójny i procesowo przewidywalny. Co z tego?

Nasz plan na realizację przedsięwzięcia będzie miał określony, logiczny ciąg działań wyspecyfikowane produkty i okeślone, wymagane role. To już jest niezła baza do szacunków.

Realizacja

Mając Metodykę, możemy rozpocząć działania z nadzieją, że jeśli nie zdarzy się nic, co wpływa na jej dobór (okrojony do konkretnego kontekstu), bedą one prowadzone według dobrze ustalonego planu, To daje pewien komfort zarówno od strony zarządczej jak i wykonawczej.

A co, jeśli w trakcie prac zmieni się sytuacja? Do pewnego stopnia, nic. Należy sięgnąć do Metodyki i wybrać z niej takie elementy, które odzwierciedlają nowe uwarunkowania.

I tak iteracyjnie. I przyrostowo.

Post Mortem

A co, gdy zakończy się przedsięwzięcie? Jak to co? Należy usiąść, przysyskutować zrealizowane działania i zastanowić się, czy to co się wydarzyło, nie powinno wpłynąć na metodykę. Jeśli tak, zmodyfikujemy ją. Następnym razem będzie jeszcze bardziej przewidywalnie.

Ale czy to nie jest za ciężkie?

Czy to nie ogranicza swobody działania? Czy to nie powoduje, że ludzie są pozbawienie szansy na kreatwyność?

No właśnie? Jak to jest z tymi Metodykami? Moim zdaniem….

Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

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ć.

Sezon na Architekturę i Analizę Biznesową

Tym razem, zamiast merytorycznego wpisu zapraszam na cykl bardzo merytorycznych spotkań. Naszym zamierzeniem jest stworzenie miejsca, w którym w atrakcyjnej formie, w niedużym gronie doświadczonych osób będzie można dyskutować o nietrywialnych problemach z szeroko pojętej Architektury Biznesowej oraz Analizy Biznesowej.

Cykl będzie podzielony na sezony, w ramach których będą się odbywać 3 spotkania koncentrujące się na jednym temacie. W przypadku tematów, które zostaną uznane za wyjątkowo interesujące, będziemy starali się podsumować sezon konferencją, w której będzie mogła wziąć udział większa liczba osób.

Serdecznie zapraszam do udziału w pierwszym spotkaniu, które odbędzie się we Wrocławiu 07.03.2019. Odnośnik do strony wydarzenia Architekci biznesowi, analitycy procesowi, analitycy biznesowi – sprzymierzeńcy czy konkurenci?

Edżajl 2018 (level Corpo, level hard)

agile2018mediumDługo nosiłem się z zamiarem powrotu do pisania. W końcu to nastąpiło, ale po raz kolejny sprawdziła się zasada, że rzecz raz odłożona dalej odkłada się już sama. Ostatecznie, zaniosłem się i idąc za ciosem postanowiłem kontynuować wątek zwinności. Dlaczego? Bo chyba nie da się go nie kontynuować, obserwując wszechobecne uzwinnianie się zespołów, metod pracy i całych organizacji. I ten ostatni poziom wydaje się być groźny. I o tym, w skali korporacyjnej, poniżej.

Co to jest ten Edżajl?

No właśnie. Na początku mojej przygody z tym trendem, było to nic innego jak sposób organizacji pracy w zespole projektowym. Kilka prostych zasad, proste narzędzie (stosowaliśmy ScrumDesk) i można było się w to pobawić. Fundamentalnych usprawnień nie odnotowaliśmy, ale miałem wrażenie, że w jakimś stopniu wzrosło poczucie świadomości stanu prac w zespole. Od strony inżynierskiej Scrum nie wpłynął na stosowane metody pracy. Tak było wiele lat temu.

Tymczasem mamy rok 2018. Mamy Edżajl. I tego Edżajla już nie rozumiem. Co oznacza, że nie rozumiem większości otaczającego mnie świata zawodowego.

Poziom IT

Co o nim wiem. Wiem, że Edżajl to klimat pracy. Ma być korzystny. O klimat troszczą się Edżajlkołczowie. Piękni dwudziestoletni, którzy są w stanie powiedzieć jakie metody pracy stosować, a jakie nie, bo się nie sprawdzają. Sprawdzają się metody proste albo nowe. Nie sprawdzają się metody kojarzone z Łoterfolem – siedliskiem zła, który kreatywnych ludzi wciskał w tryby biurokratycznej machiny i pozbawiał wpływu na cokolwiek.

Skąd to wiedzą? Wiedzą stąd, że spotykają się w swoim gronie pięknych dwudziestoletnich i dyskutują. Na tych spotkaniach panuje dobry klimat, skutkujący szczerą, otwartą rozmową, z której to powstają nowe pomysły. W sposób otwarty Edżajlkołczowie komunikują swoje przemyślenia zespołom edżajlowym. Ponieważ pracujemy w duchu akceptowania zmian i poprawek, nie przejmujemy się tym, że nowe pomysły często przeczą starym pomysłom. Refaktor idei, czyli pozytyw.

Edżajlkołczowie pracują ze swoimi zespołami. Zespoły mają ograniczoną liczebność, gdyż zespoły zbyt duże są nieefektywne. Przy większych przedsięwzięciach, powstaje wiele zespołów mających realizować wspólny cel. Ale zespoły są autonomiczne i nikt, ale to Nikt Spoza Zespołu, nie może czegokolwiek wrzucić do Baklogu. Tak więc zespoły muszą się ze sobą dogadywać. Customer collaboration over contract negotiation. Tako rzecze Manifest. Jak się uda, to się dogadają. Jak się nie uda, to zespół, który liczył ale się przeliczył, w swojej autonomiczności musi czekać na autonomię innego zespołu. Ale tym się nie martwimy, bo ważne, że klimat rozmów był korzystny. Kiedyś się dowiezie. Na razie zaślepimy, wdrożymy, i jakoś to będzie. Responding to change over following a plan. No przecież.

W dużych organizacjach systemów jest dużo. Najczęściej zmiana pociąga za sobą zmianę w więcej niż jednym systemie. Autonomiczny zespół musi więc posiadać u siebie specjalistów, którzy będą w stanie dokonać zmian w każdym z systemów. Ale nie zawsze się da. Bo jeśli zmiana dotyka kilkunastu systemów, to posiadanie choćby jednego specjalisty u siebie spowodowałoby przekroczenie maksymalnej liczby osób w zespole. Co więcej, może się także nie udać z racji tego, że system jest z gatunku centralnych i z założenia ma być dobrem wspólnym. A jeśli dobro wspólne, to nie prywatne. I na przykład sposób specyfikowania wymagań dla takiego dobra wspólnego może się różnić od tego, który wypracował zespół autonomiczny. Co więcej, zespół systemu centralnego może mieć całkiem rozbieżne z zespołem edżajlowym priorytety. I znowu trzeba czekać. I zaślepiać.

Manifest rzecze także  Working software over comprehensive documentation. Każdy przedszkolak, nie mówiąc o Edżajlkołczach, wie, że do produkcji softu potrzeba epików, storysów i tasków. Można też kanwasy, łajefrejmy i inne persony. Komunikacja, komunikacja, lekkość, zwinność. Tego nam potrzeba. Życie takiego bytu jest tak burzliwe, jak krótkie. Dyskusja, spory, poprawki, dyskusja, poprawki, zaimplementowane, DOD spełnione, poszło! A po roku jakiś inny, Obcy zespół musi sięgnąć do koncepcji rozwiązania. I męczy, i dręczy, i nawet próbuje się wbić do Baklogu autonomicznego systemu, ale ten ma przecież swoje, autonomiczne priorytety. Się uda, się wbije. Się nie uda, to powstanie kopia, łata, cokolwiek, co pozwoli Obcemu zrealizować swoje, autonomiczne plany. Że to niepotrzebne? Że to nadmiarowe? Kozioł ofiarny, by móc pracować w dobrym klimacie.

W bardzo dużych organizacjach, systemów i zespołów potrafi być bardzo dużo. Wprawdzie każdy jest zmotywowany, skoncentrowany na celu, ale jakaś kontrola – pardon, liderszip – być musi. Ktoś komuś jakiś raport na biurko czasami musi wrzucić. Najlepiej jakby z terminami, kosztami. Oczywiście wszystko edżajlowo, ale tak gdzieś pod spodem, jakby jakiegoś Ganta? Tylko, żeby nikt nie widział.

Poziom organizacji

No ale jak to zrobić? Ha! Proste! Tu do akcji wkraczają piękni trzydziestoletni – mistrzowie fechtunku słowem i pałerpojntem. Ci, którzy karierę pięknych dwudziestoletnich mają za sobą i doradzają. Oni mają wiedzę Świata, gdyż w takich organizacjach pracują, co to taką wiedzą dysponują. I oni wiedzą, że taka jedna firma, to kiedyś, podzieliła się na Trajby, Składy, Czaptery. I oni wiedzą, że tak trzeba postąpić, aby duch edżajla spłynął na całą organizację, a nie tylko na ajti. Wprawdzie piękni dwudziestoletni nie ogarnęli jeszcze zagadnienia współpracy w skali mikro, ale nie przeszkadza to we wdrażaniu zmiany w skali makro.

BPRRolnictwo w Polsce ma długą historię. I co, jak co, ale orki nikt nie musi nas uczyć. Zaorajmy więc dotychczasowe struktury i wdrażajmy podejścia autonomiczne na poziomie biznesu. Piękni trzydziestoletni nie pamiętają jednak, że tego typu radykalne zmiany historia zarządzania zna i ma za sobą. Jedną z najbardziej zbliżonych do Rewolucji Edżajl jest teoria Business Process Reingeenering, opisana przez Hammera i Champy’ego w latach dziewięćdziesiątych w książce Reengineering the Corporation: A Manifesto for Business Revolution. Doświadczenia z  wdrażania tej metody dały w efekcie łagodniejsze podejścia typu Business Process Improvement. Ale to było dawno, a teraz jest Edżajl. Będzie Pan zadowolony.

Tak więc, mamy nowe struktury organizacji edżajlowej. Wywiedzione wprost z koncepcji budowy oprogramowania, metody edżajl zaczynają rządzić biznesem. Edżajl to prostota, wobec czego wraz z nowymi strukturami dekretowane są redukcje (czytaj, uproszczenia) ról i stanowisk. Wprawdzie pracę trzeba wykonać, ale będzie jakoś prościej, bo stanowisk i ról mniej. Poza tym, edżajl to wymienność, więc zawsze można komuś obok coś wrzucić – niech czuje, że ma Edżajla. Czyli prościej i w dobrym klimacie. Nowe struktury są autonomiczne. Nie troszczą się szczególnie o inne, wszystko hermetyzują u siebie i dla siebie. Oczywiście za wyjątkiem tych obszarów, których ukryć się nie da. Ale tutaj jakoś trzeba się dogadać.

Każda zmiana ma jakieś skutki uboczne. To oczywiste. Wśród lekko zdezorientowanych skutków ubocznych stoją ramię w ramię osoby zajmujące się procesami biznesowymi, architekci biznesowi, architekci IT. Pojawia się bowiem zasadnicze pytanie – co ma być optymalizowane – praca Trajbów, czy praca całej organizacji? Co, jeśli te cele nie są zbieżne? Idąc dalej, jak tworzyć architekturę biznesową (choćby pojęcia) – dla Trajbu czy organizacji? Mamy architektury IT dla Trajbów czy dla organizacji? Jak wdrażać jednolite standardy w konstelacji autonomicznych jednostek? Senioredżajlkołczowie to wiedzą. Proponują jednostki wskrośtrajbowe. Ale to oznacza, że Trajb nie jest już tak autonomiczny, jak to obiecywali. Ale kto jest ważniejszy – ten od Wskroś, czy ten w Pionie? Pozostaje się dogadać.

I różne takie

Mylnym byłby wniosek, że tak fundamentalne problemy dotyczą jedynie poziomu organizacji. Na poziomach zespołów także mamy dylematy z gatunku dawno rozwiązanych ale w Edżajl fundamentalnych. Czy analiza powinna być elementem sprintów, czy też wyciągnąć ja poza sprinty, gdyż jest trudna do oszacowania. Wyciągnięcie jej poza sprint skutkuje rozpoczynaniem prac ze stabilnymi wymaganiami. Ale w takim razie w ramach czego powinna być prowadzona analiza? Jeśli zaś jest prowadzona w sprincie, opóźnienia stają się nagminne. Czy user story to wymaganie, czy coś innego? Jak się mają te wymagania do innych metod ich specyfikowania. Jak połączyć repozytorium user story z repozytoriami na przykład narzędzi do opisu wymagań technikami inżynierskimi (UML, BPMN, SysML). Czy elementem zmiany jest też poziom organizacji? Jeśli tak, jaki zespół powinien to robić? Ciężko sobie wyobrazić nieduży zespół posiadający w swoim składzie architektów, analityków biznesowych, analityków systemowych, specjalistów od usprawniania procesów, kontroli procesów, itd. Różne zespoły? To jaki produkt jest prezentowany Prodaktołnerom? Diagram? Jakby wbrew fundamentalnym obietnicom Edżajl.

To co to jest ten Edżajl?

No właśnie. Minął rok i dalej nie wiem. Intuicja podpowiada mi, że to prosta droga ku porażce. Że to już było. Że obietnice aż kłują populizmem w oczy. To, że ja nie rozumiem, co to Edżajl, to jeszcze nie problem. Problemem jest to, że wdrażający Edżajl, mam wrażenie, także nie wiedzą, co to tak do końca jest.

Ale kilkudziesięcioletnie doświadczenie mówi też, poczekajmy. Zobaczymy co z tego wyjdzie.  Idąc tym tokiem myślenia, mam wrażenie, że  Edżaj  zakończy swój dynamiczny żywot tak jak inne koncepcje, które miały zrewolucjonizować świat, a ostatecznie stały się małą częścią czegoś większego, dużo bardziej skomplikowanego. Pytanie oczywiście o koszty tej nauki. Ale to już inna bajka.

Ilustracja: https://pl.freepik.com/darmowe-wektory/ręcznie-rysowane-eleganckie-baleriny_849800.htm Designed by Freepik

 


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

The Business Agility Manifesto – jest nadzieja

Open flying old books

Agile (czytaj, ażil) w korporacji, jak na razie, kojarzy mi się z wielkim bałaganem, jeszcze większym nieporozumieniem i niekończącym się poganianiem jednego wzniosłego hasła, innym wzniosłym hasłem uzupełnianym metaforami coach’ów z zupełnie niepasującej bajki. Może trochę przesadzam, ale jeśli przesadzam, to tylko trochę.

Dwa tygodnie temu w ręce moje wpadł Manifest (https://busagilitymanifesto.org/) opracowany przez osoby, które bardziej kojarzą się z tymi niedobrymi czasami twardej inżynierii niźli ze zwinnością. Roger Burlton, Ronald Ross oraz John Zachman po raz kolejny połączyli siły i na bazie swoich doświadczeń wypracowali zestaw zasad dla zwinnego biznesu. I po raz kolejny, trafili w moje potrzeby. Najważniejszą z nich była potrzeba odnalezienia się w tym szaleństwie, które obserwuję i choćby drobnego odniesienia się do fundamentalnych wątpliwości odnośnie prób skalowania sofware’owego agile’a do potrzeb agile’owej korporacji. I postawienia przeciwwagi dla narracji w stylu „ostatecznie liczy się działający soft”. Bo moim zdaniem tak nie jest. Działający soft jest środkiem do celu, ale nie tylko on decyduje o zwinności organizacji. I od oprogramowania chciałbym zacząć analizę zaleceń manifestu, świadom tego, że zaczynam niejako od środka.

Developing software faster is not sufficient, in and of itself, for survival and growth because once operational, such software is likely to prove difficult to continuously and rapidly change without unintended consequences.

Samoorganizujące się zespoły, dobierające techniki głównie pod potrzeby szybkiego dostarczenia oprogramowania, nie zwracające szczególnej uwagi na szeroki kontekst organizacyjny tworzenia i utrzymania oprogramowania miesiąc po miesiącu dozbrajają tykającą od wdrożenia pierwszego przyrostu bombę. Ograniczanie wiedzy o biznesowym kontekście przedsięwzięcia do form akceptowanych w słownomuzycznym backlogu, odżegnywanie się od technik badających spójność biznesową rozwiązania oraz zgodność z otoczeniem, w którym przyjdzie je zastosować oraz stawianie na piedestale potrzeb deweloperów skutkuje zaciąganiem biznesowego i technologicznego długu, którego termin spłaty może nadejść gwałtownie, bez wcześniejszego uprzedzenia.

W moim przekonaniu, aby oprogramowanie mogło wspierać zwinne zarządzanie organizacją, musi być oparte o solidne fundamenty, w szczególności:

  • uwzględniać biznesową interpretację rzeczywistości organizacyjnej (być w zgodzie z modelem pojęć (koncepcji) ),
  • stanowić naturalne rozwinięcie wynikającego ze strategii organizacji łańcucha tworzenia wartości (być w zgodzie z modelem procesowym bądź innym, holistycznym spojrzeniem na opis realizowanych w organizacji działań dostarczających produkt Klientowi),
  • opierać się o solidny fundament analizy systemowej, zapewniający wewnętrzną spójność oprogramowania.

Część z tych tematów znajduje swoje rozwinięcie w materiałach uzupełniających manifest.

True business agility is measured not just by speed of response to requests, changes, or disruption, but also by the coherence of the response.

Spójność, której dotyczy postulat, powinna być traktowana wielowymiarowo – w poziomie, jako wewnętrzna synergia komponentów rozwiązania informatycznego, jak i w pionie – jako zgodność z rozwiązaniem biznesowym. Aby można było to stwierdzić, wymagane jest stworzenie jednoznacznego opisu wymiarów rozwiązania w formie umożliwiającej ich szczegółową analizę w efektywny sposób. Do tego potrzebny jest aparat narzędziowy bogatszy niż szkice i historyjki.

A critical skill for analysts is the ability to engage in dialogs to assess business knowledge for gaps, conflicts, ambiguity, and completeness.

Aparat ten daje szansę na nawiązanie efektywnego i skutecznego dialogu ze wszystkimi stronami wpływającymi na rozwiązanie, nie tylko tymi, którzy są w stanie zrozumieć potrzebę wytwórcy oprogramowania.

Instantaneous change is not the goal. The goal is well-considered change that achieves the desired business effect and avoids unintended side effects.

Frictionless change is not the goal. The goal is change that is dependably shaped according to business strategy, policies, and business obligations and commitments obligations.

Dobrze zaprojektowane rozwiązanie, uwzględniające wymagania wielu stron, pozwoli na jego płynniejsze wdrożenie oraz dłuższe wykorzystywanie, bez konieczności poprawiania go zaraz po wdrożeniu.

Skimping on the quality of business software – creating a tech debt – has no place in businesses striving for change in existing lines of business.

Dobrze zaprojektowanie rozwiązanie nie będzie automatycznie obciążone żadnym długiem, wręcz przeciwnie, będzie kolejnym małym krokiem w kierunku realizacji strategii.

Failing expensively or repeatedly, even if fast, is nonetheless waste to be eliminated.

The value of failing fast in order to learn fast must be balanced against other factors including: impact on business customers, cost of rework, and exposure to risk.

A jeśli już przyjdzie nam od razu poprawiać świeżo opracowany produkt, oznaczać to będzie, iż najprawdopodobniej po prostu źle wykonaliśmy swoją pracę. Strategia Fail fast ma swoje określone miejsce i nie powinna tłumaczyć każdej porażki.

Self-organizing teams and other agile organization schemes alone do not lead to business agility.

Self-organizing teams are a means, not an end. They do not reduce, but rather increase, the need for business strategy, value chain coherence, reuse of business knowledge, and effective portfolio governance.

A i jeszcze te zespoły. Samostanowiące o sobie. Samoorganizujące się. Szlachcic na zagrodzie… Pracujemy w dużej firmie. Musimy dbać o synergię. Musi być ktoś, kto ustanawia reguły, a zespoły samostanowiąc o sobie, muszą się w wyznaczonych ramach mieścić. Musi być ktoś, kto rozlicza ze stosowania się do reguł. Musi być lider. Konsekwentny.

Tyle na pierwszy raz.


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

Analiza biznesowa jest zbyt trudna, czy brakuje kompetentnych analityków biznesowych?

Notebook and coffee with copy space on a wooden background. selective focusTakie pytanie (wydaje się, że retoryczne) padło podczas dzisiejszej, niespodziewanej, popołudniowej rozmowy telefonicznej zainspirowanej wpisem o architekturze procesów. A nawet się nie wydaje – jest retoryczne. Wykształconych analityków biznesowych brakuje. Głównie dlatego, że żadna uczelnia, w cyklu dziennym, ich nie kształci. Kształcą studia podyplomowe, ale pół roku, czy rok to zdecydowanie za mało. Brakuje mistrzów, przy których młody adept (dawniej, czeladnik) mógłby się uczyć i nauczyć. Mistrzów brakuje, ponieważ jeśli ktoś jest wyjątkowo zdolny i jakimś cudem dane mu było pracować i poszerzać przez dziesiątki lat swoją wiedzę i praktykę, to pracuje na 200% i nie ma czasu na dyrdymały. Brakuje wewnątrzorganizacyjnych metodyk analizy, gdyż brakuje mistrzów, którzy dostosowaliby dziesiątki standardów analizy biznesowej do realiów firmy, a mianowani, trzydziestoletni Senior Specials, Evangelists, Experts nie radzą sobie z zadaniem (i nic w tym dziwnego).

Pojawia się pytanie, czy jest szansa na poprawę? Systemowej, nie widzę. Mój rozmówca, także. Rynkowa…może, wraz ze wzrostem (powolnym) świadomości, że kapitałem firmy są kompetentni i zmotywowani ludzie oraz tego, że są problemy, których nie da się rozwiązać tuzinem (i wielokrotnością) dobrych ludzi, lecz jedynie co najmniej jednym wybitnym, coś ulegnie poprawie? Kto wie?

Trzymam(y) kciuki. Na razie jest smutek.


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

Evergreen, czyli architektura procesów biznesowych część 2

Fred Astaire Small

Fred Astaire

 

Przeglądnąłem wczoraj statystykę popularności wpisów, i ku mojemu miłemu zaskoczeniu, w czołówce, przez prawie dwa lata, znajduje się krótka wypowiedź o znaczeniu architektury procesów dla prac analitycznych. Oczywiście, na podstawie jednego spostrzeżenia nie należy wyciągać żadnych głębokich wniosków, ale żywiąc nadzieję, iż jeden z nich jest zbliżony do choć odrobinę trafnego, postanowiłem rozszerzyć temat, i sięgnąć zarówno do klasyki (Geary Rummler), jak i współczesności (Martyn Ould). I nie będzie to żaden cover, tylko pokazanie, w jaki sposób można, łącząc różne doświadczenia, uporządkować to co często bywa nieuporządkowane. Czyli architekturę procesów. A nawet ciut więcej – architekturę biznesową.

Zarządzamy procesami (a przynajmniej tak twierdzimy), mamy ich tysiące (to widać w repozytorium), poświęcamy na ich opisanie mnóstwo czasu (to widzimy po niskiej dostępności analityków procesowych), procesy są bardzo złożone i wyjątkowo specyficzne (bo my w ogóle jesteśmy inni niż setka innych firm działających w tej branży i robiących to samo).

-I co?

I jakoś nie udaje nam się nad tym zapanować na wysokim poziomie. Mamy poczucie, że szlifujemy szczegóły, które nie „spinają się” na poziomie makro. Więc szlifujemy dalej szczegóły … może się zepnie.

Szerzej oczywiście można byłoby pisać o symptomach świadczących o „nie spinaniu się”, ale temu być może poświęcę osobny wpis. W bieżącym, szybko będę zmierzał do pomysłu na zredukowanie problemu. Geary Rummler (jeden z moich tzw. guru), lata (świetlne, z punktu widzenia szybkozmiennego, współczesnego świata) temu, w ramach ogólnej koncepcji zarządzania wykonaniem (ang. performance improvement) opracował koncepcję Mapy Supersystemowej (ang. supersystem map). Mapa supersystemowa obrazuje otoczenie organizacji oraz jej wewnętrzną strukturę. Kluczowym z punktu widzenia rozważań niniejszego wpisu elementem mapy jest jej centralny blok zawierający działania zarządcze (ang. managing), wspierające (ang. contributing) oraz systemy tworzenia wartości (ang. value creation system) . Tak opisana struktura działań organizacji stanowi podstawę do stworzenia zarządzalnego, w oparciu o koncepcję procesową, systemu. Warto przy okazji pamiętać, iż system to układ elementów mający określoną strukturę i stanowiący logicznie uporządkowaną całość (definicja zaczerpnięta ze Słownika Języka Polskiego PWN). Aby stwierdzić, czy organizacja stanowi system, należy uwidocznić jej strukturę – czyli stworzyć jej model.

VCS

Mapa supersystemowa

O ile działania zarządcze oraz wspierające powinny być dobrze znane osobom zajmującym się wdrażaniem procesowego podejścia do zarządzania organizacją, o tyle systemy tworzenia wartości wymagają wyjaśnienia. Zgodnie z teorią Geary’ego Rummlera systemy tworzenia wartości powinny być konstruowane zstępująco (ang. top-down), poczynając od wyższych poziomów abstrakcji, a kończąc na poziomie pracy realizowanej na określonym stanowisku. Tak stworzona struktura jest nazywana w metodyce hierarchią tworzenia wartości (ang. value creation hierarchy). Poziom najwyższy, to deklaracja systemów tworzenia wartości. Duże organizacje zwykle będą miały wiele takich systemów – ich liczba stanowi wypadkową skali i różnorodności działania oraz granulacji systemów. W założeniu, pojedynczy system tworzenia wartości powinien być zarządzalnym jako całość przez określoną jednostkę biznesową, ciągiem działań prowadzących do dostarczania Klientom organizacji określonego rodzaju produktu, za który dana jednostka odpowiada. Dla przykładu, w instytucji finansowej można wyobrazić sobie jeden system tworzenia wartości produktu kredytowego, ale równie dobrze można wyobrazić sobie kilka systemów wartości w tym obszarze, na przykład biorąc jako dodatkowy wyróżnik segmentację Klientów. Wówczas można byłoby otrzymać system tworzenia wartości produktu kredytowego dla klientów korporacyjnych,  system tworzenia wartości produktu kredytowego dla małych i średnich przedsiębiorców oraz system tworzenia wartości produktu kredytowego dla klientów indywidualnych. Poziom granulacji systemów tworzenia wartości, jak łatwo się domyślić nie jest ustandaryzowany i wynikać powinien bezpośrednio ze specyfiki organizacji.

W kolejnym kroku dekompozycji, w ramach każdego z systemów wartości należy wyróżnić trzy obszary działań – wytworzenie (ang. launched), sprzedanie (ang. sold) oraz dostarczenie (ang. delivery). Każdy z obszarów jest odpowiedzialny za wiodące pojęcie:

  • wytworzenie – ma na celu dbać o cykl życia produktu (bądź usługi), począwszy od pomysłu nań, na wycofaniu z oferty zakończywszy.,
  • sprzedanie – ma na celu pozyskanie oraz utrzymanie Klienta na produkty (bądź usługi) wchodzące w zakres danego systemu tworzenia wartości,
  • dostarczenie – ma na celu obsłużenie zamówienia na określony produkt (bądź usługę), począwszy od złożenia zamówienia, na zakończeniu obsługi produktu zakończywszy.

Innymi słowy i w pewnym uproszczeniu, pierwszy z obszarów obejmuje cykl życia produktu, drugi – cykl życia Klienta, trzeci natomiast – cykl życia zamówienia. Między obszarami można sobie wyobrazić relacje wskazujące na fakt, iż dany obszar może funkcjonować przy założeniu, iż w poprzedzającym go obszarze wykonano już jakąś część prac (na przykład, Sprzedawanie może się rozpocząć, gdy Wytworzenie dostarczy opis finalnego produktu, aczkolwiek produkt może być jeszcze niedostępny dla Klientów). Relacje tego typu zostały na poniższym schemacie oznaczone linią ciągłą. Linia przerywaną zaznaczono potencjalną zasadność dostarczania informacji zwrotnych dla obszarów. Dla przykładu, może być zasadnym dostarczanie z poszczególnych wystąpień działań z obszaru dostarczania informacji o udzielanych upustach, reklamacjach oraz sugestiach odnośnie potencjalnych modyfikacji produktu zgłaszanych przez Klientów.

VCS (L2)

Pierwszy poziom dekompozycji systemu tworzenia wartości

Wnikliwemu czytelnikowi może szybko przyjść na myśl pytanie, czy ten poziom dekompozycji systemu tworzenia wartości ma na celu jedynie dostarczenie bazy do dalszych rozważań, czy tez może być wykorzystany do podejmowania jakichkolwiek decyzji biznesowych (pomimo faktu, iż każdy z systemów tworzenia wartości będzie dekomponowany w taki sam sposób). Pytanie trafne, a odpowiedź brzmi – na tym poziomie można już podejmować decyzje biznesowe. Jednym z przykładów jest poniższy rysunek koncepcyjny, prezentujący działania związane z obsługą Klienta jako wspólne dla wszystkich systemów tworzenia wartości. Podjęcie takiej decyzji, oznaczać będzie w praktyce konieczność zapewnienia między innymi  jednolitego spojrzenia na Klienta we wszystkich strumieniach produktowych, zapewnienia wsparcia narzędziowego (przede wszystkim wsparcia IT) umożliwiającego międzyproduktowe relacje z Klientami (np. crossselling), wdrożenia praktyk zarządczych umożliwiających utrzymanie jednolitości kontaktów z klientem w różnych jednostkach biznesowych.

Na tym poziomie opisu organizacji można także pokusić się o przypisanie jednostek organizacyjnych do realizacji prac w każdym z trzech obszarów systemu tworzenia wartości. Przypisanie to może w niektórych przypadkach rodzić konieczność podjęcia istotnych decyzji biznesowych i tym samym dostarczyć jako technika zauważalne korzyści.

VCS (L2) v1

Przesądzenia architektury biznesowej na wysokim poziomie opisu organizacji

Kolejnym poziomem dekompozycji systemów tworzenia wartości jest wskazanie procesów uczestniczących w realizacji poszczególnych obszarów. Jest to więc moment, w którym dotykamy bezpośrednio tematyki architektury procesów biznesowych, a tym samym problemu, jak ja tworzyć. Metodyka G. Rummlera, nie będąc wyjątkiem, pozostawia analityka procesowego (analityka biznesowego, architekta biznesowego) samemu sobie, nie podając wskazówek, jakimi należy się kierować podczas próby interpretacji pracy realizowanej w organizacji w terminach procesów. Jest to moim zdaniem spory jej mankament, gdyż utworzenie spójnego w ramach organizacji systemu procesów jest zadaniem bardzo trudnym, i bez podania choćby podstawowych kryteriów identyfikacji procesów, prawdopodobieństwo uzyskanie jednolitego podziału jest nieduże.

W sukurs dojrzałej i ustabilizowanej metodyce może przyjść Trzecia Fala Procesowości, czyli metodyka Riva opracowana przez Martyna Oulda. Okrzyknięta przez specjalistów z szeroko pojętego obszaru zarządzania procesami (ang. Business Process Management) jako powiew świeżego powietrza w dojrzałej już dziedzinie, Riva dostarcza kilka fundamentalnych wartości, spośród których do najważniejszych należy zaliczyć kilkuetapowy proces dochodzenia do architektury procesów biznesowych.

Punktem wyjścia do rozważań na temat architektury procesów w metodyce Riva jest model pojęć (albo model informacyjny organizacji, który jest tworzony na tym samym poziomie abstrakcji), którego przykład prezentuje poniższy rysunek. Na potrzeby dalszych rozważań, przyjmijmy, że Produkt, jako pojęcie abstrakcyjne jest konkretyzowany między innymi poprzez Produkt kredytowy. Każdy produkt wprowadzany na rynek wymaga przeprowadzenia określonej liczby Badań jakościowych, które mają potwierdzić bądź obalić czynione przy jego konstruowaniu założenia. Produkty tworzone są z myślą o określonych Segmentach, które kategoryzują Klientów obsługiwanych przez organizację.

MP (1)

Model pojęć

Model pojęć, opisany diagramem, stanowi integralną część modelu opisującego organizację na poziomie biznesowym, dostarczając aparatu pojęciowego potrzebnego do właściwego rozumienia pozostałych składowych modelu architektury biznesowej. Podobnie i w tym przypadku, model ten będzie stanowił punkt wyjścia do określenia architektury poprzez:

  1. zaklasyfikowanie poszczególnych pojęć do kategorii przedmiotu pracy (ang. unit of work),
  2. określenie relacji typu generates, pomiędzy przedmiotami pracy,
  3. utworzenie sieci procesów skupionych wokół pojedynczego przedmiotu pracy oraz relacji generates z innymi przedmiotami pracy według określonego wzorca,
  4. dostosowanie wzorcowej architektury do specyfiki organizacji.

W opisywanym podejściu, za przedmiot pracy należy uznać takie pojęcie, co do którego możemy powiedzieć, iż z biznesowego punktu widzenia praca jest wykonywana i rozliczana po to, by zmieniać stan tego pojęcia. W naszym przypadku, oznacza to, iż specjaliści dziedzinowi zgodzili się co do tego, iż praca wykonywana jest wokół poszczególnych rodzajów produktów finansowych (którego przykładem jest Produkt kredytowy) oraz Badań jakościowych. Co więcej, uznano, iż podczas pracy nad produktem powstaje konieczność uruchomienia prac nad badaniami jakościowymi, co zostało jawnie zaznaczone relacją generates. Mając to na uwadze, możemy już stwierdzić, iż procesy biznesowe będą stworzone dla tych dwóch przedmiotów pracy, oraz że wystąpią relacje pomiędzy procesami skupionymi wokół nich, o czym za chwilę.

Próbując nałożyć model pojęć na wcześniej zdekomponowany system tworzenia wartości, moglibyśmy stwierdzić, iż wyróżnione przedmioty pracy w pełni zawierają się w pierwszym z jego etapów – Wytworzeniu. Przypisanie to, zilustrowane poniżej, należy traktować jako koncepcję, która niekoniecznie musi znaleźć odzwierciedlenie w diagramie.

VCS (L2) v2mp

Przypisanie przedmiotów pracy do obszaru systemu tworzenia wartości

 

W kolejnym kroku metodyki Riva, z każdym z przedmiotów pracy należy związać trzy rodzaje procesów, kategoryzowanych jako:

  • case process – proces, którego instancje będą tworzone dla każdej instancji przedmiotu pracy (w naszym przypadku, dla każdego z produktów kredytowych, rozumianych katalogowo) i będą odpowiadały za operowanie na instancji przez cały cykl jej życia.
  • case management process – proces jednoinstancyjny, którego zadaniem jest zarządzanie instancjami typu case process, uruchomionymi dla określonego przedmiotu pracy,
  • strategy process – proces jednoinstancyjny, którego celem jest dokonywanie strategicznych przesądzeń dla danego przedmiotu pracy (na przykład, ustalanie reguł biznesowych związanych z danym przedmiotem pracy).

Prócz utworzenia procesów, metodyka wskazuje na relacje je łączące, bazując jednakże bardziej na charakterze relacji, niźli konkretnym jej kontekście. Przykład przekształcenia  omawianych dwóch przedmiotów pracy oraz relacji generates na architekturę procesów przedstawia poniższy diagram. Zgodnie z regułą, dla każdego z dwóch przedmiotów pracy utworzono po 3 diagramy różnych typów. Bazując na relacji generates prowadzącej od Produktu kredytowego do Badania jakościowego, utworzono dwie relacje:

  • jedną pomiędzy procesem Utrzymanie produktu kredytowego a Zarządzanie badaniami jakościowymi, reprezentującą prośbę o uruchomienie badania jakościowego (a precyzyjniej, utworzenie instancji procesu Przeprowadzenie badania jakościowego), za których koordynacje proces odpowiada.
  • drugą pomiędzy Zarządzaniem produktami kredytowymi a Zarządzaniem badaniami jakościowymi, reprezentującą fakt mediacji pomiędzy procesami zarządczymi w sytuacji, gdy nie można uzyskać kompromisu w poprzednio opisanej komunikacji.

 

APB.png

Architektura procesów biznesowych

 

Opisany sposób transformacji przedmiotów pracy na architekturę procesów zgodnie z przedstawionym wzorcem jest nazywany w metodyce Riva tworzeniem pierwszej wersji architektury procesów (ang. first cut architecture). W kolejnym kroku, należy skonfrontować tak powstały obraz architektoniczny z rzeczywistością organizacyjną, w efekcie czego może dojść do uproszczenia modelu – na przykład poprzez redukcję relacji, przypisanie odpowiedzialności niektórych procesów, w sytuacji, gdy działania w procesach są trywialne, do innych procesów, itp. Oczywiście, na potrzeby niniejszego wpisu, zasady tworzenia powiązań pomiędzy przedmiotami pracy oraz transformacji na pierwszą wersję architektury zostały przedstawione wybiórczo, aby jedynie zaprezentować samą koncepcję. Cała pozostała złożoność metodyki Riva w tym zakresie pozwala na pokazanie większej liczby odcieni szarości, jakie mogą wystąpić podczas tworzenia architektury procesów.

Zidentyfikowane w powyżej przedstawiony sposób procesy oraz relacje występujące pomiędzy nimi, stanowią kolejny etap, jawnie ujęty w metodyce G. Rummlera, dekompozycji systemu tworzenia wartości. W rozważanym przykładzie, udało nam się stworzyć fragment architektury w pełni zawierający się w obszarze Wytworzenia, systemu wartości dla Produktu kredytowego. Docelowo, w ten sposób można byłoby wytworzyć architekturę dla wszystkich trzech obszarów, pokazując w jaki sposób, na poziomie samych deklaracji procesów realizowana jest praca (łącznie z informacjami zwrotnymi) mająca na celu dostarczać Klientom produktu i usługi z danego obszaru biznesowego.

 

VCS (L2) v3ap

Drugi  poziom dekompozycji systemu tworzenia wartości

Metodyka G. Rummlera wprowadza kolejne poziomy dekompozycji, prowadzące, poprzez opisy przebiegów poszczególnych procesów biznesowych, do poziomu opisu odpowiedzialności na poszczególnych rodzajach stanowisk pracy. Z uwagi jednakże na fakt, iż wpis dotyczy jedynie tematu architektury procesów, na tym etapie zakończę już wpis.

Na zakończenie pragnę zwrócić jeszcze uwagę na kilka mniej, lub bardziej jawnie ujętych wcześniej zagadnień, które warto przy tej okazji zgłębić.

Po pierwsze, z przedstawionej koncepcji dochodzenia do architektury procesów biznesowych jawnie wynika, iż jest ona integralną częścią większego systemu, jakim jest opis organizacji. Co więcej, nie jest nadrzędnym elementem, co oznacza, iż tworzenie architektury procesów biznesowych musi być poprzedzone wcześniejszymi pracami, mającymi skutkować utworzeniem kontekstu biznesowego dla niej. W aktualnie obowiązującej terminologii, można byłoby stwierdzić, iż architektura procesów biznesowych jest składową architektury biznesowej, z którą powinna być zgodna.

Po drugie, koncepcje Mapy supersystemowej oraz systemów tworzenia wartości zostały przedstawione jedynie w aspekcie dochodzenia do architektury procesów. Zupełnie pominąłem aspekt zarządzania wykonaniem organizacji (ang. performance management), bez którego w praktyce nie ma sensu tworzyć takiego modelu. Bardzo upraszczając, konstruowany opis organizacji należy uzupełnić o stawiane na różnych poziomach cele, uwzględnić zakres oraz sposoby pomiarów celów oraz przewidzieć mechanizmy, które pozwolą na analizę i podejmowanie działań, mających na celu usunięcie nieakceptowalnych rozbieżności pomiędzy planem a realizacją.

Po trzecie, chciałbym jawnie stwierdzić, iż architektura biznesowa obejmuje zakres jeszcze szerszy, niż to co zostało opisane we wpisie i dodane w pierwszych dwóch punktach uzupełnienia. Patrząc z punktu widzenia samej struktury informacji, pominąłem modele decyzyjne, reguły biznesowe, cały model opisujący plan biznesowy organizacji oraz wiele innych elementów, których stosowanie jest uzależnione od specyfiki organizacji. Warto mieć to na uwadze próbując wdrażać techniki analizy biznesowej, gdyż praktyka pokazuje, że bardzo często realizacja jednych prac rodzi konieczność wdrożenia do analitycznego przybornika nowych technik, które to z kolei… w ten sposób, ewolucyjnie, można wdrażać analizę biznesową i architekturę biznesową. Aby to jednak zadziałało należy mieć metodykę, należy dysponować mechanizmami pozwalającymi na jej rozbudowę, zasobami ludzkimi, które tę trudną pracę wykonają oraz dużo cierpliwości, gdyż nie od razu Kraków zbudowano. Próba pójścia na skróty z pewnością, wcześniej, czy później, zawiedzie.


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

Recenzja: The Microguide to Process And Decision Modeling

Process and Decision ModelingDwa miesiące temu znalazłem w końcu czas, by przeczytać książkę, która czekała na mnie dłuższą chwilę. Kupiłem ją mając wątpliwości czy określenia microguide oraz process and decission modeling wzajemnie sobie nie przeczą. Nie mniej jednak, kupiłem, gdyż dopóki nie przeczytałem, nie wiedziałem. Poniżej, garść subiektywnych wrażeń po lekturze. Na wstępie, przedmowa autorstwa James’a Sinur’a, w której czytamy

For organizations that have a planning culture, this book is a bible […]

Stwierdzenie motywujące, więc tym chętniej zagłębiam się w lekturę.

Wstęp. Kilka stron poświęconych głównym wątkom książki: procesowi, decyzji oraz zdarzeniu (biznesowemu). Warte przeczytania, gdyż z jednej strony prezentują znaczenie każdego z aspektów opisu organizacji, z drugiej, porządkują wiedzę.

Rozdział 1. Definitions. Podobnie jak w przypadku wstępu, rozdział służy uporządkowaniu wiedzy. Metodą zstępującą, czytelnikowi prezentowane są różne aspekty procesowości, inżynierii decyzji oraz zdarzeń. Autorzy anonsują wzorce modelowania decyzji oraz, w stopniu adekwatnym do rozmiaru książki, omawiają zależności łączące reguły biznesowe oraz decyzje. Rozdział jak najbardziej wart poświęcenia czasu; także przez osoby, które w każdej z dziedzin mają już własne doświadczenia.

Rozdział 2. Modeling Basics. Tutaj autorzy troszkę mnie zaskoczyli. Większą część rozdziału zajmuje bowiem wstęp do składni BPMN 2.0., który, moim zdaniem, jest zbyt powierzchowny, by czegokolwiek praktycznego nauczyć, natomiast zbyt rozbudowany, by odwołać się do intuicji. Niejawnie założyłem, iż autorzy będą się koncentrowali na wskazywaniu zależności łączących dwa wymienione w tytule aspekty funkcjonowania organizacji, więc po przebrnięciu przez rozdział w poszukiwaniu sensu, czułem się lekko zawiedziony.

Rozdział 3. Building on the Basics. Analogicznie, jak w rozdziale poprzednim, autorzy wprowadzają kolejne konstrukcje BPMN. I tak samo, jak w poprzednim rozdziale zbyt szczegółowo i zbyt pobieżnie.

Rozdział 4. Handling Complexity. Walki z BPMN ciąg dalszy. W rozdziale załączono wyjątkowo dużo informacji dostępnych wprost w specyfikacji BPMN 2.0, co jeszcze bardziej pogarsza moją ocenę.

Rozdział 5. Business Events and Business Event Modeling. Ten rozdział ponownie trafia w moje oczekiwania. BPMN jest w nim omówiony w kontekście modelowania zdarzeń biznesowych, a w zasadzie w kontekście traktowania organizacji jako systemu reagującego na zdarzenia. Wartościowe spojrzenie, wartościowy fragment książki, materiał stymulujący do rozważań.

Rozdział 6. Connecting Decisions in DMN to Processes in BPMN. Analogicznie jak w przypadku rozdziału 5, bardzo wartościowy fragment książki. Kolejny rozdział, w ramach którego autorzy wywiązują się z obietnicy złożonej tytułem książki. Przykłady omawiane w rozdziale są na tyle rozbudowane, by dotknąć rzeczywistości analitycznej i wskazać kierunki myślenia przy podejmowaniu niektórych rodzajów decyzji związanych ze sposobem interpretowania i modelowania biznesu.

Rozdział 7. Execution Semantics. W rozdziale autorzy powracają niestety do wcześniejszych praktyk tłumaczenia BPMN, tym razem na poziomie wykonywalnym. Moim zdaniem, zupełnie niepotrzebny rozdział, tym bardziej, że z praktycznego punktu widzenia, niewiele można z niego wynieść.

Rozdział 8. Conclusions. Krótko i zwięźle.

Aneks A. Commercial Information. Reklamy.

Podsumowując, w mojej opinii „mniejsza połowa” książki stanowi o jej wartości, dużej wartości. Połowa większa, stanowi dodatek, którego wartości nie dostrzegłem. Jest to w moim mniemaniu materiał na inną pozycję, w ramach której należałoby go jednak poszerzyć o aspekt praktyczny, aby stanowiła nową wartość na dość dobrze już rozwiniętym rynku książek typu „BPMN 2.0 od podstaw”.

Dane bibliograficzne:

Taylor, James; Debevoise, Tom (2014-12-05). The MicroGuide to Process and Decision Modeling in BPMN/DMN: Building More Effective Processes by Integrating Process Modeling with Decision Modeling, ISBN-10: 1502789647, ISBN-13: 978-1502789648

Odnośnik do Amazon.com.


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

Definicja pojęcia. Odcinek 2

IdeaLogika matematyczna poradziła sobie ze sposobem tworzenia definicji. Wydaje się, iż analityk, drzwi otwartych wyważać nie powinien, i tworząc model pojęciowy (model koncepcji, za SBVR) winien opierać się na Dobrych Praktykach.

Kryteriów kategoryzacji definicji jest wiele. Z punktu widzenia analizy biznesowej warto zwrócić uwagę na cel definicji oraz jej budowę.

Definicja, może dotyczyć istniejącego terminu, nazywana jest wówczas leksykalną, bądź nowego terminu – wówczas nosi nazwę projektującej. Definicje leksykalne, mogą być odzwierciedleniem pojęć wynikających z zewnętrznych regulacji, standardów, powszechnych konotacji bądź wewnątrzorganizacyjnego żargonu. Na przykład: Stół to mebel posiadający blat oraz co najmniej jedną nogę. Definicje projektujące, dotyczą terminów nieistniejących w momencie ich definiowania, bądź taki, których znaczenie jest zmieniane. Na przykład aliquota (termin podchodzący z obszaru sprzedaży samochodów w systemie argentyńskim, w którym miałem okazję uczestniczyć) to wskaźnik określający aktualny, procentowy poziom wpłaty na samochód. O ile definicje leksykalne są intuicyjne, o tyle definicje projektujące wymagają, jak mi się wydaje, dodatkowego komentarza. Intuicyjnie, wydaje się, iż analizując organizacje, ciężko jest mówić o projektowaniu nowych pojęć. Przyglądając się jednakże bliżej problemowi, łatwo można skonkludować, iż definicje projektujące mają szansę pojawić się w momencie, gdy projektowany jest docelowy (usprawniony) model organizacji. Wówczas bowiem, tworząc nowe zasady funkcjonowania, pojawić się mogą nowe terminy, a wraz z nimi definicje(1).

Mając zdefiniowany cel definicji, należy się przyglądnąć definicji formie. Logika matematyczna podpowiada nam kilka możliwości, z których wydaje się, iż największe przełożenie na codzienność analityczną może mieć metoda równościowa. Bazuje ona na schemacie wyrażeniowym składającym się z trzech podstawowych części oraz łącznika równościowego:

[definiowany termin] [łącznik równościowy] [termin ogólny] [wyrażenie różnicujące].

Przykładem definicji skonstruowanej według powyższej formy jest:

Stół to mebel posiadający blat oraz co najmniej jedną nogę.

Definiowanym terminem jest stół. Łącznikiem równościowym jet to. Terminem ogólnym jest mebel, a wyrażeniem różnicującym posiadający blat oraz co najmniej jedną nogę. Warto przy okazji zwrócić uwagę na fakt, iż wiele rożnych wyrażeń może definiować to samo znaczenie. Dla przykładu, definicję stołu można byłoby zapisać jako Stół jest meblem posiadającym blat oraz co najmniej jedną nogę. Znaczenie jest identyczne, jak w przypadku wcześniejszej definicji.

Zakładając, iż definicje pojęć stanowią składową modelu pojęć, można zastanawiać się, czy wykorzystywane w definicji terminy mogą mieć odzwierciedlenie na diagramach. Odpowiedź, jak łatwo się domyślić, jest twierdząca. Zarówno pojęcia specjalizowane, jak i generyczne mogą stanowić składową modelu pojęć; dla omawianych przykładów mógłby on wyglądać następująco.

ModelPodsumowując, tworzenie definicji jest działaniem opartym o wiedzę (a nie Palec Boży), i w związku z tym powinno być realizowane systemowo. Niedefiniowanie pojęć jest błędem, definiowanie pojęć w sposób niesystemowy jest błędem a definiowanie w sposób właściwy…koniecznością. Nie jest to żadna dodatkowa wartość, lecz warunek konieczny do stworzenia poprawnego modelu biznesu.

W sumie, oczywiste. Ale dlaczego, nie powszechne?

(1) W kategoriach Business Process Management, i spojrzenia na zagadnienie z punktu widzenia metodyki Riva, naturalnym kandydatem na terminy wymagające stworzenia definicji projektujących są designed business entities.


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

Tłumaczenie pojęć BPMN 2.0 na język polski

BPMN logo smallMiło mi poinformować o udostępnieniu na stronach AION autorskiego tłumaczenia angielskich pojęć z zakresu BPMN 2.0 na język polski. Mamy tym samym nadzieję, iż pozwoli to ujednolicić terminologię stosowaną w pojawiających się coraz częściej dokumentach omawiających BPMN .

Dokument z tłumaczeniem znajduje się na stronie bazy wiedzy z zakresu analizy biznesowej . Serdecznie zapraszamy do lektury oraz do przesyłania ewentualnych uwag.