Redigerer Problembeskrivelse

En '''problembeskrivelse''' eller '''problemformulering''' er en konsis beskrivelse av et [[problem]] som skal [[Problemløsning|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 [[Prosessarkitektur|prosess]] eller et [[Produktutvikling|produkt]]. En faktabasert tilnærming kan ta utgangspunkt i bruk av [[Spørreteknikk|spørreteknikker]] som for eksempel svarer på de fem [[Spørreord|spørreordene]] "hvem, hva, når, hvor, hvorfor" (på engelsk kjent som ''[[De 5 H-ene|Five Ws]]''). Det første steget for å løse et problem er å forstå problemet, hvilket kan gjøres ved hjelp av en problembeskrivelse.<ref name=":0">{{Cite journal|last=Kush|first=Max|date=juni 2015|title=The Statement Problem|journal=Quality Progress|volume=48|issue=6}}</ref>

Problembeskrivelser er i utstrakt bruk i [[Næringsliv|næringslivet]] og [[Organisasjon|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 [[Ledelse|ledelsen]] spesifikk innsikt i problemet slik at de kan gjøre passende [[Prosjektstyring|prosjekt-godkjennende]] avgjørelser. Det er derfor kritisk at en problembeskrivelse er tydelig og utvetydig.<ref name="Annamalai"/>

== 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 [[Brukeropplevelse|brukere]], [[Kostnad|kostnader]] og tilhørende aktiviteter.<ref name="six-sigma-dummies">{{Kilde bok|tittel=Six sigma for dummies|etternavn=Gygi|fornavn=Craig|etternavn2=DeCarlo|fornavn2=Neil|etternavn3=Williams|fornavn3=Bruce|utgiver=John Wiley & Sons|utgivelsessted=Hoboken, NJ}}</ref> I tillegg brukes problembeskrivelsen også for å forklare hvordan det forventede [[Testmiljø|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å.<ref name="lindstrom">{{Kilde www|url=http://www.ceptara.com/blog/how-to-write-problem-statement|tittel=How To Write A Problem Statement|besøksdato=2018-04-10|fornavn=Chris|etternavn=Lindstrom|arkiv-dato=2020-08-05|arkiv-url=https://web.archive.org/web/20200805155222/http://www.ceptara.com/blog/how-to-write-problem-statement|url-status=yes}}</ref>

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.<ref name="six-sigma-dummies"/> Før prosjektet starter verifiserer [[Interessent|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 [[Prosjektomfang|prosjektomfanget]], hvilket sikrer at prosjektet fokuserer på det overordnede målet.<ref name=":4">{{Kilde bok|tittel=Commercializing Great Products with Design for [[Six Sigma]]|etternavn=Perry|fornavn=Randy|etternavn2=Bacon|fornavn2=David|utgiver=Prentice Hall}}</ref>

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.<ref name="Annamalai">{{Cite journal|last=Annamalai|first=Nagappan|date=September 2013|title=Importance of Problem Statement in Solving Industry Problems}}</ref>

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".<ref name="lindstrom"/> 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.<ref name="shaffer-pm">{{Kilde avis|url=https://www.proprojectmanager.com/problem-statement/|tittel=How to Write a Problem Statement|etternavn=Shaffer|fornavn=Deb|dato=2017-07-12|avis=ProProject Manager|besøksdato=2018-04-10|språk=en-US}}</ref>

== 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.<ref name="shaffer-ba">{{Kilde www|url=https://www.batimes.com/articles/cooking-up-business-analysis-success.html|tittel=Cooking Up Business Analysis Success|besøksdato=2018-04-10|fornavn=David|etternavn=Shaffer}}</ref>

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'').<ref name=":7">{{Kilde avis|url=https://www.forbes.com/sites/forbesagencycouncil/2018/04/02/take-these-steps-to-define-your-uiux-problem-and-avoid-haphazard-changes/#22f21cda7c6c|tittel=Take These Steps To Define Your UI/UX Problem And Avoid Haphazard Changes|etternavn=Widen|fornavn=Steven|dato=2018-04-02|avis=Forbes|besøksdato=2018-04-10|språk=en}}</ref> 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. "[[5-hvorfor|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 [[Symptom|symptomer]] på det faktiske problemet.<ref name="shaffer-pm" /> Ved å spørre disse tilleggsspørsmålene samt [[Parafrasering|parafrasere]] (omarbeide) hva interessenten har sagt demonstrerer man en grad av empati og forståelse av problemet.<ref name=":4" />

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 [[Fagekspert|fageksperter]] om problemet.<ref name=":7" /> 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 [[Prosessforbedring|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.<ref name="Annamalai" /> 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.<ref name=":0" />

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 [[Idemyldring|idemyldrer]] for å finne løsninger, hvilket kan resultere i sub-optimale opplevelser for brukeren.<ref name=":7" />

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 [[Forretningsanalyse|forretningsanalytikere]] for å holde fokuset på definere et problem:

# '''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.
# '''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.
# '''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.
# '''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.<ref name="shaffer-ba"/>

Etterfølgelse av dette formatet vil resultere i et gjennomførbart dokument som kan brukes av alle parter til å forstå problemet og ytre [[Kravspesifikasjon|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.

== Se også ==
* [[Problemløsning]]

== Referanser ==
<references />

== Eksterne lenker ==
* [https://www.prosjektveiviseren.no/hva-er-prosjektveiviseren/konsept/hva-er-problemet-og-hva-vil-vi-oppna Hva er problemet, og hva vil vi oppnå? | Digitaliseringsdirektoratet] {{Wayback|url=https://www.prosjektveiviseren.no/hva-er-prosjektveiviseren/konsept/hva-er-problemet-og-hva-vil-vi-oppna |date=20230110100645 }}
{{Autoritetsdata}}

[[Kategori:Problemløsning]]