BUSINESS CASE [SKRIV PROJEKTETS NAVN HER] Revisionshistorik. Revisionsdato Version Ændringer Forfatter

Transkript

1 AAU It Services Selma Lagerlöfs Vej Aalborg Ø Revisionshistorik Revisionsdato Version Ændringer Forfatter

2 1 Indhold 1 Indhold Introduktion Business case Projektmodel Vejledning Baggrund og behov Formål Behovsstiller Identificerede problemstillinger Konsekvenser og omfang af problemstillinger Prioritering af problemstillinger Afgrænsning af problemstillinger Kort beskrivelse af behov Løsningshypotese Forretningsdesign It-design Løsningstype og systemforandring Formodet løsningsomfang Forretningsmæssigt omfang Forretningsmodel Forretningsprocesser Typer af brugere Teknisk omfang Data Applikationer og interfaces Gennemførelse Interessenter Risici Afhængigheder til andre foranalyse- og/eller projekter/opgaver Organisatorisk implementering Omfang og udrulning Brugertræning Kompetencebehov Ledelse Forretning ITS Side 1 af 15

3 6.6 Indsats (estimering med usikkerhed) Ledelse Forretning ITS Overordnet tidsplan for projektet Overordnet tidsplan for projektet Økonomi Gevinster Problembaserede gevinster Tillægsgevinster Potentielle negative gevinster Investeringsbehov Områder Økonomi Strategisk fit Forretningsmæssigt fit Teknologisk fit Side 2 af 15

4 2 Introduktion Business case Business casen udarbejdes i projektets første fase og opdateres igennem hele projektet indtil at det er afsluttet. Business casen lever igennem faserne; foranalyse, initiering og detailanalyse, anskaffelse, gennemførsel og overdragelse. Business casen fungerer som beslutningsgrundlag ved alle projektets milepæle og giver et opdateret og retvisende billede af projektet. Beslutningstagere forholder sig til business casens indhold og beslutter på baggrund af business casen og projektets tilstand om projektet skal fortsætte eller afsluttes. Projektmodel Faseinddeling i foranalyse, initiering og detailanalyse, anskaffelse, gennemførsel og overdragelse sikrer at der for alle projekter etableres et solidt beslutningsgrundlag inden organisationen forpligter sig til større udgifter, at relevante parter er engagerede, at udbud eller egenudvikling sker i henhold til aftalte specifikationer, at projektet gennemføres inden for de fastsatte rammer samt at den godkendte løsning levers som aftalt. Gevinstrealisering sikrer at udbyttereview håndteres efter projektets afslutning og at værdien af løsningen høstes fyldestgørende. Vejledning Business casen: - Er baseret på spørgsmål endnu ikke besvarede spørgsmål markeres med n/a. - Svar på spørgsmål kommer via interviews og workshops. - Business casen lever igennem hele projektets livscyklus. - Foranalysen producerer udkast til business case - Initiering og detailanalysen producerer den detaljerede business case - Business case, projektafslutningsrapport og gevinstrealiseringsplan danner den sidste ajourførte dokumentation ved afslutning af projektet Side 3 af 15

5 3 Baggrund og behov Formål Beskriv kort formålet med det udtrykte behov. Behovsstiller Beskriv behovsstiller(e). Identificerede problemstillinger Hvilke problemer opleves? Kan problemerne grupperes/kategoriseres? Konsekvenser og omfang af problemstillinger Hvad er konsekvenserne af problemerne overordnet? Hvor ofte/hyppigt forekommer problemerne? Hvem oplever problemerne? Er der andre som kunne tænkes at have samme problemer? Behovs- og fordelsanalyse Hvad er konsekvensen af problemerne? Tid - lang gennemløbstid i processen? Arbejdstid - tidskrævende arbejdsopgave/proces? Personaleomkostninger - ressourcekrævende arbejdsopgave/proces? Direkte omkostninger? Image? Medarbejdertilfredshed? Tilfredshed hos studerende? Side 4 af 15

6 Prioritering af problemstillinger Behovs- og fordelsanalyse Hvordan skal problemerne prioriteres indbyrdes? Afgrænsning af problemstillinger Behovs- og fordelsanalyse Problemafgrænsning Antages det at alle eller kun nogle af problemstillingerne medtages i projektet? Kort beskrivelse af behov Hvilke overordnede processer/arbejdsopgaver ønskes ændret? Hvad skal forretningen overordnet være i stand til når løsningen er implementeret? Procesmæssigt/arbejdsgang? Datafangst/dataregistrering? Beregninger? Output? Hvornår skal organisationen være i stand til at arbejde på en ny måde? Fast deadline for alt eller tanker om en faseinddeling? Er der andre som kunne tænkes at have samme behov? Behovs- og fordelsanalyse Hvilke overordnede IT-funktioner skal understøtte dette? Workflow it understøttet arbejdsgang? Oprette? Ændre? Slette? Vise/søge? Dataudtræk/rapporter? Dataudveksling? Side 5 af 15

7 4 Løsningshypotese Forretningsdesign Forretningsproces standard eller individuel? Forretningsproces deling af viden/data på tværs eller individuelt? Organisation central eller decentral afvikling? It-design Data/viden? System/applikation? Infrastruktur? Driftsmiljø? Side 6 af 15

8 Løsningstype og systemforandring Eksisterende eller nyt? Løsningstype? Brancheløsning? Etableret standardløsning? Egenudvikling? Løsningstype Eksisterende AAU løsning Anskaffelse National defineret løsning Løsningen findes inden for det eksisterende uden tilretninger Løsningen findes inden for det eksisterende med tilretninger Mindre anskaffelse (f.eks. tillægsmodul/ delsystem) Større anskaffelse Helt nyt system med egen systemarkitektur Brancheløsning Etableret standardløsning Egenudvikling Kan der foretages en fælles udvikling med andre universiteter? 5 Formodet løsningsomfang Forretningsmæssigt omfang Forretningsmodel Organisatoriske enheder? Fysiske enheder? Geografi? Kanaler? Produkter/Koncepter/Services? Side 7 af 15

9 5.1.2 Forretningsprocesser Overordnede processer/arbejdsopgaver? Behovs- og fordelsanalyse End-2-end processer? Typer af brugere Administration Studerende Undervisere Forskere Gæster Eksterne samarbejdspartnere Teknisk omfang Data Typer af metadata? Behovs- og fordelsanalyse SW interfaces? Applikationer og interfaces Hvilke? Behovs- og fordelsanalyse Hvilke del? Side 8 af 15

10 6 Gennemførelse Interessenter Beskriv de involverede interessenter til gennemførsel af projektet. Nuværende situation AS-IS Gennemførelse Fremtid TO-BE Hvem vil få glæde af initiativet Hvem vil få løst problemer Hvem ejer processen og holdes ansvarlig for udviklingen Hvem skal involveres i beslutninger Hvem skal godkende indstilling Hvem skal godkende initiering/styregruppe Hvem skal allokere ressourcer Økonomi Medarbejdere Andre initiativer Hvem har planlagt initiativer, der berører de samme organisatoriske områder, eller forretningsprocesser Hvem er sponsor og leder andre projekter, der også påvirker Hvem vil opleve ændring i dagligt arbejde Hvilke typer af brugere er involveret i processen Konsekvenser for drift og support Hvem vil få glæde af initiativet Hvem vil få påvirkning af egne KPIer Er der andre organisatoriske enheder, som også kan bruge løsningen Risici Beskriv identificerede risici i forhold til projektets gennemførsel. Risikokategorier Sandsynlighed Status på risiko Økonomisk Ringe Reduceret sandsynlighed Applikationer Mellem Stigende sandsynlighed Infrastruktur Høj Ikke længere relevant Data Accept af løsning Kontraktuelt Ressourcebehov Organisatorisk forankring Realisering af benefits # Risikobeskrivelse 1 Dato risk er identificeret Risk ejer Hvem identificerede Kategori Sandsynlighed Konsekvens hvis risk optræder Mulige modforanstaltninger Status på risiko Side 9 af 15

11 Afhængigheder til andre foranalyse- og/eller projekter/opgaver Beskriv afhængigheder til andre projekter/opgaver. Organisatorisk implementering Omfang og udrulning Med udgangspunkt i omfanget af forretningsmodellen, hvilken udrulning/udrulningsalternativ vil være den mest hensigtsmæssige? Brugertræning Hvad skal der trænes i (system og processer)? Hvor mange brugere anslås at skulle trænes? Kompetencebehov Ledelse Hvem skal involveres i at træffe beslutninger? Om projektets omfang og fremdrift? Om løsning? Hvem skal drive og lede projektet? Hvem skal have ansvaret for forandringsledelse og realisering? Forretning Hvilke eksperter skal bidrage til design af løsningen? Hvilke medarbejdere skal bidrage til forandringsledelsen (træning, kommunikation, information, )? ITS Hvilke systemforvaltere skal bidrage til design af løsningen? Hvilken arkitektur, infrastruktur og informationssikkerhed og hvilke support- og systemspecialister skal bidrage? Indsats (estimering med usikkerhed) Særlige forhold vedrørende gennemførelse af foranalysen? Hvordan gennemføres foranalyseprocessen mest hensigtsmæssigt i forhold til: Initiativets vigtighed? Procesejerskab og bred involvering? Gennemførsel af behovs- og fordelsanalyse? Gennemførsel af økonomisk analyse? Udarbejdelsen af business case og indstilling? Side 10 af 15

12 Gennemførsel af projektet fra initiering og detailanalyse til og med overdragelse? Idriftsættelse af løsningen? Ledelse Hvem ejer projektet? Hvem skal involveres i at træffe beslutninger? Styregruppeformand Seniorbruger Seniorleverandør Forretning Hvilke eksperter skal arbejde på projektet? ITS Hvilke specialister skal arbejde på projektet? Overordnet tidsplan for projektet Behovs og fordelsanalyse Økonomisk analyse Indstilling Overordnet tidsplan for projektet Initiering og detailanalyse Anskaffelse Gennemførelse Overdragelse Drift Gevinstrealisering 7 Økonomi Gevinster Problembaserede gevinster Foranalysen Effektivitetsforbedring? Initiering og detailanalyse SMART Specifikt Hvad vil jeg opnå med mit mål? Hvorfor vil jeg gerne nå mit mål? Hvem involverer det at nå mit mål? Side 11 af 15

13 Målbart Hvordan ved jeg når jeg har nået mit mål? Hvad er mit succeskriterium for målet? Hvad har ændret sig når jeg har nået målet? Attraktivt Hvad er min motivation for at nå målet? Hvordan beriger målet min nuværende situation? Hvilken værdi giver det mig, når jeg har nået målet? Hvad drømmer jeg om? Realistisk Tror jeg på at jeg kan nå mit mål? Vil jeg ofre, hvad der er nødvendigt for at nå mit mål? Hvilke udfordringer kommer jeg til at møde på vejen? Hvordan tackler jeg udfordringerne? Tidsbestemt Hvornår kan jeg nå mit mål? Hvad er mine deadlines på vejen mod målet? Hvor lang tid har jeg? Hvor lang tid ønsker jeg at bruge? Tillægsgevinster Foranalysen Som følge af forandringen? Potentielle negative gevinster Foranalysen Som følge af forandringen? Investeringsbehov Områder Forretningens andel? Digitaliseringspuljen? ITS andel Økonomi Omkostningstyper Unit I&D Anskaffelse Gennemførsel Overdragelse Total AAU (ITS) Timer DKK Ekstern Intern AAU (andre enheder) Timer DKK Ydelser (fx IFS) DKK Total DKK Konsulenter Timer (Budgetteret faktura) DKK Andet (fx licenser, HW) DKK Total DKK Total før uforudsete omkostninger Uforudsete omkostninger DKK Total DKK Side 12 af 15

14 8 Strategisk fit Forretningsmæssigt fit Hvad skal det bruges til? Skal fungere som en vurdering af relevans/vigtighed for det enkelte behov Ved flere behov kan dette også fungere som input til prioritering blandt de enkelte behov Business relationship manageren bør inddrage AAUs strategiske mål og programmets individuelle mål, samt relevante mål fra øvrige programmer. Indtil programmerne har defineret deres egne mål, tager business relationship manageren udgangspunkt i de temporære identificerede brændende platforme for det enkelte program. Teknologisk fit Hvad skal det bruges til? Skal fungere som dokumentation af hvorvidt den antagne løsning er i overensstemmelse med IT-principperne IT principper Er løsningshypotesen i overensstemmelse med IT-principperne? P1 P2 P3 P4 P7 Løsningshypotese J/N J/N Afvigelsesforklaring Princip 1: Den samme opgave skal løses ved samme proces med samme it-løsning. Princip 2: Data registreres ved kilden, dvs. der, hvor data naturligt fødes, opdateres ét sted og anvendes mange steder. Princip 3: Procesejeren har ansvaret for digitalisering af hele processen og ansvaret for, at digitaliseringen gennemføres med involvering af alle interessenter. Princip 4: Digitalisering sker om muligt ved anvendelse af nationalt definerede it-løsninger (fællesoffentlige løsninger), dernæst ved brancheløsninger (universitære fællesløsninger), dernæst etablerede standardløsninger, som kan købes færdige og slutteligt gennem egenudvikling på AAU. AAU udvikler samtidig helst it-services i fællesskab med andre universiteter. Side 13 af 15

15 Princip 5: Valg af it-løsninger sker med udgangspunkt i offentlige standarder og offentlige arkitekturprincipper. Princip 6: Ved anskaffelse og udvikling skal der altid ske vurdering af både open source og kommercielle teknologier. Princip 7: Principperne 1-6 kan fraviges: Hvis det skaber værdi for AAU at gøre det og det samtidig kan forklares, hvorfor der afviges Hvis der er taget højde for konsekvenserne ved afvigelsen. Hvad er et princip? Et princip er et rammesættende udsagn, der afgør, hvordan it skal anvendes ved AAU Side 14 af 15