Metoda Kepner-Tregoe opiera się na systematycznych analizach problemów z próbą zrozumienia ich prawdziwych źródeł, w odróżnieniu do powszechnego podejścia – robienia założeń i rzucania się na konkluzje. Metoda Kepner-Tregoe zyskała uznanie i stała się powszechnie stosowaną metodą rozwiązywania problemów przez techniczne działy IT. Została dołączona do zbioru dobrych praktyk ITIL (ang. IT Infrastructure Library). W tym artykule skupimy się na głównych założeniach metody, opiszemy kroki, wyjaśniając jednocześnie zalety każdego kroku w odniesieniu do przykładowego problemu.

Cykl analizy w metodzie Kepner-Tregoe składa się z następujących kroków:

  • Zdefiniowanie problemu;
  • Dokładny opis problemu;
  • Określenie potencjalnych przyczyn;
  • Przetestowanie najbardziej prawdopodobnej z nich;
  • Weryfikacja prawdziwej przyczyny.

Zdefiniowanie problemu

Pierwszy krok jest kluczowy. Ktoś mógłby zapytać – jak można oczekiwać rozwiązania problemu w momencie, gdy nie potrafimy go zdefiniować? Wiele osób wówczas zwyczajnie pomija ten krok zakładając, że znają naturę problemu, widzą co się stało i prowadzą dalszą inwestygację. Niemniej jednak bardzo często powracają do początku, gdyż okazuje się,że „pewniak” najwyraźniej nie jest problemem. W ostatecznym rozrachunku prowadzi to do znaczących strat czasu, wynikających z konieczności rozpoczęcia prac od nowa.

W przypadku niektórych, zgłaszanych przez użytkowników problemów, typu „mój ekran monitora jest czarny”, podjęcie błyskawicznych działań jest dość łatwe i wiele osób od razu zaczyna pracę nad rozwiązaniem problemu. Zadanie dodatkowych pytań może doprowadzić do odkrycia nowych faktów i zdefiniowania możliwych przyczyn problemu.

Pójdźmy nieco dalej. Zadajmy kilka podstawowych pytań dotyczących problemów, co ułatwi nam analizę na późniejszym etapie w metodzie Kepner-Tregoe. Można skorzystać z wielu dróg i metod, ja posłużę się metodą 5 W (nazwa pochodzi od litery w wyrazach, od których można rozpocząć zadawanie pytań – ang.why/who/when/where/what):

  1. Kto doświadcza problemu?
  2. Do czego ekran miał posłużyć?
  3. Jakie są symptomy? Jakie błędy towarzyszą problemowi?
  4. Kiedy problem się pojawił lub od kiedy się pojawia?
  5. Gdzie problem się pojawił?

A teraz odpowiedzi na powyższe pytania:

  1. Kto – Marian Trela;
  2. Cel – zamówienie części zapasowych;
  3. Przy uruchamianiu komputera, monitor się wyłącza. Nic się nie pojawia,
    ale słychać muzykę przy starcie systemu;
  4. Problem występuje przy włączaniu komputera. Nic nie pojawia się na ekranie po starcie komputera. Wczoraj, przed wyłączeniem komputera, wszystko działało..
  5. Gdzie – komputer Mariana Treli; Nikt inni takich błędów nie zgłosił.

Na podstawie takich danych zdefiniujmy problem:

Pan Trela nie może zamówić części zamiennych na swoim komputerze, ponieważ po włączeniu komputera na jego monitorze nic się nie wyświetla. Problem utrzymuje się od dnia wczorajszego, gdy komputer został wyłączony.

Taka definicja problemu wydaje się być bardziej kompletna i czytelna. Od samego początku pozwoli działom IT na jego lepsze zrozumienie. Opiera się na pytaniach pomocniczych, zatem gwarantuje lepszy opis problemu. Pozwala na zrozumienie zakresu (zakres wpływu) oraz jego konsekwencji (brak możliwości złożenia zamówienia).

W metodzie Kepner-Tregoe ważnym krokiem jest zweryfikowanie poprawności opisu. Do tego posłuży nam lista kolejnych, dodatkowych pytań pomocniczych. Pytania skoncentrowane będą na potencjalnych przyczynach (dlaczego?):

P: Czy możliwe, że przyczyną jest niedziałająca karta graficzna?
O: Nie, komputer by się uruchomił, usłyszelibyśmy za to 3 dźwięki, po czym komputer się wyłączył.

P: Czy możliwe, że przyczyną jest wadliwy monitor?
O: Nie, przy starcie widzimy logo producenta;

P: Czy możliwe, że przyczyną jest uszkodzony twardy dysk?
O: Nie, słychać w tle dźwięk uruchamianego systemu operacyjnego;

P: Może podświetlenie monitora przestało działać?
O: Nie, przy starcie widzimy logo producenta;

P: Może komputer został przełączony na zewnętrzny monitor?
O: Nie, na zewnętrznym monitorze wszystko wyświetla się poprawnie, ale przy powrocie na wewnętrzny wyświetlacz – wszystko znika.

Na podstawie tego zestawu pytanie-odpowiedź, możemy nieco ulepszyć nasz opis problemu:

Pan Trela nie może zamówić części zamiennych na swoim komputerze, ponieważ od momentu startu sytemu operacyjnego, na jego wewnętrznym monitorze nic się nie wyświetla. Problem utrzymuje się od dnia wczorajszego, gdy komputer został wyłączony.

Dużo więcej informacji. Znacznie lepsza definicja problemu, która w metodzie Kepner-Tregoe posłuży m.in. do stworzenia formalnego opisu problemu.

Opis problemu w metodzie Kepner-Tregoe

Na tym etapie zajmiemy się opisem problemu w kontekście 4 różnych aspektów, takich jak:

  • co jest problemem;
  • gdzie problem występuje;
  • kiedy się pojawił lub pojawia;
  • rozmiar problemu.

Na nasze szczęście, częścią informacji już dysponujemy, dzięki punktom, które opisane zostały w trakcie definiowania problemu. Dzięki dalszym rozwinięciom poszerzymy znacznie swoją wiedzę na temat problemu.

Dla wszystkich aspektów problemów wymienionych powyżej, określimy krótkie charakterystyki, podobne do tych z kroku 1 (definicja) skupiając się na tym, czym problem mógłby być, lecz nie jest. Posłużymy się formą tabelaryczną, która świetnie sprawdza się w przypadku takich zadań i aktywności. Pozyskamy szczegóły nt. problemów wskazując jednocześnie czynniki, które tego problemu nie wywołały.

tabela opisująca cztery aspekty opisu problemu, rozwijane poprzez formułowanie dodatkowych pytań
tabela opisująca cztery aspekty opisu problemu, rozwijane poprzez formułowanie dodatkowych pytań

A teraz wypełnijmy tabelę w nawiązaniu do przedstawianego wcześniej problemu:

tabela opisująca cztery aspekty opisu problemu wyświetlacza
tabela opisująca cztery aspekty opisu problemu wyświetlacza

Określenie potencjalnych przyczyn

W metodzie Kepner-Tregoe, zestawienie “jest”, “mógłby być”, które zostało sporządzone wcześniej pozwoli nam na określenie zmian, które miały wpływ (kolumna „Jest”) oraz mogły, ale nie miały wpływu (kolumna „Mógłby być”). Doświadczenie w obszarze IT najczęściej wskazuje na ostatnio wprowadzone zmiany jako najczęstsze źródło problemów, przynajmniej w przypadku systemów, które przez dłuższy czas działały bez zarzutów.

By móc jeszcze lepiej opisać problem w kontekście potencjalnych przyczyn, wprowadzimy do naszej tabeli dwie dodatkowe kolumny. Pierwsza z nich „Różnice” – opisuje rozbieżności pomiędzy kolumnami „Jest” i „Mógłby być”. Druga kolumna – „Zmiany”, zawiera informacje dotyczące wszystkich zmian odnoszących się do aspektu „Gdzie”. Jest problem, który mogłyby doprecyzować „Różnice”:

Problem Analysis
rozszerzona tabela opisująca cztery aspekty opisu problemu wyświetlacza

Wartą uwagi jest kwestia, że efekty nie zawsze następują po ostatnio wykonanych zmianach, mogą jedynie przyspieszyć pojawienie się problemów, które od zawsze były w infrastrukturze, dlatego listując zmiany, nie należy ograniczać się jedynie do ostatnio przeprowadzonych.

Przetestowanie najbardziej prawdopodobnej przyczyny

Opisane we wcześniejszym kroku zmiany w metodzie Kepner-Tregoe, stanowić będą zbiór potencjalnych przyczyn problemu, wyjaśniający powody jego pojawienia się. Dla każdego potencjalnego źródła należy zadać sobie pytanie: „czy to jest przyczyna tego problemy, czy to wyjaśnia wszystko, czym problem „jest” oraz tym, czym „mógłby być, a nie jest”. Poniższa tabela pomoże w określeniu prawdopodobieństwa:

RCA problem analysis
rozszerzona tabela z testem potencjalnych przyczyn

Weryfikacja prawdziwej przyczyny

Metoda Kepner-Tregoe na tym etapie zakłada  porównanie prawdopodobnych przyczyn wystąpienia problemów z ich opisami, celem weryfikacji, czy wyczerpują one jego znamiona.

Jeżeli taka przyczyna (np. aktualizacja sterowników) została już wybrana, należy ją przetestować zgodnie z zapisami w kolumnie „Prawda, jeżeli”. Dlatego też należy zacząć od tej najbardziej prawdopodobnej zgodnie ze skalą, którą przyjęto (kolumna „Prawdopodobieństwo”). Jeżeli reprodukcja się powiedzie, potwierdzi to ostatecznie źródło problemu.

Implementacja rozwiązania, które zapobiegnie dalszym pojawieniom się problemu to ostatni krok wybiegający już poza samą analizę. Wprowadzenie zmiany może się jednak odbyć wyłącznie wtedy, gdy istnieje pewność, że zdiagnozowano źródło problemu (w ostateczności: jeżeli to prawdopodobieństwo jest wysoko oceniane).

Powróćmy do naszego przykładu. Załóżmy, że problem wyświetlacza był spowodowany ostatnią aktualizacją sterowników i pojawił się dopiero, gdy komputer został ponownie włączony. Możemy rozwiązać problem poprzez dodatkowe podłączenie zewnętrznego monitora lub też odinstalowanie ostatnio zainstalowanej wersji sterowników. Czy to stanowi jednak w rzeczy samej źródło problemu? Na problem można spojrzeć z wielu różnych perspektyw:

  • dział IT: źródło problemu – sterownik karty graficznej w wersji 5.1;
  • producent sterownika: bug w kodzie w funkcji dostrajania obrazu.

Bez względu na punkt widzenia, tak przeprowadzona analiza problemów (metodą Kepner-Tregoe) doprowadziła nas do ustalenia przyczyn problemu.

Na chwilę obecną, na polskim rynku firm szkoleniowych istnieje taka, która metodę Kepner-Tregoe traktuje jako przedmiot profesjonalnych szkoleń.