Ministerialtidende
Ministerialtidende
2008 Udgivet den 26. april 2008
12. marts 2008. Nr. 21.
Cirkulære om udarbejdelse af business case for digitaliseringsprojekter
Formål
§ 1. Cirkulære om udarbejdelse af business case for digita- liseringsprojekter har til formål at fastlægge, hvornår statslige virksomheder skal udarbejde en business case ved hjælp af den i bilag 1 vedlagte business case model for digitaliserings- projekter.
Anvendelsesområde
§ 2. Cirkulæret omfatter statslige virksomheder som defi- neret i Budgetvejledning 2006 punkt 2.2.1.
Anvendelse af den generelle business case model
§ 3. Den i bilag 1 vedlagte business case model skal udar- bejdes ved alle digitaliseringsprojekter, hvis samlede budget-
terede udgifter til anskaffelse og udvikling, herunder internt ressourceforbrug, udgør 10 millioner kroner eller derover.
Stk. 2 . Ved et digitaliseringsprojekt forstås et projekt, som omfatter omkostninger til fx hardware, software, systemud- vikling, intern og ekstern it-konsulentbistand.
§ 4. Der skal også udarbejdes en business case i forbindelse med en reinvestering.
Stk. 2. Ved reinvesteringer forstås et projekt, hvor et eksi- sterende system fx skal videreudvikles eller erstattes.
§ 5. Ved udarbejdelse af business case, jf. §§ 3 og 4, an- vendes den som bilag 2 vedlagte »vejledning til business model for offentlige digitaliseringsprojekter«.
Finansministeriet, den 12. marts 2008
Xxxx Xxxxx Xxxxxxxxx
/ Xxxxxx Xxxxxxxx
AE001297
Finansmin., x.xx. 126-36
Business case model for digitaliseringsprojekter
Bilag 1
(Se også business case model, regneark og case-eksempler mm. på xxxxxxxxxxxxx.xx/xxxxxxxxxxxx.)
Indholdsfortegnelse Ledelsesresume Revisionshistorik
1 Løsningsbeskrivelse
1.1 Forretningsmæssigt omfang
1.2 It-mæssigt omfang
1.3 Interessenter
1.4 Alternative løsninger
1.5 Delprojekter
1.6 Afhængigheder til sideordnede projekter
2 Forretningsmæssige konsekvenser
2.1 Økonomiske konsekvenser
2.2 Økonomiske nøgletal
2.3 Kvalitative gevinster
2.4 Risici
3 Implementering og opfølgning
3.1 Implementeringsstrategi
3.2 Milepælsplan
3.3 KPI’er
4 Ejerskab
4.1 Projektejer og projektleder
4.2 Leverandører
4.3 Opfølgning på forretningsmilepæle
4.4 Sponsorer
4.5 Godkendelse
Bilag
Ledelsesresume
Revisionshistorik
Version | Opsummerende beskrivelse af ændringer | Dato | Xxxx og instans |
1 Løsningsbeskrivelse
1.1 Forretningsmæssigt omfang
1.1.1 Forretningsløsningens navn eller kort beskrivelse (anvend 1-2 linjer)
Forretningsløsningens navn
1.1.2 Formål (sæt et eller flere krydser)
Forbedre servicekvalitet (f.eks. hurtigere sagsbehandlingstid eller øget mulighed for borger- selvbetjening) | |
Effektivisere forretningsprocesser eller reducere driftsomkostninger (f.eks. automatisering af processer) | |
Effektivisere it-applikationer (f.eks. udskiftning af gammel applikationslogik eller integrere applikationer) | |
Effektivisere it-infrastruktur (f.eks. konsolidering af servere, reducering af antal platforme) | |
Forbedre fleksibilitet i forretningsarkitektur (f.eks. understøttelse af standardiserede proces- ser) | |
Forbedre fleksibilitet i it-arkitektur (f.eks. indføring af åbne standarder eller implementering af SOA) | |
Opfylde lovgivning (hvis projektet sikrer opfyldelse af lovgivning (national eller internatio- nal)) |
1.1.3 Forvaltningsniveau for løsningens brug (vælg et eller flere forvaltningsniveauer)
Niveau | ||||
Inden for et eller flere ministerområ- der (benyt ministe- rienavn) | Inden for en eller flere regioner | Inden for en eller flere kommuner | Inden for en eller flere selvejende institutioner | |
Angiv navne, hvis der er mellem 1 og 5 | ||||
Angiv antal hvis der er mere end 5 | ||||
1.1.4 Kategorisering af forretningsområde (benyt én række per relevant forretningsområde)
Serviceområde |
Opgaveområde |
1.1.5 Forretningsmæssig baggrund (anvend 10-15 linjer)
1.1.6 Forretningsmæssig problemstilling (anvend 10-15 linjer)
1.1.7 Forretningsmæssig løsningsbeskrivelse (anvend 10-15 linjer)
1.1.8 Løsningens brugere (benyt én række per brugerkategori)
Løsningens brugere | Brugerkategori (borgere; virksomheder eller offentligt ansatte) | Antal |
1.1.9 Lovgivningsmæssige hensyn (benyt en eller flere rækker)
Dokumenttype | Navn og afsnit/para- graf | Beskrivelse af hensyn, løsningen skal tage |
1.2 It-mæssigt omfang
1.2.1 Applikationsomfang (benyt én række per applikationsnavn)
Applikationsnavn (f.eks. »lagerstyrings- systemet«) | Type (finansiel; selvfor- valtningsløsning; sogi- stik; fagsystem; BI; EPJ; ESDH; hvis andet, angiv da) | Leverandør (egenudvikling; eks- tern leverandør (hvis muligt – angiv hvil- ken)) | Platform (mainframe; midrange OS400/ UNIX/ VMS; Windows; Linux; hvis andet, angiv da) |
1.2.2 Infrastrukturomfang (benyt én række per infrastrukturkomponentnavn)
Infrastruktur- | Middleware (por- | Serverplatform | Lagring/ | Platform for | Netværksydel- |
komponentnavn | tal; processerver; | (mainframe; | backup | adgang (stati- | se (data LAN/ |
(f.eks. »applika- | applikationsser- | midrange | (SAN; | onær pc; bær- | WAN; video; |
tions-server1«) | ver; ESB/messag- | (OS400/UNIX/ | NAS; | bar pc; PDA/ | telefoni; inter- |
ing; adapter/con- | VMS); Win- | DAS) | mobil; stem- | netadgang; | |
nector; partner ga- | dows; Linux; | mestyret; ydre | ASP) | ||
enheder; hvis |
teway; hvis andet, angiv da) | hvis andet, an- giv da) | andet, angiv da) | |||
1.2.3 It-mæssig løsningsbeskrivelse (anvend 10-35 linjer; valgfrit at bruge illustration)
1.3 Interessenter
# | Identificerede interessenter (benyt én række per interes- sent) | Påvirket af løsning | Ind-flydelse på løsning | Involvering i dialog om- kring løs- ningen (sæt ét kryds) | Beskrivelse af involve- ring (kun, hvis der har været en involvering) | |||||
La v | Mi dd el | Hø j | La v | Mi dd el | Hø j | Ja | Nej | |||
1 | ||||||||||
2 | ||||||||||
.. | ||||||||||
1.4 Alternative løsninger
1.4.1 Nulløsningen (anvend 5-15 linjer i hver række)
Nulløsningen | |
Fordele i forhold til foreslået løs- ning | |
Ulemper i for- hold til foreslået løsning |
1.4.2 Mulige fremtidige alternative løsninger (anvend 5-15 linjer i hver række; benyt én tabel per alternativ)
Alternativ #1 | |
Fordele i forhold til foreslået løs- ning | |
Ulemper i for- hold til foreslået løsning |
1.5 Delprojekter
1.5.1 Beskrivelse af identificerede delprojekter (benyt én række for hvert delprojekt)
Navn eller refe- rence for delpro- jekt | Beskrivelse af afgrænsende karakteristika for delprojekt | Ansvarlig for delpro- jekt (navn og instans) |
1.5.2 Delprojekter for hvilke der findes en business case (benyt én række for hvert delprojekt)
Navn eller refe- rence for delpro- jekt | Business case for delprojekt (udkast; godkendt) | Projektejer af busin- ess case (navn og in- stans) |
1.6 Afhængigheder til sideordnede projekter
Navn eller refe- rence for sideord- net projekt | Beskrivelse af afhængighed til si- deordnet projekt | Instans, der ejer pro- jektet og dets løsning | Ansvarlig for side- ordnet projekt (navn og instans) |
2 Forretningsmæssige konsekvenser
2.1 Økonomiske konsekvenser
2.1.1 Pengestrømsopgørelse - udgiftsbaseret (indsæt tabel fra »Business case regneark«)
2.1.2 Pengestrømsoversigt - udgiftsbaseret (indsæt diagram fra »Business case regneark«)
2.1.3 Bevillingskonsekvenser - omkostningsbaseret (indsæt tabel fra »Business case regneark«)
2.1.4 Illustration af bevillingskonsekvenser - omkostningsbaseret (indsæt diagram fra »Business case regneark«)
2.2 Økonomiske nøgletal
2.2.1 Økonomiske nøgletal (benyt tal fra »Business case regneark«)
Projektets nutidsværdi (NPV), i DKK | |
Projektets interne rente (IRR), i procent | |
Projektets tilbagebetalingstid, i hele år |
2.2.2 Beregningsgrundlag (benyt tal fra »Business case regneark«)
Diskonteringsrente i udregning af nutidsværdi, i procent | |
Tidshorisont i udregning af nutidsværdi og intern rente, i hele år | |
Finansieringsrente, i procent | |
Aktivets levetid/afskrivningsperioden for det optagede lån, i hele år |
2.3. Kvalitative gevinster
2.3.1 Eksterne serviceforbedringer (anvend 5-35 linjer)
Service | Type af forbedring | Beskrivelse |
2.3.2 Interne serviceforbedringer (anvend 5-35 linjer)
Service | Type af forbedring | Beskrivelse |
2.3.3 Fleksibilitet (anvend 5-35 linjer)
Type af fleksibilitet | Type af forbedring | Beskrivelse |
2.4 Risici
2.4.1 Identificerede risici (benyt én række for hver identificeret risiko)
Risikoområ- de (organisa- tion; teknisk løsning; le- verandører; interessen- ter) | Beskrivelse af identifice- ret risiko | Sand-syn-lig- hed | Konse-kvens | Håndtering af identifice- ret risiko | ||||
La v | Mi dd el | Hø j | La v | Mi dd el | Hø j | |||
2.4.2 Samlet risikovurdering (sæt ét kryds)
Høj risiko | |
Middel risiko | |
Lav risiko |
2.4.3 Økonomisk risikovurdering
Sandsynlighed | Konsekvens (angiv ændring i forventede omkostninger og økonomiske gevinster, i DKK, hvis risiko realiseres) | |||
Lav | Mid- del | Høj | ||
Risiko for, at omkostninger bliver større end angivet i afsnit 2.1 og 2.2 | ||||
Risiko for, at økonomiske gevinster bliver mindre end angivet i afsnit 2.1 og 2.2 | ||||
3 Implementering og opfølgning
3.1 Implementeringsstrategi
3.2 Milepælsplan
3.2.1 Projektleverancemilepæle (benyt én række for hver milepæl)
# | Projektleverance-mi- lepæl | Forventet dato | Nøgleleverancer | Budget forbrugt |
1 | ||||
2 | ||||
.. |
3.2.2 Forretningsmilepæle (benyt én række for hver milepæl)
# | Forretningsmilepæl | Forventet dato | Gevinster ved milepæl | KPI der skal måles ved mi- lepæl |
1 | ||||
2 | ||||
.. |
3.3 KPI’er
KPI (benyt én tabel per KPI) | ||||
Hvorfor måles? | ||||
Hvordan måles? | ||||
Hvem er ansvarlig for måling? | ||||
Forventet målingsdato | Forventet værdi- interval for mål- ing | Måling | Handlingsplan, ifald målin- gen ligger uden for forventet interval | Ansvarlig for hand- ling (navn og in- stans) |
<dato_1> | ||||
<dato_2> | ||||
… | ||||
4 Ejerskab
4.1 Projektejer og projektleder
Business casens ejer og overordnet ansvarlig for dens udarbejdelse og opdatering (navn og instans) | |
Intern projektleder (navn og instans) |
4.2 Leverandører
Leverandør | Faser i hvilke leverandør er in- volveret (f.eks. analyse; design; udvikling; test; iværksættelse; drift) | Hovedansvarsområder og/eller nøgleleveranceansvar |
4.3 Opfølgning på forretningsmilepæle
Milepæl (benyt navne fra tabel i afsnit 3.2.2) | Ansvarlig for at milepæl nås (navn og instans) |
Sponsorer
Sponsor (f.eks. ho- vedkonto el- ler under- konto) | År | Finansierings- omkostninger i DKK | Renteudgifter til finansie- ring i DKK | Ressourcer i årsværk (omregnet til DKK) | Driftsudgifter i DKK | Andet |
4.5 Godkendelse
Indholdet af denne version af business casen er vurderet og godkendt af styregruppe og projektsponsorer | ||||
Rolle | Navn og instans | Stilling | Dato | Godkendt ved under- skrift |
Bilagsoversigt
Bilagstitel | Afsnit i denne business case som bi- laget hører til | Bemærkninger |
Vejledning til business case model for offentlige digitaliseringsprojekter
Bilag 2
(Se også business case model, regneark og case-eksempler mm. på xxxxxxxxxxxxx.xx/xxxxxxxxxxxx.)
Indholdsfortegnelse Introduktion til vejledningen
Formål
Vejledningens opbygning
Typisk anvendelse af business case modellen
Ledelsesresume Revisionshistorik
1 Løsningsbeskrivelse
1.1 Forretningsmæssigt omfang
1.2 It-mæssigt omfang
1.3 Interessenter
1.4 Alternative løsninger
1.5 Delprojekter
1.6 Afhængigheder til sideordnede projekter
2 Forretningsmæssige konsekvenser
2.1 Økonomiske konsekvenser
2.2 Økonomiske nøgletal
2.3 Kvalitative gevinster
2.4 Risici
3 Implementering og opfølgning
3.1 Implementeringsstrategi
3.2 Milepælsplan
3.3 KPI’er
4 Ejerskab
4.1 Projektejer og projektleder
4.2 Leverandører
4.3 Opfølgning på forretningsmilepæle
4.4 Sponsorer
4.5 Godkendelse Bilag Ordforklaringer
Introduktion til vejledningen
Formål
Business case modellen for offentlige digitaliseringsprojekter er et godkendelses- og opfølgningsværktøj for værdiskabende investeringer, hvor it-teknologi udgør en væsentlig del af omkostningerne. Modellen bør som hovedregel anvendes i stat, region og kommune i forbindelse med digitaliseringsprojekter. Modellen skal anvendes i staten, hvis den samlede forretnings- og it-investering andrager DKK 10 millioner eller derover.
En business case er ikke det samme som en projektplan. Eksempelvis kræves der ikke nogen detaljeret løsningsbeskrivelse og ej heller nogen detaljeret aktivitetsplan i en business case. Business casen fokuserer på de forretningsmæssige aspekter af løsningen, specielt beslutningsgrundlaget for den samlede investering og værdiskabelsen, efter løsningen er taget i brug.
Business casen er bygget op omkring fire hovedafsnit. Første afsnit omhandler den foreslåede løsning og dens omfang. Dette afsnit skal give beslutningstagerne et grundlag for at vurdere, hvad investeringen rettes mod. Andet afsnit omhandler projektets forretningsmæssige konsekvenser, dvs. hvilke investeringer, der skal foretages, hvilke risici projektet indeholder, og hvilke økonomiske og kvalitative gevinster projektet forventes at resultere i. Tredje afsnit omhandler, hvorledes projektet i praksis gennemføres i forhold til anvendelse af ressourcer og tid, samt hvilke projekt- og forretningsmæssige milepæle projektet indeholder. Fjerde afsnit omhandler hvilke parter, som har et ejerskab omkring løsningen. Dette skal give beslutnings- tagerne en klar redegørelse for, hvem der godkender, sponsorerer, bygger og ejer løsningen. Tillige identificeres hvem der er ansvarlig for opfølgningen på værdiskabelsen via de forskellige forretningsmile- pæle.
En business case består af to dokumenter. Hoveddokumentet er selve »business case modellen« (Microsoft Word) og dertil hører et støttedokument til økonomiske beregninger kaldet »business case regneark« (Mi- crosoft Excel).
Som supplement til vejledningen findes et eksempel på en udfyldt business case model med tilhørende business case regneark.
Business case modellen er udarbejdet med henblik på at understøtte offentlige institutioner i beslutninger om og opfølgningen på digitaliseringsinvesteringer.
Vejledningen er primært rettet mod den eller de personer, som er ansvarlige for udarbejdelse og opfølgning på business casen.
Sekundært er den rettet mod beslutningstagerne som baggrundsinformation omkring retningslinier for udarbejdelse og vedligeholdelse af en business case.
En business case er et levende dokument, der forventes at blive løbende opdateret under projektforløbet. Vejledningen tænkes derfor brugt både ved den første udarbejdelse af business casen og ved efterfølgende opdateringer.
Vejledningens opbygning
Vejledningens afsnitsnummerering er identisk med business case modellens. Dette betyder, at et givent afsnit forklarer, hvorledes det tilsvarende afsnit i business case modellen bør udfyldes. Alle tabeltekster er angivet i vejledningen med tilhørende vejledning til udfyldelse af de enkelte tekstfelter (markeret med ly- segrå baggrundsfarve).
I hvert af business case modellens afsnit er der felter, som skal udfyldes. Disse felter er markeret med lysegrå baggrund. Felterne optræder både som enkeltstående tekstfelter, hvor længere passager kan anføres, og som celler i tabeller. Bortset fra forsideteksten skal der i business casen kun udfyldes tekst i de lysegrå felter.
Alle disse felter er som udgangspunkt obligatoriske at udfylde. Undtagelsen herfor er de felter, der re- præsenterer godkendelse af business casen. Disse kan i sagens natur ikke udfyldes, før business casen er fremlagt og godkendt.
Visse afsnitsoverskrifter og tabeltekster indeholder tekst i parenteser. Denne hjælpetekst kan dels angive regler for eller anbefalinger til udfyldelse af felter og dels angive et sæt mulige værdier at vælge mellem til udfyldelse af felter.
Der kan angives andre værdier, hvis hjælpeteksten angiver dette (»hvis andet, angiv da«). I så fald skal teksten starte med »Xxxxx:« efterfulgt af en semikolonsepareret liste af alternative værdier f.eks. »Andet: ABC; DEF; GHI«.
Ved anførelse af beløb i DKK anvendes om nødvendigt »tusinder«, »millioner« etc. med henblik på at gøre det så let forståeligt for læseren som muligt. Der er ikke krav om konsistens gennem hele business casen.
Herunder følger et eksempel på en typisk tabel. Teksten i kursiv illustrerer, hvorledes felterne udfyldes, og det findes ikke i business case modellen.
Tabeltekst | Tabeltekst | |||||||
Tabeltekst | Tabeltekst | Tabeltekst | Tabel- tekst | Tabel- tekst (værdi 1; værdi 2; hvis an- det, angiv da) | Tabel- tekst (værdi 1; værdi 2; værdi 3; værdi 4) | |||
Lav | Middel | Høj | Ja | Nej | ||||
<her kan skrives tekst> | <her kan sættes kryds> | <her kan sæt- tes kryds> | <her kan sæt- tes kryds> | <her kan sættes kryds> | <her kan sæt- tes kryds> | <her kan skrives tekst> | <her skal vælges blandt de viste vær- dier eller angives alternati- ve værdi- er> | <her skal vælges blandt de viste vær- dier> |
Skriftstørrelsen er i alle felter valgt til punkt 8 og bør ikke ændres at hensyn til tabellernes og felternes layout.
Typisk anvendelse af business case modellen
I dette afsnit illustreres, hvorledes en typisk anvendelse af business case modellen kunne forløbe.
Først introduceres nogle typiske interessentroller omkring business casen og de faser, realiseringen af en løsning gennemgår.
Tabellen herunder beskriver typiske interessenter involveret omkring en business case. Bemærk, at én person godt kan udfylde flere interessentroller.
Interessent | Beskrivelse |
Bestiller | Person(er) eller instans(er), som har behov for den foreslåede løsning |
Projektejer | Person(er), som tager overordnet ejerskab for at promovere og realisere løs- ningen. Dette inkluderer specielt udarbejdelse af og opfølgning på business casen |
Sponsor | Person(er) eller instans(er), der forpligtiger sig til at bidrage med de nødvendige ressourcer (finansielle og ikke-finansielle) for løsningens realisering (inklusiv drift) |
Godkender | Person(er), som godkender business casen for den foreslåede løsning |
Projektledelse | Person(er), som er ansvarlig for projektets gennemførsel |
Leverandør | Part(er), som projektledelsen benytter sig af til at gennemføre projektet |
Driftsansvarlig | Part(er), som er ansvarlig for løsningens drift |
Figuren herunder som illustrerer de faser realiseringen af en løsning gennemgår, viser hvorledes business case modellen er kompatibel med PRINCE2-PID (projektinitieringsdokument). Det er vigtigt at være op- mærksom på, at business casen er et beslutningsværktøj, mens PRINCE2-PID er et projektplanlægnings- værktøj.
Som det ses, udarbejdes business casen under fase 2 og 3. Her vil ofte være tale om en iterativ proces. Herefter overføres business case informationerne til PID. Efter fase 3 opdateres business casen kun, hvis der er større ændringer til eksempelvis omfang, løsning og økonomi. Disse ændringer skal da godkendes på ny. I fase 6 anvendes business casen til opfølgning på værdiskabelse, men den opdateres som regel ikke i denne fase.
Den følgende tabel illustrerer på overordnet niveau en typisk anvendelse af business case modellen. Be- mærk, at der er tale om et eksempel, og at interessenter, tidsforbrug etc. kan variere betragteligt fra projekt til projekt.
Skridt | Interessent | Aktivitet | Tidspunkt (fase) | Arbejdsbyrde for udarbejdel- se af business case |
1 | Bestiller | Identificerer behov for en løsning, ud- arbejder overordnede krav til en løsning og kontakter den kommende projektan- svarlige med henblik på udarbejdelse af business case | Identificer behov | 2 dage – 1 uge |
2 | Projektejer | Identificerer styregruppe (godkender) og potentiel projektledelse. Tager ejerskab for udarbejdelsen af bus- iness casen og har dialog med relevante interessenter (f.eks. sponsorer og styre- gruppemedlemmer) | Foreslå løs- ning | 1-2 uger |
Bestiller | Er projektejeren behjælpelig med input til business casen | Foreslå løs- ning | 1-5 dage | |
Projektledelse | Påbegynder udarbejdelse af vanlige pro- jektstyringsdokumenter Er projektejeren behjælpelig med udar- bejdelsen af business casen | Foreslå løs- ning | 1-2 uger | |
Sponsor | Tilkendegiver overfor projektejeren i hvilket omfang, denne kan bidrage til dækning af business casens budget | Foreslå løs- ning | 1-3 dage | |
3 | Projektejer | Præsenterer business case for styregrup- pe | Godkend løsning | 1-2 dage |
Godkender | Evaluerer, prioriterer og godkender/af- viser business case | Godkend løsning | 1-2 dage | |
Sponsor | Evaluerer, prioriterer og godkender/af- viser business case | Godkend løsning | 1-2 dage | |
4 | Projektejer | Sørger for, at opfølgning på business ca- se sker i fornødent omfang under pro- jektet | Byg løsning | 1-4 uger |
Projektledelse | Er projektejeren behjælpelig med input til opfølgning af business casen | Byg løsning | 1-4 uger | |
Leverandør | Er projektledelsen behjælpelig i det om- fang, det skønnes nødvendigt | Byg løsning | 1-4 uger | |
5 | Projektejer | Sørger for, at opfølgning på business ca- se sker i fornødent omfang under pro- jektet | Iværksæt løsning | 1-5 dage |
Projektledelse | Er projektejeren behjælpelig med input til opfølgning af business casen | Iværksæt løsning | 1-5 dage | |
6 | Projektejer | Opfølgning på værdiskabelse som be- skrevet i business casen | Driv løsning og følg op | 1-6 uger (afhæn- gig af løsnin- gens levetid og business casens milepæle) |
Godkender | Monitorerer og evaluerer værdiskabel- sen, der fremlægges af projektejeren | Driv løsning og følg op | 1-5 dage |
Sponsor | Monitorerer og evaluerer værdiskabel- sen, der fremlægges af projektejeren | Driv løsning og følg op | 1-5 dage | |
Driftsansvarlig | Er projektejeren behjælpelig med input til opfølgning af business casen | Driv løsning og følg op | 1-4 uger | |
Bestiller | Er projektejeren behjælpelig med input til opfølgning af business casen | Driv løsning og følg op | 1-4 uger | |
7 | Projektejeren | Eventuel opfølgning på værdiskabelse som beskrevet i business casen (dette kunne f.eks. være, hvis løsningen sælges fra ved udfasningen, og en økonomiske gevinst herfor var medregnet i business casen). Involverer godkender, sponsor og drifts- ansvarlig efter behov | Udfas løs- ning | 1 uge |
Ledelsesresume
Ledelsesresumeet skal være kort og præcist.
Strukturmæssigt skal det indeholde fire korte afsnit:
• Projektets baggrund og nuværende situation
• Beskrivelse af komplikationen ved den nuværende situation
• Beskrivelse af løsningsforslaget og de væsentligste gevinster ved at implementere løsningen – både økonomiske og kvalitative
• Redegørelse for løsningens omkostning det første år, dens tilbagebetalingstid samt hvornår løsningen kan være i drift
Der bør anvendes 15-20 linjer. I særlige tilfælde, hvor alene ledelsesresumeet anvendes som beslut- ningsgrundlag, bør der anvendes ½ - 1 side
Revisionshistorik
Formålet med revisionshistorikken (også kaldet versionsstyring) er at skabe gennemsigtighed omkring væsentlige ændringer i business casen.
Version | Her angives versionsnummer på formen »<tal>.<decimal>«, hvor <tal> er et helt tal (0, 1, 2, …) og <decimal> er et af cifrene »0«, »1« til »99«. Versionsnummeret på forsiden af business casen skal svare til den nyeste (ne- derste) række i revisionshistoriktabellen. Følgende konvention bør benyttes for versionsnumrene: • Versionsnumre med slutcifre »1«,... , »99« er reserveret til versioner af bus- iness casen, som regnes for arbejdsudkast • Versionsnumre med slutcifre »0« er reserveret til versioner, som er klar til godkendelse • Versionsnumre skal være stigende og fortløbende |
Et eksempel på, hvorledes versionsnumre kan anvendes, er illustreret i tabellen herunder | |
Opsummerende be- skrivelse af ændringer | Her udarbejdes en opsummerende beskrivelse af væsentlige ændringer til den foreliggende version af business casen |
Dato | Her angives dato for udarbejdelse af den foreliggende business case |
Navn og instans | Her angives navn på den person, der har udarbejdet/modificeret denne version af business casen, samt navnet på den organisation eller instans, personen til- hører, f.eks. »Xxxx Xxxxxx, Silkeborg Kommune«, »Xxx Xxxxxx, Socialmini- steriet«, eller »Xxxxxx Xxxxxxxxx, Ry Højskole« |
Der skal tilføjes en ny række i tabellen, hver gang der udarbejdes en ny version af business casen. Et eksempel på, hvorledes versionsnumre kan anvendes, er illustreret herunder.
Benyttet versions- nummer | Forklarende tekst på eksemplets forløb |
0.1 | Første udkast |
0.2 | Endnu et udkast efter dialog med vigtig interessent (se afsnit 0) |
0.3 | Endeligt udkast (dvs. kan godkendes efter mindre aftalte ændring) |
1.0 | Version, der kan godkendes og underskrives |
1.1 | Udkast til opdatering af version 1.0 |
1.2 | Endnu et udkast (dvs. kan godkendes efter mindre aftalte ændring) |
2.0 | Opdateret version, der kan godkendes og underskrives |
1. Løsningsbeskrivelse
Formålet med løsningsbeskrivelsen er at beskrive løsningen samt hvilket forretningsmæssigt og it-mæssigt omfang, den har.
1.1 Forretningsmæssigt omfang
1.1.1 Forretningsløsningens navn eller kort beskrivelse (anvend 1-2 linjer)
Navn, som refererer til projektet eller løsningen (f.eks. »Atleticon«) eller en kort beskrivelse (f.eks. »Web-baseret system til reservation af offent- lige idrætsanlæg«)
Forretningsløsningens navn
1.1.2 Formål (sæt et eller flere krydser)
Forbedre service- kvalitet | Sæt kryds, hvis løsningen vil forbedre servicekvaliteten (f.eks. hurtigere sagsbe- handlingstid eller borgerselvbetjening) |
Effektivisere for- retningsprocesser eller reducere | Sæt kryds, hvis løsningen vil effektivisere forretningsprocesser eller reducere driftsomkostninger (f.eks. automatisere processer, reducere fejl, frigøre ressour- cer eller reducere indkøb) |
driftsomkostnin- ger | |
Effektivisere it-ap- plikationer | Sæt kryds, hvis løsningen vil effektivisere it-applikationer (f.eks. erstatte gammel applikationslogik eller integrere applikationer) |
Effektivisere it-in- frastruktur | Sæt kryds, hvis løsningen vil effektivisere it-infrastruktur (f.eks. konsolidere ser- vere, indføre virtualiseringsteknologi, mindske antallet af platforme eller centra- lisere datalagring) |
Forbedre fleksibi- litet i forretnings- arkitektur | Sæt kryds, hvis løsningen vil forbedre fleksibilitet af forretningen (f.eks. under- støtte standardiserede processer eller udvikle applikationer med henblik på pro- cesintegrering på tværs af forretningsområder), jævnfør afsnit 2.3.3 |
Forbedre fleksibi- litet i it-arkitektur | Sæt kryds, hvis løsningen vil forbedre fleksibilitet af it (f.eks. indføre åbne stan- darder, åbne platforme eller implementere serviceorienteret arkitektur (SOA)), jævnfør afsnit 2.3.3 |
Opfylde lovgiv- ning | Sæt kryds, hvis løsningen sikrer opfyldelse af lovgivning (national eller interna- tional) |
1.1.3 Forvaltningsniveau for løsningens brug (vælg et eller flere forvaltningsniveauer)
Indenfor et eller flere ministerområ- der | Hvis løsningen skal bruges inden for mellem 1 og 5 ministerområder, skal mini- sterienavnene listes (adskilt med semikolon). Hvis løsningen skal bruges inden for mere end 5 ministerområder, skal antallet angives. Hvis løsningen ikke skal bruges inden for et eller flere ministerområder lades feltet stå tomt |
Indenfor en eller flere regioner | Hvis løsningen skal bruges inden for regionerne, angives regionsnavnene (adskilt med semikolon). Hvis løsningen ikke skal bruges inden for en eller flere regioner, lades feltet stå tomt |
Indenfor en eller flere kommuner | Hvis løsningen skal bruges inden for mellem 1 og 5 kommuner, skal kommune- navnene listes (adskilt med semikolon). Hvis løsningen skal bruges inden for mere end 5 kommuner, skal antallet angives. Hvis løsningen ikke skal bruges inden for en eller flere kommuner, lades feltet stå tomt |
Indenfor en eller flere selvejende in- stitutioner | Hvis løsningen skal bruges inden for mellem 1 og 5 selvejende institutioner, skal institutionsnavnene listes (adskilt med semikolon). Hvis løsningen skal bruges inden for mere end 5 selvejende institutioner, skal antallet angives. Hvis løsningen ikke skal bruges inden for en eller flere selvejende institutioner, lades feltet stå tomt |
1.1.4 Kategorisering af forretningsområde (benyt én række per relevant forretningsområde)
Kategoriseringen af løsningen sker ved hjælp af den fællesoffentlige forretningsreferencemodel, som er en overordnet kategorisering af alle offentlige tjenester set i forhold til borgere og virksomheder.
Forretningsreferencemodellen kan findes på xxxxxxxxxxxxx.xx/xxxx, hvor talkoder for hvilket service- og opgaveområde løsningen dækker kan slås op.
Serviceområde | Her angives, hvilket serviceområde(r) løsningen bruges indenfor |
Opgaveområde | Her angives delområde(r) - hørende under det valgte serviceområde – inden for hvilket løsningen bruges |
Et eksempel på en hvordan en konkret løsning kategoriseres i forretningsreferencemodellen er indsat nedenfor:
Serviceområde | Uddannelse og arbejde (02) |
Opgaveområde | Videregående uddannelser (02.50) |
Det tal, som skal noteres i business case skabelonen, er i ovenstående eksempel 02.50. Hvis løsningen dækker flere opgaveområder i forretningsreferencemodellen noteres alle disse efter samme procedure.
1.1.5 Forretningsmæssig baggrund (anvend 10-15 linjer)
Her beskrives den forretningsmæssige baggrund. Der skal redegøres for den nuværende situation eller tilstand. Problemer beskrives først i næste afsnit.
Eksempelvis beskrives objektive fakta eller observationer såsom øget efterspørgsel, stigende udgifter, brugen af manuelle processer, etc.
1.1.6 Forretningsmæssig problemstilling (anvend 10-15 linjer)
Her beskrives de vigtigste forretningsmæssige problemer som løsningen adresserer, f.eks. manglende personalekapacitet i forhold til efterspørgsel, lange sagsbehandlingstider, budgetoverskridelser, etc.
Problemer vil typisk være relateret til de fakta, der beskrives i forrige afsnit.
1.1.7 Forretningsmæssig løsningsbeskrivelse (anvend 10-15 linjer)
Her beskrives løsningen. De overordnede formål skal forklares nærmere (dvs. detaljerne bag de kryds, der blev sat i afsnit 1.1.2).
De vigtigste gevinster skal nævnes, f.eks. frigjorte årsværk, serviceforbedringer eller understøttelse af overordnede strategier. Økonomiske omkostninger kan udelades her, idet de bliver præsenteret i afsnit 2.1.
1.1.8 Løsningens brugere (benyt én række per brugerkategori)
Løsningens bruge- re | Her angives, hvem løsningens specifikke brugere er, f.eks. personale i lønafde- lingen, skolens studerende, etc. |
Brugerkategori | Her angives, hvilken brugerkategori der er tale om. Der kan vælges mellem: Borgere, virksomheder eller offentligt ansatte |
Antal | Her angives, hvor mange brugere der forventes at benytte systemet. Man skal ikke angive det potentielle antal brugere men et skøn over det faktiske forventede antal brugere, som vil benytte løsningen, når den er fuldt udrullet |
1.1.9 Lovgivningsmæssige hensyn (benyt en eller flere rækker)
Hvis der er lovgivningsmæssige hensyn eller lignende forhold, som er relevante for løsningen, og som det vurderes nødvendigt at beslutningstagerne har specifikt kendskab til, skal denne tabel udfyldes. Der bør kun angives et par referencer, som på meget direkte vis angiver, hvilke krav eller aspekter løsningen skal tage hensyn til (f.eks. et lovkrav om løsningens implementering eller funktionalitet).
Dokumenttype | Her angives, hvilken type dokument (f.eks. lov, bekendtgørelse, cirkulære, etc.) som løsningen skal tage hensyn til |
Navn og afsnit/pa- ragraf | Her angives dokumentets navn og hvilket afsnit eller paragraf, som nærmere be- skriver det forhold, der skal tages hensyn til |
Beskrivelse af hen- syn løsningen skal tage | Her angives, hvad hensynet er, f.eks. imødekommelse af et lovkrav om at en bestemt funktionalitet skal implementeres |
1.2 It-mæssigt omfang
1.2.1 Applikationsomfang (benyt én række per applikationsnavn)
Applikationsnavn | Her angives et navn for en applikation, der indgår i it-løsningen. Det kan f.eks. være et kaldenavn for et egenudviklet model (»lagerstyringssystemet«) eller et gængs produktnavn (»Lotus Domino«). Bemærk, at der kun skal angives nye applikationer |
Type | Her angives hvilken type applikation, der er tale om. Der kan benyttes værdierne: Finansiel, selvforvaltningsløsning, logistik, fagsystem, BI, EPJ eller ESDH. Der kan vælges en eller flere af de listede værdier i hjælpeteksten (flere hvis f.eks. applikationen består af flere applikationsmoduler). Hvis ingen af disse er passende, skal man angive en alternativ værdi som be- skrevet i vejledningens introduktion, dvs. på formen »Andet: <XXXX>«, hvor <XXXX> repræsenterer en applikationstype |
Leverandør | Her vælges værdien »egenudvikling«, hvis applikationen, der beskrives i denne række, bliver udviklet at projektet selv. Ellers angives »ekstern leverandør«. Hvis den eksterne leverandør allerede er kendt, angives navnet på denne (f.eks. SAP eller IBM) |
Platform | Her angives den platform, applikationen tænkes eksekveret på. Der kan benyttes værdierne: Mainframe, midrange OS400/ UNIX/VMS, Windows, eller Linux. Værdien »midrange OS400/UNIX/VMS« dækker serverplatforme, der benytter et af operativsystemerne OS400, UNIX eller VMS. Der kan vælges en eller flere af de listede værdier i hjælpeteksten (flere hvis f.eks. applikationen kører på tværs af platforme). Hvis det er nødvendigt at benytte en alternativ (platforms)værdi, skal denne an- gives som beskrevet i vejledningens introduktion, dvs. på formen »Andet: <XXXX>«, hvor <XXXX> repræsenterer en platform |
1.2.2 Infrastrukturomfang (benyt én række per infrastrukturkomponentnavn)
Infrastruktur-kom- ponentnavn | Her angives et navn for en overordnet infrastrukturkomponent, der indgår i den foreslåede it-løsning. Det kan f.eks. være en middelwarekomponent »Kunde- portalen« eller en server »Produktionsmainframen«. Bemærk, at det er valgfrit at angive infrastruktur, medmindre business casen omhandler et infrastrukturpro- jekt |
Middleware | Her angives, om den navngivne komponent består af en bestemt kategori af middleware. Der kan benyttes en eller flere af værdierne: Portal, processerver, applikationsserver, ESB/messaging, adapter/connector eller partner gateway. Alle er gængse kategorier af middlewareprodukter på markedet. F.eks. dækker partner gateway over de produkter eller løsninger, som håndterer integration af processer eller udveksling af data med eksterne forretningspartnere (såsom hånd- tering af EDI baseret protokoler). Der kan vælges en eller flere af de listede værdier. Hvis ingen af disse er passende, skal man angive en alternativ værdi som beskrevet i vejledningens introduktion, dvs. på formen »Andet: <XXXX>«, hvor <XXXX> repræsenterer en kategori middleware. Hvis komponenten ikke er relateret til middleware, angives teksten »ej relevant« i feltet |
Serverplatform | Her angives, om komponenten er en platform. Der kan vælges en eller flere af de listede værdier i hjælpeteksten. Platformsværdierne er forklaret i forrige afsnit. Hvis det er nødvendigt at benytte en alternativ (platforms)værdi, skal denne an- gives som beskrevet i vejledningens introduktion, dvs. på formen »Andet: <XXXX>«, hvor <XXXX> repræsenterer en platform |
Lagring/ backup | Her angives, om komponenten håndterer lagring/backup. Der kan benyttes vær- dierne: SAN, NAS eller DAS. SAN, NAS og DAS refererer til hvilken type lagring/back-up, der benyttes. Hvis f.eks. løsningen benytter et sæt lokale diske, er der tale om DAS. Der kan vælges en eller flere af de listede værdier i hjælpeteksten. Hvis kompo- nenten ikke er relateret til lagring eller backup, angives teksten »ej relevant« i feltet |
Platform for ad- gang | Her angives, om komponenten håndterer brugernes adgang til it-løsningen. Der kan benyttes værdierne: Stationær pc, bærbar pc, PDA/mobil, stemmestyret eller ydre enheder. Ydre enheder kan være f.eks. printere, scannere, fax. F.eks. kunne infrastrukturkomponenten være »Brugerterminaler«, og den værdi som skulle benyttes i dette felt kunne være »Stationære pc«. Hvis det er nødvendigt at benytte en alternativ platform, skal denne angives som beskrevet i vejledningens introduktion, dvs. på formen »Andet: <XXXX>«, hvor <XXXX> repræsenterer en platform. |
Hvis komponenten ikke er relateret til en platform, der giver adgang til systemet, angives teksten »ej relevant« i feltet | |
Netværksydelse | Her angives, om komponenten relaterer sig til netværksydelser. Der kan benyttes værdierne: Data LAN/WAN, video, telefoni, internetadgang eller ASP. Hvis det er nødvendigt at benytte en alternativ netværksydelse, skal denne angives som beskrevet i vejledningens introduktion, dvs. på formen »Andet: <XXXX>«, hvor <XXXX> repræsenterer en netværksydelse. Hvis komponenten ikke benytter en netværksydelse, angives teksten »ej relevant« i feltet |
1.2.3 It-mæssig løsningsbeskrivelse (anvend 10-35 linjer; valgfrit at bruge illustration)
Her beskrives den it-mæssige del af løsningen. Beskrivelsen bør indeholde en overordnet beskrivelse af den tekniske arkitektur. Denne bør beskrives eller vises i en relevant kontekst (f.eks. integration med eksisterende systemer). Tekniske detaljer skal her udelades, og simple diagrammer må gerne benyttes hvis disse formidler overordnet og relevant information til godkenderne af business casen. Tekniske detaljer bør findes i andre specifikations- eller designdokumenter, som projektledelsen typisk kan fremskaffe
Beskrivelsen bør også fremhæve, hvilke nye nøglekomponenter der indgår i løsningen. Beskrivelsen bør redegøre for omfanget af genbrug og understøttelse af standarder og andre tekniske strategier
1.3 Interessenter
# | Her anføres et nummer, der vil kunne bruges som reference til interessenten. Der skal benyttes en fortløbende nummerering (dvs. start med 1, 2, 3, etc.) |
Identificerede interes- senter | Her angives navnet på den identificerede interessent |
Påvirket af løsning | Her angives i hvor høj grad, interessenten påvirkes af den forslåede løsning. Der skal sættes ét kryds i en af kolonnerne under »Lav«, »Middel« eller »Høj« |
Indflydelse på løsning | Her angives i hvor høj grad, interessenten har indflydelse på den foreslåede løsning. Der skal sættes ét kryds i en af kolonnerne under »Lav«, »Middel« eller »Høj« |
Involvering i dialog omkring løsningen | Her sættes ét kryds under »Ja« eller »Nej« afhængig af, om interessenten har været involveret i en dialog omkring løsningen forud for dens godkendelse |
Beskrivelse af involve- ring | Her detaljeres involveringen, såfremt en sådan har fundet sted |
1.4 Alternative løsninger
Det er valgfrit at udfylde tabellerne i dette afsnit, hvis projektets samlede investering er under DKK 1 million.
1.4.1 Nulløsningen (anvend 5-15 linjer i hver række)
Nulløsningen | Her beskrives kort hvad nulløsningen (det scenario som forventeligt vil fore- komme, hvis man ikke foretager sig noget) består af, dvs. en opsummering af den nuværende situation. I dette felt skal der ikke beskrives fordele eller ulemper |
Fordele i forhold til foreslået løsning | Her beskrives de væsentligste (op til tre) fordele ved nulløsningen |
Ulemper i forhold til foreslået løsning | Her beskrives de væsentligste (op til tre) ulemper ved nulløsningen |
1.4.2 Mulige fremtidige alternative løsninger (anvend 5-15 linjer i hver række; benyt én tabel per alternativ)
Alternativ #1 | Her beskrives kort, hvad alternativet består af. I dette felt skal der ikke be- skrives fordele eller ulemper. For hvert alternativ skal der benyttes en tabel, og alternativerne nummereres som indikeret (»Alternativ #1«, »Alternativ #2«, etc.). Beskriv kun alternativer, som reelt vil kunne komme i betragtning. Hvis der ikke findes nogen, udfyldes dette felt med teksten »Ingen reelle alternativer« |
Fordele i forhold til foreslået løsning | Her beskrives de væsentligste (op til tre) fordele ved dette alternativ |
Ulemper i forhold til foreslået løsning | Her beskrives de væsentligste (op til tre) ulemper ved dette alternativ |
1.5 Delprojekter
Det er valgfrit at udfylde tabellerne i dette afsnit, hvis projektets samlede investering er under DKK 5 millioner.
1.5.1 Beskrivelse af identificerede delprojekter (benyt én række for hvert delprojekt)
Navn eller reference for delprojekt | Her angives et navn eller en gængs reference for et delprojekt. Delprojekter vil typisk forekomme, når der er tale om et større projekt eller en løsning, som implementeres i faser. Det skal bemærkes, at økonomiske aspekter af eventuelle delprojekter skal indgå i aggregeret form i business casen |
Beskrivelse af afgræn- sende karakteristika for delprojekt | Her beskrives hvilke karakteristika, der er med til at afgrænse delprojektet. Det kan f.eks. være tale om specifikke leverancer eller gruppe af personer. Hvis projektet allerede opererer med eksplicitte navne for delprojekter, skal disse benyttes her |
Ansvarlig for delpro- jekt | Her angives den person, som er ansvarlig for delprojektet. Det kan typisk være en underprojektleder eller en holdleder |
1.5.2 Delprojekter for hvilke der findes en business case (benyt én række for hvert delprojekt)
Navn eller reference for delprojekt | Her angives et navn eller en gængs reference for et delprojekt. Det skal være et af de delprojekt navne, der forekommer i tabellen fra forrige afsnit, og for hvilke det gælder, at der er udarbejdet en separat business case |
Business case for del- projekt | Her angives navnet på business casen for delprojektet, samt om business casen kun foreligger som et udkast, eller om den er godkendt |
Projektejer af business case | Her angives hvem, der er projektejer for delprojektets business case |
1.6 Afhængigheder til sideordnede projekter
Der skal benyttes én række for hvert sideordnet projekt.
Navn eller reference for sideordnet projekt | Her angives et navn eller en gængs reference for et sideordnet projekt, som løsningen i væsentlig grad er afhængig af. Sådanne projekter kan f.eks. fore- komme, når en del af løsningen afhænger af en fællesservice eller -ydelse, der implementeres centralt |
Beskrivelse af afhæn- gighed til sideordnet projekt | Her beskrives, hvad afhængigheden består af. Der kan f.eks. være tale om en funktionel afhængighed (den foreslåede løsning har en grænseflade mod nogle specifikke funktioner i et andet system, der er ved at blive implemen- teret) og en tidsmæssig afhængighed (det sideordnede projekt skal være færdigt før den foreslåede løsning kan testes i sit fulde omfang) |
Instans der ejer projek- tet og dets løsning | Her angives den instans, som ejer det sideordnede projekt, hvortil der er en afhængighed |
Ansvarlig for sideord- net projekt | Her angives den person, der er projektejer for det sideordnede projekt |
2. Forretningsmæssige konsekvenser
Formålet med dette afsnit er at tydeliggøre projektets forretningsmæssige konsekvenser, dvs. hvilke in- vesteringer der skal foretages, hvilke risici projektet indeholder, og hvilke økonomiske og kvalitative gevinster projektet forventes at resultere i.
2.1 Økonomiske konsekvenser
2.1.1 Pengestrømsopgørelse - udgiftsbaseret (indsæt tabel fra »Business case regneark«)
Her udarbejdes en opgørelse over de forventede økonomiske omkostninger og gevinster fordelt over projektinitieringsåret og de følgende år. Tidshorisonten vælges i forhold til det enkelte projekt. Kun omkostninger og gevinster, der kan opgøres eller estimeres i kroneværdi, skal medtages i opgørelsen. Frigjort kapacitet skal kun medregnes hvis det påvirker bundlinjen eller bevirker en fremtidig budget- nedskrivning. Frigjort kapacitet, som ikke opfylder disse kriterier, medtages som kvalitative gevinster. Det skal bemærkes, at det er de forventede økonomiske omkostninger og gevinster der skal angives her, mens eventuelle risici for ændrede omkostninger og gevinster, beskrives i afsnit 2.4.3.
I business case regnearket forefindes en tabel-skabelon, som kan udfyldes og efterfølgende kopieres ind i dette felt. De enkelte poster kan ændres eller specificeres yderligere, hvis det ønskes.
Følgende bilag skal i nødvendigt omfang vedlægges business casen:
• Detaljeret beskrivelse af de enkelte poster (f.eks. hvad procesdesign, medarbejderuddannelse, etc. består af)
• Beskrivelse af den metodik, der er anvendt ved udregning af posterne (f.eks. hvorledes løn besparelser er udregnet)
• Redegørelse for hvilke forudsætninger, der er anvendt ved udregningerne (f.eks. hvorledes besparelser i årsværk omregnes til økonomiske gevinster, hvorledes forbedringer har bundlinjeeffekt, etc.)
• Opgørelse over fordelingen af de økonomiske gevinster på de relevante afdelinger/enheder, som ge- vinsterne udmøntes i
• Krydsreferencer mellem hovedarket og eventuelle støtteark i business case regnearket således, at der er fuld sporbarhed bag de estimerede gevinster og omkostninger (ikke vedlagt i eksempel)
2.1.2 Pengestrømsoversigt – udgiftsbaseret (indsæt diagram fra »Business case regneark«)
Her udarbejdes et diagram, der viser nettopengestrømmen, dvs. udgifterne og indtægterne i de enkelte år. Oversigten er m.a.o. en illustration af resultatet af de totale gevinster fratrukket de totale omkost- ninger, som er opgjort i tabellen i 2.1.1.
I business case regnearket forefindes en tabel-skabelon, som automatisk genererer oversigten ud fra de indtastede data i ovenstående afsnit 2.1.1. Denne pengestrømsoversigt (diagram) kan efterfølgende kopieres ind i dette felt.
2.1.3 Bevillingskonsekvenser - omkostningsbaseret (indsæt tabel fra »Business case regneark«)
Her udarbejdes på samme måde som i afsnit 2.1.1. en opgørelse over økonomiske omkostninger og gevinster fordelt over projektinitieringsåret og de følgende år (samme tidshorisont og kriterier som i afsnit 2.1.1). I denne opgørelse skal investeringer, som kan afskrives, fordeles ud over afskrivnings- perioden (»den økonomiske levetid«). For statslige projekter, der bliver gennemført under en omkost- ningsbaseret bevillingstype, vil tabellen vise de bevillingsmæssige konsekvenser af investeringen. For statslige projekter skal renteomkostninger desuden udregnes og inkluderes i opgørelsen
Formålet med dette er at tydeliggøre, hvorledes bevillingen og/eller regnskaberne påvirkes af investe- ringen. Hvilken afskrivningsmetode, der skal anvendes, afhænger af investeringstypen. Som regel anvendes den lineære metode, hvilket betyder, at investeringen fordeles i lige store dele over afskriv- ningsperioden. En investering på DKK 1 million, som skal afskrives efter den lineære metode over en periode på 5 år, bevirker således en omkostning på DKK 200.000 i 5 år plus de renter, som skal betales på den langfristede gæld (angives i linjen markeret med renter til finansiering).
I business case regnearket forefindes en tabel-skabelon, som kan udfyldes og efterfølgende kopieres ind i dette felt. De enkelte poster kan ændres eller specificeres yderligere, hvis det ønskes. Det skal bemærkes, at det kun er nødvendigt detaljeret at angive omkostningerne, mens de resterende poster (øgede driftsomkostninger og økonomiske gevinster) genbruges fra pengestrømsopgørelsen i afsnit 2.1.1.
Der bør være krydsreferencer mellem hovedarket og eventuelle støtteark i business case regnearket således, at der er fuld sporbarhed bag de estimerede gevinster, omkostninger og renteberegninger (ikke vedlagt i eksempel)
Yderligere information om afskrivning
For statens institutioner
Yderligere information vedrørende afskrivninger for statslige institutioner kan findes i Finansministe- riets Økonomisk Administrative Vejledning (ØAV), som man finder på xxx.xxx.xx. Det særlige afsnit om afskrivninger af it-projekter findes på xxx.xxx.xx/xx0000.xxx og/eller på xxx.xxx.xx/xx0000.
I forbindelse med projekter, som er på 50 mio. kr. eller derover, skal der udarbejdes et »investerings- skema«, som skal forelægges Finansudvalget. Investeringsskemaet kan findes på: xxxx://xxx.xxx.xx/ xx0000.xxx. Opgørelsen af budgetkonsekvenser vil bidrage med de nødvendige data til det obligatoriske investeringsskema.
For regionale institutioner
Anvendelsen af omkostningsbaserede principper er p.t. alene gældende for social- og specialundervis- ningsområdet. Erfaringer herfra vil indarbejdes i sundhedsområdet fra budget 2009. Principperne er bl.a. beskrevet i Velfærdsministeriets vejledning om budget og regnskabssystem for regioner, afsnit 10.5, som man finder på: xxxx://xxx.xx.xx/xxXxxxxxx/Xxxxxxxxxxxx/xxx0Xxxxxxxxx/00%00xxxxxxxxxx%00xx0Xxx0X/xxxxxx/ 20061213153504/CurrentVersion/10.5.pdf
Generelt har Velfærdsministeriet et dedikeret site om Budget- og regnskabssystem for regioner på: xxxx://xxx.xx.xx/xx/xxxx.xxxx?xx0000, hvor der bl.a. er links til de løbende opdateringer. Her kan man finde den udsendte »Orientering om opfølgning på omkostningsreformen …« fra 28.02.2007, hvori spørgsmålet om afskrivninger specifikt behandles.
For kommunale institutioner
Yderligere information vedrørende afskrivninger for kommunale institutioner kan findes i Budget- og regnskabssystem for kommunerne på dette link: xxxx://xxx.xx.xx/xx/xxxx.xxxx?xx0000. IT-investe- ringer betragtes som inventar i det omfang, der er tale om flytbart udstyr, og der kalkuleres med en levetid på tre år. Er der tale om infrastruktur (kabler, ledninger o.l.) er investeringen at betragte som anlæg. Kommunen kan derfor anbefales på enkelte områder at anvende en længere afskrivningshorisont
- fx 10 år - eller længere, hvis der er tale om fiberkabler, i det omfang, det kan tolkes inden for de gældende anbefalinger og regler.
Hvis investeringen indeholder væsentlige softwarelementer anbefaler KL, at kommunen vurderer hold- barheden af den valgte software. Kontorpakker har fx en tendens til at leve og dø med en given maskine.
M.a.o. er den realistiske anvendelseshorisont 3-4 år. Hvis det er et komplekse fagsystemer med bety- delige transaktionsomkostninger, er den realistiske anvendelseshorisont måske 10 år.
2.1.4 Illustration af bevillingskonsekvenser - udgiftsbaseret (indsæt diagram fra »Business case reg- neark«)
Her udarbejdes et diagram, der viser bevillingskonsekvenserne, dvs. de resulterende omkostninger eller indtægter i de enkelte år korrigeret for afskrivninger og rentebetaling.
Oversigten – i form af et diagram - laves automatisk ud fra de indtastede data fra tabelskabelonen for budgetkonsekvenser i afsnit 2.1.3. Diagrammet kan efterfølgende kopieres ind i dette felt.
2.2 Økonomiske nøgletal
2.2.1 Økonomiske nøgletal (benyt tal fra »Business case regneark«)
Projektets nutidsværdi (NPV) i DKK | Her angives nutidsværdien (NPV) af projektet. Den generelle formel for beregning af nutidsværdien af en nettopengestrøm er: Denne formel betyder, at de fremtidige nettopengestrømme diskonteres, dvs. divideres med (1 + r)t hvor r er den valgte diskonteringsrente, og t er lig den potens, der skal løftes til. Potensen, der løftes til, svarer til, hvor langt ude i fremtiden pengestrømmen falder, og som sådan divideres en pengestrøm for år 3 med (1 + r)3, mens pengestrøm- men for år 4 divideres med (1 + r)4. |
Projektets in- terne rente (IRR) i pro- cent | Her angives projektets interne rente. Den interne rente er den rente som i ovenstående beregning af nutidsværdi giver en nutidsværdi på 0. Den interne rente er således et udtryk for den samlede årlige forrentning, der opnås, og er anvendelig til sammenlig- ning af projekter. Bemærk at den interne rente ikke kan stå alene i en rangering af projekter med forskellige forudsætninger, men i givet fald skal suppleres af nutidsværdi og tilbagebetalingstid. Xxxxxx xxxxxxxxx af den interne rente kræver sekventiel løsning af to ligninger, hvorfor det anbefales at anvende f.eks. den indbyggede funktion i Excel (IRR) til udregning af den interne rente. I business case regnearket forefindes en tabel-skabelon som automatisk udregner den interne rente baseret på de indtastede værdier i pengestrømsopgørelsen (afsnit 2.1.1) |
Projektets til- bagebeta- lingstid i hele år | Her angives projektets økonomiske tilbagebetalingstid i hele år. For korte projekter med en tilbagebetalingstid på under et år kan man vælge at angive tilbagebetalingstiden i måneder. I business case regnearket forefindes en tabel-skabelon, som automatisk udregner den økonomiske tilbagebetalingstid i hele år baseret på de indtastede værdier i penge- strømsopgørelsen (afsnit 2.1.1) |
2.2.2 Beregningsgrundlag (benyt tal fra »Business case regneark«)
Diskonteringsrente i udregning af nutids- værdi i procent | Her anføres den diskonteringsrente, som er anvendt til ud- regning af nutidsværdi, jævnfør afsnit 2.2.1. Bemærk, at de økonomiske konsekvenser bør opdateres, hvis renten æn- drer sig væsentligt |
Tidshorisont i udregning af nutidsværdi og intern rente, i hele år | Her anføres den tidshorisont, som er anvendt ved udregning af nutidsværdi og intern rente, jævnfør afsnit 2.2.1. Tids- horisonten skal stemme overens med den tidshorisont, der anvendes i pengestrømsopgørelserne og pengestrømsover- sigterne i afsnit 2.1 |
Finansieringsrente, i procent | Her anføres den rente, der er antaget for finansieringen af investeringen |
Aktivets levetid/afskrivningsperioden for det optagede lån, i hele år | Her anføres den periode der er anvendes for tilbagebetaling af det lånte finansieringsbeløb. Dette vil være aktivets le- vetid, som vil variere. |
2.3 Kvalitative gevinster
2.3.1 Eksterne serviceforbedringer (anvend 5-35 linjer)
Service | Her angives, hvilken ekstern service der påvirkes af løsningen. Eksempler på eks- terne services er angivet i den følgende tabel |
Type af forbed- ring | Her angives, hvad forbedringen af servicen består i. Eksempler på forbedringer af eksterne services er angivet i den følgende tabel |
Beskrivelse | Her anføres en mere detaljeret beskrivelse af, hvorledes løsningen resulterer i de beskrevne serviceforbedringer |
Eksempler på eksterne services og forbedringer af disse er angivet i tabellen herunder.
Service | Eksempler på forbedringer |
Overholdelse af standarder | Standarder, som der er krav om - eksempelvis fra EU |
Bedre serviceka- nalstruktur | Større tilgængelighed for borgere og virksomheder til den offentlige sektor – f.eks. via flere digitale kanaler, flere online services, lettere og mere effektiv adgang, etc. |
Større gennem- sigtighed | Større gennemsigtighed om det offentliges beslutningsprocesser, der øger borgeres og virksomheders tillid til afgørelser |
Større deltagelse | Øget adgang for borgere og virksomheder til deltagelse i beslutningsprocesser knyttet til både politiske og forvaltningsmæssig behandling af sager |
Reduktion i ad- ministrative byr- der | Borgere og virksomheders omkostninger (tid og penge) reduceres – f.eks. ved re- duktion af antal og omfang af manuelle processer, mindre behov for fysisk frem- møde, etc. |
Bedre serviceop- levelse for borge- re og virksomhe- der | Borgere og virksomheder oplever en bedre service i form af hurtigere sagsgang, færre fejl, større fleksibilitet, flere valgmuligheder, venligere betjening, etc. |
2.3.2 Interne serviceforbedringer (anvend 5-35 linjer)
Service | Her angives interne services (som ikke kan opgøres i kroneværdi eller påvirker bundlinjen eller bevirker en fremtidig budgetnedskrivning), der påvirkes af løs- ningen. Eksempler på interne services er angivet i den følgende tabel |
Type af forbed- ring | Her angives, hvad forbedringen af servicen består i. Eksempler på forbedringer af interne services er angivet i den følgende tabel |
Beskrivelse | Her anføres en mere detaljeret beskrivelse af, hvorledes løsningen resulterer i de beskrevne serviceforbedringer |
Eksempler på interne services og forbedringer af disse er angivet i følgende tabel.
Service | Eksempler på forbedringer |
Forbedrede for- retningsprocesser | Større fleksibilitet, kortere procestid, etc. Som beskrevet i afsnit 2.1.1 skal kun gevinster, som ikke påvirker bundlinjen eller bevirker en fremtidig budgetneds- krivning, placeres her |
Forbedret it-drift og support | Optimering af intern it-support og drift – f.eks. færre fejl, højere oppetid, hurtigere support, etc. |
2.3.3 Fleksibilitet (anvend 5-35 linjer)
Type af fleksibi- litet | Her angives kvalitative gevinster, som øger organisationens fleksibilitet. Eksempler på typer af fleksibilitet er angivet i den følgende tabel |
Type af forbed- ring | Her angives, hvad forbedringen af fleksibilitet består i. Eksempler på forbedringer af fleksibilitet er angivet i den følgende tabel |
Beskrivelse | Her anføres de mere detaljerede beskrivelser af, hvorledes løsningen resulterer i de beskrevne forbedringer af fleksibilitet |
Eksempler på typer af fleksibilitet og forbedringer af disse er angivet i følgende tabel.
Type af fleksibi- litet | Eksempler på forbedringer |
Forbedret fleksi- bilitet i forret- ningsarkitektur | Øget organisatorisk fleksibilitet overfor markedsændringer (f.eks. ændringer i bor- gernes servicepræferencer), bedre mulighed for styring, standardisering af arbejds- processer, optimering af kommunikation mellem afdelinger, etc. |
Forbedret fleksi- bilitet i it-arkitek- tur | Øget it-arkitektonisk fleksibilitet (komponentbaseret, brug af åbne standarder så- som Web Services og XML), bedre mulighed for styring, platformuafhængig teknologi, etc. |
2.4 Risici
2.4.1 Identificerede risici (benyt én række for hver identificeret risiko)
Risikoområde | Her angives, hvilke risikoområder der er kilde til de identificerede risici. Der skal tages stilling til følgende 4 risikoområder: Organisation (risikoen skyldes forhold i organisationen), teknisk løsning (risikoen kommer af den tekniske løsning), le- verandører (risikoen er relateret til leverandørerne), interessenter (risikoen er relateret til projektets interessenter) |
Beskrivelse af identificeret risi- ko | Her beskrives eventuelle identificerede risici. Beskrivelsen skal dækkende beskri- ve, hvad risiciene skyldes, og hvad konsekvenserne består i |
Sandsynlighed | Her angives sandsynligheden for, at de beskrevne risici realiseres. Der skal sættes ét kryds i en af kolonnerne under »Lav«, »Middel« eller »Høj« |
Konsekvens | Her angives konsekvensen, hvis de beskrevne risici realiseres. Der skal sættes ét kryds i en af kolonnerne under »Lav«, »Middel« eller »Høj« |
Håndtering af identificeret risi- ko | Her beskrives, hvorledes det påregnes at håndtere de identificerede risici, herunder hvorledes risiciene forsøges forebygget, samt hvorledes der skal reageres, hvis ri- siciene realiseres |
2.4.2 Samlet risikovurdering (sæt ét kryds)
Høj risiko | Her angives, hvis den samlede risikovurdering af projektet, baseret på de identifi- cerede risici, er høj. Der sættes kun ét kryds i ét af felterne. »Høj risiko« indikerer, at projektet som helhed har en høj risiko, og at risikoelementet derfor skal vægtes højt, når der tages beslutning om projektet skal gennemføres eller ej. Ydermere skal der i høj grad tages hensyn til de identificerede risici, hvis projektet gennemføres |
Middel risiko | Her angives, hvis den samlede risikovurdering af projektet, baseret på de identifi- cerede risici, er middel. Der sættes kun ét kryds i ét af felterne. »Middel risiko« indikerer, at projektet som helhed har en middel risiko, og at det i nødvendig grad skal medtages, når der tages beslutning om projektet skal gennemføres eller ej. Ydermere skal der i tages de nødvendige hensyn til de identificerede risici, hvis projektet gennemføres |
Lav risiko | Her angives, hvis den samlede risikovurdering af projektet, baseret på de identifi- cerede risici, er lav. Der sættes kun ét kryds i ét af felterne. »Lav risiko« indikerer, at projektet som helhed har en lav risiko, og at risikoelementet ikke skal prioriteres når der tages beslutning om projektet skal gennemføres eller ej |
2.4.3 Økonomisk risikovurdering
Risiko for at omkostninger bliver større end angivet i afsnit 2.1 og 2.2 | Her angives sandsynligheden for, at omkostningerne bliver stør- re end angivet i afsnit 2.1 og 2.2. Der skal sættes ét kryds i en af kolonnerne under »Lav«, »Middel« eller »Høj« |
Risiko for at økonomiske gevinster bliver mindre end angivet i afsnit 2.1 og 2.2 | Her angives sandsynligheden for, at de økonomiske gevinster bliver mindre end angivet i afsnit 2.1 og 2.2. Der skal sættes ét kryds i en af kolonnerne under »Lav«, »Middel« eller »Høj« |
Konsekvens (angiv ændring i forven- tede omkostninger og økonomiske gevinster, i DKK, hvis risiko realise- res) | I denne kolonne angives ændringen i forventede omkostninger og økonomiske gevinster, i kroner, hvis risikoen realiseres. Ek- sempelvis »Forøgede omkostninger på DKK 1 million, grundet nyt systemdesign« eller »Reducerede gevinster på DKK 100.000 årligt, grundet manglende frigørelse af årsværk«. Der bør anføres en kort forklaring med henvisning til de identifice- rede risici i afsnit 2.4.1 |
3. Implementering og opfølgning
Formålet med dette afsnit er at tydeliggøre, hvorledes projektet i praksis gennemføres i forhold til an- vendelse af ressourcer og tid, samt hvilke projekt og forretningsmæssige milepæle projektet indeholder.
3.1 Implementeringsstrategi
Her beskrives kort hvilken implementeringsmetode, der anvendes, herunder hvilke trin, der udføres af henholdsvis interne eller eksterne ressourcer, hvilke projektmetoder, der anvendes, og om løsningen udrulles trinvist eller samlet. Der bør anvendes 10-20 linjer
3.2 Milepælsplan
3.2.1 Projektleverancemilepæle (benyt én række for hver milepæl)
# | Her anføres et nummer, der skal bruges som reference til projektleverancemi- lepælen. Der skal benyttes en fortløbende nummerering (dvs. start med 1, 2, 3, etc.) |
Projektleverance- milepæl | Her angives navnet på projektleverancemilepælen. Projektleverancemilepæle er relateret til projektprocessen, f.eks. gennemført systemtest, idriftsættelse af sy- stem, etc. Navnet skal være kort og præcist og beskrive, hvad projektleverancemilepælen består i, f.eks. »succesfuldt eksternt review«, »idriftsættelse af system«, etc. |
Forventet dato | Her angives den forventede dato for projektleverancemilepælen, f.eks. septem- ber 2012 |
Nøgleleverancer | Her beskrives den nøgleleverance, som projektleverancemilepælen resulterer i, f.eks. evalueringsrapport, idriftsat system, etc. Der kan godt være flere nøgle- leverancer per projektleverancemilepæl, hvilket angives ved at splitte feltet i flere rækker |
Budget forbrugt | For hver milepæl skal det angives, hvor stor en del af budgettet, der er forbrugt |
3.2.2 Forretningsmilepæle (benyt én række for hver milepæl)
# | Her anføres et nummer, der skal bruges som reference til forretningsmilepælen. Der skal benyttes en fortløbende nummerering (dvs. start med 1, 2, 3, etc.) |
Forretningsmilepæl | Her angives navnet på forretningsmilepælen. Forretningsmilepælene er de kon- krete forandringer, som danner forudsætning for de gevinster (forretningsmæs- sige værdiskabelser – både økonomiske og kvalitative), som projektet skal resultere i. Navnet skal være kort og præcist og beskrive, hvad forretningsmilepælen består i, f.eks. »fejlprocent under 1 %«, etc. |
Forventet dato | Her angives den forventede dato for forretningsmilepælen, f.eks. januar 2014 |
Gevinster ved mile- pæl | Her angives de gevinster (forretningsmæssige værdiskabelser), som forret- ningsmilepælen resulterer i, f.eks. frigørelse af 20 årsværk, besparelser på DKK 1 million per år på indkøb, etc. Der kan godt være flere gevinster per projekt- leverancemilepæl, hvilket angives ved at splitte feltet i flere rækker |
KPI der skal måles ved milepæl | For hver milepæl skal det angives, hvilke KPI’er (de nøgletal, der kvantificerer målopfyldelsen) der er relateret til milepælen, dvs. hvad der skal måles for at afgøre om forretningsmilepælen er nået (gevinsten er realiseret). Eksempler på KPI’er er: Lønomkostninger, omkostninger til materialer, omkostninger til eks- terne services, antal fejl per kunde, behandlingstid per sag, etc. |
3.3 KPI’er
KPI | Her angives KPI’en, der skal måles. Navnet (beskrivelsen) på KPI’en skal stem- me overens med navnene i tabellen i afsnittet før (3.2.2 Milepæle), i feltet »KPI«, der skal måles ved milepæl«. Der anvendes én tabel per KPI |
Hvorfor måles? | Her angives, hvorfor den pågældende KPI måles, f.eks. opfølgning på realisering af forventede besparelser på indkøb, etc. |
Hvordan måles? | Her angives, hvordan den pågældende KPI måles, f.eks. hvorfra data skal træk- kes, hvorledes data skal behandles, hvilket system der skal anvendes, etc. |
Hvem er ansvarlig for måling? | Her angives, hvilken funktion eller person der er ansvarlig for at udføre selve målingen, f.eks. personalechefen, indkøbschefen, etc. |
Forventet målings- dato | Her angives den forventede dato for måling af KPI’en, f.eks. januar 2014 |
Forventet værdiin- terval for måling | Her angives det værdiinterval, som målingen skal ligge inden for, for at gevin- sten betragtes som realiseret. Værdiintervallet skal være direkte relateret til den angivne KPI, og den forventede gevinst ved opfyldelse af KPI’en. Et eksempel på et værdiinterval kan være »mellem 20.000 og 22.000 rapporterede timer på aktivitet x svarende til en årlig reduktion på mellem 10 og 11 årsværk« |
Måling | Her angives måleresultatet, når målingen er gennemført |
Handlingsplan i fald målingen ligger udenfor forventet in- terval | Her angives, hvorledes der skal reageres og hvilke aktiviteter der skal udføres, hvis målingen ligger uden for det forventede interval |
Ansvarlig for hand- ling | Her angives navn og instans på den person, der er ansvarlig for at gennemføre handlingsplanen, i fald målingen ligger udenfor det forventede interval |
4 Ejerskab
Formålet med en redegørelse for ejerskab omkring løsningen er at skabe klarhed omkring ansvar for og beslutningskompetence omkring løsningen eller dele heraf.
4.1 Projektejer og projektleder
Business casens ejer og overordnet ansvarlig for dens udarbejdelse og op- | Her angives den person, som tænkes at være projektejer for den foreslåede løsning. Der angives også, hvilken instans denne person tilhører. |
datering | |
Denne person skal påtage sig at være overordnet ansvarlig for, at business casen udarbejdes og opdateres. Dette kan f.eks. xxx ved at inddrage pro- jektlederen og andre interessenter | |
Intern projektleder | Her angives navnet på en person, som tilhører samme instans som projek- tejeren og som kan agere som formel projektleder for denne instans. I det tilfælde, hvor projektet benytter en projektleder ekstern til projekte- jerens organisation (f.eks. en projektleder fra et konsulentfirma), vil den interne projektleder ikke stå for det daglige projektarbejde men mere skulle agere som en intern repræsentant for projektet |
4.2 Leverandører
Leverandør | Her angives navnet på en leverandør til projektet. En leverandør kan f.eks. være en intern projektgruppe, et eksternt konsulentfirma, eller en software- leverandør. Leverandøren bidrager med væsentlige dele nødvendige for løsningens re- alisering. Dette kan inkludere f.eks. dele af designet eller driften. Hvis en leverandørs navn ikke kendes, skal man benytte en sigende tekst. Dette kan f.eks. være, når man blot ved at en ekstern leverandør skal vælges, og dette kan angives som »Ekstern leverandør forventet« |
Faser i hvilke leverandør er involveret | Her angives, i hvilket faser leverandøren er involveret. Navnet på faserne kan komme fra den benyttede projektmetode eller gængse navne som ana- lyse, design, udvikling, test, iværksættelse og drift |
Hovedansvarsområder og/eller nøgleleverance- ansvar | Her angives, hvilket hovedansvar og/eller hvilke hovedleverancer leveran- døren har |
4.3 Opfølgning på forretningsmilepæle
Milepæl | Her angives navnet på en milepæl. Hvert navn fra tabellen i afsnit 3.2.2 bør optræde i denne tabel |
Ansvarlig for at milepæl nås | Her angives navnet på den person, der er ansvarlig for at følge op på for- retningsmilepælen og sikre at den nås |
4.4 Sponsorer
Der skal benyttes én række per sponsor og år.
Sponsor | Her angives navnet på en sponsor, der vil være forpligtet til at dække budgettet |
År | Her angives, hvilket kalenderår sponsorens budget gælder |
Finansieringsomkostninger i DKK | Her angives det beløb til dækning af projektets finansieringsomkost- ninger, som sponsoren skal dække |
Renteudgifter til finansiering | Her angives det beløb til dækning af projektets renteudgifter, som spon- soren skal dække |
Ressourcer i årsværk | Her angives, hvor mange årsværk sponsoren skal dække. Der angives i parentes, hvor mange DKK et årsværk antages at koste |
Driftsudgifter i DKK | Her angives et beløb til dækning af driftsudgifter, som sponsoren skal dække |
Andet | Her angives eventuelle andre udgifter/omkostninger, sponsoren skal dække, og der anføres kort, hvad beløbet tænkes brugt til |
4.5 Godkendelse
Der skal benyttes én række per godkender.
Rolle | Her angives den rolle, godkenderen spiller. Dette kan f.eks. være styre- gruppeformand, styregruppemedlem eller sponsor |
Navn og instans | Her angives godkenderens navn og organisatorisk tilhørsforhold (f.eks. in- stansnavn). Kun en person, der har den nødvendig autoritet omkring god- kendelse af business casen, kan nævnes. Alle personer, der er nødvendige for business casens godkendelse, skal li- stes i denne tabel |
Stilling | Her angives personens stilling |
Dato | Her angives dato for denne persons godkendelse af business casen. Hvis personen ikke har godkendt business casen, lades feltet stå tomt |
Godkendt ved underskrift | (På en trykt kopi af business casen) Her underskriver personen ved sin godkendelse af business casen |
Bilagsoversigt
Bilag
Bilagstitel | Her angives vedlagte bilagstitler. Dette kan f.eks. være et regneark (med detaljer omkring økonomiske beregninger) eller en projektplan. Bilagene skal være fortløbende nummererede |
Afsnit i denne business case som bilaget hører til | Her angives, hvilket afsnit i business casen bilaget hører til. Der må ikke vedlægges bilag, der ikke eksplicit understøtter eller bruges i et af business casens afsnit |
Bemærkninger | Her angives eventuelle bemærkninger omkring bilaget |
Ordforklaringer
ASP = Application Service Provider (udbyder af it-ydelser og services, via netværk)
BI = Business Intelligence (system til at opsamle, lagre og levere konsolideret forretningsviden, til brug for ledelsesbeslutninger)
DAS = Direct Attached Storage (Direkte forbundet lagringmedie, f.eks. en intern harddisk eller USB diskstation)
EPJ = Elektronisk patientjournal
ESB = Enterprise Service Bus (Software baseret kommunikationsinfrastruktur hvorigennem applikationer kan kalde eller udbyde services)
ESDH = Elektronisk sags- og dokumenthåndtering IRR = Projektets interne rente i procent
KPI = Key Performance Indicator (de nøgletal der kvantificerer målopfyldelsen) NAS = Network Attached Storage (Lagringsmedie, der kan nås via netværk) Nettopengestrømmen = De resulterende omkostninger eller indtægter i de enkelte år NPV = Nutidsværdien
PID = Projektinitieringsdokument
PRINCE2 = International projektstyringsmetode
Projektleverancemilepæl = Milepæl relateret til projektprocessen, f.eks. gennemført systemtest, idrift- sættelse af system, etc.
SAN = Storage Area Network (Distribueret lagringsmedie, der kan nåe via netværk) SLA = Service Level Agreement (Aftale om indhold og kvalitet af udbudt service)