BESLUTNINGSMATERIALE Bilag samlet 1 - os2.eu · 02.11.2015 med leverandøren, Xebia. Odense MO er et klientsystem til organisationskomponent KMD APOS2. MO indeholder en brugergrænseflade,

BESLUTNINGSMATERIALE

Bilag samlet 1.0 Dato 21.3.2016

BESLUTNINGSMATERIALE OS2MO – Bilag Samlet - Side 2 af 59

Indholdsfortegnelse Bilag 1 – Analyser af relevante initiativer ............................................................................................. 3

Bilag 2 – Arrangementer i analysefasen ................................................................................................. 6

Bilag 3 – Arkitekturprincipper for OS2MO ........................................................................................... 7

Bilag 4 – Løsningsbeskrivelse af OS2MO ................................................................................................ 9

Bilag 5 – Faseplan for OS2MO projektet ............................................................................................... 17

Bilag 6 – Tidsplan for OS2MO projektet ............................................................................................... 29

Bilag 7 – Budget for udvikling af OS2MO 1.0 ..................................................................................... 32

Bilag 8 – Interessentanalyse for OS2MO projektet .......................................................................... 33

Bilag 9 – Risikoanalyse for OS2MO projektet ................................................................................... 36

Bilag 10a – Den lokale businesscase ..................................................................................................... 40

Bilag 10b – Lokal businesscase beregner ........................................................................................... 46

Bilag 10c – Organisationsændring ......................................................................................................... 47

Bilag 11 – Projektet kort fortalt .............................................................................................................. 52

Bilag 12 – Executive summery ................................................................................................................. 55

Bilag 13 – Tilslutningsaftale til OS2MO ............................................................................................... 59


Bilag 1 ANALYSER AF RELEVANTE INITIATIVER

Indhold af Bilag 1 Evaluering af VeRA ...................................................................................................................................... 3

Konklusion ................................................................................................................................................. 4

Evaluering af LoRA ...................................................................................................................................... 4

Konklusion ................................................................................................................................................. 5

Evaluering af Odense Mo .......................................................................................................................... 5

Evaluering af VeRA

Evalueringen er baseret på et møde, afholdt d. 18.9.2015 med VeRA og IT-Minds, samt en gennemgang af systemdokumentationen og udviklingsmiljøet.

VeRA er et projekt, lavet i samarbejde mellem 5 nordjyske kommuner, med Hjørring som tovholder. Projektets formål er at hjælpe samarbejdskommunerne med at løse de opgaver, de har i forbindelse med Monopolbruddet med et fælles system, fælles arkitektur og evt. fælles drift. VeRA er et infrastrukturprojekt med det formål at danne fundament for integration af andre it-komponenter, herunder håndtering af beskeder og servicekald.

Positivt Udfordringer

Teknologistakken, som projektet bygger på, er simpel, velvalgt og bygger på main stream, velafprøvede open source-teknologier.

Løsningen mangler setup ift. drift, overvågning, systemtest, logning, dokumentation samt fejlhåndtering. Desuden mangler en brugergrænseflade og et administrationsmodul.

Løsningen bygger på sunde arkitekturprincipper – og et godt ”manifest” om at se, hvor langt man kan nå for få midler.

Løsningens status kan karakteriseres som ”Proof of Concept” og er ikke egnet til at anvende i et forretningskritisk produktionsmiljø.

Løsningen kan ses som en Proof of Concept på realisering af rammearkitekturen, og det vil være oplagt for OS2MO at bygge videre på den. Der er investeret omkring 350 udviklingstimer i løsningen, og de fleste kan genbruges.


Konklusion VeRA kan være et aktiv for OS2MO-projektet i forhold til at bygge videre på erfaringer og setup med en del af de valgte open source-teknologier. Der vil være en mulig besparelse på ca. 150 timer for OS2MO-projektet. Hvis VeRA i regi af OS2MO modnes til at kunne anvendes i et produktionsmiljø, vil OS2MO kunne anvende VeRA som en nødvendig infrastrukturkomponent til beskedhåndtering og kommunikation mellem de forskellige komponenter, som vil indgå i en kommunes arkitektur.

Evaluering af LoRA

Evaluering, baseret på møde 2.10.2015 med Frederiksberg Kommune og Magenta, samt fremsendt materiale, som består af systemdokumentation.

Projektet har udviklet fire services i et samarbejde mellem Frederiksberg Kommune, som har stået for Organisationservice og SAML sikkerhed POC, ’Fælles sprog III’, som har stået for Klassifikationservice, og ’Sager på tværs’, som har stået for Dokument- og Sagservice.

De fire services giver en implementering af Klassifikation og Organisation, samt Dokumentversion 1.1.1 og Sagversion 1.2.


Projektet er gennemtænkt mht. den sammenhæng, som løsningen skal indgå i, og afhængighederne i Frederiksberg Kommunes interne it-landskab, bl.a. ift. at få implementeret en IDM-løsning, og samtidigt håndtere tankerne fra KL’s Rammearkitektur.

Løsningen har, udover rammearkitekturen, valgt at bygge på en række arkitekturprincipper, der giver en stærk binding til bl.a. en bestemt databaseteknologi (PostgreeSQl, som er valgt pga. bitemporale egenskaber), som kan give udfordringer med udvikling og afhængigheder til andre løsninger.

Der er et gennemtænkt governance setup mht. den lokale anvendelse i Frederiksberg Kommune.

Løsningen er bygget i både JAVA og også Python. Valget af teknologistak giver udfordringer ift. maintainability, da der er en meget begrænset mængde udviklere på det danske marked, som kan videreudvikle i dette sidstnævnte sprog.

Det kan betragtes som en pilot-afprøvning af KL’s Rammearkitektur ift. Organisation, Klassifikation, samt Sag og Dokument.

Løsninger er bygget op med stored procedures i databasen. Det er erfaringsmæssigt svært at teste og vedligeholde systemer, der vælger at gemme et logisk lag i selve databasen i form af stored procedures, sammenholdt med systemer, som gør det i applikationslaget. Denne løsning vil på sigt gøre det svært at teste og genskabe fejl og kvalitetssikre opdateringer.

Løsningen mangler et setup omkring automatiseret test, hvilket på langt sigt kan


resulterer i et ustabilt system. Det er essentielt, at contract-first systemer, såsom webservices, har gennemtestede snitflader.

Løsningen udstiller ikke data som OIOXML, som er det eneste officielle udvekslings-format, defineret af Sag & Dokument-standarderne, men bruger et mere moderne, fysisk dataformat: JSON. Det vil i praksis betyde, at data skal konverteres til systemer, der bruger OIOXML, hvilket dog er er en forholdsvis nem procedure.

Konklusion Vedligeholdelse og governance omkring kildekoden til LoRA vil ikke være et aktiv for OS2MO-projektet. Til gengæld kan skemaer, specifikationer og forretningsviden være et aktiv for OS2MO-projektet. Især kan det give mening med et samarbejde om interoperabilitet, hvor OS2MO UI kan fungere som frontend til LoRA. Desuden er der et perspektiv i, at LoRA genbruger OS2MO’s setup til automatiseret test.

Evaluering af Odense Mo

Evaluering, baseret på gennemgang af kildekode, systemdokumentation og samtale den 02.11.2015 med leverandøren, Xebia.

Odense MO er et klientsystem til organisationskomponent KMD APOS2. MO indeholder en brugergrænseflade, et konfigurerbart lag til en kommunes forretningsregler, og udstiller forretningsservices til løsning af kommunens opgaver ved hjælp af komponenter fra rammearkitekturen, såsom “Ansæt medarbejder” eller “Flyt forretningsenhed”. MO giver dermed slutbrugerne muligheden for at udføre komplekse administrative opgaver uden at skulle forholde sig til den kompleksitet, som sag og dokumentstandarderne indeholder.


MO bygger på en teknologistak som er simpel, velvalgt og bygger på mainstream, velafprøvede open source-teknologier. Systemarkitekturen er lagopdelt, og de forskellige lag kommunikerer ved hjælp af velafgrænsede services.

Løsningen mangler en stabil backend, men vil kunne anvende den kommende OS2MO.

Brugergrænsefladen er opbygget i AngularJS, som har resulteret i en brugervenlig webklient.

Løsningen er pt. Odense-specifik og skal delvist gentænkes mht. anvendelse i andre kommuner som en del af OS2MO.

Løsningen er opbygget efter udviklingsprincippet Continuos Delivery og er fuldt automatiseret ift. test og installation.

Konfigurerbare forretningsregler er pt. lavet som Proof of Concept, og dette lag skal udbygges i forhold til at kunne anvendes af andre kommuner som en del af OS2MO.


Bilag 2 ARRANGEMENTER I ANALYSEFASEN

Inspirationsdag om organisationsdata, 28.10.2015

I kontakten med kommunerne blev projektgruppen hurtigt opmærksom på det store informationsbehov, der er i kommunerne mht. arbejdet med organisationsdata. Både hvad organisationsdata er for en størrelse, og hvordan man aktivt arbejder med grunddata i en autoritativ kilde. Derfor arrangerede projektgruppen en inspirationsdag i efteråret 2015 med oplæg af erfarne, relevante oplægsholdere omkring organisationsdata.

Med tilladelse fra KOMBIT blev invitationen sendt ud både til projektledere på Støttesystemerne og til Monopolbrudsprogramlederne. Leverandører og andre interesserede fik invitationen via LinkedIN-gruppen for OS2.

Dagen blev en succes med over 175 deltagere fra 71 kommuner, 12 leverandører og en enkelt region. Oplæggene blev efterfølgende udsendt med kommenteret indhold, således at deltagerne kunne anvende materialet hjemme i deres egne kommuner, når de skulle i gang med eller forsætte arbejdet med at få styr på deres organisationsdata. Projektgruppens formål med dagen var at øge kendskabet til projektet med OS2MO, inspirere, samt give deltagerne materiale med hjem til det videre arbejde.

Efter arrangementet blev der sendt et kort spørgeskema til deltagerne, som 32 har besvaret. Blandt besvarelserne angiver 74 %, at de skal have en lokal organisationskomponent, og 63 % siger, at det er vigtigt eller meget vigtigt for dem at få OS2MO. En del respondenter efterlyser et klart overblik over, hvad løsningen vil koste dem, samt en klar og realistisk tidsplan. Samtidigt er det væsentligt for nogle af deltagerne, at OS2MO er klar inden Støttesystemerne og understøtter Monopolbruddet, da man ikke mener at kunne implementere en organisationskomponent samtidig med monopolbruddet. En del respondenter giver desuden udtryk for, at en væsentlig del af gevinsten ved at lave en organisationskomponent i fælleskommunalt regi, er, at der kan deles procesdokumenter, der understøtter den enkelte kommune i implementeringsfasen.

Krav til OS2MO-Workshop, 6.11.2015

Som led i at sætte rammerne for OS2MO, har der den 6. november været afholdt en workshopdag, for relevante it-arkitekter og relevante leverandører. Dagen rummede både, hvad deltagerne så som de største risici/udfordringer, samt hvilke features/krav, som løsningen skulle leve op til. Samtidig blev arkitekturprincipperne for OS2MO debatteret. Dagen endte med, at deltagerne fik givet projektet god inspiration til prioriteringen af indhold i løsningen. Resultaterne fra dagen kommer til at indgå i projektets løsningsbeskrivelse.


Bilag 3 ARKITEKTURPRINCIPPER FOR OS2MO

OS2MO kommer til at være en central arkitekturkomponent, og derfor at det vigtigt at have en række gode arkitekturprincipper at bygge løsningen ud fra. Projektet følger KL’s arkitekturprincipper som udgangspunkt. Nedenstående er projektets bud på principper, som løsningen vil blive bygget ud fra.

1. Gør det simpelt – og enkelt: Fokus på enkelthed og at skabe simple og holdbare løsninger, hvor der ikke bliver overdesignet eller overtænkt. Samtidig er det en forudsætning for at komme sikkert i mål, at der hele tiden er fokus på enkelthed og ”Need to have”, for at projektet holder tidsplanen og leverer en funktionel løsning.

2. Delivery: I udviklingsfasen anvendes Continous Delivery Process – altså løbende levering og forbedringer af løsningen, kvalitet og funktionalitet.1 Herved fastholdes et skarpt fokus på kvalitet, hvorved der kan spares en faktor 10 i forhold til andre delivery-metoder.

3. Udviklingsmetode: Projektet anvender Behavior Driven Development som metode, der er den næste generation af de agile udviklingsmetoder. Derved fastholdes fokus på at skabe forretningsværdi, hvorved der kan spares en faktor 10 i forhold til andre udviklingsmetoder. Tilsammen giver fokus på metode og proces knivskarpe IT-projekter og maximal værdi med mindst mulig økonomi.

4. Open source – bygger videre på et solidt grundlag: Vælger udbredte open source-projekter med stabilt community og godt vækstpotentiale.

5. Vi foretrækker Genbrug, men stiller krav til kvalitet og stabilitet af løsninger og komponenter før de genbruges. Det er vigtigt for at have en stabil udviklingsplatform. Udfordringen vil løbende være at overveje genbrug ift. at udvikle på ny. Nogle gange kan genbrug være mere ressourcekrævende, hvis ikke fundamentet i det, der skal genbruges, er i orden.

6. Vi foretrækker Automatisering af tidskrævende systemopgaver – fx testning, opsætning af servere, udrulning mv. Samtidig begrænser det mængden af fejl ved manuelle processer.

7. Interoperabilitet: Løsningen skal udstille åbne snitflader og derved give mulighed for adgang til data. Data skal være tilgængelige via Services og følge OIO Sag- og Dokument-

1 https://en.wikipedia.org/wiki/Continuous_delivery

https://en.wikipedia.org/wiki/Continuous_delivery


standarderne. Andre systemer, som understøtter Sag- og Dokument-standarderne, skal kunne bruge de services, som OS2MO udstiller.

8. Compliance: Løsningen skal være compliant med andre nationale initiativer (tekniske standarder, der er optaget i OIO-kataloget, Den Fælleskommunale Rammearkitektur, Grunddataprogrammet og KOMBIT Støttesystemer)

9. Anvendelighed og Brugervenlighed: Løsningen skal være brugervenlig og effektiv. Den skal kunne give overblik og understøtte løsning af de kommunale opgaver. Den skal kunne anvendes i såvel små som store kommuner i både simple og avancerede setups med andre systemer. Løsningen er løskoblet i sin arkitektur og kan anvendes på mange måder.

10. Sikkerhed: Da vi har med personfølsomme data at gøre, skal sikkerhed have højeste prioritet. Autorisations- og autentifikationsmetode skal kunne tilpasses de enkelte kommuners behov. Løsningen vil derfor kunne understøtte både adgang, baseret udelukkende på Active Directory-informationer, og også arbejde med federeret adgang, baseret på SAML2 tokens, systemroller og jobfunktionsroller (som det bruges i den Fælleskommunale Rammearkitektur). Risikoanalyse, beredskab og forholdsregler skal være på plads i forhold til den daglige drift af løsningen.

Projektet forventer med ovenstående principper at kunne levere kvalitet og

forretningsværdi uden at bruge unødige ressourcer på overflødigt indhold eller processer,

som kan automatiseres, og derved undgå manuelle arbejdsgange.


Bilag 4 LØSNINGSBESKRIVELSE AF OS2MO

Indhold i bilag 4 Løsningsbeskrivelse for OS2MO – overordnet ................................................................................ 9

Organisations- og klassifikationsstandarden ........................................................................... 11

Det får du med OS2MO ........................................................................................................................... 11

OS2MO som open source .................................................................................................................. 12

Løsningsbeskrivelse af OS2MO – løsningen konkret ................................................................. 13

Hvilke oplysninger rummer OS2MO? .......................................................................................... 13

Hvilke arbejdsgange understøtter OS2MO ................................................................................ 14

Autoritative oplysninger ................................................................................................................... 15

Hvordan kan OS2MO indgå i den daglige drift? ....................................................................... 15

Løsningsbeskrivelse for OS2MO – overordnet

”OS2MO pakker KL’s rammearkitektur pænt ind og implementerer den i de enkelte kommuner, direkte i motorrummet som grundlæggende it-arkitektur som platfom for samarbejde” OS2MO-projektleder Henriette Juul Riishøj

Løsningen vil være den autoritative kilde for medarbejder- og organisationsdata i den enkelte kommune. OS2MO indeholder dermed stamoplysningerne på medarbejderne og organisatoriske enheder, herunder også oplysninger om ledere i den enkelte enhed. Men ud over medarbejderne holder OS2MO også styr på alle de andre personer med relation til kommunen, der ikke er at finde i lønsystemet. Når der skrives Medarbejdere i det følgende, menes alle personerne i kommunen. Således rummer OS2MO hele den administrative organisation med alle de relevante stamdata og udstiller dem, så de kan genanvendes på tværs af kommunens systemer. På længere sigt kan OS2MO også rumme kommunens øvrige organisationer som løn-, politisk-, projekt- og MED-organisation. OS2MO er ikke nødvendigvis der, hvor oplysningerne bliver skabt, men her bliver de opbevaret og videreformidlet til relevante aftagere, f.eks. AD’et.

Medarbejder og Organisation (MO) er således en løsning, hvori kommunen kan beskrive hele sin organisation. Således skabes en autoritativ kilde for disse stamdata, og derfra kan andre systemer hente relevante organisatoriske oplysninger. Ved ændringer, f.eks. fordi en medarbejder flytter afdeling eller ved organisatoriske forandringer, er det kun nødvendigt at opdatere MO, for at det falder på plads i de andre systemer. MO er således ikke bare en


løsning, men også et system, der vil bestå af forskellige dele i en løskoblet arkitektur og i en sammenhæng, der gør det let at implementere og anvende.

Med OS2MO som autoritativ kilde er det vigtigt trække på at en række oplysninger fra eksterne grunddata-kilder, eksempelvis adressedata eller CPR som grundlag for organisationsdataene. CPR- og adresseoplysninger vil blive hentet fra Serviceplatformen eller fra andre kendte webservices, der udstiller Grunddata.

Med OS2MO er det et mål at undgå manuelle fritekst-indtastninger, men at anvende klassifikation til at vælge sammensætningen af de organisatoriske data. Dette bidrager til at skabe valide, ensrettede, organisatoriske grunddata, f.eks lederkategorier og titler. Organisatorisk data af denne art skal i stedet bygges på en klassifikation, således at data ensrettes på tværs af den enkelte organisation. Klassifikationsdelen af OS2MO vil indeholde klassifikationer omkring titler, lederniveauer og –ansvar, ansættelsesformer og organisatoriske enheder, som defineres i en lokal kontekst, samtidig med at OS2MO også bliver kommunernes kilde til fællesoffentlige klassifikationer som KLe.

OS2MO kan indgå i en besked- og hændelsesorienteret arkitektur, hvorfor løsningen udstiller beskeder i standardiseret format til andre systemer, der er modne til at modtage disse.

OS2MO kan fungere som Master til Støttesystemerne Organisation og Klassifikation, og opdatere med de oplysninger, disse har brug for. Derfor følger projektet løbende udmelding


fra KOMBIT på dette område og sikre, at OS2MO’s funktionalitet understøtter, hvad der forventes af den lokale Master.

Organisations- og klassifikationsstandarden I sin basisstruktur vil OS2MO bestå af en kerne (en database samt services), bygget på baggrund af Organisation- og Klassifikationsstandarderne, version 1.1. (OIO Organisation, OIO Klassifikation og Generelle Egenskaber) samt på baggrund af kravene til KOMBITS Støttesystemer Organisation og Klassifikation med mulighed for fremadrettet at kunne understøtte nye versioner af standarden.

Organisation- og Klassifikationsstandarderne rummer en række uhensigtsmæssigheder, hvorfor MO rummer de mest anvendte forretningsregler med mulighed for at konfigurere disse. OS2MO leveres dog med en standardkonfigurering.

Standarderne er også meget modellerbare og har i en kommunal kontekst brug for at blive styret af et sæt forretningsregler for at skabe konsistente data. Derfor vil OS2MO rumme de mest anvendte forretningsregler. Disse er opsamlet på baggrund af erfaringer fra kommuner, der har arbejdet med lokale organisationskomponenter og standarderne i praksis. OS2MO er lavet således, at forretningsreglerne samt de anvendte klassifikationer vil være lette at konfigurere og tilpasse til lokale behov.

OS2MO vil kunne tilgås via et REST API (webservices), hvorigennem andre systemer kan hente og opdatere data i OS2MO. Derved kan OS2MO indgå i de eksisterende system-setups, eksempelvis med AD eller IDM. OS2MO vil i senere versioner kunne rumme brugerstyring, dog er det vigtigt for projektet at fokusere på at skabe en version 1.0 først. Projektgruppen er bevidst om, at de fleste kommuner primært har samlet deres organisationsdata i AD’et, så derfor vil en version 1 indeholde en integration hertil ift. udveksling af organisationsdata. OS2MO udveksler også data som OIO xml jf. standarderne, således at data udstilles i dette format og kan opdateres ligeledes jf. denne teknologistak.

Det får du med OS2MO

OS2MO er ikke bare en it-løsning, men også et fælleskab. OS2MO vil understøtte kommunerne med at få implementeret Rammearkitekturen. Det er langt fra alle landets kommuner, der har it-arkitekter ansat, som kan sikre, at der bliver truffet de rigtige arkitekturvalg. En del af løsningen til dette kan være samarbejde og fælles projekter på tværs af kommunegrænser samt erfaringsudveksling omkring implementerings-udfordringer. Erfaringer med implementering af organisationskomponenter viser, at der er udfordringer med at beskrive ens organisation, få den lagt i en it-løsning, beskrive de nødvendige forretningsregler, opbygge de nødvendige processer til håndtering af organisationsændringer samt efterfølgende stille krav til leverandørende.

For at tage hånd om dette vil OS2MO trække på erfaringerne og anvende best practices som udgangspunkt for løsningen og implementeringen. Projektet vil understøtte, at der bliver skabt rammer for, hvordan man beskriver sin organisation, hvilke klassifikationer man anvender, hvilke forretningsregler der skal anvendes, samt hvad begreberne betyder. Det


vil være et godt grundlag for det videre samarbejde mellem kommunerne, bl.a. når der skal udvikles snitflader til forskellige fagsystemer, at kommunerne har samme forståelse af begreberne, og de bliver anvendt på samme måde. Der skal dog være plads til forskellighed, og dette håndteres løbende i projektet. Projektet vil derfor ikke efterlade kommunerne med den opgave selv at opfinde den dybe tallerken, når det gælder implementeringen og anvendelsen af en organisationskomponent.

OS2MO som open source OS2MO udvikles i open source. I det følgende beskrives, hvad det betyder for OS2MO løsningen og for det fremtidige samarbejde med leverandørerne.

OS2 baserer sig på at have alle intellektuelle rettigheder til det fabrikerede ”værk” (programmeringen/koden), dets dokumentation samt til de øvrige produkter, der kommer ud af et OS2-projekt – fx designet. Dette er formuleret i det juridiske notat ”Floss aftale af den 26.04.2015” som blev vedtaget på OS2-generalforsamlingen i maj 2015. Der skal henvises til Floss-aftalen ved enhver aftale om leverancer, der indgås mellem en OS2-leverandør og en OS2-offentlig partner.

Floss-aftalen kan læses her: http://www.os2web.dk/sites/default/files/OS2%20FLOSS%20Aftale%20v1%20%2826-04-2015%29_0.pdf

I og med at OS2 arbejder med at leve op til den fælleskommunale digitaliseringsstrategis indhold og ånd omkring ejerskab, har det været naturligt for OS2 at omsætte dette ejerskabsbegreb i en relativt fri licens, som OS2-produkterne frigives under. OS2 har valgt Mozilla Public License (MPL 2), licensen for programmeret kode, og Creative Commons (CC 4 BY-SA) som licens for dokumentation, designstruktur mv.

http://www.os2web.dk/sites/default/files/VejledningLicensTekster.pdf

Begge licensformer er såkaldte permissive licenser. Det betyder, at licenserne giver mulighed for at OS2-produkterne kan benyttes i sammenhæng med andre kommercielle løsninger uden at stille krav til den licens, den kommercielle del består af.

I praksis betyder det, at OS2-produkterne godt kan indgå i løsninger, som sælges til en given virksomheds kunder på almindelige kommercielle vilkår. Kravet er, at leverandøren blot skal gøre kunderne opmærksomme på, at der benyttes et frit OS2-produkt i løsningen.

Det eneste tidspunkt, hvor OS2’s MPL 2-licens stiller krav om, at leverandørerne skal ”give” noget tilbage til OS2-fællesskabet er, hvor leverandøren modificerer eller på anden måde ændrer den kode (de filer), OS2-produktet består af. Det, som leverandøren ændrer eller tilføjer til det konkrete OS2-produkt, skal gives tilbage til OS2-fællesskabet.

For leverandører, der er OS2-partnere, gælder der yderligere et sæt adfærdsregler: OS2 har lavet et Code of Conduct, som alle leverandører skal skrive under på, hvis de vil være medlem af OS2-netværket. Code of Conduct skal sikre, at leverandørerne overholder en bestemt adfærdskodeks om åbenhed og samarbejde overfor offentlige OS2-partnere, samt over for de øvrige OS2-leverandørpartnere i OS2-fællesskabet.

http://www.os2web.dk/sites/default/files/OS2%20FLOSS%20Aftale%20v1%20%2826-04-2015%29_0.pdf

http://www.os2web.dk/sites/default/files/OS2%20FLOSS%20Aftale%20v1%20%2826-04-2015%29_0.pdf

http://www.os2web.dk/sites/default/files/VejledningLicensTekster.pdf


For OS2MO betyder det at blive udviklet under disse open source-licenser, at man får en løsning, der frit kan benyttes af fællesskabet, og hvis der er nogen udenfor fællesskabet, der udvikler videre på den oprindelige kode, skal de give dette tilbage til OS2MO-fællesskabet. Samtidig giver det et frit valg af partner ift. videreudvikling af løsningen. OS2MO vil understøtte dette ved at have høje krav til dokumentation og kvalitet, for at et udviklet element bliver optaget i den officielle, godkendte version.

Løsningsbeskrivelse af OS2MO – løsningen konkret

OS2MO er en løsning til at holde styr på medarbejder- og organisationsoplysninger som autoritativ kilde for kommunens stamoplysninger. Nedenstående er en udbygning af ovenstående, og der gås mere i detaljen med selve løsningen. Dog er det ikke en arkitekturgennemgang af løsningen, men en praktisk orienteret beskrivelse, hvor læseren kan få en forståelse af løsningen, og hvad man får med OS2MO.

I det følgende beskrives løsningen som den forventes i version 1.0. Her fokuseres der på, hvilke oplysninger løsningen håndterer, hvilke arbejdsgange løsningen understøtter, og hvordan løsningen sikrer, at der kan rettighedsstyres på de enkelte handlinger. Beskrivelsen tager udgangspunkt i brugergrænsefladen. Arkitekturen er løskoblet i OS2MO, således at opdatering af data også kan ske via ekstern kilde. Afslutningsvis i denne løsningsbeskrivelse beskrives, hvordan løsningen kan indgå i en kommunal kontekst og være autoritativ kilde for organisationsoplysninger både ift. AD og ift. Støttesystemerne.

OS2MO er skabt på baggrund af brugsmønstre i Odense Kommune, og derfor er brugergrænsefladen bygget til at optimere workflows, når medarbejdere starter, flytter rundt og stopper, samt når der er ændringer i organisationen. Handlingerne er de samme, om man er en stor eller lille kommune, men det kan variere, hvem man har til at udføre opgaven i praksis – om vedligeholdelse sker centralt eller man har valgt at lægge dele af det ud decentralt.

Alle oplysninger, som MO rummer, er styret af datoer. Dvs. alt har en start- og en stop- dato – beskrivende for den periode, en oplysning ”lever”. Ofte er stopdatoen ikke sat, men bliver det, når et ansættelsesforhold stoppes. Datoer er med til at styre, at de oplysninger, man indtaster/opdaterer, hænger sammen, f.eks. at en ansat reelt er ansat i en afdeling i det tidsrum, som afdelingen eksistere. Og at der ligeledes er forretningsregler, der er styrende for disse handlinger.

Hvilke oplysninger rummer OS2MO? OS2MO rummer oplysninger om personer med relation til kommunen og den administrative organisation, som de er en del af. Personer med relation til kommunen er ofte en udfordring at holde styr på i kommunernes systemer, da man ofter glemmer at få dem stoppet eller slettet, når der er ophørt med at have en relation til kommunen. Alle oplysningerne er struktureret ud fra klassifikationer, struktureret efter hvilken type af oplysning, det er. (I en brugergrænseflade ses klassifikationerne ofte som en dropdown med prædefineret klasser). F.eks. er titel en klassifikation. I det følgende vil betegnelsen Medarbejdere blive brugt som fællesbetegnelse for både medarbejdere, altså personer, der også er at finde i lønsystemet, og for personer, der har en relation til kommunen, men ikke er at finde i lønsystemet.


Den administrative organisation er bygget op af enheder eller afdelinger i et hierarki af over- og underenheder. Enhederne er overordnet struktureret ud fra, hvilken type af enhed de er, f.eks. team, center, stab mv. Enheder har altid en lokation, dvs. deres fysiske adresse, med tilhørende kontaktoplysninger, f.eks. telefonnr., telefontid, åbningstid mv. Medarbejderne har derfor en relation til enhederne, hvor de arbejder, og hvor de reelt fysisk er at finde. En anden vigtig oplysning vedr. enheder er, hvilke opgaver denne enhed har ansvar for at løse, i form af KLe-opmærkning. Denne er vigtig at have styr på i relation til Monopolbrudssystemerne og hhv. adgang og dataafgrænsning i disse systemer.

Ofte er en stor del af vores fokus på de medarbejdere som er it-brugere, og ofte ”glemmes” alle de mennesker som ikke i det daglige har en it-understøttelse af deres virke. OS2MO kan håndtere alle medarbejderne, ikke kun it-brugerne. Derfor bruger vi i MO betegnelsen engagementer for at beskrive, at en person har en relation til den administrative organisation.

Personerne beskrives både via deres navn og deres CPR. nr., hvilken type af engagement personen har i organisationen, samt titel på personen. Engagementer knyttes ”fast” på enheder. Således har personen nu en relation til organisationen og kan f.eks. tilknyttes et antal enheder, f.eks. en skolesekretær, der arbejder på to skoler. Med engagementer kan man også håndtere, at en person kan have flere engagementer i organisationen, f.eks. være skolelærer i dagtimerne og frivilligkoordinator på et plejecenter i weekenderne.

Enhederne har ledere, der er en ”rolle” i organisationen. I Organisationsstandarden er dette en Organisatorisk Funktion. Ledere beskrives både ud fra, hvilken type af leder, de er, f.eks. chef, teamleder mv. (lederfunktion), hvilket lederniveau de har, og deres lederbetegnelse (stillingsbetegnelse), lederansvar, f.eks. personaleansvar, økonomiansvar mv.

En anden vigtig oplysning ift. engagementerne i organisationen er, om de er it-brugere eller ej. Dette kan MO også håndtere, og der er her perspektiver i at udbygge med IDM, hvilket dog ikke er med i første version af løsningen. MO rummer også oplysninger, om en person i organisationen har et telefonnummer eller en emailadresse, hvilket er oplysninger beskrevet som kontaktkanaler. Kontaktkanalerne kan klassificeres efter, hvordan de må anvendes, dette gælder både kontaktkanaler på engagementer og enheder. Her kan relevante klassifikationer være ”Må vises ekstern/internt”, ”Må vises internt”, ”Hemmeligt” – således at kontaktkanelens oplysninger kan formidles videre og anvendes efter behov, f.eks. i kommunens omstilling.

Hvilke arbejdsgange understøtter OS2MO Alle ovenstående oplysninger skal selvfølgelig opdateres enten gennem brugergrænsefladen, via beskeder eller via webservices. I det følgende beskrives kort, hvilke arbejdsgange MO understøtter gennem brugergrænsefladen.

I forbindelse med vedligeholdelse af personer med relation til kommunen rummer MO workflow til:

At oprette engagementer med alle dertilhørende oplysninger, f.eks. stillingsbetegnelser, kontaktkanaler, relation til enheder – altså hvor personen er at finde mv.

At vedligeholde oplysningerne, når disse løbende bliver ændret At stoppe personens tilhørsforhold til organisationen


At understøtte organisationsændringer, således at personerne let kan flyttes fra en enhed til en anden.

I forbindelse med vedligholdelse af organisationen, dvs enhederne, rummer MO workflows til:

At oprette enheder i kommunen At flytte enheder rundt i organisationen At nedlægge enheder.

Løsningen er udviklet med fokus på at lette vedligeholdelsen af oplysningerne, samt at brugeren hurtigt kan skabe sig overblik og let fremsøge eller vælge de oplysninger, der er brug for. I vedligeholdelsen af oplysningerne er det forretningsreglerne, der sætter rammerne for, hvordan data kan vedligeholdes og struktureres.

Når oplysningerne skal vedligeholdes, er det vigtigt, at det er muligt at rettighedsstyre på, hvem der må hvad. For manges vedkommende vil vedligeholdelsen af organisationen klares af nogle få personer, mens flere vil have adgang til at vedligeholde oplysningerne om medarbejderne. MO er skabt med AD-integration til styring af rettighedere og er let at konfigurere.

Alle oplysningerne er, som tidligere nævnt, styret af datoer – virkningsdatoer, altså hvornår en oplysning er gældende fra og til. Og når en oplysning ændres, registreres ændringstidspunktet i loggen. Derved er det muligt at ændre fortid, nutid og lave ændringer ud i fremtiden, for så siden hen at ændre det igen. Det er altid den seneste registrerede ændring, der er den gældende. Dette kaldes dobbelthistorik. Alle ændringer bliver ligeledes logget ift. hvem der udfører dem, hvornår, hvad der ændres, og hvornår ændringen træder i kraft.

Som led i arbejdsgangen, bl.a. i forbindelse med organisationsændringer, rummer brugergrænsefladen en ”tidsmaskine”, hvor man ved et let overblik angiver, hvilken dato man ønsker at se organisationen på, og hvis man f.eks. arbejder med et få en organisationsændring på plads en måned senere, kan denne funktionalitet let give et overblik over, hvor langt man er nået f.eks. i flytningerne af medarbejdere, eller om alt ser rigtigt ud.

Autoritative oplysninger OS2MO integrerer med Serviceplatformen og henter samt opdaterer oplysninger her. Dette er primært medarbejdernes CPR-nummer, men også adresser til enhederne. Oplysningerne i MO kan opdateres som tidligere beskrevet enten via brugergrænsefladen eller via beskeder/webservices. Oplysningerne i MO udstilles på samme måde. Første version af MO rummer integration til Støttesystemet Organisation Den anden vigtige integration fra MO er til AD vedr. oplysninger om organisationen og medarbejdernes placering i denne, således at oplysningerne, der ofte håndskabes eller håndbæres kan erstattes af en autoritativ kilde og mere automatik.

Hvordan kan OS2MO indgå i den daglige drift? Kommunerne får med Støttesystemerne et sted de skal oprette, vedligeholde og udstille deres organisationsoplysninger. I forvejen har kommunen flere steder, hvor dette gøres, f.eks. KMD LoS. I første omgang vil disse oplysninger i Støttesystemerne kun være i relation


til Monopolbrudsløsningernes behov, men siden hen vil disse også kunne udstille til andre it-løsninger. MO vil her være kommunernes ”forbrænder” til Støttesystemet Organisation og Klassifikation, men også rumme alle de andre oplysninger, der er brug for i en lokal kommunal kontekst,

For nogle kommuner vil OS2MO være stedet, hvor oplysningerne skabes og sendes videre ud til øvrige it-løsninger. For andre vil MO være der, hvor et ansættelsesflow i et lønsystem sender medarbejderen videre til MO, for så at blive vedligeholdt der. Derfor vil der være mulighed for forskellige selvbetjeningsløsninger, men disse er ikke en del af OS2MO i første version, men sådanne løsninger vil være der, hvor kommunerne kan udvikle løsninger selv eller i fællesskab og efterfølgende dele dem med hinanden.

OS2MO har til hensigt at lette vedligeholdelsesbyrden, når løsningen tilsluttes STS omkring medarbejdere og organisationsoplysninger, men der vil være opgaver, f.eks. vedligeholdes af jobfunktionsroller eller adgange til it-systermer, som er udenfor MO’s scope. Dog håber projektet på at understøtte tildelingen af oprettede jobfunktionsroller til enkeltmedarbejderne. KLE-opmærkningen og vedligeholdelse af disse på enhederne forventer MO at kunne understøtte rapport/workflows, når der ændres i KLE-klassifikationen i forbindelse med de fire årlige nye versioner. Projektet er i løbende dialog med STS Organisation og Klassifikation for at sikre, at MO udvikles til at stemme overens med STS Organisation og Klassifikation og deres implementering af Sags- og Dokumentstandarden på de nævnte områder.

Bilag 5 FASEPLAN FOR OS2MO PROJEKTET

Projektet har løbende haft en aktivitetsoversigt som styringsredskab for fremdrift og rapportering til styregruppen. Derfor dækker nedenstående hele projektets levetid, fra den første aktivitet blev iværksat, efter styregruppen vedtog kommissorium og udpegede projektleder.

Fase Opgaven Beskrivelse Produkt(er) Udfører Tidspunkt Andet

Analyse Finansiering af it-arkitekt

Projektet har brug for at få en ”hus-arkitekt”, og dette kræver, at flere kommuner bidrager til finansiering.

Minimum 10 kommuner forpligter sig til at bidrage med 20.000 kr., således at der er en startkapital på 200.000 kr.

Det sikrer os grundlag for en annoncering af it-arkitekten

Projektleder, Styregruppe

Q2 2015 Accept af styregruppen til dette tiltag

Analyse Annoncering af konsulenttime indkøb (It-arkitekt)

Der er brug for en udbudsmæssig annoncering for at finde den mest kvalificerede it-arkitekt til projektets første fase.

1. Annoncerings-materiale er udarbejdet

2. Annonceringen har fundet sted

3. It-arkitekt udvalgt

Det sikrer os den nødvendige kvalitet af it-arkitekturen for projektet.

Projektleder Q2-Q3 2015 Med annoncerings-hjælp fra Ringsted Kommune

Krav til it-arkitekt forelægges på styregruppemødet til review 9. juni 2015.



Analyse Review af Frederiksberg Organisationsdatabase og KL’s Klassifikations-service

Arkitekturreview for at undersøge anvendeligheden af disse produkter som delelementer i OS2MO projektets løsningssetup

Arkitekturreviewrapport som gør det muligt at afgøre værdien af genanvendelse, kvaliteten, dokumentationen, og hvad der evt. mangler, for at disse kan anvendes til MO projektet.

Med udgangspunkt i denne rapport skabes den rigtige løsning for OS2MO, hvad enten den er baseret på eksisterende-, nyudvikling eller en kombination.

Dette giver input til it-arkitekturen for OS2MO-løsningen og scopet for første version.

It-arkitekt Q3 2015 Med inddragelse af projektgruppe og andre relevante interessenter /parter

Analyse Afklaring af VeRA’s anvendelighed og sammenhæng med projektet

For at der ikke sker overlap mellem to projekter, som umiddelbart har sammenhæng med hinanden og kan være afhængige af hinanden, er der brug for, at der bliver arbejdet med en sammenhængsrapport, hvor overlap kan

Overordnet afklaring af sammenhængen, og hvad begge løsninger kan anvende fra hinanden. Tilpasset GAP/FIT-analyse for anvendelighed.

Dette kan sikre at løsningerne kan have

It-arkitekt Q3 2015 Med inddragelse af projektgruppe og andre relevante interessenter og parter



synliggøres. Herunder en risikovurdering af et evt. samspil.

fælles gavn af hinanden

Dette giver input til it-arkitekturen for OS2MO løsningen og scopet for første version.

Analyse Afklaring af OS2MO brugergrænsefladens anvendelighed og sammenhæng med projektet

Afklaring af, hvilken opgave det er at få en hel applikation, hvor det er muligt at vedligeholde organisations- og medarbejderdata, oprette og vedligeholde klassifikationer, samt konfigurere forretningsregler.

Herunder at gøre eksisterende løsning kommuneneutral.

Beskrivelse af, hvad der mangler i løsningen, samt ca. estimater for at få en fungerende brugergrænseflade med tilhørende forretningslag

Dette giver det nødvendige overblik over omfanget af opgaven med at bygge MO-brugergrænsefladen og forretningslaget færdigt.

Dette giver input til it-arkitekturen for OS2MO-løsningen og scopet for første version.

It-arkitekt + projektleder

Q3 2015 Med inddragelse af projektgruppe og andre relevante interessenter/ parter

Analyse En workshop til involvering af it-arkitekter til grundlæggende krav.

For at OS2MO kan tegne den overordnede arkitektur og have en liste af krav til løsningen afholdes en workshop med relevante

Overblik over krav til løsningen og et dokument, der beskriver de grundlæggende krav.

It-arkitekt, projektgruppe, projektleder og førende it-arkitekter

Q3-Q4 2015



kommunale parter

Analyse Arrangement om organisationsdata

For at udbrede kendskab til projektet og skabe et netværk kommunerne imellem

Afholdelse af arrangement

Projektgruppe 28.10. 2015 Det skal accepteres af styregruppen, at arrangementet afholdes

Analyse Beskrivelse af grundlæggende arkitektur for MO-løsningen

Udarbejdelse af grundlæggende arkitektur for OS2MO – dvs. en arkitekturtegning med tilhørende overordnede opgaver, som efterfølgende kan blive en del af projektet

Dette kan gøres på baggrund af ovenstående aktiviteter

Arkitekturgrundlag som kan danne baggrund for en KL-arkitekturrapport og anvendes til næste fase af projektet, som omhandler hvilke udviklingsopgaver næste fase rummer.

Dette sikrer, at der er et overblik over projektet og sammenhænge med andre projekter i det kommunale landskab samt sammenhæng med Rammearkitekturen.

It-arkitekt + projektleder + projektgruppe

Q3-Q4 2015 Foregår i samarbejde med projektgruppen for at få en god og reel afklaring af projektets form og mål, samt hvilket scope projektet får til 1. version

Analyse Beslutningsgrundlag for scope for 1. version af OS2MO.

Alt foregående analysearbejde samles til et overblik over projektet, og scope for 1.version estimeres.

Det giver et overbliksbillede for projektet og scopet for 1. version, herunder ressourceestimater til efterfølgende udviklingsopgaver.

Dette giver projektet et

Projektleder + projektgruppe + it-arkitekt

Q3-Q4 2015



go/no-go -beslutningsgrundlag.

Analyse Udsendelse af ”Beslutnings-dokument”

Som afslutning af analysefasen deles den rapport, der er udfærdiget på aktiviteterne i analysefasen, ud til deltagerne af fundingen og andre interesserede.

Beslutningsdokument indeholdende analyserapporten

Projektgruppe og projektleder, samt it-arkitekt

Q1 2016 Materialet skal godkendes af OS2-bestyrelsen før tilslutning kan igangsættes

Tilslutning Udfærdigelse af materiale til 1. tilslutning

Tilslutningsaftale med model for finansiering udfærdiges til udsendelse

Tilslutningsaftale Projektgruppe, projektleder samt jura-bistand

Q1 2016

Tilslutning 1. tilslutning – Materiale udsendes.

Formidling af tilslutningsaftalen til kommunerne og regionerne

Mailkontakt med tilslutningsaftalen samt personlig opfølgning

Styregruppe, projektgruppe og projektleder

Q1 2016

Tilslutning Præsentation i KL-Arkitekturråd

Projektet præsenteres og vurderes i KL-arkitekturråd, og arkitekturrapport udarbejdes

Sagsfremstilling

It-arkitekturrapport

It-arkitekt, projektgruppe og projektleder

Q1 2016

Tilslutning OS2MO – arrangement

Som led i tilslutningen afholdes et arrangement om organisationsdata og OS2MO

Afholdelse af arrangement i det jyske

Projektgruppe og projektleder

Q1 2016



Udbud Forberedelse af udbud

Udarbejdelse af udbudsmateriale, overordnet kravspecifikation, afklaring af udbudsform, afklaring af kontraktvalg mv.

Udbuddet bliver afholdt med base i Silkeborg kommune.

Bliver udbuddet gennemført via SKI, vil valg af leverandør være en betydeligt lettere proces.

Udbudsmateriale mv. Projektgruppe, projektleder, it-arkitekt, jura-bistand fra Silkeborg, ekstern udbuds-assistance og evt. ekstern jura- bistand

Q1 2016 Afholdelse af udbud forudsætter, at der er en minimums-tilslutning på 1.2 mio. indbyggere for at have finansieringen af OS2MO, version 1.0 på plads.

Projektet forventer dog at arbejde med forberedelse af udbud parallelt med tilslutningsfasen.

Udbud Leverandørhøring Inddragelse af leverandører for at få feedback før udbuddet sendes ud

Dette erstattes af et senere leverandør-dialogmøde om løsningen, hvis projektet vælger et SKI-udbud.

Afholdelse af dialog møde Projektgruppe, projektleder, it-arkitekt, jura-bistand og ekstern udbuds-assistance

Q1 2016

(Q2 2016 hvis udbuddet bliver via SKI)

Udbud Afholdelse af udbud Afholdelse af udbud og indgåelse af kontrakt med leverandør

Udbud og kontraktindgåelse

Projektgruppe, projektleder, it-arkitekt, jura-bistand,

Q1-Q2 2016

Hvis det bliver på et SKI –



Silkeborg og ekstern udbuds-assistance

udbud forventes det, at der er fundet leverandør inden udgangen af Q1

Udvikling Udvikling af OS2MO version 1.0

Udvikling af OS2MO i samarbejde med den valgte leverandør som agilt udviklingsprojekt

OS2MO version 1.0 klar til testimplementering

It-arkitekt, projektgruppe, leverandør og projektleder

Q2-Q4 2016

Udvikling Indsamling af best practices og forretningsregler

For at understøtte kommunerne i deres implementering indsamler projektet best practices inden for klassifikationer og anvendelse af disse, forretningsregler mv. for at lave relevante og anvendelige implementerings-vejledninger til kommunerne

Implementerings-materiale

Standardkonfiguration af OS2MO

It-arkitekt, projektgruppe, projektleder samt relevante kommuner og samarbejds-partnere

Q2-Q4 2016 Opsamling af materialet bliver indarbejdet i de arbejdspakker, som kommuner tilsluttet 1. tilslutningen får adgang til denne understøttelse.

Udvikling Leverandørdialog Projektet vil løbende have dialog med leverandører ift. understøttelse af projektet og udbredelse af løsningen samt

Dialogmøder mv. Projektleder, it-arkitekt og projektgruppe

Q2-Q4 2016

Samt løbende efterfølgende



integrationer

Udvikling Kommunedialog Løbende dialog og understøttelse af lokalt forberedelsesarbejde efter anbefalinger fra projektet

Dialogmøder, workshops og netværk

Projektleder og projektgruppe samt it-arkitekt. Lokal kontakt-person/projekt-leder

Q2-Q4 2016

Samt løbende efterfølgende

Udvikling Understøttelse af KLE opmærkning

Lokal understøttelse af KLE-opmærkning af kommunerne ift. STS-behov. Bl.a. gennem samarbejde og best practice-understøttelse at den enkelte kommune.

Vejledninger, anbefalinger, erfarings- og dokumentations-deling, samt anden understøttelse af denne opgave

Projektleder og projektgruppe. Lokal kontakt-person /projektleder

Q3-Q4 2016 Kommuner tilsluttet 1. tilslutningen får adgang til denne understøttelse

Tilslutning 2. Tilslutning Udarbejdelse af 2. tilslutning for vedligehold, sekretariatsbistand og videreudvikling. Herunder supportaftaler, driftsaftaler mv.

2. tilslutning – Løsningen, OS2MO, udarbejdes som juridisk tekst.

Projektleder, Projektgruppe og Styregruppe

Q4 2016 Kommuner ikke omfattet af 1. tilslutning får her mulighed for at blive omfattet af de aftaler, som projektet tilvejebringer

Implemen-tering

Udrulning Udrulning af OS2MO version 1.0 i tilsluttede kommuner.

Projektet understøtter ved at have eksterne samarbejdspartnere, som

Implementerede OS2MO-løsninger i deltagende kommuner med kørende lokal governance

Projektleder, projektgruppe, it-arkitekt, lokal projektleder og eksterne samarbejds-

Q4 2016

Q1 2017



kommunerne kan anvende

partnere

Beskrivelse af faserne

Projektet afvikles via følgende overordnede faseplan:

1. Analysefasen 2. 1. Tilslutning og udbud 3. Udviklingsfasen 4. 2. Tilslutning og implementering 5. Videreudvikling

Herunder er de enkelte faser beskrevet. For at se sammenhængen med tidsplanen bedes dette bilag efterfølges af en læsning af Bilag 6, Tidsplan. Hver fase rummer en del arbejdspakker, som de forskellige elementer i ovenstående skema kan omskrives til. Arbejdspakker af relevans for de deltagende kommuner vil løbende blive kommunikeret ud, således at man har mulighed for at følge med i projektet. Det gælder især de arbejdspakker, der rummer lokalt forberedelsesarbejde, hvor de deltagende kommuner som led i deres forberedelse skal i gang. Det er kun kommunerne, der er omfattet af 1. tilslutningen, som har adgang til disse arbejdspakker, men efter 2. tilslutningen vil kommuner, som tager OS2MO i anvendelse, ligeledes få adgang til disse.

Analysefasen

Projektet har i denne fase haft en projektleder tilknyttet med en projektgruppe, der har arbejdet for at få projektgrundlaget skabt. Hertil har været indkøbt it-arkitekt til at arbejde med analysefasens forskellige arkitekturopgaver. Projektets styregruppe har fungeret som det overordnede organ for projektets fokus og retning.

1. Tilslutning og udbud

I denne fase vil projektet dels indkøbe eksterne ressourcer og dels anvende ressourcer fra styregruppens kommuner for at udarbejde en tilslutningsaftale og efterfølgende skabe fundamentet for og gennemføre udbuddet af udviklingsaftalen. Projektet vil afklare muligheden for at anvende en SKI-aftale til udviklingen, og hvis dette ikke er muligt, vil projektet afholde ordinært udbud. Projektlederen vil stå for koordineringen af dette og i samarbejde med projekt- og styregruppe søge den bredest mulige tilslutning.

For at Silkeborg Kommune på vegne af OS2MO-projektet kan indgå aftaler om udvikling, skal det økonomiske grundlag være på plads. Derfor vil fasen rumme 1. tilslutning, ”Udvikling af OS2MO”, hvor kommunerne binder sig økonomisk til at finansiere udviklingen.

It-arkitekten vil bidrage med krav til løsningen, herunder metode til test og udvikling, samt overordnede estimater på selve udviklingen. Arkitekten vil også bidrage i vurderingen af de indkommende tilbud for at sikre valg af den rigtige leverandør.

BESLUTNINGSMATERIALE OS2MO – Bilag samlet - Side 27 af 59

Udviklingsfasen

Projektet vil gennem en agil udvikling anvende it-arkitekten som teknisk projektleder for at holde fokus på kvaliteten og dokumentation. Projektlederen indgår som produktejer og som koordinator, for at der bliver leveret anvendelig funktionalitet. Projektejeren vil løbende have føling med udviklingen og medvirke til, at der bliver leveret indenfor tidsplanen.

Projektet vil her anvende en referencegruppe bestående af it-arkitekter til løbende at understøtte prioritering af backlog og sparring omkring løsningsbeskrivelser. Der vil ligeledes blive trukket på fagpersoner med relevant erfaring omkring modellering, forretningsregler og klassifikationer. Denne gruppe vil primært blive inddraget i en række workshops til at understøtte indholdet i løsningen.

Samtidig vil projektet have løbende dialog med leverandører, der har interesse i at anvende OS2MO i deres løsning, integrere med OS2MO mv. for at understøtte, at OS2MO allerede fra første version er kendt i markedet, og flere produkter allerede er klar til at understøtte/integrere, når kommunerne er klar med implementeringen. Dette kræver adgang til dokumentation og test-miljøer mv. som projektet forventer at stille til rådighed ved forespørgsel. Vil der være brug for samarbejde, der kræver ressourcer, der kan påvirke projektets fremdrift, skal dette prioriteres af styregruppen med mulighed for medfinansiering fra leverandørens side.

Risikoen i udviklingsfasen er, at projektets scope udvides i udviklingsfasen. Derfor vil der være et klart fokus fra både styregruppen og projektgruppen, at løsningens vigtigste funktionalitet understøtter de vigtigste forretningsbehov. Krav fra STS vil blive prioriteret højt, da OS2MO skal kunne fungerer som lokal master.

2. Tilslutning og Implementering

Projektet vil løbende køre test i udvalgte kommuner, med forskellige systemsetup. Testkommunerne bliver valgt på baggrund af størrelse og lønsystem, samt binding til IDM. Det forventes, at der samarbejdes med 3 kommuner, og erfaringer her bliver opsamlet og delt, samt anvendt ved udrulning. Projektet vil understøtte kommuner tilsluttet 1. tilslutningen med det lokale forberedelsesarbejde, samtidig med at OS2MO udvikles således, at kommunerne er klar til at implementere. Projektet kan ikke levere lokal projektledelse, men støtter de lokale aktører i form af aktiviteter, vejledninger mv., således at kommunerne selv udfører det lokale praktiske arbejde. Det er forventningen at OS2MO både understøtter en cloud-løsning samt en lokal implementering.

Når udviklingsfasen af OS2MO version 1.0 er nær afslutning, vil projektet lave 2. tilslutning, ”Implementering af OS2MO”. Denne rummer, at kommunerne giver tilsagn til, at OS2MO-projektet indgår aftaler om sekretariat, drift, support, vedligehold og videreudvikling på deres vegne. Kommuner, der er ikke omfattet af 1. tilslutningen, kan her blive omfattet af aftalerne med mulighed for, at de kan tage OS2MO i anvendelse mod at biddrage økonomisk til fællesskabet på lige fod med kommunerne på 1. tilslutningen samt betale et indtrædningsgebyr.

Projektet vil understøtte, at der er tilstrækkelig med information til at sikre implementeringen, men forventer også at finde samarbejdspartnere, der vil kunne understøtte lokale behov både teknisk og organisatorisk.


Samtidig med at første version bliver implementeret, forventer projektet at arbejde videre med næste version, da projektet ved, der er en række behov for funktionalitet, der vil være dækkende for alle, der er behov for at få udviklet.

Videreudvikling

Når første version af OS2MO er implementeret, vil der blive behov for koordinering af udviklingsbehov. Erfaringer omkring APOS2 før det blev købt af KMD, var, at kommunerne havde forskellige behov, som man hver især begyndte at udvikle løsninger til. For at sikre, at udviklede elementer kan komme fælleskabet til gode, er det vigtigt, at der bliver udviklet en OS2MO-udviklingsopskrift med dokumentation og test, således at projektet kan sikre kvaliteten og ophøje videreudvikling til den officielle version. Dette kræver styring på it-arkitektursiden, men også koordinering, så samme funktionalitet ikke bygges flere gange.

Derfor får OS2MO under OS2-Bestyrelsen en sekretariatsfunktion med både arkitekturbistand, projektledelse, koordinering og governance for OS2MO-løsningen for at understøtte kommunernes anvendelse af løsningen. Ved siden af sekretariatet skal der skabes arkitekturudvalg og anvendelsesudvalg som rådgivende organ for OS2MO’s anvendelse og videreudvikling.


Bilag 6 TIDSPLAN FOR OS2MO PROJEKTET

Planen er udformet som en overordnet tidsplan for OS2MO i perioden Q2 2015 - Q2 2017. Projektet rummer forskellige opgaver, der alle er estimeret/fastsat i nedenstående illustration, og hvert punkt rummer i sig selv en del underopgaver i arbejdspakker.

Tidsplanen bedes læst i sammenhæng med Bilag 5, Faseplan, for en forståelse af de forskellige opgaver i hvert element.

Tidsplanen er dog foreløbig, og der tages forbehold for, at den kan rykkes ift. tidsforbruget for tilslutningsaftalen og efterfølgende udbud. Når der er indgået aftale med en leverandør, vil projektet udsende en mere nøjagtig tidsplan, der løbende holdes opdateret.

Bliver OS2MO klar til at Støttesystemerne skal have

organisationsoplysninger?

Projektet er bevidst om, at alle deltagende kommuner har et tidspres, ift. om OS2MO bliver klart til, at den enkelte kommune skal implementere KOMBIT’s Støttesystemer. Projektet vil arbejde sig hen imod at have løsningen klar til udgangen af 2016, hvorefter kommunerne starter med at implementere SAPA i drift i starten af 2017, jf. KOMBITs tidsplan. Dvs. projektet pt. ikke kan udtale sig, om produktet er klar, til at pilotkommuner tager STS i anvendelse.

STS er bygget til, at man kan indlæse sin organisation og de medarbejdere, som bliver brugere af KY, KSD og SAPA, manuelt og vedligeholde dem her. Og hvis OS2MO ikke er klar til at kunne håndtere dette, når en kommune tager STS i anvendelse, kan den manuelle proces forsætte, indtil OS2MO er klar til at overtage denne opgave og fungere som lokal master for de oplysninger som STS har brug for på Medarbejderne (Brugerne) og Organisationen.


Figur 1. – Tidsplan for OS2MO – 2015-2017

1. Tilslutningen ”Udvikling af OS2MO” forventes at løbe over ca. 1 måned. Dog har projektet siden nytår arbejdet med at udbrede kendskabet til projektet og hvad en tilslutning rummer, således at mange kommuner allerede er bekendt med dette. Projektet har brug for, at kommuner svarende til ca. 1.2 million borgere/indbyggere binder sig økonomisk til finansiering af projektet. Der kan derfor være en forskydning i tidsplanen, hvis ikke dette opnås indenfor den ønskede tidsperiode. Dog kan styregruppen vedtage, at man alligevel går i gang med udbud/indkøb, selvom der ikke er betalende tilslutning nok.

Tidsforbruget i forbindelse med udbuddet kan variere meget. Hvis projektet kan anvende en SKI-aftale, er det meget mindre ressource- og tidskrævende, end hvis projektet skal i eksternt udbud med præ-kvalifikation osv. Alt efter, hvilken model der er mulig, har det konsekvenser for tidsplanen. Den skitserede tidsplan er en mellemting af et eksternt udbud og et SKI-udbud.

Udviklingen forventes at tage 4-6 måneder, dog er leverancerne delt op ud fra, at der kan være elementer, som hurtigere bliver klar til lokal implementering. Der vil løbende blive kommunikeret ud om dette. Det er styregruppen, der vil tage stilling til dette, efterhånden som projektet leverer. Leverancerne vil løbende være funktionelle dele af OS2MO-systemet, og her ligger værdien i at lave projektet efter den agile model.

Den lokale forberedelse vil rumme, at kommunerne får styr på den lokale governance for organisationsændringer og vedligeholdelse af medarbejderoplysninger. Samtidig vil en stor del af det lokale forberedelsesarbejde være at indsamle oplysningerne om medarbejderne og organisationen (afdelingerne) og dernæst opmærke dem med de klassifikationer, OS2MO kommer til at arbejde med. Det vil også være en del af det lokale forberedelsesarbejde, hvis man vælger at implementere KLE-opmærkning af sin


organisation i takt med, at OS2MO bliver implementeret. OS2MO-projektet understøtter arbejdet med vejledninger, erfarings- og dokumentations-deling samt konkrete arbejdspakker. Hvor ressourcekrævende det lokale forberedelsesarbejde bliver, afhænger af, hvor godt styr den enkelte kommune har på disse data.

Implementeringen kræver, at der er indgået aftaler om drift og support. Derfor gennemføres 2. tilslutning, ”Implementeringen af OS2MO”, hvor kommunerne bliver omfattet af aftaler ift. support, drift, sekretariat, vedligehold og videreudvikling. 2. tilslutningen vil finde sted umiddelbart før implementeringen. Kommuner ikke omfattet af 1. tilslutningen kan tilslutte sig ved 2. tilslutningen.

Implementeringen af OS2MO som teknisk løsning er endnu ikke afklaret – men der vil blive lavet en plan for, hvornår de enkelte kommuner kommer på løsningen, samt hvordan man som kommune vælger at anvende løsningen, enten som egen hosted eller som cloud-løsning. Derfor er der afsat tid til denne fase, og der vil, når projektet nærmer sig, komme mere information ud. Implementeringen af OS2MO vil ligeledes tage højde for de udrulningsplaner, KOMBIT anvender, dog med mulighed for, at man som kommune er medbestemmende, om hvornår OS2MO tages i anvendelse i den enkelte kommune.

De resterende angivelser i tidsplanen rummer drift – som jo er en kontinuerlig proces, når OS2MO-løsningen er implementeret – og det samme rummer videreudvikling i fælles og lokalt regi.


Bilag 7 BUDGET FOR UDVIKLING AF OS2MO 1.0

Der er endnu ikke foretaget nogen endelig estimering af udviklingsopgaven i forbindelse med udviklingen af OS2MO, men projketet har et overordnet estimat. Derfor kan der ikke på nuværende tidspunkt laves noget detaljeret budget for, hvad udviklingen vil koste. Men projektgruppen har arbejdet med nogle grundlæggende principper for budgettet. Bl.a. vil der være behov for fuldt frikøb af projektlederen i hele 2016, og det forventes, at it-arkitekten skal knyttes til projektet i, hvad der svarer til 15 % af udviklingstimerne. Projektgruppen har ligeledes arbejdet en del med finansieringen og arbejder pt. ud fra en præmis om, at de tilsluttede kommuner skal betale 5 kr./indbygger for at være med i projektet for at sikre finansiering. Og dette kræver en tilslutning fra minimum 1.200.000 indbyggere. Efterfølgende vil der være et årligt bidrag til vedligehold, let videreudvikling og sektariat for OS2MO. Dette vil ikke overstige 5 kr. pr. indbygger årligt. Det årlige biddrag fastsættes af OS2MO-styregruppen.

Følgende elementer er medtaget i indeværende projektbudget:

- Projektledelse, arkitekturassistance, konsulentassistance - Udvikling af prototype (Proof of Concept) - Analyse af eksisterende tekniske situation - Udbud eller SKI-indkøb - Udvikling af version 1.0 af OS2M0.

Overordnet arbejder projektet med følgende budgetposter for OS2MO verson 1.0. Det er cirka-angivelser

Udviklingstimer Ca. 3.500.000 kr

It-arkitektur (kvalitet, dokumentation, test) Ca. 1.000.000 kr

Projektledelse (frikøb af projektgruppe, ekstern mv) Ca. 1.000.000 kr

Andet (jura, administration mv. ) Ca. 500.000 kr

Finansieringsbehov Ca. 6.000.000 kr

Bilag 8 INTERESSENTANALYSE AF OS2MO PROJEKTET Nedenstående interessentanalyse er udarbejdet på baggrund af OS2MO projektets nuværende viden.

Nr. Interessenter Roller i/bidrag til (ambassadør) eller evt. modstand mod projektet

Interessenternes betydning for projektet

Interessenternes egne succeskriterier

Præventive tiltag

(Beskrivelse af tiltag, som vil formindske interessentens modtand mod projektet)

Ansvarlig

(Ansvarlig for at håndtere interessenten)

1 Beslutningstagere i kommunerne (deltagende)

Fungere som ambassadører og formidlere af projektet

Projektet kan ikke blive til noget, uden at der er en vis mængde tilsluttede kommuner. Projektet er til for kommunerne, derfor er involveringen vigtig.

Få styr på organisationsdata og processerne for vedligeholdelse samt optimal genbrug.

Løbende involvering og troværdi kommunikation samt at projektet leverer og overholder tidsfrister

Projektledelse, styregruppe og lokale kontaktper-soner /projektledere

2 Beslutningstagerne i kommunerne (tilsluttede)

Har ikke pt. økonomi til at deltage i projektet, samt vurderer evt. at risikoen ift. leverancerne og forsinkelser er for høj og forholder sig derfor afventende. De kan også have en lokal løsning.

Ved at overgå til at være deltagende vil de fungere som finansiel stabilitet for projektet og kan finansiere videreudvikling.

Afklare egne arbejdsgange og behovet for at få fokus på organisationsdata.

Evt. afklare om deres egen løsning er værdifuld og funktionel.

Løbende at kommunikere ud om projektet

Projektledelse, projektgruppe og styregruppe, samt OS2’s Bestyrelse

3 KOMBIT Kan understøtte projektet og udbredelsen, men kan også

Har en del indflydelse på projektets succes ift.

Ønsker STS succesfuldt Åben dialog og deltagelse fra projektets side, samt

Projektledelse og





Præventive tiltag


Ansvarlig


tale projektet ud af relevans.

Vigtige samarbejdspartnere ved integration med STS Organisation og Klassifikation.

Integration, men også ift. dialogen ift. kommunerne

implementeret. invitation til samarbejde projektgruppe, strategisk – OS2-Bestyrelsen

4 KL

Kan understøtte projektet, da projektet arbejder med Rammearkitekturen.

Kan formidle projektet ud til kommunerne og kan anvende projektet som vej til at afprøve flere byggeklodser fra rammearkitekturen.

Ønsker, at kommunerne hjemtager ejerskabet til deres it-arkitektur, ønsker at rammearkitekturen bliver implementeret som funktionelle It-løsninger eller dele heraf.

Åben dialog og løbende fælles sparring

Projektledelse, projektgruppe – Strategisk OS2-Bestyrelse

5 Digitaliseringsstyrelsen

Samarbejdspartner ift. den nye organisation 2.0-standard

Interesseret i projektet, hvis organisation 2.0 bliver til it-løsning

Trække på viden fra kommunerne ift. standarderne og den praktiske anvendelse

Åbenhed og fælles sparring

Projektleder, projektgruppe

6 Leverandører

(andre)

Interesseret, hvis det kan understøtte deres forretning og generere omsætning. Samtidig skal de understøtte deres kunders

Kan understøtte, at projektet får stor udbredelse og anvendelse

Understøtte egne forretningsmål

Åbenhed og gode samarbejdsmuligheder ift. løsningen og udbredelse – for it-leverandører understøtte at de har god adgang til

Projektleder /projektgruppe





Præventive tiltag


Ansvarlig


(kommunernes) behov. løsningen ved videreudvikling /integrationer

7 SBsys

Interesseret, da de har brug for en organisationskomponent til deres løsning.

Kan understøtte projektets udbredelse i alle SBsys- kommunerne.

Understøtte løsningen, således at den bliver mere rammearkitektur-complient.

Åbenhed og samarbejde Projektleder/ projektgruppe

8 OS2 Kitos

Interesseret, da løsningen rummer en organisationsdel, som kan understøttes eller erstattes af OS2MO,

Har adgang til 70 kommuner og kan derfor understøtte udbredelse.

Sikre at videreudvikling kan fokusere på kerneelementerne af løsning, og derved kan de hente relevante oplysninger fra OS2MO.

Åbenhed og samarbejde Projektleder /projektgruppe

9 OS2-Bestyrelsen Er anker for projektet og har interesse i, at projektet har fremdrift mv.

Understøtter projektet, da det er under OS2-fælleskabet, men også med meget interesse, da det er et niveau 3-projekt.

Få succes med OS2MO, således at OS2 bliver forankret i kommunerne som et seriøst fælleskab til udviklingsfælleskaber.

Løbende dialog og tilbagerapportering ift. fremdrift mv

Projektleder/projektejer og OS2-Bestyrelsens medlem af styregruppen


Bilag 9 RISIKOANALYSE AF OS2MO PROJEKTET

Denne risikolog er udarbejdet ud fra den viden projektet har lige nu. Den vil løbende blive justeret ift. ændringer i takt med projektets fremdrift.

Nr. Risiko Forklaring Forebyggende (inden risiko opstår)

Minimering (plan B når risiko er opstået)

Ansvarlig

1 Person-afhængighed

Projektet er afhængigt af en række personer, specielt projektlederen og it-arkitekten

Projektet arbejder med at få dokumenteret så meget som muligt, således at personafhængigheden afhjælpes, samt at flere personer involveres i it-arkitektens og projektlederens arbejde. Risikoen minimeres også, ved at projektet overgår fra tilslutning til udviklingsfasen, hvor der bliver en leverandør involveret.

Understøtte, at der er en personkreds omkring projektet, som kan overtage ved centrale personers frafald.

Projektleder

2 Manglende tilslutning

Kommunerne tror ikke på projektet, og derfor er tilslutning ikke i det ønskede omfang

Afdække begrundelser, således at kommunerne tror på projektet. Udarbejde materiale, som er dækkende for bekymringspunkterne og tager hånd om disse.

Scope projektet således, at produktet leverer hvad der er økonomi til. Derved kan projektet levere resultater, der er medvirkende til, at kommunerne efterfølgende tilslutter sig.

Styregruppen/

Projektejer




Ansvarlig

3 Budgettet skrider Det afsatte budget er ikke tilstrækkeligt til at dække udgifterne til projektet.

Stram styring af budget ift. udgifter og hvad der sættes i gang af udvikling. Ser estimaterne ud til ikke at holde, skal disse genovervejes før udvikling igangsættes.

Begrænse det resterende scope og evt. overveje yderligere funding

Projektleder /Projektejer

4 Forventninger til projektet overstiger leverancerne

Kommunerne har forskellige behov og forventninger til projektet. Ikke alle kan medtages i scopet.

Projektet er meget åbent for, hvad scopet rummer, og ligeledes for, hvilke leverancer projektet har, samt hvornår. Synliggørelse af, hvad der ligger i backloggen ift. hvad der er medtaget, således at kommunerne kan være sammen om prioriteringen, når projektet har leveret den første version.

Har en kommune haft højere forventninger end leverancerne, kan projektet henvise til leverandører, der kan understøtte lokale behov som selvstændig videreudvikling.

Styregruppen/

Projektejer

5 Forretningsbehov udvider scope med konsekvens for tidsplan

Projektets scope udvides, grundet opståede forretningsbehov eller for komplekse tekniske behov, hvorved det tager længere tid end forventet at levere.

Projektets scope afklares benhårdt, og hvis der er nye behov, skal der prioriteres i de eksisterende elementer. Tiden er en vigtig faktor for projektet, og derfor skal der gøres alt for at projektet holder tidsplanen.

Leverancerne bliver mindre ift. at der er brugt for meget tid på dele. Dvs. at scope begrænses.

Styregruppen/

Projektejer




Ansvarlig

6 Lokale Implementerings udfordringer

Det er en større opgave lokalt i kommunerne at implementere løsningen, da der er mange elementer i projektet. Det er ikke kun indsamling af data, men også det organisatoriske forandringsprojekt, der følger i kølvandet med implementeringen af løsningen.

Forberede kommunerne med alt det materiale og understøttelse, som projektet kan levere. Understøtte med opfølgning, sikre, at der er gang i processerne, og understøtte, hvis der er udfordringer – dog ikke direkte med ressourcer, men med råd og vejledning. Sikre, at kommunerne er klar over, hvilken opgave specielt dataindsamlingen er, og at der er sat ressourcer af til dette. Sikre et godt netværk af deltagende kommuner, som kan understøtte hinanden

Sikre, at der er tilstrækkeligt med eksterne ressourcer, som de lokale projekter kan trække på. Sikre, at der er et netværk af ”kollegaer” omkring projektet i andre kommuner, som kan hjælpe

Central indgriben med råd og vejledning

Lokal ejerskab/ Lokal Projektleder

Styregruppe/

Projektleder

7 Tidsplanen skrider

Af forskellige årsager skrider tidsplanen for den tekniske løsning.

Understøtte at scope hele tiden er i overensstemmelse med tidsplanen. Være åben ift. kommunikation om tidsplanen og forventede leverancer

Understøtte at der tages forhåndsregler for at minimere de konsekvenser, en forsinkelse har for de lokale projekter

Projektleder

8 Udfordringer med leverandørsamarbej

Samarbejdet med leverandøren har konsekvenser for kvaliteten eller

Klare regler i kontrakten for samarbejde. Klarhed omkring

Mulighed for at leverandøren kan

Projektleder




Ansvarlig

de

tidsplanen. leverancer og opgavefordeling samt ansvarsfordeling, herunder hvilke roller de forskellige parter har i projektet.

udskiftes hvis kvaliteten, samarbejdet eller tidsplanen påvirkes grundet vanskeligheder i samspillet med leverandøren.

Bilag 10a DEN LOKALE BUSINESS CASE

Indhold af bilag 10a Gevinst katalog ........................................................................................................................................... 40

Kommunens forberedelse ..................................................................................................................... 42

Opgaver indledende ............................................................................................................................ 42

Opgaver, som del af den lokale forberedelse ............................................................................ 43

Opgaver, som bliver en fast del af vedligeholdelsen af OS2MO ........................................ 44

Forklaring af bilag 10b Business Casen regneark ....................................................................... 44

Bilag 10a, 10b og 10c er dokumenter, der understøtter beslutningsprocessen omkring OS2MO lokalt i kommunen. Ud over at være et gevinstkatalog (Bilag 10a), som giver inspiration til, hvor kommunen kan finde gevinster, både af ressourcemæssig og kvalitativ karakter, rummer Bilag 10b et regneark, hvor kommunen kan indsætte egne tal for at afklare projektets business case. Bilag 10c er understøttende til at synliggøre, hvad en organisationsændring har af impact rundt omkring selve ændringen. Dette dokument rummer desuden en oversigt over, hvilke ressourcer og personer som projektet kræver for at blive implementeret; hvilke ressourcer OS2MO kræver for at blive anvendt i kommunen, og ligeledes hvilke opgaver kommunen allerede nu kan forberede sin implementering af OS2MO med. Disse opgaver ligger i forlængelse af opgaverne, som forberedelsen til KOMBIT’s Støttesystemer kræver af kommunerne.

Gevinstkatalog

Til understøttelse af arbejdet med en lokal business case har projektet indsamlet eksempler på, hvor en organisationskomponent giver gevinster, både af kvalitativ og ressourcemæssig betydning. Projektet kan ikke udtale sig om, hvordan det ser ud i den enkelte kommune, men kan give inspiration til, hvor gevinsterne kan findes. Nedenstående er en liste over disse.

Genbrug af data:

- Styr på organisationen ved at have en autoritativ kilde, hvori ”sandheden” findes - Kendte og vedtagne procedurer for organisationsændringer mindsker

ressourceforbruget vs. anarki, hvor der mangler overblik over, hvem skal have besked om hvilke ændringer, hvornår.


- Kendte og vedtagne begreber for, hvordan data klassificeres, dvs. at man i kommunen er enig om, hvem der er niveau 1-, 2- eller 3-ledere, eller hvem der har økonomi, personale eller fagligt ansvar som leder.

- Ressourceforbruget til vedligeholdes af oplysninger begrænses, ved at man ikke manuelt skal vedligeholde hvert system selvstændigt, men kan hente oplysninger ét sted fra.

- Mulighed for, at forskellige organisationer kan repræsenteres og vedligeholdes f.eks. MED og Arbejdsmiljø, Løn-organisationen, den politiske organisation med udvalg etc.

- Vedligeholdelse af Active Directive, fra at være manuel indtastning af alle oplysningerne til at rumme et minimum af indtastning.

- Mulighed for ved organisationsændringer at andre systemer opdateres automatisk i deres repræsentation af organisationen.

Forbedret datakvalitet

- Overblik over det samlede organisationshierarki med adresser på alle afdelinger, herunder hvilke personer der er at finde på hvilke enheder, samt hvem der er leder for hvem

- Kendte og vedtagne regler for navngivning af enheder, således at navne fremstår ensrettet. Alt efter hvem der skriver det, kan det gengives forskelligt i den manuelle vedligeholdelse.

- Gengivelse af personers navne – kan variere meget, hvis disse manuelt vedligeholdes vs. anvendelse af CPR-stamdata til validering og genbrug.

- Logning af, hvem der gør hvad i OS2MO. - Historik af, hvem der har været i organisationen hvornår.

Forbedrede arbejdsgange

- Overblik over organisationen – dvs. den samlede administrative organisation. Dette kan bl.a. bruges til diverse steder, hvor et organisationsdiagram udstilles synligt for andre i kommunen eller for omverdenen. Flere steder er dette en manuel vedligeholdelsesopgave i Power Point.

- Det bliver nemmere for medarbejdere at finde hinanden gennem udstilling af organisationen, f.eks. ved at man finder en afdeling i hierarkiet og herefter kan fremfinde den, man søger, bl.a. i en telefonbog enten via computeren eller via mobiltelefonen.

- Anvendelse af tidsforbrug til validering af data mindskes drastisk f.eks. ved trivsels-/APV-undersøgelse, da data er valide vs. at de skal valideres af f.eks. de lokale ledere. før undersøgelsen sendes ud.

- Organisationsændringer kan forberedes, før de indtræder gennem bitemporaliteten og datostyringen af data. Samtidig kan oplysningerne rettes bagud i tid.

- Mulighed for at flytte personer forud i tid, f.eks. kontorelever, der er rundt i mange forskellige enheder i løbet af et uddannelsesforløb.

- Mulighed for forenkling af ansættelse, ændringer og ophør af personer i organisationen.

- Ved at stille krav om anvendelse af OS2MO til it-systemer, der rummer manuelle vedligehold af oplysninger, begrænses tidsforbruget, ved at genindtastninger fjernes.

- Mulighed for bedre understøttelse af single-sign-on


- Højne kvaliteten af data til kommunens omstilling, bl.a. ved at udstille telefonnumre, telefontider, åbningstider, opdaterede organisationsdata, herunder navne på afdelinger, medarbejderoplysninger mv. Derved bliver det lettere for omstillingen at viderestille rigtigt. Samtidig vil KLE-opmærkningen af organisationen muliggøre lettere viderestilling.

- Opmærkning med KLE, som understøttes af OS2MO, gør det muligt at lave automatiserede arbejdsgange – f.eks. postfordeling, fællespostkasser mv.

Kommuner, der allerede har en høj grad af automatisering af brugerstyringen i AD og evt. et kørende IdM, vil på trods af, at de allerede har styr på data, have stor gavn af at implementere OS2MO. For disse kommuner vil genvinsten primært ligge i en højere datakvalitet og graden af struktureret data, der kan genanvendes, brug af klassifikationer som KLE, der kan bruges til automatisering af opgaver, samt at kommunen med implementering af OS2MO samtidig vil løfte de nødvendige opgaver i forhold til ibrugtagning af STS Organisation og STS Klassifikation.

Kommunens forberedelse

Den største opgave lokalt i kommunerne ved at implementere OS2MO er ikke den tekniske it-løsning, men ligger i forberedelsen af data og sikring af governance samt procedure for vedligeholdelse af data. Nedenstående er et overordnet overblik over de opgaver, den lokale forberedelse rummer. Projektet vil arbejde på, at der hurtigt efter tilslutning begynder at komme arbejdspakker ud over de beskrevne opgaver, således at kommunen er klar til at implementere OS2MO version 1.0, når den tekniske løsning er klar til det. Hovedparten af opgaverne, der er skitseret i det følgende, er sammenfaldende med de opgaver, kommunerne står overfor i Monopolbruddet og implementeringen af STS.

Opgaver indledende Den lokale forberedelse fordrer, at der bliver tilknyttet en række personer til opgaven, og at projektet bliver etableret i den enkelte kommune. OS2MO-projektet foreslår følgende nøglepersoner:

Udpeg en projektleder – denne bliver tovholder på projektet lokalt og OS2MO-projektet. Projektlederen skal have en del teknisk kendskab, men også være godt kendt med organisationen og arbejdsgangene. Projektet har ikke brug for en fuldtidsprojektleder. Opgaven er mere af koordinationsmæssig karakter.

Sammensæt en projektgruppe –her foreslås, at der er repræsentanter fra Løn, Økonomi, It, Brugerstyring og HR. Alle disse grupper har direkte berøring med organisationsdata og anvender det løbende som fundament i deres daglige arbejde.

Udpeg en projektejer – denne har til opgave at sikre den ledelsesmæssige opbakning i projektet, og sikre, at der er ledelsesmæssigt fokus på opgaven og gennemslagskraft, når OS2MO skal implementeres, herunder at procedurer for organisationsændringer og klassifikationer efterleves i praksis. Her er det vigtigt at få forankret projektet så relativt højt oppe i kommunens ledelse som muligt. Det er, når dagligdagen rammer OS2MO, at der er brug for ledelsesunderstøttelse og gennemslagskraft.


Udpeg en styregruppe – denne skal understøtte projektets arbejde og fremtidig setup for lokal governance af organisationsdata. Styregruppen skal forankres på kommunens øverste ledelsesniveau.

Opgaver, som del af den lokale forberedelse Nedenstående er et overblik over de arbejdsopgaver, som er den indledende del af den lokale forberedelse. Opgaverne i nedenstående vil blive udformet som arbejdspakker fra OS2-projektet til de deltagende kommuner med materiale, som understøtter dem. Nedenstående er bare et udpluk af de opgaver, som den lokale forberedelse rummer. Efterhånden som projektet nærmer sig implementeringen af OS2MO, vil flere opgaver til de lokale projektgrupper komme.

Afklar hvordan organisationsændringer sker i dag? Er der en praksis for disse? Ellers er det vigtig at få etableret en sådan. OS2MO-projektet understøtter med vejledningsmateriale. Valide stamdata afhænger af, at de bliver opdateret, også selvom proceduren er manuel.

Afklar, om der er en gruppe af medarbejdere, som fast vedligeholder organisationsoplysningerne i forbindelse med ændringer – eller om der er en ad hoc-gruppe eller bare et par medarbejdere, som har opgaven og løser den ukoordineret. F.eks. med omdrejningspunkt omkring KMD LOS, lønsystemet eller Active Directory.

Afklar, hvordan medarbejdere (og andre personer med relation til organisationen) håndteres fra start til stop. Er der et etableret flow med forbundne systemer, delvist forbundne, eller er alt manuelt?

Afklar, hvordan vedligeholdelse af medarbejderne (og andre personer med relation til organisationen) sker i dag – altså hvem gør det i praksis? Sker det decentralt gennem lederne, eller har man lokale administratorer/nøglepersoner, som gør dette? Eller foregår alt et centralt sted fra?

Afklar, om der findes en kilde, der har opdateret oplysninger om alle medarbejdere og andre personer med relation til organisationen (f.eks. eksterne konsulenter mv), eller hvor dele af en sådan oversigt kan findes – den skal bruges som udgangspunkt for data i OS2MO – men listen skal beriges med klassifikationer. Klassifikationerne kommer OS2MO-projektet med.

Afklar, om der er vedtagne regler for navngivning/begrebsanvendelse, og hvad man kalder ting lokalt – altså betegnelser, man bruger om f.eks. ledere, eller hvornår man bruger Center eller stab om enheder. Disse oplysninger skal bruges som grundlag for arbejdet med klassifikationer og opmærkning med disse

Afklar, om der anvendes KLE og hvor? Er der nogen, der vedligeholder disse? Hvilke systemer anvender KLE? Er der en officiel opmærkning i kommunen? OS2MO-projektet understøtter opmærkningen med KLE gennem vejledninger og best practices.

Afklar, hvilke it-systemer der anvender organisationsoplysninger, og hvor de får dem fra? Her kan OS2 Kitos-samarbejdet være relevant, da kommunernes anvendelse af it-systemer til forskellige opgaver er meget lig hinanden. Afklar, om it-systemerne henter organisationsoplysninger fra f.eks. Active Directory, eller om de vedligeholdes manuelt. Dette skal bruges til, at kommunen selv får et overblik over, hvor


organisationsoplysninger bruges. Projektet leverer en vejledning til, hvilke oplysninger der er de typiske for it-systemerne at efterspørge.

Opgaver, som bliver en fast del af vedligeholdelsen af OS2MO Når OS2MO er implementeret i kommunen, er der brug for, at projektet bliver til drift. Men for at der vil være valide organisatoriske stamdata, er der brug for en strategisk anvendelse og lokal governance. OS2MO forestiller sig følgende:

Lokal kontaktperson – som understøtter OS2MO fremadrettet ved opdateringer, samarbejder, integrationer mv. Således er der god forankring mellem OS2MO centralt og lokalt i kommunen og vidensdeling frem og tilbage.

Lokal organisations-gruppe – som understøtter og varetager organisationsændringer. Denne gruppe har mange systemer i starten, de skal holde styr på, men efterhånden bliver det færre systemer, der skal vedligeholdes.

Lokal KLE-ansvarlig – som understøtter og vedligeholder KLE-opmærkningen af organisationens enheder og har overblik over, hvor KLE anvendes samt til hvad. Denne har til ansvar at sørge for, at OS2MO med de afdelinger, som berøres af ændringerne af KLE også bliver opdateret, når KLE opdateres 4 gange om året. Fordelen ved at have en dedikeret KLE-ansvarlig er, at der er en, der har forstand på anvendelsen, hvad ændringerne betyder, og hvor det er kritisk, at oplysningerne bliver opdateret. Den KLE-ansvarlige er en del af den lokale organisationsgruppe.

Lokal it-administrator – der vil være behov for, at en af kommunens it-administratorer er medlem af den lokale organisationsgruppe. Det vil typisk være en it-tekniker, der allerede sidder med administration af IdM og AD.

Lokale vedligeholdere – hvis kommunen er stor, vil disse være placeret decentralt med ansvar for at vedligeholde medarbejderoplysningerne. De decentrale vedligeholdere har en stor fordel ved at være placeret ude i kommunernes organisation, og ofte ved hvad der sker, samt hvem der bliver ansat, hvordan der flyttes rundt mv. Disse har fingeren på pulsen med organisationen.

It-systemadministrator/it-arkitekt/it-projektleder– som understøtter, at it-systemerne ikke kræver lokal vedligeholdelse af organisationsoplysninger, men sikrer genbrug fra OS2MO eller STS Organisation. Med en sådan rolle er der fokus på, at data bliver genanvendt rigtigt, og at kommunen løbende får hentet gevinster ved at have en organisationskomponent. Det vil ofte give mening, at denne rolle varetages af samme person, som også er den lokale kontaktperson til OS2MO.

Forklaring af Bilag 10b, Business Casen regneark

Bilag 10a er et udkast til en business case, der kan benyttes i den enkelte kommune i forhold til at kortlægge de økonomiske gevinster ved at implementere OS2MO.

Det er væsentligt at understrege, at det ud over de kvantitative gevinster, der peges på i den lokale BC, som tidligere beskrevet er vores vurdering, at implementering af en løsning som OS2MO vil give en række kvalitative gevinster. OS2MO vil bl.a. give kommunen et meget bedre kendskab til sig selv i forhold til, hvem, der er leder hvor og for hvem mv. Ændringer i organisationen vil med OS2MO kunne foretages billigere og


markant hurtigere. Samtidigt vil OS2MO være en væsentlig byggeblok i kommunernes it-arkitektur på bagkant af Monopolbruddet.

Det er projektgruppens vurdering, at de kvalitative gevinster ved implementering af OS2MO vil have en markant effekt på kommunernes evne til at håndtere de ændringer, der kommer i de kommende år, bl.a. som følge af de fælleskommunale og fællesoffentlige digitaliseringsstrategier.

Den lokale BC (Bilag 10a) er bygget op af 3 ark. Første ark er der, hvor den enkelte kommune kan indtaste oplysninger, der afviger fra kommune til kommune, som fx indbyggertal og antal medarbejdere. Dette ark rummer også en vejledning, til hvordan de forskellige tal skal angives. Det andet ark er beregninger for implementerings- og driftsudgifter, samt de besparelser, OS2MO vil medføre. Det tredje ark er en opsummering, hvor kommunens ROI på 5 års sigt kan aflæses.

Businesscasen synliggør også de ofte skjulte timer som vedligeholdelsen af organisationsdata rummer. Timer som ofte ikke er opgjorte i den kommunale dagligdag, men som ofte ligger som overarbejde eller ekstra opgaver ved siden af den almene drift.


Bilag 10b LOKAL BUSINESSCASE BEREGNER

Dette regneark er vedlagt som selvstændigt bilag i Excel format.


Bilag 10c ORGANISATIONSÆNDRING

Dette dokument beskriver en ændring, og hvad den medfører af afledte konsekvenser. Dette er et eksempel fra en kommune, men alt er anonymiseret. En ændring af denne type er ikke bare at flytte rundt på nogle kasser, men berører mange områder af kommunens it-systemer og er tids- og ressourcekrævende.

Kommunen Mellemby har 5 Centre – Børn & Unge, Ældre & Handicap, By, Land & Kultur, Arbejdsmarked & Beskæftigelse samt Forvaltningen. I Børn & Unge skal der være en organisationsændring. Dette Center rummer kommunens 5 skoler og 10 børnehaver/vuggestuer, samt dagplejen med 10 dagplejere.

Her vil man nu pr. 1. januar ændre ledelsesstrukturerne, fra at der er selvstændige ledere i hvert af børnehusene, til at der er overordnede ledere for grupperingen. Dette betyder, at fra at være afdelinger under Børne & Unge, overenheden Børnehuse, indsættes en ny enhed; Børn 0-6 år med underenheder, hvorunder de forskellige børnehuse nu grupperes, samt at Dagplejen splittes i de to nye Områder, og at Dagplejen som enhed forsvinder.

Formålet med denne organisationsændring er at samle en del af de praktiske administrative processer og frigøre ledernes tid i de enkelte huse til at være faglige ledere og personaleledere, samle de økonomiske/administrative opgaver i overordnede funktioner og derved effektivisere.

Før ændring i Børn & Unge


Efter ændringer i Børn & Unge

Dette betyder i praksis, at der er ændringer i alle placeringer af børnehusene i den administrative organisation, og administrative medarbejdere fra de enkelte børnehuse samles i selvstændige afdelinger. Der omflyttes på lederstrukturerne, således at hver gruppe af børnehuse får en overordnet leder. Disse nye ledere udvælges fra den nuværende lederstab, og nye daglige ledere udpeges. Samtidig bliver et par enkelte børnehuse lagt sammen, mens andre børnehuse ikke ændres. De 5 administrative medarbejdere reduceres til 3 og samles i enheden Børneområdet Syd.

Illustrationen viser den administrative organisation før og efter ændringen. Den viser ændringen for det nye Børneområdet Syd, hvor der er fire børnehuse og en afdeling af dagplejen. Børnehuset Søstjernen er en samling af Børnehaven Stjernen og Vuggestuen Søhesten. I Børnehusene Blomsten, Løven og Troldehaven ændres kun ledernes ansvar, og de administrative medarbejdere fjernes fra disse børnehuse. Søhesten er et helt nyt Børnehus, samt at der også kommer en afdeling af dagplejen i Børneområdet Syd, nemlig Dagplejen Syd.

Ændringen går derfor konkret ud på:

Opret en ny enhed: Børn 0-6 år.

Opret underenhed: Børneområdet Syd.

Flyt 3 enheder (Blomsten, Løven og Troldehaven) til ny placering med start 1.1 –

under enheden Børneområdet Syd.

Opret 2 nye enheder med start 1.1 (Søstjernen og Dagplejen Syd) - under

enheden Børneområdet Syd.

Nedlæg enhederne Stjernen og Søhesten med sidste aktive dag 31.12.


Nedlæg enhederne Dagplejen og Børnehuse med sidste aktive dag 31.12.

Flyt 3 medarbejdere til enheden Børneområdet Syd start 1.1.

Flyt 6 dagplejere fra enheden Dagplejen til enheden Dagplejen Syd start 1.1.

Flyt alle medarbejdere fra enhederne Stjernen og Søhesten til enheden

Søstjernen start 1.1.

Flyt leder fra en enhed til enheden Børneområdet Syd – med økonomisk ansvar.

Ændre lederansvaret for alle ledere i alle enhederne til daglige ledere med

fagligt og personalemæssigt ansvar.

Børneområdet Syd har 80 ansatte i alt – dette ændres der ikke ved.

For hele enheden Børn 0-6 år er der i alt 10 børnehuse, og efter ændringen er der 8 børnehuse fordelt i de to områder Syd og Nord. To børnehaver flyttes sammen til en, og en børnehave integreres med en vuggestue i et nyt børnehus. Derudover er der en mængde lignende ændringer for Børneområde Nord.

For at alt dette kan finde sted, skal alt det praktiske være på plads:

Navne på alle enheder

Hvordan enhederne skal placeres i hierarkiet

Adresse på alle enheder, der ændres

Telefon numre på alle enheder, der ændres

Overblik over ændringer af kontorpostkasser ift mail-lister, kontakt-

mailadresser mv.

Konkret hvilke medarbejdere, der flyttes til hvilke enheder

Konkret alle titler på lederne

Konkret hvilket ansvar de enkelte ledere får efter ændringen ift. at kunne ændre

i systemerne og rettighederne.

Hvor skal der ændres?

Nedenstående er et udsnit af steder, hvor denne ændring af Børn & Unge Centeret skal implementeres.

Active Directive

o Omlægge strukturen

o Flytte medarbejdere på plads

o Oprette basisoplysningerne, således at systemer der trækker på AD kan

få de rigtige oplysninger

Mail-signaturen

o således at alle mailsignaturer er i overensstemmelse med de nye

enheders navne, samt at titlerne er korrekte på alle ændrede

Mail-listerne/Mail-grupper

o Mail-listerne, som bruges til fælles mails af forskellige karakter

Fællesdrev skal ændres

Kommunens Omstilling

o Omstillingen skal have besked ift. at kunne rette henvendelser til det

rette sted.


Diverse brevhoveder i breve fra kommunen og ud

Organisationsdiagrammerne

o Primært på kommunens hjemmeside, således at det er synligt, hvilke

børnehuse der findes

Hjemmesiden/Intranet

o Således at sider vedr. de gamle børnehuse fjernes og de nye tilføjes

Lønsystemet

o Medarbejdere flyttes til de rigtige afdelinger og lønnes fra de rigtige

konti.

o Stillinger oprettes og andre nedlægges.

o Organisation skal rettes til ift. den nye struktur.

o Adgange ift. rettigheder ændres – med den nye lederstruktur skal der

også ændres i, hvem der kan hvad, specielt efter at økonomiansvar

fjernes fra de enkelte børnehuse og placeres i Børneområde Syd.

Økonomisystemet

o Enhederne skal ændres.

o Kontoplanen skal ændres.

o Nye konti skal oprettes og andre nedlægges.

o Adgange til, hvem der har rettigheder til hvilke handlinger

P-numre ændres (et produktionsnummer tilhører den enkelte lokation, altså

hver enkelt adresse, hvor der ligger en afdeling af kommunen). Det skal bl.a.

rettes i lønsystemet til brug i Danmarks Statistik. Og så skal ændringerne

rapporteres tilbage til CVR.

Ændre KMD LOS alt efter kommunens anvendelse af denne

Rekrutteringssystem ift. at få de rigtige oplysninger på stillingsopslag

Diverse fagsystemer ændres.

o Institutionssystemet

Opkrævningssystemet for forældrebetaling

o Pladsanvisning

Ændres, således at børnene kan fordeles og tildeles korrekt.

ESDH

o Ændres i strukturerne, således at sager oprettes og placeres rigtigt.

Ovenstående er bare et udpluk af, hvad der er af ændringer. Nogle kommuner har delvist automatiseret nogle af processerne, men andre er helt manuelle. Ændringen ovenstående har også konsekvenser, fordi den ligger omkring årsskiftet og årsafslutningen, så man kan ikke bare flytte rundt, uden at det kan give problemer, når året ikke er afsluttet. Derfor kan det være, at man venter med at lave ændringen, til man rammer 1.2, dog med tilbagevirkende kraft.

Ikke alle systemer kan håndtere at lave ændringer forud og tilbage i tid – man ændrer pr. dags dato, når man ændrer. Og har systemerne historik, ift. hvordan det tidligere så ud?

Ofte er det enkeltpersoner, der har hver deres del af de ændringer, der skal laves, og skal informeres herom.

Ændringer har også konsekvenser for sygefraværs-statistikkerne. Ved ændringer sker der ofte det, at man ikke kan sammenligne år for år. I en ændring som med


Børneområdet Syd kan sygefraværet for de uændrede børnehuse ses med historik, mens det nulstiller for Børnehuset Søstjernen.

For hele Børneområdet Syd vil der kun kunne samles sygefravær fra den 1. januar, hvor ændringen træder i kraft.

Ovenstående er et eksempel på, at en ændring med at flytte et par børnehuse rundt er en mere omfangsrig affære end det ser ud til på papiret. Derfor er det en ressourcekrævende opgave og kræver en del forarbejde for at få oplysningerne rigtigt indsamlet, før man kan lave ændringerne. Og derefter er rækkefølgen, ift. hvordan man ændrer it-systemerne, afhængige af hinanden.

Med OS2MO bliver det lettere at lave ændringer, da systemerne kan hente oplysningerne herfra og dermed helt fjerne it-systemernes afhængigheder. Også næste gang.


Bilag 11 PROJEKTET KORT FORTALT

Medarbejder og Organisationsdata – Hvad er den rigtige

version?

Den enkelte kommune har i dag mange steder, hvor oplysninger om den administrative organisation og medarbejdere anvendes. Men hvordan kommer disse oplysninger ind i de relevante systemer? Og hvordan vedligeholdes de? Når man ser nærmere på disse oplysninger, er det jo i grunden de samme – medarbejderes navne, stillinger, telefonnumre mv., og på afdelingerne er det navnet på enheden, adressen og kontaktoplysninger, vi genfinder.

Mange gange er disse grundoplysninger manuelt indtastet i det enkelte system med mulighed for fejl. Og udfordringen er, når den kommunale organisation konstant er i forandring, om der så bliver rettet i alle it-systemerne? Det er en opgave, der løbende kræver mange ressourcer. Kommuner har bl.a. i årevis forsøgt at samle disse oplysninger i en række forskellige systemer:

Active Directory med de begrænsninger, der er i AD I lønsystemet benyttes en anden organisationsmodel end AD. I økonomisystemer med en organisationsmodel sammenblandet med

kontoplanen I KMD LOS med strukturerne omkring organisationen til anvendelse i KMD

portefølgen Og mange andre it-systemer med hvert deres lokale behov

Systemlandskab i kommunerne har længe været styret af leverandørerne, og kommunerne har nu brug for at hjemtage ejerskabet over egne data på klassifikations- og organisationsområdet. Der er med Den fælleskommunale Rammearkitektur skabt en mulighed for at hjemtage.

Samtidig bliver kommunerne i disse år udfordret af Monopolbruddet, der stiller store krav til, at der er styr på grunddata. Senest er Den Fælleskommunale Digitaliseringsstrategi kommet med krav til, at sager på længere sigt vendes mod borgerne. Derfor er det logiske sted at starte denne proces for den enkelte kommune at få styr på de organisatoriske grunddata – altså kommunernes medarbejder- og organisationsdata.

OIO Standarderne som rettesnor

Med Den fælleskommunale Rammearkitekturen har kommunerne mulighed for at bruge grundkomponenterne Organisation og Klassifikation til at beskrive organisationen med. En række kommuner har siden 2010 arbejdet sammen om at anvende disse to grundkomponenter til at beskrive den kommunale administrative organisation og genanvende disse oplysninger som autoritativ kilde for deres it-systemer. Derved er mængden af fejl blevet minimeret, da manuelt genindtastning af de samme oplysninger flere gange undgås, og brugen af klassifikation giver en ensrettet struktur i data. Herved opnås en ensrettet metode til at vedligeholde oplysninger.


På markedet findes der pt. en løsning, der kan understøtte alle disse standarder i en kommune. Samtidig er KOMBIT i gang med at udvikle Støttesystemerne, som ligeledes rummer Organisation og Klassifikation. Disse er dog i starten begrænsede til kun at kunne håndtere de oplysninger, som KY, KSD og SAPA har brug for. For at kunne drage nytte af rammearkitekturen i den enkelte kommune, har kommunerne behov for yderligere understøttelse i form af en lokal implementering af funktionalitet til Klassifikation og Organisation. Derfor er der brug for en løsning, udviklet specifikt til kommunernes aktuelle og fremtidige behov, til at rumme kommunernes medarbejder- og organisationsdata (MO). En løsning, der også er ejet af kommunerne, så kommunerne kan styre den fremtidige udvikling af MO.

Vejen til målet

OS2MO-projektet starter ikke fra bunden i udviklingen af løsningen. Odense Kommune har udviklet en brugergrænseflade og et forretningslag, der vil indgå som dele i løsningen. Som en del af projektet skal brugergrænsefladen færdigudvikles. Størstedelen af de opgaver, der tilbagestår i MO-projektet, er at udvikle ”kernen” med Klassifikation, Organisation samt håndtering af hændelser/beskeder.

MO vil blive udviklet agilt efter SCRUM-metoden. Dette giver en god mulighed for at bryde kravspecifikationen op i løbende leverancer, hvorfor projektet vil rumme flere udbud, hvor første udbud var indkøb af konsulentydelser til kvalitetssikring, arkitektur og kravstillelse.

Projektet vil via udbud finde den rette leverandør til at udvikle MO, som kan levere udviklingstimer efter kvalifikation og teknologivalg. Projektet forventes således hurtigt at kunne vise resultater ved løbende leverancer af anvendelige delkomponenter, der tilsammen danner løskoblede dele af hele OS2MO 1.0.

MO udvikles under OS2’s ejerskabskrav, og der vil derfor være synlighed af både kode og testmetodikker, således at kommuner, der selv ønsker at bygge videre eller ændre i funktionaliteten, frit selv kan gøre det eller få tredjepart til at gøre det.

OS2MO giver styr på grunddata og ejerskab over kritisk organisationsdata Med MO får den enkelte kommune mulighed for både at implementere ramme-arkitekturen og samtidig få styr på organisatoriske grunddata. MO kan indgå i forskellige løsningsscenarier, alt efter eksisterende løsninger i den enkelte kommune, men kan også være startskuddet til at ensrette processer og arbejdsgange og således sikre/opnå valide grunddata. Derfor er MO ikke kun implementeringen af et projekt, hvor mange organisatoriske arbejdsgange skal ses efter i sømmene og strømlines. I kølvandet på MO vil projektet også levere implementeringsvejledninger, forslag til organisering og best practise for anvendelse og vedligeholdelse af data.

MO understøtter således den enkelte kommunes arbejde med at blive klar til at håndtere de krav, KOMBIT’s Støttesystemer har til organisatoriske grunddata. Blandt andet kan MO udstille KLE-opmærkningen af organisatoriske enheder til brug for digitale arbejdsgange eller sikkerhedsmodellen.

MO sikrer, at egne grunddata om egen organisation kan opsamles og vedligeholdes der, hvor viden om disse data er – i organisationen. Med OS2MO er kommunen således en del af et fælleskab af kommuner med ejerskab af egne grunddata. Samtidig er det et fælleskab, hvor rammearkitekturen får lokal understøttelse og kommunernes


modenhed bliver løftet. Med dette fællesskab følger ligeledes sparring og mulighed for andre samarbejder ift. videreudvikling omkring løsning af fælles behov, f.eks. en løsning til håndtering af MED/AM-organisationen. OS2MO version 1.0 er kun starten på en spændende rejse.

Projektet arbejder med tilslutning i Q1 2016. Mere herom i Beslutningsdokumentet i afsnittet Tilslutningsaftale.


Bilag 12 EXECUTIVE SUMMERY – Paradigmeskiftet af kommunernes digitale fundament

Vi skal have styr på fundamentet

I 2020 skal vi have en decentralt funderet offentlig sektor, der på én gang yder og faciliterer nær og tilgængelig, sammenhængende og effektiv service for og med borgerne og virksomhederne.

Vi skal styrke oplevelsen af nærhed og indflydelse på egen livssituation, og de digitale services skal opleves integrerede og personlige, så de tilpasses borgerens aktuelle livssituation og behov.

Sideløbende med realiseringen af den Fælleskommunale Digitaliseringsstrategi gennemføres Monopolbruddet, der er den første trædesten i realiseringen af den Fælleskommunale Rammearkitektur. Dertil kommer hele Grunddataprogrammet, der i omfang og effekt er større end Monopolbruddet.

Disse initiativer medfører et radikalt paradigmeskifte for kommunerne og stiller helt nye krav til kommunernes digitale og organisatoriske fundament. Et fundament, der i dag ikke er sammenhængende, og hvor det er leverandørerne og ikke kommunerne, der har kontrol over fundamentet.

I dag har vi mange leverandører, der er ”specialister” inden for hver deres fagområde. De helt centrale og vigtige data vedligeholdes asynkront i forskellige it-systemer, og kommunerne kan ikke få adgang til disse (uden en regning). Samtidig er styringen af data i høj grad baseret på manuelle indtastninger med deraf følgende muligheder for fejl. Fagområderne oplever det ikke nødvendigvis som et problem i dag, men når data udveksles på tværs, og det skal ske sømløst, opstår udfordringerne.

Vi, kommunerne, har ikke metodisk styr på vores data. Vi kender ikke vores procedurer. Vi ved ikke, hvem der er ansvarlig for hvad, og hvis vi gør, er processerne ofte manuelle og afhængige af få nøglepersoner spredt i organisationen. Det er ikke robust og kan ikke understøtte den digitale transformation, der sker lige nu og i årerne frem.

De nuværende it-systemer er bygget i en anden tid. Vi er på vej mod en verden, hvor it-systemerne i langt højere grad skal hænge sammen, men ikke været bygget sammen som silo’er, systemerne skal kunne dele data og involvere borgere og virksomheder i vores processer. Det kræver standarder og et arkitekturmæssigt ejerskab. Det kræver, at vi bygger med den rigtige arkitektur og stiller de rigtige krav til leverandørerne og til os selv.

Vores nuværende fundament kan ikke bære udviklingen og skal udskiftes.


Medarbejder og organisationsdata er første trædesten

Det tager tid at skabe et nyt fundament. Vi er på vej mod en verden, hvor systemerne skal hænge sammen og dele data. Vi skal bygge med den rigtige arkitektur og stille de rigtige krav til vores leverandører. En sådan omstilling kræver styring og opbygning af en ny governance-struktur i den enkelte kommune. Det er dog en transformation, vi i fællesskab kan sikre sker i den rette retning og med en fælles fremdrift, så ingen bliver efterladt på perronen. Et af de helt centrale områder i omstillingen er Medarbejder- og Organisationsdata. Disse grundlæggende data for en organisation, har de færreste kommuner i dag en governance omkring. Data ligger i mange systemer og vedligeholdes manuelt og uden central styring. Det skaber allerede i dag store udfordringer, særligt ved organisationsændringer, men også helt simpelt ved ansættelser og fratrædelser.

Men det handler ikke kun om organisations- og persondata, men også om klassifikation. Klassifikation handler om begreber. Om at anvende de samme begreber på den samme måde. En måde at anvende klassifikation kan sammenlignes med affaldssortering på genbrugspladsen. Her er affaldet klassificeret i forskellige emner, eksempelvis plast, småt brændbart, glas osv. Det samme sker for de data, vi anvender i fagsystemerne i dag, eksempelvis i økonomisystemerne, hvor der anvendes en klassifikation for kontering, økonomi- og indenrigsministeriets kontoplan. En anden klassifikation er KL’s Emnesystematik KLE, der anvendes til at beskrive den kommunale opgaveløsning. Ved at anvende de samme begreber på tværs af fagområder og organisationer kan data flyde frit. Systemerne kan udstille data til andre systemer og genkende data fra disse ved hjælp af klassifikationerne.

Skal kommunale data udstilles og anvendes på tværs af fagområder og sektorer, og samtidigt udstilles overfor borgere og virksomheder, kræver det, at organisationerne er beskrevet efter samme standard og der anvendes ens klassifikationer. Uden dette fælles ”sprog” er det besværligt og dyrt at opretholde sikkerheden omkring data og visionen om en sammenhængende offentlig sektor.

Markedet og KOMBIT løser ikke udfordringerne

Leverandørerne har i mange år set en forretningsmæssig fordel i at kapsle kommunernes data inde i deres egne systemer og sælge vores data til os selv, ofte flere gange. Selvom markedet langsomt er ved at fjerne sig fra de gamle forretningsmodeller, så sker det kun meget langsomt og slet ikke i et tempo, hvor vi i kommunerne vil kunne leve op til de krav den Fælleskommunale Digitaliseringsstrategi og Monopolbruddet stiller til os. Vi skal tage ejerskab og stille nye helt og andre typer af krav til leverandørerne.

KOMBIT er i fuld gang med at gøre klar til den store udrulning af de første fagsystemer og Støttesystemerne, der bryder KMDs monopol. Men KOMBITs fokus er netop på Monopolbruddet og ikke på de øvrige forretningssystemer, som kommunerne anvender. En gennemsnitskommune har 150+ it-systemer, og det er kun 3 af disse, monopolbruddet omfatter. Der går, ifølge udmeldingen fra KOMBIT, minimum 2 år (medio 2018, hvor implementeringen af KY afsluttes), før resten af kommunernes systemportefølje kan drage nytte af Støttesystemerne i Monopolbruddet, og til den tid vil det være for sent at realisere de politiske visioner og ideer.


Implementeringen af Monopolbrudssystemerne er et lokalt ansvar, understøttet overordnet af KOMBIT. Derfor har kommunerne selv ansvaret for at løfte opgaven med de kompetencer, de har til rådighed.

Vi gør det sammen

I OS2, kommunernes open source-fællesskab, har kommunerne besluttet at igangsætte et projekt, der skal tilvejebringe fundamentet. Vi tager, som kommuner, ansvar for ejerskabet af vores data og til de systemer, der danner det fremtidige fundament. Vi vil sammen udvikle OS2MO (Medarbejder & Organisation), der vil være dén autoritative kilde2 til Medarbejder- & Organisationsdata. Én kilde, der udstiller data til KOMBIT og de leverandørdrevne systemer.

Via OS2MO får kommunerne en løsning, der udvikles på baggrund af de fællesoffentlige standarder og den Fælleskommunale Rammearkitektur. Den bliver ejet af kommunerne og er fra starten udviklet til at kunne håndtere både monopolbruddet og de 150+ andre it-systemer.

Projektet understøtter paradigmeskiftet og danner fundamentet for, at kommunerne kan erstatte gamle manuelle processer med nye mere automatiserede forretningsprocesser til styring og vedligehold af Medarbejder & Organisationsdata.

OS2MO er ikke kun et teknisk it-projekt. Teknikken fylder naturligvis, men det er kun en mindre del af det samlede projekt. Med OS2MO opbygges en governancestruktur3, der rummer fællesskabet, men også giver plads til individuelle hensyn og behov. Anvendelse, udvikling og løbende vedligehold af datastandarder og klassifikationer kræver styring. Ved anvendelse af en fælles løsning for organisation- og persondata, samt klassifikationer, kræves der en stærk fælles governancestruktur. I OS2MO sikrer vi rammerne om den fortsatte udvikling og tager i fællesskab styring.

I OS2MO vil vi udarbejde implementeringspakker og hjælpe kommunerne med at komme i mål. Det kan være via fælles implementeringer i de kommunale samarbejder, via fælles krav til konsulentmarkedet og lignende tiltag, der sikrer at kommunerne får de rigtige kompetencer og hjælp til implementeringen.

Vi vil samtidig understøtte den lokale kommunikation med præsentationsmateriale, skriftlig og digital kommunikation. Vi understøtter den lokale implementering og står sammen om de udfordringer, kommunerne står overfor.

OS2MO er ikke et it-projekt, men et organisatorisk projekt, der handler om at ændre måden, vi organiserer arbejdet omkring data, startende med organisations- og

2 Med autoritativ kilde menes, at data opsamles og udstilles et sted fra. Der ikke nødvendigvis her oplysningerne fødes,

men det er herfra, data kan vedligeholdes og genbruges på tværs af systemer.

3 Med governance menes, at OS2MO-projektet tager ansvar for, at der er en it-arkitekturgruppe til løsningen som sikrer

videreudvikling og sammenhænge til Rammearkitekturen og de eksisterende it-løsninger. Samtidig er der brug for et

fælles begrebsapparat og anvendelsesmønstre for at understøtte samarbejde. Dette bliver gennem en fælles

anvendelsesgruppe. Samtidig understøttes governance ift videreudvikling, så det sker efter projektets anvisninger, og at

kommunerne får frie valg i leverandører.


medarbejderdata. En sådan forandring kræver ledelse og ledelsesmæssig opbakning, bredt i hele organisationen. Men vi skal starte et sted, og det er med monopolbruddet, og implementeringen af OS2MO passer godt ind i denne sammenhæng. Herefter udvides indhold og rammer for data og klassifikationer over tid.

OS2MO er et projekt, kommunerne har haft behov for i mange år, men aldrig er kommet i gang med. Initiativet til at skabe en forandring har kommunerne hidtil ikke selv taget, da de ikke har vidst, hvor de skulle starte, men overladt dette til leverandørmarkedet, der ikke har haft en økonomisk interesse i at løse problemstillingerne til fordel for kommunerne.

Vi står derfor med et komplekst og mere eller mindre kaotisk systemlandskab, der på meget få år skal omstilles. KOMBIT har fokus på konkurrenceudsættelse af KMD-systemerne, OS2MO har et generelt fokus på samtidig at understøtte resten af kommunens forretning i monopolbruddet.

Tiden er kommet til et paradigmeskifte!


Bilag 13 TILSLUTNINGAFTALE OS2MO

[Kommunens navn]s (”Kommunen”) tilslutning til OS2MO.

OS2MO-indkøbet bliver afholdt af Silkeborg Kommune på vegne af alle tilsluttede kommuner. Der er ingen aftageforpligtelse forbundet med tilslutningen til OS2MO.

Ved sin underskrift på denne tilslutning giver Kommunen Silkeborg Kommune tilladelse til på Kommunens vegne at indgå aftaler med en eller flere leverandører om udvikling af OS2MO, idriftsættelse, drift og vedligehold samt eventuelt brugersupport. De enkelte aftaleindgåelser vil ske i forskellige faser i projektet.

Tilslutningen forudsætter, at udbudsreglerne er overholdt, ligesom gennemførelsen af det samlede projekt sker i overensstemmelse med Beslutningsdokument af 22. marts 2016, hvor nærværende tilslutningsaftale er bilag 13. Såfremt der ikke opnås tilstrækkelig kommunal tilslutning, bortfalder Kommunens tilsagn om tilslutning.

Projektet gennemføres i overensstemmelse med den tidsplan, der fremgår i Beslutningsdokumentet. For at kunne overholde tidsplanen, skal den underskrevne tilslutning være OS2MO sekretariatet i hænde senest fredag den 15. april 2016 på [email protected].

Aftagemodel Kommunen kan efter eget valg aftage ydelserne, omfattet af de indgåede aftaler. Dog forpligter Kommunen sig ved tilslutning til at betale det i Beslutningsdokumentet fastsatte beløb pr. borger på kr. 5,-, dog med knæk ved 150.000 borgere, jf. KOMBITs afregningsmodel. Beløbet betales, uanset om Kommunen tager systemet i brug eller ej.

Ved eventuel overtegning vil beløbet blive justeret. Læs nærmere herom i Beslutningsdokumentet under afsnittet Tilslutningsaftalen.

Databehandleraftale Kommunen vil, inden behandling af data påbegyndes, modtage en databehandleraftale.

Tiltrædelse Kommunen bekræfter ved sin underskrift på denne tilslutning sin deltagelse i OS2MO-projektet.

____________________________________________________________________________________________

Kommunens navn

__________________________________________________________________ _____________________

Navn og titel Dato

Documents

BESLUTNINGSMATERIALE Bilag samlet 1 - os2.eu · 02.11.2015 med leverandøren, Xebia. Odense MO er et klientsystem til organisationskomponent KMD APOS2. MO indeholder en brugergrænseflade,