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.

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.

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.