Analiza przyczyn źródłowych analitycznie

To o czym mówią specjaliści dziedzinowi, to nie są wymagania. Nie można ich tak traktować, gdyż szybką ścieżką prowadzi to do problemów w projekcie. Specjaliści dziedzinowi przekazują nam informacje. Ważne, ale jednak informacje. Mogą wśród nich być kandydaci na wymagania. Mogą być propozycje rozwiązań. Mogą być opinie na jakiś temat. Mogą być też problemy. Tym razem na dłużej chciałbym się zatrzymać przy tych ostatnich.

Słownik PWN definiuje termin Problem następująco:

1. «trudna sytuacja, z której należy znaleźć jakieś wyjście»
2. «poważna sprawa, która wymaga przemyślenia i rozstrzygnięcia»

W naszej sytuacji, pierwsza definicja wydaje się być bardziej pasująca do kontekstu. Mamy zgłoszony problem, który należy rozwiązać. Rewolucyjna czujność analityczna natychmiast powinna się w takim momencie zaktywizować, by świadomie odpowiedzieć sobie na pytanie czy to, o czym mówią specjaliści dziedzinowi, to problem źródłowy, czy też, bezpośredni albo pośredni, efekt takowego. Ale skąd mamy to wiedzieć, mógłby pomyśleć początkujący analityk. Jak to skąd, odpowiedziałby analityk bardziej doświadczony. Znasz fajf łaj?

5 Why

Po co 5 Why? Ano po to, by w dość prosty sposób zweryfikować, czy mówimy o problemie źródłowym, czy raczej o jego skutkach.

Mnóstwo czasu i nerwów tracimy na łączenie się z usługami zewnętrznymi.
O kurcze, to mamy problem. Dlaczego tak się dzieje?

Aaaaaa, bo usługa zewnętrzna rzuca błędami.
Dlaczego?
Bo okazuje się, że nie wszystkie parametry podałem tak, jak jest to wymagane.
Zapomniałeś o czymś?
Nie, nie wiedziałem.
Dlaczego nie wiedziałeś?
Bo analitycy mi nie powiedzieli.
Analitycyyy, dlaczego nie powiedzieliście?
Bo nie wiedzieliśmy.
Ale jak to?
Bo nie ma czasu na tak pogłębioną analizę.
Nie, a dlaczego?
Takie są ustalenia kierownika produkcji.

Przenosząc rozmowę na omawianą technikę, moglibyśmy uzyskać strukturę jak poniżej. Analizę zaczynamy od problemu. Następnie kolejno odpowiadamy na pytanie Dlaczego (tak się dzieje). Po osiągnięciu zadowalającej odpowiedzi, którą uznajemy za przyczynę źródłową kończymy serię pytań. Oczywiście liczba pytań dla danego problemu może być różna od 5.

W konsekwencji tej analizy, powinniśmy wskazać dodatkowo środki zaradcze, które przełożą się na usunięcie przyczyny źródłowej problemu (w przykładzie jest to usprawnienie procesu produkcyjnego).

Rys. Struktura przykładowego wnioskowania

Struktura wnioskowania nie w każdym przypadku będzie jednowątkowa – może się bowiem okazać, że odkryjemy kilka odpowiedzi na jedno pytanie Dlaczego. Taką sytuację prezentuje ilustracja poniżej.

Rys. Rozbudowana struktura przykładowego wnioskowania

Rozwijając wariantowość poszukiwań, warto mieć na uwadze, iż już pierwszy pytanie Dlaczego spowoduje, że rozpoczniemy osobną gałąź drzewa poszukiwań przyczyny źródłowej. W takiej sytuacji przydatnym może się okazać…

Diagram Ishikawy

Diagram Ishikawy, krótko mówiąc, jest techniką, która podpowiada kategorie problemów, od jakich można rozpocząć analizę przyczyn źródłowych. Po zidentyfikowaniu głównej kategorii dalej wykorzystujemy już znane nam 5 Why.

Oryginalna wersja Diagramu Ishikawy nawiązuje do typowych zagadnień produkcyjnych. Wydaje się, że dużo bardziej interesującą z punktu widzenia Analizy Biznesowej może być wersja zaproponowana przez McKinsey (7S). Taksonomia ta została wykorzystana do rozwinięcia omawianego problemu o kolejne przyczyny. Jak widać, w każdym przypadku stosujemy technikę 5 Why, natomiast konary zaproponowanego drzewa pozwalają na na ukierunkowanie kierunku myślenia na określone kategorie.

Rys. Diagram Ishikawy dla omawianego przykładu

Diagramy Ishikawy można także z powodzeniem dekomponować. Na przykład, gdyby się okazało, że dla przyczyny Programiści błędnie podają parametry wywołania usług, jest jeszcze kilka rozgałęzień, diagram stałby się mało czytelny. W takiej sytuacji można pokusić się o stworzenie diagramu traktującego tę przyczynę jako problem. Tworzy się go zgodnie z omówionymi zasadami, oczywiście mając na uwadze, iż faktyczny problem jest na diagramie pierwotnym.

Rys. Przykładowa dekompozycja

Analiza problemu może nas doprowadzić do wskazania wielu przyczyn źródłowych. Gdyby się okazało, że nie jesteśmy gotowi na usunięcie wszystkich, można przeprowadzić na przykład krótką analizę wartościującą środki zaradcze względem ich wpływu na usunięcie problemu oraz kosztów ich realizacji.

Rys. Przykład analizy atrakcyjności wdrożenia środków zaradczych

Podane techniki wyszukiwania przyczyn źródłowych mają wiele zalet. Są w miarę proste, stanowią zarówno narzędzie analityczne jak i facylitacyjne, więc mogą być z powodzeniem stosowane w trakcie pracy grupowej. Należy jednakże mieć na uwadze, iż jakość wniosków będzie bezpośrednim odzwierciedleniem jakości naszej facylitacji oraz doboru uczestników warsztatów.

Rozmawiając o problemach podczas prac analitycznych pamiętajmy, że specjaliści dziedzinowi niekoniecznie przekazują nam gotowy materiał analityczny. Informacje, to ‚tylko’ informacje. Jeśli jesteśmy informowani o problemie, bądźmy rewolucyjnie czujni i upewniajmy się, czy to faktycznie problem, czy jedynie skutek czegoś głębszego.

Bring Your Own Problem jako rama szkolenia

Szkoleniem analityków biznesowych mam przyjemność zajmować się ponad 20 lat. Pamiętam pierwsze szkolenia prowadzone z podstaw analizy systemowej z wykorzystaniem OMT – jednej z pierwszych rozpowszechnionych notacji obiektowych. Potem przyszły przypadki użycia Jacobsona, Yourdon…i tak rozwijała się analiza oparta o modelowanie w paradygmacie obiektowym. Prowadzone wówczas szkolenia w dużej mierze opierały się o poznawanie notacji i zrozumienie jak różne ich aspekty można ze sobą połączyć. W zasadzie wszystko było nowe.

20 lat później krajobraz analityczny wygląda zupełnie inaczej. Analiza Biznesowa, poprzez szerokie jej potraktowanie w ramach działań IIBA, stała się dyscypliną o bardzo szerokim zasięgu. Z drugiej strony, projekty prowadzone w dużych organizacjach (a głównie na rzecz takich pracuję) wymagają synchronizacji prac (i co ważniejsze, artefaktów w ich ramach powstających) z różnymi obszarami, zarówno merytorycznymi jak i technicznymi. Istotne stają się coraz bardziej kompetencje, pozwalające na skuteczną komunikację z różnymi interesariuszami projektów, jako że coraz bardziej rozrastają się korporacje a wraz z nimi powstają nowe księstwa, które nie zawsze mają interesy zbieżne z interesem organizacji. Na to wszystko nakładają się zmiany kulturowe (choćby wdrażane w różnej formie i skali podejścia zwinne czy też popularyzacja pracy zdalnej) oraz mnogość narzędzi wykorzystywanych do prowadzenia prac analitycznych, które często pokrywają się funkcjonalnościami i nie zawsze są zintegrowane w taki sposób, jakiego byśmy oczekiwali. A jeśli na to nałożymy fakt, iż nawet wewnątrz jednej organizacji różne zespoły mogą pracować według różnych zasad, to mamę w miarę pełny ogląd sytuacji. I jak w takiej sytuacji podnosić kompetencje?

Szkolenia tradycyjne

Oczywiście, zawsze można sobie wyobrazić obszar, w którym naszą wiedzę możemy podnieść uczestnicząc w tak zwanym tradycyjnym szkoleniu (wykład, przygotowane przez prowadzącego ćwiczenia, omówienie). Jeszcze większe korzyści można uzyskać z takich szkoleń w sytuacji, gdy chcemy przystąpić do jakiejś certyfikacji, która najczęściej wymaga przyswojenie dużej ilości nowej wiedzy. Pewne ‚dedykowanie’ materiału szkoleniowego można także uzyskać, zamawiając szkolenie zamknięte w ramach organizacji. Zawsze jednak będzie się ono opierało o wcześniej przygotowany materiał, lekko dostosowywany materiałami lub komentarzem do sytuacji organizacji. Można się także pokusić o przygotowanie całkowicie dedykowanego szkolenia dla wybranej grupy osób, ale po pierwsze, przygotowanie dobrego szkolenia to spory nakład pracy (tym samym, spory koszt dla zamawiającego) a po drugie, prowadzona podczas szkolenia ‚pogłębiona’ dyskusja może doprowadzić do wniosku, że szkolenie powinno dotyczyć jednak czegoś innego. Kilkukrotnie sam znalazłem się w takiej sytuacji, którą delikatnie można określić jako niekomfortową dla wszystkich stron.

Co w takim razie w zamian?

Bring Your Own Problem

Kilka lat temu po raz pierwszy prowadziłem szkolenie w takiej formie. Pamiętam tremę – jechałem do zacnej instytucji, z którą wcześniej omówiłem stojące przed nimi wyzwania i mając tego świadomość obawiałem się, czy szukanie przyczyn źródłowych oraz możliwych rozwiązań nie wykroczy poza moje kompetencje. Jedyne co miałem ze sobą, to komputer ze wszystkimi szkoleniami jakie do tej pory prowadziłem.

Szkolenie okazało się tak trudne, jak udane. Było zaplanowane na 6 godzin, trwało…11. Wszyscy wyszliśmy umęczeni ale zadowoleni z efektów. Spotkaliśmy się w tym samym gronie jeszcze kilka razy.

Tego typu szkolenia mają swoją specyfikę. Po pierwsze, nie mają zaplanowanego materiału do przekazania, ale zagadnienie w ramach którego będziemy prowadzili rozmowy. Oczywiście, pomysł na poprowadzenie musi być, ale to jakie treści będą przekazywane dynamicznie wynika z przebiegu rozmów. Po drugie, najczęściej są prowadzone w niezbyt licznym gronie. Im mniejsze, tym lepsze. Zwykle w szkoleniu uczestniczą kluczowe osoby z punktu widzenia omawianego zagadnienia. Po trzecie, szkolenia BYOP nie mogą być prowadzone przez ‚trenera z zawodu’, lecz doświadczonego praktyka o kompetencjach trenerskich. Po czwarte, zwykle mają swoją kontynuację.

Jeśli więc jesteś doświadczonym analitykiem i udział w tradycyjnych szkoleniach nie przynosi już korzyści, może warto pomyśleć o tego rodzaju ścieżkach podnoszenia kompetencji?

Grafika: Business photo created by rawpixel.com – www.freepik.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.