Problemstilling - Problem statement
En problemstilling er en kortfattet beskrivelse av et problem som skal behandles eller en tilstand som skal forbedres. Den identifiserer gapet mellom nåværende (problem) tilstand og ønsket (mål) tilstand for en prosess eller et produkt. Med fokus på fakta, bør problemformuleringen være utformet for å adressere Five Ws . Den første betingelsen for å løse et problem er å forstå problemet, som kan gjøres ved hjelp av en problemformulering.
Problemstillinger er mye brukt av de fleste bedrifter og organisasjoner til å utføre prosessforbedringsprosjekter. En enkel og veldefinert problemstilling vil bli brukt av prosjektgruppen for å forstå problemet og arbeide for å utvikle en løsning. Det vil også gi ledelsen spesifikk innsikt i problemet slik at de kan ta passende prosjektgodkjennende beslutninger. Som sådan er det avgjørende at problemformuleringen er klar og entydig ..
Hensikt
Hovedformålet med problemformuleringen er å identifisere og forklare problemet. Dette inkluderer å beskrive det eksisterende miljøet, hvor problemet oppstår, og hvilken innvirkning det har på brukere, økonomi og tilleggsaktiviteter. I tillegg brukes problemformuleringen til å forklare hvordan det forventede miljøet ser ut. Å definere ønsket tilstand gir en overordnet visjon for prosessen eller produktet. Det tydeliggjør formålet med å starte forbedringsprosjektet og målene det er ment å nå.
En annen viktig funksjon i problemformuleringen er å brukes som kommunikasjonsenhet. En problemstilling hjelper deg med å skaffe innkjøp fra de som er involvert i prosjektet. Før prosjektet starter, bekrefter interessentene problemet og målene er nøyaktig beskrevet i problemformuleringen. Når denne godkjenningen er mottatt, gjennomgår prosjektgruppen den for å sikre at alle forstår problemet og hva de prøver å oppnå. Dette hjelper også med å definere prosjektets omfang , noe som holder prosjektet konsentrert om det overordnede målet.
Problemet er referert gjennom hele prosjektet for å etablere fokus i prosjektgruppen og bekrefte at de holder seg på sporet. På slutten av prosjektet blir det revidert for å bekrefte at den implementerte løsningen faktisk løser problemet. En veldefinert problemformulering kan også hjelpe deg med å utføre rotårsaksanalyse for å forstå hvorfor problemet oppsto og sikre at det kan iverksettes tiltak for å forhindre at det skjer i fremtiden.
Det er viktig å merke seg at problemformuleringen ikke definerer løsningen eller metodene for å nå løsningen. Problemformuleringen gjenkjenner ganske enkelt gapet mellom problemet og måltilstandene. Det kan sies at "et godt angitt problem er halvt løst". Imidlertid er det ofte flere, levedyktige løsninger på et problem. Først etter at problemformuleringen er skrevet og avtalt, bør løsningen / diskusjonene diskuteres og den resulterende handlingsplanen bestemmes.
Definere problemet
Før problemstillingen kan utformes, må problemet defineres. Det er menneskelig natur å ønske å begynne å jobbe med en løsning så snart som mulig og ignorere definisjonen av det sanne problemet som skal løses. Et dårlig definert problem øker imidlertid risikoen for å implementere en løsning som ikke fullt ut oppfyller de forventede resultatene. Et problem kan ikke løses hvis det ikke er fullstendig forstått.
Prosessen med å definere problemet er ofte en gruppeinnsats. Det starter med å møte interessenter, kunder og/eller brukere som er berørt av problemet (hvis mulig) og lære om deres smertepunkter. Siden mennesker ofte sliter med å kommunisere problemene sine effektivt, spesielt til noen utenfor prosessen, er det nyttig å stille en rekke "hvorfor" -spørsmål til den underliggende begrunnelsen er identifisert. Denne metoden, kjent som " 5 Why's ", hjelper til med å bore ned til kjerneproblemet, ettersom mange av de erfarne frustrasjonene bare kan være symptomer på det faktiske problemet. Å stille disse tilleggsspørsmålene samt parafrasere det interessenten hadde sagt, viser en viss empati og forståelse for problemet.
Informasjonen som er samlet inn fra disse første intervjuene er bare en del av problemanalysen. Mange ganger strekker problemet seg til flere områder eller funksjoner som interessentene, kundene og brukerne ikke er klar over. De kan også være kjent med det som skjer på overflaten, men ikke nødvendigvis den underliggende årsaken. Derfor er det like viktig å samle kunnskap, informasjon og innsikt fra prosjektgruppemedlemmer og fageksperter om problemet. Ytterligere forskningsmateriell, inkludert arbeidsinstruksjoner, brukermanualer, produktspesifikasjoner, arbeidsflytdiagrammer og tidligere prosjektplaner kan også være nødvendig å konsultere. Som de fleste andre stadier i prosessforbedringsprosjektet, er definisjon av problemet ofte iterativ, da det kan være nødvendig med flere diskusjonsrunder for å få et fullstendig bilde.
Når problemet er forstått og omstendighetene som driver prosjektstart er klare, er det på tide å skrive problemformuleringen.
Skriver problemstillingen
Problemstillingen vil bli brukt for å få prosjektstøtte og godkjenning fra interessenter. Som sådan må den være handlingsorientert. Enda viktigere er at problemformuleringen må skrives tydelig og nøyaktig for å gi vellykkede resultater. En dårlig utformet eller feil problemstilling vil føre til en feilaktig løsning, samt bortkastet tid, penger og ressurser.
Det er flere grunnleggende elementer som kan bygges inn i hver problemstilling for å redusere risikoen for prosjektfeil. Først må problemformuleringen fokusere på sluttbrukeren . En vanlig feil er å fokusere på "hvordan" et problem vil bli løst i stedet for det nåværende gapet. For det andre bør problemstillingen ikke være for bred. En fordel ved å bruke "5 Why's" -tilnærmingen er at den unngår for enkelhet ved å gi detaljene som er nødvendige for å forstå problemet og utvikle en passende løsning. Til slutt bør problemstillingen ikke være for smal. Løsnings-skjevhet kveler kreativiteten som oppstår mens du brainstormer en løsning, noe som kan resultere i mindre enn optimal opplevelse for brukeren.
Det er nyttig å designe og følge et bestemt format når du skriver en problemstilling. Selv om det er flere alternativer for å gjøre dette, er følgende en enkel og grei mal som ofte brukes i Business Analysis for å opprettholde fokus på å definere problemet.
- IDEAL: Denne delen brukes til å beskrive ønsket eller "å være" tilstand for prosessen eller produktet. Den identifiserer målene til interessentene og kundene, samt hjelper til med å definere omfang. I det store og hele bør denne delen illustrere hvordan det forventede miljøet ville se ut når løsningen er implementert.
- REALITET: Denne delen brukes til å beskrive den nåværende eller "som den er" tilstanden til prosessen eller produktet. Det forklarer smertepunkter uttrykt av interessenter og kunder. Den bør også inneholde innsikt og ekspertise fra prosjektgruppen og fageksperter som er gitt under problemanalyse.
- KONSEKVENSER: Denne delen brukes til å beskrive virkningene på virksomheten hvis problemet ikke løses eller forbedres. Dette inkluderer kostnader forbundet med tap av penger, tid, produktivitet, konkurransefortrinn og så videre. Omfanget av disse effektene vil også bidra til å bestemme prosjektets prioritet.
- FORSLAG: Denne delen brukes til å beskrive potensielle løsninger. Når idealene, virkeligheten og konsekvensene er fullført, forstått og godkjent, kan prosjektgruppen begynne å tilby alternativer for å løse problemet. Det kan også inneholde forslag fra interessenter og kunder, selv om ytterligere diskusjoner og forskning vil være nødvendig før et bestemt handlingsforløp kan bestemmes.
Å følge dette formatet vil resultere i et brukbart dokument som kan brukes av alle parter for å forstå problemet og fremkalle krav som vil føre til en vinnende løsning.
Eksempel
Problemoppgaver kan variere i lengde, avhengig av kompleksiteten i problemet. Følgende er et eksempel på en enkel problemstilling for oppretting av en enkelt påloggingskapasitet:
IDEAL:
Ideelt sett ville brukerne våre kunne logge på sine bærbare datamaskiner og deretter automatisk ha tilgang til alle programmene de trenger å bruke.
REALITET:
I virkeligheten bruker vi minst tre applikasjoner hver dag for å utføre arbeidet vårt. Hver applikasjon er beskyttet av et passord med forskjellige krav til brukernavn og passordlengde. Passord utløper også på forskjellige tidspunkter.
KONSEKVENSER:
- Brukere kaster bort omtrent 2 minutter om dagen ved å logge på flere applikasjoner (La oss ta hvis det er 500 brukere, deretter 500 brukere * 2 minutter per dag = 1000 minutter i tapt produktivitet; 1000 minutter = 16,67 timer per dag * $ 75/time = $ 1250 per dag) .
- Helpdesk løser omtrent 6000 samtaler per år for å tilbakestille glemte passord og låse opp kontoer.
- Sikkerhetsrisiko ettersom brukerne vil fortsette å skrive brukernavn og passord på notater på skrivebordene.
FORSLAG
Ha et S/W Dev, Network Administration og forretningsinteressentersamarbeid for å evaluere potensielle løsninger for Single Sign On -evne.
Referanser
- ^ a b Kush, Max (juni 2015). "Erklæringsproblemet". Kvalitetsfremgang . 48 (6).
- ^ a b c Annamalai, Nagappan; Kamaruddin, Shahrul; Azid, Ishak Abdul; Yeoh, TS (september 2013). "Viktigheten av problemformulering for å løse industriproblemer". Anvendt mekanikk og materialer . Zürich. 421 : 857–863. doi : 10.4028/www.scientific.net/AMM.421.857 . S2CID 60791623 .
- ^ a b c Gygi, Craig; DeCarlo, Neil; Williams, Bruce (2015). Seks sigma for dummies . Hoboken, NJ: John Wiley & Sons. s. 76–78.
- ^ a b Lindstrom, Chris (2011-04-24). "Hvordan skrive en problemstilling" . www.ceptara.com . Hentet 2018-04-10 .
- ^ a b Perry, Randy; Bacon, David (2010). Kommersialiserer flotte produkter med design for Six Sigma . Prentice Hall. s. 18.
- ^ a b Shaffer, Deb (2017-07-12). "Hvordan skrive en problemstilling" . ProProject Manager . Hentet 2018-04-10 .
- ^ a b Shaffer, David (2015-12-21). "Suksess for matlaging av forretningsanalyse" . BA Times . Hentet 2018-04-10 .
- ^ a b c Widen, Steven (2018-04-02). "Ta disse trinnene for å definere ditt UI/UX -problem og unngå tilfeldige endringer" . Forbes . Hentet 2018-04-10 .
