Problemformulering

En problemformulering är en kortfattad beskrivning av ett problem som ska åtgärdas eller ett tillstånd som ska förbättras. Den identifierar gapet mellan det aktuella (problem)tillståndet och önskat (mål)tillstånd för en process eller produkt. Med fokus på fakta, bör problemformuleringen utformas för att ta itu med de fem Ws . Det första villkoret för att lösa ett problem är att förstå problemet, vilket kan göras genom en problemformulering.

Problembeskrivningar används i stor utsträckning av de flesta företag och organisationer för att genomföra processförbättringsprojekt . En enkel och väldefinierad problembeskrivning kommer att användas av projektgruppen för att förstå problemet och arbeta mot att utveckla en lösning. Det kommer också att ge ledningen specifika insikter om problemet så att de kan fatta lämpliga beslut om projektgodkännande. Som sådan är det avgörande att problemformuleringen är tydlig och entydig.

Syfte

Huvudsyftet med problembeskrivningen är att identifiera och förklara problemet. Detta inkluderar att beskriva den befintliga miljön, var problemet uppstår och vilken inverkan det har på användare, ekonomi och kringaktiviteter. Dessutom används problemformuleringen för att förklara hur den förväntade miljön ser ut. Att definiera det önskade tillståndet ger en övergripande vision för processen eller produkten. Den klargör syftet med att initiera förbättringsprojektet och de mål som det är tänkt att uppnå.

En annan viktig funktion av problemformuleringen är att användas som en kommunikationsenhet. En problemformulering hjälper till att få inköp från de som är involverade i projektet. Innan projektet startar intressenterna problemet och målen beskrivs korrekt i problembeskrivningen. När detta godkännande har tagits emot granskar projektteamet det för att säkerställa att alla förstår problemet och vad de försöker åstadkomma. Detta hjälper också till att definiera projektets omfattning , vilket håller projektet koncentrerat på det övergripande målet.

Problembeskrivningen refereras genom hela projektet för att skapa fokus inom projektgruppen och verifiera att de håller sig på rätt spår. I slutet av projektet granskas det igen för att bekräfta att den implementerade lösningen verkligen löser problemet. En väldefinierad problembeskrivning kan också hjälpa till att utföra rotorsaksanalyser för att förstå varför problemet uppstod och säkerställa att åtgärder kan vidtas för att förhindra att det inträffar i framtiden.

Det är viktigt att notera att problemformuleringen inte definierar lösningen eller metoderna för att nå lösningen. Problemformuleringen erkänner helt enkelt gapet mellan problem- och måltillstånd. Man kan säga att "ett väl uttalat problem är till hälften löst". Men det finns ofta flera hållbara lösningar på ett problem. Först efter att problemformuleringen har skrivits och kommit överens om bör lösningen/lösningarna diskuteras och det resulterande handlingssättet fastställas.

Att definiera problemet

Innan problemformuleringen kan skapas måste problemet definieras. Det ligger i människans natur att vilja börja arbeta på en lösning så snart som möjligt och försumma definitionen av det verkliga problemet som ska lösas. Ett dåligt definierat problem ökar dock risken för att implementera en lösning som inte helt uppfyller de förväntade resultaten. Ett problem kan inte lösas om det inte är helt förstått.

Processen att definiera problemet är ofta en gruppinsats. Det börjar med att träffa intressenter, kunder och/eller användare som berörs av problemet (om möjligt) och lära sig om deras smärtpunkter. Eftersom människor ofta kämpar med att effektivt kommunicera sina problem, särskilt till någon utanför processen, är det bra att ställa en rad "varför"-frågor tills det underliggande resonemanget har identifierats. Den här metoden, känd som de fem varför , hjälper till att gå ner till kärnproblemet eftersom många av de upplevda frustrationerna bara kan vara symptom på det faktiska problemet. Att ställa dessa ytterligare frågor samt att parafrasera vad intressenten hade sagt visar en viss grad av empati och förståelse för problemet.

Informationen som samlas in från dessa inledande intervjuer är bara en del av problemanalysen. Många gånger sträcker sig problemet till flera områden eller funktioner som intressenterna, kunderna och användarna inte är medvetna om. De kan också vara bekanta med vad som händer på ytan men inte nödvändigtvis den bakomliggande orsaken. Därför är det lika viktigt att samla in kunskap, information och insikter från projektteammedlemmar och ämnesexperter om problemet. Ytterligare forskningsmaterial, inklusive arbetsinstruktioner, användarmanualer, produktspecifikationer, arbetsflödesscheman och tidigare projektplaner kan också behöva konsulteras. Liksom de flesta andra stadier i processförbättringsprojektet är definitionen av problemet ofta iterativ eftersom flera diskussionsrundor kan behövas för att få hela bilden.

När problemet är förstått och omständigheterna bakom projektinitieringen är klara är det dags att skriva problemformuleringen.

Skriver problemformuleringen

Problembeskrivningen kommer att användas för att få projektstöd och godkännande från intressenter. Som sådan måste den vara handlingsinriktad. Ännu viktigare är att problembeskrivningen måste skrivas tydligt och korrekt för att kunna leverera framgångsrika resultat. En dåligt utformad eller felaktig problembeskrivning kommer att leda till en felaktig lösning, såväl som slöseri med tid, pengar och resurser.

Det finns flera grundläggande element som kan byggas in i varje problemformulering för att minska risken för projektmisslyckande. För det första måste problemformuleringen fokusera på slutanvändaren . Ett vanligt misstag är att fokusera på hur ett problem ska lösas snarare än det nuvarande gapet. För det andra bör problemformuleringen inte vara för bred. En fördel med att använda tillvägagångssättet med fem varför är att det undviker alltför enkelhet genom att tillhandahålla de detaljer som behövs för att förstå problemet och utveckla en lämplig lösning. Slutligen bör problemformuleringen inte vara för snäv. Solution-bias kväver kreativiteten som uppstår när man brainstormar en lösning, vilket kan resultera i en mindre än optimal upplevelse för användaren.

Det är användbart att utforma och följa ett specifikt format när du skriver en problemformulering. Även om det finns flera alternativ för att göra detta, är följande en enkel och okomplicerad mall som ofta används i affärsanalyser för att behålla fokus på att definiera problemet.

1. Idealiskt: Detta avsnitt används för att beskriva det önskade eller "att vara" tillståndet för processen eller produkten. Den identifierar målen för intressenterna och kunderna samt hjälper till att definiera omfattningen. På det stora hela bör det här avsnittet illustrera hur den förväntade miljön skulle se ut när lösningen är implementerad.
2. Verklighet: Det här avsnittet används för att beskriva processens eller produktens nuvarande eller "befintliga tillstånd". Den förklarar smärtpunkter som uttrycks av intressenter och kunder. Det bör också inkludera insikter och expertis från projektgruppen och ämnesexperter som tillhandahålls under problemanalysen.
3. Konsekvenser: Detta avsnitt används för att beskriva effekterna på verksamheten om problemet inte åtgärdas eller förbättras. Detta inkluderar kostnader förknippade med förlust av pengar, tid, produktivitet, konkurrensfördelar och så vidare. Omfattningen av dessa effekter kommer också att bidra till att bestämma projektets prioritet.
4. Förslag: Detta avsnitt används för att beskriva potentiella lösningar. När ideal-, verklighets- och konsekvensersektionerna har slutförts, förståtts och godkänts kan projektgruppen börja erbjuda alternativ för att lösa problemet. Det kan också innehålla förslag från intressenter och kunder, även om ytterligare diskussioner och forskning kommer att behövas innan ett specifikt tillvägagångssätt kan fastställas.

Att följa detta format kommer att resultera i ett fungerande dokument som kan användas av alla parter för att förstå problemet och framkalla krav som kommer att leda till en vinnande lösning.

Exempel

Problemformuleringar kan variera i längd, beroende på problemets komplexitet. Följande är ett exempel på en enkel problemformulering för att skapa en enkel inloggningsfunktion :

Idealisk :

• Helst skulle användare kunna logga in på sina bärbara datorer och sedan automatiskt ha tillgång till alla applikationer de behöver använda.

Verkligheten :

• I verkligheten används minst tre applikationer varje dag för att utföra arbetet. Varje applikation är skyddad av ett lösenord med olika krav på användarnamn och lösenordslängd. Lösenord upphör också att gälla vid olika tidpunkter.

Konsekvenser :

• Användare slösar bort cirka två minuter per dag på att logga in i flera applikationer (om det finns 500 användare, då 500 användare * 2 minuter per dag = 1000 minuter i förlorad produktivitet; 1000 minuter = 16,67 timmar per dag * $75/timme = $1250 per dag).
• Helpdesk löser cirka 6 000 samtal per år för att återställa glömda lösenord och låsa upp konton.
• Säkerhetsrisk eftersom användare kommer att fortsätta att skriva användarnamn och lösenord på klisterlappar på sina skrivbord

Förslag :

• Ha en mjukvaruutvecklare, nätverksadministration och affärsintressenter i samarbete för att utvärdera potentiella lösningar för en enkel inloggningsförmåga.