Gå til hovedindholdet
FromNine
Menu

AI & data

Data som AI og beslutninger kan stole på.

Vi bygger dataplatforme hvor hvert datasæt har en ejer, en kontrakt og en kendt kvalitet. Så trækker analyse, drift og AI på de samme tal, som alle stoler på.

For koncerner, forsyningsselskaber og myndigheder der har brug for ét pålideligt billede af data fordelt på selskaber, lande og ældre systemer.

Tal med os om dit projektLæs om adgang til viden
Data & analyse: lagene i løsningenFire lag oven på hinanden. Fra øverst til nederst: analyse og AI der bruger data, dataprodukter med ejere og kontrakter, lakehouse-lagene der renser og ensretter, og governance på tværs af det hele.01Analyse og AI02Dataprodukter og kontrakter03Lakehouse-lag04Governance og sporbarhed
  1. 01Dataprodukter med navngivne ejere, kontrakter og kvalitetskontrol
  2. 02Governance der håndhæver formålsbegrænsning og opbevaring, ikke kun et katalog
  3. 03Ét sæt KPI-definitioner som både forretning og it skriver under på

01 Problemer

Velkendte dataproblemer

De fleste AI-projekter der skuffer, viser sig at være dataprojekter i forklædning.

  1. 01

    Tre rapporter, tre forskellige tal

    Økonomi, drift og direktion beregner hver især omsætning eller sagsmængde på deres egen måde. Møderne starter med afstemning i stedet for beslutninger.

  2. 02

    Ingen ejer dataene, så ingen retter dem

    Fejl bliver fundet længere nede i kæden, rettet i et regneark og kommer igen næste måned.

  3. 03

    AI-teamet bruger det meste af tiden på at finde data

    Hver use case starter med uger af adgangsanmodninger, udtræk og oprensning, som det næste team gentager.

  4. 04

    Arkiverne kan ikke bruges til AI

    Scannede dokumenter med dårlig OCR, dubletter og ingen metadata. Retrieval over dem giver støj.

02 Leverancer

Det leverer vi

  1. 01 Datafundament til AI og analyse

    Lakehouse-arkitekturer med modellering i lag, fra rå data over ensrettede data til data klar til brug, og dataprodukter der oplyser hvad de indeholder, hvor friske de er, og hvem der står for dem.

    Det gør vi

    • Platformsarkitektur og valg af lagringsformat
    • Konventioner for modellering i lag
    • Design af dataprodukter med kontrakter
    • Indlæsning i batch og med change data capture

    Det får du

    • Lakehouse-platform defineret i kode
    • De første dataprodukter i drift
    • Skabelon for datakontrakter og proces for gennemgang

  2. 02 Kvalitet, sporbarhed og stamdata

    Automatisk kvalitetskontrol i hvert lag, sporbarhed fra kilde til rapport, og stam- og referencedata for de enheder der betyder noget: borgere, kunder, produkter og anlæg.

    Det gør vi

    • Kvalitetsregler med tærskler og alarmer
    • Sporbarhed ned på kolonneniveau
    • Regler for matchning og prioritering af stamdata
    • Styring af referencedata

    Det får du

    • Kvalitetsdashboard pr. dataprodukt
    • Sporbarhed du kan forespørge på
    • Autoritative poster for de vigtigste enheder

  3. 03 Governance der bliver håndhævet

    Et katalog, en klassificering og adgangspolitikker som platformen anvender automatisk. GDPR’s formålsbegrænsning og opbevaringsregler er indbygget, og deling af data følger forordningen om datastyring (Data Governance Act), hvor den gælder.

    Det gør vi

    • Klassificeringsmodel og mærkning
    • Attributbaserede adgangspolitikker
    • Automatisk opbevaring og sletning
    • Aftaler om datadeling og tekniske kontroller

    Det får du

    • Katalog udfyldt fra platformen
    • Adgangspolitikker som kode
    • Opbevaringsplan i drift

  4. 04 Ustruktureret indhold gjort klar til AI

    Bedre OCR-kvalitet, berigelse med metadata, fjernelse af dubletter og oprydning i arkiver, så dokumentbehandling og retrieval starter fra indhold der er værd at finde.

    Det gør vi

    • Oversigt over indhold og stikprøver af kvaliteten
    • Forbedret OCR og udtræk af layout
    • Opdagelse af næsten ens dokumenter
    • Berigelse med metadata og klassificering

    Det får du

    • Renset og beriget indholdslager
    • Rapport om indholdets kvalitet
    • Regler for nyt indhold fremover

  5. 05 Analyse og BI som bliver brugt

    Et semantisk lag med KPI-definitioner aftalt mellem forretning og it, selvbetjening med styring og indlejret analyse i SaaS-produkter og portaler.

    Det gør vi

    • Workshops om KPI-definitioner
    • Semantisk model og lag for nøgletal
    • Rammer for selvbetjening og certificerede datasæt
    • Indlejret analyse i produkter til kunder

    Det får du

    • KPI-ordliste med ejere
    • Certificeret semantisk model
    • Dashboards der erstatter regneark

  6. 06 Streaming til drift

    Change data capture og hændelsesstrømme hvor beslutninger ikke kan vente på natlig indlæsning: lagerbeholdning, sagsstatus, tegn på svindel.

    Det gør vi

    • Krav til forsinkelse pr. use case
    • CDC fra driftsdatabaser
    • Strømbehandling og materialiserede views
    • Design af genafspilning og efterindlæsning

    Det får du

    • Streamingpipelines i drift
    • Driftsvisninger med mål for aktualitet
    • Procedure for genafspilning

03 Arkitektur

En illustrativ referencearkitektur

Data flytter fra driftssystemer og dokumenter gennem indlæsning ind i et lakehouse i lag: rå data som de blev modtaget, derefter ensrettede og kvalitetskontrollerede data, og til sidst dataprodukter med en ejer og en kontrakt. Ingen brugere læser rå data.

Fra dataprodukterne fodrer én rute det semantiske lag og BI. Andre ruter fodrer retrieval og features til AI og data-API’er til andre systemer. Governance ligger under det hele og anvendes af platformen, ikke af et politikdokument.

Eksempel

  1. Kilder og indlæsning

    • Driftssystemer
    • Dokumenter efter OCR og berigelse
    • Batch og change data capture

  2. Lakehouse

    • Råt lag
    • Ensrettet lag
    • Kvalitetskontrol og sporbarhed
    • Stam- og referencedata
    • Dataprodukter med kontrakter

  3. Anvendelse

    • Semantisk lag og BI
    • Retrieval og features til AI
    • Data-API’er og deling

  4. Governance

    • Governance: katalog, klassificering, adgangspolitikker, opbevaring
Fra lakehouse-lag til dataprodukter med ejere

Illustrativ arkitektur, ikke en kundes system.

Læs diagrammet som tekst

Hovedruten går fra driftssystemer gennem indlæsning i batch og med change data capture, et råt lag, et ensrettet lag og dataprodukter til et semantisk lag med styret BI.

Ustrukturerede dokumenter kommer også ind gennem indlæsningen efter OCR og berigelse. Kvalitetskontrol og sporbarhed dækker det rå og det ensrettede lag. Stam- og referencedata fodrer dataprodukterne. Dataprodukterne leverer også til retrieval og features til AI og til data-API’er for deling.

Et governancebånd med katalog, klassificering, adgangspolitikker og opbevaring spænder over hele platformen.

04 Hensyn og begrænsninger

Tekniske hensyn og begrænsninger

  • Ejerskab før værktøjer

    Sådan håndterer vi det

    Hvert dataprodukt får en forretningsejer der afgør hvad det betyder, og en teknisk ejer der holder det kørende. Vi hjælper med at definere begge roller og kontrakten mellem dem der leverer data, og dem der bruger dem.

    Begrænsninger og afhængigheder

    En platform kan ikke skabe ejerskab. Hvis organisationen ikke udpeger ejere, kommer kvalitetsproblemerne igen, uanset værktøjerne.

  • Formålsbegrænsning i praksis

    Sådan håndterer vi det

    Personoplysninger mærkes med de formål de må bruges til, og adgangspolitikker og opbevaring følger mærkerne automatisk.

    Begrænsninger og afhængigheder

    Hvilke formål der er lovlige, afgøres af jeres databeskyttelsesrådgiver og jurister. Vi implementerer beslutningen, vi træffer den ikke.

  • Data til AI har sit eget kvalitetskrav

    Sådan håndterer vi det

    Til AI-use cases måler vi det som retrieval og modeller har brug for: dækning, aktualitet, dubletter og kvaliteten af tekstudtrækket.

    Begrænsninger og afhængigheder

    Nogle arkiver er ikke værd at rette. En vurdering ud fra stikprøver viser det, og nogle gange er det rigtige svar at lade dem ude.

05 Sådan arbejder vi

Sådan arbejder vi

Vi bygger platformen omkring de første dataprodukter der betyder noget, ikke omvendt.

  1. 01

    Vælg beslutninger, ikke datasæt

    Start med to eller tre beslutninger eller AI-use cases og de data de kræver, med navngivne ejere.

    ResultatBacklog af dataprodukter med ejere

  2. 02

    Byg fundamentet omkring dem

    Platform, indlæsning, kvalitetskontrol og governance, nok til at levere de produkter ordentligt.

    ResultatDe første dataprodukter i drift

  3. 03

    Voks produkt for produkt

    Hvert nyt produkt genbruger fundamentet, og kataloget og KPI-ordlisten vokser med.

    ResultatProduktplan og mål for anvendelse

06 Menneskelig kontrol

Hvor mennesker har kontrollen

Dataplatforme automatiserer flytning og kontrol af data. Mennesker beslutter betydning, adgang og formål.

  • Ejere godkender definitioner

    Et nøgletal eller et dataprodukt ændrer kun betydning, når forretningsejeren godkender det, og ændringen bliver versioneret.

  • Adgang gives af politikejere

    Dataejere beslutter hvem der må bruge hvilke data til hvilket formål. Platformen håndhæver det og logger hver tildeling.

  • Kvalitetsbrud stopper leverancen

    Når en kontraktkontrol fejler, får brugerne besked, og ejeren beslutter om data skal udgives, holdes tilbage eller rettes.

07 Teknologier

Teknologier vi arbejder med

Platforme
  • Databricks
  • Microsoft Fabric
  • Snowflake
  • Åbent lakehouse på Apache Iceberg eller Delta Lake
Pipelines
  • dbt
  • Apache Spark
  • Kafka og Debezium
  • Cloudnativ orkestrering
Governance
  • Unity Catalog og Purview
  • Datakataloger med åben kildekode
  • Rammeværker for datakvalitet
  • Politikbaseret adgangskontrol
Analyse
  • Power BI
  • Semantiske lag og lag for nøgletal
  • Indlejret analyse
  • SAP-analyse (eksisterende landskaber)

At vi nævner en teknologi, beskriver vores tekniske erfaring. Det betyder ikke et partnerskab med leverandøren eller at leverandøren anbefaler os.

08 Eksempel

Et illustrativt eksempel

Eksempel

Ét sæt nøgletal for en familieejet koncern

01Udgangspunkt
En familieejet koncern har selskaber i Danmark, Sverige og Tyskland. Hvert selskab rapporterer ordreindgang, leveringsevne og lager fra sit eget ERP-system med sine egne definitioner, og ledelsen sammenligner tal der ikke betyder det samme.
02Det ville vi bygge
Ensrettede dataprodukter pr. selskab der fodrer ét semantisk lag med nøgletal defineret på koncernniveau, mens de lokale detaljer bevares.
03Her beslutter mennesker
Økonomiansvarlige i hvert selskab godkender mapningen af deres data. Koncernens ejer af nøgletallene godkender definitioner og ændringer.
04Det ville vi måle
Tiden det tager at lave månedsrapporten, antallet af rettelser ved afstemning og brugen af certificerede dashboards.

09 Brancher

I din branche

  • Sundhed & life science

    Styrede forsknings- og driftsdata med streng formålsbegrænsning, pseudonymisering og logning af adgang.

  • Industri & produktion

    Stamdata om produkter og anlæg, kvalitets- og produktionsdata samlet til planlægning, sporbarhed og AI.

  • Offentlig sektor

    Autoritative kilder, data der genbruges i stedet for at borgeren indberetter dem igen, og rapportering som politikere og revisorer kan spore tilbage til den enkelte post.

Danmark

Data på tværs af selskaber og grænser

Mange danske koncerner har selskaber i Norden og resten af EU og deler data under regler der ligner hinanden, men ikke er ens. GDPR sætter én ramme for personoplysninger, og i Danmark supplerer databeskyttelsesloven GDPR, med Datatilsynet som tilsyn. Dataforordningen giver brugere rettigheder over data fra forbundne produkter og tjenester.

Vi designer dataprodukter hvis kontrakter fastlægger hvor data må behandles, til hvilke formål og hvor længe. Så kan platformen anvende den rigtige regel pr. selskab og land, uden separate kopier af dataene.

Spørgsmål om data og analyse

Har vi brug for et data mesh?

Du har brug for de nyttige dele af det: dataprodukter med ejere og kontrakter. Fuld decentralisering betaler sig i store organisationer med modne domæneteams. Mange organisationer klarer sig bedre med et centralt platformsteam og domæneejerskab af produkterne.

Er vores data klar til AI?

En kort vurdering ud fra stikprøver af de kilder en use case har brug for, giver svaret: dækning, kvalitet, adgangsrettigheder og retsgrundlag. Svaret er som regel »delvist«, med en klar liste over hvad der skal rettes først. Vores teams i AI-engineering bruger den samme vurdering.

Vi har allerede et datawarehouse. Skal vi starte forfra?

Sjældent. Et datawarehouse der leverer rapporter man stoler på, er et aktiv. Som regel udvider vi det med lakehouse-funktioner til ustrukturerede data og store datamængder og migrerer kun, hvor omkostninger eller begrænsninger gør det nødvendigt.

Hvordan håndterer I datadeling med partnere eller andre myndigheder?

Gennem dataprodukter der udstilles via styrede API’er, med aftaler, formålsbegrænsning og logning på plads. Hvor forordningen om datastyring eller dataforordningen gælder, designer vi de tekniske kontroller derefter.

Nævn den beslutning du ikke kan træffe med dagens data

Vi følger det den kræver, tilbage til kilderne og viser hvad et første dataprodukt vil kræve.

Tal med os om dit projektLæs om dokumentbehandling