Sådan opstiller du kriterier til sammenligning af software

Hvorfor et stærkt kriterieapparat redder softwarevalget

IDA har dokumenteret, at virksomheder i gennemsnit kan øge produktiviteten med 28 pct. ved automatisering. Potentialet i industrien svarer til 86 milliarder kroner. Samme undersøgelse viser, at 20 pct. af danske virksomheder har lav digitaliseringsgrad. Især manglende prioritering i ledelsen forhindrer, at potentialet bliver til virkelighed.

Mange ledere spørger derfor: Hvor skal vi begynde? En kriterieliste er et praktisk svar.

DI's chefkonsulent Thomas Skelbo siger: »Mange virksomheder træffer beslutninger om digitalisering på et mangelfuldt grundlag. Man skal selvfølgelig vide, hvad de enkelte teknologier kan. Men det er lige så vigtigt, at man kan forbinde det til sin forretning og se, om der er et potentiale.«

Formålet med DI-forløbet »Kom i gang med digitalisering« er netop »at lære ledere at se, hvor og hvordan digitalisering kan løse problemer og udvikle forretningen«.

Kriterieapparatet skal derfor rumme to typer kriterier samtidig: hvad teknologien kan, og hvilken effekt den skal have i forretningen. Et kriterium, der hverken kan besvares med en teknisk egenskab eller et forretningsmæssigt potentiale, hører ikke hjemme på listen.

Uden nedskrevne kriterier bygger grundlaget typisk på leverandørernes demoer og præsentationer. Skriv kriterierne før mødet med leverandørerne, og brug dem bagefter til at holde hvert enkelt tilbud op imod – og som reference, når beslutningen skal forklares internt.

Digitaliseringspotentiale i danske virksomheder

Fra forretningsproblem til krav: Sæt retningen først

Start med de konkrete udfordringer og arbejdsgange, ikke med produktkategorier. Formuler kæden: Hvilken opgave driller i dag, hvad skal ændres, og hvilke teknologier kan være relevante.

DI's forløb viser virtual og augmented reality, kunstig intelligens, internet of things og 3D-print i praksis, så ledere ser teknologierne i forhold til deres egen forretning i stedet for som løsrevne produkter.

Brug effektbeskrivelsen som filter: Hvordan kan teknologien frigøre tid, styrke kvaliteten og skabe en bedre oplevelse for medarbejdere, kandidater og samarbejdspartnere? De tre vinkler – tid, kvalitet, oplevelse – kan omsættes til kriterier, der besvares med ja/nej eller et tal, så de kan sammenlignes på tværs af leverandører.

Konkretisér hvert effektkriterium med en før-måling fra jeres egen drift. Består arbejdsgangen i dag af et bestemt antal manuelle trin, eller går en opgave gennem flere systemer og personer, så skriv det ned, før I ser på software. Så har I et sammenligningsgrundlag, der ikke afhænger af leverandørens regneark.

Skriv derfor krav i to spor: det funktionelle behov (hvad skal kunne løses) og det forretningsmæssige formål (hvilken effekt skal opnås, og hvordan måler vi den). Begge spor skal med i den vægtede vurdering senere; ellers vinder den løsning, der demonstrerer bedst, frem for den, der løser mest.

Fra forretningsproblem til krav

Skab fælles sprog og digital modenhed i beslutningsgruppen

En hjørnesten i DI's forløb er en digital modenhedsanalyse, der hjælper ledelsen med en ensartet forståelse af digitalisering, så de taler samme sprog. Brug samme øvelse, før kriterierne skrives: Hvor stor en ændring kan organisationen bære, hvilke kompetencer findes i huset, og hvor modne er jeres data og integrationer i dag?

Svaret sætter loftet for, hvilke krav der er realistiske. Et kriterium om fuld automatisering af en arbejdsgang er værdiløst, hvis grunddata ikke er ryddet op. Et kriterium om avanceret integration er værdiløst, hvis ingen internt kan drifte snitfladen efter go-live. Modenhedsanalysen giver argumentet for at skrive sådanne forudsætninger ind som krav eller betingelser.

DI opfordrer virksomheder til at give flere ledere og nøglemedarbejdere mulighed for at deltage i forløbet, så fælles viden kan tages med hjem og bruges praktisk. En virksomhed har ifølge DI sendt fire af sted, fordi de ved, at »digitalisering ikke kan fikses af én person alene. Det kræver samarbejde på tværs.«

Oversæt det til kriteriearbejdet: Nedsæt en gruppe med mandat til både at prioritere forretningsbehov, vurdere teknologi og forpligte sig på drift. Skriv definitioner ind i kriteriedokumentet – fx hvad I mener med »integration«, »support« og »åben standard« – så alle vurderer tilbuddene efter samme målestok.

Digital modenhed før kriterierne skrives

Byg kravspecifikationen op i kategorier

Del kravspecifikationen i tre kategorier: funktionelle krav (hvad brugerne skal kunne udføre), tekniske krav (platform, sikkerhed, ydeevne, drift, backup) og integrationsmæssige krav (snitflader, dataformater, tilslutning til eksisterende systemer). Den tredje kategori undervurderes oftest og bliver samtidig oftest dyr at reparere senere.

Digitaliseringsstyrelsens vejledning »Kravtekster til udbud« viser, hvordan en myndighed håndterer krav til kravspecifikationer, når it-systemer, der skal integreres til Digital Post, udbydes. Vejledningen er særligt rettet mod myndigheder, der udbyder brevdannende systemer, afsendersystemer eller modtagersystemer, og den er inddelt i tre dele. Del 2 indeholder forslag til standardformuleringer, der kan indarbejdes som krav i udbudsmaterialet.

Baggrunden viser, hvorfor integrationskrav skal skrives eksplicit. Digitaliseringsstyrelsen lancerede den 21. marts 2022 en ny løsning til Digital Post, udviklet og driftet af Netcompany. I omlægningen opstod bl.a. behov for tilslutning af integrationer og snitflader til den nye løsning samt omlægning af meddelelsesformat fra DP1 og DP2 til det nye meddelelsesformat MeMo. Et skift i en ekstern løsning bliver altså til nye krav i jeres eget udbudsmateriale.

Genbrug standardformuleringer i stedet for at opfinde egne fra nul. Digitaliseringsstyrelsens forslag er lavet til at kunne indarbejdes som krav og kan tilpasses jeres kontekst. Et eksempel på et konkret teknisk krav: Et modtagersystem i Digital Post deaktiveres automatisk, hvis det i alle tilfælde ikke kan modtage post i syv dage. Sådanne driftsgrænser med tal og tidsfrister er lettere at vurdere i en tilbudsevaluering end »høj tilgængelighed«.

Er anskaffelsen omfattet af udbudsreglerne, findes Konkurrence- og Forbrugerstyrelsens vejledning om udbudsreglerne (version 2, december 2024), som gennemgår reglerne. Læs den, inden kravspecifikationen færdiggøres, så kravformuleringer og udbudsform ikke spænder ben for hinanden.

Tre kravkategorier i kravspecifikationen

Regn totaløkonomi – ikke kun indkøbspris

TCO står for Total Cost of Ownership og angiver de totale omkostninger ved at eje noget. En TCO-beregning for en bil omfatter typisk indkøbspris, afgifter, drivmiddel, vedligeholdelse, reparationer, forventet afskrivning, kapitaludgifter, forsikring og syn. Mønstret kan overføres direkte: Anskaffelsesprisen er én post blandt flere, og de øvrige løber over hele brugsperioden.

For it-udstyr findes et digitalt TCO-værktøj, som på nuværende tidspunkt kan beregne totalomkostninger for computere, skærme, servere og storageudstyr. Brug den type beregninger som skabelon, når I opstiller økonomiske kriterier for en softwareanskaffelse.

I softwarevalget bør kriterielisten mindst omfatte: licens- eller abonnementsudgifter, implementering og konfiguration, integration til eksisterende systemer, drift og hosting, support- og vedligeholdelsesniveau, opdateringer og versionsløft, oplæring af brugere og administratorer samt kapitalomkostninger og forventet afskrivningsperiode. Medtag også udgifterne til at komme ud igen – migrering af data, opsigelsesvilkår og eventuel parallelkørsel i en overgangsperiode.

Pointen er den samme som i TCO-beregninger på firmabiler: Den billigste bil er ikke altid den billigste løsning. En lav anskaffelsespris kan dække over høje driftsudgifter, dyr integration eller en exit, der binder jer i årevis.

Metoden er veletableret: Miljøstyrelsen, KL og Erhvervsstyrelsen har udviklet en TCO-beregner til at beregne en bils samlede omkostninger i hele brugsfasen – dog primært udarbejdet til brug for virksomheder og kun anvendelig med måleenhederne for brændstofforbrug, WLTP og VECTO.

Skriv TCO-kriterierne som poster med enheder og periode, så tilbuddene kan stilles side om side: pris pr. bruger pr. år, pris pr. integration, pris pr. supporttime, og hvad der sker ved udløb af kontrakten. Så bliver totaløkonomien et vurderingskriterium i stedet for et regnestykke, nogen laver bagefter.

TCO-poster for softwareanskaffelse

Kriterier for åbenhed, standarder og afhængighed

Open source-software er software udgivet under en licens. Licensen giver enhver ret til frit og til ethvert formål at bruge, undersøge, ændre og dele softwaren og dens kildekode. Det er definitionen i Digitaliseringsstyrelsens vejledning om brug af open source i den offentlige sektor. Den kan bruges direkte som kriterietekst.

Vejledningen placerer spørgsmålet strategisk: Open source handler ikke om it-afdelingens teknologiske præferencer, men er en strategisk forretningsmodel og nogle udviklingsmetoder, der fremmer offentlige myndigheders medejerskab til deres løsninger og skaber bedre muligheder for at dele, videreudvikle og genbruge digitale løsninger. Offentlige myndigheder undgår så vidt muligt løsninger, der skaber afhængighed af specifikke leverandører og teknologier, og kan hvor det er relevant anvende bæredygtige open source-komponenter.

Kriteriet er ikke »open source ja/nej«. Ifølge vejledningen er valget mellem open source-software og proprietære løsninger ikke et enten-eller, men et spørgsmål om at vælge den løsning, der skaber værdi på baggrund af de udfordringer og behov, der er relevante for den enkelte myndighed. Den formulering kan lige så godt stå øverst i en privat virksomheds kriteriedokument.

Åbne standarder skal være et selvstændigt kriterium. De fremmer konkurrence på softwaremarkedet og medvirker til, at it-systemer uanset valg af software kan udveksle informationer på tværs; vejledningen kalder dem det fælles sprog, systemerne bruger til at tale med og forstå hinanden. Formulér det som et prøvbart spørgsmål: Kan løsningen udveksle data med vores øvrige systemer og med eksterne parter via åbne standarder uden leverandørspecifikke mellemled, og kan vi skifte leverandør uden at skifte dataformat?

Open source er ikke et eksperimentelt hjørne. Linux-distributioner understøtter omkring 70 pct. af internettets 10 mio. mest besøgte hjemmesider. De hostes ofte på webservere som Nginx (33 pct.) eller Apache HTTP Server (24 pct.), og 42 pct. af hjemmesiderne er udviklet med WordPress, mens også Drupal og Umbraco er open source.

Danske offentlige myndigheder bruger LibreOffice til tekstbehandling og QGIS til geodatabehandling, og 82 kommuner bruger OS2kitos. Det giver et sagligt grundlag for at spørge til modenhed, udbredelse og vedligeholdelse af de komponenter, en leverandør bygger på.

Open source-udbredelse (pct.)

Inddrag fagrollerne og test kriterierne i praksis

Kriterier skrives ikke af én faggruppe. Digitaliseringsstyrelsens open source-vejledning henvender sig til it-projektledere, it-jurister og -arkitekter, indkøbere og contract managers samt it-chefer og andre strategiske beslutningstagere hos myndigheder, der skal tage stilling til anskaffelse af software.

Samme rollekreds bør sidde med i en virksomheds kriteriearbejde: forretningen formulerer behovet, arkitektur og it vurderer snitflader og drift, jura og indkøb vurderer licensvilkår, kontrakt og pris, og contract management tager stilling til, hvordan kravene følges op efter underskrift.

Dertil kommer DI's pointe om, at digitalisering kræver samarbejde på tværs og ikke kan fikses af én person alene. Sæt derfor navn på, hvem der ejer hvilke kriterier, og hvem der har vetoret på ufravigelige krav – fx dataudtræk og sikkerhed.

Test kriterierne, før de bruges til at vælge. Vælg de arbejdsgange, der forekommer hyppigst eller gør mest skade, når de fejler, og gennemfør dem som scenarier i leverandørernes demoer eller i en afgrænset pilot. Skriv for hvert scenarie ned, hvilket krav det tester, og om kravet blev opfyldt – så bliver demoerne et dataindsamlingspunkt i stedet for et salgsmøde.

Hent inspiration udefra. DI's forløb »Kom i gang med digitalisering« indeholder inspiration fra andre virksomheder, som har gennemført tilsvarende digitaliseringsforløb, og giver viden, værktøjer og metoder til at få teknologi ind i forretningen. Brug den slags konkrete erfaringscases til at kvalificere jeres egne kriterier, før I låser dem.

Fra kriterier til prioriteret beslutning

Når kravene er skrevet, skal de vægtes og dokumenteres. Vægtningen er prioriteringen: hvilke krav er ufravigelige, hvilke er vigtige, og hvilke er ønskværdige. Uden vægte ender vurderingen i en samlet fornemmelse af, hvem der præsenterede bedst.

Dokumentationen skal mindst indeholde kravet, kategorien, vægten, hvordan det måles eller testes, og hvem der har godkendt det. Den gør beslutningen sporbar, når resultatet skal forklares internt, og gør kriterielisten genbrugelig ved næste anskaffelse og som grundlag for at følge op på, om leverancen lever op til det lovede.

Her møder kriteriearbejdet DI's diagnose. Undersøgelsen viser, at 20 pct. af danske virksomheder har lav digitaliseringsgrad, og at særligt manglende prioritering i ledelsen spænder ben for, at potentialet bliver til virkelighed. En vægtet kriterieliste er ledelsens prioritering gjort eksplicit og efterprøvelig – og giver et konkret svar på lederens spørgsmål: Hvor skal vi begynde?

Fordi den digitale modenhedsanalyse er en hjørnesten i DI's forløb og hjælper ledelsen med en ensartet forståelse af digitalisering, så de taler samme sprog, kan ledelsen efterfølgende tale om de samme kriterier og den samme målestok. Beslutningen flytter sig dermed fra et valg mellem leverandørers præsentationer til en prioriteret beslutning på et dokumenteret grundlag.

Vægtet beslutning på dokumenteret grundlag