Kravspecifikationen är död, leve kravspecifikationen

Kravspecifikationen har alltid varit en självklar komponent när man planerar upp sitt affärssystemprojekt. Samtidigt har det också varit svårt att skriva en bra kravspecifikation. Vilken nivå skall man lägga sig på, hur skall den vara utformad, skall den baseras på verksamhetsprocesser eller systemfunktioner osv. Faktum är att det i dag är ännu svårare att skriva en bra kravspecifikation än tidigare. Digitaliseringseran som vi är inne i gör att morgondagens affärssystem kommer att se väsentligt annorlunda ut än dagens system. Transaktions och datavolymerna kommer att öka exponentiellt, affärssystemet kommer att ha kopplingar mot åtskilliga andra nya datakällor, fokus kommer att flyttas mot kundupplevelse, mobilitet och appar är redan en självklarhet osv. Sannolikt kommer den databank som affärssystemets databas besitter att kunna ge underlag till mer intelligenta och ”självstyrande” affärssystem i framtiden.

Låt oss börja med att titta på begreppet kravspecifikation, hur en kravspecifikation ser ut och vad den innehåller.

Man vill ju ha ut maximal nytta av en kravspecifikation, leverantören och intressenterna skall kunna förstå vad projektet syftar till och vad behoven är och då måste man fundera på detaljgraden. I vissa fall så försöker man tvinga fram så många funktionella behov som man kan komma på, man vill ju inte begränsa sig och man kan ju inte bara tänka på nuvarande behov utan även framtidens måste tas med i beaktande. Kunder säger ofta att om vi inte vet vad systemen kan erbjuda så kan vi ju inte veta alla krav på funktioner som vi behöver och vi vill ju även ha ett system att växa i.

Så vilken nivå skall man lägga sig på? En kravspecifikation kan ta utgångpunkt i processkartor med processer och delprocesser. Då bör man tänka på vad processerna baseras på, kundens egna processer, branschstandard, APQC standard etc. leverantören och kunden måste ju kunna kommunicera kring processerna och ”tala samma språk”. Man kan också utgå från det gamla modultänket som många leverantörer tillämpade och fortfarande till viss del tillämpar och man kan då titta på vilka funktioner som man vill kunna utföra inom varje modul i ett framtida system. Man kan också kartlägga de nuvarande och framtida arbetsprocesserna och skapa så kallade användarfall som man utgår från i sin behovsbild. Man kan även titta på vilka generiska funktioner/verktyg som man vill använda sig av i sitt affärssystem såsom workflow, triggers osv för att effektivisera arbetet. Ett annat sätt är att fokusera mer på företagets unika affärsprinciper och styrande principer för sina verksamhetsprocesser i första hand. Alltså handlar det om vilket angreppsätt man väljer.

Man behöver också titta på hur och när kravspecifikationen används och vilket syfte den har. En kravspecifikation kan användas för ett antal ändamål som inträder under olika tidpunkter i projektcykeln.

  • Det kan vara vid val av system när man vill jämföra systemfunktionalitet, systemens potential (och givetvis även leverantörens/implementatörens förmåga) för att kunna se hur olika system står sig rent funktionellt mot varandra.
  • Man vill kunna estimera projektet, hur lång tid kommer det att ta, vad kommer det att kosta. Leverantörer kan lämna offert på licenser och en budgetoffert på implementationsjobbet, alternativt ett fastpris, incitament pris etc. Var får jag mest system och funktionalitet för pengarna?
  • Kravspecifikationen är ofta även en del av den överenskomna leveransen mellan leverantör och kund och ligger ofta som en bilaga till Projektdirektivet / ”Statement of Work” dokumentet i avtalspaketet.
  • Kravspecifikationen kommer även att vara ett underlag för att dimensionera projektet och design av lösningen, vad är ”in scope” och vad är utanför ”scopet”, att styra ”scopet” helt enkelt.
  • Slutligen kan kravspecifikationen användas för att verifiera att det som beställdes faktiskt var det som levererades, testades, godkändes. Här kommer kravspecifikationen fram när man skall acceptanstesta och sluttesta systemet, den gamla V-modellen kommer väl alla ihåg och när det sen är dags att stänga projektet och betala slutnotan så kommer kravspecifikationen ofta till heders igen.

Hur utformar vi kraven? Skall vi använda oss av ”skall krav” för funktioner? Sannolikt inte eftersom det finns olika sätt att hantera en funktion och även en process i olika system. Däremot bör man använda ”skall krav” när det gäller företagsunika affärsregler och styrande principer.

Mot bakgrund av ovanstående kan vi konstatera att kraven och användningen av kravspecifikationen kommer att ändra sig över tid, dvs under projektets livscykel. Vi behöver hantera nuvarande krav och framtida krav. Vi vill ju sannolikt välja ett system som vi kan växa med över åtminstone en 10 års period.

Vi måste även när vi skriver kravspecifikationen beakta vilken projektform vi planerar att tillämpa. Tillämpar vi den klassiska vattenfallsmodellen som vanligen består av mellan fyra och sex faser, exempelvis; diagnostik, analys, design, utveckling/bygg, införande, stabiliseringsfas eller tänker vi arbeta mer agilt och i form av sprintar iterera analys och design samt även försöka driftsätta funktionsdugliga systemkomponenter löpande under projektet. Att arbeta agilt med större affärssystemimplementationer är ett ganska nytt sätt, majoriteten av projekten körs fortfarande enligt klassisk vattenfallsmodell men även hybrider av de två sätten kan förekomma.

Det är alltså viktigt att tänka på syftet med kravspecifikationen när man skapar den. Är det primära syftet att jämföra olika systems funktionalitet med varandra, är det för att estimera projekt i tid och kostnad, är det för att hantera och styra projektets omfattning eller är det att ha som en avtalsbilaga för att säkerställa den slutliga leveransen.

Visionerna och drivkrafterna måste lyftas fram och detaljkraven ta ett steg tillbaka. Ett modernt affärssystem ger ju möjligheter till processeffektiviseringar som kunden inte visste om på förhand. Ett bra sätt är att sätta upp en prototyp redan under analysarbetet för att på så sätt redan tidigt börja designa viktiga processer och skapa en gemensam bild av behov och möjligheter i det framtida systemet.

Ett mer agilt arbetssätt ställer ju förstås större krav på en mer flexibel avtalsmodell och kräver en större tillit mellan parterna.

Och sen skall man komma ihåg att kravspecifikationen och systemkraven är inte allt. Det är minst lika viktigt att den implementationspartner man väljer känns rätt, är väl förankrad på marknaden, har en långsiktighet och rätt inställning till projektet, förstår branschen, ”pratar samma språk”, besitter gedigen produktkompetens, och inte minst att man skapar ett starkt förtroende för varandra, tanken är ju att det skall bli ett långt förhållande. Ett mediokert system kan faktiskt med rätt implementationspartner bli en riktig framgångssaga och på samma sätt kan ett funktionellt mycket kapabelt system sluta med ett fiasko om inte implementationspartnern kan sin produkt, kundens bransch eller saknar en fungerande implementationsmodell.

Själv tror jag att man i framtidens kravspecifikationer behöver uttrycka behoven i mer generella termer, mer processbaserat och sedan måste man vara beredd på att revidera sitt kravunderlag under resans gång. Den kravspecifikation man skrev under upphandling och urvalsprocess behöver revideras eller rent av ersättas med ett ”scope” dokument efter att man genomfört en analysfas tillsammans med sin valda implementatör. Kravspecifikationen som sådan kommer dock sannolikt alltid att behövas, den tvingar oss att planera och tänka till kring våra behov, nyttor och prioriteringar. En bra skriven kravspecifikation kommer sannolikt att minska den totala slutkostnaden för projektet.

Så – länge leve kravspecifikationen!

Författare: Göran Barchan