Beslutningsoplæg vedrørende valg af Navision Stat-scenarium

Transkript

1 - Navision Stat-projektet Beslutningsoplæg vedrørende valg af Navision Stat-scenarium Side 1 af 19

2 Dokumentkontrol Revisionshistorik Ændringer: Ændringsdato Hvad er der blevet ændret Distribution Dette dokument er blevet distribueret til: Navn Dekankredsen Styregruppen Administrationscheferne Niels Højberg Kirsten Skjødt Anette Svejstrup Petersen Peter Lundegaard Christian Klibo Jesper Runge Henrik Gudiksen Flemming Larsen Rolle Leder af forandringsprojektet Økonomisporet/Sporleder Økonomisporet/Navision Stat-projektledelsen Økonomisporet/Navision Stat-projektleder/PwC Økonomisporet/PwC Økonomisporet/PwC Økonomisporet/PwC Ledelsessekretariatet Side 2 af 19

3 Indholdsfortegnelse Formål Baggrund Beslutningsprocessen Succeskriterier for spor og projekt Scenarier Fordele og ulemper Opsummering - alle scenarier Konklusion Bilag: 1. Tidsplaner 2. Teknisk opgradering af Navision Stat fra version 3.60 til version 5.0 Formål Navision Stat er valgt som det fælles økonomisystem på det fusionerede AU. Formålet med dette notat er at redegøre for fordele og ulemper ved forskellige opgraderings- og implementeringsscenarier og på det grundlag give en anbefaling. Baggrund Det er besluttet, at det fusionerede AU skal have et fælles økonomisystem baseret på Navision Stat. Som udgangspunkt var det planen at overgå til Navision Stat version 5.0, idet denne version ville blive frigivet af Økonomistyrelsen ultimo Q Frigivelsesdatoen blev imidlertid udskudt til oktober , og samtidig stod det klart, at der ikke med sikkerhed ville forefindes et fuldt funktionsdygtigt og gennemtestet workflowsystem til fakturahåndtering integreret med version 5.0 før tidligst efteråret - sandsynligvis først foråret Workflowsystemet er således omfattet af et større udbud om et komplet indkøbs- og faktureringssystem, som Økonomistyrelsen p.t. kører, og det betyder, at de nuværende udbydere af workflowsystemer med integration til den nuværende Navision Stat 3.60 ikke har nogen interesse i at udvikle integrationen til version 5.0, medmindre de bliver vinder af udbuddet. Vinderen bliver efter planen udpeget inden sommerferien, men da udbuddet omfatter langt mere end blot fakturahåndtering, har Økonomistyrelsen oplyst, at den realistiske tidsplan for udrulning og implementering af workflowsystemet som sagt er tidligst i løbet af efteråret. 1 Økonomistyrelsen ønskede at inkludere servicepack 1 med diverse fejlrettelser og yderligere forbedringer. Side 3 af 19

4 Af overstående giver følgende to forhold to væsentlige udfordringer i forhold til forandringsprojektet og dermed Navision Stat-projektet under Økonomisporet: 1. Den udskudte frigivelse af Navision Stat Den sene udvikling af workflowsystem til fakturahåndtering til Navision Stat 5.0. Ad. 1: Tiden til udvikling af integrationer til diverse fagsystemer, tilretninger, opsætning, test og uddannelse bliver presset i forhold til ønsket om at kunne overgå til en fælles platform senest ved sommerferien. Dermed øges risikoen for fejl og dermed manglende målopfyldelse for projektet. Ad. 2: To af AU s hovedområder, ASB og DMU, har allerede i dag et workflowsystem til fakturahåndtering og vil givet fald skulle undvære det i en periode og gå tilbage til manuelle konterings- og godkendelsesprocedurer. Ud over at ville blive opfattet negativt og uhensigtsmæssigt af brugerne i organisationerne, er dette i strid med et af de overordnede succeskriterier for forandringsprojektet, som siger, at ingen hovedområder alt andet lige må blive stillet dårligere som følge af fusionen. På baggrund af de ovennævnte forhold har projektledelsen henholdsvis sporledelsen for økonomisporet fundet det nødvendigt at genoverveje den oprindelige plan for opgradering/implementering af det fælles økonomisystem. Der er herefter opstillet et antal mulige scenarier, som er analyseret med hensyn til fordele og ulemper i forhold til en række kriterier med henblik på at danne grundlag for beslutningsoplægget. Beslutningsprocessen I arbejdet med dette notat er inddraget information fra forskellige interessenter. Her skitseres kort forløbet indtil nu samt det forventede videre forløb: På møde 8. maj 2008 med administrationscheferne blev problemstillingen præsenteret og diskuteret På styregruppemødet 19. maj 2008 blev problemstillingen diskuteret. Det blev besluttet at eskalere problemstillingen til dekankredsen, og Navision Stat-projektet fik efterfølgende til opdrag at udarbejde nærværende notat/ business case til beslutningsstøtte Diverse uformelle samtaler med hovedområderne Møde med ASB og DPU for klarlæggelse af særlige forhold som følge af, at de på nuværende tidspunkt anvender Oracle ØSS, mens alle øvrige anvender Navision Stat Inddragelse af KMD Civitas, herunder med input til implikationer for budget og tidsplaner Oplæg sendes som input til administrationschefmøde 11. juni 2008 Tilbagemeldinger fra administrationschefer gennemgås Endeligt oplæg behandles af dekankredsen 16. juni 2008 Endeligt oplæg behandles af styregruppen 17. juni Side 4 af 19

5 Succeskriterier for spor og projekt Som overordnet ledetråd for planlægning og styring i spor og projekter i det administrative forandringsprojekt er der en række formelle og uformelle succeskriterier, som således også indgår i vurderingen af fordele og ulemper for de opstillede scenarier. Nogle af de væsentligste er i uddrag: Der skal etableres en sammenhængende, gennemskuelig og effektiv økonomistyringsmodel for. Dette skal opnås gennem en udstrakt grad af standardisering, hvilket gælder i både systemunderstøttelsen og i udformningen af processer og instrukser. Opsætning af Navision Stat, eventuelle tilretninger og integration til øvrige fagsystemer skal understøtte den standardiserede økonomistyringsmodel. Det skal være muligt for økonomiforvaltningen på AU at konsolidere budgetter, regnskaber og rapportering fra hovedområderne på en mere effektiv måde end i dag. Nærhedsprincippet skal understøttes, herunder må forandringerne alt andet lige ikke føre til, at nogen bliver stillet ringere, end de var før fusionen. Scenarier Indledningsvis blev der kun opereret med to overordnede scenarier (1 og 2). Imidlertid er det fundet relevant at liste flere alternativer, hvorefter følgende fire scenarier er blevet behandlet: 1. Navision Stat 5.0-scenarium: Opgradering til/implementering af Navision Stat 5.0 på alle hovedområder inden sommerferien. Inklusive ARS til projektstyring på DJF og DMU, men eksklusive workflowsystem til fakturahåndtering i fase I. 2. Navision Stat 3.60-scenarium: Implementering af Navision Stat 3.60 på ASB og DPU inklusive workflowsystem til fakturahåndtering på de hovedområder, som ønsker det, samt overgang til fælles kontoplan på alle hovedområder i fase I afsluttet i foråret. Efterfølgende i en fase II-opgradering til Navision Stat 5.0 tidligst i Oracle ØSS med fælles kontoplanscenarium: I fase I forbliver ASB og DPU på deres nuværende udgaver af Oracle ØSS, men overgår til ny fælles kontoplan. Øvrige hovedområder forbliver på nuværende udgaver af Navision Stat og overgår ligeledes til ny fælles kontoplan. 8000C og DJF får implementeret workflow til fakturahåndtering. Først i en fase II tidligst i 2010 skifter alle hovedområder til ny fælles Navision Stat Oracle ØSS uden fælles kontoplanscenarium: I Fase I forbliver ASB og DPU på deres nuværende udgaver af Oracle ØSS og med nuværende egne kontoplaner. 8000C og DJF får implementeret workflow til fakturahåndtering. Først i Fase II, tidligst i 2010, skifter alle hovedområder til ny fælles Navision Stat 5.0 med fælles kontoplan. Side 5 af 19

6 Fordele og ulemper I dette afsnit listes de væsentligste fordele og ulemper for hvert scenarium samt betydningen heraf. Betydningen af fordele og ulemper vurderes herefter i forhold til følgende kriterier: Opfyldelse af succeskriterier generelt: o Fælles kontoplan o Standardiserede processer og instrukser, samt udstrakt standardisering af itsystemanvendelse o Effektiv konsolidering og rapportering Workflowsystem til fakturahåndtering Økonomi inklusive internt ressourceforbrug. Derudover indgår overvejelser omkring tidsplaner, projektrelaterede risici samt diverse facts relateret til de enkelte scenarier. Vurderingen illustreres ved hjælp af en farveindikation: God Middel Dårlig Side 6 af 19

7 Ad. 1. Navision Stat 5.0-scenarium Fordele Forventet forbedret performance i forhold til tidligere versioner, bl.a. på grund af ny SQL 2005-databaseplatform. Nye funktioner med som standard som følge af ny version. Den samlede projektperiode holdes inden for et begrænset tidsrum og dermed lettere at holde dampen oppe. Alt andet lige det økonomisk og ressourcemæssigt mest optimale scenarium, som følge af ét projekt (fordelen reduceres dog i og med, at der skal kalkuleres med et efterfølgende workflowprojekt). Alle hovedområder kan overgå til nye fælles processer, herunder fælles kontoplan, over en relativ kort periode. Dette letter arbejdet med konsolidering og rapportering både decentralt på hovedområderne og centralt i økonomiforvaltningen. Alt andet lige en mere effektiv og mere smidig revision som følge af ensartet systemunderstøttelse og standardiserede processer. Ulemper Integration til et workflowsystem for fakturahåndtering vil sandsynligvis først være klar primo C + DJF og DPU må fortsat undvære et workflowsystem i yderligere 1½-2 år endnu. ASB og DMU vil i en periode ikke have systemunderstøttelse af workflow. Frigivelse af 5.0 i oktober 2008 betyder reduceret tid til udvikling og test af integrationer til fagsystemerne samt design og test af nye forretningsprocesser i forhold til den oprindelige plan og ønsket om at være klar senest ved sommerferien. Tilretninger og integrationer vil blive bygget på en version, der kun vil være lidt eller ingen praktisk erfaring med i og med, at AU bliver blandt de første til at tage version 5.0 i brug. Dette giver en række indbyggede projektmæssige risici. Opsummering i forhold til opstillede kriterier Scenarium Fælles kontoplan Standardisering af processer og itsystemanvendelse Effektiv konsolidering og rapportering Workflow til fakturahåndtering Økonomi/ ressourceindsats 1. Navision Stat 5.0 N/A* *Øvrige scenarier sammenlignes med Navision Stat 5.0 scenariet. Side 7 af 19

8 Bemærkninger Den manglende opfyldelse af workflow til fakturahåndtering diskvalificerer reelt scenariet som et muligt alternativ. Dels fordi det vil være imod det overordnede succeskriterium om, at ingen må blive stillet dårligere end nu, og fordi flertallet af hovedområderne vil skulle vente yderligere med at få et workflow implementeret. Side 8 af 19

9 Ad. 2. Navision Stat 3.60-scenarium Fordele Implementering af ny kontoplanstruktur på kendt systemversion af NS samt kendte integrationer til fagsystemer giver stor sikkerhed. Alle hovedområder kan overgå til fælles kontoplan over en meget kort periode. Dette letter arbejdet med konsolidering og rapportering både lokalt og centralt. Det er også muligt at foretage automatisk konsolidering med version forudsat fælles kontoplan. Dog mulig udfordring med version 4.0 på DMU. Alt andet lige en mere effektiv og mere smidig revision som følge af ensartet systemunderstøttelse og standardiserede processer. ASB og DPU bliver hurtigere indlemmet i NS-familien og vil kunne få mere indflydelse på det fremtidige set-up. Den primære ressourceindsats kan koncentreres om de to Oracle ØSS-hovedområder, ASB og DPU, og den interne knowhow fra de øvrige udnyttes bedre. Muligt at bibeholde/få et midlertidigt workflowsystem til fakturahåndtering, som allerede findes til version Dermed vil ASB og DMU ikke skulle stilles ringere, end de er i dag. DMU kan bibeholde det, de har i dag til Navision Stat, og samtidig får de øvrige hovedområder mulighed for at få et workflowsystem uden at skulle vente yderligere. De projektmæssige risici er færre og mindre ved en version, som er kendt af store dele af organisationen, og hvor mange integrationer til fagsystemer allerede findes. Bedre mulighed for at allokere tid til organisering og processer omkring workflow på DJF og 8000C. Man kan afvente, at Økonomistyrelsen Ulemper Der skal gennemføres et teknisk opgraderingsprojekt fra version 3.60 til 5.0 inden for relativ kort tid, som koster tid og penge og tab af momentum i et langt projektforløb. Meromkostningen i forhold til scenarium 1 til ekstern konsulentbistand og software estimeres til ca.10%. Meromkostningen i forhold til scenarium 1 til intern ressourceallokering estimeres til 5%. De forbedringer, version 5.0 fødes med, får man først senere glæde af. Ekstra arbejde for at sikre, at designet af nye fremadrettede processer vil harmonere med fremtidig version henholdsvis risiko for, at nogle processer vil skulle tilpasses igen. ASB risikerer at skulle skifte workflowsystem to gange. Dvs. fra det nuværende med Oracle ØSS-integration til et midlertidigt integreret med version 3.60 og senere til en løsning til version 5.0. Side 9 af 19

10 Fordele og diverse udbydere har udviklet relevante moduler og integrationer til Navision Stat 5.0, herunder at der eventuelt kommer en særlig universitetsudgave. Ulemper Opsummering i forhold til opstillede kriterier Scenarium 2. Navision Stat 3.60 Fælles kontoplan Standardisering af processer og itsystemanvendelse Effektiv konsolidering og rapportering Workflow til fakturahåndtering Økonomi/ ressourceindsats Bemærkninger Det skal bemærkes, at scenariet ikke forhindrer, at der kan designes og implementeres fælles Standardiserede processer for hele AU. Når det markeres med gult, skyldes det, at der ved den senere overgang til Navision Stat 5.0 vil skulle foretages justering af nogle processer. Ligesom det er tilfældet med scenarium 1, så vil tidsplanen betyde, at den største arbejdsindsats sker i efteråret 2008 og foråret. En ændring sammenlignet med scenarium 1 er, at ASB og DPU vil kunne skifte fra Oracle ØSS til Navision Stat et par måneder tidligere. Tilsvarende vil det samlede AU kunne overgå til den ny fælles kontoplan hurtigere. Tidsplanerne har dog ingen væsentlig indflydelse i vurderingen af scenarierne. Den præcise tidsplan afhænger bl.a. af arbejdet med ny fælles kontoplan og BI-projektets fremdrift. Et overblik over de tentative tidsplaner for alle fire scenarier ses i bilag 1. Med hensyn til Økonomi/Ressourceindsats så vedrører merudgifterne i forhold til scenarie 1: Midlertidigt workflowsystem ca kr. Teknisk opgradering fra version 3.60 til version 5.0 ca kr., ekskl. internt ressourceforbrug. For yderligere forklaring vedrørende teknisk opgradering og internt ressourceforbrug se bilag 2. Side 10 af 19

11 Ad. 3. Oracle ØSS med fælles kontoplanscenarium Fordele Muligt at bibeholde/få et midlertidigt workflowsystem til fakturahåndtering, som allerede findes til version Dermed vil ASB og DMU ikke skulle stilles ringere, end de er i dag. Både ASB og DMU kan bibeholde det, de har i dag. Øvrige hovedområder får mulighed for at få et midlertidigt workflowsystem til version 3.60 uden at skulle vente yderligere. DPU vil midlertidigt kunne få det samme workflowsystem, som ASB har til Oracle ØSS. De projektmæssige risici er på kort sigt begrænsede, da projektet er indsnævret til overgang til ny fælles kontoplan og tilhørende økonomistyringsprocesser samt eventuelle workflow-projekter på DJF, DPU og 8000C. Bedre mulighed for at allokere tid til organisering og processer omkring workflow på DJF, 8000C og DPU. Implementering af ny kontoplanstruktur på kendt systemversion af NS på DJF, DMU og 8000C. Alle hovedområder kan overgå til fælles kontoplan over en meget kort periode. Dette letter arbejdet med konsolidering og rapportering både lokalt og centralt. Man kan afvente, at Økonomistyrelsen og diverse udbydere har udviklet relevante moduler og integrationer til Navision Stat 5.0, herunder at der eventuelt kommer en særlig universitetsudgave - uden at bruge for meget tid på andet indimellem. Ulemper Selv med fælles kontoplan vil de ønskede forbedringer med hensyn til konsolidering og periodisk rapportering ikke blive opfyldt på grund af meget manuelt arbejde. Alt andet lige en mindre effektiv og mindre smidig revision som følge af manglende standardisering i systemunderstøttelse og processer. Implementering af BI (Business Intelligence) til udtræk af rapporter vil 1) enten skulle udskydes, eller 2) have forringet værdi, da data fra Oracle ØSS ikke umiddelbart vil blive omfattet, eller 3) blive væsentligt fordyret, hvis datamodellen skal omfatte Oracle ØSS i en begrænset periode. Vanskeligere at designe nye fremadrettede processer, når man vil skulle tage hensyn til to forskellige Oracle ØSSinstallationer. Hvis DPU midlertidigt får det samme workflowsystem, som ASB har til Oracle ØSS, betyder det, at de skal skifte workflowsystem to gange. Merudgifter i forbindelse med eventuel opgradering(er) af Oracle ØSS. Økonomisk ikke noget at spare i det lange løb, da udgifterne blot udskydes, og da midlertidig indførelse af tillempede nye fælles processer og kontoplan i forhold til Oracle ØSS vil være en ekstraomkostning. ASB og DPU vil blive langsommere indlemmet i NS-familien og vil kun kunne bidrage/få indflydelse i begrænset omfang i arbejdet med nye fremadrettede processer. Kortsigtet løsning, da version 3.60 under alle omstændigheder skal skiftes ud, fordi supporten ophører inden for en over- Side 11 af 19

12 Fordele Ulemper skuelig fremtid. Der skal gennemføres et opgraderingsprojekt fra version 3.60 til 5.0 på DJF, DMU og 8000C inden for relativt kort tid, som koster tid og penge og tab af momentum i et langt projektforløb. De forbedringer, version 5.0 fødes med, får man først senere glæde af. Opsummering i forhold til opstillede kriterier Scenarium 3. Oracle ØSS med fælles kontoplan Fælles kontoplan Standardisering af processer og itsystemanvendelse Effektiv konsolidering og rapportering Workflow til fakturahåndtering Økonomi/ ressourceindsats Bemærkninger Den manglende opfyldelse af Standardiserede processer er imod et af forandringsprojektet overordnede formål omkring det at skabe et nyt fælles grundlag for styringen det fusionerede AU. Konsolidering af regnskaber, budgetter og rapportering vil fortsat være en Excel-baseret manuel proces, som dels er ressourcekrævende og dels ufleksibel. Dette giver en række indbyggede risici i forhold til datakvaliteten og dermed økonomistyringen. Økonomi/Ressourceindsatsen angår her projektrelaterede aktiviteter, men derudover vil der være forøget ressourceindsats forbundet med de ineffektive manuelle processer vedrørende konsolidering og rapportering, som man vil være bundet af. Side 12 af 19

13 Ad. 4. Oracle ØSS uden fælles kontoplanscenarium Organisationerne på ASB og DPU vil kun skulle involveres inden for et begrænset tidsrum, når version 5.0 er helt klar. Muligt for ASB og DMU at bibeholde workflowsystemer til fakturahåndtering og for de øvrige at få et midlertidigt, som allerede findes til version DPU vil midlertidigt kunne få det samme, som ASB har til Oracle ØSS. De projektmæssige risici er på kort sigt meget begrænsede, da projektet er indsnævret til eventuelle workflow-projekter på DJF, DPU og 8000C. Bedre mulighed for at allokere tid til organisering og processer omkring workflow på DJF, 8000C og DPU. Man kan afvente, at Økonomistyrelsen og diverse udbydere har udviklet relevante moduler og integrationer til Navision Stat 5.0, herunder at der eventuelt kommer en særlig universitetsudgave - uden at bruge tid på andet indimellem. Ingen eller væsentlig forsinket opfyldelse af forandringsprojektets formål omkring at skabe et samlet AU med standardiserede processer osv. I praksis vil det være umuligt at implementere den nye økonomistyringsmodel nu og dermed også BI. Ønskede forbedringer med hensyn til konsolidering og periodisk rapportering vil ikke blive opfyldt. Alt andet lige en mindre effektiv og mindre smidig revision som følge af manglende standardisering i kontoplanstruktur, systemunderstøttelse og processer. Implementering af BI (Business Intelligence) til udtræk af rapporter vil 1) enten skulle udskydes, eller 2) blive væsentligt fordyret, hvis datamodellen skal omfatte forskellige versioner af økonomisystemer og kontoplaner i en begrænset periode. Økonomisk ikke noget at spare i det lange løb, da udgifterne blot udskydes. En udskydelse vil opleves som en forlængelse af den samlede projektperiode med tab af momentum og motivation til følge, da man allerede er i gang med bl.a. økonomistyringsmodelprojektet. De forbedringer, version 5.0 fødes med, får man først senere glæde af. Hvis DPU midlertidigt får det samme workflowsystem, som ASB har til Oracle ØSS, betyder det, at de skal skifte workflowsystem to gange. Merudgifter i forbindelse med evt. opgradering(er) af Oracle ØSS. Kortsigtet løsning, da version 3.60 under alle omstændigheder skal skiftes ud, fordi supporten ophører inden for en overskuelig fremtid. Side 13 af 19

14 Opsummering i forhold til opstillede kriterier Scenarium 4. Oracle ØSS uden fælles kontoplan Fælles kontoplan Standardisering af processer og itsystemanvendelse Effektiv konsolidering og rapportering Workflow til fakturahåndtering Økonomi/ ressourceindsats Bemærkninger Scenariet er ikke et reelt alternativ. Side 14 af 19

15 Opsummering samlet for alle scenarier Scenarium Fælles kontoplan Standardisering af processer og itsystemanvendelse Effektiv konsolidering og rapportering Workflow til fakturahåndtering Økonomi/ ressourceindsats 1. Navision Stat 5.0 N/A* 2. Navision Stat Oracle ØSS med fælles kontoplan 4. Oracle ØSS uden fælles kontoplan *Øvrige scenarier sammenlignes med Navision Stat 5.0-scenariet. Konklusion På baggrund af de beskrevne fordele og ulemper kan det konkluderes, at scenarium 2, Navision Stat 3.60, har flest fordele i forhold til de i beslutningsoplægget opstillede kriterier samt overordnede succeskriterier for det administrative forandringsprojekt. Scenarium 2. Navision Stat 3.60 indbefatter implementering af Navision Stat 3.60 på ASB og DPU inklusive workflowsystem til fakturahåndtering på de hovedområder, som ønsker det, samt overgang til fælles kontoplan på alle hovedområder i fase I afsluttet i foråret. Efterfølgende i en fase II-opgradering til Navision Stat 5.0 tidligst i Side 15 af 19

16 BILAG 1 Tidsplaner - Roadmaps for de fire scenarier Tidsplan Scenarium 1 (Navision Stat 5.0) Fase I Fase II Foranalyse Analyse Løsningsdesign Udvikling Opgradering fra NS 3.60 til NS 5.0 (Idriftsættelse, test, uddannelse ) Skift fra Oracle ØS til NS 5.0 (Idriftsættelse, test, uddannelse ) Implementering af workflow + evt. nye specialmoduler til NS 5.0 Opgradering fra NS 3.60 til NS 5.0 inkl. ARS (Idriftsættelse, test, uddannelse) Alle: Overgang til fælles kontoplan Aug 2008 Jan Feb Marts April Maj Juni Marts<->juli 2010 Juni-Okt 2010 *Aksen er ikke tidstro Tidsplan Scenarium 2 (Navision Stat 3.60 scenarium) Fase I Fase II Foranalyse Analyse Løsningsdesign Udvikling ASB og DPU: Skift fra Oracle ØSS til NS 3.60 (Idriftsættelse, test, uddannelse ) Alle: Overgang til fælles kontoplan Alle: Opgradering fra NS 3.60 til 5.0 Opgradering ekskl. ARS Opgradering inkl. ARS Workflow til NS C, DJF, DPU: Valgfri implementering af workflow Aug 2008 Feb Marts April Maj Marts<->juli 2010 Juni-Okt 2010 *Aksen er ikke tidstro Side 16 af 19

17 Tidsplan Scenarium 3 (Oracle ØSS med fælles kontoplan) Fase I Fase II Foranalyse Analyse Løsningsdesign Udvikling Opgradering fra NS 3.60 til NS 5.0 (Idriftsættelse, test, uddannelse ) Skift fra Oracle ØS til NS 5.0 (Idriftsættelse, test, uddannelse ) Opgradering fra NS 3.60 til NS 5.0 inkl. ARS (Idriftsættelse, test, uddannelse) Implementering af workflow Overgang til fælles kontoplan Aug 2008 Marts Marts<->juli 2010 Juni<->Okt 2010 *Aksen er ikke tidstro Tidsplan Scenarium 4 (Oracle ØSS uden fælles kontoplan) Fase I Fase II Foranalyse Analyse Løsningsdesign Udvikling Opgradering fra NS 3.60 til NS 5.0 (Idriftsættelse, test, uddannelse ) Skift fra Oracle ØS til NS 5.0 (Idriftsættelse, test, uddannelse ) Opgradering fra NS 3.60 til NS 5.0 inkl. ARS (Idriftsættelse, test, uddannelse) Implementering af workflow Overgang til fælles kontoplan 2008 Marts<->juli 2010 Juni<->Okt 2010 *Aksen er ikke tidstro Side 17 af 19

18 Bilag 2 Teknisk opgradering af Navision Stat fra version 3.60 til version 5.0 Den såkaldte tekniske opgradering fra 3.60 til 5.0 i fase II i scenarium 2 (Navision Stat 3.60) indebærer i hovedtræk: Primært teknik samt intern involvering i begrænset omfang: Mapning af tilretninger i version 3.60 i forhold til version 5.0 (i nogle tilfælde forventes eksisterende tilretninger at kunne erstattes af standardfunktionalitet i version 5.0) Analyse af eksisterende integrationer til diverse fagsystemer og eventuel tilpasning til version 5.0 (i de fleste tilfælde forventes der teknisk set ikke nogen forskel) Dataflytning fra eksisterende database til SQL 2005 (datakonvertering ikke nødvendig, forudsat at der ér indført fælleskontoplan forinden). Primær involvering af interne nøglepersoner: Test af processer, der indebærer brug af økonomisystemet, samt test af integrationer (fuld test af funktionaliteten i økonomisystemet ikke påkrævet) Ajourføring af procesbeskrivelser og i mindre omfang redesign Udrulning i forbindelse med overgang til drift i ny version. Involvering af interne brugere: Opgraderingskursus. Involvering af interne ressourcer i fase II er således betydeligt mindre end i fase I. Forskellen er indikeret i nedenstående skema: Nødvendig involvering af interne ressourcer: Projektledelse, koordinering og sparring Fase I Fase II 90% 10% Vil primært involvere et lille antal nøglepersoner, som skal påregne en ikke uvæsentlig ressourceindsats. Test 90% 10% Vil primært involvere et lille antal nøglepersoner, som skal påregne en ikke uvæsentlig ressourceindsats. Design og beskrivelse af nye fælles processer 90% Hovedparten af processerne er upåvirket og skal være på plads i fase I. 10% En mindre del af processerne skal ajourføres i forhold til den nye version. Side 18 af 19

19 Nødvendig involvering af interne ressourcer: Analyse, krav og test vedrørende integration til fagsystemer Datakonvertering og dataflytning Fase I Fase II 90-95% 5-10% Involverer primært it-tekniske kompetencer. 80% Væsentlig opgave med datamapning ved overgang til ny kontoplanstruktur. Uddannelse 75% Tidligere Oracle ØSS-brugere skal have intensiv undervisning. Workflowsystem til fakturahåndtering* (Analyse, krav, test og uddannelse) 20% Primært dataflytning. 25% En allerede uddannet bruger af NS 3.60 vil kun have brug for et mindre opgraderingskursus. 75% 25% Afhænger af, hvilken midlertidig løsning man vælger, samt hvor mange hovedområder der bliver omfattet. * Afhænger af hvilken midlertidig løsning man vælger, samt hvor mange hovedområder der bliver omfattet. Hovedparten af det interne arbejde i workflowprojektet ligger i organisering og design af processerne omkring godkendelses-flowet. Alt andet lige skal dette arbejde ikke gøres to gange, selvom man skulle skifte system i fase II. Hvis den midlertidige løsning, der vælges, bygger på samme tekniske platform, som vinderne af Økonomistyrelsens udbud gør, kan man forvente, at involveringen i fase II kommer til at ligge i den lave ende. Side 19 af 19