Sådan skriver du en ERP-kravspecifikation
En kravspecifikation er det dokument, der omsætter virksomhedens behov til konkrete krav, som ERP-leverandører kan forholde sig til. Det er fundamentet for hele udvælgelsesprocessen og kontrakten med den valgte leverandør. Alligevel er det et af de mest undervurderede dokumenter i et ERP-projekt.
Foto: Scott Graham / Unsplash
Indhold
- 1Hvorfor kravspecifikationen afgør projektets succes
- 2Strukturen i en god kravspecifikation
- 3Involvér de rigtige mennesker fra starten
- 4Undgå de klassiske fælder
- 5Fra kravspecifikation til leverandørvalg
Hvorfor kravspecifikationen afgør projektets succes
En kravspecifikation tjener tre formål: Den tvinger virksomheden til at tænke sine processer igennem, inden systemvalget træffes. Den giver leverandørerne et fælles grundlag at afgive tilbud på, så tilbuddene faktisk kan sammenlignes. Og den bliver en del af kontrakten, så begge parter er enige om, hvad der skal leveres. Uden en kravspecifikation risikerer virksomheden at vælge system på baggrund af den bedste salgsdemonstration i stedet for det bedste match. Det er også her, scope creep begynder: Når kravene ikke er dokumenteret, opstår der løbende nye ønsker, som hverken budget eller tidsplan kan bære. Danske virksomheder, der springer kravspecifikationen over, oplever typisk 40-60% budgetoverskridelser sammenlignet med 15-25% for virksomheder med en grundig specifikation.
Strukturen i en god kravspecifikation
En kravspecifikation bør indeholde fem hoveddele. Først en virksomhedsbeskrivelse med branche, størrelse, omsætning, antal brugere og forretningsmodel. Dernæst en proceskortlægning, der beskriver de vigtigste forretningsprocesser (ordre-til-faktura, indkøb-til-betaling, produktion, lønkørsel osv.) med fokus på, hvordan de fungerer i dag, og hvad der skal forbedres. Tredje del er de funktionelle krav, opdelt i must-have, should-have og nice-to-have. Fjerde del er tekniske krav: hosting, integration med eksisterende systemer, sikkerhed, performance og skalerbarhed. Femte del er kommercielle krav: prismodel, implementeringstidsplan, supportaftale og kontraktvilkår. Hold dokumentet på 30-50 sider for en mellemstor virksomhed. Længere specifikationer bliver sjældent læst ordentligt.
Involvér de rigtige mennesker fra starten
Den største fejl er at lade IT-afdelingen skrive kravspecifikationen alene. IT forstår de tekniske krav, men det er forretningen, der ved, hvordan processerne fungerer i praksis. Sammensæt et tværfagligt team med repræsentanter fra økonomi, salg, lager, produktion og HR. Hver afdeling bør bidrage med deres processer, smertepunkter og ønsker. Giv teamet 4-6 uger til at kortlægge kravene med workshops faciliteret af en intern projektleder eller ekstern rådgiver. Husk at involvere ledelsen tidligt: De skal godkende budget og ambitionsniveau, og deres opbakning er afgørende for change management senere i projektet.
Undgå de klassiske fælder
Fælde nummer ét er at skrive for teknisk. En kravspecifikation skal beskrive hvad virksomheden har brug for, ikke hvordan systemet skal bygges. Skriv 'Systemet skal kunne håndtere automatisk tre-vejs matching af indkøbsordre, modtagelse og faktura' i stedet for 'Systemet skal have en matching-algoritme med fuzzy logic og 98% præcision'. Fælde nummer to er at kræve alt. Når 80% af kravene er must-have, er ingen af dem det. Vær ærlig om prioriteringen. Fælde nummer tre er at kopiere en skabelon fra internettet uden at tilpasse den. Generiske kravspecifikationer producerer generiske svar. Inkludér jeres branchespecifikke behov: Dansk momsafregning, Nemhandel-integration, overenskomsthåndtering i lønmodulet, specifikke rapporteringskrav til bestyrelse eller revisorer.
Fra kravspecifikation til leverandørvalg
Send kravspecifikationen til 4-6 leverandører og giv dem 3-4 uger til at svare. Bed dem strukturere svaret efter jeres kravliste, så svarene kan sammenlignes direkte. Arrangér scripted demos, hvor leverandørerne demonstrerer systemet med jeres egne forretningsscenarier: En konkret salgsordre, en lønkørsel med danske overenskomster, en månedsafslutning med intercompany-transaktioner. Vurder ikke kun funktionalitet, men også brugervenlighed, implementeringsplan og teamets kemi med leverandørens konsulenter. Afslut med en total cost of ownership-beregning (TCO) over 5 og 10 år, der inkluderer licenser, implementering, tilpasninger, uddannelse og løbende drift.