Statement of Work (SOW) ERP-fase

Relaterede dokumenter
Functional Requirements Document FRD Intern Revision

Functional Requirements Document FRD Std. Ledelsesinformation

konvertering 28. januar Nuuk

Statement of Work (SOW) Business Case Implementation BCI-fase

Integrationsstrategi

Statement of Work (SOW) Overall

Dynamics AX 2012 (og AX 7) v. Benny Jepsen, Chief Solution Architect, EG A/S

Microsoft Dynamics AX Scanfak. Fall

DYNAMICS AX 2012 RAPIDVALUE FÅ OVERBLIK OG SE NYE MULIGHEDER. John T. Hummelgaard & John Petersen Maj 2013

Functional Requirements Document FRD Debitor

Functional Requirements Document FRD Finans

Microsoft Dynamics. Fall. 16 AX Scanfak

Businesscase for AX-instanser. Det fællesoffentlige ERP-sekretariat

Fælles stamdata. Den 27. januar Nuuk

SPORBESKRIVELSE FOR ØKONOMISTYRINGSSPORET

EG Bolig Ledelsesinformation BI på EG Bolig

Telefon Allerød

Hvor tjenes pengene? Farum Park, den 4. november 2014

Functional Requirements Document FRD Skattestyrelsen

Datatransport Import & Eksport af data Generelt Import/eksport Felter i Import og Eksport... 5

Igangsættelse af Anskaffelsesfase

Løsning Klient opsæt til applikationerne 1121 til 1129, er nu oprettet og medsendes herved.

Danpot C5 Kursusprogram Indhold

Installationsguide. Integration af erhvervsdata fra NN Markedsdata til Microsoft Dynamics NAV 2015

Fra Navision Stat 3.60 til 5.1

Udveksling af data med Navision Stat ved hjælp af GIS. Lars Matthiesen, UNI C

Marts 2019 AFTALE. Bilag 2. Ydelsesbeskrivelse for IKT-bygherrerådgiveren. om teknisk rådgivning og bistand (IKT-bygherrerådgivning)

SPØRGSMÅL OG SVAR TIL UDBUD MED FORHANDLING AF LEVERING, IMPLEMENTERING, VEDLIGEHOLDELSE OG SUPPORT AF ERP-SYSTEM TIL VISITDENMARK TILBUDSFASEN

Det var et simpelt bogføringsprogram dengang, uden ret mange andre muligheder end bogføring og en resultatopgørelse.

Tænk ud af boksen med Microsoft Dynamics NAV og kig på Microsoft Dynamics NAV 2016

Dynamisk hverdag Dynamiske processer

Skolepenge og Indbetalinger

2014 IT REVISOR KURSER

Markedsinfo. Microsoft Dynamics NAV 2009 SP1 Klassisk. Side 1. Copyright: Naddon version

JTA-DynamicsPDF. til. Microsoft Dynamics C5 vers. 3 SP3 eller højere. JTA-Data Jylland Vinkelvej 108a 8800 Viborg Tlf

CELENIA ENHANCED BUDGET CONTROL

Vejen til nemmere og mere sikker implementering af Microsoft Dynamics AX

VEJLEDNING Skolepenge og Indbetalinger med Totaltløsning Support tlf:

Velkommen. Microsoft Dynamics C5 version 2012

LaserNet Output Management. Lennart Garbarsch Tabellae A/S

Bilag 8 omfatter ikke alle Kundens krav. Nogle af Kundens krav er medtaget i andre Bilag for at have en naturlig sammenhæng til konteksten.

Fold mulighederne ud med Microsoft Dynamics AX

BENCHMARK ANALYSE. The Continia Way to Pay!

Implementering af Prophix budgetsystem

FACTSHEET CONTINIA PAYMENT MANAGEMENT

Opgrader til nyeste Dynamics AX version og profiter af løbende opdateringer

Forbedringer i NS

BENCHMARK ANALYSE. The Continia Way to Pay!

Hvorfor starte fra bunden?

OUTPUT MANAGEMENT PRÆSENTATION LASERNET TIL FORSYNINGSVIRKSOMHEDER

Kursuskalender 2013 Dynamics AX, C5 og NAV 1. jan juni 2013

Kontoplan Plus. Felter i Plus+ kontoplanen Eksternkonto Effekt Primo MomsABC Årskode Prv KontoNavn2...

Velkommen til. Brugerdag 2014

Målbillede for kontraktstyring. Juni 2018

Økonomi Programopdatering version DSM 2009 Efterår 2011

ACUBIZ WORKSHOP Services og Finans Fast Track // Maj 2018

DYNAMICS AX 2012 FÅ OVERBLIK OG SE NYE MULIGHEDER

Installationsguide. Integration af erhvervsdata fra NN Markedsdata til Microsoft Dynamics NAV 2013

Ebba Ehlers/Hanne Mortensen

Effektiv opkrævning. Til Microsoft Dynamics NAV.

Velkommen til - Alle gode gange tre

KONCERNREGNSKAB. MÅLGRUPPE Revisorer med ingen eller begrænset viden om koncernregnskab og koncernlignende forhold.

Bank Management / Bankafstemning. Bankafstemning. Et kort overblik over funktioner: Bankafstemning. Opret afstemningskonti

DHUV (Digitalisering af Handicap og Udsatte-Voksne)

Du har også mulighed for at udlæse faktisk bogførte tal fra et regnskabsår til et budgetark.

Til hvert selskabs CVR-nr. oprettes et PBS-nr. hos Nets. Som tilknyttes dataleverandøraftalen.

Quick guide Finans bogføring

Én IT løsning, mange fordele AX TRAVEL. - fremtidens rejsebureauløsning

Brugerguide Integration af erhvervsdata fra NN Markedsata til Microsoft Dynamics NAV 2016

Overvejelser ved valg af IT system

BILAG 5.A BESKRIVELSE AF METODE FOR AFKLARINGSFASEN

Kontraktbilag 04 - Transitionsprojekt

Bank. Microsoft Dynamics NAV 2009 Klassisk. Side 1. C op yr ig ht: Naddon version

Finansiel rapportering og konsolidering med Dynamics AX 2012 R3

TEAMSHARE ESDH VIDENDELING PROJEKTRUM EN STANDARDLØSNING FRA LECTOR BASERET PÅ MICROSOFTTEKNOLOGIER

MICROSOFT C5 LIGHT MICROSOFT C5. FÅ ET lettilgængeligt ØKONOMISYSTEM, DER KAN VOKSE MED DIN VIRKSOMHED

BILAG 1 TIDS- OG AKTIVITETSPLAN

Velkommen. Microsoft Dynamics C5 version det har aldrig været lettere

Microsoft Dynamics AX 360º Health Check

Dynamics AX hos Columbus

Dokumenterne er nu oploaded i en word udgave. Der gennemføres én analyse og designfase for det samlede økonomisystemet,

Indlæsning af tilskud fra UVM

Brugervejledning NN Markedsdata for ectrl

Transkript:

Statement of Work (SOW) ERP-fase Version 1.0 Status: Endelig Side: 1 af 76

Indholdsfortegnelse Indholdsfortegnelse... 2 Tabeloversigt... 7 1 Projektets formål og scope... 9 1.1 Formål... 9 1.2 Scope... 10 1.3 Områder ikke i scope... 11 1.4 Vurdering af involveringsgrad/dækning... 13 2 Projekttilgang, tidsplan og serviceleverancer... 13 2.1 Designfase... 13 2.1.1 Finans... 13 2.1.1.1 Formål... 13 2.1.1.2 Nøgleleverancer... 14 2.1.1.3 Hovedoutput... 15 2.1.1.4 Forudsætninger... 15 2.1.2 Debitor... 16 2.1.2.1 Formål... 16 2.1.2.2 Nøgleleverancer... 16 2.1.2.3 Hovedoutput... 17 2.1.2.4 Forudsætninger... 18 2.1.3 Kreditor... 18 2.1.3.1 Formål... 18 2.1.3.2 Nøgleleverancer... 18 2.1.3.3 Hovedoutput... 19 2.1.3.4 Forudsætninger... 19 2.1.4 ttestyrelsen... 20 2.1.4.1 Formål... 20 2.1.4.2 Nøgleleverancer... 20 2.1.4.3 Hovedoutput... 25 2.1.4.4 Forudsætninger... 25 2.1.5 Budgettering og budgetopfølgning... 26 2.1.5.1 Formål... 26 2.1.5.2 Nøgleleverancer... 26 2.1.5.3 Hovedoutput... 27 2.1.5.4 Forudsætninger... 27 2.1.6 Finanslov/bevillinger... 27 2.1.6.1 Formål... 27 2.1.6.2 Nøgleleverancer... 28 2.1.6.3 Hovedoutput... 29 2.1.6.4 Forudsætninger... 29 2.1.7 Ressortændringer... 30 2.1.7.1 Formål... 30 2.1.7.2 Nøgleleverancer... 30 2.1.7.3 Hovedoutput... 31 Status: Endelig Side: 2 af 76

2.1.7.4 Forudsætninger... 31 2.1.8 Std. Ledelsesinformation... 31 2.1.8.1 Formål... 31 2.1.8.2 Nøgleleverancer... 32 2.1.8.3 Hovedoutput... 32 2.1.8.4 Forudsætninger... 32 2.1.9 Intern revision... 33 2.1.9.1 Formål... 33 2.1.9.2 Nøgleleverancer... 33 2.1.9.3 Hovedoutput... 34 2.1.9.4 Forudsætninger... 34 2.1.10 Projekt/anlæg... 34 2.1.10.1 Formål... 34 2.1.10.2 Nøgleleverancer... 34 2.1.10.3 Hovedoutput... 35 2.1.10.4 Forudsætninger... 35 2.1.11 erelt... 35 2.1.11.1 Formål... 35 2.1.11.2 Nøgleleverancer... 36 2.1.11.3 Hovedoutput... 38 2.1.11.4 Forudsætninger... 39 2.1.12 Teknik/infrastruktur... 39 2.1.12.1 Formål... 39 2.1.12.2 Nøgleleverancer... 39 2.1.12.3 Hovedoutput... 40 2.1.12.4 Forudsætninger... 40 2.1.13 Data migration... 40 2.1.13.1 Formål... 40 2.1.13.2 Nøgleleverancer... 41 2.1.13.3 Hovedoutput... 42 2.1.13.4 Forudsætninger... 42 2.1.14 Integrationsstrategi... 42 2.1.14.1 Formål... 42 2.1.14.2 Nøgleleverancer... 43 2.1.14.3 Hovedoutput... 45 2.1.14.4 Forudsætninger... 46 2.1.15 Stamdata... 46 2.1.15.1 Formål... 46 2.1.15.2 Nøgleleverancer... 46 2.1.15.3 Hovedoutput... 47 2.1.15.4 Forudsætninger... 47 2.2 Development-fasen... 47 2.2.1 Finans... 47 2.2.1.1 Formål... 47 2.2.1.2 Nøgleleverancer... 48 Status: Endelig Side: 3 af 76

2.2.1.3 Hovedoutput... 48 2.2.1.4 Forudsætninger... 48 2.2.2 Debitor... 48 2.2.2.1 Formål... 48 2.2.2.2 Nøgleleverancer... 49 2.2.2.3 Hovedoutput... 49 2.2.2.4 Forudsætninger... 49 2.2.3 Kreditor... 49 2.2.3.1 Formål... 49 2.2.3.2 Nøgleleverancer... 50 2.2.3.3 Hovedoutput... 50 2.2.3.4 Forudsætninger... 50 2.2.4 ttestyrelsen... 51 2.2.4.1 Formål... 51 2.2.4.2 Nøgleleverancer... 51 2.2.4.3 Hovedoutput... 52 2.2.4.4 Forudsætninger... 52 2.2.5 Budgettering og budgetopfølgning... 53 2.2.5.1 Formål... 53 2.2.5.2 Nøgleleverancer... 53 2.2.5.3 Hovedoutput... 54 2.2.5.4 Forudsætninger... 54 2.2.6 Finanslov/bevillinger... 54 2.2.6.1 Formål... 54 2.2.6.2 Nøgleleverancer... 54 2.2.6.3 Hovedoutput... 55 2.2.6.4 Forudsætninger... 55 2.2.7 Ressortændringer... 55 2.2.7.1 Formål... 55 2.2.7.2 Nøgleleverancer... 56 2.2.7.3 Hovedoutput... 56 2.2.7.4 Forudsætninger... 56 2.2.8 Std. Ledelsesinformation... 56 2.2.8.1 Formål... 56 2.2.8.2 Nøgleleverancer... 56 2.2.8.3 Hovedoutput... 57 2.2.8.4 Forudsætninger... 57 2.2.9 Intern revision... 57 2.2.9.1 Formål... 57 2.2.9.2 Nøgleleverancer... 57 2.2.9.3 Hovedoutput... 58 2.2.9.4 Forudsætninger... 58 2.2.10 Projekt/anlæg... 58 2.2.11 erelt... 58 2.2.11.1 Formål... 58 Status: Endelig Side: 4 af 76

2.2.11.2 Nøgleleverancer... 58 2.2.11.3 Hovedoutput... 59 2.2.11.4 Forudsætninger... 59 2.2.12 Teknik/infrastruktur... 59 2.2.12.1 Formål... 59 2.2.12.2 Nøgleleverancer... 59 2.2.12.3 Hovedoutput... 60 2.2.12.4 Forudsætninger... 60 2.2.13 Data migration... 60 2.2.13.1 Formål... 60 2.2.13.2 Nøgleleverancer... 60 2.2.13.3 Hovedoutput... 61 2.2.13.4 Forudsætninger... 61 2.2.14 Integrationsstrategi... 61 2.2.14.1 Formål... 61 2.2.14.2 Nøgleleverancer... 61 2.2.14.3 Hovedoutput... 63 2.2.14.4 Forudsætninger... 63 2.2.15 Stamdata... 63 2.2.15.1 Formål... 63 2.2.15.2 Nøgleleverancer... 63 2.2.15.3 Hovedoutput... 64 2.2.15.4 Forudsætninger... 64 2.3 Deployment-fasen... 64 2.3.1 Finans... 65 2.3.1.1 Formål... 65 2.3.1.2 Nøgleleverancer... 65 2.3.1.3 Hovedoutput... 65 2.3.1.4 Forudsætninger... 65 2.3.2 Debitor... 66 2.3.2.1 Formål... 66 2.3.2.2 Nøgleleverancer... 66 2.3.2.3 Hovedoutput... 66 2.3.2.4 Forudsætninger... 66 2.3.3 Kreditor... 66 2.3.3.1 Formål... 66 2.3.3.2 Nøgleleverancer... 67 2.3.3.3 Hovedoutput... 67 2.3.3.4 Forudsætninger... 67 2.3.4 ttestyrelsen... 67 2.3.4.1 Formål... 67 2.3.4.2 Nøgleleverancer... 67 2.3.4.3 Hovedoutput... 68 2.3.4.4 Forudsætninger... 68 2.3.5 Budgettering og budgetopfølgning... 68 Status: Endelig Side: 5 af 76

2.3.5.1 Formål... 68 2.3.5.2 Nøgleleverancer... 68 2.3.5.3 Hovedoutput... 69 2.3.5.4 Forudsætninger... 69 2.3.6 Finanslov/bevillinger... 69 2.3.6.1 Formål... 69 2.3.6.2 Nøgleleverancer... 69 2.3.6.3 Hovedoutput... 70 2.3.6.4 Forudsætninger... 70 2.3.7 Ressortændringer... 70 2.3.7.1 Formål... 70 2.3.7.2 Nøgleleverancer... 70 2.3.7.3 Hovedoutput... 71 2.3.7.4 Forudsætninger... 71 2.3.8 Std. Ledelsesinformation... 71 2.3.8.1 Formål... 71 2.3.8.2 Nøgleleverancer... 71 2.3.8.3 Hovedoutput... 72 2.3.8.4 Forudsætninger... 72 2.3.9 Intern revision... 72 2.3.9.1 Formål... 72 2.3.9.2 Nøgleleverancer... 72 2.3.9.3 Hovedoutput... 72 2.3.9.4 Forudsætninger... 73 2.3.10 Projekt/anlæg... 73 2.3.11 erelt... 73 2.3.11.1 Formål... 73 2.3.11.2 Nøgleleverancer... 73 2.3.11.3 Hovedoutput... 74 2.3.11.4 Forudsætninger... 75 2.3.12 Teknik/infrastruktur... 75 2.3.13 Data migration... 75 2.3.13.1 Formål... 75 2.3.13.2 Nøgleleverancer... 75 2.3.13.3 Hovedoutput... 75 2.3.13.4 Forudsætninger... 75 2.3.14 Integrationsstrategi... 75 2.3.15 Stamdata... 76 2.3.15.1 Formål... 76 2.3.15.2 Nøgleleverancer... 76 2.3.15.3 Hovedoutput... 76 2.3.15.4 Forudsætninger... 76 Status: Endelig Side: 6 af 76

Tabeloversigt Tabel 1: Nøgleleverancer på Finans-området... 14 Tabel 2: Nøgleleverancer på Debitor-området... 16 Tabel 3: Nøgleleverancer på Kreditor-området... 18 Tabel 4: Nøgleleverancer på området ttestyrelsen... 21 Tabel 5: Nøgleleverancer på området Budgettering og budgetopfølgning... 26 Tabel 6: Nøgleleverancer på området Finanslov/bevillinger... 28 Tabel 7: Nøgleleverancer på området Ressortændringer... 30 Tabel 8: Nøgleleverancer på området Std. Ledelsesinformation... 32 Tabel 9: Nøgleleverancer på området Intern revision... 33 Tabel 10: Nøgleleverancer på området Projekt/anlæg... 34 Tabel 11: Nøgleleverancer på området erelt... 36 Tabel 12: Nøgleleverancer på området Teknik/infrastruktur... 39 Tabel 13: Nøgleleverancer på området Data migration... 41 Tabel 14: Nøgleleverancer på området Integrationsstrategi... 43 Tabel 15: Nøgleleverancer på Stamdata-området... 46 Tabel 16: Nøgleleverancer på Finans-området... 48 Tabel 17: Nøgleleverancer på Debitor-området... 49 Tabel 18: Nøgleleverancer på Kreditor-området... 50 Tabel 19: Nøgleleverancer på området ttestyrelsen... 51 Tabel 20: Nøgleleverancer på området Budgettering og budgetopfølgning... 53 Tabel 21: Nøgleleverancer på området Finanslov/bevillinger... 54 Tabel 22: Nøgleleverancer på området Ressortændringer... 56 Tabel 23: Nøgleleverancer på området Std. Ledelsesinformation... 57 Tabel 24: Nøgleleverancer på området Intern revision... 58 Tabel 25: Nøgleleverancer på området erelt... 58 Tabel 26: Nøgleleverancer på området Teknik/infrastruktur... 59 Tabel 27: Nøgleleverancer på området Data migration... 60 Tabel 28: Nøgleleverancer på området Integrationsstrategi... 62 Tabel 29: Nøgleleverancer på Stamdata-området... 64 Tabel 30: Nøgleleverancer på Finans-området... 65 Tabel 31: Nøgleleverancer på Debitor-området... 66 Tabel 32: Nøgleleverancer på Kreditor-området... 67 Tabel 33: Nøgleleverancer på området ttestyrelsen... 68 Tabel 34: Nøgleleverancer på området Budgettering og budgetopfølgning... 69 Tabel 35: Nøgleleverancer på området Finanslov/bevillinger... 70 Tabel 36: Nøgleleverancer på området Ressortændringer... 71 Tabel 37: Nøgleleverancer på området Std. Ledelsesinformation... 71 Tabel 38: Nøgleleverancer på området Intern revision... 72 Tabel 39: Nøgleleverancer på området erelt... 73 Tabel 40: Nøgleleverancer på området Data migration... 75 Tabel 41: Nøgleleverancer på Stamdata-området... 76 Status: Endelig Side: 7 af 76

Versionshistorik Dato Version Udarbejdet af Godkendt af Beskrivelse 20.05.2015 1.0 Emir Sibic Dokument startet 29.05.2015 1.0 Emir Sibic Dokument færdigskrevet 02.06.2015 1.0 Bente Søgaard Korrekturlæsning 04.06.2015 1.0 Palle Liebe Endelig version 08.06.2015 1.0 Andreas Hove- Jørgensen Opdatering af nøgleleverancetabeller Status: Endelig Side: 8 af 76

1 Projektets formål og scope Denne Statement of Work (SOW) skal ses sammen med bilag 3, hvori følgende er beskrevet: Indledning Projektets formål og scope overordnet Områder, der ikke er i scope overordnet Projektmetode tilgang overordnet Projektorganisation overordnet Kundens generelle ansvarsområder og projektets forudsætninger Tidsplan Betalingsplan Governance Kommunikationsplan Risikostyring Change Management Exhibits. Nærværende SOW dækker udelukkende leverancerne i ERP-fasen. Begrebet ERP-fasen er dækkende for faserne: Design (design), Development (konfiguration, opsætning og kundespecifikke kodetilpasninger) og Deployment (implementering, ibrugtagning og uddannelse). 1.1 Formål Projektets formål er at udskifte de nuværende løsninger hos hhv. kommunerne (KOM) og Grønlands Selvstyre (GS) og dermed få en fællesoffentlig ERP-platform i Grønland i form af en Microsoft Dynamics AX 2012 R3. Den overordnede baggrund for projektet er nærmere beskrevet i bilag 3. I ERP-fasen er det målet, at løsningen i videst muligt omfang anvendes uden kundespecifikke tilpasninger. Det betyder tilpasning af kundens processer med den "best practice", AX 2012 understøtter. Denne strategi Status: Endelig Side: 9 af 76

med færre kundespecifikke tilpasninger skal sikre, at fremtidige vedligeholdelses- og opdateringsomkostninger begrænses. Kunden (KOM og GS) er indstillet på gå langt for at kunne være i en standard AX 2012-løsning. Den gennemførte afklaringsfase har vist, at kunden til en vis grad kan holde sig inden for standard AX 2012, men der er også identificeret en række gaps. Det er kun de tilpasninger, som blev identificeret i afklaringsfasen, der er indeholdt i implementeringsprojektets overslag for udvikling af tilretninger. Kunden er indforstået med at skulle ændre forretningsgange og arbejdsrutiner i forbindelse med ibrugtagningen af løsningen for at tilgodese ønsket om standard og dermed undgå tilretninger herunder også førnævnte gaps, hvis EG kan anvise alternativer. 1.2 Scope Projektet er faseopdelt, og nærværende SOW dækker kun fase 1. Følgende spor er omfattet af implementeringsprojektet: Forretningsspor: Finans Debitor Kreditor ttestyrelsen Budgettering og budgetopfølgning Finanslov/bevillinger Ressortændringer Std. ledelsesinformation Intern revision Projekt/anlæg (kun DD, LW og udarbejdelse af FRD 1 ) erelt (sporet indeholder alle grundopsætninger på AX 2012 på tværs af ovennævnte forretningsspor samt add-ons medtaget i it-arkitekturen). Tekniske spor: Teknik/infrastruktur Data-migration Integrationsstrategi Stamdata. Følgende AX 2012-moduler er omfattet af implementeringsprojektet: Finans (herunder Public sector-funktionalitet) Debitor Kreditor 1 Hvad angår projekt-/anlægsområdet, er det udelukkende gennemførelsen af Deep Dive-workshop, løsningsworkshop og udarbejdelse af FRD, der er med i scope. Design, Development og Deployment på området er ikke med i scope. Status: Endelig Side: 10 af 76

Bank Budget HR Interne kontroller Tværgående Virksomhedsadministration Systemadministration Rollecentre Sikkerhedsopsætning Dataadgangsbegrænsning AIF. Følgende AX 2012 add-ons fra EG og tredjepart er omfattet af implementeringsprojektet: EG Healthcheck EG License Check EG Business Care EGVI AMC Direct Debit GDM (global data management). Følgende systemer med integration til AX 2012 er omfattet af implementeringsprojektet: EG CrossWork SharePoint Lasernet TM1. Følgende infrastruktur er omfattet af implementeringsprojektet: Rådgivning i forbindelse med konfiguration af miljøer og tekniske installationer Bistand efter behov, der er medtaget en pulje time for at dække denne rådgivning baseret på erfaringer fra andre projekter, såfremt dette ikke er dækkende håndteres det via change processen. 1.3 Områder ikke i scope Dette afsnit omhandler specifikke leverancer inden for de spor, der er omtalt i afsnit 1.2 der ikke er med i scope og dermed ikke er med i estimaterne. Evt. områder, som ikke er nævnt i dette afsnit og ikke fremgår andetsteds i dette dokument, betragtes ligeledes som værende out of scope. Status: Endelig Side: 11 af 76

Følgende specifikke funktioner/områder er ikke i scope: Portalen Sulinal Debitor Debitor-webgodkendelse Prisydelser (scripts) E-boks-udskrifter Finans PM-workflow Bruttolønslister Finanslov/bevillinger Cockpit til styring af finanslovsproces erelt Grønlandsk sproglag Kreditor BS plus ttestyrelsen Webservices indførsel Webportal for afgifter Webservices/EP (Inkasso) Portal (Status m.m.) Std. ledelsesinformation BI-løsning Intern revision Logning vedrørende læsning/åbning af transaktioner Redskaber til styring af revisionsindsatsen Integrationer Andre Winformatik-integrationer end dem, som specifikt er beskrevet i Integrationsstrategien IRIS (Udvalgte stamdata eksporteres fra XAL til IRIS, "Kvitteringer" eksporteres fra XAL til IRIS IRIS, Import af kreditorfakturagodkendelser fra IRIS til XAL, IRIS læser udvalgte stamdata direkte fra XALs Oracle-database) NETS (Fil fra NETS med samtlige bankreg. og bankkonti interval (moduluskontrol) indlæses i XAL, Fil fra NETS med betalingsoplysninger indlæses i XAL, Danner opkrævningsfil til NETS, Danner PBS-fil til NETS) SKAT (jf. eksisterende integrationer 5.1-5.28) Status: Endelig Side: 12 af 76

F2 (Nyt ESDH-system, tidligere Capture) Kiffaq mailsystem. 1.4 Vurdering af involveringsgrad/dækning Se bilag 3. 2 Projekttilgang, tidsplan og serviceleverancer 2.1 Designfase I designfasen gennemføres en grundlæggende konfiguration af systemet på de forskellige funktionsområder i AX 2012. Der gennemføres designworkshops med deltagere fra EG og kunden med henblik på en detaljeret gennemgang af de enkelte moduler og de nødvendige opsætninger, der skal foretages. Design af løsninger til de identificerede gaps udarbejdes i forbindelse med løsningsworkshops. På baggrund af dette udarbejdes der et overordnet funktionelt konfigurationsdokument (FCD) for hvert modul (eksempelvis Finans, Debitor osv.). Denne indeholder en beskrivelse af den grundlæggende opsætning i det relevante modul. I forbindelse med løsningsworkshops udarbejdes der også et funktionelt designdokument (FDD) for hvert identificerede gap, indeholdende løsningsbeskrivelsen for det pågældende gap. Større løsningskomponenter, der vurderes til at have en høj grad af kompleksitet, skal beskrives yderligere i et teknisk designdokument (TDD). I forbindelse med designworkshops tages der stilling til, om TDD skal udarbejdes for de enkelte gaps. Hvis der skal udarbejdes et TDD, sker det i starten af Developmentfasen. Processen er illustreret nedenfor: FCD start Konfiguration Forberedelse Design WS FCD færdig FDD færdig Behov for TDD? 2.1.1 Finans 2.1.1.1 Formål Målet under designfasen på Finans-området er at lave den grundlæggende opsætning og konfiguration af Finans i AX 2012 og beskrive det i et Finans FCD. De identificerede gaps fra FRD Finans behandles på designworkshoppen med henblik på at designe løsningen for de enkelte gaps og beskrive disse i FDD'er. Der udarbejdes ét FDD for hvert identificerede gap. Hvis Finans-området indeholder gaps, der kræver større løsningskomponenter, tages der stilling til, om der i development-fasen skal udarbejdes TDD'er for disse. Status: Endelig Side: 13 af 76

2.1.1.2 Nøgleleverancer Nøgleleverancer fra EG på Finans-området er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. For yderligere detaljer på området henvises der til FRD Finans og de deri beskrevne fit/gaps. Tabel 1: Nøgleleverancer på Finans-området Finansmodulet Kontoplan Finansielle dimensioner Bogføring Afstemning Bankafstemning Fin Fin Fin Fin Fin Fin Deltager i designworkshop med rette ressource. Godkende funktionelle konfigurationsdokumenter (FCD). Fælles ERPsekretariat skal forestå konfiguration og efterfølgende foretage dette i test/produktion samt flere regnskaber. Fælles ERP-sekretariat skal, inden designworkshop igangsættes, fremsende kontoplan (der forudsættes en fælles kontoplan). Deltager i designworkshop med rette ressource. Godkende funktionelle konfigurationsdokumenter (FCD). Fælles Fælles ERP-sekretariat skal, inden designworkshop igangsættes, fremsende relevante dimensioner, således at designworkshop kan træffe de endelige valg (der forudsættes en fælles kontoplan). Deltager i designworkshop med rette ressource. Godkende funktionelle konfigurationsdokumenter (FCD). Fælles ERP-sekretariat skal forestå konfiguration og efterfølgende foretage dette i test/produktion samt flere regnskaber. Deltager i designworkshop med rette ressource. Godkende funktionelle konfigurationsdokumenter (FCD). Fælles ERPsekretariat skal forestå konfiguration og efterfølgende foretage dette i test/produktion samt flere regnskaber. Deltager i designworkshop med rette ressource. Godkende funktionelle konfigurationsdokumenter (FCD). Fælles ERPsekretariat skal forestå konfiguration og efterfølgende foretage dette i test/produktion samt flere regnskaber. Deltager i designworkshop med rette ressource. Godkende funktionelle konfigurationsdokumenter (FCD). Fælles ERPsekretariat skal forestå konfiguration og efterfølgende foretage dette i test/produktion samt flere regnskaber. Status: Endelig Side: 14 af 76

CPR-nummerhåndtering Finansudligningsfunktion Finansafstemningsrapport (CW) Bankafstemningsrapport (CW) Posteringstekst m.m. QA/koordinering Fin Fin Fin Fin Fin Fin Deltager i designworkshop med rette ressource. Godkende ERPsekretariat skal forestå konfiguration og efterfølgende foretage dette i test/produktion samt flere regnskaber. Deltager i designworkshop med rette ressource. Godkende ERPsekretariat skal forestå konfiguration og efterfølgende foretage dette i test/produktion samt flere regnskaber. Deltager i designworkshop med rette ressource. Godkende ERPsekretariat skal forestå konfiguration og efterfølgende foretage dette i test/produktion samt flere regnskaber. Deltager i designworkshop med rette ressource. Godkende ERPsekretariat skal forestå konfiguration og efterfølgende foretage dette i test/produktion samt flere regnskaber. Deltager i designworkshop med rette ressource. Godkende ERPsekretariat skal forestå konfiguration og efterfølgende foretage dette i test/produktion samt flere regnskaber. Sikring af tværfaglig koordinering samt sporrelevant QAarbejde. 2.1.1.3 Hovedoutput Hovedoutput på Finans-området består af følgende: Udarbejdelse af FCD Finans Udarbejdelse af X antal FDD'er (afhængigt af antal gaps på området) Beslutning af, om der skal udarbejdes TDD'er på området og hvor mange. 2.1.1.4 Forudsætninger Følgende forudsætninger er gældende på Finans-området: Det forudsættes, at den udarbejdede FCD kan godkendes, herunder den fordeling af processer, der blev aftalt i afklaringsfasen (H = 10 %, M = 30 % og L = 60 %). Det forudsættes, at den nye fællesoffentlige kontoplan inkl. dimensionsstruktur er på plads, inden designworkshops igangsættes. Status: Endelig Side: 15 af 76

Der henvises i øvrigt til afsnit 1.3 med hensyn til områder, der ikke er i scope. 2.1.2 Debitor 2.1.2.1 Formål Målet under designfasen på Debitor-området er at lave den grundlæggende opsætning og konfiguration af Debitor i AX 2012 og beskrive det i et Debitor FCD. De identificerede gaps fra FRD Debitor behandles på designworkshoppen med henblik på at designe løsningen for de enkelte gaps og beskrive disse i FDD'er. Der udarbejdes ét FDD for hvert identificerede gap. Hvis Debitor-området indeholder gaps, der kræver større løsningskomponenter, tages der stilling til, om der i development-fasen skal udarbejdes TDD'er for disse. 2.1.2.2 Nøgleleverancer Nøgleleverancer fra EG på Debitor-området er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. For yderligere detaljer på området henvises der til FRD Debitor og de deri beskrevne fit/gaps. Tabel 2: Nøgleleverancer på Debitor-området Debitormodul Deb Deltager i designworkshop med rette ressource. Godkende funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. Udskriftsstyring Deb Deltager i designworkshop med rette ressource. Godkende funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. OIOUBL-konfiguration Deb Deltager i designworkshop med rette ressource. Godkende funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. Ydelser (Billing codes) Deb Deltager i designworkshop med rette ressource. Godkende Status: Endelig Side: 16 af 76

5 prædefinerede udskrifter Deb Deltager i designworkshop med rette ressource. Godkende Fælles ERP-sekretariat er forpligtiget til klart at definere, hvilke 5 udskrifter der skal designes inden afholdelse af workshop. Præudfyldning skabelon Medsend dokument Opsætning FI-kort Direct debit Udtræk til SKAT QA Deb Deb Deb Deb Deb Deb Deltager i designworkshop med rette ressource. Godkende Deltager i designworkshop med rette ressource. Godkende Deltager i designworkshop med rette ressource. Godkende Deltager i designworkshop med rette ressource. Godkende Deltager i designworkshop med rette ressource. Godkende Sikring af tværfaglig koordinering samt sporrelevant QA-arbejde. 2.1.2.3 Hovedoutput Hovedoutput på Debitor-området består af følgende: Udarbejdelse af FCD Debitor Udarbejdelse af X antal FDD'er (afhængigt af antal gaps på området) Beslutning af, om der skal udarbejdes TDD'er på området og hvor mange. Status: Endelig Side: 17 af 76

2.1.2.4 Forudsætninger Følgende forudsætninger er gældende på Debitor-området: Det forudsættes, at den udarbejdede FCD kan godkendes, herunder den fordeling af processer, der blev aftalt i afklaringsfasen (H = 10 %, M = 30 % og L = 60 %). Det er en forudsætning, at de integrationer, der er nævnt i FRD Debitor og i integrationsstrategien, designes. Det forudsættes, at fagsystemerne kan levere de nødvendige fakturagrundlag til AX 2012, jf. FRD Debitor. Det forudsættes, at Fælles ERP-sekretariat udarbejder en fuld oversigt over ydelser (katalog) samt beskrivelse af evt. særlige regler, der er gældende for bestemte typer ydelser. Der henvises i øvrigt til afsnit 1.3 med hensyn til områder, der ikke er i scope. 2.1.3 Kreditor 2.1.3.1 Formål Målet under designfasen på Kreditor-området er at lave den grundlæggende opsætning og konfiguration af Kreditor i AX 2012 og beskrive det i et Kreditor FCD. De identificerede gaps fra FRD Kreditor behandles på designworkshoppen med henblik på at designe løsningen for de enkelte gaps og beskrive disse i FDD'er. Der udarbejdes ét FDD for hvert identificerede gap. Hvis Kreditor-området indeholder gaps, der kræver større løsningskomponenter, tages der stilling til, om der i development-fasen skal udarbejdes TDD'er for disse. 2.1.3.2 Nøgleleverancer Nøgleleverancer fra EG på Kreditor-området er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. For yderligere detaljer på området henvises der til FRD Kreditor og de deri beskrevne fit/gaps. Tabel 3: Nøgleleverancer på Kreditor-området Kreditor Kre funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. Status: Endelig Side: 18 af 76

EGVI Kre funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. 5 prædefinerede udskrifter Kre Fælles ERP-sekretariat er forpligtiget til klart at definere, hvilke 5 udskrifter der skal designes inden afholdelse af workshop. Bankeksport GLN-register Kreditorworkflow (FRD) QA Kre Kre Kre Kre Sikring af tværfaglig koordinering samt sporrelevant QA-arbejde. 2.1.3.3 Hovedoutput Hovedoutput på Kreditor-området består af følgende: Udarbejdelse af FCD Kreditor Udarbejdelse af X antal FDD'er (afhængigt af antal gaps på området) Beslutning af, om der skal udarbejdes TDD'er på området og hvor mange. 2.1.3.4 Forudsætninger Følgende forudsætninger er gældende på Kreditor-området: Status: Endelig Side: 19 af 76

Det forudsættes, at den udarbejdede FCD kan godkendes, herunder den fordeling af processer, der blev aftalt i afklaringsfasen (H = 10 %, M = 30 % og L = 60 %). Det er en forudsætning, at der i forbindelse med designworkshoppen vælges en kreditorworkflowløsning (gerne inden designworkshoppen). Det er en forudsætning, at de integrationer, der er nævnt i FRD Kreditor og i integrationsstrategien, udarbejdes. Der henvises i øvrigt til afsnit 1.3 med hensyn til områder, der ikke er i scope. 2.1.4 ttestyrelsen 2.1.4.1 Formål Området ttestyrelsen er kendetegnet ved en række meget specifikke processer og behov i ttestyrelsen, såsom Inkasso, Motorafgift m.fl. Disse processer er som udgangspunkt ikke understøttet af standard AX 2012, hvorfor fokus på sporet er at finde løsningerne via tredjepartsprodukter til de specifikke formål eller lave de nødvendige kundespecifikke tilpasninger i AX 2012. Målet under designfasen på området ttestyrelsen er at lave opsætning og konfiguration af de moduler i AX 2012, som specifikt skal anvendes på området. Det indebærer bl.a. de dele af Finans-, Debitor- og Kreditor-modulerne, som skal bruges på eksempelvis inkassoområdet. Modulerne bliver i forvejen opsat på de enkelte spors designworkshops med deltagelse af repræsentanter fra ttestyrelsen, hvorfor designworkshop på området ttestyrelsen vil fokusere på mere specifikke funktioner. Desuden vil der være fokus på grundlæggende opsætning af fiktive regnskaber for øvrige fordringshavere (inkasso), jf. ttestyrelsen FRD. Der udarbejdes et ttestyrelsen FCD med specifikke opsætninger og konfigurationer på området. Derudover vil FCD'erne på de enkelte områder også være dækkende for ttestyrelsen. De identificerede gaps fra FRD ttestyrelsen skal desuden behandles på designworkshoppen med henblik på at designe løsningen for de enkelte gaps og beskrive disse i FDD'er. Der udarbejdes ét FDD for hvert identificerede gap. Hvis området ttestyrelsen indeholder gaps, der kræver større løsningskomponenter, tages der stilling til, om der i development-fasen skal udarbejdes TDD'er for disse. 2.1.4.2 Nøgleleverancer Nøgleleverancer fra EG på området ttestyrelsen er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. For yderligere detaljer på området henvises der til FRD ttestyrelsen og de deri beskrevne fit/gaps. Status: Endelig Side: 20 af 76

Tabel 4: Nøgleleverancer på området ttestyrelsen Inkasso Rykker Fakturaprocesoptimering (told) Betalingsplaner Udskriv kontoudtog (Portal) Afgiftsregister Afgiftssammenhængen Afgiftslogik funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. Status: Endelig Side: 21 af 76

Automatafgift Motorafgift Indførselsafgift/godsregistrering Udførselsafgift Stempelregister/Udlæg Statistikregister (told) Dan billinggrundlag i kladder ( 85) Udligning på tværs af billing codes Fælles ERP-sekretariat skal inden designworkshop definere evt. yderligere afgifter, som skal indeholdes. Der er "medtaget" 4 afgifter. Deltager i designworkshop med rette ressourcer. Godkende funktionelle designdokumenter (FDD). Fælles ERP-sekretariat skal forestå konfiguration og efterfølgende foretage dette i test/produktion samt flere regnskaber. Status: Endelig Side: 22 af 76

Kreditormodregning Modregningsbrev (Portal) Meddebitorlogik Løntræk/afdragsordning 5 prædefinerede udskrifter Fælles ERP-sekretariat er forpligtiget til klart at definere, hvilke 5 udskrifter der skal designes inden afholdelse af workshop. Udligning Udskrifter Rykker Status: Endelig Side: 23 af 76

Rente Opkrævning Mellemregning Fiktive regnskaber (INI, GF ) Winformatik (overgangsfase) Indlevering af løntræk Private krav CrossWork templates 10 Fælles ERP-sekretariat foretager selv opsætning af yderligere regnskaber, der ønskes. Deltager i designworkshop med rette ressourcer. Godkende funktionelle designdokumenter (FDD). Fælles ERP-sekretariat skal forestå konfiguration og efterfølgende foretage dette i test/produktion samt flere regnskaber. Fælles ERP-sekretariat skal sikre, at det inden designworkshop er defineret, hvilke 10 dokumenter der skal designes. Deltager i designworkshop med rette ressourcer. Godkende funktionelle designdokumenter (FDD). Fælles ERP-sekretariat skal forestå konfiguration og efterfølgende foretage dette i test/produktion samt flere regnskaber. Status: Endelig Side: 24 af 76

Testsupport QA/koordinering EG bistår Fælles ERP-sekretariat's superbrugere ifm. deres testarbejde. EG udfører ikke det enkelte testarbejde og udarbejder heller ikke testcases, men validerer og kvalitetssikre (QA) disse. Sikring af tværfaglig koordinering samt sporrelevant QA-arbejde. 2.1.4.3 Hovedoutput Hovedoutput på området ttestyrelsen består af følgende: Beslutning om valg af inkassoløsning dette skal foretages inden næste fase (development) Udarbejdelse af FCD ttestyrelsen Udarbejdelse af X antal FDD'er (afhængigt af antal gaps på området) Beslutning af, om der skal udarbejdes TDD'er på området og hvor mange. 2.1.4.4 Forudsætninger Følgende forudsætninger er gældende på området ttestyrelsen: Det forudsættes, at den udarbejdede FCD kan godkendes, herunder den fordeling af processer, der blev aftalt i afklaringsfasen (H = 10 %, M = 30 % og L = 60 %). Det forudsættes, at den nye fællesoffentlige kontoplan inkl. dimensionsstruktur er på plads, inden designworkshops igangsættes. Det er en forudsætning, at der er valgt en kreditorworkflowløsning (gerne inden designworkshops). Det er en forudsætning, at de integrationer, der er nævnt i FRD ttestyrelsen og i integrationsstrategien, udarbejdes. Det forudsættes, at fagsystemerne kan levere de nødvendige fakturagrundlag til AX 2012, jf. FRD Debitor. Det forudsættes, at Fælles ERP-sekretariat-sekretariatet udarbejder en fuld oversigt over ydelser (katalog) samt beskrivelse af evt. særlige regler, der er gældende for bestemte typer ydelser. Det er en forudsætning, at der vælges en løsning til inkasso i forbindelse med designworkshops (gerne inden designworkshops). Der henvises i øvrigt til afsnit 1.3 med hensyn til områder, der ikke er i scope. Status: Endelig Side: 25 af 76

2.1.5 Budgettering og budgetopfølgning 2.1.5.1 Formål Målet under designfasen på området Budgettering og budgetopfølgning er at lave den grundlæggende opsætning og konfiguration af Budgettering i AX 2012 og beskrive det i et Budgettering og budgetopfølgning FCD. De identificerede gaps fra FRD Budget og Budgetopfølgning behandles på designworkshoppen med henblik på at designe løsningen for de enkelte gaps og beskrive disse i FDD'er. Der udarbejdes ét FDD for hvert identificerede gap. Hvis området Budgettering og budgetopfølgning indeholder gaps, der kræver større løsningskomponenter, tages der stilling til, om der i development-fasen skal udarbejdes TDD'er for disse. 2.1.5.2 Nøgleleverancer Nøgleleverancer fra EG på området Budgettering og budgetopfølgning er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. For yderligere detaljer på området henvises der til FRD Budget og budgetopfølgning og de deri beskrevne fit/gaps. Tabel 5: Nøgleleverancer på området Budgettering og budgetopfølgning Budgetmodul Budgetsimulering Balanceniveau QA/koordinering Bud Bud Bud Bud funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. Sikring af tværfaglig koordinering samt sporrelevant QA-arbejde. Status: Endelig Side: 26 af 76

2.1.5.3 Hovedoutput Hovedoutput på området Budgettering og budgetopfølgning består af følgende: Udarbejdelse af FCD Budgettering og budgetopfølgning Udarbejdelse af X antal FDD'er (afhængigt af antal gaps på området) Beslutning af, om der skal udarbejdes TDD'er på området og hvor mange. 2.1.5.4 Forudsætninger Følgende forudsætninger er gældende på området Budgettering og budgetopfølgning: Det forudsættes, at den udarbejdede FCD kan godkendes, herunder den fordeling af processer, der blev aftalt i afklaringsfasen (H = 10 %, M = 30 % og L = 60 %). Det forudsættes, at den nye fællesoffentlige kontoplan inkl. dimensionsstruktur er på plads, inden designworkshops igangsættes. Det forudsættes, at standard budgetmodul anvendes i videst muligt omfang. Det forudsættes, at evt. integrationer til eksternt budgetværktøj (eksempelvis TM1) designes. Det forudsættes, at Management Reporter anvendes, jf. FRD Budgettering og budgetopfølgning. Der henvises i øvrigt til afsnit 1.3 med hensyn til områder, der ikke er i scope. 2.1.6 Finanslov/bevillinger 2.1.6.1 Formål Området Finanslov/bevillinger er kendetegnet ved en række meget specifikke processer og behov i GS. Disse processer er som udgangspunkt ikke understøttet af standard AX 2012, hvorfor fokus på sporet er at finde løsningerne via tredjepartsprodukter til de specifikke formål eller lave de nødvendige kundespecifikke tilpasninger i AX 2012. Målet under designfasen på området Finanslov/bevillinger er at lave den grundlæggende opsætning og konfiguration af Budgetteringsmodulet i AX 2012 med henblik på specifikke finanslovsprocesser. Derudover at konfiguration af eksterne værktøjer, der er valgt i forbindelse med løsningsworkshop til understøttelse af processerne på området, også gennemgås, og konfigurationen laves. Dette skal beskrives i et Finanslov/bevillinger FCD. De identificerede gaps fra FRD Finanslov/bevillinger behandles på designworkshops med henblik på at designe løsningen for de enkelte gaps og beskrive disse i FDD'er. Der udarbejdes ét FDD for hvert identificerede gap. Hvis området Finanslov/bevillinger indeholder gaps, der kræver større løsningskomponenter, tages der stilling til, om der i development-fasen skal udarbejdes TDD'er for disse. Status: Endelig Side: 27 af 76

2.1.6.2 Nøgleleverancer Nøgleleverancer fra EG på området Finanslov/bevillinger er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. For yderligere detaljer på området henvises der til FRD Finanslov/bevillinger og de deri beskrevne fit/gaps. Tabel 6: Nøgleleverancer på området Finanslov/bevillinger TM1 SharePoint Templates CDM FL-udskrivning Workflowinformation (AX) Godkendelse workflow (SP) Datasammenhængen (TM1) FinLov FinLov FinLov FinLov FinLov FinLov FinLov funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. Status: Endelig Side: 28 af 76

Prisregister Budgetflow (TM1) Dokumentgodkendelsesflow (SP) Testsupport QA/koordinering FinLov FinLov FinLov FinLov FinLov EG bistår Fælles ERP-sekretariat's superbrugere ifm. deres testarbejde. EG udfører ikke det enkelte testarbejde og udarbejder heller ikke testcases, men validerer og QA'er disse. Sikring af tværfaglig koordinering samt sporrelevant QA-arbejde. 2.1.6.3 Hovedoutput Hovedoutput på området Finanslov/bevillinger består af følgende: Beslutning om valg af løsning til understøttelse af processer på området Finanslov/bevillinger Udarbejdelse af FCD Finanslov/bevillinger Udarbejdelse af X antal FDD'er (afhængigt af antal gaps på området) Beslutning af, om der skal udarbejdes TDD'er på området og hvor mange. 2.1.6.4 Forudsætninger Følgende forudsætninger er gældende på området Finanslov/bevillinger: Det forudsættes, at den udarbejdede FCD kan godkendes, herunder den fordeling af processer, der blev aftalt i afklaringsfasen (H = 10 %, M = 30 % og L = 60 %). Det forudsættes, at den nye fællesoffentlige kontoplan inkl. dimensionsstruktur er på plads, inden designworkshops igangsættes. Det forudsættes, at standard budgetmodul anvendes og der er derfor ikke medtaget estimater til tilretninger af modulet. Det forudsættes, at der vælges et værktøj til understøttelse af finanslovsprocesserne, jf. FRD Finanslov/bevillinger. Status: Endelig Side: 29 af 76

FRD Finanslov/bevillinger er udarbejdet med udgangspunkt i en løsning via TM1/CDM/SharePoint. Det forudsættes, at Management Reporter anvendes, jf. FRD Finanslov/bevillinger. Der henvises i øvrigt til afsnit 1.3 med hensyn til områder, der ikke er i scope. 2.1.7 Ressortændringer 2.1.7.1 Formål Området Ressortændringer er kendetegnet ved en række meget specifikke processer og behov i forbindelse med ændringer i organisationen og dimensionsstrukturen. Disse processer er som udgangspunkt ikke understøttet af standard AX 2012, hvorfor fokus på sporet er at lave de nødvendige kundespecifikke tilpasninger i AX 2012. Målet under designfasen på området Ressortændringer er at lave den grundlæggende opsætning og konfiguration af modulerne Finans og Virksomhedsstyring i AX 2012 med henblik på specifikke behov i ressortændringsprocessen. Dette skal beskrives i et Ressortændringer FCD. De identificerede gaps fra FRD Ressortændringer behandles på designworkshops med henblik på at designe løsningen for de enkelte gaps og beskrive disse i FDD'er. Der udarbejdes ét FDD for hvert identificerede gap. Hvis området Ressortændringer indeholder gaps, der kræver større løsningskomponenter, tages der stilling til, om der i development-fasen skal udarbejdes TDD'er for disse. 2.1.7.2 Nøgleleverancer Nøgleleverancer fra EG på området Ressortændringer er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. For yderligere detaljer på området henvises der til FRD Ressortændringer og de deri beskrevne fit/gaps. Tabel 7: Nøgleleverancer på området Ressortændringer Hierarkier Datostyring Res Res funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. Status: Endelig Side: 30 af 76

Rapporteringsenheder 5 stk. QA Res Res Fælles ERP-sekretariat skal inden designworkshop havde listet, hvilke 5 rapporteringsenheder der ønskes. Sikring af tværfaglig koordinering samt sporrelevant QA-arbejde. 2.1.7.3 Hovedoutput Hovedoutput på området Ressortændringer består af følgende: Udarbejdelse af FCD Ressortændringer Udarbejdelse af X antal FDD'er (afhængigt af antal gaps på området) Beslutning af, om der skal udarbejdes TDD'er på området og hvor mange. 2.1.7.4 Forudsætninger Følgende forudsætninger er gældende på området Ressortændringer: Det forudsættes, at den udarbejdede FCD kan godkendes, herunder den fordeling af processer, der blev aftalt i afklaringsfasen (H = 10 %, M = 30 % og L = 60 %). Det forudsættes, at den nye fællesoffentlige kontoplan inkl. dimensionsstruktur er på plads, inden designworkshops igangsættes. Det forudsættes, at funktionaliteten organisationshierarkier i AX 2012 anvendes. Det forudsættes, at Ressortændringer udelukkende er et spørgsmål om rapporteringsstruktur. Det forudsættes, at Ressortændringer, som medfører behov for omposteringer, håndteres manuelt. Der henvises i øvrigt til afsnit 1.3 med hensyn til områder, der ikke er i scope. 2.1.8 Std. Ledelsesinformation 2.1.8.1 Formål Målet under designfasen på området Std. Ledelsesinformation er at lave den grundlæggende opsætning og konfiguration af værktøjet Management Reporter, jf. FRD Std. Ledelsesinformation, og beskrive det i et Std. Ledelsesinformation FCD. De identificerede gaps fra FRD Std. Ledelsesinformation behandles på designworkshoppen med henblik på at designe løsningen for de enkelte gaps og beskrive disse i FDD'er. Der udarbejdes ét FDD for hvert identificerede gap. Status: Endelig Side: 31 af 76

Hvis området Std. Ledelsesinformation indeholder gaps, der kræver større løsningskomponenter, tages der stilling til, om der i development-fasen skal udarbejdes TDD'er for disse. 2.1.8.2 Nøgleleverancer Nøgleleverancer fra EG på området Std. Ledelsesinformation er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. For yderligere detaljer på området henvises der til FRD Std. Ledelsesinformation og de deri beskrevne fit/gaps. Tabel 8: Nøgleleverancer på området Std. Ledelsesinformation Management Reporter 3 stk. QA LedInf LedInf funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. Fælles ERP-sekretariat skal sikre, at der inden designworkshop foreligger et udkast til, hvilke 3 finansielle rapporter der skal anvendes. Sikring af tværfaglig koordinering samt sporrelevant QA-arbejde. 2.1.8.3 Hovedoutput Hovedoutput på området Std. Ledelsesinformation består af følgende: Udarbejdelse af FCD Std. Ledelsesinformation Udarbejdelse af X antal FDD'er (afhængigt af antal gaps på området) Beslutning af, om der skal udarbejdes TDD'er på området og hvor mange. 2.1.8.4 Forudsætninger Følgende forudsætninger er gældende på området Std. Ledelsesinformation: Det forudsættes, at den udarbejdede FCD kan godkendes, herunder den fordeling af processer, der blev aftalt i afklaringsfasen (H = 10 %, M = 30 % og L = 60 %). Det forudsættes, at den nye fællesoffentlige kontoplan inkl. dimensionsstruktur er på plads, inden designworkshops igangsættes. Det forudsættes, at Management Reporter anvendes som rapporteringsværktøj. Der henvises i øvrigt til afsnit 1.3 med hensyn til områder, der ikke er i scope. Status: Endelig Side: 32 af 76

2.1.9 Intern revision 2.1.9.1 Formål Målet under designfasen på området Intern revision er at lave den grundlæggende opsætning og konfiguration af sikkerhedskontrolværktøjer samt standard databaselog i AX 2012. Derudover skal de gængse rapporteringsmuligheder på området gennemgås. Det skal beskrives i et Intern revision FCD. De identificerede gaps fra FRD Intern revision behandles på designworkshoppen med henblik på at designe løsningen for de enkelte gaps og beskrive disse i FDD'er. Der udarbejdes ét FDD for hvert identificerede gap. Hvis området Intern revision indeholder gaps, der kræver større løsningskomponenter, tages der stilling til, om der i development-fasen skal udarbejdes TDD'er for disse. 2.1.9.2 Nøgleleverancer Nøgleleverancer fra EG på området Intern revision er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. For yderligere detaljer på området henvises der til FRD Intern revision og de deri beskrevne fit/gaps. Tabel 9: Nøgleleverancer på området Intern revision Sikkerhedsstyring Rapportudtræk Databaselog QA IntRev IntRev IntRev IntRev funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. Sikring af tværfaglig koordinering samt sporrelevant QA-arbejde. Status: Endelig Side: 33 af 76

2.1.9.3 Hovedoutput Hovedoutput på området Intern revision består af følgende: Udarbejdelse af FCD Intern revision Udarbejdelse af X antal FDD'er (afhængigt af antal gaps på området) Beslutning af, om der skal udarbejdes TDD'er på området og hvor mange. 2.1.9.4 Forudsætninger Følgende forudsætninger er gældende på området Intern revision: Det forudsættes, at den udarbejdede FCD kan godkendes, herunder den fordeling af processer, der blev aftalt i afklaringsfasen (H = 10 %, M = 30 % og L = 60 %). Det forudsættes, at standard AX 2012 Databaselog anvendes. Der henvises i øvrigt til afsnit 1.3 med hensyn til områder, der ikke er i scope. 2.1.10 Projekt/anlæg 2.1.10.1 Formål Målet under designfasen på området Projekt/anlæg er udelukkende at gennemføre en analyse af processerne på området med henblik på at vælge og estimere en løsning. I henhold til EG's ODM-metode gennemføres faserne BA og SA på området, og resultaterne beskrives i en Projekt/anlæg FRD. 2.1.10.2 Nøgleleverancer Nøgleleverancer fra EG på området Projekt/anlæg er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. Tabel 10: Nøgleleverancer på området Projekt/anlæg Deep Dives LW Pro Pro Fælles ERP-sekretariat har besluttet, at analyse på Projekt/anlæg medtages i fasen, men procesmæssigt anvendes EG ODM. Fælles ERP-sekretariat skal levere procesoverblik til EG og foretage udvælgelse af relevante processer. Fælles ERP-sekretariat skal deltage med relevante ressourcer på sporet, således at løsningsworkshop kan afholdes optimalt. FRD Pro Fælles ERP-sekretariat skal godkende FRD som i tidligere forløb, og disse skal efterfølgende estimeres for Status: Endelig Side: 34 af 76

det efterfølgende forløb. QA Rådgivning Koordinering Pro Pro Pro Sikring af tværfaglig koordinering og sporrelevant QAarbejde. Fælles ERP-sekretariat skal udarbejde indstilling til styregruppen om, hvorledes dette skal håndteres. EG bidrager med rådgivning i relation til indstillingen. Fælles ERP-sekretariat skal håndtere forløbet. EG skal koordinere med egne ressourcer, men også sikre sammenhængen med XAL. 2.1.10.3 Hovedoutput Hovedoutput på området Projekt/anlæg består af følgende: Udarbejdelse af Deep Dive-referater for området Projekt/anlæg Udarbejdelse af LW-referater for området Projekt/anlæg Udarbejdelse af FRD for området Projekt/anlæg. 2.1.10.4 Forudsætninger N/A. 2.1.11 erelt 2.1.11.1 Formål Sporet erelt omfatter en række tværgående moduler i AX 2012, tredjepartsmoduler (EG og andre) og evt. supportsystemer, som arbejder med AX 2012. Der er tale om følgende: Licenskonfiguration i AX 2012 Brugere Roller Funktionsrettigheder Adgangsbegrænsninger HR Medarbejdere Organisation Bankmodul AIF (Application integration framework) GDM (Global data management) EGVI Status: Endelig Side: 35 af 76

AMC Direct Debit EG CrossWork TM1 SharePoint Lasernet. Målet under designfasen på sporet erelt er at lave den grundlæggende opsætning og konfiguration af ovennævnte. Der udarbejdes et erelt FCD, som dækker de konfigurationer, der ikke i forvejen er omfattet af de øvrige spor (hvis nødvendigt, kan der udarbejdes flere FCD'er på området). Sporet erelt har ikke været en del af afklaringsfasen, hvorfor der ikke foreligger specifikke FRD'er på området. Der udarbejdes ikke nogen FDD'er for sporet erelt, men sporet vil danne grundlag for en række af FDD'er på de øvrige spor. Det samme er gældende med hensyn til TDD'er. 2.1.11.2 Nøgleleverancer Nøgleleverancer fra EG på området erelt er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. Tabel 11: Nøgleleverancer på området erelt Basiskonfiguration AMC Lasernet HR funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. Status: Endelig Side: 36 af 76

Organisation Medarbejdere EGVI CrossWork Bank AIF GDM TM1 funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. Status: Endelig Side: 37 af 76

SharePoint Roller 10 stk. Funktionsrettigheder Adgangsbegrænsninger Sprogstyring Brugeroprettelse Sparring (eks.) QA funktionelle konfigurationsdokumenter (FCD). Fælles foretage dette i test/produktion samt flere regnskaber. Fælles ERP-sekretariat skal sikre, at EG bliver involveret i relevante møder vedrørende basisopsætning og roller/rettigheder. Fælles ERP-sekretariat skal sikre, at godkendelse af leverancer foretages, efter at EG QA-funktion har godkendt disse. 2.1.11.3 Hovedoutput Hovedoutput på området erelt består af følgende: Udarbejdelse af en eller flere FCD'er (afhængigt af behov). Status: Endelig Side: 38 af 76

2.1.11.4 Forudsætninger Følgende forudsætninger er gældende på området erelt: Det forudsættes, at den udarbejdede FCD kan godkendes, herunder den fordeling af processer, der blev aftalt i afklaringsfasen (H = 10 %, M = 30 % og L = 60 %). Der henvises i øvrigt til afsnit 1.3 med hensyn til områder, der ikke er i scope. 2.1.12 Teknik/infrastruktur 2.1.12.1 Formål Sporet Teknik/infrastruktur omfatter udarbejdelse af dokumentation og rådgivning i forbindelse med sizing af de tekniske installationer, licenser m.m., som skal understøtte den nye ERP-platform. Målet under designfasen på sporet Teknik/infrastruktur er at bistå kunden med sizing og dokumentation af den nødvendige infrastruktur til en løsning i denne størrelsesorden. Der udarbejdes ikke FCD'er, FDD'er eller TDD'er for sporet Teknik/infrastruktur. Disse erstattes af en række tekniske dokumenter. Disse fremgår af afsnittet om nøgleleverancer for sporet Teknik/infrastruktur (afsnit 2.1.12.2). 2.1.12.2 Nøgleleverancer Nøgleleverancer fra EG på området Teknik/infrastruktur er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. Tabel 12: Nøgleleverancer på området Teknik/infrastruktur Dokumentation AX Dokumentation SQL NFR-dokument Dokumentation af sammenhængen Tek_Infras Tek_Infras Tek_Infras Tek_Infras Fælles ERP-sekretariat skal ud fra NFR-dokument godkende den fremsendte dokumentation. Fælles ERP-sekretariat skal samtidig sikre, at hostingpartneren har relevant information til at håndtere installationen. Fælles ERP-sekretariat skal ud fra NFR-dokument godkende den fremsendte dokumentation. Fælles ERP-sekretariat skal samtidig sikre, at hostingpartneren har relevant information til at håndtere installationen. Fælles ERP-sekretariat skal levere input vedr. brugere input/sizing og øvrige krav inden workshop. Fælles ERP-sekretariat skal medvirke til, at den nuværende systemsammenhænge bliver stillet til rådighed. Status: Endelig Side: 39 af 76

Releaseprocedure Tek_Infras 1. installation (Testmiljø) Tek_Infras QA Rådgivning Teknisk projektledelse Tek_Infras Tek_Infras Tek_Infras Fælles ERP-sekretariat skal definere, hvilke ønsker de har til denne procedure, således at EG kan indarbejde disse i den normale beskrivelse. Fælles ERP-sekretariat skal sikre, at hostingpartner inddrager EG ifm. 1. installation, således at EG kan foretage sidemandsoplæring. Sikring af tværfaglig koordinering samt sporrelevant QA-arbejde. Da hosting foretages uden for EG's ansvarsområde, er det vigtigt, at Fælles ERP-sekretariat rådfører sig med EG vedrørende best practice og erfaring fra andre kunder. Fælles ERP-sekretariat skal ifm. installation og igangsætning have en teknisk projektleder, som sammen med EG's tilsvarende får disse opgaver løst. 2.1.12.3 Hovedoutput Hovedoutput på området Teknik/infrastruktur består af følgende: Udarbejdelse af NFR-dokument og andre tekniske dokumenter (se afsnit 2.1.12.2) Opsætning af ét AX 2012-testmiljø. 2.1.12.4 Forudsætninger Følgende forudsætninger er gældende på sporet Teknik/infrastruktur: Det forudsættes, at de fysiske installationer af servere, pc'er og databaser ikke er en del af EG's leverance. 2.1.13 Data migration 2.1.13.1 Formål Sporet Data migration omfatter definition, udtræk, rensning og import af de data, som er defineret i forbindelse med fælles stamdata og konverteringsworkshop gennemført i uge 5. På baggrund af den pågældende workshop er der udarbejdet er dokument vedrørende konverteringen (se dokumentet "Konverteringsstrategi"). Målet under designfasen på sporet Data migration er at definere, inden for de overordnede beslutninger om konvertering fra uge 5, hvilke specifikke data der konverteres og i hvilket omfang. Der gennemføres designworkshops, og der udarbejdes løsningsbeskrivelser i form af FDD'er. Der udarbejdes ét FDD for hver type data, der skal konverteres (eksempelvis finanssaldi). Der tages desuden stilling til, om der i development-fasen skal udarbejdes TDD'er for disse. Status: Endelig Side: 40 af 76

2.1.13.2 Nøgleleverancer Nøgleleverancer fra EG på området Data migration er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. For yderligere detaljer på området henvises der til konverteringsstrategien. Tabel 13: Nøgleleverancer på området Data migration Excel-journal upload Finanssaldospecifikation Finanssaldi Finanstransaktioner Åbne kreditorposter Åbne debitorposter (fritekst) Datakonv Datakonv Datakonv Datakonv Datakonv Datakonv Deltager i designworkshop med rette ressourcer. Godkende funktionelle konfigurationsdokumenter (FCD). Fælles ERP-sekretariat skal forestå konfiguration og efterfølgende foretage dette i test/produktion samt flere regnskaber. Fælles ERP-sekretariat skal sikre, at der inden designworkshop foreligger et udkast til, hvilke 3 finansielle rapporter der skal anvendes. Fælles ERP-sekretariat skal foretage dataudtræk fra Winformatik og XAL, således at de finanssaldospecifikationer, der skal indlæses, ligger i det format, EG har anvist, og at det balancerer med tilhørende saldo på finanskontoen. Fælles ERP-sekretariat skal foretage dataudtræk fra Winformatik og XAL, således at de finanssaldospecifikationer, der skal indlæses, ligger i det format, EG har anvist, og at det balancerer med tilhørende saldo på finanskontoen. Fælles ERP-sekretariat skal foretage dataudtræk fra Winformatik og XAL, således at de finanssaldospecifikationer, der skal indlæses ligger i det format, EG har anvist, og at det balancerer med tilhørende saldo på finanskontoen. Fælles ERP-sekretariat skal foretage dataudtræk fra Winformatik og XAL, således at de kreditorspecifikationer, der skal indlæses, ligger i det format, EG har anvist, og at det balancerer med tilhørende saldo på kreditor. Fælles ERP-sekretariat skal foretage dataudtræk fra Winformatik og XAL, således at de debitorspecifikationer, der skal indlæses, ligger i det format, EG har anvist, og at det balancerer med tilhørende saldo på debitor. Status: Endelig Side: 41 af 76

Konverteringstabel Historisk Finanslovstabel Datavask bistand QA/koordinering Datakonv Datakonv Datakonv Datakonv Fælles ERP-sekretariat skal inden designworkshop have beskrevet, hvilken konvertering fra "Gammel konto" til ny konto der er lavet, samt den tilhørende sammenhæng. Fælles ERP-sekretariat skal inden designworkshop sikre, at finanslovsdata, der bliver konverteret over, findes i den nye kontoplansstruktur. EG bistår Fælles ERP-sekretariat's superbrugere ifm. deres testarbejde. EG udfører ikke det enkelte testarbejde og udarbejder heller ikke testcases, men validerer og QA'er disse. Sikring af tværfaglig koordinering samt sporrelevant QA-arbejde. 2.1.13.3 Hovedoutput Hovedoutput på området Data migration består af følgende: Udarbejdelse af FDD'er for hver datatype i afsnit 2.1.13.2 ovenfor Beslutning af, om der skal udarbejdes TDD'er på området og hvor mange. 2.1.13.4 Forudsætninger Følgende forudsætninger er gældende på sporet Data migration: Det forudsættes, at DIXF-værktøjet anvendes. 2.1.14 Integrationsstrategi 2.1.14.1 Formål Sporet Integrationsstrategi omfatter identificerede systemintegrationer mellem det nye økonomisystem AX 2012 og en række andre systemer/datakilder, herunder: Integrationer til fagsystemer, der anvendes i kommunerne og GS Integrationer til nuværende økonomisystemer eller dele heraf, som ikke er med i fase 1 (fx lån) Bankintegrationer Webservices m.fl. Integrationerne er overordnet beskrevet i integrationsstrategidokumentet udarbejdet af EG i afklaringsfasen. Integrationer til offentlige stamdataregistre er beskrevet i afsnit 2.1.15. Målet under designfasen på området Integrationsstrategi er at lave detaljeret design af de enkelte integrationer, der er defineret i afklaringsfasen, jf. integrationsstrategien. Disse beskrives i FDD'er. Der udarbejdes ét FDD for hver integration. Status: Endelig Side: 42 af 76

Integrationer betragtes som gaps, der kræver større løsningskomponenter, hvorfor der skal udarbejdes ét TDD for hver integration i development-fasen. 2.1.14.2 Nøgleleverancer Nøgleleverancer fra EG på området Integrationsstrategi er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. For yderligere detaljer på området henvises der til integrationsstrategien. Tabel 14: Nøgleleverancer på området Integrationsstrategi Winformatik Løn Banking Stamdata Int Int Int Int Inden designworkshop er det Fælles ERP-sekretariat's ansvar, at de enkelte integrationers sammenhæng med processer er defineret. Deltager i designworkshop med rette ressourcer. Godkende funktionelle designdokumenter (FDD). Fælles ERP-sekretariat skal forestå konfiguration og efterfølgende foretage dette i test/produktion samt flere regnskaber. Inden designworkshop er det Fælles ERP-sekretariat's ansvar, at de enkelte integrationers sammenhæng med processer er defineret. Deltager i designworkshop med rette ressourcer. Godkende funktionelle designdokumenter (FDD). Fælles ERP-sekretariat skal forestå konfiguration og efterfølgende foretage dette i test/produktion samt flere regnskaber. Inden designworkshop er det Fælles ERP-sekretariat's ansvar, at de enkelte integrationers sammenhæng med processer er defineret. Deltager i designworkshop med rette ressourcer. Godkende funktionelle designdokumenter (FDD). Fælles ERP-sekretariat skal forestå konfiguration og efterfølgende foretage dette i test/produktion samt flere regnskaber. Inden designworkshop er det Fælles ERP-sekretariat's ansvar, at de enkelte integrationers sammenhæng med processer er defineret. Deltager i designworkshop med rette ressourcer. Godkende funktionelle designdokumenter (FDD). Fælles ERP-sekretariat skal forestå konfiguration og efterfølgende foretage dette i test/produktion samt flere regnskaber. Status: Endelig Side: 43 af 76

XAL-integrationer E-skat Finansintegrationsservice Debitorintegrationsservice Kreditorintegrationsservice Int Int Int Int Int Inden designworkshop er det Fælles ERP-sekretariat's ansvar, at de enkelte integrationers sammenhæng med processer er defineret. Deltager i designworkshop med rette ressourcer. Godkende funktionelle designdokumenter (FDD). Fælles ERP-sekretariat skal forestå konfiguration og efterfølgende foretage dette i test/produktion samt flere regnskaber. Inden designworkshop er det Fælles ERP-sekretariat's ansvar, at de enkelte integrationers sammenhæng med processer er defineret. Deltager i designworkshop med rette ressourcer. Godkende funktionelle designdokumenter (FDD). Fælles ERP-sekretariat skal forestå konfiguration og efterfølgende foretage dette i test/produktion samt flere regnskaber. Inden designworkshop er det Fælles ERP-sekretariat's ansvar, at de enkelte integrationers sammenhæng med processer er defineret. Deltager i designworkshop med rette ressourcer. Godkende funktionelle designdokumenter (FDD). Fælles ERP-sekretariat skal forestå konfiguration og efterfølgende foretage dette i test/produktion samt flere regnskaber. Inden designworkshop er det Fælles ERP-sekretariat's ansvar, at de enkelte integrationers sammenhæng med processer er defineret. Deltager i designworkshop med rette ressourcer. Godkende funktionelle designdokumenter (FDD). Fælles ERP-sekretariat skal forestå konfiguration og efterfølgende foretage dette i test/produktion samt flere regnskaber. Inden designworkshop er det Fælles ERP-sekretariat's ansvar, at de enkelte integrationers sammenhæng med processer er defineret. Deltager i designworkshop med rette ressourcer. Godkende funktionelle designdokumenter (FDD). Fælles ERP-sekretariat skal forestå konfiguration og efterfølgende foretage dette i test/produktion samt flere regnskaber. Status: Endelig Side: 44 af 76

Stamdataopdatering Integrationskoordinering Designstruktur QA/crashtest Business Care-services (5 nye) Int Int Int Int Int Inden designworkshop er det Fælles ERP-sekretariat's ansvar, at de enkelte integrationers sammenhæng med processer er defineret. Deltager i designworkshop med rette ressourcer. Godkende funktionelle designdokumenter (FDD). Fælles ERP-sekretariat skal forestå konfiguration og efterfølgende foretage dette i test/produktion samt flere regnskaber. Inden designworkshop er det Fælles ERP-sekretariat's ansvar, at de enkelte integrationers sammenhæng med processer er defineret. Deltager i designworkshop med rette ressourcer. Godkende funktionelle designdokumenter (FDD). Fælles ERP-sekretariat skal forestå konfiguration og efterfølgende foretage dette i test/produktion samt flere regnskaber. Fælles ERP-sekretariat skal sikre, at viden og fremtidige ønsker til struktur bliver indarbejdet. Fælles ERP-sekretariat skal sikre, at forholdene for at udføre en crashtest er til rådighed. Fælles ERPsekretariat skal udføre crashtest. EG kvalitetssikrer forhold og rådgiver ifm. udførelse af test. Fælles ERP-sekretariat-sekretariatet skal sammen med hostingpartneren definere, hvilke 5 overvågningselementer der skal udarbejdes. EG vil dernæst få disse indarbejdet i standardpakken. Integrationsalert/workflow Int ERP-sekretariatet skal inden møder vedrørende området definere, hvilke alerts/workflow der er krævet. Der er medtaget en timepulje til løsning. 2.1.14.3 Hovedoutput Hovedoutput på området Integrationsstrategi består af følgende: Udarbejdelse af FDD pr. integration Udarbejdelse af TDD pr. integration. Status: Endelig Side: 45 af 76

2.1.14.4 Forudsætninger Følgende forudsætninger er gældende på området Integrationsstrategi: Det forudsættes, at de integrationer, der fremgår af integrationsstrategien, er dækkende. ERP er ansvarlig for at levere relevant information omkring integrationer. Der henvises i øvrigt til afsnit 1.3 med hensyn til områder, der ikke er i scope. 2.1.15 Stamdata 2.1.15.1 Formål Sporet Stamdata omfatter de stamdata, der er defineret i forbindelse med fælles stamdata og konverteringsworkshops gennemført i uge 5. Sporet Stamdata omfatter bl.a. identificerede stamdata mellem det nye økonomisystem AX 2012 og offentlige registre, herunder: CPR GER. Stamdata er overordnet beskrevet i stamdatadokumentet "Model til styring af stamdata" udarbejdet af EG i afklaringsfasen. Målet under designfasen på sporet Stamdata er at lave detaljeret design af de stamdataintegrationer, der er defineret i afklaringsfasen, jf. integrationsstrategien. Disse beskrives i FDD'er. Der udarbejdes ét FDD for hver integration. Integrationer betragtes som gaps, der kræver større løsningskomponenter, hvorfor der skal udarbejdes ét TDD for hver integration i development-fasen. 2.1.15.2 Nøgleleverancer Nøgleleverancer fra EG på Stamdata-området er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. For yderligere detaljer på området henvises der til dokumentet "Model til styring af stamdata". Tabel 15: Nøgleleverancer på Stamdata-området DIXF opsætning CPR GAB-mapping Stam Stam Fælles ERP-sekretariat skal stille med systemejere, som kan udføre opsætning og efterfølgende træne dataansvarlige internt. Fælles ERP-sekretariat skal inden møde have forberedt, hvilke data der kan udtrækkes. Status: Endelig Side: 46 af 76

GER GAB-mapping Debitor fælles data Stamdatabistand QA/koordinering Stam Stam Stam Stam Fælles ERP-sekretariat skal inden møde have forberedt, hvilke data der kan udtrækkes. Fælles ERP-sekretariat skal inden møde have forberedt, hvilke data der kan udtrækkes. EG bistår Fælles ERP-sekretariat's superbrugere ifm. deres testarbejde. EG udfører ikke det enkelte testarbejde og udarbejder heller ikke testcases, men validerer og QA'er disse. Sikring af tværfaglig koordinering samt sporrelevant QA-arbejde. 2.1.15.3 Hovedoutput Hovedoutput på Stamdata-området består af følgende: Udarbejdelse af FDD pr. stamdataintegration Udarbejdelse af TDD pr. stamdataintegration. 2.1.15.4 Forudsætninger Følgende forudsætninger er gældende på Stamdata-området: Det forudsættes, at de integrationer, der fremgår af integrationsstrategien, er dækkende. Det forudsættes, at DIXF-værktøjet anvendes. Det forudsættes, at CPR- og GER-registre kan levere den nødvendige information. Der henvises i øvrigt til afsnit 1.3 med hensyn til områder, der ikke er i scope. 2.2 Development-fasen I development-fasen udarbejdes de tekniske designdokumenter (TDD) på de områder, det er aftalt i designfasen. Der gennemføres udvikling af kundespecifikke tilpasninger af systemet jf. de FDD'er, der er udarbejdet i designfasen, og de TDD'er, der er udarbejdet i development-fasen. Der foretages test af løsninger, jf. bilag 8a. 2.2.1 Finans 2.2.1.1 Formål Målet under development-fasen på Finans-området er at udarbejde relevante TDD'er på området. Med udgangspunkt i FRD, FDD og TDD skal der udvikles tilpasninger til de identificerede gaps. Der foretages test og godkendelse af konfiguration, opsætning og tilpasninger. Status: Endelig Side: 47 af 76

2.2.1.2 Nøgleleverancer Nøgleleverancer fra EG på Finans-området er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. For yderligere detaljer på området henvises der til FRD Finans og de deri beskrevne fit/gaps. Tabel 16: Nøgleleverancer på Finans-området CPR-nummerhåndtering Finansudligningsfunktion Posteringstekst m.m. Testsupport QA/koordinering Fin Fin Fin Fin Fin Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal udføre test af funktioner og flow i henhold til testbeskrivelsesdokument. EG bistår med support, hvis elementer ikke fungerer. Sikring af tværfaglig koordinering samt sporrelevant QAarbejde. 2.2.1.3 Hovedoutput Hovedoutput på Finans-området består af følgende: Udarbejdelse af X antal TDD'er (afhængigt af antal gaps på området) Udvikling af tilpasninger Test og godkendelse af opsætning, konfiguration og tilpasninger. 2.2.1.4 Forudsætninger Følgende forudsætninger er gældende på Finans-området: Det forudsættes, at der i designfasen er udarbejdet og godkendt de aftalte FDD'er og TDD'er. Det forudsættes, at de nødvendige tekniske installationer og AX 2012-miljøer er på plads, inden development-fasen igangsættes. 2.2.2 Debitor 2.2.2.1 Formål Målet under development-fasen på Debitor-området er at udarbejde relevante TDD'er på området. Med udgangspunkt i FRD, FDD og TDD skal der udvikles tilpasninger til de identificerede gaps. Der foretages test og godkendelse af konfiguration, opsætning og tilpasninger (herunder integrationer). Status: Endelig Side: 48 af 76

2.2.2.2 Nøgleleverancer Nøgleleverancer fra EG på Debitor-området er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. For yderligere detaljer på området henvises der til FRD Debitor og de deri beskrevne fit/gaps. Tabel 17: Nøgleleverancer på Debitor-området Ydelser (Billing codes) Præudfyldning skabelon FI kort opsætning Direct debit Test support Deb Deb Deb Deb Deb Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal udføre test af funktioner og flow i henhold til testbeskrivelsesdokument. EG bistår med support, hvis elementer ikke fungerer. QA Deb Sikring tværfaglig koordinering samt spor relevant QA arbejde 2.2.2.3 Hovedoutput Hovedoutput på Debitor-området består af følgende: Udarbejdelse af X antal TDD'er (afhængigt af antal gaps på området) Udvikling af tilpasninger Test og godkendelse af opsætning, konfiguration og tilpasninger (herunder integrationer). 2.2.2.4 Forudsætninger Følgende forudsætninger er gældende på Debitor-området: Det forudsættes, at der i designfasen er udarbejdet og godkendt de aftalte FDD'er og TDD'er. Det forudsættes, at de nødvendige tekniske installationer og AX 2012-miljøer er på plads inden development-fasen igangsættes. 2.2.3 Kreditor 2.2.3.1 Formål Målet under development-fasen på Kreditor-området er at udarbejde relevante TDD'er på området. Med udgangspunkt i FRD, FDD og TDD skal der udvikles tilpasninger til de identificerede gaps. Der foretages test og godkendelse af konfiguration, opsætning og tilpasninger (herunder integrationer). Status: Endelig Side: 49 af 76

Kreditor-sporet er kendetegnet ved, at der i skrivende stund stadig ikke er foretaget valg af kreditorworkflowsystem. Afhængigt af, om det er EGVI, IRIS eller et tredje system, der vælges i designfasen, vil dette have indflydelse på mængden af gaps på området. Derudover vil kompleksiteten af de tilpasninger, der skal udvikles, også være forskellig afhængigt af det valg, der foretages. 2.2.3.2 Nøgleleverancer Nøgleleverancer fra EG på Kreditor-området er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. For yderligere detaljer på området henvises der til FRD Kreditor og de deri beskrevne fit/gaps. Tabel 18: Nøgleleverancer på Kreditor-området GLN register Kreditorworkflow (FRD) Test support Kre Kre Kre Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal udføre test af funktioner og flow i henhold til testbeskrivelsesdokument. EG bistår med support, hvis elementer ikke fungerer. QA Kre Sikring tværfaglig koordinering samt spor relevant QA arbejde 2.2.3.3 Hovedoutput Hovedoutput på Kreditor-området består af følgende: Udarbejdelse af X antal TDD'er (afhængigt af antal gaps på området) Udvikling af tilpasninger Test og godkendelse af opsætning, konfiguration og tilpasninger (herunder integrationer). 2.2.3.4 Forudsætninger Følgende forudsætninger er gældende på Kreditor-området: Det forudsættes, at der i designfasen er udarbejdet og godkendt de aftalte FDD'er og TDD'er. Det forudsættes, at de nødvendige tekniske installationer og AX 2012-miljøer er på plads inden development-fasen igangsættes. Det forudsættes, at der ved valg af anden kreditorworkflowløsning end den, der er beskrevet i FRD Kreditor (under afklaringsfasen), er udarbejdet en ny analyse og FRD på området, inden development-fasen igangsættes. Status: Endelig Side: 50 af 76

2.2.4 ttestyrelsen 2.2.4.1 Formål Målet under development-fasen på området ttestyrelsen er at udarbejde relevante TDD'er på området. Med udgangspunkt i FRD, FDD og TDD skal der udvikles tilpasninger til de identificerede gaps. Der foretages test og godkendelse af konfiguration, opsætning og tilpasninger (herunder integrationer). Området ttestyrelsen er kendetegnet ved, at der i skrivende stund stadig ikke er foretaget valg af inkassoløsning. Afhængigt af, om det er InkassoPro, EG Public Debitor eller en AX 2012-tilpasset løsning, der vælges i designfasen, vil dette have indflydelse på mængden af gaps på området. Derudover vil kompleksiteten af de tilpasninger, der skal udvikles, også være forskellig afhængigt af det valg, der foretages. 2.2.4.2 Nøgleleverancer Nøgleleverancer fra EG på området ttestyrelsen er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. For yderligere detaljer på området henvises der til FRD ttestyrelsen og de deri beskrevne fit/gaps. Tabel 19: Nøgleleverancer på området ttestyrelsen Afgift register Afgift sammenhængen Afgift logik Automatafgift Motorafgift Indførselsafgift/godsregistrering Udførselsafgift Stempelregister/Udlæg Statistik register (told) Dan billinggrundlag i kladder ( 85) Udligning på tværs af billingcodes Kreditormodregning Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Status: Endelig Side: 51 af 76

Modregningsbrev (Portal) Meddebitor logik Løntræk / afdragsordning Udligning Udskrifter Rykker Rente Opkrævning Mellemregning WinFormatik (overgangsfase) Indlevering af løntræk Private krav Information omkring løntræk/et Test support QA/Koordinering Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Sikring tværfaglig koordinering samt spor relevant QA arbejde 2.2.4.3 Hovedoutput Hovedoutput på området ttestyrelsen består af følgende: Udarbejdelse af X antal TDD'er (afhængigt af antal gaps på området) Udvikling af tilpasninger Test og godkendelse af opsætning, konfiguration og tilpasninger (herunder integrationer). 2.2.4.4 Forudsætninger Følgende forudsætninger er gældende på området ttestyrelsen: Det forudsættes, at der i designfasen er udarbejdet og godkendt de aftalte FDD'er og TDD'er. Status: Endelig Side: 52 af 76

Det forudsættes, at de nødvendige tekniske installationer og AX 2012-miljøer er på plads, inden development-fasen igangsættes. Det forudsættes, at der ved valg af anden inkassoløsning end den, der er beskrevet i FRD ttestyrelsen (under afklaringsfasen), er udarbejdet en ny analyse og FRD på området, inden development-fasen igangsættes. 2.2.5 Budgettering og budgetopfølgning 2.2.5.1 Formål Målet under development-fasen på området Budgettering og budgetopfølgning er at udarbejde relevante TDD'er på området. Med udgangspunkt i FRD, FDD og TDD skal der udvikles tilpasninger til de identificerede gaps. Der foretages test og godkendelse af konfiguration, opsætning og tilpasninger (herunder integrationer). Afhængigt af, hvilken løsning der vælges i designfasen i forbindelse med sporet Finanslov/bevillinger, kan det have indflydelse på kompleksiteten af dette spor, da budgetter og finanslov/bevillinger behandles ved hjælp af samme funktionalitet i AX 2012. Hvis der vælges et andet værktøj til finanslov, kan det betyde, at den samme skal anvendes i forbindelse med budgetteringsprocesser i AX 2012. 2.2.5.2 Nøgleleverancer Nøgleleverancer fra EG på området Budgettering og budgetopfølgning er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. For yderligere detaljer på området henvises der til FRD Budgettering og budgetopfølgning og de deri beskrevne fit/gaps. Tabel 20: Nøgleleverancer på området Budgettering og budgetopfølgning Balanceniveau Test support Bud Bud Fælles ERP-sekretariat skal bistå med afklaring såfremt der opstår behov. Fælles ERP-sekretariat skal udføre test af funktioner samt flow, iflg test beskrivelses dokument. EG bistår med support såfremt elementer ikke fungerer. QA/koordinering Bud Sikring tværfaglig koordinering samt spor relevant QA arbejde Status: Endelig Side: 53 af 76

2.2.5.3 Hovedoutput Hovedoutput på området Budgettering og budgetopfølgning består af følgende: Udarbejdelse af X antal TDD'er (afhængigt af antal gaps på området) Udvikling af tilpasninger Test og godkendelse af opsætning, konfiguration og tilpasninger (herunder integrationer). 2.2.5.4 Forudsætninger Følgende forudsætninger er gældende på området Budgettering og budgetopfølgning: Det forudsættes, at der i designfasen er udarbejdet og godkendt de aftalte FDD'er og TDD'er. Det forudsættes, at de nødvendige tekniske installationer og AX 2012-miljøer er på plads, inden development-fasen igangsættes. Det forudsættes, at Management Reporter er installeret og konfigureret, inden fasen igangsættes. 2.2.6 Finanslov/bevillinger 2.2.6.1 Formål Målet under development-fasen på området Finanslov/bevillinger er at udarbejde relevante TDD'er på området. Med udgangspunkt i FRD, FDD og TDD skal der udvikles tilpasninger til de identificerede gaps. Der foretages test og godkendelse af konfiguration, opsætning og tilpasninger (herunder integrationer). I skrivende stund er der ikke foretaget valg af en løsning til håndtering af processerne vedrørende finanslovsudarbejdelse. Afhængigt af, hvilken løsning der vælges i designfasen til understøttelse af disse processer, vil det have betydning for, hvilke tilretninger der skal laves på området. Hvis der vælges et eksternt værktøj, såsom TM1, vil det betyde, at der skal udvikles en integration. Hvis det derimod vælges at tilpasse AX 2012 for at kunne håndtere processerne heri, vil det betyde tilpasning af AX 2012, men ingen integration. 2.2.6.2 Nøgleleverancer Nøgleleverancer fra EG på området Finanslov/bevillinger er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. For yderligere detaljer på området henvises der til FRD Finanslov/bevillinger og de deri beskrevne fit/gaps. Tabel 21: Nøgleleverancer på området Finanslov/bevillinger Workflow information (AX) FinLov Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Status: Endelig Side: 54 af 76

Godkendelse workflow (SP) Datasammenhængen (TM1) Prisregister Budget flow (TM1) Dokumentgodkendelseflow (SP) Test support QA/koordinering FinLov FinLov FinLov FinLov FinLov FinLov FinLov Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal udføre test af funktioner samt flow, iflg test beskrivelses dokument. EG bistår med support såfremt elementer ikke fungerer. Sikring tværfaglig koordinering samt spor relevant QA arbejde 2.2.6.3 Hovedoutput Hovedoutput på området Finanslov/bevillinger består af følgende: Udarbejdelse af X antal TDD'er (afhængigt af antal gaps på området) Udvikling af tilpasninger Test og godkendelse af opsætning, konfiguration og tilpasninger (herunder integrationer). 2.2.6.4 Forudsætninger Følgende forudsætninger er gældende på området Finanslov/bevillinger: Det forudsættes, at der i designfasen er udarbejdet og godkendt de aftalte FDD'er og TDD'er. Det forudsættes, at de nødvendige tekniske installationer og AX 2012-miljøer er på plads, inden development-fasen igangsættes. Det forudsættes, at Management Reporter er installeret og konfigureret, inden fasen igangsættes. Det forudsættes, at der ved valg af anden løsning til understøttelse af finanslovsprocesser end den, der er beskrevet i FRD Finanslov/bevillinger (under afklaringsfasen), er udarbejdet en ny analyse og FRD på området, inden development-fasen igangsættes. 2.2.7 Ressortændringer 2.2.7.1 Formål Målet under development-fasen på området Ressortændringer er at udarbejde relevante TDD'er på området. Med udgangspunkt i FRD, FDD og TDD skal der udvikles tilpasninger til de identificerede gaps. Der foretages test og godkendelse af konfiguration, opsætning og tilpasninger. Status: Endelig Side: 55 af 76

2.2.7.2 Nøgleleverancer Nøgleleverancer fra EG på området Ressortændringer er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. For yderligere detaljer på området henvises der til FRD Ressortændringer og de deri beskrevne fit/gaps. Tabel 22: Nøgleleverancer på området Ressortændringer Rapporteringsenheder 5 stk Test support QA Res Res Res Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal udføre test af funktioner samt flow, iflg test beskrivelses dokument. EG bistår med support såfremt elementer ikke fungerer. Sikring tværfaglig koordinering samt spor relevant QA arbejde 2.2.7.3 Hovedoutput Hovedoutput på området Ressortændringer består af følgende: Udarbejdelse af X antal TDD'er (afhængigt af antal gaps på området) Udvikling af tilpasninger Test og godkendelse af opsætning, konfiguration og tilpasninger. 2.2.7.4 Forudsætninger Følgende forudsætninger er gældende på området Ressortændringer: Det forudsættes, at der i designfasen er udarbejdet og godkendt de aftalte FDD'er og TDD'er. Det forudsættes, at de nødvendige tekniske installationer og AX 2012-miljøer er på plads, inden development-fasen igangsættes. 2.2.8 Std. Ledelsesinformation 2.2.8.1 Formål Målet under development-fasen på området Std. Ledelsesinformation er at verificere opsætning og konfigurationen af Management Reporter og AX 2012, jf. udarbejdede FRD- og FDD-dokumenter. Med udgangspunkt i FRD og FDD foretages test og godkendelse af konfiguration og opsætning på området. 2.2.8.2 Nøgleleverancer Nøgleleverancer fra EG på området Std. Ledelsesinformation er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. For yderligere detaljer på området henvises der til FRD Std. Ledelsesinformation og de deri beskrevne fit/gaps. Status: Endelig Side: 56 af 76

Tabel 23: Nøgleleverancer på området Std. Ledelsesinformation Test support Træning (superbrugere kursus 6 pers) QA LedInf LedInf LedInf Fælles ERP-sekretariat skal udføre test af funktioner samt flow, iflg test beskrivelses dokument. EG bistår med support såfremt elementer ikke fungerer. Fælles ERP-sekretariat skal stille med relevante superbrugere til deltagelse i kurset. Deltagerantal på alle kurser er 6 personer. Sikring tværfaglig koordinering samt spor relevant QA arbejde 2.2.8.3 Hovedoutput Hovedoutput området på Std. Ledelsesinformation består af følgende: Test og godkendelse af opsætning, konfiguration af Management Reporter. 2.2.8.4 Forudsætninger Følgende forudsætninger er gældende på området Std. Ledelsesinformation: Det forudsættes, at der i designfasen er udarbejdet og godkendt de aftalte FDD'er og TDD'er. Det forudsættes, at de nødvendige tekniske installationer og AX 2012-miljøer er på plads, inden development-fasen igangsættes. Det forudsættes, at Management Reporter er installeret og konfigureret, inden fasen igangsættes. 2.2.9 Intern revision 2.2.9.1 Formål Målet under development-fasen på området Intern revision er at verificere opsætning og konfigurationen af AX 2012, jf. udarbejdede FRD- og FDD-dokumenter. Med udgangspunkt i FRD og FDD foretages test og godkendelse af konfiguration og opsætning på området. 2.2.9.2 Nøgleleverancer Nøgleleverancer fra EG på området Intern revision er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. For yderligere detaljer på området henvises der til FRD Intern revision og de deri beskrevne fit/gaps. Status: Endelig Side: 57 af 76

Tabel 24: Nøgleleverancer på området Intern revision Test support IntRev Fælles ERP-sekretariat skal udføre test af funktioner samt flow, iflg test beskrivelses dokument. EG bistår med support såfremt elementer ikke fungerer. QA IntRev Sikring tværfaglig koordinering samt spor relevant QA arbejde 2.2.9.3 Hovedoutput Hovedoutput på området Intern revision består af følgende: Test og godkendelse af opsætning, konfiguration af AX 2012. 2.2.9.4 Forudsætninger Følgende forudsætninger er området gældende Intern revision: Det forudsættes, at der i designfasen er udarbejdet og godkendt de aftalte FDD'er og TDD'er. Det forudsættes, at de nødvendige tekniske installationer og AX 2012-miljøer er på plads, inden development-fasen igangsættes. 2.2.10 Projekt/anlæg N/A. 2.2.11 erelt 2.2.11.1 Formål Målet under development-fasen på området erelt er at udarbejde relevante TDD'er på området og bistå med sparring og rådgivning i forbindelse med test og godkendelse af konfiguration, opsætning og tilpasninger. 2.2.11.2 Nøgleleverancer Nøgleleverancer fra EG på området erelt er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. Tabel 25: Nøgleleverancer på området erelt Sprog styring Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Status: Endelig Side: 58 af 76

Sparring (eks.) QA 2.2.11.3 Hovedoutput Fælles ERP-sekretariat skal sikre, at EG bliver inddraget i møder/workshops m.m., som påvirker den struktur og løsning, der er foreslået. Sikring tværfaglig koordinering samt spor relevant QA arbejde Hovedoutput på området erelt består af følgende: Udarbejdelse af X antal TDD'er (afhængigt af antal gaps på området) Udvikling af tilpasninger Test og godkendelse af opsætning, konfiguration af AX 2012. 2.2.11.4 Forudsætninger Følgende forudsætninger er gældende på området erelt: Det forudsættes, at der i designfasen er udarbejdet og godkendt de aftalte FDD'er og TDD'er. Det forudsættes, at de nødvendige tekniske installationer og AX 2012-miljøer er på plads, inden development-fasen igangsættes. 2.2.12 Teknik/infrastruktur 2.2.12.1 Formål Målet under development-fasen på området Teknik/infrastruktur er at sikre kvaliteten af de tekniske installationer og infrastrukturen. 2.2.12.2 Nøgleleverancer Nøgleleverancer fra EG på området Teknik/infrastruktur er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. Tabel 26: Nøgleleverancer på området Teknik/infrastruktur QA Rådgivning Teknisk projektledelse Tek_Infras Sikring tværfaglig koordinering samt spor relevant QA arbejde Fælles ERP-sekretariat skal sikre at EG'S teknisk ekspert indgår i relevante møder samt får relevant in- Tek_Infras formation Tek_Infras Fælles ERP-sekretariat skal ifm installation samt igangsætning have en teknisk projektleder som sammen med EG's tilsvarende få disse opgaver løst Status: Endelig Side: 59 af 76

2.2.12.3 Hovedoutput Hovedoutput på området Teknik/infrastruktur består af følgende: Rådgivning og QA. 2.2.12.4 Forudsætninger Følgende forudsætninger er gældende på området Teknik/infrastruktur: Det forudsættes, at EG's tekniske ekspert deltager i relevante møder og får relevant information. 2.2.13 Data migration 2.2.13.1 Formål Målet under development-fasen på området Data migration er at udarbejde relevante TDD'er på området. Med udgangspunkt i Konverteringsstrategien, FDD og TDD skal der laves konfiguration og udvikling af tilpasninger til de identificerede datamigrationer. Test af data og migration af disse skal foretages i denne fase, jf. anbefalingerne i Konverteringsstrategien med henblik på godkendelse af konfiguration, opsætning og tilpasninger. Det er afgørende, at der foretages grundig kontrol af data, herunder ikke blot selve migrationskørslerne, men også kvaliteten af de data, der kommer fra eksisterende systemer. 2.2.13.2 Nøgleleverancer Nøgleleverancer fra EG på området Data migration er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. For yderligere detaljer på området henvises der til Konverteringsstrategien. Tabel 27: Nøgleleverancer på området Data migration Finanssaldo specifikation Finanssaldo Transaktions finans Åbne kreditor poster Åbne debitor poster (fritekst) Konverteringstabel Historisk Finanslovstabel Datakonv Datakonv Datakonv Datakonv Datakonv Datakonv Datakonv Fælles ERP-sekretariat skal sikre, at GS og kommunerne foretager afstemning i denne fase. Fælles ERP-sekretariat skal sikre, at GS og kommunerne foretager afstemning i denne fase. Fælles ERP-sekretariat skal sikre, at GS og kommunerne foretager afstemning i denne fase. Fælles ERP-sekretariat skal sikre, at GS og kommunerne foretager afstemning i denne fase. Fælles ERP-sekretariat skal sikre, at GS og kommunerne foretager afstemning i denne fase. Fælles ERP-sekretariat skal sikre, at GS og kommunerne foretager afstemning i denne fase. Fælles ERP-sekretariat skal sikre, at GS og kommunerne foretager afstemning i denne fase. Status: Endelig Side: 60 af 76

Datavask bistand QA/Koordinering 2.2.13.3 Hovedoutput Datakonv Datakonv Fælles ERP-sekretariat skal udarbejde datavask tjekliste. ERP skal foretage evt. datavask via udarbejdet tjekliste. Sikring tværfaglig koordinering samt spor relevant QA arbejde Hovedoutput på området Data migration består af følgende: Udarbejdelse af X antal TDD'er (afhængigt af antal gaps på området) Udvikling af tilpasninger Test og godkendelse af opsætning, konfiguration og tilpasninger (herunder integrationer) Test af datakvalitet Sikring af valide data. 2.2.13.4 Forudsætninger Følgende forudsætninger er gældende på området Data migration: Det forudsættes, at der i designfasen er udarbejdet og godkendt de aftalte FDD'er og TDD'er. Det forudsættes, at de nødvendige tekniske installationer og AX 2012-miljøer er på plads, inden development-fasen igangsættes. Det forudsættes, at rensning af data, der skal migreres er foretaget inden migrering. 2.2.14 Integrationsstrategi 2.2.14.1 Formål Målet under development-fasen på området Integrationsstrategi er at udarbejde TDD'er for hver integration, der er identificeret. Med udgangspunkt i Integrationsstrategien, FDD og TDD skal integrationerne udvikles i denne fase. Desuden skal der foretages test af hver integration med henblik på godkendelse. Det er afgørende, at der foretages grundig test af integrationer, da de er en vigtig komponent i løsningslandskabet. 2.2.14.2 Nøgleleverancer Nøgleleverancer fra EG på området Integrationsstrategi er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. For yderligere detaljer på området henvises der til Integrationsstrategien. Status: Endelig Side: 61 af 76

Tabel 28: Nøgleleverancer på området Integrationsstrategi Winformatik Løn Banking Stamdata XAL - integrationer E-skat Finansintegration service Debitor integration service Kreditor integration service Stamdata opdatering Int Int Int Int Int Int Int Int Int Int Fælles ERP-sekretariat skal bistå med afklaring samt sikre eksterne interessenter er tilstede på de aftalte tidspunkter. ERP skal desuden sikre sig at de beskrevne integrationer er udarbejdet i systemlandskabet Fælles ERP-sekretariat skal bistå med afklaring og sikre, at eksterne interessenter er til stede på de aftalte tidspunkter. Fælles ERP-sekretariat skal desuden sikre sig, at de beskrevne integrationer er udarbejdet i systemlandskabet. Fælles ERP-sekretariat skal bistå med afklaring samt sikre eksterne interessenter er tilstede på de aftalte tidspunkter. ERP skal desuden sikre sig at de beskrevne integrationer er udarbejdet i systemlandskabet Fælles ERP-sekretariat skal bistå med afklaring og sikre, at eksterne interessenter er til stede på de aftalte tidspunkter. Fælles ERP-sekretariat skal desuden sikre sig, at de beskrevne integrationer er udarbejdet i systemlandskabet. Fælles ERP-sekretariat skal bistå med afklaring samt sikre eksterne interessenter er tilstede på de aftalte tidspunkter. ERP skal desuden sikre sig at de beskrevne integrationer er udarbejdet i systemlandskabet Fælles ERP-sekretariat skal bistå med afklaring samt sikre eksterne interessenter er tilstede på de aftalte tidspunkter. ERP skal desuden sikre sig at de beskrevne integrationer er udarbejdet i systemlandskabet Fælles ERP-sekretariat skal bistå med afklaring samt sikre eksterne interessenter er tilstede på de aftalte tidspunkter. ERP skal desuden sikre sig at de beskrevne integrationer er udarbejdet i systemlandskabet Fælles ERP-sekretariat skal bistå med afklaring samt sikre eksterne interessenter er tilstede på de aftalte tidspunkter. ERP skal desuden sikre sig at de beskrevne integrationer er udarbejdet i systemlandskabet Fælles ERP-sekretariat skal bistå med afklaring samt sikre eksterne interessenter er tilstede på de aftalte tidspunkter. ERP skal desuden sikre sig at de beskrevne integrationer er udarbejdet i systemlandskabet Fælles ERP-sekretariat skal bistå med afklaring samt sikre eksterne interessenter er tilstede på de aftalte tidspunkter. ERP skal desuden sikre sig at de beskrevne integrationer er udarbejdet i systemlandskabet Status: Endelig Side: 62 af 76

Integrationskoordinering Design struktur QA/Crashtest Business Care services (5 nye) Integrationsalert / workflow 2.2.14.3 Hovedoutput Int Int Int Int Int Fælles ERP-sekretariat skal sikre at EG's integrationsekspert indgår i relevante møder med eksterne interessenter samt sikre at disse er til stede når udvikling/test er i gang. Fælles ERP-sekretariat skal bistå med viden hvis behov opstår Sikring tværfaglig koordinering samt spor relevant QA arbejde Fælles ERP-sekretariat skal bistå med afklaring såfremt der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Hovedoutput på området Integrationsstrategi består af følgende: Udarbejdelse af X antal TDD'er (afhængigt af antal gaps på området) Udvikling af tilpasninger Test og godkendelse af opsætning, konfiguration og tilpasninger (herunder integrationer). 2.2.14.4 Forudsætninger Følgende forudsætninger er gældende på området Integrationsstrategi: Det forudsættes, at der i designfasen er udarbejdet og godkendt de aftalte FDD'er og TDD'er. Det forudsættes, at de nødvendige tekniske installationer og AX 2012-miljøer er på plads, inden development-fasen igangsættes. Det forudsættes, at de systemer der skal integreres til kan levere de nødvendige data 2.2.15 Stamdata 2.2.15.1 Formål Målet under development-fasen på Stamdata-sporet er at udarbejde TDD'er for hver integration, der er identificeret. Desuden skal der ydes rådgivning og bistand i forbindelse med opsætning af stamdata. Med udgangspunkt i dokumentet "Model til styring af stamdata", FDD og TDD skal integrationerne udvikles i denne fase. Desuden skal der foretages test af hver integration med henblik på godkendelse. Det er afgørende, at der foretages grundig test af integrationer, da de er en vigtig komponent i løsningslandskabet. 2.2.15.2 Nøgleleverancer Nøgleleverancer fra EG på Stamdata-området er grupperet og beskrevet i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. For yderligere detaljer på området henvises der til dokumentet "Model til styring af stamdata". Status: Endelig Side: 63 af 76

Tabel 29: Nøgleleverancer på Stamdata-området CPR - GAB mapping GER - GAB mapping Stamdata bistand QA/Koordinering Stam Stam Stam Stam Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. Fælles ERP-sekretariat skal bistå med afklaring, hvis der opstår behov. ERP skal forestå dataudtræk samt evt. oprydning iflg beskrivelser. ERP skal sikre at GS samt kommunerne har de informationer til rådighed. Sikring tværfaglig koordinering samt spor relevant QA arbejde 2.2.15.3 Hovedoutput Hovedoutput på Stamdata-området består af følgende: Udarbejdelse af X antal TDD'er (afhængigt af antal gaps på området) Udvikling af tilpasninger Test og godkendelse af opsætning, konfiguration og tilpasninger (herunder integrationer). 2.2.15.4 Forudsætninger Følgende forudsætninger er gældende på Stamdata-området: Det forudsættes, at der i designfasen er udarbejdet og godkendt de aftalte FDD'er og TDD'er. Det forudsættes, at de nødvendige tekniske installationer og AX 2012-miljøer er på plads, inden development-fasen igangsættes. Det forudsættes, at de offentlige registre, der skal integreres til, kan levere de nødvendige data. 2.3 Deployment-fasen Deployment-fasen omfatter primært uddannelse af brugere og koordinering vedrørende kvalitetssikring af løsningen. Kundens funktionstest og flowtest af løsningen er også en væsentlig del af fasen med support fra EG. Aktiviteter omkring Go-Live aktiviter samt tilhørende planer udarbejdes i denne fase. Der er ikke medtaget aktiviteter efter idriftsættelse. Der foretages test af løsninger jf. bilag 8a. Status: Endelig Side: 64 af 76

2.3.1 Finans 2.3.1.1 Formål Målet under på Finans-området er at gennemføre brugeruddannelse og yde support vedrørende flowtest af løsningen. 2.3.1.2 Nøgleleverancer Nøgleleverancer fra EG på Finans-området er vist i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. Tabel 30: Nøgleleverancer på Finans-området Træning 2 kurser Testsupport QA/koordinering Fin Fin Fin Fælles ERP-sekretariat skal stille med relevante superbrugere til deltagelse i kurset. Deltagerantal på alle kurser er 6 personer. Fælles ERP-sekretariat skal udføre test af funktioner og flow i henhold til testbeskrivelsesdokument. EG bistår med support, hvis elementer ikke fungerer såfremt Fælles ERP-sekretariat pga manglende uddannelse eller viden ikke kan foretage den nødvendige test vil dette kræve en change for at sikre niveau. Sikring af tværfaglig koordinering samt sporrelevant QAarbejde. 2.3.1.3 Hovedoutput Hovedoutput på Finans-området består af følgende: nemført superbrugeruddannelse Dokumenteret flowtest. 2.3.1.4 Forudsætninger Følgende forudsætninger er gældende på Finans-området: Det forudsættes, at EG bliver inddraget i relevante møder/workshops vedrørende løsningen for at kunne yde den rette support/sparring. Det forudsættes, at kunden stiller med relevante superbrugere til planlagte uddannelsesworkshops. Status: Endelig Side: 65 af 76

2.3.2 Debitor 2.3.2.1 Formål Målet under deployment-fasen på Debitor-området er at gennemføre brugeruddannelse og yde support vedrørende flowtest af løsningen. 2.3.2.2 Nøgleleverancer Nøgleleverancer fra EG på Debitor-området er vist i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. Tabel 31: Nøgleleverancer på Debitor-området Træning 2 kurser Testsupport QA Deb Deb Deb Fælles ERP-sekretariat skal stille med relevante superbrugere til deltagelse i kurset. Deltagerantal på alle kurser er 6 personer. Fælles ERP-sekretariat skal udføre test af funktioner og flow i henhold til testbeskrivelsesdokument. EG bistår med support, hvis elementer ikke fungerer. Sikring af tværfaglig koordinering samt sporrelevant QAarbejde. 2.3.2.3 Hovedoutput Hovedoutput på Debitor-området består af følgende: nemført superbrugeruddannelse Dokumenteret flowtest. 2.3.2.4 Forudsætninger Følgende forudsætninger er gældende på Debitor-området: Det forudsættes, at EG bliver inddraget i relevante møder/workshops vedrørende løsningen for at kunne yde den rette support/sparring. Det forudsættes, at kunden stiller med relevante superbrugere til planlagte uddannelsesworkshops. 2.3.3 Kreditor 2.3.3.1 Formål Målet under deployment-fasen på Kreditor-området er at gennemføre brugeruddannelse og yde support vedrørende flowtest af løsningen. Status: Endelig Side: 66 af 76

2.3.3.2 Nøgleleverancer Nøgleleverancer fra EG på Kreditor-området er vist i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. Tabel 32: Nøgleleverancer på Kreditor-området Træning 2 kurser Testsupport QA Kre Kre Kre Fælles ERP-sekretariat skal stille med relevante superbrugere til deltagelse i kurset. Deltagerantal på alle kurser er 6 personer. Fælles ERP-sekretariat skal udføre test af funktioner og flow i henhold til testbeskrivelsesdokument. EG bistår med support, hvis elementer ikke fungerer. Sikring af tværfaglig koordinering samt sporrelevant QAarbejde. 2.3.3.3 Hovedoutput Hovedoutput på Kreditor-området består af følgende: nemført superbrugeruddannelse Dokumenteret flowtest. 2.3.3.4 Forudsætninger Følgende forudsætninger er gældende på Kreditor-området: Det forudsættes, at EG bliver inddraget i relevante møder/workshops vedrørende løsningen for at kunne yde den rette support/sparring. Det forudsættes, at kunden stiller med relevante superbrugere til planlagte uddannelsesworkshops. 2.3.4 ttestyrelsen 2.3.4.1 Formål Målet under deployment-fasen på området ttestyrelsen er at gennemføre brugeruddannelse og yde support vedrørende flowtest af løsningen på områder, der er specifikke for ttestyrelsens processer. 2.3.4.2 Nøgleleverancer Nøgleleverancer fra EG på området ttestyrelsen er vist i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. Status: Endelig Side: 67 af 76

Tabel 33: Nøgleleverancer på området ttestyrelsen Træning 2 kurser Testsupport QA/koordinering Fælles ERP-sekretariat skal stille med relevante superbrugere til deltagelse i kurset. Deltagerantal på alle kurser er 6 personer. Fælles ERP-sekretariat skal udføre test af funktioner og flow i henhold til testbeskrivelsesdokument. EG bistår med support, hvis elementer ikke fungerer. Sikring af tværfaglig koordinering samt sporrelevant QAarbejde. 2.3.4.3 Hovedoutput Hovedoutput på området ttestyrelsen består af følgende: nemført superbrugeruddannelse Dokumenteret flowtest. 2.3.4.4 Forudsætninger Følgende forudsætninger er gældende på området ttestyrelsen: Det forudsættes, at EG bliver inddraget i relevante møder/workshops vedrørende løsningen for at kunne yde den rette support/sparring. Det forudsættes, at kunden stiller med relevante superbrugere til planlagte uddannelsesworkshops. 2.3.5 Budgettering og budgetopfølgning 2.3.5.1 Formål Målet under deployment-fasen på området Budgettering og budgetopfølgning er at gennemføre brugeruddannelse og yde support vedrørende flowtest af løsningen. 2.3.5.2 Nøgleleverancer Nøgleleverancer fra EG på området Budgettering og budgetopfølgning er vist i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. Status: Endelig Side: 68 af 76

Tabel 34: Nøgleleverancer på området Budgettering og budgetopfølgning Træning 2 kurser Testsupport QA/koordinering Bud Bud Bud Fælles ERP-sekretariat skal stille med relevante superbrugere til deltagelse i kurset. Deltagerantal på alle kurser er 6 personer. Fælles ERP-sekretariat skal udføre test af funktioner og flow i henhold til testbeskrivelsesdokument. EG bistår med support, hvis elementer ikke fungerer. Sikring af tværfaglig koordinering samt sporrelevant QAarbejde. 2.3.5.3 Hovedoutput Hovedoutput på området Budgettering og budgetopfølgning består af følgende: nemført superbrugeruddannelse Dokumenteret flowtest. 2.3.5.4 Forudsætninger Følgende forudsætninger er gældende på området Budgettering og budgetopfølgning: Det forudsættes, at EG bliver inddraget i relevante møder/workshops vedrørende løsningen for at kunne yde den rette support/sparring. Det forudsættes, at kunden stiller med relevante superbrugere til planlagte uddannelsesworkshops. 2.3.6 Finanslov/bevillinger 2.3.6.1 Formål Målet under deployment-fasen på området Finanslov/bevillinger er at gennemføre brugeruddannelse og yde support vedrørende flowtest af løsningen. 2.3.6.2 Nøgleleverancer Nøgleleverancer fra EG på området Finanslov/bevillinger er vist i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. Status: Endelig Side: 69 af 76

Tabel 35: Nøgleleverancer på området Finanslov/bevillinger Træning 2 kurser Testsupport QA/koordinering FinLov FinLov FinLov Fælles ERP-sekretariat skal stille med relevante superbrugere til deltagelse i kurset. Deltagerantal på alle kurser er 6 personer. Fælles ERP-sekretariat skal udføre test af funktioner og flow i henhold til testbeskrivelsesdokument. EG bistår med support, hvis elementer ikke fungerer. Sikring af tværfaglig koordinering samt sporrelevant QAarbejde. 2.3.6.3 Hovedoutput Hovedoutput på området Finanslov/bevillinger består af følgende: nemført superbrugeruddannelse Dokumenteret flowtest. 2.3.6.4 Forudsætninger Følgende forudsætninger er gældende på området Finanslov/bevillinger: Det forudsættes, at EG bliver inddraget i relevante møder/workshops vedrørende løsningen for at kunne yde den rette support/sparring. Det forudsættes, at kunden stiller med relevante superbrugere til planlagte uddannelsesworkshops. 2.3.7 Ressortændringer 2.3.7.1 Formål Målet under deployment-fasen på området Ressortændringer er at gennemføre brugeruddannelse og yde support vedrørende flowtest af løsningen. 2.3.7.2 Nøgleleverancer Nøgleleverancer fra EG på området Ressortændringer er vist i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. Status: Endelig Side: 70 af 76

Tabel 36: Nøgleleverancer på området Ressortændringer Testsupport QA Res Res Fælles ERP-sekretariat skal udføre test af funktioner og flow i henhold til testbeskrivelsesdokument. EG bistår med support, hvis elementer ikke fungerer. Sikring af tværfaglig koordinering samt sporrelevant QAarbejde. 2.3.7.3 Hovedoutput Hovedoutput på området Ressortændringer består af følgende: nemført superbrugeruddannelse Dokumenteret flowtest. 2.3.7.4 Forudsætninger Følgende forudsætninger er gældende på området Ressortændringer: Det forudsættes, at EG bliver inddraget i relevante møder/workshops vedrørende løsningen for at kunne yde den rette support/sparring. Det forudsættes, at kunden stiller med relevante superbrugere til planlagte uddannelsesworkshops. 2.3.8 Std. Ledelsesinformation 2.3.8.1 Formål Målet under deployment-fasen på området Std. Ledelsesinformation er at gennemføre brugeruddannelse og yde support vedrørende flowtest af Management Reporter-løsningen. 2.3.8.2 Nøgleleverancer Nøgleleverancer fra EG på området Std. Ledelsesinformation er vist i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. Tabel 37: Nøgleleverancer på området Std. Ledelsesinformation QA LedInf Sikring af tværfaglig koordinering samt sporrelevant QAarbejde. Status: Endelig Side: 71 af 76

2.3.8.3 Hovedoutput Hovedoutput på området Std. Ledelsesinformation består af følgende: nemført superbrugeruddannelse Dokumenteret flowtest. 2.3.8.4 Forudsætninger Følgende forudsætninger er gældende på området Std. Ledelsesinformation: Det forudsættes, at EG bliver inddraget i relevante møder/workshops vedrørende løsningen for at kunne yde den rette support/sparring. Det forudsættes, at kunden stiller med relevante superbrugere til planlagte uddannelsesworkshops. 2.3.9 Intern revision 2.3.9.1 Formål Målet under deployment-fasen på området Intern revision er at gennemføre brugeruddannelse og yde support vedrørende flowtest af løsningen. 2.3.9.2 Nøgleleverancer Nøgleleverancer fra EG på området Intern revision er vist i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. Tabel 38: Nøgleleverancer på området Intern revision Træning 1 kursus Testsupport QA IntRev IntRev IntRev Fælles ERP-sekretariat skal stille med relevante superbrugere til deltagelse i kurset. Deltagerantal på alle kurser er 6 personer. Fælles ERP-sekretariat skal udføre test af funktioner og flow i henhold til testbeskrivelsesdokument. EG bistår med support, hvis elementer ikke fungerer. Sikring af tværfaglig koordinering samt sporrelevant QAarbejde. 2.3.9.3 Hovedoutput Hovedoutput på området Intern revision består af følgende: nemført superbrugeruddannelse Dokumenteret flowtest. Status: Endelig Side: 72 af 76

2.3.9.4 Forudsætninger Følgende forudsætninger er gældende på området Intern revision:' Det forudsættes, at EG bliver inddraget i relevante møder/workshops vedrørende løsningen for at kunne yde den rette support/sparring. Det forudsættes, at kunden stiller med relevante superbrugere til planlagte uddannelsesworkshops. 2.3.10 Projekt/anlæg N/A. 2.3.11 erelt 2.3.11.1 Formål Målet under deployment-fasen på området erelt er at gennemføre brugeruddannelse og yde support vedrørende flowtest af løsningen. 2.3.11.2 Nøgleleverancer Nøgleleverancer fra EG på området erelt er vist i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i tabel 3. Tabel 39: Nøgleleverancer på området erelt Basis konfiguration AMC Lasernet HR Organisation Medarbejdere EGVI Crosswork Bank Fælles ERP-sekretariat skal foretage godkendelse af konfiguration ifm deres systemtest Fælles ERP-sekretariat skal foretage godkendelse af konfiguration ifm deres systemtest Fælles ERP-sekretariat skal foretage godkendelse af konfiguration ifm deres systemtest Fælles ERP-sekretariat skal foretage godkendelse af konfiguration ifm deres systemtest Fælles ERP-sekretariat skal foretage godkendelse af konfiguration ifm deres systemtest Fælles ERP-sekretariat skal foretage godkendelse af konfiguration ifm deres systemtest Fælles ERP-sekretariat skal foretage godkendelse af konfiguration ifm deres systemtest Fælles ERP-sekretariat skal foretage godkendelse af konfiguration ifm deres systemtest Fælles ERP-sekretariat skal foretage godkendelse af konfiguration ifm deres systemtest Status: Endelig Side: 73 af 76

AIF GDM TM1 Sharepoint Roller 10 stk Funktionsrettigheder Adgangsbegrænsninger Sparring (eks.) Fælles ERP-sekretariat skal foretage godkendelse af konfiguration ifm deres systemtest Fælles ERP-sekretariat skal foretage godkendelse af konfiguration ifm deres systemtest Fælles ERP-sekretariat skal foretage godkendelse af konfiguration ifm deres systemtest Fælles ERP-sekretariat skal foretage godkendelse af konfiguration ifm deres systemtest Fælles ERP-sekretariat skal foretage godkendelse af konfiguration ifm deres systemtest Fælles ERP-sekretariat skal foretage godkendelse af konfiguration ifm deres systemtest Fælles ERP-sekretariat skal foretage godkendelse af konfiguration ifm deres systemtest ERP skal sikre at EG bliver inddraget i møder/workshop mm som påvirker den struktur samt løsning der er foreslået. QA Sikring tværfaglig koordinering samt spor relevant QA arbejde 2.3.11.3 Hovedoutput Hovedoutput på området erelt består af følgende: nemført superbrugeruddannelse Dokumenteret flowtest. Status: Endelig Side: 74 af 76

2.3.11.4 Forudsætninger Følgende forudsætninger er gældende på området erelt: Det forudsættes, at EG bliver inddraget i relevante møder/workshops vedrørende løsningen for at kunne yde den rette support/sparring. Det forudsættes, at kunden stiller med relevante superbrugere til planlagte uddannelsesworkshops. 2.3.12 Teknik/infrastruktur Der henvises til afsnit 2.2.12. 2.3.13 Data migration 2.3.13.1 Formål Målet under deployment-fasen på området Data migration er udelukkende at kvalitetssikre sporet via rådgivning og koordinering. 2.3.13.2 Nøgleleverancer Nøgleleverancer fra EG på området Data migration er vist i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. Tabel 40: Nøgleleverancer på området Data migration QA/koordinering Datakonv Sikring af tværfaglig koordinering samt sporrelevant QAarbejde. 2.3.13.3 Hovedoutput N/A. 2.3.13.4 Forudsætninger N/A. 2.3.14 Integrationsstrategi N/A. Status: Endelig Side: 75 af 76

2.3.15 Stamdata 2.3.15.1 Formål Målet under deployment-fasen på Stamdata-området er udelukkende at kvalitetssikre sporet via rådgivning og koordinering. 2.3.15.2 Nøgleleverancer Nøgleleverancer fra EG på Stamdata-området er vist i nedenstående tabel. EG's forpligtelser i forbindelse med de enkelte leverancer på området er beskrevet i bilag 3. Tabel 41: Nøgleleverancer på Stamdata-området QA/Koordinering Stam Sikring tværfaglig koordinering samt spor relevant QA arbejde 2.3.15.3 Hovedoutput N/A. 2.3.15.4 Forudsætninger N/A. Status: Endelig Side: 76 af 76