Vejledning til statens business casemodel

Transkript

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

2 Indhold 1 INDLEDNING FORMÅL HVAD ER STATENS BUSINESS CASE-MODEL? 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 PRINCIPPER SCENARIER OG GEVINSTER NEDBRYDNING AF UDGIFTER I FORUDSÆTNINGER RISICI, USIKKERHED OG TREPUNKTSESTIMERING 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É OPDATERING AF BUSINESS CASEN KVALITETSSIKRING SAMLET SPÆND PÅ UDGIFTER RISIKOPULJE VÆGTEN AF STØRSTE POST BAGGRUND OG KILDER FOR ESTIMATER SAMMENHÆNG MELLEM RISIKOREGISTER, AFHÆNGIGHEDER OG BUSINESS CASE SANDSYNLIGHEDSVURDERINGER Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen

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

4 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 Nedbrydning af udgifter i forudsætninger, se afsnit 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 Et regneark, se afsnit Et business case-resumé, se afsnit 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]

5 Figur 1. Den fællesstatslige it-projektmodel inkl. ledelsesprodukter. 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. 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 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]

6 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 ). 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 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]

7 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. 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. 3) Den fremtidige driftssituation hvis projektet eller programmet gennemføres, kaldet 1 scenariet, og hvis det ikke gennemføres, kaldet 0-scenariet. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [4]

8 Disse er illustreret i nedenstående figur. Figur 4. Overordnet indhold i statens business case-model 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. 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 projek- 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. tets 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 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. 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 Definition: 0-scenarie Driftssituationen med det billigste alternativ til at løse samme opgaver som projektet eller programmet påvirker. 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. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [5]

9 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 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 Definition: 1-scenarie Projektudgifter, samt driftssituationen med projektet eller programmet fra de første gevinster realiseres. 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 Gevinster Når vi har tal for før-situationen og de to fremtidsscenarier, kan projektets gevinster beregnes. Gevinsterne er forskellen på at implementere projektet eller programmet og ikke at gøre det. Gevinsterne kan derved godt være negative. 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. 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 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. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [6]

10 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 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 Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [7]

11 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 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 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 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. 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 ned- Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [8]

12 brydningen 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 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 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. Slutteligt angives et højt estimat (worst case), som er det realistisk højeste estimat, givet de risici der kan indtræffe. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [9]

13 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 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. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [10]

14 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 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å 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å 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 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]

15 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 [12]

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 [13]

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 8. 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. 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]

18 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. 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. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [15]

19 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 (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 [16]

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

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 10. 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. 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 [18]

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. Disse arbejdsprocesser er mellemregninger til hovedforudsætningen 'Fagspecifikke arbejdsgange' og de tre arbejdsprocesser A, B og C er derfor markeret 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 casemodellen, men illustrerer, at forudsætningerne kan kobles til forskellige konti i statens kontoplan som I business casens regneark bør det oplyses, hvilke konti forudsætningerne knytter sig til. Tastearbejdet i regnearket bliver lettere, hvis dette allerede er illustreret i forudsætningsdiagrammet Kvalitetsløftsgevinster Forudsætningsdiagrammet udarbejdes 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 nedenfor er vist et standardiseret diagram for typiske kvalitetsløftsgevinster. Figur 11. Standard-forudsætningsdiagram for kvalitetsløftsgevinster Overgang fra gevinstdiagram til forudsætningsdiagram Selvom forudsætningsdiagrammet er første trin i business case-processen, findes der andre dele af den fællesstatslige it-projektmodel og programmodel, der kan tages udgangspunkt i, når diagrammet skal laves. Gevinstdiagrammet illustrerer eksempelvis sammenhængene i projektet eller programmet for at opnå de ønskede gevinster, som vist i figuren nedenfor. Der arbejdes med flere konkrete leverancer, mål (resultater for programmer) og gevinster under hver type som indbyrdes er forbundet med pile for at vise kausalitet. Se Vejledning: Udarbejdelse af gevinstdiagram. Figur 12. Gevinstdiagram. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [19]

23 Formålet med gevinstdiagrammet at nedbryde formålet for projektet (eller visionen for programmer) til gevinster, som endeligt ender i leverancer. Kategorierne mål (resultater for programmer) 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 kategorien leverancer (og forandringsevner for programmer) fungere som fundament for projektudgifterne i forudsætningsdiagrammet. Da gevinstdiagrammet fokuserer på gevinstkæderne, er det 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, Definition: Hovedforudsætningsgruppe En hovedforudsætning samt tilknyttede underforudsætninger, der er med til at definere indholdet i hovedforudsætningen, kaldes en hovedforudsætningsgruppe. 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. 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 ind- Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [20]

24 sæ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]

25 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. 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 Udskriv alle ark Gem som PDF Udskriv business case Hent projektudgifter Kopier 0-scenarie til 1- scenarie Kopier 1-scenarie til 0- scenarie Importer BC 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 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. 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. Kopierer samtlige forudsætninger i 0-scenariet og indsætter dem i 1-scenariet. Dette vil overskrive alle eksisterende forudsætninger. Kopierer samtlige forudsætninger i 1-scenariet og indsætter dem i 0-scenariet. Dette vil overskrive alle eksisterende forudsætninger. Importerer data fra en valgt eksportfil. Kontakt Ministeriernes projektkontor for at eksportere data fra en business case. Dette vil overskrive alt data! Hvis du skal hente projektudgifter til et program skal du i stedet anvende hent projektudgifter. Låser arket / låser arket op. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [22]

26 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]

27 Forside Stamdata Opsætning Tidsplan Risici Ikke-økonomiske gevinster Gevinstejere Udgiftsbærere Projekter Omkostningsbaseret projektøkonomi PL-år Versionshistorik 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 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. 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. 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 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. Her indtastes, hvilke ændringer, der er lavet fra version til version. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [24]

28 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]

29 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]

30 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é Business casens resumé findes i arket Business casen og indeholder alle resultater og nødvendig information. 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]

31 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]

32 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.6: Ikke-økonomiske gevinster (risikojusteret) Tabel 1.7: Omkostningsbaserede udgifter, risikojusteret 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 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 Figur 1.17b.: Foreslået løsning sammenlignet med 0 scenarie (ekskl. projektudgifter) Figur 1.17c.: Foreslået løsning sammenlignet med 0 scenarie (inkl. projektudgifter) 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 4.4 Opdatering af business casen Når business casen skal opdateres ved væsentlige ændringer eller faseovergange foretages det ved dels at reestimere forudsætninger for fremtidige år med den nye viden, dels ved at ændre de på opdateringstidspunktet kendte forudsætninger fra usikre trepunktsestimeringer til sandsynlighedsmodellen ikke usikker. Herved fjernes trepunktsestimeringen og den reelle værdi for pågældende forudsætning kan tastes ind i stedet. Hvis der eksempelvis var forventet at bruge mellem 1000 og 3000 interne timer på kravsspecifikation i anskaffelsesfasen kan dette trepunkts-spænd opdateres til det reelle timeforbrug ved den næste faseovergang. I tilfælde hvor projektlederen ikke har kendskab til det løbende forbrug på så detaljeret et niveau som business casen er nedbrudt til, kan opdateringen også blot foretages på hovedforudsætningsniveau, hvor underforudsætningerne i så fald slettes, og hovedforudsætningen ændres til uden underforudsætninger samt ikke usikker således at det reelle forbrug for pågældende hovedforudsætning blot kan indtastes. Den fællesstatslige it-projekt-/programmodel, Digitaliseringsstyrelsen [29]

33 5 Kvalitetssikring 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]

34 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]

35 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]