Vejledning til statens business casemodel

Vejledning til statens business casemodel Januar 2014 Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen

Indhold 1 INDLEDNING... 1 1.1 FORMÅL... 1 1.2 HVAD ER STATENS BUSINESS CASE-MODEL?... 1 1.3 KOBLING TIL DEN FÆLLESSTATSLIGE IT-PROJEKTMODEL... 1 1.4 KOBLING TIL DEN FÆLLESSTATSLIGE PROGRAMMODEL... 2 1.5 PROCESSER OG FORMKRAV... 2 1.6 FOR DIG, DER HAR BRUGT BUSINESS CASE-MODELLEN FØR... 3 2 PRINCIPPER... 4 2.1 SCENARIER OG GEVINSTER... 4 2.2 NEDBRYDNING AF UDGIFTER I FORUDSÆTNINGER... 8 2.3 RISICI, USIKKERHED OG TREPUNKTSESTIMERING... 9 3 OPSÆTNING AF BUSINESS CASEN... 13 3.1 OPSÆTNING AF ORGANISERING... 13 3.2 OPSÆTNING AF RISIKOPROFIL... 15 3.3 OPSÆTNING AF STØRRELSE... 15 3.4 OPSÆTNING AF KONTERING... 16 4 BRUGEN AF BUSINESS CASE-MODELLEN... 17 4.1 FORUDSÆTNINGSDIAGRAM... 17 4.2 REGNEARKET... 20 4.3 BUSINESS CASE-RESUMÉ... 27 4.4 OPDATERING AF BUSINESS CASEN... 29 5 KVALITETSSIKRING... 30 5.1 SAMLET SPÆND PÅ UDGIFTER... 30 5.2 RISIKOPULJE... 30 5.3 VÆGTEN AF STØRSTE POST... 30 5.4 BAGGRUND OG KILDER FOR ESTIMATER... 30 5.5 SAMMENHÆNG MELLEM RISIKOREGISTER, AFHÆNGIGHEDER OG BUSINESS CASE... 31 5.6 SANDSYNLIGHEDSVURDERINGER... 31 Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen

5.7 FORUDSÆTNINGSDIAGRAM GENFINDES I BUSINESS CASEN... 31 5.8 TIDSPLAN... 31 5.9 DRIFTSSCENARIER... 31 5.10 GEVINSTEJERE... 31 5.11 IKKE-ØKONOMISKE GEVINSTER... 32 Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [3]

1 Indledning Dette afsnit indeholder en beskrivelse af formålet med statens business case-model, en forklaring af hvad en business case er, samt ser på sammenhængen til den fællesstatslige itprojektmodel og programmodel. 1.1 Formål Vejledningen til statens business case-model er rettet mod projektledere med økonomisk forståelse. En sund økonomisk forståelse vil gøre det lettere at udarbejde en valid business case, der lever op til de krav, der stilles til statslige it-projekter og programmer. Det anbefales derfor, at projektledere uden rimelig økonomisk indsigt inddrager organisationens økonomifunktion i forståelsen af kernebegreber samt udarbejdelsen og tolkningen af modellen. Vejledningen er optaget i Finansministeriets Økonomisk Administrative Vejledning (ØAV). I vejledningen tages udgangspunkt i udarbejdelsen af business case for et projekt, men det understreges, at vejledningsteksten, med mindre andet er angivet, også gælder for programmer. 1.2 Hvad er statens business case-model? Statens business case indgår i den fællesstatslige it-projektmodel og programmodel. Det grundlæggende formål er at beregne og tydeliggøre gevinsterne og udgifterne ved et givent projekt eller program, når der tages højde for risici. Derved vil business casens beregninger kunne bruges som en vurdering af it-projektets eller programmets berettigelse. Business casen sikrer også, at risikopuljen passer til risikoprofilen, således at der ikke opbygges større reserver end nødvendigt. En business case bygger dermed på en analyse af, hvilken forandring man ønsker, og hvordan den opnås. Mere konkret skal der findes oplysninger om gevinster, udgifter og risici. Statens business case-model er en fast skabelon for, hvordan disse opstilles, men de bagvedliggende analyser er øvelser der mest af alt kræver faglig indsigt og grundigt forarbejde. Den metodiske struktur i skabelonen er bygget op omkring tre principper: 1. Scenarier og gevinster, se afsnit 2.1 2. Nedbrydning af udgifter i forudsætninger, se afsnit 2.2 3. Risici, usikkerhed og trepunktsestimering, se afsnit 2.3 Udarbejdelsen af Statens business case-model består derefter af tre trin: 4. Et forudsætningsdiagram, se afsnit 4.1 5. Et regneark, se afsnit 4.2 6. Et business case-resumé, se afsnit 4.3 1.3 Kobling til den fællesstatslige it-projektmodel I it-projektmodellen fungerer business casen sammen med projektinitieringsdokumentet (PID en) som det centrale styringsprodukt og udarbejdes i analysefasen. Der udarbejdes dog allerede i idéfasen et overordnet estimat for projektets business case i forbindelse med udarbejdelsen af projektgrundlaget. Sammen med PID en giver business casen et overblik over projektets samlede scope. Business casen er den økonomiske opgørelse og indeholder ikke en beskrivelse af, hvorledes gevinster skal høstes, eller hvordan kvaliteten af leverancerne måles - dette beskrives i PID'- en. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [1]

Figur 1. Den fællesstatslige it-projektmodel inkl. ledelsesprodukter. Idé Analyse Ledelsesfase > Ledelsesfase Anskaffelse Specificering > Udbud Gennemførelse Ledelsesfase > Ledelsesfase Realisering Projektgrundlag Projektinitieringsdokument (PID) Projektafslutningsrapport Gevinstrealiseringsrapport Business case Efter udarbejdelse af business casen i analysefasen er den et dynamisk dokument, der bør opdateres løbende undervejs i projektforløbet. Business casen skal som minimum opdateres ved faseovergange (defineret af den fællesstatslige it-projektmodel) og ved væsentlige ændringer. 1.4 Kobling til den fællesstatslige programmodel I programmodellen udarbejdes business casen for det samlede program og indeholder alle udgifter på projekt- og programniveau samt alle gevinster, som det samlede program realiserer. Udgifter summeres i business casen på baggrund af opgørelse af udgifter for hvert projekt samt udgifter for aktiviteter på programniveau. Gevinster opgøres kun på programniveau. Figur 2. Den fællesstatslige programmodel. 7 PRINCIPPER FOR PROGRAMLEDELSE 9 PROGRAMTEMAER FASEMODELLEN Identificering af program Præcisering af program Etabler Eval uer Ledelse af programbølger Levering af forandringsevne Realisering af gevinster og for OBLIGATORISKE OG VALGFRIE LEDELSESPRODUKTER b er ed Lukning af program Business casen for et program udarbejdes i fasen præcisering af program. Herefter er business casen, som ved projektforløb, et dynamisk dokument, der bør opdateres løbende undervejs i programforløbet. Business casen skal som minimum opdateres ved alle efterfølgende programbølger (defineret af den fællesstatslige programmodel) og ved væsentlige ændringer (se tidligere definition). 1.5 Processer og formkrav 1.5.1 Statens IT-projektråd Er der tale om et projekt med et budget på udgifter over 10 mio. kr., eller et program, hvor de samlede udgifter til it overstiger 10 mio. kr. og it udgør et væsentligt element, skal alle business casens elementer (forudsætningsdiagram, regneark og business case-resumé) sendes til Statens IT-projektråds sekretariat i Digitaliseringsstyrelsen. Dette sker som et led i en risikovurdering fra Statens IT-projektråd. Processen for risikovurderinger i Statens ITprojektråd er beskrevet her. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [2]

1.5.2 It-aktstykker Hvis projektudgifter udgør 60 mio. kr. eller derover skal projektet eller programmet forelægges Folketingets Finansudvalg med henblik på tilslutning til igangsættelse (jf. Budgetvejledningen 2011 punkt 2.2.18.3). Et projekt eller et program, der undervejs overstiger 60 mio. kr. og projekter eller programmer over 60 mio. kr., som udsættes for væsentlige ændringer (jf. nedenfor) skal også forelægges Finansudvalget ved et orienterende aktstykke. Såfremt der ikke er bevillingsmæssig hjemmel til at gennemføre projektet eller programmet, skal der opnås hjemmel på bevillingslov eller ved tilslutning fra Finansudvalget, også selvom de samlede udgifter er under 60 mio. kr. Definition: Væsentlige ændringer Ved væsentlige ændringer forstås ændringer i de samlede udgifter på 10 pct. eller derover, eller mindst 6 mio. kr. Ligeledes er en forventet forsinkelse i forhold til den fastlagte tidsplan på 3 måneder eller derover en væsentlig ændring. Budgetvejledningen 2011, punkt 2.2.18.3 Udarbejdelsen af aktstykker i forbindelse med it-projekter og programmer skal følge vejledningen retningslinjer for udformning af it-aktstykker, der er optaget i ØAV og kan findes her. Skabelonen for it-aktstykker indeholder både udgifts- og omkostningsbaserede tabeller. Business case-modellen er udgiftsbaseret, men omkostningsbaserede tal kan manuelt indtastes i modellen så alle tabeller, der er nødvendige i et it-aktstykke, beregnes og vises i korrekt format i business case-resuméet. Vejledning til omregning fra udgift til omkostning kan findes her. 1.6 For dig, der har brugt business case-modellen før Den væsentligste nyudvikling af statens business case-model for de myndigheder, der har brugt modellen før, er muligheden for at opsætte brugen af business casen specifikt til det konkrete projekt eller program. Formålet hermed er bedre at understøtte de konkrete behov, som de enkelte myndigheder måtte have. Det største af disse opsætningsvalg er organisering (projekter eller programmer), men også budgetstørrelse, risikoprofil og kontering kan justeres. De forskellige måder at opsætte business casen på er gennemgået i afsnit 3. Det skal understeges, at anvendelsen af business casen, uanset opsætning, hviler på de samme grundlæggende principper. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [3]

2 Principper I dette afsnit præsenteres business casens grundlæggende principper og metodik. Der er fokus på de overordnede definitioner og linjer. Den praktiske anvendelse af principperne i regnearket uddybes i afsnit 4. For at forstå business case-modellen og den konkrete brug af regnearket er det nødvendigt med en gennemgang af de principper, business casen bygger på, nemlig brugen af flere scenarier og gevinstberegning, nedbrydning i forudsætninger samt håndtering af usikkerhed og risici. Business casens opbygning er vist i figuren nedenfor. Alle begreber gennemgås i detaljer i de efterfølgende afsnit. Figur 3. Statens business case-model. Nuværende drift Projektudgifter Fremtidig drift Input fra forretning og analyser Nuværende driftsudgifter (regnskabstal) Udgiftst (forudsætningsdiagram) Risici Risici 0-scenarie Forventede gevinster (gevinstsdiagram) Udgiftstyper (forudsætningsdiagram) Risici 1-scenarie Indtastning i regneark Udgifter Trepunkts-estimering Trepunkts-estimering Driftsudgifter 0-scenarie 1-scenarie Trepunkts-estimering Driftsudgifter før-situation Projektudgifter Forskel = Risikopulje Risikojusterede projektudgifter Risikojusteret drift 0-scenarie Forskel = Bruttogevinster Risikojusteret drift 1-scenarie Output Minus risikojusterede projektudgifter Nettogevinster 2.1 Scenarier og gevinster Det absolut væsentligste spørgsmål en business case skal besvare er om projektet eller programmet kan betale sig, altså om styregruppen eller direktionen bør vælge at bruge penge på det. Implicit heri ligger muligheden for at sige nej, altså for at vælge ikke at gøre det. For at svare på spørgsmålet er det derfor essentielt at sammenligne scenariet, hvor projektet eller programmet gennemføres, med scenariet, hvor det ikke gør. I nogle tilfælde vil et projekt eller et program nemlig udelukkende være en god investering fordi man forhindrer større fremtidige udgifter ift. ikke at gennemføre det, mens det omvendt kan være en dårlig forretning ift. den nuværende situation. I scenariet med projektet eller programmet skelnes mellem udgifter der omhandler selve projektet eller programmet og dem der omhandler den efterfølgende drift heraf, kaldet driftsudgifter. En business case indeholder derfor en analyse af tre forskellige scenarier med driftsudgifter, samt selve udgifterne til projektet eller programmet: 1) Den nuværende driftssituation, dvs. hvor meget koster det at løse den opgave i dag, som projektet eller programmet skal påvirke. 2) Projekt- eller programudgifter, dvs. hvor meget koster det at udvikle og implementere den fremtidige løsning. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [4]

3) Den fremtidige driftssituation hvis projektet eller programmet gennemføres, kaldet 1- scenariet, og hvis det ikke gennemføres, kaldet 0-scenariet. Disse er illustreret i nedenstående figur. STATENS BUSINESS CASE Nuværende drift Projekt-/programudgifter Fremtidig drift Driftsudgifter (før-situation) Projektudgifter Forskel = Risikopulje Risikojusterede projektudgifter Fremtidig drift uden projekt/program (0-scenarie) Forskel = Bruttogevinster Fremtidig drift med projekt/program (1-scenarie) Før-situation Projekt-/programudgifter 0-scenarie og 1-scenarie Figur 4. Overordnet indhold i statens business case-model 2.1.1 Før-situationen den nuværende drift Udgifter til den nuværende drift er det, det koster at udføre den opgave som projektet eller programet søger at påvirke, i dag. Det betegnes i business casen som før-situationen. Førsituationen beskriver forholdene før et projekt igangsættes, hvad det koster at udføre/drive opgaven i dag et enkelt, men et helt, års udgifter. Definition: Før-situation Den nuværende situation, før anskaffelsesfasen, med årets udgifter til at løse samme opgaver som projektet eller programmet vil påvirke - uden renter og afskrivninger. Før-situation har til formål at tegne et validt og præcist billede af, hvad løsningen af opgaven koster netop nu, dvs. på baggrund af konstaterbare udgifter og tal for ét helt år før projektets gennemførelse regnskabstallene for driften. Før-situationen kan eksempelvis bestå af de realiserede personaleudgifter forbundet med at løse opgaven samt evt. vedligehold og support på det it-system, projektet skal erstatte/udvikle. I business casen fremskrives dette ene års driftsudgifter automatisk svarende til det antal år, der analyseres. Før-situationen i business casen skal udfyldes, medmindre der er tale om nye opgaver som følge af politisk vedtagne initiativer eller implementering af national eller international lov. Før-situationen i business casen kan ikke udfyldes såfremt der er tale om helt nye opgaver, da der ikke vil være regnskabstal på driftsudgifter hertil. 2.1.2 0-scenarie I denne del af business casen er der fokus på at beskrive, hvad det i fremtiden forventes at koste at løse opgaven, hvis projektet eller programmet ikke gennemføres. Definition: 0-scenarie Driftssituationen med det billigste alternativ til at løse samme opgaver som projektet eller programmet påvirker. 0-scenariet tager højde for, at den nuværende situation ikke nødvendigvis ligner den fremtidige, selv hvis projektet eller programmet ikke gennemføres. Udgifterne forbundet med at løse de opgaver, der ville blive påvirket af projektet, kan eksempelvis stige eller falde som følge af personalebehov eller ændrede udgifter til vedligehold og support. Det er derfor nødvendigt at analysere og vurdere, om der forventes at blive anvendt flere eller færre ressourcer til at løse opgaverne, hvis projektet ikke gennemføres, før business casen kan beregnes. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [5]

Det understreges, at 0-scenariet beskriver den billigst mulige løsning som ikke er projektet eller programmet - og vil derfor som udgangspunkt være uden nyanskaffelser. Hvis der ikke er tale om nye opgaver er det almindeligt, at driftsudgifterne til it-systemer vil falde eller at kontrakterne kan genforhandles så de falder. Rådgivningscenter for it-drift i ministeriernes projektkontor kan bidrage med rådgivning omkring genforhandling af driftskontrakter. Er der tale om såkaldte brændende platforme skal 0-scenariet medtage en realistisk fremskrivning af driftsudgifter et it-system vil næsten altid kunne fortsætte med at blive brugt, desuagtet alder. Er der tale om et projekt, der fra lovgivers side er specificeret til at skulle løses på en given måde, sættes 0-scenariet lig 1-scenariet, se afsnit 4.2 for knap herfor. 0-scenariet skal altid udfyldes i business casen. Er der tvivl om, hvad der udgør det korrekte 0-scenarie kan Ministeriernes projektkontor kontaktes. 2.1.3 1-scenarie 1-scenariet er det andet af de to fremtidige driftssituationer, som business casen omfatter. Scenariet beskriver den fremtidige situation med projektet eller programmet, dvs. at det ønskede initiativ gennemføres og har den forventede virkning på de fremtidige driftsudgifter. Definition: 1-scenarie Projektudgifter, samt driftssituationen med projektet eller programmet fra de første gevinster realiseres. Det samlede 1-scenarie består derfor af to dele: Estimat på de forventede udgifter til den fremtidige drift, samt de forventede udgifter til selve initiativet, altså engangsudgifter, der skyldes projektet/programmet. Eksempelvis vil et nyt system fortsat kræve personaleressourcer og vedligehold samt evt. support, om end der kan være tale om lavere udgifter end tidligere og potentielt et helt andet system, en anden leverandør eller en anden arkitektur. Som hovedregel vil den indledende analyse af projektet eller programmet beskæftige sig med mere end ét løsningsscenarie, som gennem flere iterationer forkastes eller videreanalyseres. Det understreges, at statens business case-model, grundet sit detaljeringsniveau, som udgangspunkt kun beskæftiger sig med et løsningsscenarie for 1-scenariet. Projektet eller programmet skal derfor forud for udarbejdelsen af 1-scenariet i statens business case have lagt sig fast på omfanget af initiativet og den forventede fremtidige effekt på driftsudgifterne. 2.1.4 Gevinster Når vi har tal for før-situationen og de to fremtidsscenarier, kan projektets gevinster beregnes. Definition: Gevinst En gevinst er det, man får ud af at gennemføre projektet eller programmet. En gevinst kan altid kvantificeres og måles, uanset om det er i kr. eller anden enhed. Gevinsterne er forskellen på at implementere projektet eller programmet og ikke at gøre det. Gevinsterne kan derved godt være negative. For økonomiske gevinster skelnes mellem bruttogevinster og nettogevinster. Bruttogevinster fremkommer ved at sammenligne de to fremtidige scenarier for driften hvad er udgiften til fremtidig drift, hvis vi gennemfører projektet eller programmet sat i forhold til hvad udgiften Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [6]

vil være, hvis initiativet ikke gennemføres. Fratrækkes projektudgifterne fra bruttogevinsterne fås nettogevinsterne, som er den samlede gevinst fratrukket alle udgifter, som projektet eller programmet vil bibringe myndigheden, hvis initiativet gennemføres. En gevinst kan enten beregnes som forskellen mellem 0-scenariet og 1-scenariet (sammenligning med forventet, fremtidig drift) eller som forskellen mellem før-situationen og 1-scenariet (sammenligning med nuværende situation). Begge beregninger er vigtige at medtage, men det er forskellen mellem 0-scenariet og 1-scenariet, der giver det bedste grundlag for at kunne træffe en oplyst investeringsbeslutning. Det er denne beregning, der i statens business case-model er grundlaget for gevinster, som vist i figuren. Af figuren ses, at det viste projekt har en positiv nettogevinst, idet driftsudgifterne i 0-scenariet samlet er større end summen af projekt- og driftsudgifterne i 1- scenariet. Gevinster kan både være positive og negative. Figur 5. Eksempel på sammenhæng mellem scenarier og beregning af gevinster. Før-situationen og de to scenarier kan tegnes ind ift. hinanden så det står klart, hvad udgifterne er for de enkelte scenarier og derved underbygge et informeret valg af løsning. Dette er skitseret i figuren herunder. Figur 6. Eksempel på en skitsering af de tre scenarier. I eksemplet fastholder før-situationen de nuværende udgifter, mens 0-scenariet for det givne projekt forventer støt stigende driftsudgifter, hvis projektet ikke gennemføres. Ved 1- scenariet, der både inkluderer selve projektudgifterne samt den efterfølgende drift, hvis projektet gennemføres, kan de store udgifter til projektet observeres i starten, hvorefter der i eksemplet forventes faldende driftsudgifter. I statens business case-model skelnes der mellem effektiviserings- og kvalitetsløftsgevinster. Både effektiviseringsgevinster og kvalitetsløftsgevinster beregnes på baggrund af sammenligningen af 0- og 1-scenariet. 2.1.5 Effektiviseringsgevinster Ved effektiviseringsgevinster forstås økonomiske gevinster, som direkte påvirker myndigheden. Dvs. gevinsten kan indbudgetteres og henføres til en specifik, offentlig konto. Gevin- Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [7]

sterne kan, når de realiseres, enten blive i myndigheden og give mulighed for, at myndigheden kan løfte andre opgaver, eller gevinsterne kan tages ud af den enkelte myndighed og bruges til tværgående prioriteringer. Det er et spørgsmål om gevinstrealiseringsstrategien og planlægningen af høsten af de pågældende gevinster som begge beskrives i PID en for projekters vedkommende og i gevinstrealiseringsplanen for programmer. I udregningen af et projekts eller programs effektiviseringsgevinster, skelner business casen mellem bruttogevinsten og nettogevinsten. Bruttogevinsten udgør forskellen mellem driftsudgifterne i 0-scenariet og 1-scenariet, mens nettogevinsten, som vist i figuren indledningsvist i afsnit 2, tager højde for projektudgifterne. Hverken bruttogevinsten eller nettogevinsten siger i sig selv noget om, hvorvidt et projekt økonomisk set er attraktivt, eller om projektet i øvrigt er en god ide. Brutto- og nettogevinster tager nemlig ikke højde for, at gevinster, der høstes om lang tid, er mindre værd, end gevinster der høstes i dag. Samtidig tager brutto- og nettogevinster ikke højde for investeringens størrelse set i forhold til investeringens afkast. Her ses i stedet på nettonutidsværdien, der beregnes på baggrund af nettogevinsten. Nettonutidsværdien er forklaret under Centrale nøgletal i business case-resumeet, i afsnit 4.3. 2.1.6 Kvalitetsløftsgevinster I statens business case-model forstås kvalitetsløftsgevinster som gevinster, der kan kvantificeres, men hvor det ikke kan angives på hvilken offentlig hovedkonto, gevinsterne vil falde. Kvalitetsløftsgevinster skal dokumenteres og kvantificeres, og det er kun målbare kvalitetsløftsgevinster, der medtages i regnearket i business case-modellen. Gevinster, der ikke kan måles, kan beskrives skriftligt i PID en for projekter, eller i gevinstrealiseringsplanen for programmer. Kvalitetsløftsgevinster opdeles på ikke-økonomiske gevinster, fx i form af øget brugertilfredshed målt på tiden på en arbejdsopgave eller at antallet af fejlsager mindskes, og økonomiske gevinster for private og virksomheder. Sidstnævnte henfører til, at projekter som staten iværksætter godt kan give direkte økonomisk værdi for borgerne og de private virksomheder, uden at det har en økonomisk værdi for den udførende myndighed. Et eksempel herpå kunne være et projekt omkring frigivelse af geodata, som eksempelvis private virksomheder vil kunne benytte i kommercielle applikationer. Projektet giver derfor økonomisk værdi til de private virksomheder uden at myndigheden nødvendigvis selv kan opnå en økonomisk effekt. 2.1.7 Realiseringsfase og aktivering For at kunne beregne om et projekt eller program er en god investering eller ej, er et helt centralt spørgsmål, hvor lang tid gevinster kan tælles med og derved hvor store de samlede gevinster vil være. I statens business case-model skal driftsudgifter, og dermed gevinster, tælles med fra det tidspunkt de afholdes, desuagtet fase. Dvs. at fra den første ibrugtagning eller idriftsættelse af dele af projektets leverancer, vil de dele af driftsudgifterne der stammer herfra skulle medtages. Driftsudgifter, og derved gevinster, medtages indtil projektets aktiv er helt afskrevet, altså når dens forventede levetid er opnået. Disse levetider kan være hhv. 3, 5 eller 8 år, og styres af Moderniseringsstyrelsen. Er der tale om flere aktiver med forskellige levetider eller blot med forskellige ibrugtagningstidspunkter, således at sluttidspunktet for alle projektets aktiver ikke er ens, medtages alle driftsudgifter stadig indtil det sidste aktiv er fuldt afskrevet. Til gengæld skal de årlige afskrivningsomkostninger for evt. fuldt afskrevne aktiver fremskrives og tillægges i business casens 1-scenarie indtil det sidste aktiv er fuldt afskrevet. Dette har kun beregnings- og ikke budgetmæssig betydning. 2.2 Nedbrydning af udgifter i forudsætninger 2.2.1 Forudsætninger En business case er aldrig bedre end de data den består af, og de analyser der ligger til grund. Med andre ord er modellen afhængig af, at de enkelte udgifter i business casen er estimeret så korrekt som muligt. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [8]

I business case-modellen gøres dette ved at nedbryde udgifterne og deres sammenhænge i forudsætninger, som illustreres i et forudsætningsdiagram (se afsnit 4). Formålet med nedbrydningen er at gøre estimaterne mere sikre. Eksempelvis vil et estimat opgjort overordnet for de samlede udgifter til eksterne konsulenter være mere usikkert, end hvis udgiften er nedbrudt i fx timeantal og timepris, og der for begge disse to udgiftstyper eller forudsætninger, er lavet en bevidst overvejelse om, hvor mange timer, der forventes anvendt, og hvilken type konsulenter (og følgende timepris) det drejer sig om. Dvs. at selvom business casen regner på de samlede projektudgifter og de samlede driftsudgifter i de enkelte scenarier, bygger disse samlede udgifter på flere, mindre dele. Disse mindre dele er altså forudsætninger for de samlede udgifter og det niveau, hvor projektet bliver så konkret, at det er muligt at estimere. Det er derfor et krav i statens business case-model, at forudsætningerne for hhv. projektudgifter og driftsudgifter tydeliggøres. En anden fordel ved nedbrydningen er, at det styrker muligheden for at styre projektet. Projektlederen får lettere ved at følge udgifterne og kan dermed handle på, hvilke dele af projektet der forløber planmæssigt, og hvilke dele der potentielt koster mere eller mindre end oprindeligt estimeret. Afsnit 4 gennemgår selve brugen af regnearket business casen i detaljer, herunder også hvordan man laver og udfylder forudsætningsdiagrammet. 2.2.2 Udgifter Både før-situationen, projektudgifter og opgørelse af den fremtidige drift i form af 0 og 1- scenariet omhandler opgørelse af udgifter. Udgifter i en business case er de bekostninger, der enten afholdes af, eller påvirkes af resultatet af projektet eller programmet. Der kan være tale om udgifter i flere organisationer, hvis initiativet fx er fællesoffentligt og tiltænkt at skabe forandring i flere organisationer. Der skelnes mellem udgifter, der er forbundet med at drive eller udføre bestemte opgaver, driftsudgifter, og de (engangs)udgifter, der er knyttet til at gennemføre selve projektet eller programmet, projekt-/programudgifter. Typiske driftsudgifter vedrører drift og forvaltning af it-systemet (fx vedligeholdelse, administrative udgifter eller licenser) og fagspecifikke arbejdsgange. Typiske projekt- /programudgifter vedrører analyse, projektledelse, implementering, transport, test, software-udvikling, hardware og licenser. 2.3 Risici, usikkerhed og trepunktsestimering Når forudsætningerne udgiftstyperne for en business case er identificeret og nedbrudt, og udgifterne skitseret starter arbejdet med at vurdere usikkerheden af estimaterne af udgifterne. Estimater af udgifter i en business case er ofte forbundet med en usikkerhed, da der dels kan være en række risici forbundet med en udgift som gør, at udgiften bliver enten dyrere eller billigere end forventet, dels vil være en generel estimeringsusikkerhed. Disse risici og usikkerheder skal identificeres og vurderes før business casen udarbejdes, se vejledning om risikostyring og anvendelse af risikoregisteret. Grundtanken omkring risici er, at man ikke kan være sikker på, hvilke risici, der indtræffer, og hvilke der ikke gør. I stedet arbejdes med et usikkerhedsspænd indenfor hvilket den endelige pris for den enkelte udgift eller forudsætning vil lande. Usikkerhedsspændet skal derfor afspejle de risici, der kan indtræffe, samt den generelle estimeringsusikkerhed. 2.3.1 Trepunktsestimering I statens business case-model konstrueres et usikkerhedsspænd for en udgift ved hjælp af en trepunktsestimering. Herved forstås, at man angiver et middelestimat, som er det forventede estimat desuagtet risici, altså et ikke-risikojusteret estimat. Middelestimatet er med andre ord den pris, som man forventer der skal betales, eller det timeforbrug man forventer der skal bruges. Herefter angives et lavt estimat (best case), som er det realistisk laveste estimat, givet de risici der kan indtræffe og have betydning for denne forudsætning. Slutte- Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [9]

ligt angives et højt estimat (worst case), som er det realistisk højeste estimat, givet de risici der kan indtræffe. For at kunne fastlægge den usikkerhed, der er forbundet med det givne estimat så præcist som muligt, er det nødvendigt at angive sandsynligheden for, at de forskellige estimater indtræffer. Dette gøres i business case ved et procentvist estimat af, hvor sandsynlige hhv. det lave estimat, det høje estimat og middelestimatet er. Nye forudsætninger i business case-modellen er på forhånd indstillet til en trekantssandsynlighedsmodel, hvor middelestimatet er mest sandsynligt, og det lave (best case) og høje (worst case) estimat mindre sandsynlige. Dette vil være den langt mest almindelige sandsynlighedsfordeling. Der vil dog være store forskelle på trekantens form, alt afhængigt af om projektet eller programmet vurderer, om det høje og lave estimat er lige sandsynlige eller ej. Som oftest vil de høje estimater at prisen bliver mere end forventet - være mere sandsynligt end man oprindeligt påtænker. Som projektleder er der ofte en tendens til at være alt for optimistisk på projektets vegne, bevidst eller ubevidst. Det er også muligt at vælge andre sandsynlighedsfordelinger samt at fravælge trepunktsestimeringen, hvis estimatet for forudsætningen ikke er usikker. På baggrund af det indlagte usikkerhedsspænd mellem de tre estimater, og sandsynligheden for at de indtræffer, udregner modellen et risikojusteret estimat. Denne udregning er et gennemsnit af de indtastede estimater, vægtet efter sandsynligheden. Risikopuljen for den pågældende forudsætning er forskellen på middelestimatet, altså hvad der forventes, og det risikojusterede estimat. Sandsynlighedsmodellers betydning for indtastning af estimat Ikke usikker: Estimatet er ikke usikkert og angives kun i middelværdien. Det kunne for eksempel være regnskabstal. Trekant: Den mest almindelige sandsynlighedsmodel. Estimatet er mindre usikkert. Middelestimatet er mest sandsynligt, og det lave (best case) og høje (worst case) estimat mindre sandsynlige. Det kunne for eksempel være antallet af timer til et projekt. Tilfældig: Estimatet er meget usikkert, og sandsynligheden er tilfældig for hvorvidt resultatet er lavt eller højt. Brugerdefineret (diskret): Estimatet er diskret med maksimalt tre forskellige udfald defineret af brugeren. Altså kan udfaldet være enten lavt, middel eller højt, men ikke et resultat imellem estimaterne. Kan for eksempel anvendes ved udbud, hvor man har fået tre fastpristilbud. Hvis usikkerhedsspændet er symmetrisk, således at der er lige så stor sandsynlighed for et positivt udfald som for et negativt udfald, og at spændene fra middelestimatet til hhv. det høje og lave estimat er lige store, vil det risikojusterede tal og det ikke-risikojusterede middelestimat være ens. Dette vil betyde, at der ikke tillægges nogen risikopulje. Hvis usikkerhederne rundt om det forventede estimat til gengæld er asymmetriske, således at der er større sandsynlighed for enten det lave eller det høje estimat, eller at spændet fra middelestimatet til det lave estimat enten er større eller mindre end spændet til det høje estimat, vil der være forskel på det ikke-risikojusterede middelestimat og det risikojusterede tal. I så fald vil der være en risikopulje. Dette er illustreret med eksempler i figur 8. For alle de vist forudsætninger forventes udgiften at blive 20.000 kr. Ved forudsætning A bliver resultatet af risikojusteringen, at også det risikojusterede estimat bliver 20.000 kr. Dette skyldes, at det lave og det høje estimat afviger lige meget fra det ikke-risikojusterede middelestimat (de er hhv. 10 højere og 10 lavere), samt at der er lige stor sandsynlighed for det høje som for det lave estimat. Der tillægges altså ikke nogen risikopulje. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [10]

Ved forudsætning B afviger det høje estimat mere fra middelestimatet end det lave estimat. Det høje estimat ligger 30 over middelestimatet, hvor det lave estimat kun ligger 5 under. Dette påvirker det risikojusterede resultat, således at det risikojusterede estimat bliver 6.300 kr. højere end middelestimatet. Sandsynligheden for at det lave og høje estimatet indtræffer, er den samme, men den større forskel mellem det høje estimat og middelestimatet trækker det vægtede gennemsnit i retning mod det høje estimat. Der tillægges altså en risikopulje på 6.300 kr. Ved forudsætning C er spændet mellem middelestimatet og hhv. det høje og lave estimat igen den samme. Men her har projektet vurderet, at der er langt større sandsynlighed for, at det høje estimat indtræffer (45 pct. sandsynligt) end det lave (5 pct. sandsynligt). Dette trækker igen det vægtede gennemsnit det risikojusterede estimat højere end det ikkerisikojusterede middelestimat. Igen tillægges der en risikopulje i dette tilfælde på 4.000 kr. Figur 7. Eksempler på trepunktsestimering Ved forudsætning D er spændet mellem det lave estimat og middelestimatet større end spændet mellem det høje estimat og middelestimatet. Da sandsynlighederne for hhv. det høje og lave estimat er ens, trækkes det vægtede gennemsnit i retning mod det lave estimat. Resultatet bliver en negativ risikopulje på -1.250 kr. Det er i sig selv ikke et problem, at risikopuljen er negativ for en enkelt forudsætning eller udgift, det betyder, at der risici in mente kan budgetteres med at spare penge her ift. det oprindeligt forventede middelestimat. 2.3.2 Den samlede risikopulje Dem samlede risikopulje er summen af risikopuljerne for hver enkelt hovedforudsætning. Hver af disse risikopuljer udregnes som beskrevet ovenfor som forskellen på det forventede estimat og det risikojusterede estimat. For et projekt eller program som helhed, hvor alle risikopuljer slås sammen til en samlet risikopulje, er det urealistisk, at usikkerhed og konkrete risici medfører, at der kan budgetteres med at spare penge ift. de forventede estimater. Konkret medfører en negativ risikopulje også, at projektet ift. Statens IT-projektråd holdes op mod et lavere budget end det forventede, da baseline for statusrapporteringerne er det risikojusterede budget. Det er centralt, at usikkerhedsspændene er realistiske og afspejler de risici, der kan indtræffe. Der er ikke nogen lette svar på, hvad risici koster, og der vil ofte være tale om at kvalificere sine gæt så meget som muligt gennem analyser og ved at spørge fagpersoner, der har viden om den givne udgift eller risiko. De enkelte projektmyndigheder bør i forbindelse med udarbejdelsen af business casen fastlægge velbeskrevne og klare retningslinjer for anvendelsen af risikopuljen, herunder sikre, at ledelsen i et nødvendigt omfang er involveret. Det er vigtigt at være opmærksom på, at Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [11]

business casen er udgiftsbaseret. Dette betyder, at budgettet skal omformes til omkostninger, inden den endelig budgeteffekt kan udregnes. 2.3.3 Primær og sekundær risiko I modellen kan der ved hver hovedforudsætningsgruppe angives, hvilken risiko, der primært driver usikkerheden i de underliggende underforudsætninger. Denne vælges på baggrund af de væsentlige risici som projektet har identificeret og tastet ind i regnearket, se afsnit 4. Hvis der ikke vælges en risiko, vil modellen antage, at der er tale om generel usikkerhed. Dette betyder, at om end estimatet er usikkert, så kan der ikke peges på en konkret risiko, der driver denne usikkerhed. Der kan tillige vælges en sekundær risiko, hvis der er flere forhold, der påvirker estimatets udfald. Vælges der både en primær og sekundær risiko, vil risikobeløbet vægte den primære risiko med 70 procent og den sekundære med 30 procent. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [12]

3 Opsætning af business casen Dette afsnit indeholder en beskrivelse af, hvordan business casen opsættes til anvendelse for det konkrete projekt eller program. Der er fokus på, hvornår man skal vælge den ene opsætning frem for en anden og konsekvenserne heraf. Første gang regnearket med business casen åbnes i Excel skal business casen opsættes, så den passer til det konkrete projekt eller programs kontekst og behov. Det understreges, at der om den samme Excel-fil med makroer, blot med forskellig opsætning. Forståelsen og anvendelsen af de gennemgående kernebegreber, beskrevet i afsnit 2, er ens for alle opsætninger. Hertil bemærkes, at langt hovedparten af modellens ark og funktioner er ens uanset opsætningen disse er beskrevet nærmere i afsnit 4. Business casen kan opsættes indenfor fire kategorier: Organisering, risikoprofil, størrelse og kontering. Det beskrives i efterfølgende afsnit, hvad der skal vælges, hvorfor opsætningerne er forskellige, samt den konkrete effekt på business casens udformning. 3.1 Opsætning af organisering Business casen skal opsættes til den konkrete organisering, hvortil der er tre valgmuligheder: Projekt, program eller projekt i program. For at imødekomme ændringer i organiseringer, også efter projekter eller programmer er sat i gang, kan valget af organisering løbende justeres uden at miste data. 3.1.1 Projekt Projekter organiseres og styres efter retningslinjerne fastlagt i den fællesstatslige itprojektmodel, hvori business case-modellen indgår. Projekter vil have egne projektudgifter og ansvar for, at alle gevinster realiseres. Dvs. både udgifter og gevinster vil fremgå af business casen for et projekt. Definition: Projekt En midlertidig organisation der etableres for at levere en eller flere leverancer iht. realisering af en business case. Projekter i statens business case-model inkluderer derfor både et ark til at indtaste projektudgifter samt ark til driftsudgifter og gevinster for de enkelte scenarier, som beskrevet i afsnit 2. 3.1.2 Program Programmer organiseres og styres efter retningslinjerne fastlagt i den fællesstatslige programmodel, hvori business case-modellen indgår. Et program består modsat projekter af to eller flere projekter samt andre aktiviteter, der hver især bidrager til en samlet opfyldelse af programmets mål og realisering af gevinster. Gevinster opgøres derfor i business casen ikke på de enkelte projekter. For programmer ligger business casen og opfyldelsen af denne derfor på programniveauet. På samme måde som for projekter er det derfor nødvendigt at have et klart overblik over både programmets samlede udgifter og de efterfølgende driftsscenarier og gevinster, som beskrevet i afsnit 2. Programmets udgifter indeholder udgifter til selve programorganisationen, den generelle ledelse af programmet, samt udgifterne til de enkelte projekter, der er en del af programmet. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [13]

Definition: Program En midlertidig fleksibel organisationsstruktur, der er oprettet for at koordinere, styre og overvåge gennemførelsen af en gruppe gensidigt afhængige projekter og aktiviteter for at levere en samlet business case i form af resultater og gevinster, der understøtter samme vision. I statens business case-model sikres det bedste operationelle overblik over projekters udgifter og forbrug ved at fastholde ansvaret på projektplan ud fra et nærhedsprincip. Dette betyder, at hvert enkelt projekt i programmet skal udforme deres egen udgiftsdel af en business case. Denne laves i deres egne Excel-filer, som styres af projekterne selv, mere herom under projekt i program. Figur 8. Business casen for programmer og deres projekter. Programmets business case Nuværende drift (før-situation) Programudgifter Fremtidig drift (0 og 1-scenarie) Program Projekt i program Nuværende drift Projekt A Nuværende drift Projekt B Projektudgifter Projekt A Projektudgifter Projekt B Som det fremgår af ovenstående figur vil det ofte ikke være relevant at udarbejde førsituationen for programmer og dermed for projekter i programmer. Dette skyldes, at der typisk for programmer er tale om gennemgribende forandringer og opgaver, som ikke løses i den nuværende situation. Ministeriernes projektkontor kan kontaktes, såfremt der for et program er tvivl om hvorvidt, der skal udarbejdes en før-situation i business casen. 3.1.3 Projekt i program For projekter, der indgår som del af et program ligger gevinsterne, og derved estimeringen af de fremtidige driftsscenarier, på programniveauet. Projektet leverer altså ikke i sig selv gevinster, men leverancer, der gør programmet i stand til at opnå en forandringsevne som i sidste ende gerne skal resultere i opnåelse af programmets vision og høstningen af gevinster. Definition: Projekt i program En midlertidig organisation, der etableres for at levere en eller flere leverancer til opnåelse af forandringsevne. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [14]

Som illustreret i figur 9, og beskrevet i afsnittet program, er projekterne i et program ansvarlige for deres egne projektudgifter og skal som konsekvens selv udforme en udgiftsdel af en business case i en separat fil. Idet projekterne følger den fællesstatslige itprojektmodel vil denne business case være enslydende med en normal business case for projekter med den væsentlige undtagelse, at der ikke vil være mulighed for at indtaste driftsudgifter for den fremtidige drift 0- og 1-scenariet. Dette skyldes, at gevinster indgår i beregningen og outputtet fra den fremtidige drift og da det netop er programmet, der er ansvarlig for at beregne og hente gevinsterne, findes dette ikke på projektniveau. Det kan dog stadig være en god ide at komme med input til programledelsen til estimeringen af disse scenarier, men forankringen ligger på programniveau. 3.2 Opsætning af risikoprofil Den anden opsætningsmulighed i business casen relaterer sig til risikoprofilen for det pågældende projekt eller program. Alle projekter og programmer, der gennemgår en risikovurdering i Statens IT-projektråd, bliver vurderet til at have normal eller høj risiko. Som udgangspunkt vil projekter og programmer over 60 mio. kr. være i høj risiko. Dette er dog altid en konkret vurdering fra sag til sag, som vil blive fastlagt endeligt af Statens it-projektråd. Der kan løbende ændres i valget af risikoprofil uden at miste data. 3.2.1 Normal risiko Projekter eller programmer vurderet til normal risiko vil beregne deres risikojusterede udgifter som beskrevet i afsnit 2. Risikopuljen vil her være forskellen på de ikke-risikojusterede projektudgifter (middelestimaterne) og de risikojusterede projektudgifter (risikojusterede estimater). Dette er det mest hyppige tilfælde og valget af risikoprofil vil derfor som udgangspunkt stå til normal risiko. 3.2.2 Høj risiko Vurderes et projekt eller et program til at være i høj risiko skal der udover ovennævnte normale risikopulje tillægges en ekstra højrisikopulje. Beregningen af de risikojusterede projekt- eller programudgifter inklusiv denne højrisikopulje sker ved hjælp af monte carlo-simulering. Det samlede budget ved monte carlo-simulering findes ved at beregne det budget, der er 70 procent sandsynligt. Dette inkluderer både en normal risikopulje samt en højrisikopulje, der er forskellen mellem den normale risikopulje og budgettet der er 70 procent sandsynligt. Både den normale risikopulje og højrisikopuljen udregnes på baggrund af monte carlo simuleringen. Vælges høj risiko under risikoprofil åbner det op for muligheden for at monte carlo-simulere business casen gennem programmet @Risk. Såfremt en business case skal simuleres og myndigheden ikke selv har adgang til programmet @Risk, er Ministeriernes projektkontor behjælpelige hermed. Den samlede risikopulje indbudgetteres som beskrevet i vejledningen indbudgettering af risikopulje ifm. nye it-projekter, der er optaget i ØAV og kan findes her. 3.3 Opsætning af størrelse Valg af størrelse er mest relevant for projekter, da programmer budgetmæssigt vil have et betydeligt omfang. Valget af størrelsen på projektet har mindre betydning for udformningen af business case-modellen, men er snarere en mulighed for at komme let og hurtigt i gang for mindre projekter. 3.3.1 Over 10 mio. kr. Større it-projekter med samlede udgifter på over 10 mio. kr. har hidtil været normalen for brugen af statens business case-model. Det er derfor det valg, der står som udgangspunkt i kategorien størrelse. 3.3.2 Under 10 mio. kr. For mindre projekter kan det være ressourcetungt at skulle indtaste mange forskellige forudsætninger og lave forudsætningsdiagrammet. Vælges projekter under 10 mio. kr. i størrelse vil der i business casen automatisk blive indsat de mest almindelige hovedforudsætninger Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [15]

(udgiftstyper) i et it-projekt i regnearket. Dette kan bidrage til at skabe et overblik over de projektudgifter og driftsudgifter i forbindelse med et it-projekt, og dermed hurtigt sætte gang i analysen, der skal føre til en kvalificeret beslutning om at igangsætte et it-projekt. Den gennemgående metode er ikke ændret og de gængse funktionaliteter, beskrevet i afsnit 4, vil stadig være gældende. Dog vil det sjældent være nødvendigt at nedbryde udgifterne i samme omfang, hvilket også nedsætter tastearbejdet. De indsatte hovedforudsætninger kan slettes og redigeres, så det passer til det konkrete projekt. 3.4 Opsætning af kontering Det sidste valg, der skal træffes for at forme business casen efter de konkrete behov, er valget af kontering. Kontering er væsentlig idet udgifterne kvalificeres, hvilket gør det nemmere at økonomistyre og udregne afskrivningsprofiler efterfølgende, samt gør det muligt at få flere informationer fra tabellerne i business case-resumeet. Som udgangspunkt indeholder kontering ni konti, der er de oftest anvendte for it-projekter og kan henføres til den statslige kontoplan. Beskrivelse af den statslige kontoplan kan findes her. Det er muligt at tilføje og redigere listen med konti, hvilket kan være relevant i forbindelse med tværoffentlige projekter og programmer. Disse valg kan ændres løbende. Definitioner for de ni oftest anvendte konti for it-projekter: Personaleudgifter: Direkte udgifter til interne medarbejdere og medarbejderspecifikt overhead. Udgifter her svarer til statens kontering på standardkonto 18 inklusiv underliggende finanskonti. Køb af IT-tjenesteydelser: Konsulentbistand til it-projekter, der ikke aktiveres, vedligeholdelseskontrakter, datakommunikation, etc. Udgifter her svarer til statens kontering på finanskonto 22.65. Køb af tj.ydelser i øvrigt: Konsulentbistand, advokatbistand, kursusafgifter, databehandling, installationsudgifter, etc. Udgifter her svarer til statens kontering på finanskonto 22.70. Andre ordinære driftsomkostninger: Dækker de resterende udgifter, der ikke kan henføres til ovenstående finanskonti fx it-varer og øvrige varer under bagatelgrænsen, der umiddelbart forbruges regnskabsmæssigt. Udgifter her svarer til statens kontering på standardkonto 22 inklusiv underliggende finanskonti, men eksklusiv finanskonto 22.65 og 22.70. Personaleomkostninger, der kan aktiveres: Personaleudgifter, der kan aktiveres ift. reglerne herom i Finansministeriets Økonomisk-Administrative Vejledning. Du kan læse mere i ØAV her. Immaterielle anlægsaktiver: Aktiver uden fysisk substans, som er erhvervet til vedvarende eje eller brug, fx it-systemer. Udgifter her svarer til statens kontering på standardkonto 50 inklusiv underliggende finanskonti. Materielle anlægsaktiver: Aktiver med fysisk substans, som er erhvervet til vedvarende eje eller brug, fx servere, it-udstyr, etc. Udgifter her svarer til statens kontering på standardkonto 51 inklusiv underliggende finanskonti. Omsætningsaktiver: Aktiver, der har brugstid på under ét år. Udgifter her svarer til statens kontering på standardkonto 60 inklusiv underliggende finanskonti. Indtægter: Indtægter (fx salg af vare- og tjenester og gebyrindtægter) kan i visse tilfælde indføres i driftsscenarierne (0- og 1-scenariet). Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [16]

4 Brugen af business casemodellen Dette afsnit indeholder en mere detaljeret beskrivelse af den konkrete brug af business casemodellen, herunder en beskrivelse af udarbejdelse af forudsætningsdiagrammet, udfyldelsen af regnearket og tolkningen af business case-resuméet. Udarbejdelsen af statens business case-model består af tre trin: Et forudsætningsdiagram, der nedbryder de forskellige udgiftstyper for projektet eller programmet. Forudsætningsdiagrammet kan med fordel konstrueres på baggrund af et gevinstdiagram. Herefter udarbejdes en business case, der omfatter en estimering af forudsætninger (udgifter) i regnearket. Estimeringen bygger på den risikoanalyse og scenariebeskrivelse der er lavet for projektet eller programmet samt metoden trepunktsestimering. Det sidste trin er et business caseresumé, der er forståelsen for resultaterne af beregningerne. De tre trin bør følges i den nævnte rækkefølge. Forudsætningsdiagrammet fungerer som en visuel guide til den efterfølgende indtastning i regnearket - alle forudsætninger i forudsætningsdiagrammet skal indtastes direkte i regnearket efterfølgende. 4.1 Forudsætningsdiagram Der er ofte mange forudsætninger eller udgiftstyper i en business case og derfor kan en visualisering hjælpe med at bryde forudsætningerne ned i mindre, mere håndterbare dele. Visualiseringen af projektets eller programmets forudsætninger sker ved hjælp af et såkaldt forudsætningsdiagram. Figur 6 skitserer et standard-forudsætningsdiagram indeholdende forudsætninger, som er typiske for mange projekter. Timepris (intern) Antal timer Interne Vedligeholdelse (intern) ressourcer Timepris Eksterne Driftudgifter (0 og 1- scenarie) (ekstern) Antal timer (ekstern) ressourcer Administrative udgifter Licenser Drift og forvaltning af system Driftudgifter (både 0 og 1- scenariet) Årsværkspris Arbejdsproces A Tid per sag Interne ressourcer Arbejdsproces B Fagspecifikke arbejdsgange Antal sager Arbejdsproces C Nettogevinster Timepris (intern) Analyse Antal timer (intern) Interne ressourcer Projektledelse Timepris (ekstern) Eksterne ressourcer Uddannelse Kommunikation Implementering Projektudgifter Antal timer (ekstern) Vejledninger Timepris (intern) Transport og øvrige udgifter Projektudgifter Antal timer Interne Funktionalitet A Test (intern) ressourcer Funktionalitet B Timepris (ekstern) Eksterne ressourcer Funktionalitet C Software udvikling Antal timer (ekstern) Hardware Hovedforudsætning med underforudsætninger Hovedforudsætning uden underforudsætninger Underforudsætning (med usikkerhed) Underforudsætning (mellemregning) Figur 9. Standard-forudsætningsdiagram. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [17]