Problemmeddelande - Problem statement

Ett problemmeddelande är en kortfattad beskrivning av ett problem som ska åtgärdas eller ett villkor som ska förbättras. Det identifierar klyftan mellan nuvarande (problem) tillstånd och önskat (mål) tillstånd för en process eller produkt. Med fokus på fakta, bör problemmeddelandet utformas för att hantera de fem W: erna . Det första villkoret för att lösa ett problem är att förstå problemet, vilket kan göras med hjälp av ett problemmeddelande.

Problem uttalanden i stor utsträckning används av de flesta företag och organisationer för att utföra processförbättring projekt. Ett enkelt och väldefinierat problemmeddelande kommer att användas av projektteamet för att förstå problemet och arbeta för att utveckla en lösning. Det kommer också att ge ledningen specifika insikter om problemet så att de kan fatta lämpliga projektgodkännande beslut. Som sådan är det avgörande för att problemmeddelandet ska vara tydligt och entydigt ..

Ändamål

Huvudsyftet med problemmeddelandet ä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 tillhörande aktiviteter. Dessutom används problemmeddelandet för att förklara hur den förväntade miljön ser ut. Att definiera önskat tillstånd ger en övergripande vision för processen eller produkten. Det tydliggör syftet med att initiera förbättringsprojektet och de mål som det är tänkt att uppnå.

En annan viktig funktion i problemmeddelandet är att användas som kommunikationsenhet. Ett problemmeddelande hjälper till att få inköp från de som är involverade i projektet. Innan projektet börjar verifierar intressenterna problemet och målen beskrivs korrekt i problemmeddelandet. När detta godkännande har mottagits granskar projektgruppen det för att säkerställa att alla förstår frågan 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.

Problemanalysen refereras genom hela projektet för att skapa fokus inom projektteamet och verifiera att de håller sig på rätt spår. I slutet av projektet återbesöks det för att bekräfta att den implementerade lösningen verkligen löser problemet. Ett väldefinierat problemmeddelande kan också hjälpa till att utföra grundorsaksanalys för att förstå varför problemet uppstod och se till att åtgärder kan vidtas för att förhindra att det händer i framtiden.

Det är viktigt att notera att problemmeddelandet inte definierar lösningen eller metoderna för att nå lösningen. Problemmeddelandet erkänner helt enkelt klyftan mellan problemet och måltillstånden. Man kan säga att "ett väl uppgivet problem är halvt löst". Men det finns ofta flera, lönsamma lösningar på ett problem. Först efter att problemmeddelandet skrivits och kommit överens om bör lösningen / diskussionerna diskuteras och det resulterande handlingssättet bestämmas.

Definierar problemet

Innan problemmeddelandet kan skapas måste problemet definieras. Det är mänsklig natur att vilja börja arbeta med en lösning så snart som möjligt och försumma definitionen av det sanna 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 påverkas av problemet (om möjligt) och lära sig om deras smärta. 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 är identifierat. Denna metod, känd som " 5 Varför ", hjälper till att gå in på kärnproblemet, eftersom många av de upplevda frustrationerna bara kan vara symptom på det verkliga problemet. Att ställa dessa ytterligare frågor samt parafrasera vad intressenten hade sagt visar en viss empati och förståelse för problemet.

Informationen som samlats in från dessa första 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 kanske också känner till vad som händer på ytan men inte nödvändigtvis den bakomliggande orsaken. Därför är det lika viktigt att samla kunskap, information och insikter från projektgruppens medlemmar 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 steg 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 som driver projektinitieringen är tydliga är det dags att skriva problemmeddelandet.

Skriver problemmeddelandet

Problemmeddelandet 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 problemmeddelandet måste skrivas tydligt och korrekt för att lyckas med resultat. Ett dåligt utformat eller felaktigt problemmeddelande leder till en felaktig lösning, såväl som slösad tid, pengar och resurser.

Det finns flera grundläggande element som kan byggas in i varje problemmeddelande för att minska risken för projektfel. Först måste problemmeddelandet fokusera på slutanvändaren . Ett vanligt misstag är att fokusera på ”hur” ett problem kommer att lösas snarare än det nuvarande gapet. För det andra bör problemmeddelandet inte vara för brett. En fördel med att använda ”5 varförs” -metoden ä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 problemmeddelandet inte vara för smalt. 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 designa och följa ett specifikt format när du skriver ett problemmeddelande. Även om det finns flera alternativ för att göra detta, är följande en enkel och enkel mall som ofta används i affärsanalys för att behålla fokus på att definiera problemet.

1. IDEAL: Det här avsnittet används för att beskriva processens eller produktens önskade eller "vara" tillstånd. Den identifierar intressenternas och kundernas mål samt hjälper till att definiera omfattning. I stort bör detta avsnitt illustrera hur den förväntade miljön skulle se ut när lösningen är implementerad.
2. VERKLIGHET: Detta avsnitt används för att beskriva processens eller produktens nuvarande eller "befintliga" tillstånd. Det förklarar smärtpunkter som uttrycks av intressenter och kunder. Det bör också innehålla insikter och expertis från projektteamet och ämnesexperter som tillhandahålls vid problemanalys.
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 i samband med förlust av pengar, tid, produktivitet, konkurrensfördelar och så vidare. Storleken på dessa effekter hjälper också till att bestämma projektets prioritet.
4. FÖRSLAG: Detta avsnitt används för att beskriva potentiella lösningar. När sektionerna för ideal, verklighet och konsekvenser 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 användbart dokument som kan användas av alla parter för att förstå problemet och framkalla krav som leder till en vinnande lösning.

Exempel

Problemmeddelanden kan variera i längd, beroende på problemets komplexitet. Följande är ett exempel på ett enkelt problemmeddelande för skapandet av en enda inloggningsfunktion:

IDEAL:

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

VERKLIGHET:

I verkligheten använder vi minst tre applikationer varje dag för att utföra vårt arbete. Varje applikation skyddas av ett lösenord med olika krav på användarnamn och lösenordslängd. Lösenord löper också ut vid olika tidpunkter.

KONSEKVENSER:

• Användare slösar bort cirka 2 minuter per dag med att logga in på flera applikationer (Låt oss ta 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 6000 samtal per år för att återställa glömda lösenord och låsa upp konton.
• Säkerhetsrisk eftersom användarna fortsätter att skriva användarnamn och lösenord på klisterlappar på sina skrivbord.

FÖRSLAG

Ha en S/W -enhet, nätverksadministration och affärsintressenter för att utvärdera potentiella lösningar för en Single Sign On -funktion.

Referenser