7.1 Datastrategi og datastyring

Overblik og motivation

Datastrategi er jeres bevidste plan for at behandle data som et aktiv: hvordan de produceres, beskrives, ejes, beskyttes, deles og forbruges for at skabe værdi. Datastyring er det operativsystem, der gør strategien virkelig: de roller, politikker, standarder og kontroller, der holder data troværdige og compliant over tid. I små teams er disse anliggender ofte implicitte, båret i hovedet på nogle få ingeniører. I skalaen af store udviklerorganisationer, virksomheder og offentlige agenturer falder den uformalitet fra hinanden. Hundredvis af teams producerer tusinder af tabeller. Dusinvis af systemer hævder at holde den “rigtige” kundepost. Og ingen kan sige med sikkerhed, hvilket tal der er korrekt i et bestyrelsesdæk eller en offentlig rapport.

For store teams er omkostningen ved dårlig datastyring ikke abstrakt. Tilsynsmyndigheder forventer påviselig afstamning og kontrol over personlige, finansielle og sundhedsdata under regimer som GDPR (EU’s General Data Protection Regulation), HIPAA (den amerikanske Health Insurance Portability and Accountability Act) og sektorspecifikke regler. Virksomheder står over for direkte økonomisk eksponering fra fejlrapporterede målinger, dumpede revisioner og duplikerede dataplatforme. Offentlige agenturer bærer ekstra forpligtelser omkring journalopbevaring, aktindsigt, offentlig ansvarlighed og lige behandling af borgere. I hver af disse sammenhænge er data, I ikke kan stole på, værre end ingen data, fordi de driver selvsikre, men forkerte beslutninger.

Den idé, der driver fremskridt i skala, er enkel: behandl data som et produkt. I stedet for at data er et udstødningsbiprodukt af applikationer har hvert vigtigt datasæt en ejer, en dokumenteret grænseflade, kvalitetsgarantier og forbrugere, der behandles som kunder. Dette kapitel dækker den produkttankegang sammen med de klassiske styringsdiscipliner: ansvarlighed for data, katalogisering, stamdatastyring og kvalitet. Det dækker også de organisatoriske valg, der afgør, hvilken model der passer til jeres team: en data mesh (decentraliserede, domæneejede data udgivet som produkter), et data lakehouse (styring i datavarehusstil lagt oven på en fleksibel data lake) og et datavarehus (et styret centralt lager af modellerede, forespørgselsklare data).

Se også: kapitel 4.5 (privatliv og databeskyttelse), kapitel 7.2 (datateknik) og kapitel 4.6 (compliance og styring).

Grundprincipper

Data er et varigt aktiv med ejere, ikke et engangsbiprodukt af applikationer.
Hvert vigtigt datasæt har en navngiven ansvarlig ejer og en dokumenteret kontrakt.
Styring muliggør troværdig brug; det er ikke en bureaukratisk port, der kun siger nej.
Der bør være én autoritativ kilde for hver kritisk forretningsentitet.
Kvalitet, privatliv og afstamning designes ind, ikke inspiceres ind bagefter.
Forbrugere af data er kunder, hvis behov former produktet.
Politikker kodes og håndhæves automatisk, hvor det er muligt, ikke overladt til god vilje.
Føderet ejerskab skalerer bedre end et enkelt centralt team, efterhånden som organisationen vokser.

Anbefalinger

Behandl data som et produkt

Giv hvert væsentligt datasæt en produktejer, der er ansvarlig for dets egnethed til brug. Et dataprodukt har et navn, et dokumenteret skema, en beskrivelse af dets betydning og proveniens, en defineret opdateringskadence og offentliggjorte kvalitetsforventninger. Jeres forbrugere bør kunne finde det, forstå det og afhænge af det uden at stille det producerende team et eneste spørgsmål. Anvend den samme disciplin, I anvender på software-API’er: versionering, udfasningsmeddelelser, changelogs og bagudkompatibilitet.

Etablér datakontrakter og SLA’er

En datakontrakt er en eksplicit, maskintjekbar aftale mellem en producent og dens forbrugere. Den dækker skema, semantik, friskhed, volumen og tilladte ændringer. Håndhæv kontrakter i pipelinen, så en brydende opstrømsændring fejler hurtigt ved kilden i stedet for stille at korrumpere nedstrøms rapporter uger senere. Par kontrakter med serviceniveauaftaler og -mål. For eksempel “kundedimensionen opdateret inden kl. 06:00 dagligt, 99,5 % af dagene, med færre end 0,1 % nul-forretningsnøgler.” Offentliggør disse, og alarmér ved brud.

Byg ansvarlighed for data og en styringsmodel

Hold ansvarlighed adskilt fra udførelse. Dataejere (ofte forretningsledere) er ansvarlige for et domæne. Dataansvarlige (emneeksperter) vedligeholder definitioner, løser kvalitetsproblemer og godkender adgang. Et let datastyringsudvalg sætter tværgående standarder og afgør uenigheder. Hold modellen føderet: et centralt understøttende team leverer værktøj, standarder og coaching, mens domæneteams ejer deres data. Det undgår både flaskehalsen ved fuld centralisering og kaosset ved ingen styring overhovedet.

Invester i et datakatalog og afstamning

Et søgbart katalog er hoveddøren til jeres dataejendom. Det bør holde forretningsordlister, tekniske skemaer, ejerskab, følsomhedsklassifikationer, kvalitetsscorer og afstamning fra ende til anden fra kildesystem gennem transformationer til dashboards. Automatisér høstning af metadata frem for at stole på manuel dokumentation, som hurtigt rådner. Afstamning er essentiel til konsekvensanalyse, hændelsesrespons, revision og regulatoriske anmodninger såsom indsigt og sletning for registrerede.

Stamdatastyring og en enkelt kilde til sandheden

For kerneentiteter (kunde, borger, produkt, leverandør, medarbejder) brug stamdatastyring til at afstemme dubletter og modstridende poster til én gylden post. Vælg en arkitektur (register, konsolidering, sameksistens eller centraliseret) ud fra hvor autoritativt knudepunktet skal være. Definér matchnings- og overlevelsesregler eksplicit, og gør dem reviderbare. En enkelt kilde til sandheden forhindrer den klassiske fejl, hvor økonomi, salg og drift hver rapporterer forskellig omsætning.

Mål datakvalitet på tværs af dimensioner

Styr kvalitet langs navngivne dimensioner: nøjagtighed, fuldstændighed, konsistens, rettidighed, gyldighed og unikhed. Instrumentér pipelines med automatiserede tests og kontinuerlig dataobserverbarhed (friskheds-, volumen-, skemadrift- og fordelingstjek), så I fanger anomalier, før forbrugere påvirkes. Behandl datahændelser som produktionsnedbrud, med detektion, triage, rodårsagsanalyse og postmortems.

Klassificér, beskyt og kontrollér adgang

Klassificér data efter følsomhed, og anvend kontroller i forhold hertil: kryptering, maskering, tokenisering, sikkerhed på række- og kolonneniveau og adgang efter mindste privilegium gennemgået regelmæssigt. Hold en opbevarings- og sletteplan, der tilfredsstiller både minimeringskrav og journalopbevaringslov. I offentlige sammenhænge så afstem åbenhedsforpligtelser med privatlivsbeskyttelse bevidst, frem for sag for sag.

Afvejninger: fordele og ulemper

Tilgang	Fordele	Ulemper	Bedst egnet
Centralt styringsteam	Ensartede standarder, klar ansvarlighed	Flaskehals, afkoblet fra domæner	Små eller stærkt regulerede organisationer
Føderet styring	Skalerer, domæneekspertise, ejerskab	Kræver stærkt værktøj og kultur	Store virksomheder med mange domæner
Datavarehus	Modent, styret, ydedygtigt SQL	Stift, dyrt for ustrukturerede data	Stabile BI-tunge arbejdsbyrder
Data lakehouse	Fleksibelt, samlet, håndterer alle datatyper	Yngre værktøj, styringsindsats	Blandet analyse og ML
Data mesh	Domæneejerskab, skalerer organisatorisk	Høj modenhedsbarre, koordinationsomkostning	Meget store, decentraliserede organisationer

Styring afvejer altid hastighed mod tillid. Let styring lader teams bevæge sig hurtigt, indtil en revision, et brud eller en pinlig fejlrapportering tvinger en dyr afregning. Tung styring beskytter tilliden, men kan kvæle eksperimentering og skubbe teams mod skyggesystemer. Det varige svar er at kode styring som automatiseret, selvbetjent rækværk, så den compliant sti også er den lette sti. Arkitektonisk favoriserer datavarehuse styret enkelhed, mesh favoriserer organisatorisk skala, og lakehouses deler forskellen. Det rette valg følger jeres organisations struktur langt mere end noget teknisk benchmark.

Spørgsmål til drøftelse med dit team

Hvilken dataarkitektur (varehus, lakehouse eller mesh) passer faktisk til, hvordan jeres organisation er struktureret, og er I ærlige om den modenhedsbarre, hver kræver? Afvejningstabellen gør pointen, at dette valg følger organisationsstruktur, ikke benchmarks: et varehus belønner stabile BI-tunge arbejdsbyrder, et lakehouse håndterer blandet analyse og ML, og et mesh skalerer på tværs af mange autonome domæner, men kræver høj modenhed og stærkt værktøj. For en stor virksomhed eller et offentligt agentur med dusinvis af domæner producerer et spring til et mesh, før I har selvbetjeningsplatforme og en styringskultur, kaos klædt ud som decentralisering. Tag konkrete signaler med: hvor mange domæner producerer data, om centrale teams allerede er en flaskehals, og om domæneteams har færdighederne og incitamentet til at eje produkter. Hvis I mangler føderet værktøj i dag, kan det ærlige svar være et styret varehus eller lakehouse nu og et mesh senere. Vælg den model, jeres folk faktisk kan drive, og invester så i den modenhed, den næste model kræver.
Kan I opfylde en sletteanmodning fra ende til anden i dag, og beviser jeres afstamning, hvor hver kopi af en personpost gik hen? Under GDPR og lignende regimer er en sletteanmodning eller anmodning om indsigt fra en registreret en juridisk forpligtelse med hårde frister, og at kopiere data vidt og bredt uden afstamning gør det umuligt at opfylde. Store teams fordeler rutinemæssigt data ud i marts, udtræk, caches og regneark, så det reelle spørgsmål er, om I kan spore og nå hver kopi, ikke om I kan slette originalen. Tag dokumentation med: vælg én rigtig kunde eller borger og forsøg at opregne hvert sted, vedkommendes data bor. Hvis I ikke kan, er det hul både en compliance-risiko og et sprængradiusproblem ved brud. Svaret bør drive investering i automatiseret afstamning og strammere kontroller af ukontrolleret kopiering, fordi den compliant sti skal bygges, før anmodningen ankommer.
Er jeres styring den lette sti eller en port, folk går udenom, og hvor er de skyggesystemer, der beviser det? Kapitlets varige svar er at kode styring som automatiseret, selvbetjent rækværk, så den compliant sti også er den hurtigste, fordi tung manuel styring skubber teams mod skyggeregneark og ustyrede kopier. For virksomheder og agenturer er skyggesystemer, hvor brud, forkerte tal og dumpede revisioner fødes, netop fordi ingen holder øje med dem. Tag en konkret opgørelse med: hvilke teams holder deres egne kopier, hvilke rapporter går uden om kataloget, og hvor folk siger, at den officielle proces er for langsom. Hvert skyggesystem er et signal om, at den styrede sti koster mere end omvejen. Ret gnidningen frem for at udstede endnu en politik, så det er reelt lettere at bruge certificerede data og kontrakter end at gå udenom dem.
Hvilken kritisk forretningsentitet har mest brug for en enkelt autoritativ kilde, og hvem er ved navns nævnelse ansvarlig for dens gyldne post i dag? Stamdatastyring findes for at forhindre økonomi, salg og drift i hver at rapportere en forskellig kunde eller en forskellig omsætningsfigur, og i skala forvandler fraværet af én autoritativ kilde hvert tværdomænetal til et skænderi. De konkurrerende hensyn er, hvor autoritativt knudepunktet skal være (register, konsolidering, sameksistens eller fuldt centraliseret), og hvor megen matchnings- og overlevelseslogik I er villige til at bygge og revidere, da et tungere knudepunkt koster mere, men løser mere konflikt. Tag de entiteter, der optræder i flest rapporter (kunde, borger, produkt, leverandør, medarbejder), en optælling af hvor mange systemer, der hævder at holde den rigtige post for hver, og de matchningsregler, I bruger i dag, hvis nogen, med. For en bank eller et nationalt agentur så navngiv den ansvarlige ejer og overlevelsesreglerne eksplicit, for en tilsynsmyndighed, der sporer et tal fra offentlig rapport tilbage til kilden, vil spørge, hvem der besluttede, hvilken dublet der vandt, og “ingen” er ikke et svar, der overlever en revision.
Hvordan ved I, at et kritisk datasæt er egnet til brug, før en forbruger opdager, at det er ødelagt? I umodne ejendomme findes kvalitet af analytikeren, hvis dashboard går i stykker, eller direktøren, hvis bestyrelsestal er forkert, hvilket er det dyrest mulige detektionspunkt. Spændingen er mellem omkostningen ved at instrumentere kvalitet (tests, friskheds- og volumentjek, fordelings- og skemadriftovervågning på tværs af navngivne dimensioner som nøjagtighed, fuldstændighed og gyldighed) og omkostningen ved de hændelser, I forebygger, og teams underinvesterer rutinemæssigt, fordi fejlene forbliver usynlige, til de bliver katastrofale. Tag de tre seneste datahændelser, hvordan de blev opdaget, og hvor længe de kørte, før nogen lagde mærke til dem, plus de kvalitets-SLA’er, I faktisk offentliggør og alarmerer på i dag, med. For virksomheds- og offentlig rapportering så bind hvert kritisk dataprodukt til eksplicitte kvalitetstærskler og behandl et brud som et produktionsnedbrud med triage og en postmortem, fordi et forkert tal i en regulatorisk indberetning eller en offentlig statistik bærer juridisk og omdømmemæssig omkostning, der dværger overvågningsregningen.
Er jeres styring reelt føderet med domæneejerskab, eller et centralt team holdt ansvarligt for data, det ikke forstår? Kapitlet argumenterer for, at føderet ejerskab med central understøttelse skalerer, hvor ren centralisering flaskehalser, og ren decentralisering falder ned i kaos, og alligevel hævder mange organisationer føderation, mens et lille centralt team forbliver nominelt ansvarligt for tusinder af tabeller, det ikke har domæneviden om. Det modstridende træk er reelt: centrale teams giver ensartethed og én at holde ansvarlig, mens domæneejerskab giver ekspertise og ansvarlighed, men kræver at forretningsejere accepterer et ansvar, de måske ikke vil have. Tag et ærligt kort over, hvem der er ansvarlig versus hvem der faktisk vedligeholder definitioner og løser kvalitetsproblemer for jeres øverste domæner, og om dataansvarlige har den autoritet og den tid, rollen kræver. I en stor virksomhed eller et stort agentur så tjek, at ejerskabet sidder hos folk med både domæneviden og mandat til at sige nej, for styring tildelt et centralt team uden autoritet producerer politikker, ingen følger, og et udvalg, der ikke afgør noget.

Sektorperspektiv

Startup. Hastighed og overlevelse slår proces. Navngiv én ejer for hvert kernedatasæt og gør ét lager til den enkelte kilde til sandheden for entiteter som “aktiv kunde”, og spring kataloger, udvalg og mesh helt over. En kontrakt på én side for jeres håndfuld kritiske tabeller (skema, opdateringstidspunkt, en enkelt kvalitetsforventning) ender “hvis tal er rigtigt”-diskussionen på en eftermiddag. Støt jer til den styring, der allerede er bygget ind i jeres varehus, frem for at bemande en funktion, I ikke har råd til.

Lille virksomhed. Uden en dedikeret dataspecialist og med et stramt budget så behandl styring som datahygiejne frem for et platformsprojekt: vid hvilke personoplysninger I holder, hvor de bor, og hvem der må røre dem. Foretræk et administreret varehus eller BI-værktøj, der leverer afstamning, adgangskontrol og opbevaring ud af boksen, så I køber styring indlejret i værktøjer, I allerede kører, i stedet for at bygge den. Forbehold enhver skræddersyet pipeline til det ene datasæt, der reelt driver forretningen.

Stor virksomhed. I skala på tværs af mange teams er arbejdet føderet ejerskab med central understøttelse: et fælles katalog med automatiseret afstamning, håndhævede datakontrakter, stamdata for kerneentiteter og kvalitets-SLA’er målt mod baselines. Kod styring som selvbetjent rækværk, så den compliant sti også er den hurtige sti, og styr data som en portefølje af produkter med navngivne ejere. Sådan kan revisorer spore ethvert tal fra rapport tilbage til kilde, og grupper holder op med at genopfinde de samme pipelines og definitioner.

Offentlig sektor. Indkøbsregler, åbenhed og offentlig ansvarlighed former hvert valg. Behandl offentliggjorte indikatorer som dataprodukter med dokumenteret metodologi, versionerede udgivelser og kvalitetsporte, og afstem aktindsigts- og åbne data-forpligtelser med privatliv og minimering bevidst frem for sag for sag. Kræv dataportabilitet og oplysning om afstamning i leverandørkontrakter for at undgå indlåsning, hold en forsvarlig opbevarings- og sletteplan, og lad et ansvarlighedsudvalg for data holde fælles definitioner, så “husstand” eller “arbejdsløshed” betyder det samme på tværs af hver afdeling.

Eksempler

Startup. Et SaaS-firma på seed-stadiet fandt ud af, at dets faktureringsregneark, dets salgsværktøj og dets produktdatabase hver rapporterede et forskelligt kundeantal, og ingen kunne sige, hvilket var rigtigt til investoropdateringen. Teamet på fire personer navngav én ejer for hvert kernedatasæt, gjorde varehuset til den enkelte kilde for “aktiv kunde” og skrev en kontrakt på én side, der beskrev skemaet og det daglige opdateringstidspunkt. Det tog en eftermiddag, og det afsluttede den ugentlige diskussion om, hvis tal man skulle stole på.

Stor virksomhed. En multinational bank konsoliderede dusinvis af modstridende kundeposter på tværs af sine detail-, udlåns- og formueafdelinger i et stamdatastyringsknudepunkt med overlevelsesregler og en gylden post. Hvert domæne udgav dataprodukter med kontrakter og friskheds-SLA’er, synlige i et centralt katalog med afstamning. Tiden til regulatorisk rapportering faldt kraftigt, fordi revisorer nu kunne spore ethvert tal fra rapport til kilde. Banken pensionerede også flere redundante rapporteringsplatforme.

Offentlig sektor. Et nationalt statistikagentur behandler sine offentliggjorte indikatorer som dataprodukter med dokumenteret metodologi, versionerede udgivelser og strenge kvalitetsporte. Et ansvarlighedsudvalg for data afstemmer definitioner på tværs af afdelinger, så “arbejdsløshed” eller “husstand” betyder det samme overalt. Klassifikation og kontrolleret adgang beskytter respondenters fortrolighed, mens et offentligt katalog understøtter åbenhed og aktindsigtsforpligtelser.

Business case: motivation, ROI og TCO

Motivationen for datastyring er risikoreduktion og værdiskabelse i nogenlunde lige dele. På risikosiden omfatter undgåede omkostninger regulatoriske bøder, brudansvar, dumpede revisioner og omdømmeskaden ved at offentliggøre forkerte tal. På værdisiden fremskynder troværdige, findbare data hver nedstrøms analyse- og maskinlæringsindsats, reducerer duplikerede pipelines og forkorter tiden fra spørgsmål til svar.

Adoptionsomkostningen er reel: kataloge- og kvalitetsværktøj, tid fra ansvarlige for data og ejere og den organisatoriske forandring, der skal til for at få ejerskab til at holde. Vej de totale ejeromkostninger (TCO) mod omkostningen ved ikke at adoptere, som regel er større, blot skjult. Uden måling viser den sig som analytikere, der bruger det meste af deres tid på at finde og rense data, teams der genopbygger de samme pipelines, og ledere der træffer beslutninger på tal, ingen kan forsvare. Før sagen over for ledelsen på deres sprog: styring forvandler data fra et ansvar med ubegrænset nedside til et aktiv med akkumulerende afkast, og den er en forudsætning for troværdig AI. Begynd, hvor smerten og den regulatoriske eksponering er højest, så I hurtigt kan vise værdi.

Anti-mønstre og faldgruber

Styring ved udvalg uden automatisering, der producerer politikker, ingen følger.
At katalogisere alt på én gang i stedet for de datasæt, der faktisk betyder noget.
Stamdataprojekter, der koger havet og aldrig leverer en gylden post.
At behandle datakvalitet som en engangsoprydning frem for kontinuerlig observerbarhed.
Ejerskab tildelt et centralt team, der mangler domæneviden eller autoritet.
Kontrakter dokumenteret i wikis, men ikke håndhævet i pipelines.
At kopiere data vidt og bredt uden afstamning, hvilket gør sletteanmodninger umulige at opfylde.
At købe et værktøj og kalde det en strategi; værktøj uden en driftsmodel fejler.

Modenhedsmodel

Opstart: Data er udokumenterede og uejede, håndteret ad hoc og reaktivt. Definitioner er i konflikt på tværs af teams. Kvalitet opdages af forbrugere, når rapporter går i stykker. Intet katalog eller ingen afstamning findes.
Udvikling: Grundlæggende praksis dukker op, men er inkonsistent på tværs af teams. Nogle datasæt har ejere og dokumentation, og et delvist katalog findes. Kvalitetstjek er manuelle og reaktive. En styringspolitik er skrevet, men svagt og ujævnt håndhævet.
Standardisering: Ejerskab, kontrakter og SLA’er er dokumenteret og håndhævet i hele organisationen. Kritiske dataprodukter har navngivne ejere; et katalog med automatiseret afstamning dækker nøgledomæner; stamdata findes for kerneentiteter; styring er føderet med central understøttelse og anvendt ensartet frem for team for team.
Styring: Ejendommen måles og styres mod baselines. Kvalitetsdimensioner (nøjagtighed, fuldstændighed, rettidighed, gyldighed, unikhed) følges mod offentliggjorte SLA-mål; kontraktbrudsrater, afstamnings- og katalogdækning, friskhed og tid til at opfylde en sletteanmodning rapporteres på dashboards; observerbarhed alarmerer på skemadrift og volumenanomalier; hændelser får triage, rodårsagsanalyse og postmortems; adgangs- og go/no-go-beslutninger hviler på målinger mod baselines, ikke mening.
Orkestrering: Styring forbedres løbende og er integreret på tværs af organisationen. Data-som-produkt er normen på tværs af domæner; kontrakter håndhæves automatisk, og brydende ændringer fejler hurtigt; selvbetjent rækværk koder politik; kvalitet og afstamning fodrer proaktiv risikostyring; definitioner er betroede i hele virksomheden og understøtter reguleret rapportering og AI. Organisationen genbalancerer rutinemæssigt ejerskab, pensionerer redundante platforme og tilpasser styring, efterhånden som forretningen og reguleringen skifter.

Idéer til drøftelse

Hvilken af jeres forretningsentiteter har mest akut brug for en enkelt kilde til sandheden, og hvorfor er den fragmenteret i dag?
Hvor ville håndhævede datakontrakter have forebygget en nylig hændelse?
Er jeres organisation struktureret til føderet ejerskab, eller ville centralisering passe bedre lige nu?
Hvordan afstemmer I offentlige åbenhedsforpligtelser med privatliv og minimering?
Hvilken procentdel af jeres analytikeres tid går med at finde og rense data, og hvad ville det være værd at halvere den?
Hvem er ved navns nævnelse ansvarlig for jeres vigtigste datasæt, og ved de det?

Vigtigste pointer

Behandl data som et produkt med ejere, kontrakter og SLA’er, ikke som applikationsudstødning.
Føderet styring med central understøttelse skalerer bedre end ren centralisering.
Et katalog med automatiseret afstamning er hoveddøren til en troværdig dataejendom.
Etablér en enkelt kilde til sandheden for kerneentiteter gennem stamdatastyring.
Styr kvalitet kontinuerligt på tværs af navngivne dimensioner med observerbarhed og hændelsesrespons.
Kod styring som automatiseret rækværk, så den compliant sti er den lette sti.
Vælg varehus, lakehouse eller mesh, så det passer til jeres organisation, ikke hypen.

Referencer og videre læsning

DAMA International, “DAMA-DMBOK: Data Management Body of Knowledge.”
Zhamak Dehghani, “Data Mesh: Delivering Data-Driven Value at Scale.”
Ralph Kimball and Margy Ross, “The Data Warehouse Toolkit.”
Piethein Strengholt, “Data Management at Scale.”
David Loshin, “Master Data Management.”
Chad Sanderson and colleagues, writings on data contracts.
ISO/IEC 38505, “Governance of data.”
ISO 8000, “Data quality” standard series.