Kiedyś opiekowałem się jednym z serwisów internetowych ze strony firmy ją obsługującej po wdrożeniu. Serwis był umieszczony na serwerach jednej z firm hostingowych. W godzinach szczytu wykorzystania serwisu występowały sytuacje, gdy serwer był niedostępny. W takim momencie wykonywałem telefon do administratorów z prośbą o pomoc. Po chwili, dłuższej lub krótszej wszystko wracało do normy. Trudno było określić przyczyny, więc po jakimś czasie firma hostingowa została zmieniona.
Administrator serwera znajdował rozwiązanie krótkoterminowe, które wykorzystywał wielokrotnie. Chcąc uniknąć takiej sytuacji w przyszłości, mógłby przeprowadzić analizę, zmierzającą do znalezienia rzeczywistej przyczny. O powyższej sytuacji przypomniał mi artykuł na stronie Startup Lessons Learned dotyczący metody 5-ciu dlaczego (Five Whys).
Znalezienie przyczyny problemów mogłoby przebiegać jak w poniższym przykładzie zaczerpniętym ze wskazanej powyżej strony (po przetłumaczeniu):
- Dlaczego serwis internetowy padł?
Odp.: Użycie wszystkich procesorów obsługujących serwis doszło do 100%. - Dlaczego użycie procesora podskoczyło?
Odp.: Nowy kawałek kodu posiadał pętlę nieskończoną. - Dlaczego nowy kod został źle napisany?
Pracownik X popełnił błąd. - Dlaczego jego pomyłka została dołączona do kodów?
Nie napisał testu jednostkowego dla nowej funkcjonalności. - Dlaczego nie napisał testu jednostkowego?
Jest nowym pracownikiem I nie został właściwie przeszkolony w wykorzystaniu TDD (ang. Test Driven Development).
Dochodzenia za pomocą tej metody do sedna sprawy, do rzeczywistej przyczyny, może odbywać się w kroku Analizy problemu przed przygotowaniem Korekty długoterminowej – kroków wskazanych przy omawianiu metody rozwiązywania problemów 8D. Pozwala to uniknięcie powtórzenia takiej sytuacji w przyszłości.
Modelowanie procesów biznesowych 