Sådan laver du en samlet vurderingsmodel til softwarevalg

Formål, beslutning og rammer

En vurderingsmodel skal besvare ét konkret spørgsmål: hvilken it-anskaffelse organisationen vælger at gennemføre. Københavns Kommune vedtog i budget 2012 at indføre en fælles beslutningsproces for anskaffelse af større it-systemer. Modellen bør have frister og en klar angivelse af, hvem der er bundet af vurderingen.

En komplet, anvendelig vurderingsmodel til softwarevalg skal indeholde kriterier, vægtning, scoring og beslutningsgates. Hver del skal have en ejer og et beslutningspunkt.

Den samlede model bygges trinvist: formål og beslutningsramme, behovskortlægning, kriterier, krav/ønsker/dokumentation, åbenhed, vægtning og scoring, review, implementering og revision. Hvert trin skal have en ejer og et beslutningspunkt.

Den anskaffende enhed skal følge den obligatoriske del af it-anskaffelsesvurderingen fra Koncernservice. Vurderingen indhentes forud for større it-anskaffelser finansieret af anlægsmidler og inden beslutning om, hvilken anskaffelse man vil foretage. Servicemålet er gennemsnitligt 15 arbejdsdage fra henvendelse til it-vurderingen foreligger.

Placer beslutningskompetencen eksplicit. I Københavns Kommune indstiller Økonomiforvaltningen til Økonomiudvalget, som anbefaler over for Borgerrepræsentationen. Processen omfatter alle større it-anskaffelser i kommunen.

For statslige myndigheder gælder en anden ramme. Myndigheder, der opfylder mindst ét af kriterierne, skal følge modellen for porteføljestyring af statslige it-systemer og gå til review ved Statens It-råd. Kriterierne er årlige it-omkostninger på mere end 70 mio. kr., samfundskritiske it-systemer i porteføljen eller it-projekter med it-aktstykker tiltrådt af Folketingets Finansudvalg.

Statens It-råds rådgivning skal understøtte it-styringen. Den skal sikre en effektiv, opdateret og vedligeholdt it-systemportefølje.

Kobl vurderingen til organisationens strategiske styringsdokumenter. Et enkelt systemvalg må ikke trække i en anden retning end porteføljen. Københavns Kommunes platformstrategi beskriver, hvordan digitaliseringsbehov kan løses med færre it-systemer. De udvalgte teknologier i platformstrategien udgør grundlaget for Koncernservices it-anskaffelsesvurderinger.

It-anskaffelser er samtidig underlagt den fælleskommunale digitaliseringsstrategi. Den stiller en række digitaliseringskrav til kommunerne. For statslige myndigheder er koblingen mellem strategi og systemvalg forankret i porteføljestyringsmodellen og review hos Statens It-råd.

Kortlæg behov og nuværende systemlandskab

Start kortlægningen med tal, der viser spredningen. Ved opgørelsen i indstillingen om bedre styr på it-indkøb havde Københavns Kommune ca. 550 it-systemer og systemintegrationer/services samt ca. 180 nye it-projekter i pipeline. Kommunens samlede driftsudgifter til it udgjorde ca. 500 mio. kr. i regnskab 2011.

Kortlægningen skal give tal, der kan bruges i vægtningen og scoringen. Antal systemer, integrationer, projekter og driftsudgifter er eksempler på sådanne tal.

Trin 1 i den samlede model er kortlægningen. Den skal omfatte antal systemer, integrationer/services, projekter i pipeline og driftsudgifter.

Antallet blev brugt som begrundelse for behovet for koordinering og styring. Det gjaldt udgifter til anskaffelse, drift og vedligehold på tværs af kommunen. En tilsvarende opgørelse over systemer, integrationer og igangværende projekter er nødvendig, før du kan vurdere, om et nyt system tilfører noget. Ellers bliver det blot endnu et system med samme formål.

Kortlægningen er også en formel forudsætning i staten. Myndigheder omfattet af porteføljestyringsmodellen skal kortlægge deres it-systemportefølje. De skal udarbejde en it-handlingsplan, der er det centrale dokument for rådgivning og review hos Statens It-råd.

I Københavns Kommune var et udtrykt mål med den fælles beslutningsproces at reducere antallet af it-systemer. Flere af systemerne løste de samme forretningsbehov.

For private virksomheder er den samme kortlægning nødvendig. Dhlan.dk beskriver, at mange danske virksomheder vælger masseproducerede løsninger og ender med software, der ikke opfylder deres reelle behov. Kortlægningen skal derfor vise både eksisterende software og de reelle behov.

Beskriv forretningsbehovet, før du beskriver løsningen. Medtag integrationerne i behovsbilledet. Ifølge dhlan.dk er god integrering noget af det vigtigste ved ny software, fordi den skal kunne kommunikere problemfrit med eksisterende software. Opstår der fejl og gnidninger internt i softwaren, bliver den nye løsning mindre effektiv.

Det gælder også cloud-løsninger. Nuværende apps skal kunne tale sammen med de nye. Den fællesoffentlige open source-vejledning indeholder en tjekliste, der kan bruges ved markedsafdækning, strategiudvikling, anskaffelse og implementering.

Vælg kriterier for hele softwarens livscyklus

Funktionelle kriterier er nødvendige, men ikke tilstrækkelige. Dhlan.dk peger på fire vurderingspunkter. Tre af dem kan bruges direkte i modellen.

Det første er god integrering med eksisterende software.

Det andet er databeskyttelse, herunder om løsningen kan håndtere migrering af virksomhedens data, fx datamigrering til skyen. Det tredje er enkelhed, så softwaren er så simpel og funktionel som muligt.

Gør kriterierne målbare i den konkrete anskaffelse. For integration betyder det, at den nye software skal kunne kommunikere problemfrit med eksisterende software, og at nuværende apps skal kunne tale sammen med nye cloud-løsninger. For databeskyttelse betyder det, at løsningen skal kunne håndtere migrering af data, fx datamigrering til skyen, uden at sårbar data mistes eller korrumperes.

Trin 2 i den samlede model er valget af kriterier for hele livscyklussen. Kriterierne skal dække integration, databeskyttelse, enkelhed, etablering, drift, vedligehold og udfasning.

Samme kilde skelner mellem virksomhedsstørrelser. For en mindre virksomhed vil et standardprogram ofte kunne klare jobbet. En større eller nichepræget virksomhed bør tage højde for sine unikke krav og behov. Kriterierne skal derfor rumme både standardbehov og særbehov, uden at standardkravene drukner.

Læg økonomien ind over hele levetiden, ikke kun anskaffelsessummen. Københavns Kommunes begrundelse for at konsolidere it-porteføljen handlede om at nedsætte omkostningerne ved både anskaffelse og den efterfølgende drift og vedligehold af it-løsninger. Kriteriebilledet bør derfor omfatte etableringsomkostninger, integrationsomkostninger, drifts- og vedligeholdelsesomkostninger og omkostningerne ved at udskifte eller udfase løsningen igen.

Tilføj kriterier for åbenhed, uafhængighed og resiliens, hvis organisationen vil undgå at blive låst. Rapporten om støttestrukturer, der hører til den fællesoffentlige open source-vejledning, beskriver, hvordan open source kan understøtte større autonomi og samarbejde. Den kan styrke digital suverænitet, transparens og resiliens — blandt andet over for dominerende teknologileverandører.

I publikationen "Anvendelse af åbne standarder for software i det offentlige" opereres der med udfaldet "anbefalet (bør)". En anbefalet standard vurderes typisk højt. Placer kriterierne enten blandt de obligatoriske krav eller blandt de vægtede ønsker, afhængigt af om åbenhed er et krav i den konkrete anskaffelse.

Kriterierne er de punkter, der senere vægtes og scores. De skal derfor kunne formuleres, så de kan bedømmes ens i den konkrete anskaffelse.

Skeln mellem krav, ønsker og dokumentation

Del kriterielisten i tre niveauer: obligatoriske krav, ønsker og dokumentationskrav. Københavns Kommunes model viser princippet: Den obligatoriske del af it-anskaffelsesvurderingen fra Koncernservice skal den anskaffende enhed følge. Andre dele af grundlaget er retningsgivende.

Trin 3 er at skelne mellem obligatoriske krav, ønsker og dokumentationskrav. Obligatoriske krav er gates; ønsker vægtes og scores med dokumentation.

Et obligatorisk krav bør formuleres, så det enten er opfyldt eller ikke opfyldt. Manglende opfyldelse bør udelukke løsningen frem for at blive udlignet af point på andre kriterier.

Obligatoriske krav er beslutningsgates. De skal være opfyldt, før ønskerne overhovedet vægtes og scores. Ellers bliver gaten uden effekt.

Knyt hvert kriterium til en konkret dokumentationskilde. Bestem på forhånd, hvem der godkender materialet. Reviewprocessen hos Statens It-råd illustrerer en sådan arbejdsdeling: en foreløbig gennemgang, hvor materialet forbedres, og en endelig indsendelse med ledelsesgodkendelse.

For data- og migreringsspørgsmål skal dokumentationen indhentes aktivt i stedet for at forudsættes. Dhlan.dk anbefaler, at man på forhånd stiller spørgsmål som, om den nye software tilbyder datamigrering til skyen. Undersøg de forskellige løsninger grundigt, inden du lægger dig fast.

Gør hvert sådant spørgsmål til en dokumentationslinje i modellen. Angiv, hvad leverandøren skal fremlægge, og hvad organisationen selv skal teste eller verificere.

Vurder åbenhed: open source og åbne standarder

Afklar først, hvad open source betyder i organisationens sammenhæng. Den fællesoffentlige open source-vejledning definerer open source som software udgivet under en licens. Licensen giver enhver ret til at bruge, undersøge, ændre og dele softwaren og dens kildekode frit.

De fire rettigheder — brug, undersøgelse, ændring og deling — bør du kunne svare på for hver kandidatløsning. Det gælder, hvis åbenhed indgår i vurderingen.

Åbenhedskriteriet skal indgå på samme måde som de øvrige kriterier. Det kan være et obligatorisk krav eller et vægtet ønske. Valget afhænger af den konkrete anskaffelse.

Trin 4 er åbenhedsvurderingen. Den skal afklare licensrettighederne, tjeklistens fire faser og muligheden for genbrug, hvis åbenhed indgår i anskaffelsen.

Brug den fællesoffentlige tjekliste som praktisk redskab. Tjeklisten er en del af vejledningen om brug af open source. Den kan bruges til at diskutere og tage stilling til de vigtigste overvejelser ved markedsafdækning, strategiudvikling, anskaffelse og implementering. Vejledningen er målrettet både medarbejdere og strategiske beslutningstagere, der skal tage stilling til it-anskaffelser.

Kobl åbenhedsvurderingen til digital suverænitet og resiliens, hvis det er et strategisk mål. Rapporten "National Support Structures and Capabilities for growing Digital Sovereignty through Sharing and Reuse of Open Source Software in the Public Sector" beskriver forslag til, hvordan Danmark kan styrke sin digitale suverænitet over for dominerende teknologileverandører. Den beskriver også, hvordan open source kan være en praktisk løsning, der muliggør større autonomi og samarbejde i den offentlige sektor.

Rapporten skitserer modeller for en fødereret national støttestruktur baseret på Open Source Program Offices på nationalt, regionalt, kommunalt og institutionelt niveau. En sådan struktur kan kombinere politik, indkøbs- og compliance-støtte, delt infrastruktur og fællesskabsforvaltning, eventuelt gennem en trinvis modningsvej mod et samlet økosystem.

Genbrug er et selvstændigt spor. Rapporten om genbrug af software i den offentlige sektor kortlægger politik og praksis for genbrug af software i 15 digitalt modne lande. Ifølge den fællesoffentlige beskrivelse kan den bruges til at støtte strategiske beslutninger, fx om at udvikle en vision for genbrug af software og open source.

Tag stilling til, om eksisterende offentlige løsninger eller komponenter kan genbruges, før der vælges nyudvikling. Den beslutning hører i vurderingsmodellen og ikke i implementeringsfasen.

Tjekliste til åbenhed og open source i offentlig sektor

Omsæt kriterierne til en samlet vurderingsmodel

Byg modellen op i to lag. Første lag er obligatoriske krav, der fungerer som gates. En løsning, der ikke opfylder dem, falder ud, uanset hvor godt den scorer på ønsker.

Navngiv modellens fire bestanddele: kriterier, vægtning, scoring og beslutningsgates. Kriterierne vælges i trin 2 og 3. Vægtningen og scoringen hører til ønskerne. Beslutningsgaten placeres før kontrakt og implementering.

Andet lag er ønsker og vurderingskriterier, der vægtes og scores. Hvert kriterium bærer en henvisning til den dokumentation, der begrunder scoren. Københavns Kommunes model illustrerer samme logik: De udvalgte teknologier i platformstrategien udgør grundlaget for Koncernservices it-anskaffelsesvurderinger. Den obligatoriske del skal følges af den anskaffende enhed.

Den samlede model er en trinvis opskrift. Den går fra 1) kortlæg behov og systemlandskab over 2) vælg livscykluskriterier, 3) skeln mellem krav, ønsker og dokumentationskrav, 4) vurder åbenhed og 5) vægt og scor ønskerne til 6) review og beslutningsgates samt 7) implementering, opfølgning og revision.

Vægtningen sker ved at rangere ønskerne efter den konkrete anskaffelse. Obligatoriske krav er ikke vægtede ønsker; de er gates. Hver score skal kunne føres tilbage til en dokumentationslinje.

Den samlede vurdering skal vise, hvordan hvert ønske vægtes, og hvordan det scores. Hver score skal have en dokumentationslinje. Gates holdes uden for den vægtede score.

Modellen bør kunne aflæses direkte: kriterium, type, vægt, score, dokumentation og beslutningsgate. Uden den kobling bliver vurderingen en samling løsrevne krav.

Uden kriterier, vægtning, scoring og gates kan modellen ikke bruges til at træffe en beslutning. Den bliver en liste af krav uden rangorden.

Læg konsekvenserne for den samlede it-portefølje ind som et selvstændigt vurderingspunkt. I Københavns Kommune var det et udtrykt mål med den fælles beslutningsproces at reducere antallet af it-systemer. Flere systemer løste de samme forretningsbehov. Platformstrategien skulle beskrive, hvordan digitaliseringsbehov kunne løses med færre it-systemer.

Et nyt systems integrationsflade, overlap med eksisterende systemer og bidrag til eller aftryk på konsolideringen bør derfor kunne aflæses direkte af modellen.

Planlæg vurderingens tidsforbrug som en del af modellen. Servicemålet i Københavns Kommunes model viser, at vurderingen skal have en defineret tidsramme fra henvendelse til vurdering. Har organisationen flere konkurrerende anskaffelser i pipeline, er det nødvendigt at beskrive, hvordan vurderingerne prioriteres. Beslutningsgrundlaget skal komme i tide til den beslutning, det skal understøtte.

Vis usikkerheden frem for at skjule den i et gennemsnit. Marker for hvert kriterium, om scoren bygger på leverandørens oplysninger, på egen test, på referencebesøg eller på andre kilder. Hold foreløbigt materiale adskilt fra det endelige, godkendte materiale.

Kvalitetssikring gennem review og beslutningsgates

Statens It-råds proces er en færdig skabelon for et reviewforløb med ledelsesinvolvering. Arbejdet opdeles i tre trin. Det første er en forberedende proces med opstartsmøde hos sekretariatet og eventuelt et rammesættende møde med Statens It-råd.

Det andet er selve reviewet hos Statens It-råd, der inkluderer et dialogmøde. Det tredje er opfølgning og rapportering med et opfølgende møde mellem reviews samt årlig statusrapportering. I figuren over processen er de udfyldte ikoner de procestrin, der direkte involverer myndighedens øverste ledelse.

Trin 6 i den samlede model er reviewet og beslutningsgaten. Reviewet gentager den statslige tredeling: forberedelse, review og opfølgning. Gaten placeres før kontrakt og implementering.

Beslutningsgaten skal kontrollere, at kriterier, vægtning og scoring er gennemført. Den skal også kontrollere, at de obligatoriske krav er dokumenteret opfyldt. Først derefter kan anskaffelsen gå videre.

Fastlæg mødekaden med konkrete intervaller. Opstartsmødet holdes ca. 6 måneder før reviewet og er henvendt til de medarbejdere og kontorchefer, der arbejder med kortlægning og udarbejdelse af it-handlingsplanen. Her informerer sekretariatet om processen og præciserer datoer for review og indsendelse af materialer.

Det rammesættende møde holdes umiddelbart efter opstartsmødet, altså også ca. 6 måneder før reviewet, hvis myndigheden har behov for det. Det kan fx være ved udskiftning i ledelsen siden sidste review eller, hvis myndigheden ikke tidligere har været til review. Her deltager to medlemmer af It-rådet og myndighedens øverste ledelse, herunder øverste direktør. Formålet er at drøfte ledelsens involvering i og forankring af arbejdet samt forventet udbytte.

Materialegennemgangen ligger ca. 2 til 3 måneder før reviewet. Efter den endelige indsendelse har Statens It-råd og sekretariatet 8 arbejdsdage til at gennemgå materialerne. På dag 8 sender sekretariatet en kommenteret dagsorden til myndigheden.

Indbyg beslutningsgaten før kontrakt og implementering, ikke efter. I Københavns Kommune skal it-anskaffelsesvurderingen indhentes forud for større it-anskaffelser finansieret af anlægsmidler. Det skal ske, inden der træffes beslutning om, hvilken anskaffelse man vil foretage.

Læg reviewet som et formelt stop i din egen proces. Spørgsmålet er, om beslutningsgrundlaget er godkendt af den øverste ledelse, og om de obligatoriske krav er dokumenteret opfyldt, før der forhandles kontrakt.

Tidsplan for review hos Statens It-råd

Implementering, opfølgning og revision

Etabler et fast sted, hvor teknologivalgene holdes vedlige. I Københavns Kommune godkendes processen for vedligeholdelsen af teknologivalgene og placeres i Koncernservice. De udvalgte teknologier udgør grundlaget for de efterfølgende it-anskaffelsesvurderinger.

Modellen skal holdes levende efter beslutningen. Kriterier, vægte og dokumentationskrav skal kunne revideres ved næste anskaffelse.

Uden en sådan ejer og proces bliver kriterielisten hurtigt forældet. Næste anskaffelse vurderes så mod et grundlag, der ikke længere svarer til porteføljen.

Gør opfølgningen dokumentbaseret og tilbagevendende. For statslige myndigheder i porteføljestyringsmodellen indeholder processen et opfølgende møde mellem reviews samt årlig statusrapportering. Læg tilsvarende datoer ind i din egen kalender: et opfølgningsmøde, hvor gevinster og afvigelser gennemgås, og en årlig status, hvor porteføljen vurderes samlet.

Følg implementeringen på de punkter, hvor fejl får varige konsekvenser. Ifølge dhlan.dk er datamigrering og databeskyttelse de områder, hvor mange virksomheder arbejder med en stor mængde sårbar data, der ikke bør mistes eller korrumperes. Man bør derfor undersøge løsningerne grundigt, inden man lægger sig fast — herunder om løsningen tilbyder datamigrering til skyen.

I den fællesoffentlige open source-vejledning dækker tjeklisten også implementering. Den kan bruges til at tage stilling til overvejelserne i den fase.

Trin 7 er implementering, opfølgning og revision. Revisionen skal opdatere teknologivalg, kriterievægte og dokumentationskrav. Ellers holder modellen ikke trit med porteføljen.

Kobl den løbende opfølgning til de effektiviseringspotentialer, anskaffelsen var begrundet med. Revisionen af valget skal bygge på udfald og ikke på det oprindelige beslutningsnotat. I Københavns Kommune blev status på udmøntningen af projekter og effektiviseringspotentialer i den fælleskommunale digitaliseringsstrategi taget til efterretning af Økonomiudvalget. Det skete som led i samme indstilling, der udmøntede den fælles beslutningsproces for it-anskaffelser.