Zastanów się, co zrobisz (Decydowanie)

Uwaga. Wiele terminów występujących w  tekście zostało użytych w ramach przyjętej przez autora konwencji terminologicznej. W celu ich wyróżnienia, zostały one zapisane jako nazwy własne. 

"[...] Niemal aż do naszych czasów nauka zajmowała się wyłącznie problemami poznawczymi, i to tak dalece, że poznawanie uważano za istotę nauki, zupełnie nie dostrzegając problemów decyzyjnych. Decydowanie nie było problematyką lecz uprawnieniem. Monarcha kazał zbudować pałac, gdy mu się tak spodobało. Innemu na jego miejscu mogłoby się spodobać inaczej, na przykład kazać zbudować cyrk. Zrozumienie błędności takiego postępowania toruje sobie drogę z największym trudem — i dziś jeszcze ogromna większość decydentów pojmuje decydowanie arbitralnie, jako przywilej i nagrodę za zasługi, a nie jako jeden z rodzajów pracy polegający na rozwiązywaniu problemów decyzyjnych (z podaniem dowodu trafności), nie gorszy, ale i nie lepszy od innych rodzajów pracy, a na pewno wymagający odpowiednich kwalifikacji [...]"

- Marian Mazur ,"Cybernetyka i charakter"

Tym postem zakończymy rozważania nad "racjonalnym empiryzmem" zawoalowanym w koncepcie wzorca procesowego TREP.

Omówiliśmy już Obserwowanie i Motywowanie. Przyszła pora na - last, but not least - Decydowanie.

Zerknijmy na poniższy diagram, który ilustruje istotę oraz miejsce Decydowania w procesie opartym o wzorzec TREP.

Proces TREP 

(Copyright 2020-2021Marek Bisztyga )

Celem Decydowania jest zredagowanie i przekazanie do wiadomości Wykonawcy, a przy okazji pozostałym uczestnikom procesu, dyrektywy wykonania określonego Działania opisanego w treści Decyzji, które to Działanie w zamyśle Decydenta ma doprowadzić do wytworzenia pewnego stanu Systemu (i/lub jego Otoczenia), który to stan  będzie  stanowić Rozwiązanie zidentyfikowanego uprzednio (na etapie Motywowania)  Problemu. 

Z powyższego (patrz rysunek) wynika, że Rozwiązanie Problemu zależy od:

• właściwego rozpoznania symptomów problematycznej Sytuacji (Architektury Sytuacji) z 
• poprawnego postawienia Problemu i zakresu wiedzy o Problemie (Architektura Problemu), jego dziedzinie (Metamodel) oraz wiedzy ogólnej (Racjonalność), w kontekście której rozpatrywane jest dane zjawisko,
• wnikliwości procesów Obserwowania, Motywowania i Decydowania,

a także od 

• przygotowania odpowiednich warunków początkowych dla podjęcia Działania.

Przedstawmy Decydowanie jako podproces TREP skonstruowany (jakżeby inaczej) według wzorca TREP. 

Decydowanie jako podproces TREP
(Copyright 2020-2021Marek Bisztyga )

Przykładowy przebieg procesu decyzyjnego może wyglądać następująco:

(Copyright 2020-2021Marek Bisztyga )

Przyrównując architekturę procesu Decydowania do wzorca TREP, należy wziąć pod uwagę ważną i oczywistą okoliczność: Decydowanie dotyczy przyszłości. Wszystkie produkty  podprocesu Decydowania należy traktować jako antycypację pewnego stanu przyszłego. Można zatem uznać, że:

• weryfikowanie spójności i kompletności Decyzji to odpowiednik Decydowania (sic! decydowanie o decydowaniu), czyli oceny, czy konstrukcja Decyzji jest:
• zgodna ze sztuką i stanem wiedzy,
• kompletna,
• jednoznaczna,
• spójna wewnętrznie,
• czytelna
• możliwa do wykonania,

a jeśli nie, sterowanie należy przekazać do czynności, której zadaniem będzie usunięcie zaobserwowanuch wad,

• definiowanie celu Decyzji to odpowiednik Motywowania (do czego dążymy, co chcemy osiągnąć poprzez wykonanie Decyzji),
• definiowanie przedmiotu Decyzji to odpowiednik Przygotowania (co będzie przedmiotem przyszłego Działania, co będzie przedmiotem Zmiany, jakie warunki początkowe powinny zostać spełnione),
• definiowanie metody wykonania Decyzji to odpowiednik przyszłego Działania (jak ma przebiegać przyszłe Działanie), 
• walidowanie adekwatności Decyzji to odpowiednik Obserwowania (antycypacja potencjalnych skutków wykonania danej Decyzji i ocena, na ile są pożądane z punktu widzenia przyjętego Celu  Egzystencjalnego i/lub Strategicznego). 

Jedynie określenie (konstatacja) kwestii, w której ma być podjęta Decyzja - co nie jest tożsame z określeniem przedmiotu Decyzji, a co można uznać za odpowiednik wyznaczenia Celu Egzystencjalnego i/lub Strategicznego, jakim jest konieczność rozstrzygnięcia pewnego dylematu poprzez opracowanie i podjęcie Decyzji  -  wynika z już istniejącego i zaobserwowanego stanu wybranego fragmentu rzeczywistości.

Potocznie Decyzję postrzega się jako wyraz woli lub intencji osiągnięcia określonego celu, rezultatu, wytworzenia efektu, produktu - słowem, wykreowanego jakiegoś konkretnego i pożądanego stanu przyszłego. Nie można bowiem decydować o stanach przeszłych (a nawet teraźniejszych, gdyż teraźniejszość to nic innego jak przeszłość, która właśnie w tym momencie nastała), choć nie wszyscy podzielają ten pogląd i niekiedy próbują "postulować" przeszłość. 

Decyzję w TREP również podejmuje się z zamiarem osiągnięcia skutku, ale przy założeniu, że wiąże się to z koniecznością uruchomienia określonego Działania, które w zamyśle Decydenta ma doprowadzić do owego pożądanego stanu.

Jeśli Decyzja nie wskazuje przyszłego celowego Działania, lecz jest jedynie  konstatacją chęci/woli/intencji bez uwzględniania możliwości i sposobu  osiągnięcia celu (skutku), nie jest Decyzją. Jest tylko deklaracją intencji, wyrazem woli i niczym więcej. Słowem "chciejstwem".

Na przykład, nie można zdecydować, że będę "piękny i bogaty". Można jedynie wyrazić pragnienie, że "chciałbym", albo że "byłoby dobrze być". Można natomiast zdecydować o podjęciu określonych kroków w kierunku zmiany stanu urody i majątku.

Możemy zatem uznać, że Decyzja to specyfikacja przyszłego Działania, a Decydowanie to proces ustalania jego parametrów, czyli nic innego jak projektowanie. Jeśli tak, ma ono ścisły związek z analizą (poznawaniem).

"[...] Pomimo że problemy poznawcze i decyzyjne tak wyraźnie różnią się od siebie, są one od siebie nieodłączne. Aby coś poznać, trzeba w tym celu coś zrobić, a więc decydować. I na odwrót, aby coś osiągnąć, trzeba do tego coś wiedzieć, a więc poznać. Decydowanie pomaga poznawać, a poznawanie pomaga decydować [...]"

- Marian Mazur "Cybernetyka i charakter"

 

Jak wynika z powyższego, dla podjęcia Decyzji potrzebna jest:

• informacja "co wiemy"  - poznane fakty o obserwowanym zjawisku, które stanowią komponent empiryczny,
• wiedza "co rozumiemy" - interpretacja faktów w oparciu o  Metamodel i Racjonalność, które łącznie nazwiemy komponentem racjonalnym,

oraz

• motyw "co, po co, dlaczego i jak zrobimy" - synteza, czy i jak zamierzamy zmienić zaobserwowaną Sytuację.

Informacji i wiedzy dostarcza Obserwowanie.  Motywowanie zaś - definiując konkretny Problem - wskazuje potencjalny kierunek Zmiany, co do sposobu przeprowadzenia której ma zapaść Decyzja. Zatem

jeśli nie zdefiniowano Problemu, nikt nie oczekuje jego Rozwiązania, ergo nie jest potrzebna żadna Decyzja, gdyż nie ma konieczności dokonania wyboru sposobu przeprowadzenia Zmiany i podjęcia Działania, co do którego należy ową Decyzję podjąć.

zatem:

• jeśli nie ma problemu, nie są potrzebne decyzje,
• jeśli nie są potrzebne decyzje, nie są potrzebni decydenci.

Czy teraz rozumiecie skąd się biorą wydumane problemy? Decydent (manager) też człowiek. Z czegoś żyć musi. Jak nie ma problemów, by je dzielnie rozwiązywać wykazując tym samym swoją przydatność, trzeba je stworzyć. Wielu managerów robi to wręcz podświadomie.

Decyzje podejmuje się:

• wobec określonego Problemu lub Sytuacji,
• w konkretnych okolicznościach miejsca i czasu,
• z uwzględnieniem dostępnych środków i możliwych sposobów działania,
• przy wykorzystaniu
• posiadanej informacji o tymże Problemie lub  Sytuacji,

oraz

• wiedzy dziedzinowej w formie Metamodelu i ogólnej w postaci Racjonalności. 

Skoro Decyzja stanowi wyraz woli podjęcia Działania, powinna przyjąć formę dyrektywy, która jednoznacznie instruuje potencjalnego jej Wykonawcę:

1. jaki jest cel Działania będącego przedmiotem Decyzji, jaki stan ma zaistnieć w wyniku implementacji Decyzji (na co zmienić to, co ma podlegać oddziaływaniu),
2. co będzie przedmiotem oddziaływania (przetwarzania) i/lub jakie są konieczne warunki początkowe, aby Decyzję można było wykonać,
3. w jaki sposób wykonać Decyzję.

Decyzja podjęta w oparciu o odpowiedzi na powyższe trzy pytania - co, na co i jak zmieniać - stanowi rozstrzygnięcie tak zwanych dylematów decyzyjnych, o czym wspominałem w postach z lat ubiegłych.

Decyzja niezawierająca rozstrzygnięć wymienionych 3. dylematów jest ułomna i z zasady nie powinna być wykonywana. W przypadku braku choćby jednego z komponentów, należy podjąć najpierw Decyzję "pomocniczą" o rozstrzygnięciu nierozstrzygniętego dotąd dylematu decyzyjnego i uzupełnieniu Decyzji podstawowej (pierwotnej). Należy podjąć Decyzję o podjęciu poprawnej Decyzji (sic!). Choć wydaję się to oczywiste, wielu Decydentów nie korzysta z tej możliwości i kieruje do egzekucji Decyzje niekompletne, nieświadomie cedując na Wykonawców trud opracowania brakujących rozstrzygnięć, co ci skwapliwie czynią chcąc wykazać się posłuszeństwem i skutecznością, choć nie zawsze zgodnie z intencją Decydenta, przejmując tym samym odpowiedzialność za skutki Decyzji. Wtedy jakże często ojcem sukcesu jest Decydent, a porażki Wykonawca.

Dlatego przed przekazaniem Wykonawcy (lub przed odbiorem od Decydenta), Decyzję należy poddać Weryfikacji, czyli badaniu, czy zawiera wymagane elementy - odpowiedzi na pytania co, na co i jak zmieniać - oraz czy te elementy są ze sobą spójne logicznie: przedmiot zmiany jest dostępny, warunki wstępne są możliwe do spełnienia, metoda jest możliwa do przeprowadzenie w danych warunkach, a rezultat jest osiągalny przy jej (metody) prawidłowym przeprowadzeniu. Tylko Decyzje pozytywnie zweryfikowane powinny być realizowane. To pozwala unikać arbitralności w jej wykonaniu. Wykonawca wtedy ma ograniczony wpływ na wypaczenie intencji Decydenta. Z drugiej strony, odpowiedzialny Wykonawca nie powinien wykonywać Decyzji nie zweryfikowanej, gdyż rodzi to ryzyko, że jest ona niekompletna i/lub niespójna, a zatem błędna.

Każda Decyzja podlega również Walidacji. Należy bowiem potwierdzić, że Decyzja jest podejmowana we właściwej kwestii, a jej spodziewany efekt jest zgodny ( a przynajmniej nie sprzeczny) z ogólną strategią i misją Organizacji  oraz pryncypiami ewolucji Architektury Organizacji i/lub Systemu. Ma to uchronić Decydenta przed wywoływaniem niepożądanych bądź nieprzewidzianych skutków, jako że każda wykonana Decyzja nie pozostaje bez konsekwencji - powoduje i utrwala Zmiany Organizacji i/lub Systemu, ale również ich otoczenia.

Praktykujący Scrum, jak również inne metodyki nurtu agile, z pewnością zauważą, że definicja celu Decyzji jest niczym innym jak definicją tzw. Criteria of Acceptance (CoA) - wymagania pożądanego, a tym samym akceptowanego stanu przyszłego (to-be), a Walidacja kontrolą i potwierdzeniem prawidłowości ich sformułowania.

Znowu nawiązując do Agile, łatwo zauważyć, że Weryfikacja dotyczy kontroli spełnienia tzw. Definition of Ready (DoR) - zbioru reguł i standardów, które określają, jakie cechy powinien posiadać Product Backlog Item (PBI), aby mógł być skierowany do realizacji. W przypadku zastosowania wzorca TREP są to odpowiedzi na owe sakramentalne 3 pytania: co, na co i jak zmieniać.

W TREPie Decyzja wyłania się stopniowo. Proces Decydowania jest procesem iteracyjnym. Może obejmować wiele różnych pętli i powtórzeń. Trwa dotąd, aż Decyzja osiągnie właściwą postać oraz zostanie pozytywnie zwalidowana (czy jest poprawna?) i zweryfikowana (czy jest poprawnie podjęta?). Czyżby znowu agile?

Łatwo zauważyć, że o ile Motywowanie to analiza i definiowanie Problemu, to Decydowanie - jako antycypacja pożądanego stanu przyszłego - stanowi projektowanie Rozwiązania tegoż Problemu.

Zazwyczaj projektowanie kojarzone jest li tylko z czynnością (niekiedy bardzo złożoną) opracowywania szczegółowej wizji przyszłego stanu rzeczywistości - obiektu, systemu, sytuacji - produktem czego  jest artefakt o nazwie "projekt" zawierający opis i/lub model owego przyszłego stanu. Rzadko utożsamiamy projektowanie z podejmowaniem Decyzji i dlatego często popełniany jest błąd polegający na ignorowaniu w trakcie procesu projektowania integralnych elementów Decyzji: warunków i ograniczeń początkowych oraz metody realizacji przedmiotu projektu. Wiadomo "co", ale nie wiadomo "z czego" i "jak". Często bywa jednak tak, że to, co jest możliwe wynika z "z czego" i z "jak".

Znany mi jest przypadek amerykańskiego producenta zaawansowanej aparatury pomiarowej (nie zostałem upoważniony by zdradzić jego nazwę), który podjął decyzję inwestycyjną o budowie nowej fabryki spektroskopów. Inwestor najpierw dokonał wyboru lokalizacji. Wybrał miasto "gdzieś na głębokiej prowincji", gdyż władze stanowe, w ramach promocji regionu, oferowały wysokie wsparcie finansowe dla nowej inwestycji. Następnie przeprowadził analizę dostępnej w okolicy siły roboczej i koniecznych dla jej wyszkolenia nakładów. Na podstawie pozyskanej informacji opracował biznesplan i wystąpił do banku o finansowanie. Dopiero po "dopięciu" finansowania, zaprojektował urządzenie i technologię jego produkcji, traktując projektowanie jako regularny krok decyzyjny w procesie realizacji przedsięwzięcia. Szczegółowa decyzja, co i jak konkretnie robić zapadła z uwzględnieniem istotnych ograniczeń - dostępnego budżetu oraz poziomu kompetencji technicznych możliwej do pozyskania kadry inżynierskiej i produkcyjnej. Pozornie wydawałoby się, że ów inwestor działał "od końca". Nie prawda. Gdyby najpierw skupił się na samym spektroskopie, mogłoby się okazać, że lokalne uwarunkowania nie pozwoliłyby na realizację inwestycji z powodu braku "z czego" i "jak". Choć wydaje się to oczywiste "na chłopski rozum", takie podejście przeczy  kultowi "fokusowania się na celu", idei jakże często promowanej przez różnej maści "kołczów" i na kursach typu "jak zostać milionerem w weekend".

Na celu, owszem, należy się koncentrować, ale na etapie działania. Najpierw należy skupić się na procesie jego definiowania i decyzji co do jego wyboru, albowiem co nam z tego, że dziarsko osiągniemy cel, którego nie powinniśmy lub nie musimy osiągać?

Jeśli uznać, że miarą sukcesu jest skuteczność rozumiana jako umiejętność osiągania postawionych celów, to tajemnicą sukcesu jest umiejętność podejmowania trafnych Decyzji. Również tych o nieosiąganiu niczego.

Wasz,

M.

Mamy problem (Motywowanie)

Uwaga. Wiele terminów występujących w  tekście zostało użytych w ramach przyjętej przez autora konwencji terminologicznej. W celu ich wyróżnienia, zostały one zapisane jako nazwy własne. 

Kontynuujmy temat podjęty w poprzednim odcinku poświęconym Obserwowaniu. Dla przypomnienia, staramy się wyjaśnić "racjonalność empiryzmu" wzorca procesowego TREP zaproponowanego w postcie  "Zastanów się, co robisz!" jako alternatywę dla  scrumowej "teorii empiryzmu".

Wiemy już, że celem Obserwowania (patrz poprzednie posty) jest pozyskanie Informacji o obserwowanym Zjawisku oraz wiedzy o jego dziedzinie (kontekście) poprzez budowę - lub udoskonalenie, gdy już istnieje - Metamodelu, a także wiedzy ogólnej zwanej tu Racjonalnością.  W tym właśnie przejawia się rzeczony "racjonalizm empiryczności" podejścia reprezentowanego przez TREP.   

Przejdźmy zatem do kolejnej aktywności będącej elementem tzw "pętli decyzyjnej" TREP, czyli do Motywowania.

Proces TREP
(Copyright 2020-2021 Marek Bisztyga)

W potocznym rozumieniu tego słowa, motywowanie polega na wzbudzaniu chęci i zaangażowania podmiotu do podjęcia działania oraz ukierunkowaniu jego zachowania na osiągnięcie określonych efektów, pożądanych z punktu widzenia motywującego, choć niekoniecznie motywowanego.

Czym Motywowanie w TREP wyróżnia się na tle innych form "zachęcania", to kreowanie poczucia potrzeby celowości w działaniu, a dokładnie:

• poczucia niedogodności, braku komfortu, braku korzyści, straty wynikającej z zaniechania zmiany i/lub korzyści (nagrody) z niej płynących,
• potrzeby lub konieczności  zmiany istniejącego stanu rzeczy,
• celowości w działaniu, lub inaczej,  dążenia do konkretnego celu lub do uzyskania konkretnego efektu lub  rezultatu, do wytworzenia pożądanego stanu przyszłego, do obrania kierunku rozwoju lub do wyboru sposobu Działania.

Motywowanie, wraz z Decydowaniem, jest etapem pośrednim  pozwalającym przejść od pasywnego Obserwowania do aktywnego Działania nadając mu atrybut celowości. Jest przygotowaniem do Decydowania, a nawet jego "drugą stroną medalu". Bez świadomości potrzeby i celu Działania wszelkie Decydowanie  jest bezprzedmiotowe, gdyż nie ma o czym decydować. Decydujemy bowiem nie tyle (tylko) o tym, czy działać czy nie, ale o tym, że jeśli działać, to po co, a jeśli nie działać, to dlaczego. Decyzja "robić coś, choćby cokolwiek" jest bez sensu. Gdy nie wiemy co, po co i dlaczego lepiej już nic nie robić.

Podsumowując powyższe można stwierdzić, że Motywowanie to optymalizacja ewentualnej przyszłej Decyzji odnośnie kierunku i sposobu Działania. 

Warto jednak wydzielić Motywowanie w formie odrębnej aktywności TREP, gdyż, jak się okazuje,  jest ono Działaniem nieoczywistym i złożonym.

Zgodnie z naszą nowo utartą tradycją przedstawmy Motywowanie jako podproces w konwencji wzorca TREP.

Motywowanie TREP.

(Copyright 2020-2021 Marek Bisztyga)

Podstawowym zadaniem Motywowania w TREP jest opracowanie i dostarczenie potencjalnego Celu Operacyjnego dla kolejnego aktu Decydowania.

W ramach tego realizowane są następujące czynności (aktywności):

• definiowanie propozycji wytworzenia pożądanego stanu przyszłego, obrania kierunku rozwoju lub  wyboru sposobu działania - słowem rozwiązania jakiegoś problemu (patrz niżej),
• badanie komplementarności (braku sprzeczności) wybranego  celu z celem nadrzędnym (Celem Egzystencjalnym, Strategicznym, misją, wizją rozwoju, kierunkiem ewolucji, marzeniem itp.) oraz innymi celami operacyjnymi, dotyczącymi tego samego zjawiska lub obiektu, w celu stwierdzenia, czy osiąganie danego celu jest racjonalne i korzystne,
• określenie sposobu pomiaru stopnia realizacji celu - po czym poznamy, że zbliżamy się do osiągnięcia celu lub już go osiągnęliśmy, by niepotrzebnie nie kontynuować działania tracąc czas i energię, a może nawet szkodząc zamiarowi,
• określenie warunków początkowych, przy jakich dany cel operacyjny można (lub warto)  przyjąć do realizacji, aby wesprzeć realizację celu wyższego poziomu i zachować komplementarność z innymi celami,

oraz  na wstępie i/lub na końcu każdej iteracji

• weryfikowanie kompletności tak sformułowanego celu oraz jego zgodności z przyjętą w procesie koncepcją "jakości celu", na przykład  z modelem S.M.A.R.T.

Nic bardziej nie motywuje do działania jak świadomość potrzeby i możliwości jej zaspokojenia. W postcie Panta Rhei padła propozycja, aby w przypadku zastosowań IT Motywowanie interpretować jako proces identyfikacji Problemu. Wydaje się, że taką  interpretację można rozciągnąć na ogół przypadków. 

Wszelkie celowe działanie  powinno wynikać z konieczności rozwiązania jakiegoś Problemu.

Nawet gdyby wszystkie Problemy zostały rozwiązane, a tym samym potrzeby  zaspokojone, i jedynie trzeba by podtrzymywać ów "błogostan", wtedy samo jego podtrzymanie staje się Problemem, który  trzeba co jakiś czas  rozwiązywać, albowiem nic nie trwa wiecznie. Panta rhei.

 

W organizacjach, gdzie funkcjonują  systemy wynagradzania oparte o pomiar "pracowitości" często kreuje się Problemy "na siłę", by potem dzielnie je rozwiązywać. Jest to jedna z metod "oszukiwania systemu". Lubują się w niej ambitni (czytaj: cwani) menedżerowie, którzy za wszelka cenę chcą udowodnić, że bez nich "interes się nie kręci" i są niezastąpieni. Tej sytuacji po części winni są ich szefowie, którzy stwierdziwszy, że zespół lub dział osiągnął zdolność pełnej samokontroli, postanawiają "zaoszczędzić" i zwalniają tych, którym ten stan zawdzięczają. Ale nic nie trwa wiecznie. Od czasu do czasu proces trzeba zmodernizować, rozbudować, dostosować do zmian w otoczeniu. Panta rhei. Znowu przyjdzie zatrudnić jakiegoś speca od procesów (AAAAAAby zatrudnić fachowca ... umieść, proszę, ofertę w komentarzu. Oczekuję tylko poważnych propozycji 😉). 

A co by było, gdyby płaca zasadnicza była proporcjonalna do ilości pracy, a premia do jakości - im mniej rozwiązywania Problemów, tym wyższa. Ale jak tu płacić za  "nicnierobienie"?

Nie ma obawy. Zawsze coś będzie do naprawy albo poprawy. Teoria ograniczeń niezawodnie zamanifestuje się kolejny raz i dlatego zawsze będą jakieś "problemy". Natura o to zadbała. Poza tym, z czegoś i za coś trzeba przecież żyć 😉. 

Zatem  najlepszym sposobem motywowania do działania jest uwypuklenie "sprawy do załatwienia", a potrzeba lub konieczność jej załatwienia stanowi właśnie Problem do Rozwiązania.

Problem jednak w tym, że Problemy nie tak łatwo dostrzec.

Czym w ogóle jest Problem? Pozornie wydaje  się to oczywiste, ale jak zajrzymy do słownika, a szczególnie do słownika synonimów, sprawa zaczyna się komplikować. Jest to pojęcie tak obszerne i niejednoznaczne, że warto je doprecyzować na potrzeby naszego dalszego wywodu.

Koncepcja Problemu

Załóżmy, że rozpatrujemy jakiś System - techniczny, organizacyjny, konceptualny - nie ważne jaka jest jego natura. Problem jest to nabyty lub immanentny stan Architektury Systemu, który powoduje manifestację jednego lub wielu tzw. Efektów Niepożądanych (Undesired Effect – UDE).

Efekt Niepożądany jest przejawem lub skutkiem zachowania się (działania)  jednego lub  interakcji kilku elementów Systemu, który to Efekt pojawia się wbrew intencjom dysponentów (interesariuszy) Systemu, jest niekorzystny (obiektywnie lub subiektywnie) i dlatego jest uznany za niepożądany.

Efekty Niepożądane występują z powodu istnienia wielu czynników i okoliczności, w tym z powodu Głównej Przyczyny implikującej  pozostałe.

Rozwiązanie Problemu to taka Zmiana Architektury Systemu, wprowadzenie której powoduje usunięcie Głównej Przyczyny  Problemu i tym samym Niepożądanych Efektów  konstytuujących dany Problem. Rozwiązanie danego Problemu może jednak generować nowy, tzw. Wtórny Problem, inny od tego pierwotnego.

Wartym podkreślenia  jest fakt, iż Efekty Niepożądane, ich Główna Przyczyna i Rozwiązanie Problemu mogą należeć do różnych warstw Architektury Systemu. Na przykład Niepożądane Efekty mogą manifestować się w obszarze procesów biznesowych, ich Główna Przyczyna może leżeć w warstwie aplikacyjnej IT,  a rozwiązaniem  może być zmiana w obszarze infrastruktury technicznej i systemowej IT lub wręcz poza Systemem, w jego otoczeniu. Możliwa jest każda kombinacja alokacji Efektów, Przyczyn i Rozwiązań pomiędzy warstwami Architektury Systemu .

Swoistym Efektem Niepożądanym może być również brak występowania Efektu Pożądanego (Desired Effect  - DE). Można zatem uznać, że dążenie do  osiągnięcia nowego, dotąd nie występującego Efektu Pożądanego jest również dążeniem do  Rozwiązania Problemu polegającego na wywołaniu Efektu Pożądanego.

Problem może powstać:

• w wyniku przypadkowych lub intencjonalnych oddziaływań zewnętrznych;
• w wyniku namysłu interesariuszy Systemu, w rezultacie którego powstała uświadomiona potrzeba zmiany w Systemie.

lub

• z powodu kombinacji powyższych czynników.

Problem vs Kłopot vs Zagadnienie.

W tym miejscu należy wyjaśnić pewną kwestię terminologiczną. W języku potocznym oprócz terminu “Problem” występują 2 inne  - “Kłopot”  i “Zagadnienie” - które często  błędnie używane są zamiennie ze słowem “Problem”, wprowadzając przy tym wiele zamieszania i niejednoznaczności. Wprowadźmy zatem precyzyjne ich rozróżnienie:

• “Problem” to niepożądany stan wywołany zachowaniem Systemu, który, poprzez wprowadzenie określonej zmiany, można zmienić w stan pożądany. Z pojęciem “Problem” nieodłącznie jest związane pojęcie “Rozwiązanie”, czyli zmiana, której wprowadzenie likwiduje  “Problem” poprzez zmianę stanu niepożądanego w stan pożądany lub akceptowany.

• “Kłopot” to negatywna klasyfikacja lub postrzeganie określonego nieodwracalnego stanu lub  nieuniknionego zjawiska.  “Kłopotu” nie można rozwiązać, czyli usunąć, bo gdyby było to możliwe,  znaczyłoby to, że mamy do czynienia z “Problemem”. “Kłopot” można obejść, uniknąć lub pogodzić się z nim dostosowując się do jego permanentnej obecności. 

• "Zagadnienie" to kwestia, którą należy rozstrzygnąć podejmując decyzję lub dokonując wyboru określonej opcji.

• Unikanie, obchodzenie lub adaptacja do  “Kłopotów” może spowodować “Problemy”.

• Rozwiązywanie “Problemów”, czyli dokonanie zmiany, może napotkać lub spowodować  “Kłopoty”.

• Rozwiązywanie “Problemów” i radzenie sobie z “Kłopotami” może wymagać rozpatrzenia “Zagadnienia” i znalezienie wyjścia z sytuacji  wymagającej  dokonania wyboru. 

Zatem zadanie poradzenia sobie z “Kłopotem” można sprowadzić do zadania rozwiązania “Problemu”. Najpierw należy opracować obejście, uniknięcie lub sposób  adaptacji do “Kłopotu”, a potem rozwiązać “Problemy” związane z ich implementacją.

Przykładem “Kłopotu” jest grawitacja. Nie można jej zlikwidować, ale można jej uniknąć udając się w kosmos. By tam się dostać, koniecznym jest rozwiązanie szeregu Problemów technicznych i  organizacyjnych.  Należy przy tym rozstrzygnąć “Zagadnienie” pozyskania środków i na ten cel.

Powracając do głównego tematu, produktem Motywowania jest definicja Problemu, a jego Rozwiązanie jest celem Działania, co do którego powinna zapaść jakaś Decyzja.

Wtedy Motywowanie można przedstawić następująco:

Motywowanie poprzez definicję Problemu

(Copyright 2020-2021 Marek Bisztyga)

Spójrzmy na Motywowanie  "Inteligentnym Szkiełkiem i  Okiem" analityka biznesowo-systemowego.

• Centralnym Zagadnienie Motywowania jest opracowanie Architektury Problemu - modelu zjawiska powodującego manifestację Niepożądanych Efektów w Systemie i/lub jego otoczeniu.
• W ramach analizy Architektury Problemu następuje identyfikacja Głównej Przyczyny (tzw. root-cause) - tego fragmentu Architektury Systemu, zmiana którego prawdopodobnie spowoduje Rozwiązanie Problemu. Opracowanie Rozwiązania nie jest jednak przedmiotem Motywowania. W TREP, a raczej jego implementacji Panta Rhei, to zadanie Przygotowania (definiowania Rozwiązania w Panta Rhei) i/lub Oddziaływania (implementowania Rozwiązania w Panta Rhei).
• Architektura Problemu powinna być komplementarna z Architekturą Systemu. Nie jest bowiem możliwe, aby Problem był definiowany poza kontekstem Systemu, którego dotyczy -  przy użyciu elementów strukturalnych  i zachowań wykraczających poza obszar danego Systemu. Jeśli w Architekturze Problemu występują również inne elementy, należy powtórnie zdefiniować System (np. poszerzyć o elementy otoczenia) i jego Architekturę.
• Należy również zdefiniować stan Systemu "po" zmianie i/lub kryteria akceptacyjne implementacji Rozwiązania, nie wnikając w sposób jego implementacji, a także plan testów akceptacyjnych, pozwalających stwierdzić , że nastąpiło Rozwiązanie Problemu.
• Proces Motywowania zostaje zakończony po stwierdzeniu kompletności i prawidłowości Architektury Problemu oraz pozostałych artefaktów.

A działa to tak:

Motywowanie poprzez definicję Problemu.

(Copyright 2020-2021 Marek Bisztyga)

Jak z powyższego widać, również w przypadku Motywowania można skutecznie powiązać "empirię", a przynajmniej jej rezultaty,  z "racjonalnością" walidacji i weryfikacji.

Do zobaczenia wkrótce,

Wasz,

M.

Inteligentne "szkiełko i oko" (Obserwowanie)

Uwaga. Wiele terminów występujących w  tekście zostało użytych w ramach przyjętej przez autora konwencji terminologicznej. W celu ich wyróżnienia, zostały one zapisane jako nazwy własne. 

W jednym z poprzednich postów został zaprezentowany wzorzec Procesu Racjonalnie Empirycznego, z angielska zwanego The Rationally Empirical Process, w skrócie TREP. 

W kolejnych kilku postach spróbuję dociec, gdzie i jak w TREPie przejawia się ów "racjonalny empiryzm", który w postcie "Szkiełko i Oko" zaproponowałem jako alternatywę dla kontrowersyjnej, w mojej opinii, scrumowej "teorii empiryzmu".

TREP - Proces Racjonalnie Empiryczny

(Copyright 2020-2021 Marek Bisztyga)

Spójrzmy raz jeszcze na TREPa. Zwróćmy uwagę na następujące aktywności:

• Obserwowanie,
• Motywowanie,

oraz

• Decydowanie,

które łącznie można nazwać pętlą "analityczną"  (nareszcie coś nawiązującego do naszej umiłowanej  analizy).

Pozostałe Działania - Przygotowanie i Oddziaływanie (Implementacja Decyzji) - choć równie istotne, bo to one właśnie wywołują realne zmiany "w czasie i przestrzeni", mają wtórny charakter wobec tych pierwszych, gdyż stanowią implementację uprzednio podjętych Decyzji i są od nich całkowicie pochodne. Bez poczynienia Obserwacji trudno określić Motywację, bez której z kolei nie bardzo wiadomo do czego się Przygotowywać, a bez uprzednio podjętej Decyzji nie zostanie uruchomiona jej Implementacja, czyli Oddziaływanie. 

Proces TREP
(Copyright 2020-2021 Marek Bisztyga)

Zacznijmy od Obserwowania. Zobrazujmy je w konwencji wzorca TREP, ale - by podkreślić i łatwiej zapamiętać fakt, że jest to jego podproces - diagram przedstawmy w układzie "poziomym" (Jest to tylko zabieg graficzno-estetyczny. Oba układu diagramu są równoważne) 

Obserwowanie jako podproces TREP

(Copyright 2020-2021 Marek Bisztyga)

Istotą Obserwowania jest wgląd i zrozumienie wybranego fragmentu rzeczywistości, co służy - choć nie gwarantuje - podejmowaniu adekwatnych do obserwowanej Sytuacji Decyzji.

Celem Obserwowania jest (patrz post "Zastanów się, co robisz") :

• pozyskiwanie Informacji (faktów, danych) o obserwowanym Zjawisku,
• klasyfikacja przedmiotu obserwacji, czyli jego umiejscowienie w siatce pojęciowej  (czym jest, do czego jest podobne, z czym jest powiązane itp,)

oraz

• wzbogacenie (poszerzenie zakresu i pogłębienie szczegółowości)   posiadanej wiedzy dziedzinowej - Metamodelu - oraz ogólnej, czyli Racjonalności (wyjaśnienie tych terminów można znaleźć w postcie Szkiełko i Oko).

Produktem Obserwowania jest:

• opis Zjawiska utrwalony w postaci tzw. Architektury Zjawiska/ Sytuacji/ Obiektu/ Systemu, 
• uaktualniony Metamodel,
• wzbogacona Racjonalność (patrz post "Szkiełko i Oko").

Obserwowanie jest Działaniem złożonym. Obejmuje następujące grupy czynności: 

• Percepcja Informacji, czyli rejestracja bodźców, detekcja zmian ilościowych lub jakościowych, pobieranie nowych danych lub jakakolwiek inna forma postrzegania tzw. Faktów dotyczących przedmiotu Obserwowania oraz jego Otoczenia; 
• Recepcja przedmiotu obserwacji, czyli - korzystając z odnotowanych Faktów, posiadanej wiedzy dziedzinowej Metamodelu i Racjonalności - przedstawienie jego Struktury i Zachowania - lub Dynamiki, gdy mamy do czynienia z obiektami pasywnymi, niezdolnymi do przejawiania własnego Zachowania, ale zmieniającymi stan - odpowiadając na pytania:
• z jakich elementów się składa ów przedmiot i jak są one powiązane (jaką mają Strukturę), 
• jakie procesy wewnętrzne w nim zachodzą (jak się Zachowują), 
• w jakich procesach zewnętrznych uczestniczy (w jakie wchodzi interakcje z innymi obiektami),
• jak zmienia się jego Struktura w wyniku Zachowania lub Dynamiki. 
• Synteza (modelowanie) Architektury obserwowanego Obiektu lub Zjawiska, czyli zrozumienie Zasad jego konstrukcji, Zachowania i/lub działania, w szczególności mechanizmu powodującego zaobserwowane Zachowanie uprzednio zidentyfikowanej Struktury;
• Klasyfikacja przedmiotu obserwacji poprzez próbę przyrównania rozpoznanej Architektury do aktualnego Metamodelu oraz postawienie, a następnie potwierdzenie lub sfalsyfikowane hipotezy, z jakiej klasy Zjawiskiem mamy do czynienia, bądź stwierdzenie wystąpienia nieznanego dotąd fenomenu; 
• Aktualizacja Metamodelu, czyli poszerzenie wiedzy o dziedzinie przedmiotu obserwacji oraz wkomponowanie jej w swą indywidualną i/lub kolektywną Racjonalność. 

 

Przykładowy przebieg Obserwowania.

(Copyright 2020-2021 Marek Bisztyga)

Zatem Obserwowanie nie jest li tylko biernym empirycznym (sensualnym) aktem postrzegania.

Obserwowanie stanowi rozstrzygnięcie  3  dylematów poznawczych:

• z czego się składa i  jak jest zbudowane,
• jaka jest jego dynamika: jak działa wewnętrznie, jak się zmienia pod wpływem oddziaływania otoczenia i jak oddziałuje na otoczenie,
• czym jest, czy i do czego jest podobne, czy może stanowi do tej pory nieznane

postrzegane zjawisko.

Oprócz powyższych "klasycznych" dylematów poznawczych, niektórzy badacze postulują konieczność rozstrzygania dodatkowego dylematu:

• jaka jest geneza przedmiotu obserwacji.

Byt postrzegany w danym momencie jest wynikiem pewnej transformacji stanu rzeczywistości "sprzed chwili". Często zatem, by zrozumieć jego stan bieżący, należy wiedzieć, z czego powstał, wykształcił się, co uległo przeobrażeniu. Pomoże to również w zrozumieniu jego ewentualnej dalszej ewolucji.

Obserwowanie to proces iteracyjny i przyrostowy. W jego trakcie dokonuje się akt tworzenia wiedzy przy aktywnym udziale Obserwatora, poprzez sukcesywną i naprzemienną Percepcję i Recepcję przedmiotu obserwacji. W jego ramach prowadzone są czynności par excellence "rozumowe" (analizy, syntezy), których nie da się zrealizować bez posiadania pewnej wiedzy i/lub wyobrażenia a priori, przynajmniej bez przyjęcia pewnych założeń, które obserwacja może potwierdzić lub sfalsyfikować, niezależnie skąd owa wiedza pochodzi.

Obserwowanie polega również na stawianiu, potwierdzaniu lub sfalsyfikowaniu hipotez odnośnie przedmiotu obserwacji, co również jest działalnością stricte intelektualną, choć bazującą na empirycznych rezultatach - tzw. Faktach - wymagającą posługiwania się jakimś teoretycznym modelem rozpatrywanego fragmentu rzeczywistości - Metamodelem - i Racjonalnością, która pozwala się nim posłużyć.

Na tym właśnie zasadza się owa "racjonalność empiryzmu" Obserwowania.

Interesująca właściwością tak zdefiniowanego Obserwowanie jest możliwość stosowania zarówno podejścia redukcjonistycznego, jak i holistycznego, a nawet jednego i drugiego naraz. Można zacząć od postrzegania detali i składania ich w całość budując Architekturę, lub odwrotnie, najpierw dojrzeć Architekturę jako całość, by potem rozkładać ją na części. Dzięki konstrukcji Obserwowania opartej o wzorzec TREP, można stosować oba podejścia naprzemiennie - w jednej iteracji przechodzić od szczegółu do ogółu, by w następnej, po próbie klasyfikacji, zdekomponować "ogólny" obraz, w celu weryfikacji, czy szczegóły się zgadzają.

"Na upartego" można nawet zastosować podejdzie emergentne. Wystarczy skonstatować to, co widać "gołym okiem" - Strukturę i Zachowanie - następnie, pomijając proces "zrozumienia" dlaczego "to" działa w taki, a nie inny sposób, sklasyfikować przedmiot obserwacji. Wiedzy z takiego podejścia jednak nie przybędzie. 

Dlaczego budowa Architektury i Klasyfikacja przedmiotu obserwacji jest tak istotna?

Aby móc zrozumieć przyszłość,  gdyż, jak wiadomo, przyszłości nie da się (jeszcze) przewidywać. 

Gdy stanie się to możliwe - kto wie? - moje dotychczasowe "filozofowanie", jak również parę innych rzeczy na tym świecie, stanie się bezprzedmiotowe i bez sensu. Ale, dopóki jeszcze coś bywa niewiadomym ...cieszmy się "chwilą" i kontynuujmy. 

Wiedząc z czym ma się do czynienia, a zatem rozumiejąc zasady zachowania się obserwowanego Zjawiska, można z pewnym prawdopodobieństwem antycypować przyszły rozwój wypadków i na tej podstawie wybierać adekwatne sposoby reagowania. Zatem umiejętność "rozumienia" przyszłości to warunek konieczny, choć niewystarczający, dla efektywnego Decydowania, które zawsze dotyczy właśnie przyszłości,

Niektórzy jednak, aby zdecydować o przyszłości najpierw uciekają się do manipulacji przeszłością, czyli Faktami, w myśl maksymy: 

"[...] Kto rządzi przeszłością, w tego rękach jest przyszłość; kto rządzi teraźniejszością, w tego rękach jest przeszłość. [...]"

- G. Orwell, Rok 1984

Nowa wiedza o Zjawisku pozyskana w trakcie Obserwowania uzupełnia Metamodel i Racjonalność, które tak wzbogacone są wykorzystywane do jeszcze bardziej pogłębionych analiz, syntez i podejmowania bardziej adekwatnych Decyzji, ale również do udoskonalenia metod i technik pozyskiwania Faktów w kolejnych iteracjach procesu poznawczego. Jest to proces iteracyjny i przyrostowy. 

Bez Recepcji nie ma Percepcji i przyrostu Wiedzy, ale bez teoretycznego Metamodelu i Racjonalności, czyli Wiedzy, nie rozumiemy, co rejestrują zmysły.

A Intuicja? Jest integralną, "podświadomą" częścią Racjonalności, równie ważną w procesach poznawczych co jej "świadoma" część. Intuicja to Wiedza, z obecności której nie zdajemy sobie sprawy i podlega takim samym prawom rozwoju. 

Ani "ilość" ani "jakość" (cokolwiek to znaczy) pobieranej w trakcie Recepcji Informacji tego nie zmienią. "Nagie" Fakty to zbyt mało.

"Patrzenie", choć istotne, nie jest najważniejszą operacją procesu Obserwowania. "Szkiełko i Oko" należy podłączyć do "Rozumu".

Z powyższego wywodu wynika kilka ważnych wniosków. 

• Klasyfikacja przedmiotu Obserwowania, a zatem i zdolność do "rozumienia jego teraźniejszości i  przyszłości", zależny w takim samych stopniu od:
• dokładności pomiaru czy ilości pozyskanych danych (Recepcji),
• poprawności analizy i syntezy Architektury (Percepcji),
• co używanego Metamodelu i posiadanej Racjonalności. 

Co począć w sytuacji, gdy mamy do czynienia z mnogością nie tylko Metamodeli (co jest zjawiskiem częstym), ale również Racjonalności, i nie można jednoznacznie orzec, która z nich jest poprawna, właściwa, która jest tą "jedynie słuszną"?

• Aby umyślnie wpłynąć na rezultat Obserwowania, a tym samym na podjęte na podstawie jego rezultatów Decyzje, nie trzeba przeinaczać Faktów, fałszerstwo których można łatwo wykryć. Wystarczy odpowiednio sterować przebiegiem procesu Obserwowania, "wgrać" określony Metamodel i/lub ukształtować Racjonalność. Na tym zasadza się istota tzw. zarządzania refleksyjnego, w których przedmiotem zainteresowania "zarządcy" jest nie tyle Szkiełko i Oko, lecz i Rozum "ofiary" oraz jej zdolność do lub umiejętność posługiwania się nim.

A jak "teoria" Obserwowania przekłada się na problematykę analizy biznesowo-systemowej?

Jeśli rozumieć termin "analiza" dosłownie - jako wyodrębnianie składników, cech i właściwości - Obserwowanie jest dokładnie tym, co nas, społeczność analityczną powinno interesować najbardziej, a w szczególności przedmiot (Architektura) i dziedzina (Metamodel) rozpatrywanego zagadnienia. Stanowią one podstawę każdego Działania. 

Analitycy, pracując na Faktach, nie ograniczają się li tylko do ich konstatacji, lecz dążą do ich zrozumienia w szerszym kontekście i wzajemnym powiązaniu. Pomimo że czynności analityczne często są inicjowane zgłoszeniami konkretnych niepożądanych symptomów - błędów, awarii, zleceń usprawnień i tym podobnych zdarzeń - jeśli nie są niezwłocznie obsłużone przez tzw. "pierwszą linię wsparcia", zostają przetransformowane w zgłoszenie Problemu i kierowane do analityków w celu opracowania ich Rozwiązania.

Wtedy pierwszą czynnością jest właśnie Obserwowanie - odtworzenie fragmentu rozpatrywanej rzeczywistości w formie Architektury Problemu (problemy tez mają swe architektury), Architektury Systemu oraz Metamodelu dziedzinowego.

Zastosujmy prezentowany powyżej model Obserwowania w przypadku Zmiany Systemu IT w celu Rozwiązania uprzednio zgłoszonego Problemu.

W procesie “Panta Rhei” Obserwowaniu zostało przypisane Walidowanie Rozwiązania Problemu - badanie, czy wprowadzona Zmiana Systemu rzeczywiście stanowi Rozwiązanie postawionego Problemu, i czy w tym sensie przedstawia jakąś wartość "biznesową". Podstawą do przeprowadzenia Walidacji jest zgłoszenie opracowania Rozwiązania Problemu oraz dostarczenie scenariuszy jego testów funkcjonalnych. Walidujący powinni jeszcze dysponować opisem Problemu podlegającego Rozwiązaniu oraz, oczywiście, testową instalacją nowej wersji Systemu. Produktem Walidowania jest:

• ocena, czy zaprezentowane Rozwiązanie stanowi Rozwiązanie Problemu,
• oraz Decyzja, czy można lub warto je wdrażać. Dodatkową korzyścią może być wzbogacenie wiedzy o samym Systemie i jego dziedzinie.

Przedstawmy Walidowanie w postaci podprocesu TREP (bądźmy konsekwentni do końca):

Walidowanie jako podproces TREP

(Copyright 2020-2021 Marek Bisztyga)

Walidowanie obejmuje następujące czynności:

• Testowanie funkcjonalne (“black-box”) Systemu.

Warunkiem kontynuacji Walidowania jest pozytywny rezultat testów funkcjonalnych. Wynik negatywny nie daje podstaw do stwierdzenia, że zaprezentowania Zmiana Systemu stanowi Rozwiązanie Problemu, co powoduje wyjście z procesu. 

• Identyfikacja zmian Struktury Systemu.

Identyfikacja nowych, usuniętych i zmienionych elementów oprogramowania oraz infrastruktury technicznej nowej wersji Systemu umożliwia dalsze badanie innych aspektów Systemu i zrozumienie wpływu zmian strukturalnych na przebieg procesów biznesowych Organizacji. 

• Identyfikacja zmian Zachowania Systemu.

Identyfikacja nowych, usuniętych i zmienionych funkcji nowej wersji Systemu umożliwia dalsze badanie innych aspektów Systemu i zrozumienie wpływu zmian funkcjonalnych na przebieg procesów biznesowych Organizacji. 

• Rekonstrukcja architektury procesów biznesowych Organizacji.

Zmiana Struktury i Zachowania nowej wersji Systemu może istotnie wpływać - zarówno pozytywnie, jak i negatywnie - na przebieg procesów biznesowych realizowanych przez Organizację, zatem konieczna jest konceptualna rekonstrukcja architektury procesów biznesowych i ocena ich domniemanego stanu w przypadku wdrożenia Rozwiązania Problemu.

• Decyzja odnośnie przydatności biznesowej nowej wersji Systemu.

Odpowiedź na pytanie, w jakim zakresie nowa wersja Systemu (lub jego fragmentu) rozwiązuje Problem oraz ocena skutków (biznesowych, ekonomicznych, organizacyjnych i innych) zmian Systemu umożliwia podjęcie Decyzji - pod warunkiem uzyskania pozytywnych rezultatów testów funkcjonalnych - o skierowaniu do wdrożenia produkcyjnego nowej wersji Systemu.

• Uaktualnienie Metamodelu Systemu.

Kompleksowa analiza Zmian Systemu wynikających z opracowania Rozwiązania Problemu dostarcza nowej wiedzy o samym Systemie, ale również o dziedzinie Systemu, którą to wiedzę (a raczej jej przyrost) należy wkomponować w dotychczasowy Metamodel Organizacji i Systemu.

Zatem i analitycy mogą "patrzeć" Rozumem. Przynajmniej powinni.

Do skarbnicy "ludowych" mądrości wszedł pewien cytat z "Idioty" Fiodora Dostojewskiego:

"Jak Pan Bóg chce kogoś ukarać, to mu najpierw rozum odbiera."

Ciekawe, dlaczego kara nie polega na odebraniu wzroku, słuchu lub innego zmysłu, co mogłoby się wydać równie dotkliwe? Może dlatego, że 

"Tylko rozum widzi i tylko rozum słyszy; wszystko inne jest głuche i ślepe." , 

jak miał powiedzieć Epicharm z Kos.

Nieustająco Wasz, 

M. 

Panta Rhei (TREP w Praktyce)

Uwaga. Wiele terminów występujących w  tekście zostało użytych w ramach przyjętej przez autora konwencji terminologicznej. W celu ich wyróżnienia, zostały one zapisane jako nazwy własne. 

W poprzednim postcie przedstawiłem wzorzec Procesu Racjonalnie  Empirycznego, po angielsku The Rationally Empirical Process, czyli TREP.

Pozornie TREP wydaje się nieco "wydumanym", teoretycznym i uproszczonym, w praktyce jednak, pomimo swej prostoty (a może właśnie dlatego?), okazuje się być poręcznym podejściem przy organizacji działania w bardzo szerokim zakresie. Na jego bazie można skonstruować wiele użytecznych procesów, również w obszarze wytwarzania i utrzymania rozwiązań IT (dalej nazywajmy je "Systemami"), co nas analityków interesuje najbardziej.  Zaryzykuję stwierdzenie, że wszystkie znane i praktykowane metodyki w tym obszarze są jego szczególnymi przypadkami.

Nie wierzycie? No to poczytajcie.

Przyjmijmy, że mamy do czynienia z bytem dalej zwanym "Firmą" - takim teminem w języku polskim potocznie określa się twór organizacyjny służący celom biznesowym - czyli złożonym bytem gospodarczym  obejmującym:

• Przedsiębiorstwo, byt konceptualny, podmiot prawa, wyodrębnioną prawnie  i ekonomicznie jednostkę gospodarczą,
• Organizację, byt socjologiczny, tworzony przez grupę osób intencjonalnie połączonych wspólnym zorganizowanym i celowym działaniem, pozostających w formalnych relacjach (struktura organizacyjna), wykonujących określone sekwencje (procesy) czynności (funkcje) o charakterze gospodarczym (zarządzanie finansowe, transakcje handlowe, marketing, itp), technologicznym (wytwarzanie, świadczenie sług, logistyka) i zarządczym (podejmowanie decyzji odnośnie Struktury i Zachowania i Organizacji). Przyjmijmy dodatkowo, że osoby tworzące Organizację Przedsiębiorstwa posiadają swe indywidulane Racjonalności na tyle zbliżone, że umożliwiają wzajemną komunikację i współdziałanie, czyli nie występuje zagrożenie przypadku budowy wieży Babel.
• System - byt techniczno-technologiczny składający się z kompleksu maszyn i urządzeń (w tym tzw. systemów informatycznych), środków transportu i łączności, nieruchomości wraz z wyposażeniem oraz innych środków trwałych,

(Uwaga. Czasami w niniejszym blogu termin "System" będziemy używać sensu largo w odniesieniu do każdego bytu będącego systemem w rozumieniu teorii systemów)

• Wiedzę branżową i ogólną (byt informacyjny), która podpowiada jak  zbudować, utrzymać w ruchu i rozwijać Przedsiębiorstwo, Organizację i System, oraz realizować procesy biznesowe, zarządcze, technologiczne i inne, czyli swego rodzaju Metamodel Przedsiębiorstwa.

Zatem Firma posiada Architekturę, a więc, wobec Firmy można zastosować Podejście Architektoniczne.

Architektura bytu gospodarczego

(Copyright 2020-2021 Marek Bisztyga)

Firma działa w pewnym otoczeniu i w reakcji na jego bodźce oraz zjawiska wewnętrzne zostaje poddawana Zmianom (sposób rozumienia pojęcia zmiany został podany w poprzednim postcie) w celu adaptacji do nowych warunków. Choć Zmiany mogą dotknąć różnych jej  elementów,  sposób ich przeprowadzenia obejmuje podobny, wręcz identyczny w swej istocie zestaw stanów i Czynności, i choć w różnych konkretnych przypadkach (kontekstach) mogą one występować pod różnymi nazwami, w istocie dotyczą aktywności tego samego charakteru. Oto one.

Uświadamianie (sobie lub interesariuszom) potrzeby Zmiany

Inicjatywy dokonania Zmian wynikają z uświadomionej i niezaspokojonej  potrzeby. Zazwyczaj najpierw dostrzegane są niepożądane objawy (symptomy) wskazujące na zaistnienie niepożądanego Stanu Przedsiębiorstwa, Organizacji i/lub Systemu (lub brak Stanu pożądanego, co również stanowi Stan niepożądany), który wywołuje przejaw woli i chęci  interesariuszy Przedsiębiorstwa przejścia w Stan pożądany. W tej fazie najczęściej jeszcze nie wiadomo, na czym owa Zmiana miałaby konkretnie polegać, ale panuje przekonanie, że musi nastąpić. Osiągnięcie Stanu pożądanego staje się Celem Strategicznym, przyjmując, że Celem Egzystencjalnym jest trwanie Przedsiębiorstwa i kontynuacja realizacji jego Misji. 

Owa wola/chęć dokonania Zmiany może być wyrażona w formie:

• zgłoszenia symptomów Stanu niepożądanego (np. zgłoszenia awarii),
• zgłoszenia wymagań biznesowych odnośnie pożądanej nowej funkcjonalności Organizacji i/lub Systemu (ang. features),

Definiowanie Problemu

Konstatacja potrzeby Zmiany buduje świadomość istnienia Problemu i konieczności jego Rozwiązania. By stwierdzić,  na czym ów Problem polega i co jest jego istotą - co jest jego tzw. "root cause", a co za tym idzie, co powinno być przedmiotem Zmiany - należy:

• zbadać scenariusz prowadzący do manifestacji objawów owego niepożądanego Stanu (Dynamika/Zachowanie Problemu) motywującego do Zmiany, lub scenariusz, który powinien być realizowany w ramach  postulowanej nowej funkcjonalności,
• zidentyfikować elementy Przedsiębiorstwa, Organizacji lub Systemu,  i ewentualnie ich otoczenia, które biorą udział w mechanizmie manifestacji tychże objawów lub w antycypowanym scenariuszu (Struktura Problemu).
• zrozumieć sam mechanizm powstawania objawów Stanu niepożądanego oraz zjawisk, które za nimi stoją, lub inicjacji i przebiegu antycypowanego scenariusza (Metamodel Problemu).

W ten sposób budowana jest tzw. Architektura Problemu obejmująca jego Strukturę, Dynamikę i Metamodel.  Pojęcie Architektury zostało wyjaśnione w odrębnym postcie.

Definiowanie Rozwiązania

Dysponując  Architekturą Problemu jesteśmy w stanie określić przedmiot (zakres) i sposób Zmiany, która ma polegać na takiej modyfikacji, dodaniu lub usunięciu wybranych elementów Przedsiębiorstwa, Organizacji i/lub Systemu, by w jej następstwie zniknął Stan niepożądany (lub pojawił się Stan pożądany) lub pojawiła się pożądana funkcjonalność. Tak skonstruowana Zmiana definiuje Architekturę Rozwiązania obejmującą:

• Strukturę Rozwiązania, czyli opis zbioru  zmodyfikowanych, dodanych lub usuniętych elementów  Przedsiębiorstwa, Organizacji lub Systemu (co i na co zostanie zmienione),
• Dynamikę/Zachowanie Rozwiązania, czyli opis pożądanego/oczekiwanego zachowania się zmienionych fragmentów   Przedsiębiorstwa, Organizacji lub Systemu, 
• Metamodel Rozwiązania, czyli opis ogólnej "mechaniki" wyjaśniającej jak i dlaczego można spodziewać się nowego Zachowania nowej Struktury, 

oraz opis metody jego implementacji, czyli plan działań, rezultatem których będzie materializacja Architektury Rozwiązania.

Implementacja Rozwiązania

Dysponując Architekturą (projektem) Rozwiązania można przystąpić do jego implementacji, czyli do przeprowadzenia faktycznej Zmiany Architektury Przedsiębiorstwa, Organizacji lub Systemu. Implementacja zazwyczaj sama w sobie jest procesem złożonym, obejmującym wiele kroków. Przebiega w sposób zróżnicowany, w zależności od przyjętej metodyki inżynierii, użytych technologii i narzędzi.

Walidowanie Rozwiązania, czyli odpowiedź na pytanie, czy dostarczyliśmy właściwe Rozwiązanie właściwego Problemu

Zanim Rozwiązanie zostanie skierowane do wdrożenia, czyli stanie się fragmentem nowej, zmienionej rzeczywistości, należy poddać je walidacji, czyli zbadać, czy i na ile stanowi Rozwiązanie  postawionego Problemu, i czy w tym sensie przedstawia wartość (np. biznesową) dla Organizacji. Technicznie rzecz ujmując, należy przeprowadzić "testy akceptacyjne" nowo powstałej wersji Organizacji czy Systemu oraz orzec, czy wprowadzone zmiany Struktury i Zachowania wykazują pożądane cechy, a także, czy nie powodują  niespodziewane nowe niepożądane efekty. 

Weryfikowanie procesu  budowy Rozwiązania, czyli odpowiedż  na pytanie, czy rozwiązanie zbudowaliśmy i dostarczyliśmy prawidłowo i właściwie

Na każdym etapie prac nad Rozwiązaniem należny weryfikować, czy proces jego budowy przebiega zgodnie z planem i ze sztuką, oraz czy spełnia wszystkie standardy obowiązujące w danej Organizacji. Rozwiązanie nie może spełniać jedynie wymagań funkcjonalnych.  Ważne, aby nie posiadało wad koncepcyjnych, błędów i usterek, nie rodziło zagrożeń naruszenia prawa, zasad bezpieczeństwa i innych pryncypiów, a przy tym spełniało wymogi ekonomiczne, mieściło się w akceptowalnych granicach całkowitych kosztów posiadania (TCO). 

Teraz powróćmy na moment do wzorca procesowego TREP.

Wzorzec TREP

(Copyright 2020-2021 Marek Bisztyga)

Z poprzedniego posta pamiętamy, że TREP obejmuje następujące Działania:

• określanie Celu Egzystencjalnego lub Strategicznego  rozpatrywanego podmiotu, 
• Motywowanie,
• Przygotowanie,
• Oddziaływanie (Implementowanie Decyzji),
• Obserwowanie,
• Decydowanie.

Przyjmijmy, że:

• Zaobserwowanie niepożądanych efektów i uświadomienie potrzeby Zmiany to wytyczanie Celu Egzystencjalnego i/lub Strategicznego (sensu dalszej egzystencji, misji), 
• Definiowanie Problemu to wyznaczanie Celu Operacyjnego, czyli Motywowanie.  By podjąć konkretne działanie, najpierw należy zrozumieć  jego cel, jakim jest Rozwiązanie Problemu.
• Definiowanie Rozwiązania to Przygotowanie do Implementacji Rozwiązania. Bez koncepcji lub planu budowy Rozwiązania Problemu nie można przystąpić do jego faktycznego rozwiązywania. Definicja Rozwiązania, oprócz wiedzy co i jak trzeba zrobić,  pozwala oszacować nakłady pracy  oraz określić wymagane zasoby, albowiem bezpośrednio zależą one nie tylko od Problemu, a od przyjętego sposobu jego rozwiązywania. Każdy Problem można rozwiązać na kilka sposobów.
• Implementowanie Rozwiązania to ...  Implementowanie czyli materializacja zamiaru dostarczenia Rozwiązania, 
• Walidowanie Rozwiązania to Obserwowanie/Analiza potencjalnych skutków jego wdrożenia i ocena,  czy i na ile  Rozwiązanie rozwiązuje Problem, a tym samym przedstawia wartość dla Organizacji,
• Weryfikowanie Rozwiązania to monitoring i sterowanie przebiegiem  procesu kreowania Rozwiązania począwszy od uświadomienia potrzeby Zmiany  do wdrożenia,  zakończone decyzją odnośnie dopuszczenia Rozwiązania do użytku, czyli Decydowanie.

Wtedy wzorzec TREP mógłby skonkretyzować się w postaci następującego procesu:

Proces Panta Rhei

(Copyright 2020-2021 Marek Bisztyga)

i działać przykładowo tak:

Proces Panta Rhei w działaniu

(Copyright 2020-2021 Marek Bisztyga)

Tym sposobem stworzyliśmy  przypadek użycia wzorca TREP w sferze praktycznej (np. IT), który na cześć mojego "filozoficznego" patrona, Heraklita z Efezu - praojca dialektyki i filozofii procesu -  nazwałem procesem 

Panta Rhei.

1. Proces inicjuje konstatacja wystąpienia niepożądanego Stanu i woli jego odmiany. Sterowanie zostaje przekazane Koordynatorowi (Decydentowi).
2. W pierwszej iteracji zostaje podjęta Decyzja o zdefiniowaniu Problemu.
3. Sterowanie zostaje przekazane analitykowi, który opracowuje Architekturę Problemu.
4. Następnie, na jej bazie, powstaje Architektura Rozwiązania.
5. Dalej, jeśli ta spełnia wymogi poprawności, na jej podstawie zostaje podjęta Decyzja projektowa. 
6. Kroki 3-4-5 mogą być powtarzane wielokrotnie
7. Projekt Rozwiązania zostaje skierowany do Implementacji.
8. Po jej ukończeniu, Rozwiązanie zostaje poddane Walidacji.
9. Jeśli jest ona negatywna, z reguły jest powtarzana definicja Rozwiązania i Implementacja.
10. W pewnych okolicznościach, jednak, może zaistnieć również konieczność zmiany definicji Problemu.
11. Wielo iteracyjny cykl trwa dopóty, dopóki Rozwiązanie nie zostanie zwalidowane pozytywnie i nie zapadnie Decyzja o akceptacji Rozwiązania.  

W przypadku zastosowania konkretnych ram postępowania, np. Scrum,  Proces Panta Rhei mógłby przybrać następującą, bardziej rozbudowaną formę :

Scrum jako implementacja Procesu "Panta Rhei" (1/2)

(Copyright 2020-2021 Marek Bisztyga)

 i przebiegać w następujący sposób:

Scrum jako implementacja Procesu "Panta Rhei" (2/2)

(Copyright 2020-2021 Marek Bisztyga)

W powyższym przykładzie poszczególne działania Procesu Panta Rhei odpowiadają tym zaczerpniętym z ram Scrum. Działanie "Implementacja  Rozwiązania" zostało przedstawiona w postaci rozwiniętego pod-procesu realizującego przebieg sprinta (Sprint Run), jak łatwo zauważyć również zbudowanego w oparciu o wzorzec TREP. Choć nie jest to uwidocznione na diagramie, Zarządzanie Product Backlog i pozostałe czynności również mogą przebiegać według wzorca TREP.

Można zatem uznać, że mamy do czynienia z implementacją  Scrum  jako szczególnego przypadku TREP.

Czy ma to jakieś praktyczne zastosowanie?

Po pierwsze, nic nie stoi na przeszkodzie, aby tak właśnie zorganizować pracę zespołu scrumowego (zdaję sobie sprawę, że po tych słowach wielu "fundamentalistów" scrumowych właśnie rzuciło na mnie klątwę i zaprzysięgło dżihad) i zautomatyzować workflow, tym samym implementując ową mityczną empiryczną "kontrolę procesu" w sposób godny miana podejścia procesowego.

Po drugie, procesowe ujęcie praktyki Scrum umożliwia bardzo przydatną z punktu widzenia zarządzania analizę symulacyjną procesu metodą Monte Carlo, na przykład przy użyciu narzędzi implementujących BPSim - standard specyfikacji i ilościowej analizy procesów. Dzięki temu możliwa jest dość dokładna estymacja szeregu parametrów procesu, takich jak np. czas trwania (włącznie z przestojami), koszty przebiegu procesu, stopień utylizacji zasobów i innych. Wiem, że w codziennej praktyce Scruma mało kto podchodzi do analizy procesu na tak szczegółowym poziomie, ale jeśli jest łatwe w użyciu narzędzie, to czemu nie? Przy projektach za "poważne" pieniądze - gdy "omsknięcie" w estymacjach o kilka punktów scrumowych kosztuje wiele kilo złotych monet - może warto spróbować?

Powróćmy do procesu Panta Rhei.

Proces możemy również kontrolować przy użyciu metodyki Kanban i sterować nim za pomocą względnie prostej tablicy. Wykorzystanie narzędzi Kanban dostarcza również  dodatkowych "profitów" analitycznych - możliwość ilościowego pomiaru efektywności procesu,  na przykład  przy pomocy Cumulative Flow Diagram.

Tablica Kanban sterująca Procesem Panta Rhei.

(Copyright 2020-2021 Marek Bisztyga)

Niech Was nie deprymuje mnogość kolumn w powyższej tablicy. Jak to w życiu, po każdej czynności zgłaszamy jej zakończenie i gotowość do weryfikacji ustawiając zadanie w kolumnie "Gotowe / Do Weryfikacji". Weryfikator, po analizie stanu realizacji zadania, wstawia je do kolejki zadań oczekujących na realizację kolejnej wybranej przez Weryfikatora czynności. Dzięki temu zachowujemy w  procesie zasadę "pull" - każda czynność  zostanie wykonana, gdy pojawią się ku temu warunki,  a Wykonawca będzie miał wolne "moce przerobowe". Gdyby zredukować w imię opacznie rozumianej prostoty ilość kolumn i wyrzuci kolejki oczekiwania, proces zamieniłby się w typ "push", a Weryfikator czasami nie mógłby przydzielać kolejnych zadań - musiałby śledzić dostępność poszczególnych Wykonawców. Proces mógłby się "zapychać". Poza tym, śledzenie stanu kolejek zadań oczekujących dostarcza cennych informacji zarządczych na temat efektywności całego procesu. Pozwala zauważyć wąskie gardła (zbyt długie czasy oczekiwania na pobranie) i zasygnalizować potencjalne problemy. 

Pewną modyfikacją powyższego układu tablicy,  naruszającą nieco kanoniczność metodyki Kanban,  jest zastąpienie kolumn zadań "oczekujących" wydzielonym torem (tzw. swimlane). Zadania oczekujące na obsługę są umieszczane w torze "oczekujących", skąd są pobierane do toru "obsługiwanych" w ramach danej kolumny. Zmniejsza to co prawda ilość kolumn, ale przy okazji powoduje wypaczenie wyników analizy czasu obsługi: czas oczekiwania (przebywania w torze "oczekujących") jest sumowany z czasem  rzeczywistej obsługi (przebywania w torze "obsługiwanych") zadania, gdyż większość narzędzi Kanban nalicza czas przebywania zadania w kolumnie bez względu na tor. W niektórych okolicznościach jednak może to być nawet  pożądaną cechą tablicy, gdy czas oczekiwania zadania ma "obciążać" obsługującego.

Tablica Kanban sterująca Procesem "Panta Rhei".

Wersja 2-torowa.

(Copyright 2020-2021 Marek Bisztyga)

Jako że Weryfikator jednoosobowo (kierownik projektu w podejściu "projektowym") lub kolektywnie (zespół w Scrum) "kieruje ruchem" w Procesie Panta Rhei, od jego decyzji zależy,  czy dany przebieg procesu będzie  bardziej typu "waterfall",  czy "agile". Może nawet mieszać podejścia w trakcie przebiegu Procesu. Jeśli zechce i ma to sens, może "iść waterfallem" (w dowolnej jego mutacji) w fazach definicji Problemu i Rozwiązania, a "agilem" (FDD, Scrumem, Kanbanen, a nawet Scrumbanen) w fazie Implementacji, tworząc wiele przyrostów walidowanych i weryfikowanych w każdej iteracji. Taka sytuacja  często ma miejsce, gdy problematyczne zjawisko jest dobrze udokumentowane,  a pomysł na jego rozwiązanie wydaje się oczywisty, natomiast wiele niewiadomych czai się w konstrukcji modyfikowanego produktu (np. w kodzie). Podejście można zmieniać z iteracji na iterację, gdy po  kolejnej Implementacji  nagle okaże się, że należy zmienić ocenę skali Problemu i zakresu Rozwiązania w świetle odkrycia nieznanych przedtem zależności architektonicznych kodu (zjawisko tzw. kompensat Zmian). W takich sytuacjach Panta Rhei daje pełną swobodę w adaptacji do bieżących warunków i potrzeb. Choć to jawne odejście od ortodoksji ( a nawet pachnące herezją), nie powoduje za to  żadnych "wojen religijnych" i "walk plemiennych" pomiędzy zwolennikami różnych podejść, ram postępowania i metodyk. Pokój i Harmonia.  Spróbujmy sobie to wyobrazić... 

Ech...Rozmarzyłem się...

Nieustająco Wasz,

M.