I mit sidste blogindlæg argumenterede jeg for, at kravspecifikationen er afgørende for, at et IT projekt får succes. Jeg lovede også, at jeg ville vende tilbage med et indlæg om, hvordan man laver en god kravspecifikation.
I Sopra Steria arbejder vi både med, hvad man kan kalde den klassiske tilgang til kravspecifikationen, og med behovsanalyse som en del af vores Lean NEXT model. I dette blogindlæg vil jeg tage udgangspunkt i den klassiske tilgang suppleret
med min egen erfaring i rollen som forretningsanalytiker, og så kan du se frem til et tredje indlæg, der fokuserer på Sopra Sterias Lean NEXT model.
Kravspecifikationen er et produkt af det fagområde, der hedder forretningsanalyse (Business Analysis). Denne disciplin defineres meget godt og bredt i BABOK Guiden som: ”…the practice of enabling change in an enterprise by defining
needs and recommending solutions that deliver value to stakeholders”. At udarbejde en kravspecifikationen kræver ikke forudgående specifik teknisk kendskab til IT-løsningen eller platformen, der skal implementeres. Det
kræver heller ikke specialiseret forretningsviden om den forretning, hvortil den skal implementeres. Det, der er vigtigt, er en forståelse for og erfaring med de aktiviteter, der skal gennemløbes.
Case
For at gøre guiden håndgribelig – så tager jeg i alle steps udgangspunkt i følgende case:
”Vi skal have digitaliseret og ensartet vores onboarding-proces af nye kunder i forretningen. Denne proces foregår i dag på forskellig vis i de 3 lande, vi opererer i. Processen er manuel, forskellig i hvert land, tager (for) lang tid for kundeservice at håndtere og slutteligt tager det for lang tid for kunderne, fra de søger om at blive kunder, til at de rent faktisk bliver det. Vi har valgt et BPMS (Business Proces Management System) til opgaven”.
Nedenstående 6 steps anbefaler jeg, at du får styr på og beskrevet i en kravspecifikation, inden du påbegynder udviklingen.
1. Kortlæg forretningskravene
I samarbejde med forretningen skal du starte med at definere deres behov og krav. Disse krav svarer på, hvorfor løsningen skal udvikles og definerer, hvad der skal til, for at projektet bliver en succes. Forretningskravene er altid ”high-level” og mål for hele forretningen. Disse krav er styrende for, hvilken løsning du skal vælge, hvilke interessenter du skal inddrage i kravspecifikationen, og så skal de bruges til at styre den løbene prioritering i projektet. Det er dem, der indgår i og udgør business casen for projektet. (Business casen som løbene bør justeres hvis og når kravene ændrer sig igennem projektets forløb). Det er meget vigtigt, at disse krav er målbare.
Case eksempel:
På basis af en analyse har forretningen bl.a. besluttet sig for følgende målsætninger, som stilles til krav i projektet:
2. Beskriv ”current state”
Hvis IT-projektet medfører en forandring af noget eksisterende, hvilket ofte er tilfældet, så er det afgørende at forstå, hvad der skal forandres for at kunne leve op til forretningskravene. Det er derfor en forudsætning, at du kortlægger ”current state”. Hvis du ikke har et klart billede af det nuværende setup, så har du ikke styr på, hvad der skal forandres og dermed udvikles i dit projektet. Derudover er en analyse af ”current state” grundlaget for din forandringsstrategi og for at tage en dialog med interessenterne.
Case-eksempel:
Lav en procestegning over den nuværende onboarding process for hvert af de 3 lande. Kortlæg de 3 systemlandskaber og beskriv eventuelle integrationer og afhængigheder til andre systemer. For at lykkedes med at kortlægge ”current state” skal du involvere nøglepersoner fra forretningsområderne i alle 3 lande.
3. Beskriv ”future state”
Beskriv det nye, det der evt. skal fjernes, og hvad der skal ændres. Dette giver dig et ”high-level” billede af, hvor du skal hen og kan bruges til at finde ud af, hvordan du kommer fra ”current state” til ”future state”. Dette er ikke en udtømmende beskrivelse af en løsning, som kan sendes direkte til udvikling, men skal fungere som en klar definition af hvilken løsning, der vil dække dine behove og fungere som en definition af succes. Formålet med ”future state” er at afgrænse scope og definere et løsningsrum, samt skabe konsensus blandt de identificerede stakeholders omkring løsningen.
Case-eksempel:
Lav en procestegning over den ønskede fremtidige onboarding process for de 3 lande med det nye systemlandskab og eventuelle forventede integrationer. Lav en tegning over den fremtidige ”high-level” arkitektur med hjælp fra en IT-arkitekt.
4. Kortlæg interessentkrav
Når du har forstået og beskrevet forretningskravene og skitseret det fremtidige setup, er det muligt at identificere dine interessenter og indsamle og beskrive deres krav til løsningen. Hvad skal der til for, at lige præcis denne stakeholder kan bruge løsningen tilfredsstillende? Teknikker til indsamlingen er f.eks. workshops, interviews, ”mind-mapping”, ”shadowing” og brainstorming. Interessenter kan f.eks. være domæneeksperter (såkaldte SME’er), brugere af systemet, IT support, HR, IT drift, legal m.fl. Dvs. alle dem der bliver påvirket af initiativet.
Case-eksempel:
Afhold en workshop med hver af de 3 lande og få kortlagt deres krav ift. det forventede fremtidige setup. Brug eventuelt MoSCOW prioritering til kravene (”Must have”,”Should have”, “Could have”, “Would have”).
Et eksempel på et interessentkrav kan være de lovmæssige krav legal-afdelingen stiller til projektet: “Før vi kan optage samtaler med kunder, der ringer fra Norge, skal vi have en aktiv tilkendegivelse fra kunden”.
5. Kortlæg løsningskrav
Endelig bør du beskrive løsningskrav – målrettet dem der skal bygge og levere løsningen. Hvad skal der til for at løse interessent- og forretningskravene, så du når frem til det ønskede fremtidige setup. Her bør én eller flere IT arkitekter med deres tekniske baggrund og viden bidrage væsentligt. Det bedste er, hvis du kan få dem, der skal udvikle løsningen til at bidrage.
Løsningskravene opdeles i funktionelle og ikke-funktionelle krav. Funktionelle krav beskriver systemets opførsel og dermed specifikke funktionaliteter. De ikke-funktionelle krav beskriver kvalitetsmæssige krav til systemet i form af svartider, arkitektur, tilgængelighed, sikkerhed, skalerbarhed, dokumentation, brugervenlighed mv.
Case-eksempel:
Et funktionelt løsningskrav kan lyde således: ”Al kontakthistorik, der har været med kunden, skal være tilgængelig, når kunden er identificeret.
Et ikke-funktionelt krav kan være: ”Systemet skal indeholde klart forståelige meddelelser, som hjælper brugeren til at udføre sine arbejdsgange, korrigere fejl og som ikke forstyrrer Brugerens arbejdsgang mere end højst
nødvendigt”.
6. Kortlæg ændringskrav
Identificér mulige strategier for hvordan du kommer fra det nuværende setup til det fremtidige og beskriv hvilken af dem, der er den anbefalede. Afstem hvilke eventuelle midlertidige steps der er nødvendige og eventuelt kræver ny funktionalitet.
Case-eksempel:
I lægger en forandringsstrategi, der betyder, at I starter med udrulning i Danmark. Det betyder, at de sidste to lande fortsat skal bruge den eksisterende løsning i en periode. Da forretningen stadig skal eksistere i overgangsperioden, skal der udarbejdes en løsning, der gør, at der kan sendes kundehistorik mellem de 2 systemer. Denne funktionalitet er midlertidig, indtil alle har taget det nye system og proces i brug.
Arbejd non-lineært og agilt
Selvom jeg ovenover antyder en rækkefølge, vil du ofte have behov for at genbesøge forretnings- og interessentkrav, efter du har talt med udviklere og IT arkitekter om, hvad der er muligt. Det er dermed ikke en lineær vandfaldsproces at udarbejde en kravspecifikation. ”Future state” beskrivelsen bør f.eks. genbesøges efter afklaringen af interessent- og løsningskrav, da de med stor sandsynlighed vil ændre på den oprindelige forestillede ”future state”.
Kravene vil typisk ændres i løbet af projektet, ved at forretningen får andre prioriteter eller bliver klogere omkring løsningen. Derfor er det vigtigt ikke at betragte kravene som statiske, men som et udgangspunkt der kan ændres,
når man bliver klogere og hvis man prioriterer anderledes. Kravene vil typisk skulle detaljeres yderligere, når de skal udvikles, og der kan være behov for en dialog med interessenterne igen, hvis nye spørgsmål dukker
op.
Hvis projektet, som det ofte er tilfældet, er en forandring eller forbedring af noget eksisterende, vil mange af interessenternes ønsker og krav udspringe af de processer og systemer, de kender. De vil derfor have en tendens til, at systemerne
skal kunne præcis det samme. Det er dog en af dine fornemste opgaver at udfordre disse ønsker ved f.eks. at foreslå at løse behovene på en ny og bedre måde.
Det er min erfaring, at projekters succes i stor grad er afhængige af, hvorvidt du har styr på kravene eller ej. Manglende seriøst arbejde med kravspecifikationen kan være årsag til mange fejlede IT-projekter.
At analysere, beskrive og modulere krav, samt vurdere det nødvendige detalje niveau kræver en vis erfaring. Står du over for en større digital transformation eller et IT-projekt, hvor du har brug for at få styr på
kravene, rådgiver vi jer gerne, ligesom vi også kan varetage selve udarbejdelsen af kravene for jer eller i samarbejde med jer.
Vil du vide mere om eller søger sparring til hvordan digitalisering kan tænkes ind og hjælpe din virksomhed, så kontakt os på +45 61 77 70 70 eller på mail: rasmus.halvor@soprasteria.com
Kontakt os