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.

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.

UML a model pojęć

airMail XSList od czytelnika

Na początku tego tygodnia przeprowadziłem ciekawą dyskusję dotyczącą zasadności stosowania diagramu klas języka UML do tworzenia modelu pojęć. Modelu pojęć dla całej organizacji. Za zgodą autora, publikuję najistotniejszy fragment listu, który dyskusję zapoczątkował.

[…]  postanowiłem sprawdzić, co w Internecie piszą na ten temat. Okazało się, że w większości są to ogólniki. […] Na jednej z polskich stron znalazłem kilka wpisów, z których jeden wprost krytykuje taki pomysł. Nie mam bardzo dużego doświadczenia w analizie biznesowej, gdyż na co dzień pełnię rolę analityka i architekta systemów, więc ciężko mi się do niego odnieść. […] Moje doświadczenia w tym względzie wynikają przede wszystkim z kontaktów z architektami oraz efektami prac analityków biznesowych. […] W mojej organizacji podjęto decyzję o usystematyzowaniu prac analityków biznesu oraz analityków systemów […] i z naszej strony uczestniczę w pracach zespołu, który ma to (metodę przyp. aut.) wykonać. […] Z Pana wpisów wynika, iż UML można stosować do stworzenia takiego modelu. Mógłbym prosić o uzasadnienie, dlaczego Państwo wybraliście UML?

Dyskusja bardzo szybko została przeniesiona z platformy mejlowej na telekomunikacyjną, dzięki czemu udało się wymienić spostrzeżeniami, opiniami i wyciągnąć wnioski. Poniżej, przedstawiam ich krótkie podsumowanie.

Standard

UML to standard jeśli chodzi o język służący do opisu struktur informacyjnych. Celowo unikam określenia „struktur danych”, gdyż zastosowanie UML nie ogranicza się do tego aspektu prac analitycznych. Skoro to standard, to jest spore prawdopodobieństwo, że będzie zrozumiały dla stosunkowo szerokiej grupy odbiorców. Skoro to standard, to z pewnością będzie wspierany przez dużą część dostawców narzędzi do modelowania. Z tych dwóch powodów, UML jest najprawdopodobniej najlepszym wyborem w przypadku przedsięwzięć, w którym liczba różnych grup interesariuszy modelu oraz osób go wykorzystujących jest niemała.

Istota

Trzy elementy stanowią clue modelu pojęć: wyrażenie reprezentujące pojęcie, definicja oraz zależności (fakty) łączące pojęcia. Teoretycznie, można przyjąć, iż reprezentacja pojęcia nie musi być li tylko wyrażeniem słownym – może to być na przykład ikona. W praktyce można jednak założyć, iż inne reprezentacje niż wyrażenia tekstowe nie wystąpią. Skoro mamy słowa, to powinniśmy mieć i ich znaczenie. Znaczenie jest określane definicją. I ten element stanowi jeśli nie najtrudniejszy, to jeden z najtrudniejszych aspektów modelu pojęć. To właśnie od błędnych, bądź nieistniejących definicji wyrażeń tekstowych, jakimi posługują się specjaliści biznesowi, rozpoczynają się problemy komunikacyjne. Początkowo, jedynie podczas opisu sposobu funkcjonowania biznesu, a następnie przekładają się i multiplikują na etapie planowania rozwiązań IT. Ostatni z elementów to zależności pomiędzy pojęciami (w pewnym sensie, także będące pojęciami), oddające swoją nazwą oraz ewentualną definicją, logiczny ich charakter.

Cel

Po co tworzymy model pojęć? Po to, by zapisać wiedzę o jakiejś dziedzinie. Po to, by się na tej podstawie skutecznie i efektywnie komunikować . I to wszystko. Żadnych systemów, żadnych baz danych, żadnych procesów.

W przypadku analizy biznesowej, ogólne określenie wiedza najczęściej  doprecyzowuje się określeniem wiedzy dziedzinowej, czy wiedzy biznesowej.

Jak może wyglądać taki model?

Może na przykład przyjąć formę tekstową, a przykładowe zapisy mogłyby brzmieć na przykład tak. Wiedza analityczna służy analitykom biznesowym. Wiedza analityczna jest pozyskiwana od specjalistów dziedzinowych. Specjalista dziedzinowy zna obszar dziedzinowy. Specjalista dziedzinowy wspiera analityka biznesowego. Analityk biznesowy posługuje się technikami analitycznymi. Modelowanie procesów jest technika analityczną. Inżynieria reguł biznesowych jest techniką analityczną.

Jak wyglądałby taki model w notacji dedykowanej modelom pojęciowym?

CMap. To technika dedykowana takim zastosowaniom. Model wyglądałby następująco.

CMcmap.PNG

Przykładowy model w notacji CMap

Standardem UML można go zastąpić?

Tak. Poniżej odpowiednik.

CMuml

Model pojęć w notacji UML

Czy wszyscy go dobrze przeczytają?

Tak. Być może trzeba będzie poświęcić 20 minut więcej na wytłumaczenie kilku symboli UML. Może nawet 40 minut. A w przypadku stosowania zaawansowanych konwencji, może i 60 minut więcej niż w przypadku CMap, czy jakiejkolwiek innej notacji dedykowanej mapom pojęć. Ale jest to czas pomijalny z punktu widzenia przedsięwzięć polegających na wdrożeniu ogólnoorganizacyjnych modeli pojęć. Całkowicie pomijalny.

W praktyce, można sobie wyobrazić konstrukcje występujące w dedykowanych językach do modelowania pojęć, które nie dadzą się wprost zaprezentować notacją UML, aczkolwiek wystarczy zastosować proste konwencje, które bez utraty informacji i łamania jakichkolwiek zasad języka UML, pozwolą na ich reprezentację w standardzie. Dlatego uważam, iż nie ma praktycznych przeciwwskazań do stosowania UML w tym zakresie, natomiast jest kilka silnych argumentów za tym przemawiających, o których napisałem na wstępie.

Odrobina teorii dla wnikliwych

Ale czy przypadkiem UML nie został zastosowany jako obrazek, w tle łamiąc semantykę pojęć takich jak np. klasa, czy asocjacja? Nie, brzmi odpowiedź. Powołując się na autorytet w dziedzinie map pojęciowych, jakim jest profesor Joseph Novak, można przytoczyć jego definicję słowa concept, rozumianego w niniejszym wpisie jako pojęcie(*).

Concept is a perceived regularity in events or objects, or records of events or objects, designated by a label.

Pojęcie jest więc czymś, co jesteśmy sobie w stanie wyobrazić, podać jego cechy i czasami definicję, czego reprezentacją jest wyrażenie tekstowe.

Klasa w języku UML jest pośrednio wyprowadzona z pojęcia klasyfikator (ang. classifier), z którym w specyfikacji UML 2.5 skojarzono następującą definicję.

A Classifier represents a classification of instances according to their Features.

Klasyfikator obejmuje więc swoim zakresem instancje, które są zgodne co do swoich właściwości (features). Podobieństwo to można bezpośrednio przełożyć na regularność (regularity), występującą w definicji „concept”. Dalsze specjalizacje (StructuredClassifier, EncapsulatedClassifier, Class) nie zmieniają jakościowo tej definicji, dając możliwość skojarzenia z klasą dodatkowych cech, aczkolwiek żadna z tych cech nie jest obligatoryjna (rysunek poniżej) . Sama klasa zdefiniowana jest następująco.

A Class classifies a set of objects and specifies the features that characterize the structure and behavior of those objects.

 

UMLmetamodelclass

Fragment metamodelu UML 2.5 dotyczący metaklasy Class

Powyższe rozważania pokazują, iż zastąpienie dedykowanych notacji do tworzenia diagramów pojęć, diagramami klas języka UML nie wypacza w żaden sposób intencji twórców UML.

(*) Model pojęć i model koncepcji w dziedzinie analizy biznesowej są traktowane jako określenia tożsame.

 


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

Model pojęć – dlaczego tak trudno napotkać go w przyrodzie? Ciąg dalszy.

IdeaModel pojęć, wydawałoby się, jeden z kluczowych aspektów szeroko pojętej architektury biznesowej, jest chyba jednym z najrzadziej spotykanych w modelach rodzajów artefaktów. Pisałem o problemie we wpisie Definicja pojęcia. Odcinek 3 i do niego chciałbym teraz nawiązać. Szukając poprzednio przyczyn takiego stanu rzeczy, wymieniłem cztery, które przychodziły mi do głowy:

  • brak świadomości znaczenia modelu pojęć dla działań analitycznych,
  • niezrozumienia pojęcia „model pojęć”,
  • brak umiejętności tworzenia modelu pojęć,
  • brak umiejętności poprawnego definiowania pojęć.

W dalszym ciągu podpisuję się pod nimi, aczkolwiek niedawno, w ramach refleksji nad przeprowadzonymi pracami, do głowy przyszedł mi kolejny powód, jakim jest „oczywista oczywistość”. Oczywista oczywistość, że wiemy kto to jest Klient (od lat ich obsługujemy). Oczywista oczywistość, że wiemy czym się różni Klient potencjalny od Klienta. Oczywista oczywistość, że nie można zdefiniować ostrej granicy pomiędzy Klientem potencjalnym a Klientem. Oczywista oczywistość, że nie ma sensu definiować tych pojęć. Oczywista oczywistość, że wszyscy wiedzą jaka jest różnica pomiędzy tymi pojęciami.

Oczywiście, oczywistość „oczywistych oczywistości” w praktyce taka oczywista nie jest. Bo w praktyce, przy okazji sporej liczby projektów, w których terminologiczna nieścisłość sprawia zauważalny problem, o problemie się dyskutuje. To zajmuje czas. Ponieważ często problemy terminologiczne potrafią być złożone, może się zdarzyć, że osiągnięta zostanie wystarczająco dobra, jak na potrzeby tego, konkretnego projektu postać definicji, albo ustalone zostanie, że problem jest ważny i oczywiście należy się nim zająć, ale w jakimś kolejnym projekcie. I oby do następnej kadencji, pardon, projektu.

Oczywistą oczywistością jest natomiast to, że bez jasno określonych znaczeń niektórych pojęć, komunikacja staje się:

  • utrudniona (poprzez powracające pytania),
  • nieoptymalna (poprzez powracające pytania),
  • niepewna (nie mamy pewności, czy wszystkie strony tak samo rozumieją pojęcia).

A jeśli szwankuje komunikacja, to z pewnością odbije się to czkawką przy tak zwanej innej okazji (procesy będą niewłaściwie skonstruowane, decyzje będą bazowały na niewłaściwych założeniach, systemy będą wymagały poważnych zmian, gdy okaże się, że trzeba na wrażliwy aspekt pojęć spojrzeć z innej strony). I wydawałoby się, że argumenty te powinny działać na korzyść podejmowania trudu tworzenia modeli pojęć – niestety, w większości znanych mi przypadków nie działają. Natomiast broni składać nie można. Być może, argumentem będzie dostarczenie innej, bezdyskusyjnej wartości, do wytworzenia której niezbędnie niezbędny będzie model pojęć? Ale o tym już następnym razem…


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

IdeaSłowniki pojęć, definicje pojęć, modele pojęć stanowią dla mnie ostatnimi laty spore wyzwanie…motywacyjne. Być może jestem wyjątkowym pechowcem w tym obszarze; co nie zmienia faktu, iż ostatnio parokrotnie spotkałem się z tak dużym – nieadekwatnym do skali zagadnienia – oporem zespołów realizujących prace analityczne przed tworzeniem modeli pojęć, że skłoniło mnie to do głębszej analizy przyczyn tego stanu rzeczy. Wprawdzie potwierdzenia moich wniosków od wspomnianych zespołów nigdy nie otrzymałem, ale mam silne przekonanie, iż główne powody oporu są następujące:

  • brak świadomości znaczenia modelu pojęć dla działań analitycznych,
  • niezrozumienia pojęcia „model pojęć”,
  • brak umiejętności tworzenia modelu pojęć,
  • brak umiejętności poprawnego definiowania pojęć.

Początkowo, wydawało mi się, iż głównym powodem jest głęboko zakorzenione przekonanie, iż Prawdziwi Analitycy, w przeciwieństwie do Analityków Teoretyków koncentrują się na Problemie i odrzucają, zbędne formalizmy, które nie dość, że opóźniają pracę, to jeszcze stanowią pożywkę dla niepotrzebnych dyskusji O Jakiś Metodykach. Aczkolwiek teraz skłonny jestem stwierdzić, iż jest to raczej przyjmowana postawa, niźli głębokie przekonanie.

Przy takim założeniu, należy przyczyn szukać dalej. Niezrozumienie pojęcia „model pojęć” może takową stanowić. Choć technika modelowania pojęć została już wielokrotnie opisana w szeroko pojętej literaturze fachowej, jej wdrażanie w praktyce w dalszym ciągu możne sprawiać problemy. Dla przykładu, często pojawia się pytanie jak dużo cech pojęć należy opisywać w modelu? Często także należny zmierzyć się z pytaniem, czym się różni model pojęć od modelu danych? Gdyby jednakże to miało być tą główną przyczyną oporu, zapewne wspomniane zespoły postawiłyby jawnie takie pytania.

Pozostaje więc do rozważenia brak umiejętności. I obawiam się, że tutaj należy szukać praprzyczyn… „Powszechnie znielubiany” UML, ERD odrzucane z uwagi na silne konotacje z bazami danych, Concept Maps, Topic Maps nieznane, podobnie jak techniki proponowane przez Ronalda Rossa, SBVR uznawany za teorię teoretyczną…wszystko to powoduje, iż spora cześć zespołów analitycznych odrzuca już na wstępie tę fundamentalną technikę analityczną z uwagi na … brak wiedzy z zakresu a tym samym, umiejętności jej stosowania.  A szkoda, bo nie ma głupszych błędów, niż te wynikające z niezrozumienia znaczenia słów.

W pierwszym akapicie wspomniałem o wyzwaniu motywacyjnym. Wyzwanie w dalszym ciągu istnieje, bowiem w 2 na 4 przypadki nie udało się zmotywować zespołów analitycznych realizujących prace, do stworzenia modelu pojęć na poziomie analizy biznesowej (oba projekty dotyczyły usprawnienia procesów i wdrożenia systemu, więc można mówić o poziomie CIM tworzonego modelu). W dalszym ciągu szukam więc argumentów, które w kolejnych tego typu sytuacjach, mogłyby zespoły przekonać do tej techniki. Przekonać, a nie tylko przymusić.

P.S. Bardzo dziękuję za mejle dotyczące modelu pojęć (koncepcji). Mam nadzieje, że odpowiedzi, pomimo sporego opóźnienia, okazały się przydatne. Jednocześnie, zachęcam do komentowania wpisów na blogu.

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.

Definicja pojęcia

Definicja to zestaw słów nadający znaczenie słowu lub zestawowi słów.

Definicja to zestaw słów nadający znaczenie słowu lub zestawowi słów.

Definicja to zestaw słów nadający znaczenie słowu lub zestawowi słów.

Definiowane pojęcie to pojęcie ogólne wraz z określeniem wyróżniającym.

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

Ciąg dalszy nastąpi.

 


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

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.