Statement of Work (SOW) Overall

Statement of Work (SOW) Overall Version 1.0 Status: Endelig Side: 1 af 19

Indholdsfortegnelse 1 Indledning... 4 2 Projektmål, rammer og scope... 5 2.1 Formål... 5 2.2 Projektets rammer... 8 2.3 Scope... 10 2.3.1 Lokationer... 12 2.3.2 Acceptkriterier kvalitet og test... 12 2.4 Områder Out of scope... 13 3 Projektstrategi, tidsplan og serviceleverancer... 13 3.1 Projektstrategi... 13 3.2 Tidsplan... 15 3.2.1 Baggrund og forudsætninger for tidsplan... 16 3.3 Projektledelsesstrategi... 16 4 Projektorganisation og bemanding... 17 4.1 Projektorganisationsstruktur... 17 4.2 Projektroller og -ansvar... 17 4.3 Styregruppe... 17 5 Generelt ERP-ansvar og projektforudsætninger... 17 5.1 Leverandører og underleverandører... 17 5.2 Projektforudsætninger... 17 Status: Endelig Side: 2 af 19

Versionshistorik Dato Version Udarbejdet af Godkendt af Beskrivelse 20.05.2015 1.0 Ole Malthe Dokument oprettet 29.05.2015 1.0 Bente Søgaard Korrekturrettelser 29.05.2015 1.0 Ole Malthe Færdigskrevet 04.06.2015 1.0 Palle Liebe Review og endelig version. Status: Endelig Side: 3 af 19

1 Indledning Denne SOW repræsenterer den komplette plan for rammer, serviceydelser, serviceleverancer og godkendelse for alle aktiviteter overordnet set, der udføres under Design- (design), Development- (opsætning og tilpasning) og Deploymentfasen (implementering og uddannelse). Alle ændringer i dette dokument vil blive forvaltet i overensstemmelse med Change Management-processen. Ud over nærværende SOW er der udformet en specifik SOW for henholdsvis Business Case Implementation (BCI) og for selve ERP-delen. Grønlands Selvstyre (GS) og de 4 kommuner Kommuneqarfik Sermersooq (SER), Kommune Kujalleq (KU), Qeqqata Kommune (QE) og Qaasuitsup Kommunia (QA) har indgået en projektsamarbejdsaftale vedrørende gennemførelsen af det fællesoffentlige ERP-projekt benævnt ERP Pisariillisaaneq (ERP). Derudover deltager KANUKOKA (KAN), som er en interesseorganisation for de grønlandske kommuner, betegnet som De Grønlandske Kommuners Landsforening. De 4 kommuner benævnes i nærværende dokument enten med en fællesbetegnelse (KOM) eller med de benævnelser, som fremgår ovenfor som fx (QA). Projektsamarbejdsaftalen er underskrevet af de 5 offentlige instanser de 4 kommuner og GS. Formålet med den indgåede samarbejdsaftale er at sikre et godt grundlag for at gennemføre det fællesoffentlige ERP-projekt, jf. projektets businesscase og leveranceplaner. Parterne har vurderet, at samarbejdet og projektet har en så høj risiko qua projektets kompleksitet og udbredelse, at en decideret aftale er berettiget. Aftalen ophører, når projektet er gennemført. De 5 offentlige instanser har til gennemførelse af ERP-projektet etableret sig med en Styregruppe, der har konstitueret Departementschef Peter Hansen som formand, og som i øvrigt består af repræsentanter fra KOM, KAN og GS. Til varetagelse af opgaver er der etableret et fælles sekretariat benævnt Fælles ERPsekretariatet som p.t. er placeret i GS' lokalitet i Nuuk. Det er henholdsvis KOM's og GS' projektorganisationer, der har ansvaret for, at der sker rettidig levering af de ydelser, som ERP-kontrakten kræver. Fælles ERP-sekretariatet er det daglige omdrejningspunkt i fremdriften af projektet. EG A/S (EG) har gennem mange år haft et tæt samarbejde med GS om udvikling og vedligehold af GS' eksisterende ERP-system kaldet XAL. Samarbejdet blev etableret tilbage i efteråret 2001 gennem daværende thy-data A/S. De 4 kommuner har gennem de seneste mange år anvendt systemet Winformatik, der er specielt udviklet til kommunerne. Systemet er udviklet af KIMIK-IT A/S, som fortsat ligeledes vedligeholder og drifter systemet for kommunerne. Siden 2011 har projektet efter det oplyste været i et konstant og fremadrettet forløb, hvor der er gennemført en detaljeret og omfattende ide- og analysefase og anskaffelsesfase, hvor et fælles standardsystem Microsoft Dynamics AX 2012 benævnt AX 2012 er valgt. I anskaffelsesfasen valgte Styregruppen efter gennemførelse af en prækvalifikation og et udbud, at EG skulle forestå gennemførelsen af Afklaringsfasen. Status: Endelig Side: 4 af 19

Afklaringsfasen havde til formål at skabe forudsætningen for den økonomiske ramme, der fremlægges for KOM og Naalakkersuisut til politisk godkendelse i maj 2015 og til endelig beslutning i den Politiske Koordinationsgruppe i juni 2015. Hvis beslutningen i juni måned om igangsættelse af Gennemførelsesfasen er positiv, starter fasen i august 2015 med en forventet idriftsættelse i 3. kvartal 2016. Både det hidtidige forløb siden 2011 og det fremtidige forventede forløb frem til Gennemførelsesfasen kan overordnet sammenfattes således: Parallelt med dette skal dette projekt sikre implementeringen af den businesscase, der er udarbejdet under Business analysis (se bilag 3a). Ligeledes skal det understøtte den change management, der skal ske parallelt med ERP-projektet. 2 Projektmål, rammer og scope 2.1 Formål Projektet har sit udspring i ambitionerne fra Strukturreformen, der tilbage i 2005 anbefalede: En fælles platform for alle offentlige systemer Fælles standarder og rammer for kommende offentlige it-projekter Et sammenhængende administrativt system for hele den offentlige sektor Fælles standarder for programmer. Strukturreformen blev efterfølgende fulgt op af Budgetsamarbejdsaftalen mellem GS og KOM i 2013. I redegørelse bag Budgetsamarbejdsaftalen står der blandt andet: "Endvidere ønskes der fokus på effektmåling på alle væsentlige udgiftsområder. Desuden præciseres det, at incitamentsstrukturen skal understøtte de politiske målsætninger. Gennemgående i den fremlagte økonomiske politik er, at der skal være en ansvarlig økonomistyring og effektivisering i den offentlige sektor, som tilgodeser balancen mellem det korte og lange perspektiv, således at der vedvarende er holdbare løsninger" Projektet er en direkte udløber af disse ambitioner og har til formål " at modernisere og effektivisere den offentlige administration i Grønland ved at understøtte forretningsudviklingen med sammenhængende digitale løsninger, så bedre økonomistyring og ledelsesinformation kan opnås 1 ". Status: Endelig Side: 5 af 19

Systemunderstøttelsen af økonomistyringen i KOM og GS er i dag baseret på forskellige tekniske platforme. Det betyder bl.a., at det er vanskeligt at udveksle data mellem offentlige myndigheder, og at arbejdet er præget af mange manuelle processer, som med fordel kan effektiviseres. Det er vurderet, at de samlede gevinster for projektet er meget store, når man ser på driften af systemerne, effektiviseringen af processerne, kvalitetsforbedringer i ydelserne og ikke mindst evnen til at styre økonomien og skabe valide data til brug for beslutningsstøtte på både strategisk og politisk niveau. Af dokumentet Business Case for Pisariillisaaneq ERP-projektet dateret den 6. maj 2015 afsnit 6.1 Den nuværende situation (baggrund), afsnit 6.2. Formålet med projektets løsning og afsnit 6.3 Situationen hvis projektet ikke gennemføres (business as usual) fremgår følgende formål med projektet: "6.1 Den nuværende situation (baggrund) Projektet er initieret i et samarbejde mellem kommunerne, KANUKOKA og Grønlands Selvstyre i forsøget på at samle de offentlige kræfter om rammerne for fælles økonomistyring og fælles ledelsesinformation. Pisariillisaaneq er meget mere end et it-projekt, idet konsekvenserne af implementeringen vil kræve meget af de enkelte organisationer særligt i forhold til ledelsesmæssig vedholdenhed og opbakning. Pisariillisaaneq-projektet skal derfor mere ses som et organisationsprojekt end et it-projekt. Baggrunden for projektet er en erkendelse i kommunerne og Grønlands Selvstyre af, at der med de nuværende systemer er en række udfordringer, jf. projektkommissoriet. Svært at få tilstrækkelig og relevant ledelsesinformation Data- og sagsudveksling er kompliceret og tidskrævende Mange af de nuværende systemer understøtter ikke en digital forvaltning Der er behov for bedre økonomistyringsfaciliteter, end de nuværende systemer kan tilbyde Kritiske revisionsbemærkninger med hensyn til interne kontrolsystemer og dokumentationsniveau Stor mængde af forskellige delsystemer og selvstændige systemer. Manglende overblik over sammenhænge, dvs. mangel på strukturerede og koordinerede systemudviklinger og anskaffelser af nye separate systemer. 6.2 Formålet med projektets løsning I projektkommissoriet er der listet en række overordnede krav til, hvad et nyt økonomistyrings- og ledelsesinformationssystem skal bidrage med. Beskrivelse af komplikationen ved den nuværende situation: Det er helt centralt, at projektet koordineres med nedenstående projekter og initiativer: Grunddata-programmet: Struktur på registerforhold, således at landsdækkende registre opdateres struktureret, og at anvendelsen er ensartet og lovlig. (CPR + GER/CVR) Persondatalovens indførelse: Få de lovgivningsmæssige rammer tilpasset til, at fællessystemer kan anvendes. (PDL) Status: Endelig Side: 6 af 19

Beskrivelse af løsningsforslaget og de væsentligste gevinster (både økonomisk og kvalitativt): Når projektet er fuldført, vil der være opnået generelle gevinster på tværs af forretningsområder, og der vil være opnået omfattende gevinster i udvalgte funktionsområder. De overordnede gevinster vil være følgende: Overblik og gennemsigtighed, da man har tilstrækkelig ledelsesinformation Sammenhængende systemer og integrerede data vil føre til større effektivitet via økonomistyring Der vil være øget samarbejde på tværs af hele den offentlige forretning Der vil være større digitaliseringsparathed Ensartetheden i borgerbetjeningen vil være større og af bedre kvalitet Kontrolmulighederne vil være større, og dokumentationen vil være bedre, så der vil være færre revisionspåtegninger Der vil være styr på registre og data En øget deling af data på tværs af enheder Der ville kunne opnås effektiviseringer i den offentlige sektor generelt og på it-budgetterne specifikt. De mere specifikke gevinster kan opsummeres som følgende: Øget indkassering af motorafgifter (Selvstyret) Forbedret grundlag for udførelse af modregninger Korrekte priser og faktureringsgrundlag Reduktion af tab på debitorer Reduktion i portoudgifter Øget opkrævning af afgifter (Toldfunktionen) Sikrer priser og betaling af leverandørfakturaer Bedre disponeringsgrundlag. De specifikke områder, hvor der forventes frigivelse af ressourcer, kan opsummeres som følgende: Ressourcer til håndtering af motorafgifter (Selvstyret) Håndtering af faktureringsgrundlag og fakturering Effektivisering af ressourcer til udsendelser af rykkere, fakturaer m.m. Elektronisk håndtering af afgiftsanmeldelser (Toldfunktionen) Effektivisering af rykkerprocedurer Oprettelse af debitorer ud fra fælles stamdata Effektivisering af afstemningsprocesser Effektivisering af indbetalinger Optimeret tilgang til budgetopfølgning Effektivisering af udarbejdelse af finanslov/bevillinger Status: Endelig Side: 7 af 19

Elektronisk håndtering og godkendelse af leverandørfakturaer Processer og løsning for håndtering af løntræk og afdragsordninger (Selvstyret). 6.3 Situationen hvis projektet ikke gennemføres (business as usual) Såfremt man ikke foretager sig noget, må opmærksomheden henledes på, at det vil have følgende konsekvenser: Der arbejdes stadig med separate systemer og leverandøraftaler. Der opnås således hverken stordriftsfordele eller samarbejdsgevinster. Man vil fortsat mangle overblik og tilstrækkeligt kvalificeret ledelsesinformation, og det vil heller ikke være muligt at foretage de effektmålinger, som kan vise, om ressourcerne bruges hensigtsmæssigt. Analyse- og præsentationsmuligheder vil stadig afhænge af, at man har enkeltpersoner, som kan trække data over i Excel og lave de fornødne analyser og præsentationer. Der vil fortsat være problemer med dobbeltsystemer, manglende systemoverblik og manglende mulighed for at kontrollere data i systemerne. Problemerne omkring datafangst vil ikke blive løst, da de nuværende systemer ikke teknologisk er i stand til at håndtere dette. Digitaliseringsparatheden øges ikke, og dermed kan det være en bremseklods for de øvrige tiltag, som man er i gang med andre steder. Endelig er det helt essentielt, at mulighederne for effektmåling af strategiske tiltag ikke opnås, hvilket vil betyde, at man fortsat er henvist til subjektiv vurdering af strategiske tiltag." 2.2 Projektets rammer I dette afsnit redegøres for projektets rammer på et overordnet niveau. Kontrakten for projektet er baseret på Herbert Nathans ERP12-kontrakt med tilhørende bilag. Projektstyring i EG foregår i henhold til EG's projektledelsesmetode (EG PMM), og leverancen foregår i henhold til EG's leverancemodel One Delivery Model (ODM). EG ODM bygger på Microsofts Sure Step-metode og EG's best practice. De to metoder EG PMM (projektstyring) og EG ODM (leverance) er samtidig en del af kvalitetssikringen af projektet. Vedrørende EG's projektmodel henvises til ERP12-kontraktens bilag 8b. Detaljeret oversigt over EG PMMog EG ODM-metoderne ses nedenfor i figur 1. Status: Endelig Side: 8 af 19

Figur 1 EG PMM og EG ODM I december 2014 blev der indgået kontrakt om gennemførelse af Afklaringsfasen. I Afklaringsfasen er Business og Solution Analysis gennemført. Nærværende projekt dækker følgende ODM-faser: Det er forudsat, at der for alle interessenter i KOM og GS vil være én Designfase og én Developmentfase, men det endnu ikke er fastlagt, hvordan Deployment- og Operationsfasen skal foregå. Det forventes, at de enkelte interessenter i juni måned i forbindelse med beslutningen om gennemførelse af projektet tager stilling til tidspunkt for Go live for den enkelte interessent. Det forventes, at GS, formentlig sammen med SER, er den første interessent, der har Go live. Tidsplaner, der udarbejdes på nuværende tidspunkt, er således ikke vedtagne og godkendte tidsplaner, men udelukkende oplæg til, hvordan en mulig tids- og implementeringsplan kunne udformes. Det forventes at blive nærmere konkretiseret og udformet i løbet af juni måned og senest i Designfasen. I projektet indgår faserne, som er illustreret i figuren nedenfor, og som skal håndtere design, udvikling og implementering af løsning samt understøtte den organisatoriske implementering af en løsning baseret på Microsoft Dynamics AX Core-løsning hos både GS og KOM på forskellige lokationer. Lokationerne er beskrevet i bilag 10. Status: Endelig Side: 9 af 19

Modellen, der bliver arbejdet efter i projektet, ser således ud: Projektet dækkes med udarbejdelse af 3 "Statement of Work" (SOW). De 3 SOW'er er: 1. Bilag 3 Leverancebeskrivelse Overall (SOW) (dækkende generelle overordnede forhold) 2. Bilag 3a Leverancebeskrivelse BCI (SOW) (dækkende implementering af businesscase og change management) 3. Bilag 3b Leverancebeskrivelse ERP (SOW) (dækkende ERP-implementeringen) Tilsammen beskriver de 3 SOW'er, hvad EG leverer i projektet. 2.3 Scope Projektet er faseopdelt nærværende Overall SOW omfatter udelukkende fase 1. Status: Endelig Side: 10 af 19

Fase 1 Nedenstående AX 2012-funktionsområder er i scope og omfattet af nærværende projekt således: Budget Debitor Finans Finansloven Generelt Intern revision Kreditor til kreditorworkflow er der afsat en pulje på 100 timer til udvikling timer derudover håndteres med change management. Baseret på EGVI, som er et EG add-on til håndtering af flowløsning. Hvis dette ikke vælges, vil der være integrationer, som skal beskrives mellem det valgte system og AX 2012. Projekt-/anlægsstyring gennemførelse af Deep Dives og løsningsworkshop. Der er medtaget timer svarende til det som skal benyttes ved gennemførelse af afklaringen på området. Standard Ledelsesinformation Ressortomlægninger/organisationsændringer Skattestyrelsen Fælles stamdata. De enkelte funktionsområder betegnes som spor. For eksempel vil AX 2012 funktionsområde Finans omtales som Finans-sporet. Det er ligeledes gældende for øvrige områder af mere teknisk karakter. I bilag 3b, som der henvises til, beskrives scope for de enkelte spor mere specifikt. Status: Endelig Side: 11 af 19

Derudover er følgende områder af mere teknisk karakter i scope i fase 1: Teknik/infrastruktur NFR Infrastruktur i den gennemførte afklaringsfase blev det med en change aftalt, at NFR Infrastruktur blev overført til gennemførelse i Designfasen. Det betyder, at det første, der skal gennemføres på sporet, er en analyse, hvor output er et NFR-dokument. Derudover er ydelserne vedrørende Teknik/infrastruktur begrænset til, at EG beskriver krav til infrastruktursetup, mens det forventes, at tredjepart forestår installation af nødvendig infrastruktur. Datakonvertering Fælles stamdata Integrationer. Ovennævnte spor beskrives ligeledes mere specifikt i bilag 3b. Generelt henvises til beslutninger truffet på ERP-styregruppemøder, som kan findes i samarbejdsportalens mappe "090 Steering Committee", herunder vedrørende stamdata og konverteringssporene. MC-ydelser er nærmere beskrevet i bilag 3a, hvortil der henvises. Projektledelse gennemføres i henhold til EG's PMM-model. 2.3.1 Lokationer Lokationer for projektaktiviteter og uddannelse kan ses i bilag 10 afsnit f. 2.3.2 Acceptkriterier kvalitet og test Test- og kvalitetssikringsaktiviteter strækker sig fra Design- og Developmentfaserne hen over Deploymentfasen. Test- og kvalitetssikringsaktiviteter omfatter dels den af EG anvendte projekttilgang og metoder angivet i afsnit 2.2 Projektets rammer, dels udarbejdelse af testgrundlag og gennemførelse af konkrete tests af løsningen, jf. den af ERP-sekretariatet udarbejdede strategi for gennemførelse af tests. Tests kan ses i bilag 8a. Der vil endvidere blive udarbejdet en kvalitetsplan for projektet, jf. EG's PMM-metode som beskrevet i bilag 8b. EG's anvendte projekttilgang og metoder er beskrevet i bilag 8b. EG rådgiver om udarbejdelse af de aftalte teststrategier, mens ERP-sekretariatet udformer testdokumenter. Status: Endelig Side: 12 af 19

2.4 Områder Out of scope Følgende områder er ikke omfattet af fase 1 i projektet og er dermed Out of scope: Områderne 2 til 7 nævnt i "Pisarillisaaneq_rul1_7. Dokumentation (se bilag 4) Brugervejledninger udformes ikke af EG, såfremt disse kræves, udformer Fælles ERPsekretariatet. Driftshåndbog udformes ikke. Afledte tiltag og effekter ved løsningen og projektet grundet ny lovgivning, herunder Persondataloven, er generelt Out of scope. Konvertering af stamdata og transaktioner. Driftssupport er Out of scope, og systemsupport forventes håndteret af ERP's nuværende samarbejdspartnere. I forbindelse med næste fase skal det afstemmes, hvorvidt EG skal varetage 2. og 3. level support via AMS-setup (spoc-center). Derudover er der en række sporrelaterede elementer, som er Out of scope. Der henvises til bilag 3b, hvor disse er behandlet. 3 Projektstrategi, tidsplan og serviceleverancer 3.1 Projektstrategi Som anført i afsnit 2.2 anvendes EG's ODM-model som leverancemodel. For nærmere beskrivelse af modellen henvises til kontraktens bilag 8b. Figuren nedenfor viser faserne i ODM: ODM-faser Status: Endelig Side: 13 af 19

ODM indeholder to tilgange til Design og Development: ODM-alternativer 1. alternativ er den iterative tilgang, hvor design, tilpasning og test udføres i sprints. Det giver en agil tilgang til udvikling og medfører større involvering fra brugerside, som har den fordel, at brugerne gradvist introduceres til løsningen. Gennem dette arbejde vil det være muligt for ERP at give feedback til teamet, og det er muligt at opdatere/ændre scope gennem processen fremadrettet. Det første sprint er normalt en baseline opsætning af den besluttede standardfunktionalitet. Den agile metode betyder ikke, at ALT kan ændres. Der skal tages hensyn til overordnet scope og beslutninger, og estimater skal overholdes. Det er dog en mere procesorienteret tilgang, og tilbageløb af opgaver er lettere og accepteret. 2. alternativ er den traditionelle "vandfaldsudvikling", hvor alt er designet før tilpasning. Det medfører en høj effektivitet og indsigt i den komplette løsning fra begyndelsen, hvilket kan være vanskelig i store projekter. Den samlede løsning fastlægges i begyndelsen, hvorefter løsningen tilpasses, testes og godkendes under ét. Status: Endelig Side: 14 af 19

For projektets Design- og Developmentfase er valgt den iterative tilgang, som overordnet set ser således ud: Design-/Developmentfaser For nærmere beskrivelse af faserne henvises til bilag 8b. 3.2 Tidsplan Projektet bliver opdelt i faser og milepæle som beskrevet nedenfor. Denne tidslinje er kun en vurdering, som er baseret på vores nuværende planlægningsforudsætninger, og kan blive ændret i løbet af projektet. I tilfælde af at første milepæl Accept af kontrakt skubbes, vil planen som helhed blive skubbet i samme grad. Den overordnede milepælsplan for projektet sammenfattes i nedenstående figur og fremgår ligeledes af kontraktens bilag 1, hvortil der henvises. 1/7-15 Udrulningsfasen 1/5-16 - 31/8-16 Idriftsættelse Garantiperiode start 1/9-16 Design- & udviklingsfasen 1/8-15 - 30/4-16 Kontraktindgåelse Overtagelsesprøve Afsluttet og godkendt 31/8-16 Overordnet milepælsplan Driftsprøve Afsluttet og godkendt 1/10-16 Status: Endelig Side: 15 af 19

Der er på nuværende tidspunkt ikke udformet oplæg til den overordnede tidsplan. Denne vil blive udformet i opstarten af designfasen. 3.2.1 Baggrund og forudsætninger for tidsplan Baseret på dialog med ERP-sekretariatet er tidsplanen fra vores side vurderet således, at idriftsættelse kan foretages pr. 1. oktober 2016 ud fra følgende forudsætninger: Allokering af ressourcer til at køre sideløbende aktiviteter. Rettidig planlægning og kommunikation af indhold/emner på workshops (WS) og uddannelsesseancer, således at deltagerne kan forberede deltagelse dette for at sikre, at som minimum det planlagte indhold nås på hver seance. At projektdeltagerne betragter outputtet fra Afklaringsfasen i form af procesafgræsninger og procesbeslutninger som et fast udgangspunkt for implementeringen. Med andre ord skal det i videst muligt omfang undgås, at proces- og scope-beslutninger taget i Afklaringsfasen skal diskuteres og behandles igen. FRD og den kommende PBL er udgangspunktet for tidsplanen og estimater. Følgende områder er dog i forbindelse med ERP's review og godkendelse noteret til ekstra fokus og vurdering i Designfasen: Finanslov, herunder TM1 Skattestyrelsen Kreditorworkflow NFR-dokument (infrastruktur) overført fra Afklaringsfasen til Designfasen Hvilket fremgår af bilag 3b for det enkelte spor. "Hjemmeopgaver" fra de enkelte workshops og uddannelsesseancer skal færdiggøres inden for den aftalte deadline. At ERP-superbrugere og projektdeltagere i øvrigt anvender tid til selvtræning i applikationsforståelse og -anvendelse. Umiddelbar og direkte kommunikation i projektledelsen, hvis forudsætningerne er under pres uanset hvilken part. 3.3 Projektledelsesstrategi EG's projektledelsesmodel PMM følges. Der henvises til kontraktens bilag 8b, hvor denne er nærmere beskrevet. Status: Endelig Side: 16 af 19

4 Projektorganisation og bemanding 4.1 Projektorganisationsstruktur På nuværende tidspunkt i slutningen af Afklaringsfasen foreligger der et oplæg til organisationsstruktur, som fremgår af kontraktens bilag 10, hvortil der henvises. Der udestår således en nærmere beskrivelse af den organisationsstruktur, ERP vil have i projektet det skal fastlægges, inden projektet påbegyndes. Det må forventes, at der på EG's side sker tilpasning i organisationsplanen vedrørende sporansvarlig med tilførsel af yderligere ressourcer. 4.2 Projektroller og -ansvar Der henvises til kontraktens bilag 10, hvor en oversigt over projektroller og -ansvar fremgår. 4.3 Styregruppe Styregruppen har det overordnede ledelsestilsyn og den overordnede ledelse vedrørende nærværende projekt. Der henvises til kontraktens bilag 10, hvor styregruppens sammensætning, ansvar og opgaver er nærmere beskrevet. 5 Generelt ERP-ansvar og projektforudsætninger 5.1 Leverandører og underleverandører Ud over Microsoft, der leverer Dynamics AX, benyttes andre leverandører i projektet, der enten optræder som EG's underleverandører eller som leverandører til ERP. Begge kategorier kan underopdeles i leverandører af konsulentydelser og leverandører af softwareprodukter, dvs. tredjepartsprogrammer og AX-moduler. Leverandører af tredjepartsprogrammer og AX-moduler skal levere al kode til EG's udviklingsansvarlige. Medmindre det er aftalt, må ingen ud over EG programmere/ændre i systemerne i scope under denne SOW. Dette gælder også for bilag 3b. 5.2 Projektforudsætninger Serviceydelser, priser og leveringsplaner vedrørende nærværende projekt er baseret på følgende forudsætninger: Projektsuccesen afhænger af aktiv deltagelse fra øverste niveau under hele projektet. Status: Endelig Side: 17 af 19

For at opnå succes med projektet skal superbrugere involveres gennem alle projektets faser for at facilitere processer og opnå forståelse og for at finde den bedste løsning på alle forretningsmæssige processer. Det forudsættes, at standardfunktionalitet og "anbefalet praksis" passer til både KOM's og GS' behov i henhold til gap/fit-beslutninger på de enkelte processer i Afklaringsfasen. ERP-sekretariatet stiller 7 (junior) konsulenter til rådighed med henblik på bl.a. at agere projektassistenter for leverandørens konsulenter. Det vil typisk være dokumentationsopgaver, udarbejdelse af beslutningsreferater fra workshops og at spille en aktiv rolle i forbindelse med gennemførelse af tests o.l., som vil være deres primære opgaver. Leverandøren har til opgave at gennemse og godkende det producerede output og gøre opmærksom på, hvis kvaliteten af outputtet ikke er højt nok. Derigennem sikrer vi en overlevering af og ejerskab til projektet. I estimatet er der regnet med, at EG's konsulenter foretager en repræsentativ opsætning af systemet (test), og at Fælles ERP-sekretariatet efterfølgende forestår den fulde opsætning i det miljø, som vælges hertil, herunder udformning af den dokumentation, som ønskes. Tilstedeværelse af de rigtige kompetencer: Begge parter arbejder aktivt på at tilvejebringe de rigtige kompetencer til varetagelse af projektets aktiviteter. Parterne afstemmer løbende forventninger til, hvilke kompetencer der er behov for, og hvilke der kan tilvejebringes. Eventuel oplevelse af manglende kompetencer tages hurtigst muligt op med den anden part, og parterne arbejder sammen om at finde en løsning. Fælles ERP-sekretariatet og EG tager fælles initiativ til at uddanne hinanden gensidigt, hvor det er relevant. Fælles ERP-sekretariat uddanner leverandøren i forståelse af kundeorganisationen, og EG uddanner Fælles ERP-sekretariat i de metoder og værktøjer, som anvendes i projektet. Estimatet er baseret på, at parterne ligeledes har den nødvendige beslutningskompetence for gennemførelse af de aftalte aktiviteter. Tredjepartshåndtering, herunder eksterne rådgivere: Fælles ERP-sekretariat håndterer de interessenter, som deltager i eller påvirker og/eller påvirkes af projektet. Det gælder også eventuelle tredjeparter, som er aktør i projektet på Fælles ERP-sekretariats vegne. Styregruppen, Fælles ERP-sekretariat og EG's projektleder vurderer løbende, på hvilket niveau tredjeparter deltager i projektet. Meromkostninger, som skyldes manglende deltagelse fra Fælles ERP-sekretariatets underleverandører, fx Tele Greenland, afholdes af Fælles ERP-sekretariatet og håndteres via en Change Request. Leverandørens ydelser og ansvarsområder for områderne Integration, Masterdata og Konvertering vil blive specificeret i separate strategidokumenter. Disse strategier danner grundlag for de afgivne budgettal. Men overordnet er det antaget, at 80% af integrationerne er fil-baserede med kommunikation til eksisterende "Servicebus". Hvad angår Masterdata henvises til Masterdata-strategien. Med hensyn til datakonvertering er der indregnet timer til indlæsning af data i standard AX-format. Status: Endelig Side: 18 af 19

Træning Træningsstrategi og krav udformes af Fælles ERP-sekretariatet. Der er medtaget superbrugerkurser for 6 deltagere i 1 dag og 1 dags forberedelse. Kurset vil blive afholdt pr. område både inden for det faglige og det tekniske. Hvis det ud fra træningsstrategien ikke er dækkende, håndteres dette som en change. Træning vil blive efter princippet "Train the Trainer". Test Teststrategi og krav udformes af Fælles ERP-sekretariatet. Estimatet forudsætter, at EG rådgiver om udarbejdelse af teststrategi, men Fælles ERPsekretariat udformer. Under Development- og Deploymentfaserne gennemføres følgende testelementer, som beskrevet i bilag 8a. Igen her er det forudsat, at Fælles ERP-sekretariat udformer testmateriale, og at EG vejleder og foretager QA på det udarbejdede testmateriale i form af testscripts mv. Dokumentation Krav udformes af Fælles ERP-sekretariatet. Der er for nuværende ikke set detaljeret på dette, hvorfor bilag 4 endnu ikke er færdiggjort. Hvis alle kommuner ikke er med fra starten, skal der udformes en udrulningsplan, som sikrer, at disse kommuner kan fortsætte i eksisterende system, og eventuelle midlertidige integrationer fra Winformatik (overgangsfase) skal udarbejdes, hvilket ikke er medtaget i budgetoverslaget. Oprettelse af fiktive regnskaber til fordringshavere der udarbejdes et dokument, der beskriver, hvordan oprettelse af regnskaber foretages men Inkasso gør det selv. Kontoplaner skal foreligge i rette tid inden indgangen til Designfasen, jf. styregruppebeslutning af 11.02.2015. I risikologgen pkt. 44 er anført, at hovedprojektet ikke kan igangsættes, hvis der ikke foreligger en kontoplan. I den BC-infrastruktur, der er udarbejdet i Afklaringsfasen, anbefaler vi en 1 instans Dynamics AXløsning, hvor der udarbejdes offline løsninger, så data kan tilgås i tilfælde af afbrydelser i infrastrukturens kommunikationsforbindelser, hvilket vores estimater og tidsplaner har taget udgangspunkt i. Status: Endelig Side: 19 af 19