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.

Plakat BPMN 2.0

Z przyjemnością informuję, iż w ramach AION opracowaliśmy i opublikowaliśmy nasz własny plakat prezentujący konstrukcje wykorzystywane do opisu przebiegów procesów biznesowych w BPMN 2.0. Mamy nadzieję, iż ten prosty dokument pozwoli na sprawniejsze konstruowanie modeli oraz umożliwi właściwa interpretację wykorzystywanych w modelach procesów konstrukcji.

Zapraszamy do lektury.

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.

Evergreen, czyli architektura procesów biznesowych

Fred Astaire

Fred Astaire

Tworzenie architektury procesów biznesowych należy do wdzięcznych, wiecznie żywych i rzadko kiedy poważnie – w początkowych fazach projektów – traktowanych tematów. Efekt jest najczęściej taki sam – niegasnące dyskusje na temat zasadności podziału działań w procesach, zasadności tworzenia wielopoziomowych zagłębień podprocesów, sposobu komunikowania się procesów (na przykład, stosować, czy nie stosować w opisie procesów biznesowych na poziomie organizacji konstrukcje BPMN 2.0 Call Activity).

Następuje więc w projekcie taki moment, kiedy nad zasadami podziału organizacji na procesy należy się pochylić. I jest to moment, od którego ból pleców się zaczyna. Bez względu na czas poświęcony na trwanie w pozycji pochylonej, bez jasno określonej, dobrej techniki podziału problemu nie uda się rozwiązać. Niestety, większość znanych mi metodyk usprawniania procesów do tematu podchodzi w sposób dość wygodny, stwierdzając, iż architekturę procesów biznesowych należy stworzyć. Często, pojęcie nie pada jawnie, przyjmując postać sformułowania hierarchii procesów – będącej jedną z form określania architektury procesowej. Co więcej, wraz z podziałem całości działań na procesy zalecane jest tworzenie procesów end-to-end (cokolwiek w praktyce to  oznacza), koncentrowanie się na łańcuchach wartości i dostarczaniu klientowi (kimkolwiek jest) wartościowych produktów. Intuicyjnie, jest to zrozumiałe, natomiast w praktyce niewystarczające.

Do problemu podchodzę empatycznie, gdyż przez lata sami w firmie poszukiwaliśmy jasnych zasad wyodrębniania procesów biznesowych z całości prowadzonych działań i najczęściej, po ukończeniu kolejnego projektu mieliśmy wątpliwości, czy jesteśmy w stanie jasno określić zastosowane niejawnie zasady podziału (czasami, przyjmowaliśmy podział przedstawiony przez Klienta, próbując na poziomie opisów przebiegów procesów ratować sytuację). Pewnego dnia w nasze ręce trafiła książka Business Process Management: A Rigorous Approach opisująca mało wówczas znaną nam metodyk Riva. I tak oto zaczęła się nasza długa przygoda z metodyką, niezależnie od tego, czy mamy okazję zastosować rekomendowaną technikę Role Activity Diagram (RAD), czy też skazani jesteśmy na BPMN. Dostosowując podejście do standardów przemysłowych, zamiast oryginalnie zaprezentowanych środków wyrazu, stosujemy:

  • diagramy klas języka UML do opisu encji biznesowych (business entity) oraz przedmiotów pracy (unit of work) oraz zależności (dependency) łączących poszczególne przedmioty pracy,
  • autorski profil języka UML, dostosowujący ogólne mechanizmy modelowania klas do specyfiki metodyki RIVA,
  • BPMN 2.0, do opisu architektury procesów oraz przebiegów procesów, w zgodzie z zaleceniami metodyki RIVA.

Dzięki połączeniu tych dwóch światów: skutecznej metodyki i przemysłowych standardów wyrazu, udaje nam się z projektu na projekt wyprowadzać na prostą niejasne architektury oraz nadać projektom obejmującym tworzenie procesowego obrazu organizacji właściwe tempo. Nie piszę tego z myślą o zareklamowanie usług, lecz wskazanie skuteczności metody w praktycznych zastosowaniach. Książka Martyna Oulda nie jest bardzo obszerna – można ją ze zrozumieniem przeczytać w ciągu kilku dni. W ramach kolejnych wpisów zaprezentuję nasze podejście do realizacji zaleceń metodyki, mając nadzieję, iż uzupełniając książkę będą stanowiły dobry dobry punkt wyjścia do zainteresowania się RIVĄ.

Problem Business Process Management (BPM)

Pod koniec lat 90-tych miałem okazję uczestniczyć w programie szkoleniowym i certyfikacyjnym metodyki Geary’ego Rummlera. Firma przez niego prowadzona stawiała sobie między innymi za cel promowanie procesowego podejścia do usprawniania organizacji, z angielska nazywanego Business Process Improvement (BPI).

BPI, stanowiło już wówczas w metodyce Rummlera, element bardziej ogólnej filozofii zarządzania organizacją – Business Process Managament (BPM). Upłynęło naście lat, i wydawałoby się, że koncepcje te powinny już okrzepnąć i dobrze osadzić się w codzienności zarządczej, albo zostać odrzucone i zastąpione Jakimś Nowym-Lepszym. Mam wrażenie, że żaden z tych scenariuszy nie wystąpił. A jaki nastąpił? No właśnie…

Modelowanie procesów w dalszym ciągu jest realizowane. Bardzo często jako etap prowadzonych przedsięwzięć informatycznych. To dobrze, ale i źle, gdyż stworzone Modele Realizacji Prac (zwane, modelami procesowymi), służą wyspecyfikowaniu wymagań, po czym są odkładane Na Półkę, jako jeden z artefaktów Procesu Wytwórczego Oprogramowania. Modele (zwane, modelami procesowymi) są także tworzone w ramach inicjatyw usprawniania działań organizacji, dostarczając najczęściej efemeryczną wartość zespołom, które zmienią zasady pracy i…odłożą modele Na Półkę.

Ze świecą szukać organizacji, w których wszystkie wymienione działania stanowią element planowanego podejścia do zarządzania organizacją w sposób procesowy. Z przykrością stwierdzam, na bazie dotychczasowych spostrzeżeń, iż idea BPM w Polsce jest wiecznie żywa, ale wiecznie nierealizowana. Co gorsza, często ograniczona do wdrożenia narzędzi klasy BPMS, jest krytykowana za swoją złożoność i pracochłonność. Dlaczego, co gorsza? Powód jest trywialny – na pytanie, jaka jest stosowana metodyka zarządzania procesami biznesowymi, najczęściej pada odpowiedź „jaka metodyka?”. A jeśli już pada coś bardziej konkretnego, to jest to „własna metodyka” (czytaj:…no właśnie…). Na pytanie „czy oparta, na jakiejś dobrze znanej”, odpowiedź najczęściej nie jest udzielana.

Zastanawiające jest to, jak mało chcemy wkładać pracy w nauczenie się i wdrożenie jakiegoś spójnego mechanizmu zarządczego. jak bardzo chcemy szybko osiągnąć spektakularny sukces. Jak szybko negatywnie oceniamy rzeczy, których dobrze nie poznaliśmy. I jak łatwo podejmujemy decyzję o zarzuceniu Tego Co Zaczęte I Nie Ukończone i rozpoczęciu Tego Co Obiecujące.

Proces bizesowy – subiektywny, czy obiektywny?

LupaDość nieoczekiwanie, wpis o regułach biznesowych wzbudził dyskusję, prowadzoną (niestety) drogą mejlową, o procesach biznesowych, a w zasadzie ich obiektywno-subiektywnym aspekcie. Po uzgodnieniu z Panami Andrzejem oraz Zygmuntem, iż warto byłoby opublikować przemyślenia, przedstawiam ich fabularną wersję.

A: „Pisze Pan o procesach biznesowych oraz ich związku z regułami biznesowymi. O ile reguły istnieją zawsze w organizacji, o tyle procesy nie. A w zasadzie istnieją zawsze, tylko nie zawsze są opisane. Załączam w cc kolegę Z, pracującego po sąsiedzku w banku, z którym regularnie toczymy spory o to, w jaki sposób odtwarzać procesy nie na potrzeby IT, lecz biznesu jako takiego”

Z: „Dziękuję za włączenie mnie do dyskusji. Od razu doprecyzuję – moim zdaniem nieistotne jest ich opisanie, ważne, aby ludzie mieli świadomość, iż oprócz działu pracują też na rzecz procesów, w których w naturalny sposób uczestniczą.”

JA: „Dlaczego sądzicie Panowie, że procesy – w sensie BPM – istnieją zawsze?”

Z: „To oczywiste. Gdyby procesy nie istniały, nie można byłoby zaobserwować realizowanych przez pracowników działań. Skoro działania są, to są realizowane w ramach procesów. Tym bardziej, że są powtarzalne, co – jeśli się nie mylę – stanowi fundament zarządzania procesami”.

A: „No właśnie”

JA: „A skąd wiadomo w obszarze jakiego procesu działania są prowadzone ? Załóżmy, że pracownik działu reklamacji, będący w dobrych relacjach z niegdysiejszym, niezadowolonym klientem,  odbierze odeń telefon z informacją, iż otrzymał drogą mejlową propozycję poszerzenia wykupionej usługi i prosi, aby któryś z handlowców przesłał do asystentki prezesa dedykowaną ofertę, uwzględniającą przysługujące upusty. Czy z tego opisu należy wnioskować, że proces reklamacji inicjuje proces sprzedażowy ? A może uznać, iż dział reklamacji uczestniczy aktywnie w realizacji procesów sprzedażowych? A może jeszcze coś innego?”.

Z: „Ciekawe. A troszkę odwracając pytanie – czy to ważne?”

JA: „Załóżmy, że jednym z result indicators (RI) dla procesu sprzedażowego jest liczba interakcji klient-firma, prowadząca do nowej sprzedaży. Liczba ta jest istotna, gdyż firma postawiła sobie za cel takie opracowanie materiałów reklamowych i promocyjnych, by kontaktujący się klient nie potrzebował żadnych dodatkowych wyjaśnień i był już wstępnie zdecydowany na konkretny produkt. Dzięki temu, firma ma nadzieję, na zmniejszenie kosztów obsługi przedsprzedażowej, która przy tak dużym wolumenie klientów jest zauważalna. Dla tak określonego result indicator naturalnym jest stworzenie performance indicator (PI), na bieżąco monitorującego liczbę interakcji w każdej instancji danego procesu biznesowego.

Wydaje się, iż przy tak postawionym problemie, istotne jest, by jawnie przypisać działanie do określonego procesu biznesowego. W przeciwnym bowiem razie, uznaniowość kojarzenia określonych działań z procesem możne zniekształcić pomiary zarówno dla PI jak i dla RI..

Z: „Hmm, rzeczywiście ma to jakiś sens.  Skąd w takim razie wiadomo, gdzie zaczynają się i kończą poszczególne procesy?”

JA: „Nie wiadomo, dopóki tego nie ustalimy. Co więcej, nie wiadomo, czy są jakiekolwiek procesy; jeśli bowiem nikt do tej pory nie wprowadzał zarządzania procesowego, to oznacza to, iż prowadzone w organizacji działania nie są ujęte w te ramy”.

A: „W takim razie, w co są ujęte?”

JA: „Trudno powiedzieć. Mogą być ujęte w nawiasy procedur operacyjnych, być może uwzględnione w ramach „procesów” stworzonych na potrzeby wdrożeń IT, a być może są efektem podjętych przez pracownika decyzji, nieujętych w nic, poza jego kompetencje. Żadna z tych sytuacji nie odzwierciedla jednakże pojęcia proces w takim rozumieniu, jakie wynika z zaleceń BPM”.

A: „A jakie są te zalecenia BPM?”

JA: „W kontekście tematu, który poruszamy, można uznać, iż procesy muszą stanowić spójny system działań wewnątrz organizacji, odzwierciedlający aktualny bądź planowany stan, opracowywany z myślą o dostarczeniu wartości klientowi w zgodzie z przyjętymi założeniami biznesowymi. Innymi słowy, musimy jakoś podzielić system pracy organizacji na mniejsze części i na ich bazie stworzyć system.”

A: „W jaki sposób wyodrębnić te części z całości?”

JA: „Z wykorzystaniem metodyki albo stosując gotowe podziały opisane w procesowych modelach referencyjnych dla danej branży”.

A: „Moje doświadczenie podpowiada mi, że takiej metodyki nie ma.”

Z: „Wręcz przeciwnie, co firma doradcza, to metodyka!  Zawsze „wewnętrzna”, której szczegółów zdradzać nie można. To już przerabialiśmy nie raz w banku. I rzeczywiście muszę przyznać, że co firma, to inny obraz procesów otrzymywaliśmy, pomimo tego, że w niektórych obszarach nic się nie zmieniało przez lata. Uświadomiłem sobie jednakże teraz, iż problemem nie było to, że firmy nie chciały nam opracować tego Jedynego, Słusznego modelu procesów. Problemem było raczej zrozumienie zasad podziału, które w każdym z przypadków, które pamiętam były niejasne i z pewnością nie były konsekwentnie stosowane”.

Z: „A są jakieś metody jednolitego podziału firmy na procesy?”.

JA: „Znam jedną – metodykę Riva. Być może są inne – aczkolwiek nigdy na takową nie trafiłem. Warto z niej skorzystać oraz dodatkowo osadzić w szerszym obrazie procesowym, proponowanym przez Geary’ego Rummlera oraz kontynuatorów jego prac”.

Z:Teraz rozumiem to Pana stwierdzenie o subiektywności procesów. A. – zgadzasz się z takim podejściem?”

A: „Szczerze powiem, że nie do końca sobie to poukładałem. Jeśli mogę, to chętnie skorzystałbym z możliwości rozmowy za tydzień, dwa, aby omówić ewentualne wątpliwości.”

JA: „Bardzo chętnie”.

Koniec. Na dzisiaj.

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.