Stwierdzenie problemu - Problem statement

Stwierdzenie problemu to zwięzły opis problemu, który należy rozwiązać, lub warunku, który należy poprawić. Identyfikuje lukę między obecnym stanem (problemu) a pożądanym (celem) stanem procesu lub produktu. Skupiając się na faktach, oświadczenie problem powinien być zaprojektowany w celu zaspokojenia Pięć Ws . Pierwszym warunkiem rozwiązania problemu jest zrozumienie problemu, co można zrobić za pomocą opisu problemu.

Zestawienia problemów są szeroko stosowane przez większość firm i organizacji do realizacji projektów doskonalenia procesów . Zespół projektowy użyje prostego i dobrze zdefiniowanego opisu problemu, aby zrozumieć problem i pracować nad opracowaniem rozwiązania. Zapewni również kierownictwu konkretny wgląd w problem, aby mogli podejmować odpowiednie decyzje zatwierdzające projekt. W związku z tym ważne jest, aby sformułowanie problemu było jasne i jednoznaczne.

Cel, powód

Głównym celem opisu problemu jest identyfikacja i wyjaśnienie problemu. Obejmuje to opisanie istniejącego środowiska, miejsca występowania problemu i jego wpływu na użytkowników, finanse i działania pomocnicze. Ponadto opis problemu służy do wyjaśnienia, jak wygląda oczekiwane środowisko. Zdefiniowanie pożądanego stanu zapewnia ogólną wizję procesu lub produktu. Wyjaśnia cel rozpoczęcia projektu doskonalenia i cele, które ma on osiągnąć.

Inną ważną funkcją opisu problemu jest wykorzystanie go jako urządzenia komunikacyjnego. Stwierdzenie problemu pomaga w uzyskaniu poparcia osób zaangażowanych w projekt. Przed rozpoczęciem projektu interesariusze weryfikują problem, a cele są dokładnie opisane w opisie problemu. Po otrzymaniu tego zatwierdzenia zespół projektowy sprawdza je, aby upewnić się, że wszyscy rozumieją dany problem i co starają się osiągnąć. Pomaga to również zdefiniować zakres projektu , dzięki czemu projekt koncentruje się na ogólnym celu.

Stwierdzenie problemu jest przywoływane w całym projekcie, aby skoncentrować się w zespole projektowym i sprawdzić, czy są na dobrej drodze. Pod koniec projektu następuje ponowne sprawdzenie, aby potwierdzić, że wdrożone rozwiązanie rzeczywiście rozwiązuje problem. Dobrze zdefiniowane stwierdzenie problemu może również pomóc w przeprowadzeniu analizy przyczyn źródłowych, aby zrozumieć, dlaczego wystąpił problem i zapewnić, że można podjąć środki, aby zapobiec jego wystąpieniu w przyszłości.

Należy zauważyć, że opis problemu nie definiuje rozwiązania ani metod dojścia do rozwiązania. Stwierdzenie problemu po prostu rozpoznaje lukę między stanem problemu a stanem celu. Można powiedzieć, że „problem dobrze postawiony jest w połowie rozwiązany”. Jednak często istnieje wiele realnych rozwiązań problemu. Dopiero po napisaniu i uzgodnieniu opisu problemu należy omówić rozwiązanie (rozwiązania) i określić wynikający z tego kierunek działań.

Zdefiniowanie problemu

Zanim sformułowanie problemu będzie mogło zostać spreparowane, problem musi zostać zdefiniowany. W ludzkiej naturze leży chęć jak najszybszego rozpoczęcia pracy nad rozwiązaniem i zaniedbywanie definicji prawdziwego problemu do rozwiązania. Jednak słabo zdefiniowany problem zwiększa ryzyko wdrożenia rozwiązania, które nie w pełni spełnia oczekiwane rezultaty. Problemu nie da się rozwiązać, jeśli nie jest do końca zrozumiały.

Proces definiowania problemu to często wysiłek grupowy. Zaczyna się od spotkania z interesariuszami, klientami i/lub użytkownikami, których dotyczy problem (jeśli to możliwe) i poznania ich problemów. Ponieważ ludzie często mają trudności ze skutecznym komunikowaniem swoich problemów, szczególnie komuś spoza procesu, warto zadać serię pytań „dlaczego” do czasu zidentyfikowania podstawowego rozumowania. Ta metoda, znana jako „ 5 dlaczego ”, pomaga dotrzeć do sedna problemu, ponieważ wiele doświadczonych frustracji może być jedynie objawami rzeczywistego problemu. Zadawanie tych dodatkowych pytań, a także parafrazowanie tego, co powiedział interesariusz, świadczy o empatii i zrozumieniu problemu.

Informacje zebrane z tych wstępnych wywiadów to tylko część analizy problemu. Wielokrotnie problem rozciąga się na wiele obszarów lub funkcji, których interesariusze, klienci i użytkownicy nie są świadomi. Mogą również być zaznajomieni z tym, co dzieje się na powierzchni, ale niekoniecznie z podstawową przyczyną. Dlatego równie istotne jest zebranie wiedzy, informacji i spostrzeżeń od członków zespołu projektowego oraz ekspertów merytorycznych na temat problemu. Konieczne może być również zapoznanie się z dodatkowymi materiałami badawczymi, w tym instrukcjami pracy, podręcznikami użytkownika, specyfikacjami produktów, schematami przepływu pracy i poprzednimi planami projektów. Podobnie jak w przypadku większości innych etapów projektu doskonalenia procesu, definiowanie problemu jest często iteracyjne, ponieważ może być potrzebnych kilka rund dyskusji, aby uzyskać pełny obraz.

Po zrozumieniu problemu i wyjaśnieniu okoliczności, które doprowadziły do ​​rozpoczęcia projektu, nadszedł czas na napisanie opisu problemu.

Pisanie opisu problemu

Stwierdzenie problemu zostanie wykorzystane do uzyskania wsparcia projektu i zatwierdzenia przez interesariuszy. Jako taki musi być zorientowany na działanie. Co ważniejsze, opis problemu musi być napisany jasno i dokładnie, aby zapewnić pomyślne wyniki. Źle spreparowane lub niepoprawne stwierdzenie problemu doprowadzi do wadliwego rozwiązania, a także do zmarnowania czasu, pieniędzy i zasobów.

Istnieje kilka podstawowych elementów, które można wbudować w każde stwierdzenie problemu, aby zmniejszyć ryzyko niepowodzenia projektu. Po pierwsze, opis problemu musi koncentrować się na użytkowniku końcowym . Częstym błędem jest skupianie się na tym, „jak” zostanie rozwiązany problem, a nie na obecnej przepaści. Po drugie, opis problemu nie powinien być zbyt szeroki. Zaletą stosowania podejścia „5 dlaczego” jest to, że unika się nadmiernej prostoty poprzez podanie szczegółów potrzebnych do zrozumienia problemu i opracowania odpowiedniego rozwiązania. Wreszcie, opis problemu nie powinien być zbyt wąski. Tendencja do rozwiązania tłumi kreatywność, która pojawia się podczas burzy mózgów nad rozwiązaniem, co może skutkować mniej niż optymalnym doświadczeniem użytkownika.

Przy pisaniu opisu problemu przydatne jest zaprojektowanie i przestrzeganie określonego formatu. Chociaż istnieje kilka opcji, aby to zrobić, poniżej znajduje się prosty i bezpośredni szablon często używany w analizie biznesowej, aby skupić się na zdefiniowaniu problemu.

  1. IDEALNY: Ta sekcja służy do opisania pożądanego lub „być” stanu procesu lub produktu. Identyfikuje cele interesariuszy i klientów oraz pomaga w zdefiniowaniu zakresu. Ogólnie rzecz biorąc, ta sekcja powinna zilustrować, jak będzie wyglądało oczekiwane środowisko po wdrożeniu rozwiązania.
  2. RZECZYWISTOŚĆ: Ta sekcja służy do opisania aktualnego lub „takiego, jaki jest” stanu procesu lub produktu. Wyjaśnia problemy zgłaszane przez interesariuszy i klientów. Powinna również zawierać spostrzeżenia i wiedzę zespołu projektowego oraz ekspertów merytorycznych przekazane podczas analizy problemu.
  3. KONSEKWENCJE: Ta sekcja służy do opisania wpływu na firmę, jeśli problem nie zostanie naprawiony lub poprawiony. Obejmuje to koszty związane z utratą pieniędzy, czasu, wydajności, przewagi konkurencyjnej i tak dalej. Skala tych efektów pomoże również określić priorytet projektu.
  4. PROPOZYCJA: Ta sekcja służy do opisu potencjalnych rozwiązań. Gdy sekcje ideału, rzeczywistości i konsekwencji zostaną ukończone, zrozumiane i zatwierdzone, zespół projektowy może zacząć oferować opcje rozwiązania problemu. Może również zawierać sugestie zainteresowanych stron i klientów, chociaż dalsze dyskusje i badania będą potrzebne przed określeniem konkretnego kierunku działania.

Stosowanie tego formatu da w rezultacie działający dokument, z którego mogą korzystać wszystkie strony, aby zrozumieć problem i określić wymagania, które doprowadzą do zwycięskiego rozwiązania.

Przykład

Opisy problemów mogą mieć różną długość, w zależności od złożoności problemu. Poniżej znajduje się przykład prostego opisu problemu dotyczącego tworzenia możliwości pojedynczego logowania:

IDEALNY :

Idealnie byłoby, gdyby nasi użytkownicy mogli logować się na swoich laptopach, a następnie automatycznie uzyskiwać dostęp do wszystkich aplikacji, których potrzebują.

RZECZYWISTOŚĆ :

W rzeczywistości do wykonywania naszej pracy używamy co najmniej trzech aplikacji dziennie. Każda aplikacja jest chroniona hasłem o różnych wymaganiach dotyczących nazwy użytkownika i długości hasła. Hasła również wygasają w różnym czasie.

KONSEKWENCJE :

  • Użytkownicy marnują około 2 minut dziennie logując się do wielu aplikacji (Przyjmijmy, że jeśli jest 500 użytkowników, to 500 użytkowników * 2 minuty dziennie = 1000 minut w utraconej produktywności; 1000 minut = 16,67 godzin dziennie * 75 USD/godz. = 1250 USD dziennie) .
  • Helpdesk rozwiązuje około 6000 połączeń rocznie, aby zresetować zapomniane hasła i odblokować konta.
  • Ryzyko bezpieczeństwa, ponieważ użytkownicy będą nadal pisać nazwy użytkowników i hasła na karteczkach samoprzylepnych na swoich biurkach.

WNIOSEK

Współpracuj z programistami programistycznymi, administracją sieci i interesariuszami biznesowymi w celu oceny potencjalnych rozwiązań dla funkcji pojedynczego logowania.

Bibliografia

  1. ^ B Kush Max (czerwiec 2015). „Problem z oświadczeniem”. Postęp jakości . 48 (6).
  2. ^ B c Annamalai, Nagappan; Kamaruddin, Shahrul; Azid, Ishak Abdul; Tak, TS (wrzesień 2013). „Znaczenie opisu problemu w rozwiązywaniu problemów branżowych”. Mechanika Stosowana i Materiały . Zurych. 421 : 857-863. doi : 10.4028/www.scientific.net/AMM.421.857 . S2CID  60791623 .
  3. ^ B c Gygi Craig; DeCarlo, Neil; Williams, Bruce (2015). Six sigma dla manekinów . Hoboken, NJ: John Wiley & Sons. s. 76-78.
  4. ^ B Lindstrom Chris (2011-04-24). „Jak napisać zgłoszenie problemu” . www.ceptara.com . Pobrano 2018-04-10 .
  5. ^ B Perry Randy; Boczek, Dawid (2010). Komercjalizacja świetnych produktów z designem dla Six Sigma . Sala Prezydencka. P. 18.
  6. ^ B Shaffer Deb (12.07.2017). „Jak napisać zgłoszenie problemu” . Kierownik Projektu . Pobrano 2018-04-10 .
  7. ^ B Shaffer David (21.12.2015). „Przygotowywanie sukcesu analizy biznesowej” . Czasy BA . Pobrano 2018-04-10 .
  8. ^ B c Widen, Steven (2018-04-02). „Wykonaj te kroki, aby zdefiniować problem z interfejsem użytkownika/UX i uniknąć przypadkowych zmian” . Forbesa . Pobrano 2018-04-10 .