Problembeskrivelse

En problembeskrivelse eller problemformulering er en konsis beskrivelse av et problem som skal tas tak i eller en tilstand som skal forbedres. Den identifiserer forskjellen mellom nåværende tilstand (problemet) og den ønskede tilstanden (målet) til en prosess eller et produkt. En faktabasert tilnærming kan ta utgangspunkt i bruk av spørreteknikker som for eksempel svarer på de fem spørreordene "hvem, hva, når, hvor, hvorfor" (på engelsk kjent som Five Ws). Det første steget for å løse et problem er å forstå problemet, hvilket kan gjøres ved hjelp av en problembeskrivelse.

Problembeskrivelser er i utstrakt bruk i næringslivet og organisasjoner for å utføre prosessforbedring. En enkel og veldefinert problembeskrivelse brukes av en prosjektgruppe for å forstå problemet og arbeide mot å utvikle en løsning. Den vil også gi ledelsen spesifikk innsikt i problemet slik at de kan gjøre passende prosjekt-godkjennende avgjørelser. Det er derfor kritisk at en problembeskrivelse er tydelig og utvetydig.

Formål

Hovedformålet med problembeskrivelsen er å identifisere og forklare problemet. Dette inkluderer å beskrive det eksisterende miljøet hvor problemet oppstår, og hvilke konsekvenser det har for brukere, kostnader og tilhørende aktiviteter. I tillegg brukes problembeskrivelsen også for å forklare hvordan det forventede miljøet ser ut. Å definere den ønskede tilstanden gir en overordnet visjon for prosessen eller produktet. Det tydeliggjør formålet med å initiere forbedringsprosjektet og målene som det er ment å oppnå.

En annen viktig funksjon til problembeskrivelsen er at den kan brukes til kommunikasjon. En problembeskrivelse hjelper på å få tilslutning fra de som er involvert i prosjektet. Før prosjektet starter verifiserer interessentene problemet, og at målene er presist beskrevet i problembeskrivelsen. Når godkjenningen er mottatt går prosjektlaget gjennom den for å sikre at alle forstår problemet og hva de prøver å oppnå. Dette bidrar også til å definere prosjektomfanget, hvilket sikrer at prosjektet fokuserer på det overordnede målet.

Problembeskrivelsen blir referert til gjennom prosjeket for å etablere fokus i prosjektlaget og verifisere at det holder seg på rett spor. På slutten av prosjektet blir den gått gjennom på nytt for å sikre at den implementerte løsningen faktisk løser problemet. En veldefinert problembeskrivelse kan også hjelpe med å gjennomføre en rotårsaksanalyse for å forstå hvorfor problemet oppstod og gjøre tiltak for å forebygge at det skjer i fremtiden.

Det er viktig å merke seg at problembeskrivelsen ikke definerer løsningen eller metodene for å komme til en løsning. Problembeskrivelsen skal bare beskrive forskjellen mellom problemet og den ønskede sluttilstanden. Et ordtak sier at "et velformulert problem er halvvegs løst". Imidlertid er det ofte flere mulige løsninger på et problem. Bare når en problembeskrivelse har blitt skrevet og det er enighet om den bør løsninger diskuteres og resulterende handlingsforløp bestemmes.

Definering av problemet

Før problembeskrivelsen kan formuleres må problemet være definert. Det ligger i den menneskelige natur å begynne å arbeide med å løse problemet så fort som mulig og neglisjere å definere det virkelige problemet som må løses. Imidlertid vil et dårlig definert problem øke risikoen for å implementere en løsning som ikke gir de forventede resultatene. Et problem kan ikke løses dersom det ikke er helt forstått.

Prosessen med å definere et problem er ofte en gruppeinnsats. Den starter med et møte med interessentene, kundene og/eller brukerne som påvirkes av problemet (hvis mulig) og for å lære om hvilke problemer de opplever (på engelsk ofte kalt pain points). Ettersom folk ofte sliter med å effektivt kommunisere sine utfordringer, særlig overfor noen som kommer fra utenfra prosessen, er det hjelpsomt å stille en rekke spørsmål om "hvorfor" inntil den underliggende årsaken er identifisert. "De fem hvorfor" er en slik metode (på engelsk kjent som five whys, ikke til å forveksles med five Ws), som kan være et verktøy for å komme til roten av det underliggende problemet siden mange erfarte frustrasjoner snarere kan være symptomer på det faktiske problemet. Ved å spørre disse tilleggsspørsmålene samt parafrasere (omarbeide) hva interessenten har sagt demonstrerer man en grad av empati og forståelse av problemet.

Informasjonen samlet fra disse inngående intervjuene er bare en del av problemanalysen. Ofte strekker problemet seg over flere områder eller funksjoner som interessentene, kundene eller brukerne ikke kjenner til. De kan også være kjent med hva som skjer på overflaten, men ikke nødvendigvis den underliggende årsaken. Derfor er det vel så essensielt å samle kunnskap, informasjon og innsikt fra prosjektmedlemmer og fageksperter om problemet. Det kan også være nødvendig å se gjennom ytterligere forskningsmateriale, arbeidsinstruksjoner, brukermanualer, produktspesifikasjoner, arbeidsflytdiagrammer og tidligere prosjektplaner. Som for de fleste andre steg i prosessforbedrings-prosjekter er det å definere problemet ofte interaktivt ettersom flere runder med diskusjon trengs for å få oversikt.

Når problemet har blitt forstått og omstendighetene som driver prosjekt-initieringen er tydelige er det tid for å skrive ned problembeskrivelsen.

Skriving

Problembeskrivelsen brukes for å få prosjektstøtte og godkjenning fra interessentene, og bør derfor være aksjonsorientert. Det er viktig at problembeskrivelsen er skrevet tydelig og presist for å kunne gi vellykkede resultat. En dårlig skrevet eller ukorrekt problembeskrivelse vil føre til en feilaktig løsning, samt bortkastet tid, penger og ressurser.

Det er flere grunnleggende elementer som kan bygges inn i enhver problembeskrivelse for å minimere risiko for at et prosjekt feiler. For det første må problembeskrivelsen fokusere på sluttbrukeren. En vanlig feil er å fokusere på hvordan et problem vil bli løst i stedet for det nåværende behovet. For det andre bør en problembeskrivelse ikke være for bred. En fordel med å bruke "de fem hvorfor"-tilnærmingen er at den unngår å overforenkle ved å gi detaljer som trengs for å forstå problemet og utvikle en hensiktsmessig løsning. Til slutt bør problembeskrivelsen ikke være for smal. Løsnings-bias dreper kreativiteten som oppstår når man idemyldrer for å finne løsninger, hvilket kan resultere i sub-optimale opplevelser for brukeren.

Det er nyttig å utforme og følge et spesifikt format når man skriver en problembeskrivelse. Selv om det finnes flere måter å gjøre det, er det følgende en enkel og rett frem mal som ofte brukes av forretningsanalytikere for å holde fokuset på definere et problem:

1. Idealet: Beskriver ønsket tilstand for prosessen eller produktet. Den identifiserer målene til interessentene og kundene, samt hjelper til med å definere omfanget. I det store og hele skal denne delen illustrere hvordan det forventede miljøet vil se ut når løsningen er implementert.
2. Virkelighet: Beskriver den nåværende tilstanden til prosessen eller produktet. Den forklarer hvilke problemer interessenter og kunder opplever. Man bør også ha med innsikt og ekspertise spilt inn fra prosjektlaget og fageksperter under problemanalysen.
3. Konsekvenser: Beskriver konsekvensene for virksomheten dersom problemet ikke løses eller forbedres. Dette inkluderer kostnader forbundet med tap av penger, tid, produktivitet, konkurransefortrinn, og så videre. Størrelsen på disse effektene vil også bidra til å bestemme prioriteringen av prosjektet.
4. Forslag: Beskriver potensielle løsninger. Når delene ideal, virkelighet og konsekvenser er fullført, forstått og godkjente, kan prosjektgruppen begynne å tilby alternativer for å løse problemet. Det kan også inkludere forslag fra interessenter og kunder, selv om ytterligere diskusjoner og undersøkelser vil være nødvendige før et spesifikt handlingsforløp kan bestemmes.

Etterfølgelse av dette formatet vil resultere i et gjennomførbart dokument som kan brukes av alle parter til å forstå problemet og ytre krav som vil føre til en vinnende løsning.

Eksempel

Problemstillinger kan variere i lengde avhengig av problemets kompleksitet. Følgende er et eksempel på en enkel problemstilling for å implementere enkeltpålogging:

Idealet:

• Ideelt sett vil brukerne kunne logge på sine bærbare datamaskiner og deretter automatisk ha tilgang til alle programmene de trenger å bruke.

Virkelighet:

• I virkeligheten brukes minst tre applikasjoner hver dag for å utføre arbeidet. Hver applikasjon er beskyttet av et passord med forskjellige krav til brukernavn og passordlengde. Passord utløper også til forskjellige tider.

Konsekvenser:

• Brukere kaster bort omtrent to minutter per dag på å logge inn på flere applikasjoner (hvis det er 500 brukere vil man få: 500 brukere * 2 minutter per dag = 1000 minutter i tapt produktivitet; 1000 minutter = 16,67 timer per dag * 750 kr/time = 12 500 kr per dag).
• Kundestøtte løser omtrent 6000 oppdrag per år for å tilbakestille glemte passord og låse opp kontoer.
• Sikkerhetsrisiko ettersom brukere vil fortsette å skrive brukernavn og passord på klistrelapper på pultene sine

Forslag:

• Ha en programvareutvikler som samarbeider med nettverksadministrasjonen og forretningsinteressenter for å evaluere potensielle løsninger for en enkeltpålogging.

Eksterne lenker

• Hva er problemet, og hva vil vi oppnå? | Digitaliseringsdirektoratet Arkivert 10. januar 2023 hos Wayback Machine.