Projekter der gjorde en forskel

En større retailvirksomhed stod i en situation, mange vækstvirksomheder genkender. IT-projekter blev startet på mavefornemmelse, kørt af dem der råbte højest, og afsluttet når budgettet var brugt. Der var ingen projektmodel, ingen arkitekturfunktion og ingen stillingtagen til AI, trods stigende brug af AI-værktøjer i organisationen.

Kort sagt: teknologien var løbet fra styringen.

Vi startede med det mest akutte. En Stage Gate-model med klare faser for et standard IT-projekt, fra idé til afslutning. Hver fase med konkrete krav til, hvad der skal beskrives og godkendes, før projektet rykker videre. Ikke et teoretisk dokument, men en operationel ramme, som projektledere faktisk kan bruge.

Dernæst etablerede vi en Enterprise Architecture funktion med et Architecture Board, guidelines og guardrails. EA blev koblet direkte ind i projektmodellens faser, så arkitekturvurderinger sker løbende i projektet, ikke som et stempel til sidst.

Til sidst udarbejdede vi et udkast til en AI-strategi, der binder ind i EA-modellen. Ikke en isoleret AI-politik, men en integreret del af den arkitektur og governance, virksomheden nu havde fået på plads.

En offentlig virksomhed havde købt Microsoft 365-licenser og erklæret sig klar til skyen. Problemet var, at ingen reelt vidste, hvad de havde købt. Licenserne var aktiveret, produkterne var tilgængelige, men hverken brugere, driftsorganisation eller sikkerhedsfunktion var forberedt på omfanget af det, der var blevet rullet ud.

M365 er ikke ét produkt. Det er et økosystem af værktøjer, der griber ind i alt fra filhåndtering og kommunikation til identitetsstyring og sikkerhedspolitikker. Uden en plan bliver det hurtigt et uoverskueligt landskab, hvor folk bruger det, de kan finde, og ignorerer resten.

Vi gennemgik samtlige implementerede produkter sammen med Microsoft og identificerede de vigtigste elementer fra hver teknologi og deres betydning for organisationen. Hvert element blev vurderet sammen med de ansvarlige fra drift, sikkerhed og forretningen, så prioriteringen afspejlede den faktiske virkelighed, ikke leverandørens standardanbefaling.

Udgangspunktet var en retailvirksomhed med et IT-landskab, der var vokset organisk over mange år. Systemer var købt og implementeret efterhånden som behovet opstod, uden en overordnet plan og uden nogen, der holdt styr på, hvad der fandtes, hvad det gjorde, og hvad det talte med. Governance eksisterede stort set ikke. Beslutninger om nye løsninger blev truffet lokalt, og ingen havde det samlede overblik.

Første skridt var at skabe netop det overblik. Vi kortlagde systemlandskabet fra bunden. Det var et stort og tidskrævende arbejde, fordi der ikke fandtes dokumentation at tage udgangspunkt i. Hver applikation, integration og dataflow blev identificeret, beskrevet og placeret i en samlet arkitekturmodel. Undervejs dukkede der systemer op, ingen vidste eksisterede, og afhængigheder, der ændrede billedet af, hvad der egentlig var muligt at ændre.

På det fundament etablerede vi en Enterprise Architecture-funktion med den styring og de strukturer, der skulle til for at den kunne fungere i praksis. Et EA Governance Board med mandat til at træffe bindende beslutninger om arkitekturretning. Et Architect Forum som det faglige forum, hvor løsningsarkitekter og domæneeksperter arbejder med konkrete problemstillinger. Guidelines og guardrails, der sætter rammerne for, hvad man kan vælge, og hvad man ikke kan. Et Patterns Library med godkendte løsningsmønstre, så teams ikke opfinder de samme løsninger igen og igen.

EA-funktionen blev ikke sat ved siden af projektorganisationen. Den blev integreret direkte i projektmodellen og den samlede eksekverings- og styringsmodel. Arkitekturvurderinger indgår nu som en fast del af projekters livscyklus, ikke som et stempel, der indhentes til sidst, men som en løbende dialog fra idé til leverance.

AI governance blev en naturlig del af EA-modellen frem for en separat øvelse. Vi etablerede et overblik over virksomhedens AI-systemer med klassifikation og risikovurdering efter EU AI Act-kategorier. Overblikket er opbygget, så det løbende kan opdateres og bruges som grundlag for compliance-dokumentation, efterhånden som lovkravene skærpes.

En reguleret virksomhed havde det problem, mange dataintensive organisationer genkender, men sjældent taler højt om. Data fandtes i overflod, spredt over en myriade af kilder, systemer og formater. Men ingen kunne med sikkerhed sige, hvor et givent tal kom fra, hvordan det var blevet transformeret undervejs, eller om det matchede tallet i rapporten ved siden af.

Der var ingen data governance, ingen lineage og ingen konsolideret master data-struktur. For en reguleret virksomhed er det ikke bare et praktisk problem. Det er en risiko.

Vi styrede et dataplatformsprojekt, der etablerede en struktureret arkitektur fra bunden. En tiered datastruktur med data storage, data lakes og data factory, designet til at håndtere data fra indsamling til forbrug i et kontrolleret flow. Parallelt blev der implementeret data governance, så ejerskab, kvalitet og lineage blev en del af strukturen, ikke noget man håbede på.