Vejledning til statens business case- model

Transkript

1 Vejledning til statens business case- model August 2013 Den fællesstatslige it-projekt-/programmodel, model, Digitaliseringsstyrelsen

2 Indhold 1 INDLEDNING FORMÅL HVAD ER EN BUSINESS CASE? LÆSEVEJLEDNING KOBLING TIL DEN FÆLLESSTATSLIGE IT-PROJEKTMODEL KOBLING TIL DEN FÆLLESSTATSLIGE PROGRAMMODEL PROCESSER OG FORMKRAV FOR DIG, DER HAR BRUGT BUSINESS CASE-MODELLEN FØR KERNEBEGREBER NUVÆRENDE DRIFT FREMTIDIG DRIFT GEVINSTER FORUDSÆTNINGER OG UDGIFTER OPSÆTNING AF BUSINESS CASEN OPSÆTNING AF ORGANISERING OPSÆTNING AF RISIKOPROFIL OPSÆTNING AF STØRRELSE OPSÆTNING AF KONTERING BRUGEN AF BUSINESS CASE-MODELLEN FORUDSÆTNINGSDIAGRAM REGNEARKET BUSINESS CASE-RESUMÉ KVALITETSSIKRING AF EN BUSINESS CASE 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 En business case er en beregning af de samlede økonomiske og ikke-økonomiske konsekvenser af en potentiel investering, såsom et projekt eller et program. Den bygger på en analyse og opgørelse af, hvilken forandring man ønsker, og hvordan den opnås. 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. 1.2 Hvad er en business case? Statens business case-model Statens business case-model består af tre elementer: 1. Et forudsætningsdiagram 2. Et regneark 3. Et business case-resumé Forudsætningsdiagrammet bidrager til at nedbryde de forventede gevinster i de forskellige udgiftstyper, der findes i et projekt. Det illustreres visuelt i et diagram, se tillige afsnit 4.1. Figur 1. Elementer i statens business case-model Regnearket er udarbejdet i Excel og indeholder business casen. Business casen opgør mulige gevinster ved den fremtidige drift, såfremt projektet eller programmet gennemføres, dels opgøres nuværende drift samt projekt- eller programudgifter. Dette er yderligere beskrevet i efterfølgende afsnit, samt afsnit 2. Business case-resumeet er beregnet som ledelsesinformation og summerer de væsentligste nøgletal og tabeller fra business casen. Resumeet anvendes også i forbindelse med udarbejdelse af it-aktstykker, se afsnit Statens business case Statens business case indgår i den fællesstatslige it-projektmodel of programmodel. En business case er en udvidet cost-benefit-analyse af et givent it-projekt eller program. 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, både når man ser på den fremtidige drift på det område, som skal løftes, og når man ser på projekteller programudgifterne. Business casen sikrer også, at risikopuljen passer til risikoprofilen, således at der ikke opbygges større reserver end nødvendigt. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [1]

4 En business case består derfor overordnet af en analyse af tre forhold: 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. 3) Den fremtidige driftssituation hvis projektet eller programmet gennemføres og hvis det ikke gennemføres. Ved at se på den fremtidige driftssituation både med og uden projektet eller programmet kan man i business casen beregne den gevinst, der er ved at iværksætte initiativet. Business casens overordnede elementer er illustreret i nedenstående figur. Figur 2. Indhold i statens business case 1.3 Læsevejledning I afsnit 2 beskrives kernebegreberne i statens business case-model. Afsnit 3 gennemgår mulighederne for forskellig anvendelse af modellen, herunder specielt business casen, og i afsnit 4 beskrives den konkrete brug af regnearket. Afsnit 5 beskriver kvalitetssikring af en udfyldt business case. 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.4 Kobling til den fællesstatslige it-projektmodel I it-projektmodellen fungerer business casen sammen med projektinitieringsdokumentet (PID en) som det centrale styringsprodukt som 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 [2]

5 Figur 3. 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 alle efterfølgende faseovergange (defineret af den fællesstatslige it-projektmodel) og ved væsentlige ændringer. 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 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 4. Den fællesstatslige programmodel. b 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). Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [3]

6 1.6 Processer og formkrav 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 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 ). 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. ovenfor) 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. 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.7 For dig, der har brugt business case-modellen før Den væsentligste nyudvikling med opdateringen af 27. august 2013 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 0. Det skal understeges, at anvendelsen af business casen, uanset opsætning, hviler på de samme grundlæggende kernebegreber og metodik. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [4]

7 2 Kernebegreber I dette afsnit præsenteres business casens grundlæggende begreber og metodik. Der er fokus på de overordnede definitioner og linjer. Den praktiske anvendelse af begreberne 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 kernebegreber, business casen bygger på, nemlig brugen af flere scenarier, udgifts- og gevinstberegning, gevinsttyper, forudsætninger og håndtering af usikkerhed som følge af risici. Business casens opbygning er vist i figuren nedenfor, og kort kommenteret. Alle begreber gennemgås i detaljer i de efterfølgende afsnit.. Figur 5. Statens business case-model. Figuren viser, at der i business casen findes tre kasser, som der skal analyseres og indtastes information om i regnearket: Før-situationen som er den nuværende driftssituation, projekt-/programudgifter samt den fremtidige drift. For den fremtidige drift kigges der både på fremtiden uden projektet (0-scenarie) og fremtiden med projektet (1-scenarie). Sekundært søger illustrationen at vise trinene i udarbejdelsen af business casen, dvs. hvad der er forudgående analyser og input fra forretningen, hvad der reelt skal indtastes i regnearket, og hvad regnearket beregner og outputter, herunder resultater og nøgletal fra business casen som bruges løbende i projektarbejdet. Business casen beregner en række centrale økonomiske størrelser til vurdering af projektet eller programmet, hvoraf brutto- og nettogevinster skal fremhæves. 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 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 over de næste 5-8 år, hvis initiativet gennemføres. Endelig bemærkes, at business casen opererer med risikojusterede økonomiske størrelser. Dette sker for økonomisk at indregne de usikkerheder - risici, der knytter sig til estimater af udgifter uanset om det er de fremtidige projektudgifter eller de fremtidige udgifter knyttet Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [5]

8 til driften. For projektet eller programmet udgør forskellen mellem de risikojusterede udgifter og de ikke-risikojusterede udgifter risikopuljen dvs. den økonomiske størrelse som projektet bør afsætte i reserve til dækning af specifikke risici, som kan opstå under projektet. Den eneste term, der ikke er risikojusteret er opgørelsen af den nuværende drift til at løse den opgave, som projektet eller programmet skal påvirke. Den økonomiske størrelse af den nuværende drift kan opgøres på baggrund af regnskabstal. Det er derfor ikke nødvendigt at indkalkulere risici. I de efterfølgende afsnit forklares nævnte kernebegreber. 2.1 Nuværende drift Som figur 5 på forrige side viser, er beregningen af den nuværende drift, af projekt- eller programudgifterne samt af den fremtidige drift kerneelementer i business casen. Udgifter til det første element - den nuværende drift er det, det koster at udføre opgaven i dag. Det betegnes i business casen som før-situationen. Før-situationen 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. 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. De økonomiske tal, der fremkommer ved opgørelse af før-situationen bruges til at vurdere omfange, udgiften og rentabiliteten af projektet eller programmet, dvs. til sammenligning mod den fremtidige drift, hvor initiativet er gennemført. 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-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.2 Fremtidig drift En business case handler, som beskrevet i indledningen, om at opgøre konsekvenserne af en potentiel investering. Business casen estimerer derfor på fremtiden både den fremtidige drift og forventningen til udgifterne til projektet eller programmet. I statens business case opgøres de to kasser fra figur 5 vedrørende projekt- eller programudgifter og den fremtidige drift ved at analysere to fremtidige scenarier. De to fremtidige scenarier beskriver henholdsvis situationen, hvor projektet eller programmet ikke gennemføres (0-scenariet) og situationen, hvor initiativet gennemføres (1-scenariet). Udgifter til projektet eller programmet indtastes derfor i business casen under 1-scenariet, da dette er det fremtidige scenarie, hvor initiativet er gennemført. I figur 5 er denne sammenhæng mellem den fremtidige drift og projekt- eller programudgifterne vist ved, at nettogevinsterne for business casen først fremkommer, når man medtager projekt- eller programudgifterne i beregningen. De to scenarier beskrives i hhv. PID en for projekter og programpræciseringsdokumentet for programmer. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [6]

9 0 og 1-scenariet skal altid udfyldes i business casen. Er der tvivl om, hvad der udgør det korrekte 0-scenarie kan Ministeriernes projektkontor kontaktes. Scenarierne for den fremtidige drift er beskrevet efterfølgende 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. 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 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. Det samlede 1-scenarie består derfor af to dele: Estimat på de forventede udgifter til den fremtidige drift efter at projektet eller programmet er gennemført, samt de forventede udgifter til selve initiativet. 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. Definition: 1 scenarie Projektudgifter, samt driftssituationen med projektet eller programmet fra de første gevinster realiseres. 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. 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. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [7]

10 Figur 6. Eksempel på en skitsering af de tre scenarier. Udgifter 0-scenarie Før-situation 1-scenarie Tid I dette eksempel 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. 2.3 Gevinster Gevinstberegning er fokus for statens business case. Formålet med at opstille førsituationen, 0 og 1-scenariet er at udregne og opstille de gevinster, som projektet eller programmet vil have for myndigheden. 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. En gevinst kan enten beregnes som forskellen mellem 0-scenariet og 1-scenariet (sammenligning med forventet, fremtidig drift) eller som forskellen mellem førsituationen og 1-scenariet (sammenligning med nuværende situation). Begge beregninger er vigtige at medtage, med 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. Figur 7. Eksempel på sammenhæng mellem scenarier og beregning af gevinster. Sammenlignet med forventet, fremtidig drift Driftsudgifter uden projekt Driftsudgifter med projekt Af figuren ses, at det viste projekt har en positiv gevinst, 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. Projektudgifter Positiv gevinst 0-scenarie 1-scenarie Gevinster Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [8]

11 2.3.1 Projektformål Gevinster ses og evalueres i forhold til formålet med projektet. Et af de væsentlige formål med business case-modellen er derfor at sikre, at det fremgår tydeligt, hvilket primært formål et projekt søger at realisere. I den fællesstatslige itprojektmodel skelnes mellem tre formål, hvoraf der skal vælges ét og kun ét som det primære: Effektivisering: Kvalitetsløft: Projekter, der har som primært formål at realisere et økonomisk potentiale i den offentlige sektor. Projekter, der har som primært formål at løfte kvaliteten af en service, der leveres af den offentlige sektor. International lovgivning: Projekter, som igangsættes for at sikre, at Danmark overholder international lovgivning - ofte EU-lovgivning. Alle projekter skal, uanset primært formål, beskrive institutionens fremtidige driftsudgifter, både med og uden projekt-/programgennemførelse. Effektiviseringsgevinster skal altid beregnes. Kvalitetsløftsgevinster er derimod kun et krav for projekter med kvalitetsløft som det primære formål. På programniveau aggregeres projektformål for de enkelte projekter, hvilket fremgår af business casen Gevinstkategorier I statens business case-model skelnes der i henhold til formålet med projektet mellem effektiviseringsgevinster og kvalitetsløftsgevinster. Effektiviseringsgevinster er økonomiske gevinster, der kan have en direkte effekt på en myndigheds budget, hvis de høstes. Kvalitetsløftsgevinster er gevinster, der enten forbedrer ikke-økonomiske parametre, såsom tilfredshed, eller som trods, at de er økonomiske, ikke har en direkte effekt på en myndigheds eget budget, såsom økonomiske gevinster for erhvervslivet eller borgere. Både effektiviseringsgevinster og kvalitetsløftsgevinster beregnes på baggrund af sammenligningen af 0- og 1-scenariet. De forskellige kategorier af gevinster er forklaret i det følgende Effektiviseringsgevinster Ved effektiviseringsgevinster forstås økonomiske gevinster, som direkte påvirker myndigheden. Dvs. gevinsten kan indbudgetteres og henføres til en specifik, offentlig konto. Gevinsterne 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 programmets 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. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [9]

12 Kvalitetsløftsgevinster I statens business case-model forstås kvalitetsløftsgevinster som alle typer kvantitative gevinster, der ikke har en budgethenførbar økonomisk effekt. Gevinster, som kan kvantificeres, men hvor det ikke kan angives på hvilken offentlig hovedkonto, gevinsterne vil falde, er således at betragte som kvalitetsløftsgevinster. 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.4 Forudsætninger og udgifter De foregående afsnit har beskrevet de tre kasser af udgifter, der skal analyseres og indtastes i statens business case den nuværende drift, projekt- eller programudgifter, samt den fremtidige drift. Dette er i afsnit 2.3 sat i forhold til det primære formål for business casen nemlig at opgøre de forventede gevinster ved at iværksætte initiativet. For at komme så langt må man imidlertid før opgørelsen af projekt- eller programudgifter samt den fremtidige drift starte med de grundlæggende forudsætninger dvs. de forventede typer af udgifter, som driver henholdsvis projekt- og driftsudgifterne. Ud fra dette kan de reelle udgifter så estimeres, hvortil der tilknyttes risici og foretages en tre-punktsestimering for at få de risikojusterede udgifter. Formålet med denne trepunktsøvelse er at inddrage den usikkerhed, der ligger i estimaterne af udgifterne i beregningen i business casen. Resultatet er, at der til projektet eller programmet udregnes en risikopulje, som er en reserve til projektet i tilfælde af at risici opstår. I de følgende underafsnit beskrives forudsætninger og udgifter, risici og trepunktsestimeringer samt sammenhængene mellem disse begreber i business casen 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 udgiftstyper i business casen er estimeret så korrekt som muligt. Dette betyder først og fremmest, at det er vigtigt at få identificeret de udgiftstyper eller budgetposter, som driver udgifterne for projekt- eller programmet og den fremtidige drift. I business casen kaldes nedbrydningen af disse udgiftstyper og deres sammenhænge for forudsætninger, og 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. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [10]

13 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 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 udgifter, der er knyttet til at gennemfører 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 Risici 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 kan være en række risici forbundet med en udgift som gør, at udgiften bliver enten dyrere eller billigere end forventet. Disse risici 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 udgiftstype eller forudsætning vil lande. Usikkerhedsspændet skal derfor afspejle de risici, der kan indtræffe. I statens business case 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. 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. Slutteligt 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. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [11]

14 Det er også muligt at vælge andre sandsynlighedsfordelinger samt at fravælge trepunktsestimeringen, hvis estimatet for forudsætningen ikke er usikker. 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. På baggrund af det indlagte usikkerhedsspænd mellem de tre estimater, og sandsynligheden for at de indtræffer, udregner modellen en risikojusteret udgift. 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. 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, og at projektet eller programmet vil ikke have en buffer til håndtering af hændelsen, hvis den opstår. 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 kr. Ved forudsætning A bliver resultatet af risikojusteringen, at også det risikojusterede estimat bliver 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. 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 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å 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 procent sandsynligt) end det lave (5 procent sandsynligt). Dette trækker igen det vægtede gennemsnit det risikojusterede estimat højere end det ikke-risikojusterede middelestimat. Igen tillægges der en risikopulje i dette tilfælde på kr. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [12]

15 Figur 8. Eksempler på trepunktsestimering Estimater Sandsynlighed Lavt Middel Højt Lavt Middel Højt Risikojusteret Risikopulje Forudsætning A % 50 % 25 % 20 0 Forudsætning B % 50 % 25 % 26,3 6,3 Forudsætning C % 50 % 45 % 24 4 Forudsætning D % 50 % 25 % 18,75-1,25 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å 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. For et projekt eller program som helhed, hvor alle risikopuljer slås sammen til en samlet risikopulje, er det urealistisk, at usikkerhed som følge af de konkrete risici medfører, at der kan budgetteres med at spare penge ift. de oprindelige, 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 dog fortsat 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 business casen er udgiftsbaseret. Dette betyder, at budgettet skal omformes til omkostninger, inden den endelig budgeteffekt kan udregnes 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 [13]

16 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 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 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 [14]

17 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 9. Business casen for programmer og deres projekter. 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 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 [15]

18 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 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 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 Såfremt en business case skal simuleres og myndigheden ikke selv har adgang til 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 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 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 [16]

19 (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 Køb af tj.ydelser i øvrigt: Konsulentbistand, advokatbistand, kursusafgifter, databehandling, installationsudgifter, etc. Udgifter her svarer til statens kontering på finanskonto 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 og 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 [17]

20 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-resumeet. 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. Figur 10. Standard-forudsætningsdiagram. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [18]

21 Forudsætningsdiagrammet er opdelt i to. Den øverste del viser forudsætninger forbundet med driftsudgifterne, mens den nederste del viser forudsætninger forbundet med projektudgifterne. Sammenhænge mellem forudsætningerne er illustreret med pile. Sammenhængene i et forudsætningsdiagram udtrykker et fremadrettet flow i business casen hen mod formålet. Derfor må pilene, der udtrykker forudsætningernes sammenhænge, aldrig lede tilbage. Ved formulering af forudsætninger forbundet med driftsudgifter er det vigtigt, at forudsætningsdiagrammet er opstillet således, at det både kan håndtere situationen, hvor projektet ikke gennemføres (0-scenariet), og situationen hvor projektet gennemføres (1-scenariet). Forudsætningerne for driftsudgifterne bør derfor defineres værdineutralt, altså ikke 'sparet tid' eller 'hurtigere sagsbehandling', men 'sagsbehandlingstid'. En sådan forudsætning kan håndtere begge situationer men med forskellig værdi alt afhængig hvilken situation, der er tale om. Vær opmærksom på, at nogle forudsætninger, afhængig af situationen, kan forekomme uberørte eller passive. Forskellen mellem driftsudgifterne i 0- og 1-scenariet er business casens bruttogevinster. Disse kan godt være negative eller nul. Bruttogevinsterne fratrukket projektudgifterne giver projektets samlede nettogevinster. I figur 10 er nettogevinsterne illustreret med den lyseblå oval længst ude til højre Forudsætningstyper Der findes fire typer af forudsætninger, som er væsentlige at skelne imellem før de indtastes i regnearket. Der sondres på to akser detailgrad af udgiften eller budgetposten - om der er tale om en hovedforudsætning eller en underforudsætning, samt om der er tale om en forudsætning, der direkte kan estimeres, eller om forudsætningen agerer mellemregning for andre forudsætninger. De fire typer forudsætninger er vist i nedenstående figur og beskrevet efterfølgende. Figur 11. Typer af forudsætninger Hovedforudsætninger uden underforudsætninger er overordnede budgetposter, og angives i tusinde kroner. Hovedforudsætninger, der estimeres, beregnes ikke på baggrund af andre forudsætninger. Denne type forudsætning estimeres direkte med en usikkerhed, der stammer fra risici, der direkte kan henføres til forudsætningen. Det er alle hovedforudsætninger, der lægges sammen til de samlede udgifter. Overordnet udgift (budgetpost) Nedbrudt udgift (art) Hovedforudsætninger med underforudsætninger er overordnede budgetposter, der kan nedbrydes yderligere og som har tilknyttede underforudsætninger. Usikkerheden ligger længere til venstre i diagrammet, da forudsætningen er nedbrudt. Hovedforudsætninger med underforudsætninger kan derfor ikke estimeres direkte men opgøres ved at summere underforudsætningerne. Det er alle hovedforudsætninger, der lægges sammen til de samlede udgifter. Underforudsætninger med usikkerhed er detaljerede budgetposter, der ikke kan nedbrydes yderligere, og ikke har yderligere underliggende forudsætninger De beregnes dermed ikke på baggrund af andre forudsætninger. Denne type forudsætning estimeres direkte med en usikkerhed, der stammer fra risici, der direkte kan henføres til forudsætningen. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [19]

22 Underforudsætninger mellemregning er detaljerede budgetposter, der er nedbrudt yderligere og har tilknyttede underliggende underforudsætninger. En underforudsætning mellemregning, skal indtastes som en formel, der knytter de underliggende underforudsætninger sammen. I standard-diagrammet i figur 9 består hovedforudsætningen Fagspecifikke arbejdsgange af tre forskellige arbejdsprocesser. esser. Disse arbejdsprocesser er mellemregninger til hovedforudsætningen 'Fagspecifikke arbejdsgange' og de tre arbejdsprocesser A, B og C er derfor mar- keret med gult. Processerne består hver især af 3 underforudsætninger Årsværkspris, Tid pr. sag og Antallet af sager. Disse er derfor markeret med orange. Disse tre underforudsætninger (orange) er hver især behæftet med forskellig grad af usikkerhed. De hvide bokse i forudsætningsdiagrammet er ikke forudsætningstyper i business caseforskellige konti i statens kon- toplan som I business casens regneark bør det oplyses, hvilke konti forudsætningerne knyt- modellen, men illustrerer, at forudsætningerne kan kobles til ter sig til. Tastearbejdet i regnearket bliver lettere, hvis dette allerede er illustreret i forududarbejdes logisk for effektiviseringsgevinster, men skal ligeledes udarbejdes for kvalitetsløftsgevinster, selvom dette ikke vil blive så detaljeret som for den økonomiske side. Kvalitetsløftsgevinsterne skal også indtastes i business casen. I figur 12 sætningsdiagrammet Kvalitetsløftsgevinster Forudsætningsdiagrammet nedenfor er vist et standardiseret diagram for typiske kvalitetsløftsgevinster. Figur 12. Standard-forudsætningsdiagram for kvalitetsløftsgevinster. Samfundsøkonomiske gevinster Medarbejdertilfredshed Kundetilfredshed Udbredelse til andre platforme Implementering af regel/lov Standardisering af systemer Dataindsamling Sikkerhed Kvalitetsløft gevinster Overgang fra gevinstdiagram til forudsætningsdiagram Selvom forudsætningsdiagrammet er første trin i business case-processen, findes der andre dele af hhv. den fællesstatslige it-projektmodel og programmodel, som der kan tages udgangspunkt i, når diagrammet skal laves. Det bedste af disse andre værktøjer ift. forudsæter sammenhængene i projektet eller programmet for at opnå de ønskede gevinster. Sagt med andre ord - på samme måde som forudsætningsdiagrammet skelner mellem projektudgifter og driftsudgifter, skelner gevinstdiagrammet mellem leverancer, forandringsevner, resultater og gevinster, der påvirker hinanden fra venstre mod højre. Denne generiske sammenhæng er vist i figuren nedenfor. ningsdiagrammet er gevinstdiagrammet. Gevinstdiagrammet Figur 13. Gevinstdiagram. Organisatorisk forankring Leverancer Forandringsevne Resultater Gevinster Formål Den fællesstatslige it-projekt-/programmodel, model, Digitaliseringsstyrelsen [20]

23 Som det fremgår af figuren er formålet med gevinstdiagrammet at nedbryde formålet for projektet (eller visionen for programmer) til gevinster, som endeligt ender i leverancer. Kategorierne resultater og gevinster kan med fordel inspirere driftsudgiftsdelen af forudsætningsdiagrammet, således at gevinsterne længst mod højre i gevinstdiagrammet overføres som hovedforudsætninger, og niveauerne til venstre herfor som underforudsætninger. Det understreges, at dette ikke nødvendigvis vil indeholde alle økonomiske driftsudgifter, men det giver et godt startsted. På samme måde kan kategorierne leverancer og forandringsevner fungere som fundament for projektudgifterne i forudsætningsdiagrammet. Da gevinstdiagrammet fokuserer på gevinstkæderne, er primært ift. driftsudgifterne, at der kan være en stor fordel i at starte ud fra gevinstdiagrammet. 4.2 Regnearket Regnearket er baseret på Microsoft Excel og anvender makroer. Det er derfor nødvendigt, at aktivere makroer for at kunne benytte statens business case. Der vil ofte fremkomme en bjælke med en sikkerhedsadvarsel som vist herunder. Her skal vælges Indstillinger og herefter Aktiver indholdet. Når regnearket lukkes, popper en sikkerhedsmeddelelse vedrørende arkets makroer op. Igen er det nødvendigt at vælge Med makroer. Regnearket består af tre grupper af faneblade: 1) Startside og forside: Her tastes grundlæggende oplysninger om projektet, tidsrammen, projektets omfang, opsætningen af business casen, mv. 2) Udgiftsark for projekt- og driftsudgifter: Her tastes dels oplysninger ind om selve projektets udgifter, dels om udgifterne i før-situationen og de to fremtidsscenarier. 3) Business casen: Resultatet af indtastningerne præsenteres via en række nøgletal, tabeller og grafer. Hver forudsætning har én linje i regnearket. Hovedforudsætninger, der har underforudsætninger, kan ikke i sig selv være behæftet med usikkerhed, som beskrevet under forudsætningstyper. De består af en formel, der medtager de underforudsætninger, der definerer indholdet. Usikkerheden håndteres på den regnearkslinje, der beskriver underforudsætningen. Angivelse af risikohændelsen, dvs. den primære og eventuelt sekundære risici, der er årsag til usikkerheden foregår dog stadig pr. hovedforudsætningsgruppe. Definition: Hovedforudsætningsgruppe En hovedforudsætning samt tilknyttede underforudsætninger, der er med til at definere indholdet i hovedforudsætningen, kaldes en hovedforudsætningsgruppe. Når der i arket indsættes en ny underforudsætning, indsættes denne automatisk i bunden af den hovedforudsætningsgruppe, som den med cursoren valgte celle hører til. Når der indsættes en ny hovedforudsætning, indsættes denne under den sidste underforudsætning i den valgte hovedforudsætningsgruppe og danner dermed en ny hovedforudsætningsgruppe. Når regnearket startes vil det være muligt løbende at gemme sikkerhedskopier. Disse vil blive gemt samme sted som arket selv hvilket betyder, at det er nødvendigt først at gemme selv (med makroer) og derefter vil alle sikkerhedskopier blive gemt i samme mappe med angivelse af dato og tidspunkt. Hvis du har modtaget en business case på , så undlad at åbne den direkte fra en. Den bør gemmes på et fælles fil-drev eller på computeren. Ellers vil eventuelle sikkerhedskopier også blive gemt som midlertidige internetfiler der, afhængigt af dine internetindstillinger, kan blive slettet. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [21]

24 Fakta: Genvej til regnearkets funktioner Regnearket anvender formler og makroer, der afhængigt af indtastningen - åbner og låser de celler, der skal udfyldes. Automatiseringen i arket betyder, at der er 3 typer celler: 1) Gule celler, der kan redigeres. 2) Celler, der ikke kan redigeres. Disse er typisk hvide 3) Celler, hvor alle oplysninger ikke er angivet, men bør angives. Disse er røde. Makroer skal være aktiveret, for at business casen virker! Redigering skal foregå via båndet med knapper, der findes øverst på siden under fanen Statens business case-model 2.0. Kopier Indsæt Ny hovedforudsætning Ny underforudsætning Frys / Frigør Slet Vis/skjul nøgletal Vis/skjul underforudsætninger Vis/skjul underforuds. i gruppe Opdater Tjek version Lav sikkerhedskopi Print alle ark Gem som PDF Print business case Importer BC Eksporter BC Hent projektudgifter Lås ark/lås ark op Kopierer de rækker, der markeres. Indsætter de kopierede rækker under den række der markeres. Indsætter ny hovedforudsætning under den hovedforudsætningsgruppe, der markeres. Indsætter ny underforudsætning nederst i den hovedforudsætningsgruppe, der markeres. Fryser de rækker der markeres. / Frigør fryste rækker. Sletter de rækker, der markeres. Viser sektionen Nøgletal i arkene projektudgifter og programudgifter. / Skjuler sektionen Nøgletal i arkene projektudgifter og programudgifter. Viser alle underforudsætninger i arket. / Skjuler alle underforudsætninger i arket. Viser alle underforudsætninger i den hovedforudsætningsgruppe, der markeres. / Skjuler alle underforudsætninger i den hovedforudsætningsgruppe, der markeres. Opdaterer tabeller. Hvis du har tastet ind og ikke opdateret, kan der være tabeller i business case resumeet, der ikke er opdaterede. Tjekker om der benyttes den nyeste version af business casen. Gemmer sikkerhedskopi. Printer alle forudsætningsark som de vises. Gemmer business case-arket som pdf. Printer business case-arket. Importerer data fra en valgt eksportfil. Dette vil overskrive alt data! Hvis du skal hente projektudgifter til et program skal du i stedet anvende hent projektudgifter. Gemmer en eksportfil med alle nuværende indtastninger og data. Henter projektudgifter fra eksportfil og indsætter det i arket programudgifter under det projektnavn, der markeres. Hvis du skal hente projektudgifter til program, skal du markere en celle under det pågældende projekt. Låser arket / låser arket op. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [22]

25 4.2.1 Startside og forside Første og kun første gang regnearket åbnes, mødes brugerne af en startside, der fungerer som tjekliste til opsætning af business casen efter brugerens behov, se afsnit 3. Herefter vil brugerne i stedet møde fanen forside, samt ark til indtastning af forudsætninger. Bemærk, at det kan tage lidt tid første gang business casen skal udformes. Startsiden Er du klar til at starte? Hjælp, forklaringer og vejledninger Guidet start (oplysninger om projektet) Start-knap Når der klikkes på denne sektion åbnes tjeklisten, som bør besvares for at sikre, at projektets forarbejde er tilstrækkeligt til, at det giver mening at gå videre til selve indtastningen i regnearket. Giver en kort introduktion til definitioner og kernebegreber som også er gennemgået i denne vejledning. Her kan du indtaste de første oplysninger om projektet. Projektnavn, journaliseringsnummer, formål og projektets nuværende fase. Oplysningerne føres videre, og kan senere redigeres. Fører dig videre til opsætning af business case og herefter selve den udfoldede model. Seneste version Seneste sikkerhedskopi Tjekker om den version af statens business case-model du har åbnet, er den seneste version. Angiver, hvornår du senest har taget en kopi af din business case. Vær opmærksom på at gemme en version af business casen første gang på et fælles fil-drev eller på den lokale computer. Herefter vil sikkerhedskopierne gemmes samme sted når du trykker Gem sikkerhedskopi. Det er i forside-arket, der indtastes de grundlæggende data, som skal bruges til at beregne business casen. Arket kan redigeres og udbygges undervejs, og består af to sektioner: Om projektet, hvor stamdata og oplysninger om projektet udfyldes, og en sektion med Hjælp, forklaringer og vejledninger til udfyldelsen. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [23]

26 Forside Stamdata Business opsætning Tidsplan Risici PL-år Gevinstejere Udgiftsbærere Projekter Her indtastes projektets stamoplysninger. Hvis du allerede har indtastet dette på startsiden, overføres disse data automatisk. Her vælges, hvilken opsætning af business casen, der er tale om, se afsnit 3. Der kan vælges mellem hhv. organisering (projekt, projekt i program, eller program), risikoprofil (normal eller høj risiko), størrelse (over eller under 10 mio. kr.) samt kontering. Listen med de otte typiske konti for statslige it-projekter kan ændres via knapperne rediger og tilføj. Her angives projektets start og sluttidspunkt og fordelingen på de enkelte faser. Projektets startdato er altid det tidspunkt, hvor projektets idéfase gik i gang og afslutningen på realiseringsfasen er det tidspunkt, hvor de aktiver, der anskaffes som led i projektet, er fuldt afskrevet. Det er nødvendigt at indtaste for, at resten af arket kan tilpasse sig projektets faseopdeling, og for at beregne de økonomiske nøgletal. Listen redigeres via knapperne rediger og tilføj. Husk, faser må ikke overlappe, jf. vejledning til den fællesstatslige it-projektmodel. Her angives projektets væsentligste risici. Projektets risici indtastes med hhv. sandsynlighed, konsekvens samt risikotype fra risikoregisteret, der er et produktbilag til PID i den fællesstatslige it-projektmodel. Risici redigeres via knapperne rediger og tilføj. Her vælger du, hvilket pris- og lønreguleringsår, du vil have business casen vist i. Som udgangspunkt er den indstillet til år Valget kan ændres undervejs. I regnearkets udgiftsark skal du anføre, hvilket pl-år de enkelte udgifter er angivet i, men dette forhindrer ikke, at selve business casen kan vises i et andet pl-år. Gevinstejere er en liste over de myndigheder, der bærer dele af driftsudgifterne for de enkelte opgaver. Det vil samtidig typisk være den, der har ansvaret for at høste gevinsten. Gevinstejere tilknyttes hver forudsætning. Listen kan redigeres via knapperne rediger og tilføj. Udgiftsbærere er en liste over de myndigheder, der bærer dele af udgifterne for projektet eller programmet. Udgiftsbæreren tilknyttes hver forudsætning. Listen kan redigeres via knapperne rediger og tilføj. Er kun relevant for programmer. Her indtastes de projekter, der er en del af programmet. Listen er nødvendig for at kunne indhente projekternes udgifter til business casen. Ikke-økonomiske gevinster Her angives navnene på de ikke-økonomiske gevinster, der forventes i projektet. Navnene vil blive kopieret til hhv. Drift med projekt og Drift fremtidig uden projekt. Omkostningsbaseret projektøkonomi Versionshistorik Her er der mulighed for at indtaste en omkostningsbaseret økonomi. Statens business case-model er udgiftsbaseret, men i forbindelse med aktstykker til Finansudvalget, vil det være nødvendigt at udregne den omkostningsbaserede effekt af projektet. Data, inkl. afskrivningsprofil skal dog indtastes manuelt for at blive beregnet i business casen. Vejledning til omregning fra udgift til omkostning kan findes her. Her indtastes, hvilke ændringer, der er lavet fra version til version. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [24]

27 4.2.2 Udgiftsark projekt- og programudgifter I disse ark indtastes projekt- eller programudgifter på baggrund af det udarbejdede forudsætningsdiagram. Udgifterne deles op så de for projekters vedkommende inddeles i faser og for programmers vedkommende inddeles i hhv. programledelse og projekter, projektudgifterne hentes fra de enkelte projekters business cases. Derudover fungerer arkene fuldstændigt ens. Når der skal hentes projektudgifter til et program, markeres en celle på første linje i arket under det pågældende projekt. Herefter trykkes på knappen hent projektudgifter og den eksporterede fil fra det pågældende projekts business case vælges. Husk at vælge hent projektudgifter, og ikke importer business case. Sidstnævnte vil importere alt data og derved overskrive allerede indtastede stamoplysninger og driftsudgifter! Arket består af to dele: En sektion, der vedrører nøgletal og en sektion, der er opdelt i de hhv. de forskellige faser eller de forskellige projekter. For begge sektioner gælder, at den styrende logik i regnearket er, at der indsættes en række pr. forudsætning med tilhørende beskrivende data. Under hovedforudsætningerne indtastes de tilhørende underforudsætninger. For hovedforudsætninger uden underforudsætninger samt for underforudsætninger (mellemregning) indtastes formler med referencer til de underliggende underforudsætninger. For hovedforudsætninger uden underforudsætninger samt underforudsætninger (med usikkerhed) indtastes i stedet den konkrete trepunktsestimering af forudsætningen med usikkerhed og sandsynlighed. Sektionen vedrørende nøgletal er valgfri og er ment som en hjælp til at kunne indeholde de forudsætninger, der ikke er fasespecifikke og som bruges af flere hovedforudsætninger. Et eksempel på dette kunne være prisen på et internt årsværk i staten. Disse forudsætninger behøver kun at blive indtastet én gang. Langt de fleste forudsætninger er fasespecifikke. Forudsætningstitel Forudsætningstype År Titlen på forudsætningen. Bør svare til titlen i forudsætningsdiagrammet. Forudsætningstypen vælges via drop-downmenuen. Det er vigtigt for udformningen af business casen, at det er de rigtige typer af forudsætninger der vælges. Se Forudsætningsdiagram for beskrivelse af de enkelte forudsætningstyper. Her angives, hvilket år den pågældende udgift eller aktivitet afholdes i. Afholdes den samme udgift eller aktivitet i to forskellige år, laves der to forudsætninger, også selvom det er inden for samme fase. Kolonnen er kun relevant, hvis der som forudsætningstype er valgt en hovedforudsætning. Er det en underforudsætning, vil cellen være hvid, og låst. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [25]

28 Konto Udgiftsbærer PL-år Grundlag for estimat Oplysningerne bruges bl.a. til at opdele udgifterne på eksterne og interne udgifter. Derfor skal der for hver forudsætning indtastes hvilken konto, udgiften kan henføres til. Business casen er indstillet til at medtage ni forskellige konti, som kan redigeres i fanebladet Forside. Kolonnen er kun relevant hvis der er tale om en hovedforudsætning. Der vælges ud fra en drop-downliste der tager udgangspunkt i de udgiftsbærere, der er tastet ind i fanen Forside, hvor listen også kan redigeres. Denne kolonne er kun relevant hvis der er tale om en hovedforudsætning. Business casen er som standard indstillet til at der indtastes beløb med pris- og lønreguleringstal fra Hvis der anvendes et andet pl-år, kan året vælges via drop-downlisten. Beregningen af den samlede business case vil automatisk justere til det i Forside-fanen valgte pl-niveau. Denne kolonne er kun relevant hvis der er tale om en hovedforudsætning. Kilden eller grundlaget for estimatet. Sandsynlighedsmodel I kolonnen sandsynlighedsmodel, vælges mellem forskellige typer af sandsynlighedsmodeller, der beskriver sandsynligheden for de tre estimater, der til sammen udgør forudsætningens trepunkts-estimering. Nye forudsætninger er på forhånd indstillet til en trekantsmodel, hvor der er størst sikkerhed for middelestimatet. Hvis der ikke er usikkerhed forbundet med forudsætningen, anvendes modellen ikke usikker Udgiftsark - drift Driftsarkene bruges til at beskrives og håndteres udgifterne til at udføre/drive de opgave som projektet påvirker. Der skal indtastes forudsætninger på samme måde som for projektog programudgifter, men for både før-situation, 0-scenarie og 1-scenarie. For alle tre ark gælder det, at alle opgaver, som projektet påvirker, skal medtages. Er der tale om helt nye opgaver, er det derfor ikke relevant at udfylde før-situationen. Arket vedrørende før-situationen indeholder kun én sektion og færre kolonner. Da tallene er afholdt, er usikkerhedsspænd ikke er relevant. Ligeledes kan forudsætninger begrænses til hovedforudsætningsniveau. Arkene, der beskriver driften med og uden projekt, hhv. 1- og 0-scenariet, består af to sektioner og er identiske. Den første sektion (økonomi) er identisk med de funktioner og kolonner, der er beskrevet i projektudgifts-arket med den undtagelse, at der ikke indtastes en Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [26]

29 udgiftsbærer for udgiften, men en gevinstejer for driftsudgiften. Den anden sektion i driftsarkene (kvalitetsløft) giver mulighed for at indtaste forudsætninger, der ikke er direkte budgethenførbare. Statens business case deler disse forudsætninger op i to kategorier, ikkeøkonomiske variable og økonomi for virksomheder og private. Forskellen på disse er gennemgået i afsnit 2, vedr. gevinster. Rækkerne vedrørende økonomiske gevinster for private og virksomheder fungerer på samme måde som de øvrige udgiftssektioner bortset fra, at der ikke skal angives en konto, da udgifterne i denne sektion er karakteriseret ved ikke at være budgethenførbare. Rækkerne vedrørende ikke-økonomiske variable er langt hen ad vejen identiske med de øvrige sektioner, men introducerer enkelte nye kolonner: Ikke økonomiske variable Navn Navnet på variablen. Eksempelvis medarbejdertilfredshed. Enhed Den enhed, variablen skal måles i. Det kan eksempelvis være medarbejdertilfredshed i % eller på en skala fra Prioritering Her indtastes om der er tale om en primær eller sekundær gevinst. Primære gevinster kan henføres direkte til projektets succeskriterier og der er kun disse der har betydning for en evt. trafiklysmarkering ved de halvårlige statusrapportering til IT-projektrådet. 4.3 Business case-resumé Dette ark udgør en samlet præsentation af business casens resultater. Der kan ikke tastes eller ændres i dette ark. Når du er færdig med at ændre i udgiftsark, driftsark og forsiden, er det vigtigt, at du trykker på knappen opdater tabeller. Ellers risikeres, at ændringerne i data ikke slår igennem i alle business casens tabeller. Den øverste venstre halvdel af business case-resuméet indeholder stamoplysninger for projektet/programmet. Øverst til højre er opgivet en række centrale nøgletal, som sammen med tabel 1.2: Økonomiske nøgletal og størrelsen på risikopuljen til højre herfor giver de vigtigste oplysninger om projektets samlede økonomi. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [27]

30 Udover de nævnte centrale nøgletal findes flere tabeller, der bør have projektets opmærksomhed. Tabel 1.3: Faseopdelte udgifter giver eksempelvis et indblik i, hvilke faser, der er særlig omkostningsfulde for projektet, og skal endvidere indrapporteres til Statens ITprojektråd ved de halvårlige statusrapporteringer. Særligt relevant kan det være at kigge på tabellerne 1.10 og 1.11, der viser hvilke hovedforudsætninger, der driver udgifterne til hhv. projekt- eller programudgifter og driftsudgifter. Dette kan bruges til at vurdere, om der er forudsætninger, der er særligt omkostningsdrivende, og derfor bør tildeles særskilt opmærksomhed og evt. revurdering af deres trepunktsestimering. Centrale nøgletal i business case resuméet Nettonutidsværdi Projektets nettonutidsværdi er nettoværdien ved projektets igangsættelse af alle fremtidige økonomiske gevinster og udgifter (risikojusteret) diskonteret med 4 % p/a. Nettonutidsværdien er det vigtigste nøgletal, når det skal afgøres, om et projekt økonomisk set har en positiv business case. Med beregningen af nettonutidsværdien tages højde for, at gevinster, der falder længere ude fremtiden, er mindre værd, end gevinster, der falder tidligere. Nettonutidsværdien beregnes både ved en sammenligning af 1-scenariet med den forventede fremtidige drift (0-scenariet) og den nuværende drift (før-situationen). I tabel 1.2: Økonomiske nøgletal vises sammenligningen med 0-scenariet både risikojusteret, ikke-risikojusteret samt for hhv. best og worst case. Nettogevinster Nettogevinsterne angiver gevinsterne ved projektet, fratrukket projektets udgifter. Er der valgt at tilføje omkostningsbaserede tal vil nettogevinsten også blive beregnet med renter, hvilket er den bevillingsmæssige effekt. Nettogevinsterne sammenlignes både med forventet fremtidig drift (0-scenariet) og den nuværende drift (før-situationen). I tabel 1.2: Økonomiske nøgletal vises sammenligningen med 0-scenariet både risikojusteret, ikke-risikojusteret samt for hhv. best og worst case, men ekskl. renter. Samlede udgifter Udtrykker de samlede udgifter knyttet til projektet/programmet ekskl. renter. I tabel 1.2: Økonomiske nøgletal vises de samlede udgifter både risikojusteret, ikkerisikojusteret samt for hhv. best og worst case. Drift uden projekt/program Drift med projekt/program Samlet bruttogevinst ekskl. renter Samlede udgifter inkl. proj./ programudgifter ekskl. renter Risikopulje Viser 0-scenariet, dvs. de fremtidige udgifter til at løse samme opgave uden nyanskaffelser, ekskl. renter og afskrivninger. Driften vises risikojusteret, ikke risikojusteret og for hhv. best og worst case. Viser driften af 1-scenariet, dvs. driften af opgaven fra realiseringstidspunket, hvis projektet gennemføres. Driften vises risikojusteret, ikke risikojusteret og for hhv. best og worst case. Viser forskellen i driftsudgifter for 1- og 0-scenariet. Vises risikojusteret, ikkerisikojusteret samt for hhv. best og worst case. Viser det samlede 1-scenarie, hvor både drift og udgifter til projekt/program er indregnet. Vises risikojusteret, ikke-risikojusteret samt for hhv. best og worst case. Risikopuljen er det beløb, der specifikt er beregnet til at skulle afsættes for at dække de i projektet identificerede risici. Risikopuljen er ikke beregnet til at dække uforudsete udgifter i al almindelighed, men en specifik beregning baseret på trepunktsestimeringen af, hvad prisen på usikkerheden fra projektets risici er. Såfremt der er foretaget MC-simulering af projektet/programmet vil der også være en pulje til højrisiko, som ikke er fordelt på de enkelte faser, men i stedet placeres på sidste år før realisering. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [28]

31 En sidste tabel, der er særdeles nyttig i analysesammenhænge, er tabel 1.8: Pris på projektets risici, mio. kr., der viser priserne på de forskellige risici i projektet/programmet. Tabellen er en sammentælling af de risici, der er blevet påhæftet de forskellige forudsætninger, og kan fortælle projektet noget om, hvilke risici, der er særlig omkostningstunge for projektet. Disse priser kan evt. overføres til risikoregisteret til vurdering og prioritering af risikotiltag. Herudover viser business-casen en lang række tabeller, som på forskellig vis kan bruges til at analysere projektet, jf. listen herunder. Tabeller i business casen Tabel 1.1: Stamdata Tabel 1.2: Økonomiske nøgletal Tabel 1.3: Faseopdelte udgifter i mio. kr. Tabel 1.4: Samlede udgifter og økonomiske gevinster, mio. kr. Tabel 1.5: Samlet økonomi med og uden projekt (eksl. projektudgifter), mio. kr. Tabel 1.13: Udgifter fordelt på projekter Tabel 1.14: Projektudgifter fordelt på interne og eksterne ressourcer Tabel 1.15: Omkostningsbaseret økonomi Tabel 1.16 Økonomiske nøgletal inklusiv private og virksomheder Figur 1.17a: Pengestrømme Tabel 1.6: Ikke-økonomiske gevinster (risikojusteret) Figur 1.17b.: Foreslået løsning sammenlignet med 0- scenarie (ekskl. projektudgifter) Tabel 1.7: Omkostningsbaserede udgifter, risikojusteret Figur 1.17c.: Foreslået løsning sammenlignet med 0- scenarie (inkl. projektudgifter) Tabel 1.8: Pris på projektets risici, mio. kr. Tabel 1.9: Oversigt over pris på risikotyper, mio. kr. Tabel 1.10: Økonomiske gevinster, risikojusteret (Hovedforudsætninger) Tabel 1.11: Projektudgifter (Hovedforudsætninger) Tabel 1.12: Økonomiske bruttogevinster fordelt på gevinstejere, risikojusteret Figur 1.18a.: Monte carlo-simuleret sandsynlighedsfordeling af projektudgifter Figur 1.18b.: Monte carlo-simuleret sandsynlighedsfordeling af nettonutidsværdi Tabel 1.19 Udgifter fordelt på udgiftsbærere Tabel 1.20 Tidsplan fordelt på faser Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [29]

32 5 Kvalitetssikring af en business case Her gives tips til, hvordan projektet eller programmet efter udfyldelsen af business casen kan kvalitetssikre sin business case. Der præsenteres en række temaer, som kan bruges som målinger for at imødegå de mest almindelige mangler. Det er generelt vanskeligt at give retningslinjer for, hvad der er en pålidelig risikojusteret business case. Alligevel kan det være givtigt med en systematik i gennemgangen af business cases, da dette sikrer, at de fleste forhold tages i betragtning når kvaliteten og dermed usikkerheden af en business case vurderes. De temaer, der er beskrevet nedenfor, kan virke som indikatorer i forbindelse med en vurdering af business casens kvalitet. 5.1 Samlet spænd på udgifter Det første indtryk af business casens evne til at reflektere projektets risiko er bredden på spændet for udgifterne. En god idé kan være at sammenligne worst case-scenariet med de ikke-risikojusterede udgifter. Selvom et lille spænd kan indikere at der er lav usikkerhed grundet få risici, og derved at projektet ikke synes risikabelt, viser erfaringerne, at dette sjældent er tilfældet. Et smalt spænd kan nemlig også indikere, at den underliggende risikoanalyse undervurderer projektets risici. Som en generel indikation kan bruges, at worst caseudgifterne bør være mere end dobbelt så høje som de ikke-risikojusterede udgifter. Det understreges dog, at det er en generel anbefaling, og at der kan være forhold ved et konkret projekt, der gør at risikoen er så lille, at spændet bør være smalt. Det væsentligste er, at risikoanalysen og usikkerhedsspændene passer sammen. 5.2 Risikopulje Der bør være en positiv risikopulje i projektet til at håndtere risici og tiltag til at minimere disse. Denne beregnes på baggrund af trepunktsestimaterne og kan i teorien være negativ, men for et projekt som helhed, hvor alle risikopuljer slås sammen til en samlet risikopulje, er det urealistisk. Det ville betyde, at usikkerhed som følge af projektets risici medfører, at der kan budgetteres med at spare penge ift. de oprindelige estimater. Konkret medfører en negativ risikopulje også, at projektet ift. f.eks. Statens IT-projektråd holdes op mod et lavere budget end det forventede da baseline for statusrapporteringerne er det risikojusterede budget for projektet. 5.3 Vægten af største post Store enkeltstående udgiftsposter på både projektudgifts- og driftssiden betyder, at business casen ikke er tilstrækkeligt nedbrudt i forudsætninger. Det er et tegn på, at projektledelsen ikke har tilstrækkeligt indblik i projektets kritiske udgifter. Ideelt set bør den største enkeltstående post, altså en forudsætning der ikke er yderligere nedbrudt, være mindre end 5 % af de samlede udgifter. Hvis andelen er væsentlig større bør det overvejes, om posten kan brydes yderligere ned. Forudsætninger bør nedbrydes til et niveau, hvor risici direkte påvirker forudsætningen. Risikohændelsen dvs. den primære og evt. sekundære risici, der driver usikkerheden, skal dog stadig angives pr. hovedforudsætningsgruppe. 5.4 Baggrund og kilder for estimater Grundlaget for estimater er en indikator for usikkerheden i business casen. De mest solide estimater er baseret på faste og dokumenterbare størrelser, som eksempelvis et fastpristilbud eller en total-eliminering af processer, hvis omkostning kan dokumenteres ved regnskabsførte historiske udgifter. Man bør se en klar systematik i de antagelser, som risikovurderingerne hviler på. Risikovurderinger uden forklaringer og kilder skaber usikkerhed om den samlede business case. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [30]

33 5.5 Sammenhæng mellem risikoregister, afhængigheder og business case Der bør være en sammenhæng mellem de risici man har identificeret og indskrevet i risikoregisteret og risikojusteringen i business casen. Har man eksempelvis identificeret en risiko for, at en teknologisk løsning ikke virker, kan man reflektere dette i business casen ved at indarbejde usikkerhed om ressourceforbruget i den tilhørende fase. Dette punkt er også en indikator for, om der er tilstrækkeligt samarbejde mellem institutionens projektfolk (som typisk varetager risikoregisteret) og institutionens økonomiafdeling (som ofte er tovholder på business casen). Business casen bør også reflektere projektets interne afhængigheder. Ideelt set bør risici fra risikoregisteret kunne genfindes direkte i business casens estimater, og der bør være taget højde for alle beskrevne interne afhængigheder i estimater og usikkerhedsspænd. 5.6 Sandsynlighedsvurderinger Hvis sandsynlighedsvurderingerne gennemgående er ens og symmetriske, og derved ikke er specificeret til de konkrete forudsætninger, er det tegn på, at trepunktsestimeringen ikke tager højde for konkrete risici. Det udgør en risikofaktor for business casens validitet, da usikkerhedsspændene i så fald ikke vil passe til de risici projektet står over for. 5.7 Forudsætningsdiagram genfindes i business casen Udarbejdelse af et detaljeret forudsætningsdiagram går forud arbejdet med selve udfyldelsen af business casens regneark. Forudsætningsdiagrammet skaber et tydeligt overblik og indsigt i business casens drivende og vigtigste forudsætninger og er dermed også med til at tydeliggøre projektets usikkerheder. Således er et gennemarbejdet forudsætningsdiagram udgangspunktet for at udarbejde en god business case. Stemmer forudsætningsdiagrammet derfor ikke overens med de forudsætninger, der indtastes i regnearket, mistes denne overskuelighed og det bliver sværere at videreformidle, hvilke forudsætninger, der er drivende for projektet. Endvidere bør forudsætningsdiagrammet bygge på PID'ens forretningsbeskrivelse, så alle forudsætninger for forretningsforandringen medtages. 5.8 Tidsplan Selvom tidsfaktoren ikke i sig selv medtages i trepunktsestimeringer i business casen kan de økonomiske konsekvenser af en forsinkelse indføres i disse trepunktsestimeringer ved det høje estimat (worst case). Dette vil især være hensigtsmæssigt, hvis tidsplanen for udrulning og gevinsthøstning er meget aggressiv. Er der eksempelvis indsat milepæle kort tid efter det aktuelle tidspunkt eller hvis gevinster forventes høstet kort tid efter afslutning på faser, kan det være tegn på stor optimisme i business casen, som bør stå mål med de risici og derved den usikkerhed som en sådan stram tidsplan fordrer. En langsom indfasning af gevinster efter implementeringen vil ofte tyde på større realisme i forhold til projektets evne til at realiseres business casen, og derved færre risici og mindre usikkerhed for resultatet. 5.9 Driftsscenarier Det er obligatorisk at indtaste data for både 0-scenarie, 1-scenarie og, medmindre alle opgaver er nye, også for før-situationen. Husk, at forudsætningerne skal dække levetiden for systemet, hvilket som oftest vil være fem år for tilpasning eller nyudvikling af applikationer til et i forvejen eksisterende standardsystem eller otte år for specialudvikling af et forrentningskritisk system. Levetidsreglerne administreres af Moderniseringsstyrelsen Gevinstejere Der skal være navngivne gevinstejere på alle gevinster. Klart definerede gevinstejere og aftaler med disse om ansvaret for høstning af gevinsterne er en nødvendighed for at sikre, at projektets gevinster også høstes. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [31]

34 5.11 Ikke-økonomiske gevinster Ikke-økonomiske gevinster skal angives, hvis der er tale om et projekt, der har kvalitetsløft som formål. Såfremt der er tale om et effektiviseringsprojekt eller opfyldning af lovgivning kan potentielle ikke-økonomiske gevinster angives i projektets business case. Selvom der er tale om ikke-økonomiske gevinster, skal de være målbare, med klare, neutrale og korte navne, samt angivne enheder og prioritering. Såfremt projektets PID omtaler ikkeøkonomiske gevinster, skal disse fremgå af business casen, og det bør klart fremgå, hvem der er gevinstejer, samt hvornår gevinsterne forventes høstet. Enheden gevinsterne måles i, bør være tilpasset karakteren af gevinsterne. Målbare gevinster er et ufravigeligt krav, dels for at skabe et klart beslutningsgrundlag for projektets styregruppe, dels for at der kan følges op på om gevinsterne høstes. De gennemgåede temaer i dette afsnit er en vejledning til en intern kvalitetssikring - som en hjælp til selvhjælp. At have fulgt temaerne kan dog aldrig give en garanti for, at projektet eller programmet ikke kan få anbefalinger vedrørende business casen og forretningspotentialet ved en risikovurdering i Statens IT-projektråd. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [32]