ROI på et IT-projekt: sådan regner I rigtigt

Når jeg spørger en kunde, hvor lang tid de tror, deres IT-projekt skal være om at tjene sig hjem, får jeg typisk to svar.

Det ene er "det ved jeg ikke, vi har bare brug for det." Det andet er en optimistisk PowerPoint, hvor alt går op i et tal, der lyder for godt.

Det rigtige svar ligger imellem - og det er ikke svært at regne, hvis I bruger den rigtige model.

Tre kilder til ROI

Der er typisk tre måder, et IT-projekt skaber værdi på:

1. Tidsbesparelse. Et antal timer om ugen falder ud af medarbejdernes hverdag, fordi en proces er blevet automatiseret eller forenklet.

2. Fejlreduktion. En tilbagevendende fejlkilde forsvinder eller falder markant. Fejlen kostede noget hver gang den opstod - i kreditnotaer, refusioner, supportopkald eller dårlig kundeoplevelse.

3. Direkte vækst. Bedre opfølgning gør, at flere leads bliver til kunder. Hurtigere svartid gør, at færre kunder vælger en konkurrent.

De tre kilder er meget forskellige at regne på. Det skal man være ærlig om.

Tidsbesparelse: den nemmeste, men også den mest oversolgte

Den klassiske udregning: "Anne bruger 3 timer om ugen på dette. Hendes timepris er 400 kr. Det er 600 kr. om ugen, 31.000 kr. om året."

Der er to fælder i den udregning.

Den første: tiden forsvinder ikke nødvendigvis. Hvis Anne sparer 3 timer om ugen, men ikke har andet at lave i de 3 timer, sparer I ikke pengene - I har bare en medarbejder, der er mindre presset. Det er fint, men det er ikke det samme som en ROI på regnskabet.

Den anden: tiden er ofte fordelt på mange små bidder, ikke én sammenhængende blok. En medarbejder, der sparer 5 minutter 12 gange om ugen, vil sjældent kunne omsætte det til reel ekstra produktivitet.

Skriv tidsbesparelser ned. Men reducer det med en faktor på 0,5–0,7, før I bruger det i jeres business case. Det er den ærlige version.

Fejlreduktion: kig efter de tilbagevendende fejl

Fejlreduktion er ofte den underbedømte ROI-kilde. Det er fordi, fejl er pinlige at tale om, og fordi de sjældent er samlet ét sted.

Kig efter ting som:

• Hvor mange kreditnotaer udsteder I om måneden - og hvor mange af dem skyldes datafejl?
• Hvor mange supportopkald handler om "jeg fik ikke det, jeg bestilte" eller "systemet siger noget andet end I sagde"?
• Hvor mange medarbejdertimer går med at "rette op på det" - i økonomi, lager, ordrer?

Når I først har tallene, er det relativt let at estimere, hvad en 50% reduktion er værd. Og 50% er ofte realistisk i et godt projekt.

Direkte vækst: ofte den største, men også den sværeste at love

Det bedste IT-projekt vi har lavet - målt på ROI - var hos en B2B-virksomhed, hvor opfølgning på leads gik fra "når der er tid" til at være automatisk styret. Antallet af vundne aftaler steg med over 20%.

Men jeg kunne ikke have lovet det på forhånd. Det blev synligt, da vi havde data efter første halvår.

Når I regner direkte vækst med i en business case, så lav det som en opside, ikke som en del af jeres break-even. Hvis projektet kan løbe rundt på tidsbesparelse og fejlreduktion alene, er væksten en bonus. Hvis I baserer jeres business case på vækst-antagelser, lægger I jer i et risikabelt projekt.

Vores tommelfingerregel

Et godt IT-projekt skal kunne tjene sig hjem på 18-24 måneder på tidsbesparelse og fejlreduktion alene. Direkte vækst er en bonus.

Hvis projektet kræver vækst for at løbe rundt, er det enten for stort, for dyrt - eller løser ikke det egentlige problem.

Det er en kedelig pointe at ende på, men det er den, der har sparet vores kunder for de største ærgrelser. Det er også den, der gør, at vores kunder typisk laver IT-projekter med os mere end én gang.