Declarație problemă - Problem statement

O declarație de problemă este o descriere concisă a unei probleme care trebuie abordată sau o condiție de îmbunătățit. Identifică decalajul dintre starea curentă (problemă) și starea dorită (obiectiv) a unui proces sau produs. Concentrându - se pe fapte, declarația problema ar trebui să fie concepute pentru a aborda cinci Ws . Prima condiție a rezolvării unei probleme este înțelegerea problemei, care se poate face printr-o declarație a problemei.

Declarațiile de problemă sunt utilizate pe scară largă de majoritatea companiilor și organizațiilor pentru a executa proiecte de îmbunătățire a proceselor . O declarație de problemă simplă și bine definită va fi utilizată de echipa de proiect pentru a înțelege problema și pentru a lucra la dezvoltarea unei soluții. De asemenea, va oferi conducerii informații detaliate asupra problemei, astfel încât să poată lua decizii adecvate de aprobare a proiectului. Ca atare, este crucial ca declarația problemei să fie clară și fără ambiguități ..

Scop

Scopul principal al afirmației problemei este identificarea și explicarea problemei. Aceasta include descrierea mediului existent, unde apare problema și ce impact are asupra utilizatorilor, finanțelor și activităților auxiliare. În plus, declarația de problemă este utilizată pentru a explica cum arată mediul așteptat. Definirea stării dorite oferă o viziune generală pentru proces sau produs. Acesta arată clar scopul inițierii proiectului de îmbunătățire și obiectivele pe care este menit să le îndeplinească.

O altă funcție importantă a declarației de problemă este de a fi utilizată ca dispozitiv de comunicație. O declarație de problemă ajută la obținerea buy-in-ului de la cei implicați în proiect. Înainte de începerea proiectului, părțile interesate verifică problema, iar obiectivele sunt descrise cu exactitate în declarația problemei. După primirea acestei aprobări, echipa de proiect o revizuiește pentru a se asigura că toată lumea înțelege problema la îndemână și ce încearcă să realizeze. Acest lucru ajută, de asemenea, la definirea scopului proiectului , care menține proiectul concentrat asupra obiectivului general.

Declarația de problemă este menționată pe tot parcursul proiectului pentru a stabili concentrarea în cadrul echipei de proiect și a verifica dacă acestea rămân pe drumul cel bun. La sfârșitul proiectului, acesta este revizuit pentru a confirma că soluția implementată rezolvă într-adevăr problema. O declarație de problemă bine definită poate ajuta, de asemenea, la efectuarea analizei cauzei principale pentru a înțelege de ce a apărut problema și pentru a se asigura că pot fi luate măsuri pentru a preveni apariția acesteia în viitor.

Este important să rețineți că afirmația problemei nu definește soluția sau metodele de soluționare. Afirmația problemei recunoaște pur și simplu decalajul dintre starea problemei și obiectivul. Se poate spune că „o problemă bine enunțată este pe jumătate rezolvată”. Cu toate acestea, există adesea mai multe soluții viabile la o problemă. Numai după ce declarația de problemă este scrisă și convenită, soluția (soluțiile) trebuie discutată (e) și se determină cursul rezultat.

Definirea problemei

Înainte ca declarația de problemă să poată fi elaborată, problema trebuie definită. Este natura umană să dorească să înceapă să lucreze la o soluție cât mai curând posibil și neglijând definiția adevăratei probleme care trebuie rezolvată. Cu toate acestea, o problemă slab definită crește riscul implementării unei soluții care nu îndeplinește pe deplin rezultatele așteptate. O problemă nu poate fi rezolvată dacă nu este înțeleasă complet.

Procesul de definire a problemei este adesea un efort de grup. Începe cu întâlnirea cu părțile interesate, clienții și / sau utilizatorii afectați de problemă (dacă este posibil) și învățarea despre punctele lor de durere. Întrucât oamenii se luptă adesea cu comunicarea eficientă a problemelor lor, în special cuiva în afara procesului, este util să puneți o serie de întrebări „de ce” până când se identifică raționamentul de bază. Această metodă, cunoscută sub numele de „ 5 De ce ”, ajută la aprofundarea problemei esențiale, deoarece multe dintre frustrările experimentate ar putea fi simple simptome ale problemei reale. Punerea acestor întrebări suplimentare, precum și parafrazarea a ceea ce a spus părțile interesate demonstrează un grad de empatie și înțelegere a problemei.

Informațiile colectate din aceste interviuri inițiale sunt doar o parte a analizei problemei. De multe ori problema se extinde la mai multe domenii sau funcții de care părțile interesate, clienții și utilizatorii nu sunt conștienți. De asemenea, pot fi familiarizați cu ceea ce se întâmplă la suprafață, dar nu neapărat cauza care stă la baza lor. Prin urmare, este la fel de esențial să adunați cunoștințe, informații și informații de la membrii echipei de proiect și experți în materie cu privire la problemă. Materialele de cercetare suplimentare, inclusiv instrucțiuni de lucru, manuale de utilizare, specificații ale produselor, diagrame ale fluxului de lucru și planurile anterioare ale proiectului pot fi, de asemenea, necesare consultării. La fel ca majoritatea celorlalte etape ale proiectului de îmbunătățire a procesului, definirea problemei este adesea iterativă, deoarece pot fi necesare mai multe runde de discuții pentru a obține o imagine completă.

Odată ce problema este înțeleasă și circumstanțele care au condus la inițierea proiectului sunt clare, este timpul să scrieți declarația problemei.

Scrierea declarației problemei

Declarația de problemă va fi utilizată pentru a obține sprijinul proiectului și aprobarea părților interesate. Ca atare, trebuie să fie orientat spre acțiune. Mai important, declarația problemei trebuie scrisă în mod clar și precis pentru a oferi rezultate reușite. O declarație de problemă prost elaborată sau incorectă va duce la o soluție defectuoasă, precum și la pierderea de timp, bani și resurse.

Există mai multe elemente de bază care pot fi încorporate în fiecare declarație de problemă pentru a reduce riscul eșecului proiectului. În primul rând, declarația de problemă trebuie să se concentreze asupra utilizatorului final . O greșeală obișnuită se concentrează pe „cum” va fi rezolvată o problemă, mai degrabă decât pe decalajul actual. În al doilea rând, afirmația problemei nu ar trebui să fie prea largă. Un avantaj al utilizării abordării „5 De ce” este că evită simplitatea excesivă, oferind detaliile necesare pentru înțelegerea problemei și dezvoltarea unei soluții adecvate. În cele din urmă, afirmația problemei nu ar trebui să fie prea îngustă. Soluția-prejudecată înăbușe creativitatea care apare în timp ce brainstorming o soluție, care poate duce la o experiență mai puțin decât optimă pentru utilizator.

Este util să proiectați și să urmați un anumit format atunci când scrieți o declarație de problemă. Deși există mai multe opțiuni pentru a face acest lucru, următorul este un șablon simplu și direct folosit adesea în Analiza afacerii pentru a menține accentul pe definirea problemei.

  1. IDEAL: Această secțiune este utilizată pentru a descrie starea dorită sau „a fi” a procesului sau a produsului. Identifică obiectivele părților interesate și ale clienților, precum și ajută la definirea domeniului de aplicare. În general, această secțiune ar trebui să ilustreze cum ar arăta mediul așteptat odată ce soluția este implementată.
  2. REALITATE: Această secțiune este utilizată pentru a descrie starea curentă sau „așa cum este” a procesului sau a produsului. Acesta explică punctele de durere exprimate de părțile interesate și clienți. De asemenea, ar trebui să includă cunoștințele și expertiza echipei de proiect și a experților în materie furnizați în timpul analizei problemelor.
  3. CONSECINȚE: Această secțiune este utilizată pentru a descrie impactul asupra afacerii dacă problema nu este rezolvată sau îmbunătățită. Aceasta include costurile asociate cu pierderea de bani, timp, productivitate, avantaj competitiv, etc. Amploarea acestor efecte va ajuta, de asemenea, la determinarea priorității proiectului.
  4. PROPUNERE: Această secțiune este utilizată pentru a descrie soluții potențiale. Odată ce secțiunile de ideal, realitate și consecințe au fost finalizate, înțelese și aprobate, echipa de proiect poate începe să ofere opțiuni pentru rezolvarea problemei. Poate include, de asemenea, sugestii ale părților interesate și ale clienților, deși vor fi necesare discuții și cercetări suplimentare înainte de a putea fi determinat un anumit curs de acțiune.

Urmarea acestui format va avea ca rezultat un document viabil care poate fi utilizat de toate părțile pentru a înțelege problema și a obține cerințe care vor duce la o soluție câștigătoare.

Exemplu

Afirmațiile problemei pot varia în lungime, în funcție de complexitatea problemei. Următorul este un exemplu de declarație de problemă simplă pentru crearea unei capacități Single Sign On:

IDEAL :

În mod ideal, utilizatorii noștri ar putea să se conecteze la laptopurile lor și apoi să aibă automat acces la toate aplicațiile pe care trebuie să le folosească.

REALITATE:

În realitate, folosim cel puțin trei aplicații în fiecare zi pentru a ne îndeplini munca. Fiecare aplicație este protejată de o parolă cu cerințe diferite pentru numele de utilizator și lungimea parolei. Parolele expiră, de asemenea, în momente diferite.

CONSECINȚE :

  • Utilizatorii pierd aproximativ 2 minute pe zi conectându-se la mai multe aplicații (Să luăm dacă există 500 de utilizatori, apoi 500 de utilizatori * 2 minute pe zi = 1000 de minute de productivitate pierdută; 1000 de minute = 16,67 ore pe zi * 75 USD / oră = 1250 USD pe zi) .
  • Helpdesk rezolvă aproximativ 6000 de apeluri pe an pentru a reseta parolele uitate și a debloca conturile.
  • Pericol de securitate, deoarece utilizatorii vor continua să scrie nume de utilizator și parole pe note lipicioase pe birourile lor.

PROPUNERE

Aveți o colaborare între S / W, administrarea rețelei și părțile interesate de afaceri pentru a evalua soluțiile potențiale pentru o capacitate de conectare unică.

Referințe

  1. ^ a b Kush, Max (iunie 2015). „Problema declarației”. Progres în calitate . 48 (6).
  2. ^ a b c Annamalai, Nagappan; Kamaruddin, Shahrul; Azid, Ishak Abdul; Yeoh, TS (septembrie 2013). „Importanța declarației de problemă în rezolvarea problemelor din industrie”. Mecanică și materiale aplicate . Zurich. 421 : 857–863. doi : 10.4028 / www.scientific.net / AMM.421.857 . S2CID  60791623 .
  3. ^ a b c Gygi, Craig; DeCarlo, Neil; Williams, Bruce (2015). Șase sigme pentru manechine . Hoboken, NJ: John Wiley & Sons. pp. 76-78.
  4. ^ a b Lindstrom, Chris (24-04-2011). "Cum se scrie o declarație de problemă" . www.ceptara.com . Adus 10-04-2018 .
  5. ^ a b Perry, Randy; Bacon, David (2010). Comercializarea produselor excelente cu design pentru Six Sigma . Prentice Hall. p. 18.
  6. ^ a b Shaffer, Deb (2017-07-12). "Cum se scrie o declarație de problemă" . Manager ProProject . Adus 10-04-2018 .
  7. ^ a b Shaffer, David (21.12.2015). „Gătirea succesului în analiza afacerii” . BA Times . Adus 10-04-2018 .
  8. ^ a b c Widen, Steven (02.04.2018). „Faceți acești pași pentru a vă defini problema UI / UX și pentru a evita modificările întâmplătoare” . Forbes . Adus 10-04-2018 .