Styring designes ind i org'en
Findes også på 28 sprog
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 1 af 6 i kapitlet Datakvalitet og styring, kapitel 5 i kurset Data Architect. Hvert modul står på egne ben. Næste: Hold dårlige data ude
Spørgsmålet, dette modul besvarer: Hvad betyder datastyring for en arkitekt, og hvem gør hvad?
Når folk hører datastyring (data governance), tænker de på møder: udvalg, politikker, standarder, et dokument, der forklarer, hvem der skal gøre hvad med dataene. Alt det kan være en del af et styringsprogram. Som arkitekt er jeg interesseret i et andet spørgsmål: hvor bliver politikken håndhævet?
Hvis politikken siger, at kun økonomi må ændre et felt, hvad håndhæver det så? Hvis den siger, at ERP’et ejer kundens juridiske post, hvad forhindrer så nogen i Salesforce i at ændre den? Hvis den siger, at teamene kun ser en modtagers adresse for deres egne stop og kun på dagen, hvad gør det så faktisk sandt? Hvis den siger, at noget skal gemmes i syv år, hvad arkiverer eller fjerner det så efter syv? En politik uden et håndhævelsespunkt er for det meste et ønske. Styring bliver til arkitektur, når de beslutninger bygges ind i systemet.
Styring bliver aldrig færdig
Sektion kaldt “Styring bliver aldrig færdig ”Lad mig få det af vejen tidligt: Du bliver aldrig færdig med styring. Jeg har set det gå i bølger. En virksomhed sætter virkelig fokus på datakvalitet, og tingene bliver bedre. Fokus flytter sig, og kvaliteten glider. En ny integration går i luften, en forretningsenhed ændrer sin proces, nogen importerer en fil, virksomheden opkøber en anden, en agent begynder at skrive poster, og problemet ændrer sig igen. Målet er ikke en mytisk tilstand, hvor hver post er perfekt for evigt. Det er at holde dataene troværdige nok til forretningen og holde det værste af de dårlige data ude. Det er løbende arbejde.
Når Salesforce mest står alene, betyder styring at rydde op i data ét sted. Når Salesforce er ét knudepunkt i landskabet fra kapitel 4, bliver det sværere, og mere nødvendigt. Nu bor kunden i Salesforce, ERP’et, datavarehuset, partnersystemer og Data 360. Hvem ejer den? Hvem kan ændre den? Hvilken kopi er autoritativ, hvilke attributter må flytte sig, hvor længe opbevares de, og hvem svarer, når de er forkerte? Det er ikke konfigurationsspørgsmål. Det er styringsspørgsmål, der bliver til konfiguration.
Postens ejer er ikke dataejeren
Sektion kaldt “Postens ejer er ikke dataejeren ”Start med ordet ejer, for Salesforce gør det forvirrende. Åbn en konto (Account), og du ser en Owner: en sælger, lad os sige. Ejer sælgeren kundedataene? Ikke nødvendigvis. I Salesforce ejes en post på et objekt med en ejer af en bruger eller en kø; ejeren får fuld adgang, og ejeren styrer tildeling og deling via rollehierarkiet og delingsregler (Sharing and Record Access Features (opens in a new tab), på engelsk). Det er postejerskab: en platformmekanisme.
Dataejeren er noget andet: den person eller funktion, der står til ansvar for dataene som et forretningsaktiv. Økonomi kan eje de juridiske kundeoplysninger, drift leveringsstatussen, HR medarbejderdataene. Salesforce giver dig endda et sted at registrere det: klassifikationsfeltet Data Owner på hvert felt (Data Classification Metadata Fields (opens in a new tab), på engelsk).
Hos Steve Trucking kan en detailpartners konto være ejet af den salgschef, der håndterer den partner. Men partnerens juridiske identitet styres af økonomi og er mastered i økonomiafdelingens ERP. Salg, service, drift og partnerportalen har alle brug for kontoen; intet af det betyder, at salgschefen skal ændre partnerens juridiske identitet, når økonomi først har fastlagt den. Jeg har set teams kigge på feltet Owner og gå ud fra, at de har løst dataejerskabet. Det har de ikke. Tildeling af poster er ikke forretningsmæssigt ansvar.
Ejer, forvalter, vogter
Sektion kaldt “Ejer, forvalter, vogter ”Tre styringsroller, tre forskellige opgaver.
Dataejeren fastsætter politikken. Ejeren svarer på, hvad dataene betyder, hvem der må oprette og ændre dem, hvor præcise de skal være, hvor længe de opbevares, hvem der må se dem, hvilket system der er autoritativt, og hvad der sker, når de er forkerte. Arkitekten skal ikke opfinde de svar. Det er en af mine fasteste holdninger: ejerne fastsætter politikken; arkitekterne håndhæver den. Hvis økonomi siger, at det juridiske navn kun kan ændres via ERP-processen, når kunden først er aktiv, er det en styringsbeslutning. At gøre det mekanisk sandt er mit job.
Dataforvalteren (data steward) holder det kørende. Forvalteren er tæt på dataenes daglige sundhed: holder øje med kvalitetssignaler, undersøger dubletter, løser undtagelser, koordinerer rettelser, vedligeholder definitioner og opdager den proces, der bliver ved med at producere dårlige data. To opgaver mere ligger hos forvalteren. Når to teams er uenige om, hvad et felt betyder, hvem der ejer det, eller hvem der må se det, bringer forvalteren uenigheden til ejeren og sørger for, at beslutningen bliver ført ud i livet. Og forvalteren opbygger datakompetence (data literacy): hjælper de mennesker, der indtaster og bruger dataene, med at forstå, hvad de betyder, og hvorfor reglerne findes. En forvalter har brug for mere end et navn på et diagram. Forvalteren har brug for tid, synlighed, en proces og myndighed til at få problemer løst. Ellers bliver »dataforvalter« nogens ottende ansvarsområde, som der kigges på én gang i kvartalet.
Datavogteren (custodian) driver systemet. Admins, platformteams, sikkerhedsteams: dem, der driver den teknologi, der opbevarer og behandler dataene. Ejeren siger, at kun disse roller må se dem; vogteren driver de kontroller, der gør det sådan. Navnene betyder mindre end at gøre hvert ansvar tydeligt, og i en lille organisation kan én person have to kasketter på.
Sådan kører programmet
Sektion kaldt “Sådan kører programmet ”Styringsprogrammer har typisk tre former. Centraliseret: Ét team skriver politikkerne og standarderne for alle domæner. Det er konsistent, og det kan blive en flaskehals, langt fra de mennesker, der udfører arbejdet. Fødereret (decentraliseret): Hvert domæne, for eksempel økonomi, salg eller drift, styrer sine egne data inden for nogle få fælles regler. Det er tæt på arbejdet, og definitionerne glider fra hinanden mellem domænerne. Hybrid: Et lille centralt team ejer standarderne og de fælles definitioner, og domæneejerne og forvalterne håndterer deres egne data. De fleste større virksomheder, jeg har set, ender et sted i hybriden. For arkitekten besvarer formen ét praktisk spørgsmål: Hvem godkender en politik, før jeg håndhæver den, og hvor bor de fælles definitioner?
Eksamensviden. Kend de tre måder at køre et styringsprogram på, centraliseret, fødereret (decentraliseret) og hybrid, og hvad hver af dem betyder for, hvem der fastsætter politikken, og hvor de fælles definitioner bor.
Lad RACI’en gøre sig fortjent til sin plads
Sektion kaldt “Lad RACI’en gøre sig fortjent til sin plads ”En RACI (hvem er Responsible, Accountable, Consulted og Informed: udførende, ansvarlig, konsulteret og informeret) hjælper, men ikke et kæmpe regneark, lavet fordi styring »kræver et«. Jeg vil have den til at besvare arkitekturspørgsmål, startende med de tre fra kapitel 4 (De fire spørgsmål bag kategorierne): Hvor bliver dataene oprettet, hvor bliver de redigeret, og hvor bliver der refereret til dem? Det er ofte forskellige systemer. Tag et produkt: ERP’et opretter det, Salesforce refererer til det, portalen viser det, datavarehuset analyserer det. Nu ændrer forretningen, hvad »aktivt produkt« betyder. Hvor starter ændringen, hvem godkender den, hvordan spreder den sig, og hvilke kopier er skrivebeskyttede? Hvis du ikke kan svare, har du ikke styring endnu. Du har kopier. En god RACI afslører præcis den uklarhed.
Styring skal blive mekanisk
Sektion kaldt “Styring skal blive mekanisk ”Forretningen siger, at kun økonomi må ændre kundens juridiske navn. Jeg vil ikke have, at arkitekturens svar er »det tager vi i oplæringen«. Oplæring hjælper; det er ikke håndhævelse. Måske er det adgang på feltniveau, en valideringsregel, et felt, som kun integrationen skriver, eller en kontrolleret proces i stedet for direkte redigering. Mekanismen afhænger af kravet, men der skal være en:
| Styringspolitik | Ejer beslutter | Muligt håndhævelsespunkt |
|---|---|---|
| ERP’et ejer kundens juridiske identitet | Økonomi | Felter kun for integrationen, tilladelser, validering |
| Kun folk med et behov ser personoplysninger | Privacy, sikkerhed | Deling, tilladelser, feltadgang |
| Kunde-id’er er unikke | Forretningsejer | Unikt External ID, dubletregler |
| Styrede poster oprettes ikke i hånden | Dataejer | Tilladelser, automatisering, integration |
| Følsomme data har en fastsat opbevaringsperiode | Privacy, jura | En opbevarings- eller sletningsproces |
| Vigtige ændringer skal kunne bevises | Compliance | Felthistorik, revisionsspor |
| Dataenes kilde forbliver identificerbar | Dataejer | Et kildefelt, metadata om dataoprindelse |
Jeg skriver muligt håndhævelsespunkt med vilje. Det her er ikke en tabel til at vælge funktioner. Det er rækkefølgen i tænkningen: Hvad er politikken, hvem ejer den, og hvad i arkitekturen gør den sand?
Ejerne fastsætter politikken; arkitekterne håndhæver den.
Stol ikke på god opførsel
Sektion kaldt “Stol ikke på god opførsel ”»Ændr aldrig kunde-id’et fra ERP’et.« Alle ved det, indtil nogen gør det: ved et uheld, via en dataindlæsning, via automatisering, via en integration, via en agent. Hvis en ændring ville skade virksomhedens data, er »lad venligst være« ikke kontrollen. Byg kontrollen. Hav tillid, men kontrollér. Mennesker, integrationer, automatisering og AI laver alle fejl, så arkitekturen bør gå ud fra, at noget før eller siden vil forsøge det, politikken forbyder. Hvad sker der så?
Styring krydser systemgrænser
Sektion kaldt “Styring krydser systemgrænser ”Tilbage til landskabet. ERP’et ejer kunden; Salesforce, datavarehuset og en kundedataplatform har kopier; en partner får noget af den. Hvilket system gælder politikken for? Dem alle. Salesforce kan korrekt blokere en ændring af det juridiske navn, mens en integration lader et system længere nede i kæden overskrive det. Salesforce kan slette personoplysninger, som datavarehuset stadig har. Et felt, der er klassificeret som følsomt i Salesforce, kan lande i et uklassificeret tekstfelt et andet sted. Styring kan ikke stoppe ved org’ens kant, for det gør dataene ikke. Derfor kom kapitel 4 først: Landskabet fortæller dig, hvor langt styringen skal række.
Styr nok, ikke alt
Sektion kaldt “Styr nok, ikke alt ”Den modsatte fejl er lige så reel. Vi opdager, at styring betyder noget, så vi låser alt: Ingen kan oprette, hver ændring kræver godkendelse. Dataene er styret, og ingen kan udføre deres arbejde. Styring betyder den passende kontrol for dataene: stram for nogle, let for andre. Nogle poster kan oprettes frit, nogle kræver godkendelse; nogle felter kan næsten alle redigere, nogle kun integrationen. Det næste modul bliver praktisk om netop det.
Og fordi styring aldrig bliver færdig, har håndhævelsen brug for feedback. Stiger antallet af dubletter? Bliver påkrævede felter fyldt med skrald? Fejler integrationer, finder brugerne omveje, vokser undtagelserne, bruger forvalterne hele dagen på ét problem? De signaler fortæller dig, om designet virker, og nogle gange, at kontrollen, eller politikken, skal ændres.
Ud over eksamen: hvad AI ændrer. Styring har fået en ny forbruger: agenten. Dataejeren beslutter stadig, hvad der må bruges, og til hvad; arkitekten gør det stadig håndhæveligt. Det, der ændrer sig, er hastighed og skala. En agent læser, kombinerer og handler på styrede data langt hurtigere end et menneske, så en politik, der kun findes i et dokument, beskytter endnu mindre.
Hvad en arkitekt beslutter her
Sektion kaldt “Hvad en arkitekt beslutter her ”- Hvem der står til ansvar for hvert vigtigt datadomæne, og hvordan det adskiller sig fra postejerskab.
- Hvem der forvalter dataene, og hvem der driver dem som vogter.
- Hvor vigtige data oprettes, redigeres, refereres og er mastered på tværs af landskabet.
- Hvilket håndhævelsespunkt der gør hver vigtig politik mekanisk sand.
- Hvordan arkitekturen viser, om styringen virker eller er begyndt at glide.
Når jeg hører et styringskrav, oversætter jeg det. »ERP’et ejer det her.« »Kun disse personer må se det her.« »Vi skal kunne bevise, hvem der ændrede det her.« »Gem det her i syv år.« Hver gang: Vis mig håndhævelsespunktet. Arkitekten beslutter ikke politikken. Vi designer systemet, der håndhæver den. Det er dér, styring holder op med at være et dokument og bliver til arkitektur.
Læs mere
Sektion kaldt “Læs mere ”- Salesforce Help, Sharing and Record Access Features (opens in a new tab) (på engelsk, kontrolleret 2026-10-14).
- Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (på engelsk, kontrolleret 2026-10-14).