En business case er det dokument, direktionen træffer sin beslutning på. For et IT-projekt skal den kunne svare på fem ting på få sider: hvad er formålet, hvilke alternativer er overvejet, hvilke gevinster er der, og hvem ejer dem, hvad er risikoen, og hvad bliver følgen af at lade tingene stå. Den er skrevet til dem, der skal vælge, og den skal vise, at valget er et rigtigt valg. Ligner dokumentet en reklame for en beslutning, der allerede er taget, er det værd at skrive om.
Hvad skal en business case indeholde?
I en virksomhed med flere afdelinger og selskaber skal en business case gøre to ting. Den skal give direktionen et grundlag for at sige ja eller nej. Og den skal gøre projektet sammenligneligt med alt det andet, der konkurrerer om de samme penge og folk, når sagen kommer op i porteføljerådet.
Længden skal passe til beslutningen. Et mindre projekt kan klare sig med en side, og et flerårigt program skal have mere. Tre til seks sider er nok til de fleste. Det, der ikke kan siges på den plads, kan ligge i bilag.
Dokumentet skrives af forretningen sammen med IT. Skriver IT alene, bliver gevinsterne teknik, og ingen i forretningen har forpligtet sig. Business casen skal have en navngiven afsender uden for IT, når projektet tjener et forretningsformål.
Skabelonen
Her er en skabelon, I kan bruge direkte. Under hver overskrift står, hvad afsnittet skal svare på.
1. Formål. Hvilket problem eller hvilken mulighed handler det om, og hvorfor nu? Skriv det i forretningens ord, så en direktør uden for IT kan genkende det. Står der kun, at et system skal skiftes, er formålet ikke fundet endnu.
2. Omfang. Hvad er med, og hvad er ikke med? Hvilke selskaber, processer og systemer berøres? Afgrænsningen mod det, der ikke er med, er ofte det, der siden skaber uenighed.
3. Alternativer. Hvilke andre veje er overvejet? Mindst tre bør stå her: at gøre intet, at gøre noget mindre og den foreslåede løsning. Når valget står mellem at bygge, købe eller integrere, er det et spørgsmål med sin egen logik, men i en virksomhed, der bruger IT, er det ofte standardsystemet, der skal holdes op imod det, I har.
4. Gevinster med ejer. Hvad bliver bedre, hvordan måles det, og hvem i linjen står inde for det? Hver gevinst skal have et navn på sig. Det er emnet i gevinstrealisering.
5. Omkostninger. Hvad koster det at indføre og at drive bagefter? Tag jeres egne folks tid med, også i forretningen, og vis driften over systemets levetid. Hvordan regnestykket laves, står i totalomkostninger. Spørgsmål om, hvordan projektet behandles i regnskabet, tages med revisor, se aktivering af IT-omkostninger.
6. Risici. Hvad kan gå galt, hvad betyder det for forretningen, og hvem håndterer det? Tag også risikoen for, at gevinsten udebliver, og at de folk, der er regnet med, ikke kan frigøres.
7. Hvis intet gøres. Hvad sker der om et år, tre år og fem år, hvis projektet ikke bliver til noget? Det er det afsnit, der oftest er skrevet for let. Ved et gammelt system kan det være det stærkeste argument, se fornyelsesefterslæb.
8. Kapacitet og plan. Hvem skal lave arbejdet, hvad må vente imens, og hvad er de første milepæle? Et forslag uden svar på, hvad der må vige, er ufærdigt.
9. Beslutning. Hvad bedes direktionen om? Skriv det i én sætning, og nævn beløbsrammen, hvad den første fase frigiver, og hvornår sagen kommer tilbage.
Fire ting, der ødelægger en business case
Alternativerne er stråmænd. Det er let at se, når de to andre muligheder kun står der for at tabe. Skriv dem, så en fornuftig person kunne vælge dem.
Gevinsterne står uden ejer. Sparet tid fordelt på mange medarbejdere bliver sjældent til en gevinst, medmindre nogen beslutter, hvad tiden skal bruges til. Skriv kun det, en leder vil stå inde for.
Tallene er for pæne. Den, der vil have sit projekt igennem, regner optimistisk. Lad økonomifunktionen se tallene igennem, før sagen kommer op. Ved større sager giver det mening at vise, hvad der sker, hvis gevinsten kommer senere eller bliver mindre.
Kun anskaffelsen er med. Driften over en lang årrække, opgraderinger og de interne timer forsvinder let. Så ser projektet billigere ud, end det bliver.
Tænkt eksempel
En koncern overvejer et fælles system til indkøb i tre selskaber. Formålet er bedre indkøbspriser og ét billede af leverandørerne. Alternativerne er at beholde de tre lokale løsninger, at samle to af dem eller at indføre et nyt fælles system. Gevinsterne ejes af indkøbschefen og to økonomichefer, som hver skriver under på, hvad de forventer. Hvis intet gøres, kan selskaberne fortsætte, men et af de lokale systemer mister snart sine opdateringer. Sagen slutter med en anmodning om at frigive første fase, og hvornår direktionen ser sagen igen. Eksemplet er tænkt, og der står med vilje ingen beløb i det.
Efter beslutningen
Business casen skal leve videre. Tag den frem ved hver større milepæl, og spørg, om den stadig holder. Ændrer forudsætningerne sig, skal den opdateres, og sagen skal tilbage til dem, der besluttede. En stor investering hører desuden ofte til i bestyrelsen, se stor IT-investering i bestyrelsen.
Det gør I nu
Gør skabelonen til jeres standard, og aftal, hvornår den skal bruges. Tag den næste sag, der skal op i direktionen, og skriv den i formatet. Bed økonomi om at læse tallene igennem, og bed en leder fra hvert berørt selskab om at bekræfte gevinsterne, før sagen behandles.
Det skal I lade være med
- At skrive business casen, når beslutningen reelt er taget · så er den pynt, og alle kan mærke det.
- At lade IT skrive gevinsterne for forretningen · så ejer ingen dem bagefter.
- At springe “hvis intet gøres” over · det er ofte det afsnit, der bærer sagen.
Det skal I kræve af dem, der leder IT
- ☐ En fast skabelon, der bruges til alle større sager.
- ☐ Reelle alternativer, herunder at gøre mindre eller intet.
- ☐ Navngivne ejere i linjen for hver gevinst.
- ☐ Driftsomkostninger over levetiden og interne timer med i tallene.
- ☐ Økonomifunktionens gennemsyn før behandlingen.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Prioriteringsmodel for IT-projekter · Totalomkostninger
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CIO hos Nielco IT
