Åbne standarder, rammearkitekturen og fælles projekter

Transkript

1 Åbne standarder, rammearkitekturen og fælles projekter Whitepaper til Køge Kommune 12. august 2013 CONNECTING BUSINESS & TECHNOLOGY Whitepaper om fælleskommunal rammearkitektur, Køge Kommune-v1 Devoteam. Kopiering og distribution kun tilladt efter aftale med Devoteam A/S.

2 Indholdsfortegnelse 1. Indledning Metode Læsevejledning Baggrund og forudsætninger i Køge Kommune Køge Kommunes digitaliseringsstrategi Systemporteføljen og it-anskaffelser Principper for systemejerskab Værdiforståelsen i Køge Kommune Overblik over det fælles gods Baggrund og formål OIO - standardisering og arkitektur Den fællesoffentlige digitaliseringsstrategi Den fælleskommunale handlingsplan Rammearkitektur, it-arkitektur-principper og vejledninger De konkrete monopolbrud Projektfællesskaber Konklusion tre drivere for forandring Anbefalinger Anbefalinger vedr. SAPA Anbefalinger vedr. støttesystemer og Serviceplatform Anbefaling: Plan for genbrug af data Anbefaling om principper for deltagelse i projekter Forslag til handlingsplan Perspektivering Henvisninger OIO EA arbejdet Fælles strategier og planer Den fælleskommunale rammearkitektur Øvrigt relevant materiale

3 Liste over tabeller og figurer Tabel 1: Eksempler på digitaliseringsinitiativer i Køge Kommune... 5 Figur 1: Overblik over rammearkitekturen Figur 2: Rådhus-metafor for rammearkitekturen Figur 3: Køge Kommunes fremtidige systemlandskab i rammearkitekturen Figur 4: Overblik over SAPA-løsningen # v 1 2

4 1. Indledning Køge Kommune har siden 2010 arbejdet med udmøntningen af Den Fælleskommunale Digitaliseringsstrategi De fælleskommunale indsatsområder er indarbejdet i kommunens egen digitaliseringsstrategi, og der arbejdes på at styrke udmøntningen af de konkrete initiativer. Et af de fælleskommunale indsatsområder, der ønskes styrket, er sammenhængende it og konkurrence, der indeholder den fælleskommunale rammearkitektur. For at styrke arbejdet ønsker Køge Kommune et overblik over, hvordan det fælles gods bedst muligt kan skabe værdi for kommunen. Med fælles gods menes både den fælleskommunale rammearkitektur, de fælleskommunale og fællesoffentlige strategier, den fælles standardisering og de fælles projekter. Der er særligt fokus på at afdække de væsentligste drivere i det fælles gods, hvor Køge Kommune skal have særlig opmærksomhed. Ved drivere forstås her initiativer i det fælles gods, som 1) kan skabe stor værdi 2) er obligatoriske og kræver lokal handling, og/eller 3) er særligt risikofyldte, fx fordi de er forretningskritiske, rummer stor teknologisk eller organisatorisk kompleksitet, etc. Da analysen er foretaget for it-afdelingen, fokuseres på arkitektur- og standardiseringsmæssige aspekter af det fælles gods, og i mindre grad på den forretningsmæssige implementering. Køge Kommune ønsker konkrete anvisninger på dels, hvordan det fælles gods bedst muligt indarbejdes i kommunens anskaffelser, dels efter hvilke principper kommunen skal tilslutte sig og deltage i de fælles projekter. Opgaven omfatter ikke den egentlige it-drift, herunder netværk, servere, storage, sikkerhed, it-arbejdspladser mv Metode Devoteam har gennemgået relevant dokumentation i Køge Kommune og interviewet it-ledelsen for at kortlægge kommunens nuværende situation, forudsætninger og værdiforståelse. Devoteam har ligeledes gennemgået al relevant og offentligt tilgængelig information om det fælles gods, herunder strategier, rammearkitektur og projekter. Denne desk top research er suppleret dels af Devoteams omfattende viden fra deltagelse i # v 1 3

5 andre projekter og analyser, dels af interview med en række nøglepersoner omkring især den fælleskommunale rammearkitektur. Der er foretaget interview med: KOMBIT, der har ansvaret for rammearkitekturen og gennemfører monopoludbuddene af SAPA, ydelses- og sygedagpengesystemerne, samt Gentofte og Odense kommuner, der har særligt gode forudsætninger for at skabe værdi af det fælles gods, qua deres deltagelse i centrale projekter Læsevejledning Afsnit 2 tager udgangspunkt i Køge Kommunes aktuelle situation for at tegne et billede af kommunens forudsætninger for at få værdi af det fælles gods. Herefter sammenfatter afsnit 3 de fællesoffentlige standarder og den fælleskommunale rammearkitektur mv. med det formål at afgrænse de dele, som det er særligt væsentligt for Køge Kommune at forholde sig til. Afsnit 3 identificerer de tre største drivere for forandring, som kommunen med fordel kan tage udgangspunkt i: (1) Implementering af SAPA til afløsning af KMD Sag, (2) implementering af rammearkitekturens støttesystemer og Serviceplatformen samt (3) forberedelse til genbrug af data. På denne baggrund giver afsnit 4 konkrete anbefalinger til Køge Kommune. Anbefalingerne fokuserer på en målrettet indsats for at skabe værdi af de tre drivere. Det drejer sig bl.a. om at mappe kommunens eksisterende systemportefølje i relation til de tre drivere. Det drejer sig også om klare principper for at indgå i projekter og i samarbejder. I afsnit 5 omsættes de konkrete anbefalinger i en handlingsplan for Køge Kommune. Afsnit 6 perspektiveres analysen ved at pege på yderligere overvejelser, som analysen af det fælles gods giver anledning til. Det drejer sig om fx projektressourcer og organisering i relation til det fælles gods. Afsnit 7 indeholder en oversigt over henvisninger til relevante websider, som Køge Kommune med fordel kan følge for også fremover at holde sig opdaterede om det fælles gods: standarder, arkitektur, strategier, monopoludbud og andre projekter. # v 1 4

6 2. Baggrund og forudsætninger i Køge Kommune Dette afsnit beskriver Køge Kommunes baggrund og forudsætninger for at arbejde med de fællesoffentlige standarder, rammearkitekturen og fælles projekter. Samtidig beskrives eksisterende behov i organisationen, der kan adresseres gennem arbejde med standarder og arkitektur. Afsnittet danner et udgangspunkt for de konkrete anbefalinger, som gives i afsnit Køge Kommunes digitaliseringsstrategi Køge Kommune har siden 2010 arbejdet med digitaliseringsprojekter med udgangspunkt i en politisk vedtaget digitaliseringsstrategi, der dækker hele kommunen. Strategien udløber med udgangen af Tabel 1: Eksempler på digitaliseringsinitiativer i Køge Kommune Tværgående Fagspecifikke Udover strategiske pejlemærker indeholder strategien en række konkrete initiativer. De konkrete initiativer er dels fra den Fælleskommunale Handlingsplan , dels Køge Kommunes egne initiativer, jf. tabel 1. Oversigten er ikke udtømmende. Fælleskommunale initiativer Egne initiativer Dokumentation af løsningers anvendelse og funktionalitet Fælles principper for arkitektur og indkøb Etablering af servicekatalog (forretningsservices) Fælleskommunal konkurrenceudsættelse af monopolsystemer Bedre systemudnyttelse Data i beskæftigelsesindsatsen Fælles Medicinkort (FMK) og MedComstandarder Standardiserede geodata Forvaltning af ejendomsdata DUBU (Digitalisering af udsatte børn og unge) Strategi på skole- og dagtilbudsområdet Som det fremgår af tabel 1, berører standardisering og rammearkitekturen tværgående såvel som fagspecifikke initiativer. Særligt sundheds- og omsorgsområdet samt det tekniske område er berørt. Ved vedtagelsen af Digitaliseringsstrategien i 2010 var der ikke i fagforvaltningerne taget selvstændige initiativer, som er indar- # v 1 5

7 bejdet i digitaliseringsstrategien. I stedet gennemføres fagspecifikke initiativer parallelt med udmøntningen af digitaliseringsstrategien. Særligt på skole- og dagtilbudsområderne har der været fokus på udmøntning af det fælles gods, idet der er taget stilling til de fælles initiativer i en overordnet strategi Systemporteføljen og it-anskaffelser I det følgende gennemgås styringen af Køge Kommunes systemportefølje og systemanskaffelser. Systemporteføljen afgrænses bredt til systemer, der finder anvendelse i kommunen. Det vil sige, at også systemer, som ikke ejes af kommunen, men stilles til rådighed af andre offentlige myndigheder, inddrages Kommunens overblik over systemporteføljen Køge Kommune vedligeholder data om systemporteføljen i en række excel-ark, som opdateres manuelt. Ifølge oversigten har kommunen godt 300 aktive systemer fordelt over den samlede forvaltning. Ca. halvdelen af systemerne er enten tværgående systemer som økonomi- og lønsystemer eller basissystemer som telefonsystem og active directory (AD). Køge Kommune har i dag som hovedregel dokumenteret fx systemejer og systemansvarlig, systemleverandør og i et vist omfang også eksisterende integrationer. Hertil kommer en lang række andre parametre, der dog ikke omfatter fx dato for kontraktudløb, kontraktsum etc. Det er Devoteams vurdering, at en styrket central registrering af systemdokumentation, aftalegrundlag og grænseflader kan bidrage til et bedre overblik over systemporteføljen. Køge Kommune har formelt ikke faste principper for it-anskaffelser, og de enkelte forvaltninger har hver især beslutningskompetence til anskaffelse af nye systemer. Dog er der pligt til at orientere It-afdelingen om anskaffelser med henblik på afklaring af spørgsmål vedrørende teknisk implementering, sikkerhed, mv. På trods af fraværet af formulerede, vedtagne anskaffelsesprincipper følger kommunen de facto følgende tre overordnede anskaffelsesprincipper: # v 1 6

8 Princip om tilslutning til fælleskommunale initiativer: Det vil sige, at kommunen som udgangspunkt bakker op om og tilslutter sig fælleskommunale initiativer i regi af KL/KOMBIT. Princip om anvendelse af standardløsninger: Det vil sige, at udviklingsprojekter på egen hånd som udgangspunkt fravælges. Princip om risikominimering ved nyanskaffelser: Det vil sige, at kommunen som udgangspunkt først anskaffer nye systemer, når de har været afprøvet i andre kommuner. Nedenfor er beskrevet, hvordan principperne konkret giver sig til udtryk i systemporteføljen Anvendelse af fællesoffentlige og kommunale systemer Princippet om tilslutning til fælleskommunale initiativer fortolkes i forhold til de konkrete initiativer. Køge Kommune bakker loyalt op om initiativer, som indgår i aftaler mellem regeringen og KL. Når der er tale om initiativer af mere frivillig karakter, vurderer kommunen nøgternt fordele og ulemper ved tilslutning. Køge Kommune er eksempelvis tilsluttet monopolbruddene, FLIS og DUBU. Der skelnes således mellem systemer, hvor tilslutning opfattes som obligatorisk (fx monopolbrudene), og systemer, hvor tilslutning er mere valgfri (fx DHUV). Fagforvaltningerne har frihed til selv at vælge tilslutning på deres respektive områder, men rådfører sig i et vist omfang med den centrale it-afdeling Egne it-anskaffelser Ved formelle udbudsforretninger er der en intern arbejdsdeling mellem udbudsfunktionen, it-afdelingen og fagområderne. Udbudsressourcerne er begrænsede, og forholder sig derfor primært til overholdelse af formkrav og procedurer. Der bliver ikke anvendt standardkrav ved it-anskaffelser. Egne anskaffelser bliver typisk gennemført efter vandfaldsmetoden. Ved anskaffelser, der ligger under udbudsgrænsen, bliver udbudsfunktionen typisk ikke inddraget, og hvis der er tale om anskaffelse af fagsystemer, bliver itafdelingen i selve anskaffelsesfasen inddraget efter behov. Der bliver kun i meget begrænset omfang gennemført udviklingsprojekter. # v 1 7

9 Anvendelse af udbudsfællesskaber Køge Kommune anvender SKI-aftaler, hvor det giver mening. Særligt fremhæves lavere udbudsomkostninger og prisbesparelser som fordele ved SKI. Kommunen har fx en aftale på KMD Elev via SKI. Kommunens fælles udbudsfunktion rådgiver i begrænset omfang om anvendelse af SKI-rammeaftaler. Kommunen deltager også i Fællesudbud Sjælland (FUS), som har koordineret et fælles miniudbud af Microsoft-aftaler på SKI s rammeaftale. Kommunen har desuden deltaget i kravspecificering af et fælles Ungdomsuddannelsesvejlednings-system (UUV) Principper for systemejerskab Køge Kommune har skriftligt dokumenteret sine principper for systemejerskab. Der skelnes mellem systemejer og systemansvarlig med følgende ansvarsdeling: Systemejer er ansvarshavende for: Økonomi vedr. systemet og dets anvendelse At systemet understøtter forretningen At it-standarder og it-sikkerhedspolitik overholdes Systemændringer Indgåelse af serviceaftaler At systemet anvendes som forventet (ledelsesmæssig opfølgning) Systemejer skal udpege systemansvarlig Systemansvarlig varetager følgende opgaver: Modtager og prioriterer ændringsønsker og igangsætter udviklingstiltag efter aftale med systemejer Håndterer systemændringer Håndtering af fejl Har den løbende kontakt med systemleverandør vedr. bl.a. serviceaftaler Definerer adgangsforhold/rolleprofiler for brugere til applikationen Anmelder systemet til datatilsynet - hvis relevant Er bindeled mellem IT-afdelingen, systemejer og fagforvaltningen Koordinerer grænseflader med andre systemansvarlige/-ejere Ansvarlig for, at brugerne kan anvende systemet, herunder: # v 1 8

10 Uddannelse af brugere Sikre, at der er support til brugere Med de beskrevne principper er systemejerskabet for fagsystemer typisk decentralt, og den enkelte systemejer har en høj grad af autonomi. Formelt set er den fagspecifikke del af systemporteføljen således stærkt forankret i fagområderne. På tværs af systemporteføljen er der kun få fælles standarder, og den centrale itafdeling fører ikke tilsyn med systemejerskabet på de enkelte fagområder. Principperne for systemejerskab og for anskaffelser betyder, at ressourcer med viden om og faglighed omkring systemansvar er spredt på tværs af forvaltningerne. Herunder hører erfaring med fællesoffentlige og fælleskommunale systemer, egne anskaffelsesprocesser og anvendelse af udbudsfællesskaber Værdiforståelsen i Køge Kommune De beskrevne principper for systemejerskab og it-anskaffelser suppleres af en særlig værdiforståelse i Køge Kommune. Med værdiforståelse menes i denne sammenhæng forståelse af, hvornår initiativer i det fælles gods opfattes som værdifulde for Køge Kommune. Alle input til værdiforståelsen kommer fra It-afdelingen, idet der ikke er foretaget en egentlig undersøgelse i fagforvaltningerne Prioritering og planlægning Det er vigtigt for Køge Kommune, at håndtering af initiativer i det fælles gods prioriteres med udgangspunkt i en konkret vurdering af det nødvendige ressourceforbrug sammenholdt med det forventede, værdimæssige udbytte. Prioriteringen skal samtidig tage stilling til risici. Udover prioriteringen er det vigtigt, at initiativerne planlægges med udgangspunkt i sammenhænge og ressourcestyring, og at fælleskommunale tidsplaner følges. De konkrete elementer i værdiforståelsen er følgende: Fokus på funktionalitet og effektiv understøttelse af arbejdsgange: For at sikre effektiv opgavevaretagelse har kommunen en særlig interesse i systemernes funktionalitet og understøttelse af arbejdsgange. # v 1 9

11 Billigere drift og vedligeholdelse af software: For Køge Kommune er realisering af direkte besparelser på drift og vedligeholdelse af software en mulighed for at frigøre ressourcer til budgetmæssige omprioriteringer. Udmøntning af aftaler mellem KL og regeringen: Det er vigtigt for Køge Kommune at bakke loyalt op om aftaler mellem KL og regeringen. Minimering af risici: Når der anskaffes nye systemer eller udskiftes eksisterende systemer, er der en risiko for negativ påvirkning af brugerne. Særligt i implementeringsfasen og ved overgang til almindelig drift. For Køge Kommune er det afgørende at minimere disse forretningsmæssige risici. # v 1 10

12 3. Overblik over det fælles gods I dette afsnit udpeges de særlige elementer i det fælles gods dvs. strategier og projekter, standarder, arkitektur og grunddata som Køge Kommune skal være særligt opmærksom på Baggrund og formål Baggrunden for arbejdet med åbne standarder, rammearkitektur og fælles projekter i kommunerne er en længere proces i regi af både statslige, fællesoffentlige og fælleskommunale samarbejder. De væsentligste præmisser for arbejdet med rammearkitekturen, genbrug af data og monopolbruddene er i dag beskrevet i Den Fællesoffentlige Digitaliseringsstrategi , som er aftalt mellem regeringen, Danske Regioner og KL samt Den Fælleskommunale Handlingsplan for Digitalisering , som er vedtaget i KL s bestyrelse. Den Fælleskommunale Handlingsplan er det væsentligste overordnede referencepunkt for Køge Kommune, men særligt i forhold til genbrug af data er det relevant også at følge med i de fællesoffentlige projekter. En del af udgangspunktet for både Den Fællesoffentlige Digitaliseringsstrategi samt Den Fælleskommunale Rammearkitektur er den hvidbog om åbne standarder i det offentlige, som blev udgivet i Der findes referencer til relevante dokumenter bagerst i dokumentet Formål: At identificere drivere for udvikling Formålet er at afdække drivere i det fælles gods, hvor Køge Kommune skal have særligt fokus på arkitektur og standardisering, idet det forudsættes, at fagforvaltningerne på deres respektive områder forholder sig til fagligt afgrænsede projekter. Afsnittes indledes med en beskrivelse af, hvad der i denne sammenhæng menes med drivere, og det beskrives samtidigt, hvordan det fælles gods kan inddeles hierarkisk. Disse beskrivelser følges op af en redegørelse for baggrunden for det fælles gods. Efterfølgende stilles der skarpt på først de fællesoffentlige standarder og OIO-arbejdet, herefter den fællesoffentlige og den fælleskommunale strategi, hvilket følges op af en gennemgang af rammearkitekturen og monopolbruddene. Afslutningsvis gennemgås forskellige typer af projektfællesskaber. # v 1 11

13 Det konkluderes, at Køge Kommune skal være særligt opmærksom på følgende tre drivere i det fælles gods: SAPA (Sagsoverblik/Partskontakt): Fælleskommunalt udviklingsprojekt i regi af KOMBIT og en del af monopolbruddene, som vil påvirke itunderstøttelsen i meget store dele af kommunen. Genbrug af data: Et centralt element i den fællesoffentlige digitaliseringsstrategi, hvis potentiale i høj grad skal realiseres lokalt. Støttesystemer og Serviceplatform: Centrale komponenter i rammearkitekturen, hvis potentiale i høj grad skal realiseres lokalt. I afsnit 4 gives der med udgangspunkt i de tre drivere konkrete anbefalinger til Køge Kommune Kriterier for udpegning af drivere Ved drivere forstås initiativer i det fælles gods, som i væsentligt omfang opfylder et eller flere af de følgende kriterier: Initiativer i det fælles gods, som kan skabe stor værdi, fx i form af sparet tid til vedligeholdelse af data, eller bedre forretningsmæssig udnyttelse af data, er obligatoriske og kræver lokal handling, fx initiativer aftalt mellem KL og regeringen eller pålagt ved lov, er særligt risikofyldte, fx fordi de er forretningskritiske, rummer stor teknologisk eller organisatorisk kompleksitet, etc. De obligatoriske initiativer er en særlig kategori af det fælles gods, idet det fælles gods kan kategoriseres i følgende hierarki: Obligatoriske initiativer: Initiativer, som er aftalt mellem staten og KL eller pålagt ved lov. De åbne, obligatoriske standarder og monopolbruddene er eksempler på aftalte initiativer, mens udmøntning af digital post er pålagt ved lov. Anbefalede initiativer: Tilslutning til visse initiativer er anbefalet af KL, men ikke direkte pålagt kommunerne. Fx Byg og Miljø. Frivillige initiativer: Tilslutning til en række andre initiativer er helt frivillig. Fx tilslutning til udvikling af et fælles bibliotekssystem i regi af KOMBIT. # v 1 12

14 For Køge Kommune kan der være et stort gevinstpotentiale i tilslutning til de anbefalede og frivillige initiativer. Men da initiativerne pr. definition ikke er obligatoriske, og da de yderst sjældent vil udgøre en forretningsmæssig risiko på tværs af de borgerrettede funktioner, bliver de ikke identificeret som væsentlige drivere. Dette betyder ikke, at Køge Kommune ikke skal interessere sig for disse initiativer, men blot, at initiativerne ikke bør tildeles højeste prioritet i kommunens tværgående indsats. Uanset placeringen i hierarkiet vil den organisatoriske implementering og gevinstrealisering af et givet initiativ altid ligge lokalt i Køge Kommune Læsevejledning til afsnit 3 I den resterende del af afsnit 3 gennemgås hovedelementer i det fælles gods med et underafsnit til hvert af følgende emner: OIO standardisering og arkitektur, Den fællesoffentlige digitaliseringsstrategi, Den fælleskommunale handlingsplan, Rammearkitektur og fælles it-arkitektur-principper, Monopolbruddene Projektfællesskaber. Alle underafsnittene indeholder en gennemgang af de vigtigste elementer med henvisning til de relevante kilder, og dernæst en vurdering af relevansen for Køge Kommune. Det afsluttende underafsnit konkluderer, hvilke drivere Køge Kommune især skal forholde sig til for at skabe værdi af det fælles gods. # v 1 13

15 3.2. OIO - standardisering og arkitektur OIO (oprindeligt: Offentlig Information Online) er en samlebetegnelse for det fællesoffentlige arbejde med standardisering og arkitektur Obligatoriske standarder Det er obligatorisk for alle offentlige myndigheder at overholde syv sæt af åbne standarder. 1 De åbne standarder er: 1. Standarder for dataudveksling mellem offentlige myndigheder (OIOXML) 2. Standarder til for sag og dokument (tidl. FESD) 3. Standarder til elektroniske indkøb i det offentlige (OIOUBL) 4. Standarder for digital signatur (OCES) 5. Standarder for offentlige netsteder / hjemmesider og tilgængelighed 6. Standarder for it-sikkerhed (DS484 - kun for staten) 7. Standarder for dokumentudveksling (ODF, OOXML og PDF) Anbefalede standarder Desuden findes en række anbefalede standarder på Et eksempel er notationsformen BPMN, der anbefales som notationsform for procesdiagrammering. Anvendelse af disse standarder er ikke obligatorisk, men er typisk hensigtsmæssig OIO-arkitekturarbejdet OIO-arkitekturarbejde er sammenfattet i arkitektur-guiden. 2 Arkitektur-guiden giver blandt andet et overblik over fællesoffentlige redskaber til at beskrive strategi, forretning, information, applikation og teknologi på både konceptuelt, logisk og fysisk niveau. Det er med andre ord et arkitektur-opslagsværk for det offentlige Danmark. 1 Se 2 Se # v 1 14

16 Relevans for Køge Kommune OIO-standarderne hører til de obligatoriske elementer i det fælles gods, og Køge Kommune skal derfor overholde standarderne, hvor det er relevant. Køge Kommune skal være særligt opmærksom på at stille krav til leverandører om, at dataudveksling mellem systemer som udgangspunkt sker i OIOXML, når kommunen efterspørger konkrete integrationer mellem systemer. Standarderne for sag og dokument ligger til grund for mange af støttesystemerne i den fælleskommunale rammearkitektur, og bliver uddybet i afsnittet herom. De øvrige standarder har følgende relevans: Standarder for e-indkøb, digital signatur og dokumentudveksling vurderes at være implementeret i Køge Kommune. Standarder for offentlige netsteder er relevant ved fornyelser af disse. Fx ved etablering af en ny hjemmeside. De øvrige, anbefalede standarder vurderes især at være relevante ved egenudvikling af systemer og ved selvstændig systemdokumentation. OIO-arkitekturarbejdet er især relevant, hvis Køge Kommune ønsker en mere formaliseret beskrivelse af sin arkitektur og ønsker at styre efter en målarkitektur, og/eller hvis Køge Kommune gennemfører større it-udviklingsprojekter med deltagelse af it-arkitekter Den fællesoffentlige digitaliseringsstrategi Den fællesoffentlige strategi 3 indeholder følgende tre overordnede spor: Spor 1: Slut med papirblanketter og brevpost Spor 2: Ny digital velfærd Spor 3: Tættere offentligt samarbejde. 3 Jf. Digitale_vej_til_fremtidens_velfærd.ashx # v 1 15

17 Relevans for Køge Kommune Strategien er aftalt mellem staten, Danske Regioner og KL, og realiseringen af den hører derfor til den obligatoriske del af det fælles gods. Spor 1 og 2: Disse spor løses i al væsentlighed gennem initiativer i Den Fælleskommunale Handlingsplan, og implementeres primært af fagforvaltningerne i Køge Kommune. Spor 3: Spor 3 indeholder bl.a. genbrug af data. Der peges særligt på etablering af autoritative grunddata, som billigt kan stilles til rådighed for kommunerne. Det drejer sig bl.a. om CPR, CVR og BBR-data. Genbrug af data er en del af Den Fælleskommunale Rammearkitektur. I forbindelse med Køge Kommunes udmøntning af rammearkitekturen er det derfor særdeles relevant at forholde sig til, hvordan og i hvilket omfang kommunens systemportefølje kan og bør anvende de såkaldte autoritative grunddata. En forudsætning herfor er realisering af en række statslige og fællesoffentlige projekter. Dette beskrives nærmere i afsnittet om rammearkitekturen. Samtidig skal Køge Kommune være opmærksom på, at det er aftalt mellem regeringen og KL, at kommunerne skal øge datakvaliteten. # v 1 16

18 3.4. Den fælleskommunale handlingsplan Den fælleskommunale handlingsplan 4 indeholder de initiativer, som skal udmønte den fælleskommunale digitaliseringsstrategi, vedtaget af KL s bestyrelse. Handlingsplanen indeholder seks indsatsområder, hvoraf fire er afgrænset til enkelte fagområder. Nedenfor gives en oversigt. Digital kommunikation med borgerne: Dette indsatsområde dækker initiativer i forhold til kanalstrategi, hjemmesider, selvbetjening samt digital post og fjernprint. Fagligt afgrænsede indsatsområder: De fagligt afgrænsede indsatsområder vedrører (1) beskæftigelse, (2) børn og kultur, (3) social og sundhed samt (4) teknik og miljø. Sammenhængende it og konkurrence: Indsatsområdet dækker rammearkitektur, monopolbrud og FLIS (fælleskommunalt ledelsesinformationssystem). Udover handlingsplanens seks indsatsområder indeholder selve strategien også en delstrategi for digital ledelse Relevans for Køge Kommune Nedenfor er beskrevet, hvordan Køge Kommune skal forholde sig til de tværgående indsatsområder. De fire fagspecifikke indsatsområder har ikke tværgående relevans, men de kan godt være obligatoriske ligesom de kan indeholde et væsentligt gevinstpotentiale. Det forudsættes, at Køge Kommunes fagforvaltninger udmønter disse indsatsområder, og de behandles derfor ikke yderligere her. Digital kommunikation med borgerne: En væsentlig del af indsatsområdet er udmøntet ved overholdelse af e2012-målene og herudover realiseres en stor del af indsatsområdet gennem bølgeplanen for obligatorisk digital selvbetjening og implementering af digital post og fjernprint. Her skal Køge Kommune være opmærksom på, at der til anskaffelse af nye selvbetjeningsløsninger er udarbejdet en Udviklingsvejledning for selvbetjeningsløsninger, 5 og at der er en række obligatoriske krav, som nye selvbetjeningsløsninger skal overholde. Disse krav er beskrevet i arkitekturguiden.dk. Herudover skal kommunen forholde sig til gevinstrealisering af digital post og fjernprint. 4 Se Den Fælleskommunale Digitaliseringsstrategi 5 Se Udviklingsvejledning for selvbetjeningsløsninger # v 1 17

19 Sammenhængende it og konkurrence: Indsatsområdet håndteres i vid udstrækning af rammearkitekturen og de fælles KOMBIT-udbud. Køge Kommune realiserer en stor del af indsatsområdet ved at gå med i de fælles udbud på monopolområdet. Herudover kan Køge Kommune realisere sin del af strategien på forskellige ambitionsniveauer. I afsnit 4 om anbefalinger operationaliseres tiltagene i forhold til Køge Kommunes aktuelle situation. Digital ledelse: Delstrategien for digital ledelse håndteres ikke i handlingsplanen, og der er en meget begrænset fælleskommunal indsats på området i regi af KL. Det er derfor her en forudsætning, at Køge Kommune selvstændigt arbejder aktivt med digital ledelse, fx med udgangspunkt i KL s og Devoteams modenhedsmåling. 6 6 Modenhedsmodel # v 1 18

20 3.5. Rammearkitektur, it-arkitektur-principper og vejledninger Den fælleskommunale rammearkitektur er et særskilt projekt (6.1.a) under indsatsområdet sammenhængende it og konkurrence i den Fælleskommunale Handlingsplan , som potentielt har konsekvenser for kommunens samlede systemportefølje. I dette afsnit brydes rammearkitekturen ned for at udpege de dele, som har særlig relevans for Køge Kommune. Rammearkitekturen er ikke direkte aftalt mellem regeringen og KL, men den er en forudsætning for den fælleskommunale konkurrenceudsættelse af KMD-systemer, som indgår i Økonomiaftalen for Den er således ikke formelt en del af de obligatoriske initiativer i det fælles gods, men de facto er en række af elementerne alligevel obligatoriske, fx serviceplatform og støttesystemer. De facto-tilstanden forpligter på den ene side kommunerne til at udmønte rammearkitekturen, men giver samtidig et meget stort spillerum i den konkrete udmøntning Rammearkitekturens indhold KOMBIT beskriver den samlede rammearkitektur som et stærk redskab for kommunerne i forbindelse med at stille krav til leverandørerne om at anvende fælles it-komponenter, snitflader, osv., således, at det samme arbejde ikke gøres flere gange. Samtidig er rammearkitekturen et stærkt strukturerings- og styringsredskab, som rammesætter et fælles begrebsapparat, en fælles opdeling af it-services og et fælles sæt af standarder. Det styrker kravformuleringen og dialogen mellem kommuner og it-leverandører. (Den fælleskommunale rammearkitektur s. 5) Som sådan indeholder rammearkitekturen en lang række forskellige elementer, der tilsammen skal sætte rammer for it-udviklingen og leverandørhåndteringen i kommunerne. Figur 1 nedenfor giver et overblik over elementerne. # v 1 19

21 Figur 1: Overblik over rammearkitekturen Kilde: Oplæg ved Mette Kurland, KOMBIT, den 6. marts 2013 for Association for Enterprise Architects på ITU. Architects-6-marts-2013.pdf Som det fremgår af figur 1, er rammearkitekturen formuleret ud fra en overordnet strategi og vision, som operationaliseres i en række principper for forretnings- og it-arkitekturen. Der er eksempelvis principper for, hvordan it-sikkerhed tænkes ind i it-løsninger og hvordan brugere inddrages i behovsafklaring og udviklingsforløb. Principperne er således relativt konkrete, og er beskrevet i De fælleskommunale arkitekturprincipper. Under principperne ligger en model for, hvordan den enkelte kommune kan beskrive sin forretning og it-understøttelsen heraf. Med forretning menes her både borgerrettede funktioner og de administrative funktioner, som understøtter dem. Det er i modellen, at begreberne logiske forretningstjenester, standarder, integrationsmønstre og driftsmønstre findes. Udover modellen indeholder rammearkitekturen yderligere en beskrivelse af de fysiske komponenter, som skal findes i rammearkitekturen. Her tænkes på, hvordan de konkrete it-løsninger skal struktureres, hænge sammen og driftes. # v 1 20

22 Den væsentlige pointe er her, at rammearkitekturen ikke blot handler om, hvordan it-løsningerne skal hænge sammen, men i høj grad også, hvordan it-løsningerne skal hænge sammen med de processer, som de understøtter. Helt overordnet bygger rammearkitekturen på de fællesoffentlige OIO EA principper og målene om genbrug af data i Den Fællesoffentlige Digitaliseringsstrategi Dens primære sigte er at skabe sammenhæng i den kommunale it og øget konkurrence på markedet for kommunal it Visionen Rammearkitekturens vision er todelt. KOMBIT beskriver selv det overordnede formål som at skabe grundlag for at gennemføre konkurrenceudsættelse af itsystemer på de områder, hvor KMD i dag er eneste leverandør. Herudover skal arkitekturen også bruges til at løfte den kommunale digitalisering som helhed. (Den fælleskommunale rammearkitektur s. 5) Den første del af formålet om konkurrenceudsættelse af KMD-systemer håndteres af KOMBIT med inddragelse af kommunerne, men den anden del af visionen om at løfte den kommunale digitalisering som helhed i høj grad er den enkelte kommunes ansvar. Visionen for fremtidens sammenhæng mellem det fælles gods og itunderstøttelsen i den enkelte kommune kan beskrives med en rådhus-metafor. Rådhusets fundament er støttesystemer, som fagsystemer i kommunens overbygning kan trække på. Figur 2 illustrerer rammearkitekturens vision for det enkelte rådhus. # v 1 21

23 Figur 2: Rådhus-metafor for rammearkitekturen Kilde: Oplæg ved Mette Kurland, KOMBIT, den 6. marts 2013 for Associations for Enterprise Architects på ITU. Som det fremgår af figur 2, er komponenterne i rådhusets overbygning meget tæt knyttet op på specifikke borgerrettede opgaver, mens komponenterne i kælderen går på tværs, og hver især understøtter flere af komponenterne i overbygningen. Rammearkitekturens vision er at forbedre sammenhængen mellem de forskellige komponenter i den enkelte kommune, på tværs af kommunerne og på tværs af den offentlige sektor som helhed Rammearkitekturens potentiale For at blive mere konkrete i forhold til potentialet tager rammearkitekturen udgangspunkt i en analyse af forretningsbehov, som går på tværs af den kommunale sektor. På denne baggrund opstilles en række mål for it-arkitekturen i kommunerne. KOMBIT s egen beskrivelse af potentialet i rammearkitekturen kan kort sammenfattes til følgende: Arbejdstidsbesparelser for slutbrugere. Besparelser på it-udgifter (anskaffelse, drift og vedligeholdelse). # v 1 22

24 Forbedring af brugeroplevelser. Som det fremgår af det følgende er der en lang række forudsætninger, som skal opfyldes, før potentialerne kan realiseres. En række af forudsætningerne har Køge Kommune begrænset eller ingen indflydelse på, men der er samtidig en række forudsætninger, som der kan arbejdes aktivt med for at skabe konkret forretningsmæssig værdi herunder lokale investeringer Køge Kommune og Rammearkitekturen De enkelte kommuner har i dag omfattende systemporteføljer. Rådhus-metaforen beskriver, hvordan fagsystemerne i den enkelte kommune understøttes af en række støttesystemer, men den beskriver ikke, hvordan den enkelte kommunes systemer hænger sammen med systemer uden for. Dette illustreres i figur 3 nedenfor. Figur 3: Køge Kommunes fremtidige systemlandskab i rammearkitekturen Kilde: Oplæg ved Mette Kurland, KOMBIT, den 6. marts 2013 for Associations for Enterprise Architects på ITU. Note: KOMBIT angiver, at figuren er i udkast Den orange del af figur 3 (= Kommunen) indeholder kommunens egen systemportefølje, hvoraf en del er fagsystemer i rådhusets overbygning, mens de øvrige # v 1 23

25 er støttesystemer i rådhusets kælder. En særlig kategori af fagsystemerne er selvbetjeningsløsninger, som ikke blot anvendes af kommunens medarbejdere, men også af borgere. Det bemærkes, at figur 3 reducerer kompleksiteten af den faktiske systemportefølje i kommunerne væsentligt. Fx har Køge Kommune i alt ca. 300 systemer registreret i kommunens systemdokumentation. I de røde dele af figur 3 ligger de fælleskommunale løsninger, som KOMBIT anskaffer på vegne af kommunerne. En del af disse er fagsystemer (SAPA, Ydelsessystem, Sygedagpengesystem), som i rådhusmetaforen vil ligge i overbygningen, mens den øvrige del er støttesystemer, som vil ligge i kælderen. Hertil kommer fagsystemer i den grønne del, som vil blive anvendt af Udbetaling Danmark. I rådhuskælderen ligger dog også en række yderligere systemer og løsninger, som bliver tilvejebragt via staten (de blå) og regionerne (de lilla). Fx borger.dk, digital post og CPR-data. I forhold til lige netop de autoritative grunddata har kommunerne forpligtet sig til at bidrage til at øge datakvaliteten. 7 Ifølge rammearkitekturen skal sammenhængen mellem det, der ligger i den enkelte kommune, og det, der ligger udenfor, skabes via Den Fælleskommunale Serviceplatform, som ligger i midten af figuren. En række af komponenterne i rammearkitekturen findes allerede i dag, men der er også en væsentlig del, som skal tilvejebringes. Heraf har den enkelte kommune ansvaret for de komponenter, som ligger i den orange del. Ansvaret for den enkelte kommune kan opsummeres som følgende: Anvendelse af Serviceplatformen: Det er visionen for fremtidens systemlandskab, at Køge Kommune er i stand til at anvende det fælles gods via integrationer og grænseflader gennem Serviceplatformen. Etablering af lokale støttesystemer: Den enkelte kommunes rolle i relation til etablering af de lokale støttesystemer er endnu uafklaret. Fx er det endnu et åbent spørgsmål, om kommunen skal udfylde organisationsstandarden, eller om kommunen kan stille krav om, at en leverandør gør det. Det er ligeledes uafklaret, hvordan den konkrete tekniske installation sker: Om det kan overlades til leverandørerne, eller om det forudsætter selvstændig installation af 7 Grunddataprogrammet. # v 1 24

26 kommunen. Dette forventes at indgå i senere version af Drejebog for monopolbrudene. Nye krav til it-leverandører: Kommunen skal indlede en prioriteret dialog med sine væsentligste leverandører om, hvordan de kan leve op til og dermed nyde godt af rammearkitekturen og af autoritative grunddata. Den væsentligste opgave for Køge Kommune p.t. er således at få overblik over systemporteføljen og prioritere, hvilke leverandører kommunen vil tale med, jf. afsnit 4 og Vejledning og operationalisering For at hjælpe kommunerne med realisering af rammearkitekturen udgiver KOM- BIT løbende vejledninger i håndtering af forskellige dele af kommunernes ansvar. På nuværende tidspunkt er status for vejledningerne følgende: Krav og vejledning til kommunernes fremtidige it-udbud: Notatet er udgivet af KOMBIT i en foreløbig udgave, der alene vedrører Serviceplatformen. I skrivende stund er en udvidet vejledning, der også omfatter støttesystemerne, i høring i kommunerne og hos leverandørerne. Høringsfristen er d. 23. maj. Udviklingsvejledning for selvbetjeningsløsninger: Hjemmeside med beskrivelse af 24 fællesoffentlige krav til selvbetjeningsløsninger og vejledning til opfyldelse af kravene. Udgivet af Styregruppen for den fællesoffentlige digitaliseringsstrategi. Drejebog for monopolbruddet 8 : KOMBIT har 31. maj 2013 (rev. 19. juni 2013 til version 1.1) udgivet Kommunernes drejebog for monopolbruddet, der skal være en samlet kanal for information om arbejdet med monopolbruddet. Drejebogen beskriver organisatorisk forberedelse og implementering, teknisk forberedelse og implementering, samt udbudskrav, jura og leverandørdialog. Og sigter mod at beskrive aktiviteter og beslutninger, som skal gennemføres i kommunerne inkl. start- og slutpunkt. Drejebogen peger bl.a. på behov for følgende organisatorisk forberedelse og implementering (med angivelse af forventet start- og slutpunkt i parentes): 8 # v 1 25

27 At skabe overblik over systemerne (Juni 2013-fortløbende) At kortlægge brugermønstre i KMD Sag (Juni 2013-fortløbende) At forholde sig til KOMBITs ni forslag til kommunernes forberedelse til SA- PA (Juni 2013-fortløbende) At estimere ressourcer for arbejdet med monopolbrud (Uge / ) At etablere en projektorganisation pr. monopolsbrudsprojekt (Juni December 2013) At opstille plan for gevinstrealisering for de nye løsninger ( ) Drejebogen peger bl.a. på følgende tekniske forberedelse: At kommunerne kortlægger sit eksisterende it-miljø op i mod KOMBITs kommende kravliste, idet kommunerne vil være forpligtet til, at deres it-miljø lever op til KOMBITs krav (Sep juni 2015). Drejebogen peger bl.a. på følgende juridiske forberedelse: Kommunerne indarbejder krav vedr. Serviceplatformen [og på sigt også støttesystemerne] i kommende udbud og genudbud (Juni fortløbende) Relevans for Køge Kommune Rammearkitekturen skal bidrage til realisering af indsatsområdet Sammenhængende it og konkurrence i Den Fælleskommunale Handlingsplan, og hjælper således Køge Kommune med at indfri de fælleskommunale mål. I forhold til første del af rammearkitekturens vision om konkurrence på monopolområderne indfries målene gennem KOMBIT s fælleskommunale udbud, jf. senere om relevansen af vejledningerne. I forhold til den anden del af visionen om at løfte digitalisering generelt skal Køge Kommunen forholde sig til den resterende del af systemporteføljen, som ikke konkurrenceudsættes via monopolbruddene. Her kræver realiseringen af rammearkitekturen, at der stilles nye krav til kommunens it-leverandører omkring anvendelse af Serviceplatformen og støttesystemerne. # v 1 26

28 Særligt relevante arkitekturprincipper ved it-anskaffelser: Ud af de samlede fælleskommunale arkitekturprincipper vurderer Devoteam, at især følgende principper har relevans for Køge Kommune: A2: Der skal udarbejdes særskilte udviklings- og driftskontrakter for større systemer. Dette kræver efter Devoteams vurdering et selvstændigt juridisk fokus i anskaffelsesprocessen, da fx K01 og K02 alene har kontraktparadigme for udvikling og ikke har en særskilt kontraktskabelon for driftskontrakter. A2: der skal udarbejdes standardkrav til brug ved udbud (med egen kravspecifikation) af it-systemer. Kravene bør på den korte bane koncentreres om integration til serviceplatformen og anvendelse af støttesystemerne. Jf. senere om vejledningerne, skal Køge Kommune overveje, hvordan og hvornår kravene indarbejdes. B1: Genbrug skal være muliggjort i udbud som option. Bortset fra rene open source løsninger, der jf. licensaftalerne for open source kan genbruges, er der p.t. ikke gode eksempler på, hvordan genbrug sikres. B8: Leverandører af kommunale it-løsninger skal kende standarderne og være i stand til at bruge dem som option. C1: Krav om at udstille data bør indgå i kravspecifikationen som option. Disse to principper kan udmøntes ved at følge den kommende drejebog i rammearkitekturen fra KOMBIT. Devoteams forslag til konkret udmøntning fremgår af afsnit 4 og 5. Drejebogen bør følges nøje af Køge Kommune, da den er den centrale vejledning for det samlede monopolbrud. Devoteams nærmere anbefalinger om, hvordan Køge Kommune kan prioritere og operationalisere Drejebogens anbefalinger, fremgår af afsnit 4 og 5. # v 1 27

29 3.6. De konkrete monopolbrud KMD har de facto monopol på de tre fagsystemer KMD Sag, KMD Aktiv og KMD Sygedagpenge. For at bryde disse monopoler sætter KOMBIT på kommunernes vegne fagsystemerne Sagsoverblik/Partskontakt (SAPA), Kommunernes Ydelsessystem og et nyt sygedagpengesystem i udbud. Herudover sendes støttesystemerne i udbud og udbud af Serviceplatformen er gennemført i Udbetaling Danmark sender yderlige fire monopolsystemer i udbud. Fagsystemerne og deres relevans for Køge Kommune beskrives nedenfor. Der fokuseres særligt på SAPA, da systemet har tværgående relevans, mens de to øvrige fagsystemer er mere fagspecifikke. Det forudsættes, at fagforvaltningerne i Køge Kommune forholder sig mere konkret til disse systemer SAPA SAPA er særligt, fordi det ikke er et enkeltstående KMD-system med et begrænset antal integrationer, som erstattes af et nyt system. SAPA indebærer derimod, at et system (KMD Sag) med mange integrationer erstattes af et nyt system med mindst det samme antal integrationer, idet ambitionen med SAPA er, at løsningen omfatter mindst det samme som KMD Sag i dag, men potentielt mere. SAPA sikrer også, at kommunen får adgang til den fysiske del af rammearkitekturen, det man også kunne kalde den fælles infrastruktur. Det drejer sig om Serviceplatformen og de fælleskommunale støttesystemer, jf. figur 4. # v 1 28

30 Figur 4: Overblik over SAPA-løsningen Samlet SAPA-løsning Udvikling, drift, support og governance. SAPA-portal (ét udbud) - Overblik, advis, journalskrivning (plus dokument, sagsbehandler, historik og direkte hop) Støttesystemer (ét udbud) Sagsindeks, dokumentindeks, klassifikation, organisation, beskedfordeler Serviceplatform (ét udbud - gennemført) Snitflader OK/planlagte (Klippekort) Snitflader på vej (Grunddataprogram og monopoludbud) KK snitflader (uafklaret) KMD systemer: Sag, Aktiv, Dagpenge, Boligstøtte, Pension, Familieydelser, Nye Dagpenge, Ydelses-, Pensions, Boligstøtte og Fam.yd.systemer Bygnings-, adresse-, virksomhedsog persondata 3. Part systemer Andre KMDsystemer Kilde: Devoteam pba. diverse KOMBIT-figurer. Som det fremgår af figur 4, tilvejebringer SAPA-løsningen både en portal, en række støttesystemer samt Serviceplatformen. Snitfladerne til de eksisterende KMD systemer er planlagte og finansieres over den såkaldte klippekortordning. Snitfladerne til de nye monopoludbuds-systemer og til de autoritative grunddata tilvejebringes af henholdsvis udbuddene og af grunddataprogrammet. Tilbage står, at Køge Kommune skal sikre integrationen til 3. partssystemer, altså systemer fra andre leverandører end KMD, samt til de KMD-systemer der ikke er omfattet af ovenstående Ydelses- og sygedagpengesystemerne mv. Monopoludbuddene omfatter også Kommunernes Ydelsessystem, som afløser KMD Aktiv og et nyt Sygedagpengesystem, som afløser KMD Sygedagpenge. Disse udbydes ligeledes af KOMBIT. KOMBIT koordinerer i øvrigt monopoludbuddene med UDK, for at sikre synergi og sammenhæng til de tidligere kommunale opgaver, der nu er overflyttet til UDK. # v 1 29

31 Relevans for Køge Kommune Køge Kommune har allerede tilsluttet sig monopoludbuddene. For Kommunernes Ydelsessystem, Sygedagpenge og SAPA skal Køge Kommune forholde sig til organisatoriske implementering og gevinstrealisering. For SAPA skal kommunen desuden forholde sig til, hvilke systemer der skal integrere til SAPA, og hvordan kravet om dette aftales med systemleverandøren. Hertil kommer, at Køge Kommune skal forholde sig til Støttesystemerne og Serviceplatformens implementering. Af de tre implementeringer er SAPA uden sammenligning den største opgave. Dels er den langt mere teknologisk kompleks. Dels anvendes KMD Sag i dag og SAPA i fremtiden af en lang række brugere i forskellige forvaltninger Projektfællesskaber Der eksisterer i dag en lang række projektfællesskaber, som Køge Kommune skal forholde sig til. En del af dem er direkte knyttet til udmøntning af rammearkitekturen i kommunerne, mens andre rækker på tværs af den offentlige sektor og andre igen er mindre fællesskaber med deltagelse fra en mindre skare af kommuner. Projektfællesskaberne kan overordnet inddeles i følgende kategorier: Fællesoffentlige projekter: Eksempelvis digital post og fælles medicinkort (FMK). Nationale fælleskommunale projekter: Projekterne vil typisk gennemføres i regi af KOMBIT. Et eksempel er DHUV, der netop er gået i udbud. Mindre fælleskommunale samarbejder og projekter: En gruppe af kommuner kan vælge at gå sammen i mindre konsortier omkring konkrete projekter. Der kan være tale om mindre udviklingsprojekter som fx CPR-broker og SBSYS, men der kan også være tale om etablering af drifts- eller indkøbsfællesskaber. Jf. det beskrevne hierarki i indledningen af afsnit 3, gælder det for en række projekter, at tilslutning er obligatorisk, som det eksempelvis er tilfældet med lov om digital post eller monopolbrudsprojekterne, der indgik i Økonomiaftalen for # v 1 30

32 For en række øvrige projekter er tilslutning valgfri, som det eksempelvis er tilfældet med Digitalisering af Handicappede og Udsatte Voksne (DHUV) Genbrug af data og fællesoffentlige projekter generelt Der findes en række fællesoffentlige projekter på tværs af stat, regioner og kommuner, hvoraf en andel er afgrænset til de enkelte fagområder. Et eksempel er det Fælles Medicinkort (FMK). Det forudsættes, at fagforvaltningerne har overblik over projekterne på deres områder. Herudover findes der en række statslige projekter, som har relevans for Køge Kommune. Eksempler på projekter, som kommunen allerede forholder sig til, er Borger.dk, digital post og NemLogin. De væsentligste projekter, som Køge Kommune endnu ikke forholder sig til, er projekterne om tilvejebringelse af autoritative grunddata. Ifølge rammearkitekturen skal grunddataene stilles til rådighed for kommunerne via Serviceplatformen, og Køge Kommune behøver derfor ikke at forholde sig særskilt til integrationen til grunddata, da denne jo løses, forudsat at Serviceplatformen er implementeret korrekt. Derimod udestår en større opgave med at skabe værdi af grunddata, jf. anbefalingerne herom i afsnit Nationale, fælleskommunale projekter Udover de projekter, som er de facto obligatoriske for Køge Kommune jf. økonomiaftalerne mellem KL og regeringen findes der en række yderligere nationale projekter i regi af KOMBIT, som Køge Kommune har mulighed for at tilslutte sig. Det drejer sig eksempelvis om Fælleskommunal Ledelsesinformation (FLIS), Nyt Fælles Bibliotekssystem og Digitalisering af Handicappede og Udsatte Voksne (DHUV). For Køge Kommune rummer disse projekter mulighed for at gennemføre anskaffelse af nye systemer eller udskiftning af eksisterende løsninger med et minimalt ressourceforbrug. Samtidig giver projekterne i en vis udstrækning mulighed for at realisere rammearkitekturen på enkeltområder gennem KOMBIT. Disse projekter er typisk afgrænset til enkelte fagområder, og det forudsættes, at fagforvaltningerne har forholdt sig aktivt til projekterne inden for deres respektive områder. # v 1 31

33 Mindre fælleskommunale samarbejder og projekter I en mindre skala findes kommunale samarbejdsprojekter i stil med Ballerup, Egedal og Furesø kommunernes fælles it-driftsfællesskab, som forventes at vinde frem. Flere andre kommuner er i gang med overvejelser i samme retning, men forventer først at kunne træffe beslutning efter kommunalvalget i Driftsfællesskaberne kan forventes at udvikle sig med overbygninger til varetagelse af eksempelvis systemejerskab og anskaffelsesprojekter, som det er tilfældet med Koncernservice i Københavns Kommune. For Køge Kommune er det relevant at forholde sig til mulighederne i denne type samarbejder, da der formentligt vil være relevante stordriftsfordele for kommunen. Udover driftsfællesskaberne findes der også mindre, kommunale samarbejder om udviklingsprojekter som SBSYS og CPR-broker. Disse projekter kan på afgrænsede områder rumme fordele for Køge Kommune, men de er ikke kritiske at forholde sig til. Endelig kan nævnes indkøbsfællesskaber, fx de 29 sjællandske kommuner, der har sparet millioner på fælles anskaffelse af Microsoft-licenser. Deltagelse i denne type samarbejder er ikke forretningskritisk, og kan vurderes fra sag til sag. Er der en god business case, og tilstrækkelige ressourcer til at deltage, er det naturligt at deltage Relevans for Køge Kommune For Køge Kommune er følgende punkter særligt relevante: Samlet set ligger hovedparten af de projektfællesskaber, som drejer sig om systemanskaffelse ude i de enkelte fagområder, og det er afgørende, at fagforvaltningerne forholder sig aktivt til potentialet i projekterne på deres respektive områder. Der er en tendens i retning af driftsfællesskaber mellem kommuner, og Køge Kommune bør undersøge potentialet på dette område Konklusion tre drivere for forandring Gennemgangen af det fælles gods har identificeret en række drivere, som Køge Kommune med fordel kan tage fat i, når indsatsen for at få værdi af det fælles gods skal prioriteres. Ved drivere forstås her initiativer i det fælles gods, som er # v 1 32

34 enten obligatoriske, særligt risikofyldte eller som rummer et særligt gevinstpotentiale på tværs af forvaltningen. Udmøntning af rammearkitekturen nødvendiggør ikke på nuværende tidspunkt nye it-anskaffelser i den enkelte kommune, men der kan med fordel tænkes i forberedelse af den lokale etablering af støttesystemer. Samtidig vil der være et behov for projektressourcer til håndtering af disse drivere i de kommende år. De identificerede drivere er: SAPA: SAPA-projektet, da Køge Kommune allerede har tilsluttet sig projektet, og da det vil være et vigtigt og synligt projekt med tydelig forretningsmæssig værdi. Støttesystemer og Serviceplatform: Da implementering af disse er en forudsætning for både en succesfuld implementering af SAPA og for at skabe yderligere merværdi. Genbrug af data: Da Køge Kommune for relativt beskedne implementeringsmæssige omkostninger kan spare omkostninger. Anbefalingerne i afsnit 4 fokuserer på, hvordan Køge Kommune kan skabe værdi og minimere risici ved at fokusere på disse tre drivere. # v 1 33

35 4. Anbefalinger Køge Kommune har efterspurgt et overblik over, hvordan det fælles gods bedst muligt kan skabe værdi for kommunen. Herunder er der efterspurgt en afdækning af, hvor Køge Kommune skal have et selvstændigt fokus på arkitektur og standardisering, og konkrete anvisninger på dels, hvordan det fælles gods bedst muligt indarbejdes i kommunens anskaffelser, dels efter hvilke principper kommunen skal tilslutte sig og deltage i de fælles projekter. For at kunne give Køge Kommune konkrete anbefalinger tilpasset kommunens aktuelle situation har Devoteam undersøgt og i afsnit 2 beskrevet den nuværende praksis, baggrund og forudsætninger på området. Anbefalingerne er baseret på de tre ovenfor beskrevne drivere, og for hver enkelt anbefaling beskrives, hvilken konkret merværdi Devoteam forventer, at Køge Kommune vil kunne få af det fælles gods. Hertil kommer naturligvis, at Køge Kommune løbende bør holde sig tæt orienteret om alt vejledningsmateriale fra KOMBIT og KL, jf. henvisningerne i afsnit 7. Denne anbefaling er ikke uddybet nærmere i øvrigt Anbefalinger vedr. SAPA SAPA er en af de tre drivere, som analysen i afsnit 3 pegede på dels skulle gennemføres, dels kunne skabe konkret merværdi ved en fokuseret indsats. Støttesystemerne og Serviceplatformen, der også kan bruges af andre systemer end SAPA, behandles i næste afsnit. Helt grundlæggende er opgaven så stor og vigtig, at den bør projektorganiseres med både organisatorisk og teknisk projektleder. En naturlig første opgave ville være at opstille de konkrete forretningsmæssige mål og visioner for SAPA i Køge Kommune, udarbejde en lokal business case og beslutte, hvilke gevinster Køge Kommune vil forsøge at realisere gennem en SAPA-implementering. Devoteam anbefaler desuden: 1. At identificere SAPA-systemer Første opgave er at identificere, hvilke systemer, som Køge Kommune ønsker, skal integrere til SAPA. # v 1 34

36 Jf. figur 4. i afsnit 3 er det kun en delmængde af systemer, som SAPA-projektet etablerer snitflader til. For den resterende del skal Køge Kommune selv etablere snitflader. Og for alle systemer, der skal integrere, skal Køge Kommune sikre sig, at der er indgået konkret aftale med leverandøren. Et godt udgangspunkt er de systemer, som KMD Sag integrerer til i dag. Hvis der er en forretningsmæssig værdi af denne integration, bør integrationen til KMD Sag suppleres med en integration til SAPA. Denne analyse kan suppleres med en analyse af, hvilke systemer, som Køge Kommune ville ønske, var integreret til KMD Sag i dag, da dette også indikerer en forretningsmæssig værdi. 2. At gå i dialog med leverandørerne snarest muligt For alle de systemer, som Køge Kommune ønsker at integrere til SAPA, forestår en opgave med at drøfte med leverandøren hvordan, hvornår og på hvilke betingelser en integration kan etableres. For systemer, der jf. figur 4 etableres snitflader til via centrale projekter (Kommunernes Ydelsessystem og nyt Sygedagpengesystem, samt eksisterende KMDsystemer med integration til KMD Sag), bør denne integration være relativ let at etablere. Erfaringer med integrationer tilsiger dog, at leverandører ofte vil fremhæve specifikke forhold, der netop vedrører deres kontrakt. Herudover kan en række andre forhold spille ind: Kontraktlængde jo længere fra den nuværende kontrakts udløb, des sværere forhandlingssituation er kommunen i. I forbindelse med en egentlig anskaffelse kan kravene stilles i forbindelse med anskaffelsen, i andre tilfælde vil det være ændringsanmodninger eller selvstændige udviklingsprojekter 3. Overveje konkrete krav Kravene til integrationer kan stilles på flere niveauer fra en hensigtserklæring om at leve op til SAPA-standarderne til et ufravigeligt krav om, at en integration skal være i drift en given dato. KOMBIT skriver selv herom: # v 1 35

37 Det er naturligvis op til den enkelte kommune at beslutte, i hvor høj grad og hvor detaljeret Støttesystemerne skal fremgå af kommunens udbudsmateriale. Detaljeringsgraden kan gå fra en henvisning til Støttesystemernes eksistens til at brugen af Støttesystemerne bliver kravsat som et minimumskrav i udbudsmaterialet. 9 Køge Kommune skal i den forbindelse være opmærksom på, at et konkret krav vil udløse et modkrav om betaling. Drejer det sig fx om integration mellem et ESDHsystem og SAPA kan Køge Kommune således risikere at blive mødt af et krav om at betale den fulde pris for integrationen (og således komme til at betale for udviklingen af integrationen på vegne af alle leverandørens kommunale kunder). Hvis der er usikkerhed om, hvad den konkrete integration indebærer og det vil der være, særligt så længe SAPA-løsningen er under udvikling, og standarderne for integration ikke er færdigspecificerede vil leverandørerne have svært ved at prissætte det. Når leverandører vil have svært ved at prissætte integrationen korrekt, vil de tage en forsikringspræmie ved at indkalkulere usikkerheder og risici ved i deres pris. En mellemform kan derfor være, at Køge Kommune aftaler med leverandøren, at der skal afholdes en workshop med deltagelse af KOMBIT og evt. ekstern rådgivning, der fastslår det konkrete udviklingsbehov og dermed peger på en rimelig prissætning. Alternativt, at leverandørerne angiver prissætningen som en option. Også prissat som option vil der være en forsikringspræmie dvs., at leverandørerne medtager usikkerheder og risici i prissætningen. Fordelen ved at medtage krav, fx i form af optioner, er, at det vil give kommunerne en mulighed for at købe den konkrete udvikling af integrationer ind som en del af kontrakten. 4. Indbringe tvivlsspørgsmål for KOMBIT Der må forudses at opstå en række tvivlstilfælde ved så omfattende et implementeringsprojekt, der påvirker så mange leverandører og så mange brugere. Køge Kommune bør derfor som en del af sin projektorganisering etableret en god kommunikation med KOMBIT. En kommunikation, der fx kan bruges at afklare 9 Vejledning til kommunernes fremtidige it-udbud (støttesystemerne), side 2. # v 1 36

38 muligheder for fælles betaling af udvikling af snitflader på områder, hvor Køge Kommune måtte blive mødt af krav om selvstændig betaling for udvikling af snitflader Værdi for Køge Kommune En lokal business case bør efter Devoteams vurdering indeholde gevinster ved billigere it-drift, ved tidsbesparelser pga. færre klik og større forretningsmæssig værdi pga. større og bedre overblik. Samtidig bør den beskrive de ikke ubetydelige projektressourcer, Køge Kommune bør afsætte Anbefalinger vedr. støttesystemer og Serviceplatform En optimal udnyttelse af støttesystemerne og Serviceplatformen kræver efter Devoteams vurdering en selvstændig projektorganisering, da det er meget omfattende projekt, der vedrører adskillige fagsystemer. Indsatsen i fht. støttesystemer og Serviceplatform kan deles op i to. For det første, hvad der er nødvendigt for at få SAPA til at fungere. For det andet, hvad der er ønskeligt for at få merværdi af støttesystemerne ud over SAPA Nødvendige tiltag i fht. SAPA: KOMBIT står for udvikling og vedligeholdelse af Serviceplatform og støttesystemer. Køge Kommune skal sikre sig, at alle relevante systemer i Køge Kommune kan integrere til SAPA. Jf. ovenfor skal der stilles krav til de enkelte systemer, hvis integrationer til støttesystemer og serviceplatform skal kunne købes på de eksisterende kontrakter. 2. Støttesystemers merværdi for andre fagsystemer Helt generelt giver støttesystemerne en mulighed for, at fagsystemer kan trække direkte på støttesystemerne, således at systemerne ikke indeholder den konkrete komponent. Dvs. at hvis det pågældende fagsystem lever op til standarderne for støttesystemerne og kan integrere via Serviceplatformen, så kan fagsystemet undvære en selvstændig vedligeholdelse af data. 10 KOMBIT udgiver en særskilt vejledning i de kommunale støttesystemer. # v 1 37

39 Devoteam anbefaler derfor, at Køge Kommune gennemgår sin systemportefølje for at analysere, hvilke systemer der har størst mulige gavn af støttesystemerne, særligt af Organisation. En god indikator for, om Organisation er relevant, er om systemet er tværgående, dvs. dækker hele organisationen. Herefter bør Køge Kommune gennemgå de samme skridt som ved SAPA, nemlig at indlede dialog med leverandørerne, overveje konkrete krav og indbringe tvivlsspørgsmål for KOMBIT. 3. Serviceplatformens merværdi Jf. KOMBITs vejledning i Serviceplatformen kan kommunerne bruge den til at få leverandørerne til at udstille deres væsentligste snitflader på den. Devoteam vurderer, at Køge Kommune vil have konkrete værdi ved, at system til system-integrationer sker via Serviceplatformen. Køge Kommune bør derfor analysere, hvilke system til system-integrationer, som kommunen har i dag og/eller ønsker at etablere i dag. Herefter anbefaler Devoteam samme model som for Støttesystemer og SAPA: At indlede dialog med leverandørerne, overveje konkrete krav og indbringe tvivlsspørgsmål for KOMBIT Værdi for Køge Kommune Korrekt implementering af Støttesystemer og Serviceplatform er en forudsætning for at få værdi af SAPA. Herudover er den primære værdi for Køge Kommune ved støttesystemerne på kort sigt sparet arbejdstid ved, at data kun vedligeholdes ét sted. Værdien af integrationer via Serviceplatformen vil på længere sigt være en bedre og løsere koblet it-arkitektur Anbefaling: Plan for genbrug af data Genbrug af data giver Køge Kommune mulighed for dels at undgå selvstændige køb af de såkaldte autoritative data, dels at undgå vedligeholdelse af data. Med Serviceplatformen sikres integrationen med de forskellige registre; som nævnt i afsnit 3, kan Serviceplatformen allerede hente CPR-data. # v 1 38

40 Devoteam anbefaler at 1. Identificere relevante systemer Køge Kommune bør gennemgå sin systemportefølje og sine kontrakter for at identificere, hvilke systemer der i høj grad bruger autoritative data 2. Opsige unødvendige datakøbsaftaler og registeraftaler Køge Kommune bør identificere, om kommunen har unødvendige aftaler om datakøb og registre, som skal opsiges, før udgiften til dem bortfalder. Herefter anbefaler Devoteam samme model som for Støttesystemer og SAPA: At indlede dialog med leverandørerne, overveje konkrete krav og indbringe tvivlsspørgsmål for KOMBIT Værdi for Køge Kommune Køge Kommune har muligheder for at få billigere data på kort sigt og billigere vedligeholdelse af data Anbefaling om principper for deltagelse i projekter Devoteam anbefaler, at Køge Kommune prioriterer aftalte/obligatoriske projekter højere end andre. Jf. afsnit 3 må SAPA, Støttesystemer og Serviceplatform, samt genbrug af data betragtes som de væsentligste aftalte/obligatoriske projekter. I anbefalingen ligger, at Køge Kommune sikrer fuld og hel implementering af disse, før kommunen dedikerer væsentlige ressourcer til andre typer af projekter. Herudover anbefaler Devoteam, at Køge Kommune indgår i / tilslutter sig fælles projekter, hvis der både er udarbejdet en lokal business case, der viser, at Køge Kommune har en merværdi af den, og er ejerskab til business casen i forretningen I forhold til aktiv deltagelse anbefaler Devoteam, at Køge Kommune kun medvirker aktivt i fælles projekter, hvis forretningen (også) allokerer ressourcer. # v 1 39

41 Værdi for Køge Kommune Ved at følge principperne sikrer Køge Kommune, at der er ejerskab i forretningen til at implementere systemet. Hvis forretningen ikke kan finde ressourcer til at udarbejde business casen, eller ikke har ejerskab til den efter udarbejdelsen, mindsker det i væsentlig grad mulighederne for at høste nogen som helst gevinster af projektet. # v 1 40

42 5. Forslag til handlingsplan Devoteam foreslår en kortsigtet handleplan bestående af fem trin for Køge Kommune. Handleplanen vil skulle revideres løbende, fx hvert halve år. I praksis vil der være tale om iterative skridt: 1. Opdatér skabelonen for systemdokumentation 2. Gennemgå eksisterende kontrakter og systemer 3. Kortlæg og overvåg kommende it-kontrakter 4. Prioriter, hvilke kontrakter og systemer, der er mest relevante 5. Indled dialog med leverandørerne Som næste skridt eller evt. sideløbende skridt anbefaler Devoteam: I. Projektorganiserer SAPA-implementeringen i Køge Kommune. II. Udarbejd business case for Køge Kommunes anvendelse af SAPA III. Projektorganiser genbrug af data i Køge Kommune Alle skridt bør tages med involvering af som minimum både den forvaltning, der er systemejer og it-afdelingen. Eksempelvis bør det være en forretningsmæssig afvejning, foretaget af systemejer, hvorvidt det giver forretningsmæssig værdi at integrere et it-system til SAPA. It-afdelingen bør tilsvarende have ansvar for rådgivning om muligheder og begrænsninger ved rammearkitektur og grunddata mv. 1. Opdater skabelonen for systemdokumentation Køge Kommunes systemdokumentation bør udbygges og opdateres, således at den for alle systemer angiver Kontraktudløbsdato Integrationer mellem systemet og andre systemer Scoring (høj, middel, lav) af, hvilken relevans det fælles gods har for det enkelte system SAPA-relevans Serviceplatform-relevans Støttesystem-relevans Genbrug af data-relevans SAPA-relevansen kan indkredses ved at undersøge: hvilke systemer integrerer til KMD Sag i dag? Og hvilke systemer ville Køge Kommune ønske var integreret til KMD Sag allerede i dag? I udgangspunktet vil alle disse systemer være relevante # v 1 41

43 for SAPA-løsningen. Nogle integrationer kan med tiden have mistet deres forretningsmæssige værdi, så det vil være nødvendigt med en konkret afvejning i hvert enkelt tilfælde. Serviceplatform-relevansen kan indkredses ved at kortlægge, hvilke system til system-integrationer, Køge Kommune har i dag, suppleret med de system til systemintegrationer, som Køge Kommune ville ønske, var etableret allerede i dag. Som udgangspunkt vil det være de systemer, der skal udstille deres snitflader på Serviceplatformen, således at fremtidige integrationer kan ske ad den vej. Støttesystem-relevansen kan indkredses ved at beskrive, hvor vigtigt følgende er: Organisation: Vedligeholdes hele eller store dele af kommunens organisation i it-systemet? Beskedfordeler: Er (sagsbehandling i) systemet afhængigt af, hvad der sker i andre systemer? Og vice versa? Klassifikation: Vedligeholdes en omfattende klassifikation, fx KLE, den kommunale kontoplan etc. i systemet? Sags- og Dokumentindeks: Vil det være en fordel, at kunne udstille systemets sager og dokumenter i SAPA-løsningen? Dette kriterium vil være delvist overlappende med kriteriet for at afgøre, om systemet er SAPA-relevant. Ydelsesindeks: I hvilket omfang indeholder systemet ydelser til borgere, som det er relevant at udstille i SAPA-løsningen? Dette kriterium vil være delvist overlappende med kriteriet for at afgøre, om systemet er SAPA-relevant. Adgangsstyring og administration: Alle systemer, der bruger rammearkitekturens komponenter (støttesystemer og Serviceplatform) skal kunne anvende støttesystemet Adgangsstyring og administration for at leve op rammearkitekturens sikkerhed. Genbrug af data-relevansen kan indkredses ved at analysere, i hvilket omfang Systemet har karakter af et skyggeregister, som helt kan undværes, når genbrug af data er fuldt indfaset. Det kunne fx være Ejendoms- og Stamregistret (ESR). Systemet vedligeholder store datamængder, der er delmængder af de autoritative data. Kommune flere gange indkøber samme/overlappende sæt af data. # v 1 42

44 6. Perspektivering Analysen har peget på en række afledte forhold ved at skabe værdi af det fælles gods. Disse afledte forhold analyseres ikke nærmere i dette white paper. Væsentligt behov for projektressourcer, fx til både teknisk og organisatorisk projektledelse. Implementeringen af SAPA mv. stiller krav til både tekniske og organisatorisk projektledelse i Køge Kommune. Det er en forudsætning for at realisere den fulde værdi, at opgaverne bemandes med de rigtige kompetencer og med tilstrækkelige timer, jf. også Drejebogens betragtninger herom. Behov for stærkt forretningsengagement. Langt de fleste valg og overvejelser for at skabe værdi af det fælles gods forudsætter et stærkt forretningsmæssigt engagement. Fx for at vurdere, hvilke systemer der skal integrere til SAPA, og hvilke systemer der skal integrere til autoritative grunddata. I det hele taget kræver monopolbruddet og den samlede transition et stærkere kommunalt engagement end hidtil også fra forretningens side. Principper for it-anskaffelser. Devoteam vurderer, at det kan være en fordel for Køge Kommune at formalisere, hvilke principper der skal gælde i it-anskaffelser, herunder hvilke krav til indarbejdelse af rammearkitektur og grunddata der er i forskellige typer af anskaffelser. Fælles business case model. Køge Kommune bør have en fælles business case model for at kunne prioritere deltagelse på tværs af projekter og for at sikre gevinster af projekter og anskaffelser. Dette vil også gøre det lettere at imødekomme KOMBITs anbefalinger om gevinstrealiseringsplaner. Øget samarbejde med andre kommuner som en strategisk valgmulighed. Som analysen har vist, er der rigtigt meget fælles gods, som Køge Kommune skal forholde sig til. Det kan derfor overvejes at etablere faste samarbejder og en aftalt arbejdsdeling mellem flere forskellige kommuner. # v 1 43

45 # v 1 44

46 7. Henvisninger I det følgende er samlet en række kildehenvisninger, som er relevante i Køge Kommunes videre arbejde med udmøntningen af det fælles gods. Henvisningerne er inddelt i kategorier svarende til indholdet i afsnit 3 om det fælles gods. Køge Kommune bør holde sig opdateret løbende særligt i fht. KOMBITs vejledninger om monopolbrud OIO EA arbejdet Arkitekturguiden Overblik over den fællesoffentlige arkitektur og de fællesoffentlige infrastrukturkomponenter. Åbne standarder vejledning Vejledning til de syv sæt af åbne, obligatoriske standarder. Udviklingsvejledning for selvbetjeningsløsninger 24 fællesoffentlige krav til selvbetjeningsløsninger og vejledning i opfyldelse af dem. Herunder krav til brugergrænseflade Fælles strategier og planer Den Fællesoffentlige Digitaliseringsstrategi Strategien, som er aftalt mellem staten, Danske Regioner og KL. Denne strategi indeholder en række mere eller mindre konkrete initiativer, og den underbygger og sætter rammer for den fælleskommunale strategi. Grunddataprogrammet. Grunddataprogrammet, som er et initiativ under den fællesoffentlige digitaliseringsstrategi, beskriver alle initiativerne for at sikre adgang til autoritative data. Den Fælleskommunale Digitaliseringsstrategi Den overordnede strategi, som er aftalt mellem kommunerne i regi af KL. Handlingsplan for den fælleskommunale digitaliseringsstrategi Handlingsplanen er en plan for udmøntning af den fælleskommunale strategi, og indeholder de konkrete initiativer Den fælleskommunale rammearkitektur # v 1 45

47 Den Fælleskommunale Rammearkitektur Notat med fokus på overordnede begreber, hvor særligt begrebet forretningsservices uddybes. Notatet tilbyder en overordnet forståelse af rammearkitekturen, men giver ingen konkrete handlingsanvisninger. Fælleskommunale arkitekturprincipper, version 1.0 Notat med en operationalisering af rammearkitekturen i generelle, handlingsanvisende principper. Krav og vejledning til kommunernes fremtidige it-udbud Vejledningen beskriver, hvordan kommunerne kan stille krav om integrationer til Serviceportalen. Fælles kommunal rammearkitektur og konkrete støttesystemer Oplæg af Mette Kurland fra KOMBIT om den fælleskommunale rammearkitektur ved Association of Enterprise Architects møde på ITU d. 6. marts Indeholder et opdateret overblik over indholdet i rammearkitekturen Øvrigt relevant materiale Digitaliseringsstrategi Køge kommune Køge Kommunes vedtagne digitaliseringsstrategi. Modenhedsmodel Model til måling af kommunernes digitale modenhed inklusiv måling af godt 20 kommuners modenhed udarbejdet af KL og Devoteam. # v 1 46