Forestil dig en lille virksomhed, hvor to medarbejdere hver måned bruger en uge på at taste ordrer ind i hånden. Det virker, det har altid virket, men det tager tid, og en gang imellem sniger der sig en fejl ind. En leverandør banker på og siger, at hun har en løsning, der klarer indtastningen automatisk. Skal man købe den? Det lyder som et spørgsmål, man svarer på med et regneark. Men så enkelt er det ikke. Det, man har brug for, er en business case: en begrundet anbefaling, der stiller de mulige veje op ved siden af hinanden, vejer fordele, omkostninger og risiko mod hinanden, og til sidst peger på det, man bør gøre, og siger hvorfor.
Det er værd at holde fast i den definition, for den bliver ofte misforstået. En business case begrunder, at man sætter et projekt i gang. Den vurderer fordelen, omkostningen og risikoen ved de forskellige muligheder, man har, og giver en begrundelse for den løsning, man foretrækker. Et regneark kan være en del af den, men et regneark alene er ikke en business case, lige så lidt som en pris er en beslutning. Regnearket fortæller, hvad noget koster; business casen fortæller, om det er værd at gøre, sammenlignet med alternativet, og hvorfor.
Der skal være mindst to muligheder
Kernen i metoden er så enkel, at den er let at overse: der skal være mindst to alternativer. Har man kun én mulighed, er der jo intet at vælge imellem, og så er en business case overflødig, man gør bare det ene, man kan. Værdien opstår i sammenligningen. Derfor bygger man altid mindst to scenarier op og stiller dem over for hinanden.
Det første scenarie kalder man base-casen. Det er billedet af, hvad der sker, hvis vi bare fortsætter som nu. Man kalder det også nul-alternativet, altså at gøre ingenting og køre videre ad det spor, man er på. Base-casen er ikke en tom mulighed, man kan feje til side. Den har sine egne omkostninger og sine egne risici (de to medarbejdere bruger stadig en uge om måneden, fejlene opstår stadig), og netop derfor er den målestokken. Alt andet skal jo være bedre end at fortsætte som nu, ellers er der ingen grund til at ændre noget.
Det andet scenarie er policy-casen: det forslag, man gerne vil fremlægge. Her køber virksomheden løsningen, der klarer indtastningen. Der kan sagtens være flere policy-cases, måske overvejer man også at ansætte en ekstra person i stedet, eller at lægge opgaven ud til en anden virksomhed. Hver af dem er et selvstændigt forslag, der skal holdes op mod base-casen.
Men her kommer det praktiske greb, der gør metoden håndterbar. Hvis man prøver at regne hvert scenarie helt igennem (al omsætning, alle lønninger, al husleje, alt), drukner man i tal, hvoraf de fleste er ens i begge scenarier. Huslejen er den samme, hvad enten man taster i hånden eller ej. Derfor regner man i praksis kun på delta-casen: forskellen mellem de to. Delta er policy minus base. Det, man regner på, er alene det, forslaget ændrer i forhold til at fortsætte som nu. Hvad falder bort, hvad kommer til? Alt det, der er ens, kan man roligt lade stå udenfor, for det påvirker ikke valget.
Meget mere end økonomi
Her begår mange den anden store fejl: de tror, business casen kun handler om penge. Det gør den ikke. Konsekvenserne af et valg deler sig på to måder på én gang. For det første i fordele og ulemper. For det andet i det, der er finansielt, og det, der er ikke-finansielt. Man skal hele vejen rundt, for en beslutning, der ser fornuftig ud på papiret, kan være tåbelig, hvis man har glemt en halvdel af konsekvenserne.
De finansielle konsekvenser er dem, man lettest kommer i tanke om. Der er capex, altså hvad det koster at anskaffe løsningen i første omgang, for vores indtastningsløsning de 80.000 kr., den koster at få op at stå. Der er opex, altså hvad det koster at drive den løbende, her 30.000 kr. om året til abonnement og vedligehold. Og så er der cashflow, pengene ind og ud: kan kassen overhovedet bære de 80.000 kr. i netop den måned, hvor de forfalder, samtidig med at der stadig skal betales løn og husleje? En løsning kan være god på papiret og alligevel umulig lige nu, hvis pengene ikke er der, dengang de skal bruges. Den simple kerne er velkendt (indtægter minus udgifter er lig med profit), men i praksis regner man ofte på cashflow, altså på de faktiske betalingsstrømme, fordi det er dem, der afgør, om kassen kan holde. Forskellen mellem at eje og at leje, og hvordan capex og opex hænger sammen, kan man læse mere om under capex og opex, og selve regnearbejdet på betalingsstrømme hører hjemme i investeringsvurdering og betalingsstrømme.
De ikke-finansielle konsekvenser er dem, der oftest glemmes, og som lige så ofte afgør sagen. Har vi kompetencerne til at bruge den nye løsning, eller skal de to medarbejdere først læres op, og hvad sker der, hvis den ene, der nåede at lære den at kende, siger op? Hvad med sikkerhed og data: hvor kommer ordrerne til at ligge henne, og hvem kan komme til dem, når indtastningen ikke længere sker inde i huset? Er løsningen skalerbar, så den kan følge med, når julesalget på en enkelt måned fordobler antallet af ordrer? Og passer den med, hvor vi vil hen, det strategiske fit? Er virksomheden på vej mod ét samlet system, kan en lille fritstående løsning være billig og alligevel forkert, fordi den trækker i den modsatte retning. Ingen af de fire spørgsmål har en pris på, men de kan hver især vælte et valg, som regnearket ellers sagde ja til.
Der gemmer sig en fin pointe i, at konsekvenserne deler sig i fordele og ulemper: den enes fordel er ofte den andens ulempe. At blive ved det gamle sparer os for anskaffelsen, men koster os den spildte tid; at købe det nye koster penge nu, men frigør timerne. Men det er sjældent så rent, at det bare er to sider af samme mønt. Der er næsten altid mere end det (en ny risiko her, en overset kompetence der), og derfor gælder det om at få alle konsekvenserne på bordet, ikke kun de oplagte. Et godt værktøj til netop det er tankeeksperimentet i to identiske jordkloder, der tvinger én til at finde den fulde forskel mellem to veje.
Delta-regnestykket i praksis
Lad os sætte tal på og regne på deltaet, altså kun på forskellen. I base-casen bruger de to medarbejdere tilsammen en uge om måneden på indtastning. Sætter man den tid til omkring 120.000 kr. om året i løntimer, er det den udgift, forslaget kan fjerne. Policy-casen koster 80.000 kr. at anskaffe (capex) og 30.000 kr. om året at drive (opex). Det første år ser regnestykket på cashflow altså sådan ud: ind kommer en besparelse på 120.000 kr., ud går 80.000 + 30.000 = 110.000 kr. Nettoet det første år er en beskeden gevinst på 10.000 kr. Men fra år to falder anskaffelsen bort, og så står den årlige besparelse på 120.000 kr. kun over for de 30.000 kr. i drift, et årligt plus på 90.000 kr. Set over nogle år er forslaget klart bedre end at fortsætte som nu. Selve metoden til at veje sådanne fordele og ulemper systematisk op mod hinanden er en cost-benefit-analyse, og den bygger direkte oven på delta-tankegangen her.
Læg mærke til, at vi hele vejen kun regnede på det, der ændrede sig. Vi rørte ikke huslejen, ikke den øvrige løn, ikke omsætningen, kun forskellen mellem de to scenarier. Det er delta-casen i arbejde, og det er grunden til, at metoden kan bruges på selv store beslutninger uden at drukne i tal.
Der er dog en hage ved den slags besparelse, som er værd at være helt ærlig om. De 120.000 kr. er kun en rigtig besparelse, hvis de to medarbejderes tid faktisk forsvinder ud af regnskabet, altså hvis de kan afskediges, eller hvis man undlader at ansætte en, man ellers skulle. Sker det ikke, og det gør det som regel ikke, bliver timerne jo ikke sparet væk; de bliver brugt på noget andet. Det er ofte en god ting: de to får tid til opgaver, der skaber mere værdi end manuel indtastning. Men så er gevinsten ikke længere 120.000 kr. på kontoen, den er, at den samme løn nu køber mere værdifuldt arbejde. Og om det er en god handel, er en vurdering, ikke et tal: er de frigjorte timer mere værd brugt på det nye end på det gamle? Den ærlighed hører med i en solid business case, for ellers kommer man til at love en kontant besparelse, der aldrig rammer bundlinjen.
Et klassisk eksempel gør faren tydelig. Forestil dig et nyt intranet, der sparer hver eneste medarbejder to minutter om dagen. I en virksomhed med 1.000 ansatte er det 2 × 1.000 = 2.000 minutter om dagen, altså godt 33 timer, svarende til omkring fire-en-halv fuldtidsansattes arbejdsdag, hver eneste dag. Sat op på den måde ligner det en gevinst, ingen kan sige nej til. Men er det en god business case? Kun hvis de sparede minutter rent faktisk kan veksles til penge, hvis de mange små stumper tid summer op til, at man kan undvære en stilling eller lade være med at ansætte. Kan de ikke det, er besparelsen, hvad man kalder funny money: den er ægte nok, for folk får virkelig to minutter mere om dagen, men den kan ikke byttes til rede penge og dukker aldrig op på bundlinjen. To minutter spredt ud på tusind mennesker forsvinder bare ind i hverdagen. Det gør ikke intranettet dårligt, det kan sagtens være pengene værd på andre måder, for eksempel mindre irritation eller færre fejl. Men netop dét er grunden til, at en business case er så vigtig: den tvinger en til at få det hele med, også skelnen mellem en besparelse, der kan mærkes i kassen, og en, der ikke kan. Kun sådan kan man træffe en beslutning på et ærligt grundlag.
Når nye tal dukker op undervejs: sunk cost
En business case er lavet, før man går i gang, på den viden man havde dengang. Men virkeligheden retter sig ikke altid efter regnearket, og så opstår et af de steder, hvor sund fornuft nemt fører galt af sted. Tag et andet eksempel. En virksomhed regner en case på en løsning, der skal give en besparelse på 20 mio. kr. Den koster 15 mio. kr. at købe og 3 mio. kr. at implementere, altså 18 mio. kr. i alt. Tyve mod atten ser fornuftigt ud, og projektet sættes i gang.
Midt i implementeringen viser det sig, at et andet stykke software skal ændres først, ellers virker den nye løsning ikke. Det koster 4 mio. kr. ekstra, som ingen havde regnet med. Nu melder spørgsmålet sig: skal vi fortsætte? Den umiddelbare mavefornemmelse siger, at projektet lige er blevet dårligt, 20 mod 22, det løber jo ikke længere rundt. Men det er forkert regnet. De 15 + 3 = 18 mio. kr. er allerede brugt eller bundet; de er sunkne omkostninger, og de kommer ikke tilbage, hvad enten man fortsætter eller stopper. Derfor skal de slet ikke med i beslutningen nu. Det eneste, der tæller, er de fremadrettede tal: rest-gevinsten, der stadig kan hentes, mod rest-udgiften, der stadig skal betales. Her står 20 mio. kr. i besparelse endnu foran os over for kun de 4 mio. kr., det koster at komme videre. Set sådan er det oplagt at fortsætte. Hele denne skelnen mellem hvad der er brugt og hvad der ligger foran, er kernen i alternativomkostning og sunkne omkostninger.
En metode til langt mere end it
Det gennemgående eksempel har handlet om at købe en løsning, men metoden hører ikke it til. Enhver større beslutning kan struktureres på samme måde: hold base-casen (fortsæt som nu) op mod en eller flere policy-cases (forslagene), regn på deltaet mellem dem, og få både de finansielle og de ikke-finansielle fordele og ulemper på bordet. Skal bageriet leje et nabolokale? Skal kaffevognen udvides til to vogne? Skal virksomheden skifte leverandør? Det er alt sammen base, policy og delta med fordele og ulemper, og en anbefaling til sidst.
For business casen ender altid i en anbefaling. Den er ikke en neutral bunke tal, man læsser af på ledelsens bord; den er en begrundet konklusion, der siger, hvad man mener man bør gøre, og hvorfor det er bedre end alternativerne. Netop derfor er business casen også omdrejningspunktet flere andre steder i projektarbejdet. Den er det, man vejer forslag imod hinanden med, når midlerne er knappe, i projektportefølje og prioritering. Den knytter an til, hvad projektet egentlig skal skabe af værdi, i nyttemål og produktmål. Og den bliver ikke lagt væk, når projektet er sat i gang: ved hver port i projektfaser og stage-gate tages business casen frem igen og prøves mod den nyeste viden, holder regnestykket stadig? Bagefter måler man med gevinstrealisering, om den gevinst, business casen lovede, faktisk kom hjem. Og fordi enhver anbefaling hviler på antagelser, der kan briste, hører der altid en risikoanalyse med, der siger hvad der kan gå galt, og hvor følsomt regnestykket er over for det.
Kort sagt
En business case er en begrundet anbefaling, ikke et regneark. Den kræver mindst to muligheder, ellers er der intet at vælge imellem: en base-case, der viser hvad der sker hvis vi fortsætter som nu, og en eller flere policy-cases, der er de forslag vi vil fremlægge. I praksis regner man ikke de to scenarier helt igennem, men på delta-casen (forskellen mellem dem, altså policy minus base), for det er kun det, forslaget ændrer, der påvirker valget. Konsekvenserne skal hele vejen rundt: fordele og ulemper, finansielt (capex, opex, cashflow) og ikke-finansielt (kompetencer, sikkerhed, skalerbarhed, strategisk fit). Undervejs skal man huske, at allerede brugte penge er sunkne og ikke tæller med i, om man skal fortsætte, kun de fremadrettede tal gør. Og man skal være ærlig om, at en besparelse i tid kun bliver til penge, hvis den faktisk kan veksles til det, for eksempel ved at en stilling kan spares væk; ellers er den ægte nok, men funny money, der aldrig rammer bundlinjen. Til sidst ender casen i en anbefaling, der siger hvad man bør gøre, og hvorfor. Metoden gælder langt ud over it: enhver stor beslutning kan stilles op som base, policy og delta med fordele og ulemper, og et begrundet valg til sidst.