Danmarks Statistik er gået i gang med et it-program til 269,1 millioner kroner. Omkring 250 statistikker skal flyttes fra gamle og uensartede systemer til en fælles platform frem mod udgangen af 2032.
Platformens centrale dele bygger på open-source-software som Apache Spark, Iceberg, Polaris, JupyterHub, Keycloak, PostgreSQL, Python og R. Den skal stå i Danmarks Statistiks eget servermiljø, fysisk adskilt fra internettet. Ministeriets begrundelse er blandt andet færre bindinger til enkelte leverandører og større frihed til at udvikle systemet.
DUAL-programmet viser et konkret valg om ejerskab, leverandørafhængighed og viden internt i organisationen. Materialet beskriver ikke en AI-baseret udviklingsmodel. Det siger heller ikke, at AI skal bygge platformen eller skabe den forventede besparelse.
Det samme valg dukkede op i Headway Skills
Jeg stødte selv på valget i Headway Skills, som jeg driver sammen med Peter. Hans første plan bestod af en række betalte tredjepartsløsninger, der skulle forbindes for at nå visionen. Hver del løste noget vigtigt. Samlet ville planen give os flere abonnementer, flere grænser mellem systemer og flere leverandørers beslutninger at indrette os efter.
Jeg sagde nej til hele kæden. Vi kunne bygge en bedre samlet løsning selv og eje den.
Det er en beslutning om retning og om at gå i gang. Arbejdet er fortsat i gang, og jeg har ikke dokumentation for en bestemt besparelse, leveringstid eller kvalitetsforbedring. Erfaringen ligger i selve valget: Vi vurderede, at vi nu havde kapacitet til at forsøge en samlet løsning uden først at bemande hver del med et traditionelt udviklingsteam.
AI hjælper os med at læse og skrive kode, lave tests, finde fejl, dokumentere beslutninger og gennemføre afgrænsede ændringer. Det arbejde fortsætter efter den første version. Derfor indgår drift, sikkerhed, integrationer og senere ændringer i vores valg fra begyndelsen.
Min analyse af de to erfaringer
DUAL-programmet og Headway Skills er to meget forskellige projekter. De mødes i spørgsmålet om, hvem der kan forstå og ændre systemet, når leverandøren, prisen eller arbejdet ændrer sig.
Koblingen til AI er min analyse. Kodeagenter kan nu udføre en del af arbejdet med at forstå, bygge, teste og ændre software. Det kan flytte grænsen mellem et standardsystem og en egen løsning. Jeg mener derfor, at flere ledelser bør regne på valget igen.
Aktstykket om DUAL-programmet viser samtidig, hvad der følger med ejerskab. Programmet kan blive forsinket, hvis organisationen mangler tid og kompetencer til at flytte data eller bygge integrationerne til systemerne udenfor platformen. Danmarks Statistik vil bruge eksterne konsulenter ved behov og kræver, at viden bliver overdraget til medarbejderne.
Kontrollen bliver først brugbar, når mennesker i organisationen kan forstå systemet, bestille ændringer, vurdere leverandørernes arbejde og føre løsningen videre. AI kan måske hjælpe flere medarbejdere med at læse kode, undersøge en integration og dokumentere en arbejdsgang. Om det sker i DUAL, og hvilken effekt det i så fald får, fremgår ikke af materialet.
Aktstykket regner med mindst ti procent lavere ressourceforbrug i produktionen af de statistikker, der flyttes. Programmet har en risikopulje på 36 millioner kroner, og de samlede udgifter til drift, vedligehold og videreudvikling er fortsat store.
Afhængigheden skal med i regnestykket
En egen løsning kan ende med at være afhængig af én AI-tjeneste. Open-weight-modeller og kompatible API’er giver flere valgmuligheder; Kimi K2.5 er et aktuelt eksempel med publicerede modelvægte. Driften kræver stadig regnekraft og mennesker, der kan få den til at fungere. Reelt råderum kræver også, at systemet kan skifte model, leverandør og driftsmiljø.
Hvad ledelsen skal regne på
Tag ét afgrænset stykke arbejde, hvor de nuværende produkter er dyre, dårligt forbundne eller skaber omveje. Beskriv først, hvad systemet skal gøre, og hvilke dele der faktisk er særlige for organisationen.
Saml derefter hele regningen for de realistiske muligheder:
- abonnementer og prisændringer;
- integrationer, dataflytning og migration;
- udvikling, test, sikkerhed og dokumentation;
- drift, fejlretning og senere ændringer;
- den viden, som skal blive hos egne medarbejdere;
- prisen ved at skifte produkt, leverandør, model eller driftsmiljø.
Undersøg til sidst AI’s bidrag på de konkrete opgaver. Kan den hjælpe holdet med at forstå den eksisterende kode, skrive test, dokumentere ændringer eller gennemføre en migration? Hvem kontrollerer resultatet? Hvem kan tage over, når modellen tager fejl? De svar afgør, om den gamle antagelse om egen software stadig holder i netop denne organisation.