CMDB - Den kompletta guide för att lycka med sin CMDB

Vad är Service Configuration Management?

Service Configuration Management är den ITIL 4 practice som säkerställer att korrekt och tillförlitlig information om IT-miljöns konfiguration finns tillgänglig när och där den behövs. I praktiken handlar det om att veta exakt vad organisationen har, hur det är konfigurerat, hur komponenter hänger ihop och hur ändringar påverkar helheten.

I centrum för Service Configuration Management står CMDB – Configuration Management Database. Trots namnet är CMDB inte bara en databas, utan ett komplett system som innehåller information om alla IT-tillgångar (Configuration Items eller CI:s) och deras relationer till varandra.

Service Configuration Management är den practice som förvandlar en samling IT-komponenter till en förstådd, hanterad och kontrollerbar IT-miljö.

Syftet med Service Configuration Management

Det primära syftet med Service Configuration Management är att:

Ge synlighet och kontroll över IT-miljön

• Organisationen ska veta exakt vad som finns i IT-infrastrukturen
• Vilken version, vilken konfiguration, var den är placerad
• Vem som äger och ansvarar för varje komponent

Möjliggöra effektiv impact-analys

• Innan en ändring görs: Vad kommer att påverkas?
• När en incident inträffar: Vilka tjänster och användare påverkas?
• Vid planering: Vilka beroenden finns?

Stödja alla andra ITIL practices

• Incident Management behöver veta vilka CI:s som är involverade
• Change Enablement (Change Management) behöver förstå påverkan
• Problem Management behöver se mönster och relationer
• Service Level Management behöver veta vilka CI:s som stödjer vilka tjänster

Säkerställa korrekt information är tillgänglig

• Rätt information
• Till rätt personer
• Vid rätt tidpunkt
• I rätt format

Upprätthålla kontroll och compliance

• Veta vad som körs i produktionsmiljön
• Upptäcka oauktoriserade ändringar
• Dokumentera för revision
• Hantera licenser och kontrakt

Optimera kostnader och resurser

• Eliminera duplicering
• Identifiera outnyttjade tillgångar
• Planera uppgraderingar och ersättningar
• Förstå total cost of ownership

Varför Service Configuration Management är helt avgörande

Service Configuration Management och CMDB är ofta den mest underskattade och samtidigt mest kritiska ITIL practice. Här är varför:

CMDB är IT-organisationens "karta över verkligheten"

Utan en karta är det omöjligt att navigera i komplex terräng. CMDB är den kartan för IT-miljön:

Föreställ dig följande scenario utan CMDB: En kritisk server går ner klockan 02:00 på natten. On-call-teknikern behöver snabbt förstå:

• Vilka applikationer körs på servern?
• Vilka användare/verksamhetsprocesser påverkas?
• Finns det redundans eller failover?
• Vem är tjänsteägare som behöver informeras?
• Vilka andra system är beroende av denna server?

Utan CMDB kan det ta timmar att få svar på dessa frågor. Med en välfungerande CMDB tar det sekunder.

Möjliggör proaktiv IT-hantering

CMDB transformerar IT från reaktiv till proaktiv:

Proaktiv säkerhet:

• Identifiera alla system som kör en sårbar version av en programvara
• Skicka automatiska alerts när nya sårbarheter publiceras
• Se vilka system som saknar patches
• Förstå vilken exponering organisationen har

Proaktiv kapacitetsplanering:

• Identifiera system som närmar sig kapacitetsgränser
• Planera uppgraderingar baserat på faktisk användning och beroenden
• Förstå kostnadsimplikationen av olika scenarios

Proaktiv livscykelhantering:

• Veta vilka system som närmar sig end-of-life
• Planera migrationer i god tid
• Förstå vilka verksamhetsprocesser som påverkas

Kostnadsoptimering och licenshantering

Många organisationer har ingen aning om vad de faktiskt betalar för:

Software Asset Management:

• Vilka licenser äger vi?
• Var används de?
• Betalar vi för licenser som inte används?
• Riskerar vi compliance-problem för under- eller överlicensiering?

Hardware Asset Management:

• Vilken hårdvara äger vi?
• Var finns den?
• Används den eller ligger den outnyttjad?
• När behöver den ersättas?

Cloud Cost Management:

• Vilka cloud-resurser har vi?
• Vem äger dem?
• Finns det "glömda" instanser som kostar pengar?

Studier visar att organisationer utan god Configuration Management kan slösa 15-30% av sin IT-budget på:

• Outnyttjade licenser
• Duplicerad hårdvara
• Glömda cloud-resurser
• Ineffektiv kapacitetsplanering

Compliance och revision

För reglerade branscher är Configuration Management inte valfritt:

Revisorer förväntar sig:

• Komplett inventering av alla system i produktionsmiljö
• Dokumentation av vem som har tillgång till vad
• Spårbarhet av ändringar
• Bevis på att endast godkända versioner körs

Regulatoriska krav:

• SOX (Sarbanes-Oxley) kräver kontroll över finansiella system
• GDPR kräver kunskap om var persondata lagras och processas
• PCI-DSS kräver dokumentation av alla system som hanterar kortdata
• ISO 27001 kräver Asset Management

Utan CMDB är det praktiskt omöjligt att uppfylla dessa krav i en komplex IT-miljö.

Grund för automation och orchestration

Modern IT kräver automation. Men automation utan korrekt konfigurationsinformation är farlig:

Infrastructure as Code (IaC):

• Terraform, Ansible, Puppet behöver veta vad som finns
• CMDB kan vara "source of truth" för automation
• Ändringar via automation uppdaterar CMDB automatiskt

Cloud orchestration:

• Automatisk provisionering av resurser
• Auto-scaling baserat på faktisk användning
• Decommissioning av outnyttjade resurser

Service catalog:

• Användare beställer tjänster
• CMDB vet vilka resurser som behövs
• Automation provisionerar baserat på CMDB-data

Möjliggör digital transformation

För organisationer som genomgår digital transformation är CMDB fundamentalt:

Microservices och containers:

• Spåra tusentals dynamiska containers
• Förstå beroenden mellan microservices
• Kartlägga från affärsfunktion ner till container

Multi-cloud strategy:

• Veta vad som körs var (AWS, Azure, GCP, on-premise)
• Förstå kostnader per tjänst över olika clouds
• Hantera hybrid cloud-komplexitet

API-ekonomi:

• Vilka API:er exponeras och konsumeras?
• Vilka beroenden finns mellan system via API:er?
• Impact av API-ändringar

Vanliga fallgropar vid införande av Service Configuration Management

Configuration Management och CMDB-projekt är notoriskt svåra och har hög misslyckande-rate. Här är de vanligaste misstagen:

Fallgrop 1: Börja med tekniken istället för affärsbehovet

Problemet: Organisationen köper ett dyrt CMDB-verktyg och börjar mata in data utan att först definiera varför. "Vi ska ha en CMDB för att ITIL säger det" eller "Vi ska dokumentera allt vi har."

Konsekvensen:

• Massiva datainmatningsprojekt utan tydligt syfte
• Information samlas in "för säkerhets skull" som aldrig används
• CMDB blir en datadump utan värde
• Personal ser det som byråkratisk börda
• Projektet dör långsamt när entusiasmen svalna

Lösningen: Börja alltid med use cases:

• Varför behöver vi en CMDB?
• Vilka affärsproblem ska den lösa?
• Vilka decisions ska den möjliggöra?

Exempel på starka use cases:

• "Minska tiden att identifiera påverkade tjänster vid incidenter från 45 minuter till 5 minuter"
• "Automatiskt identifiera alla system som påverkas av en säkerhetssårbarhet"
• "Eliminera 'shadow IT' genom att ha en single source of truth"
• "Minska software licensing costs med 20% genom bättre synlighet"

Implementera iterativt:

• Börja med en use case
• Samla endast den data som behövs för den use casen
• Bevisa värdet
• Expandera till nästa use case

Fallgrop 2: Försöka dokumentera allt från början

Problemet: Organisationen vill ha "komplett" CMDB där allt är dokumenterat med alla attribut från dag ett. Detta leder till analyslammelse och evighets-projekt.

Konsekvensen:

• Projektet blir för stort för att hantera
• Data som samlas in är redan utdaterad när den är färdig
• Otroligt dyrt och resurskrävande
• Projektet överges innan det ger värde

Lösningen: 80/20-regeln:

• Identifiera de 20% av CI:s som ger 80% av värdet
• Fokusera på kritiska system först
• Expandera gradvis

Minimal Viable CMDB:

• Börja med endast kritiska attribut:
  • Vad är det? (CI-typ)
  • Var är det? (Location/environment)
  • Vem äger det? (Owner)
  • Vilka relationer har det? (Dependencies)
• Lägg till fler attribut när behov uppstår

Service-driven approach:

• Börja med era viktigaste affärstjänster
• Dokumentera CI:s som stödjer dessa tjänster
• Arbeta er ner från affärsvy till teknisk vy

Fallgrop 3: CMDB som IT-asset register istället för relationer

Problemet: CMDB behandlas som en glorifierad Excel-lista över IT-tillgångar. Det som gör en CMDB värdefull – relationerna mellan CI:s – negligeras.

Konsekvensen:

• CMDB blir en statisk databas
• Impact-analys är omöjlig
• Dependency mapping saknas
• De flesta use cases kan inte realiseras

Lösningen: Fokusera på relationer: En CI utan relationer är bara en datapost. En CI med relationer berättar en historia:

• Servern X hostar Applikation Y
• Applikation Y stödjer Affärstjänst Z
• Affärstjänst Z används av Affärsprocess W
• Servern X kommunicerar med Databas Q
• Servern X placerad i Datacenter R

Viktiga relationstyper:

• Hosting: Vad körs var?
• Depends on: Vad behöver vad?
• Connected to: Vad pratar med vad?
• Supports: Vilken affärstjänst stöds?
• Owned by: Vem äger och ansvarar?
• Located in: Fysisk eller logisk placering

Visualisering:

• Investera i verktyg som kan visualisera relationer
• Service maps ska vara levande dokument
• Personal ska kunna "klicka sig igenom" beroenden

Fallgrop 4: Manuellt datainsamlande och uppdatering

Problemet: Data samlas in manuellt genom Excel-formulär, intervjuer eller inventeringar. CMDB uppdateras genom manuella processer. Detta fungerar inte i en dynamisk IT-miljö.

Konsekvensen:

• Data är utdaterad nästan omedelbart
• Uppdatering är för resurskrävande för att hållas vid liv
• Personal glömmer eller vägrar uppdatera
• CMDB blir "skräpdata" som ingen litar på
• "Garbage in, garbage out"

Lösningen: Automatisk discovery och integration:

Discovery-verktyg:

• Nätverksscanning för att hitta devices
• Agent-baserad discovery för servrar och workstations
• Agentless discovery via WMI, SSH, SNMP
• Cloud discovery (AWS Config, Azure Resource Graph)
• Container discovery (Kubernetes API)

Integration med andra system:

• ITSM-verktyg: Incident, Change, Problem records uppdaterar CI:s automatiskt
• Monitoring-system: Nagios, Zabbix, Datadog rapporterar in status
• Cloud management platforms: Automatisk import av cloud resources
• Asset management systems: Hardware inventory
• Network management: Topology och configurations
• Virtualization platforms: VMware vCenter, Hyper-V
• Container orchestration: Kubernetes, Docker Swarm

CI Lifecycle automation:

• Automatiskt skapa CI när ny resurs provisioneras
• Automatiskt uppdatera vid ändringar
• Automatiskt märka som "retired" när resurs decommissionas

Data quality automation:

• Automated reconciliation (hitta duplicates)
• Data validation rules
• Automated clean-up av "stale" data

Regel: 80% automation, 20% manuell kurator

• Majoriteten av data ska komma in automatiskt
• Människor ska kurerar, kvalitetssäkrar och kompletterar
• Fokusera manuellt arbete på relationer och ägande

Fallgrop 5: Ingen tydlig process för datakvalitet och governance

Problemet: Ingen äger CMDB:s datakvalitet. Det finns inga processer för att säkerställa korrekthet, aktualitet och fullständighet. Olika team har olika syn på vad som ska dokumenteras.

Konsekvensen:

• Datalitet eroderar över tid
• Konflikterande information från olika källor
• Ingen litar på CMDB:n
• "Shadow databases" skapas av frustrerade team
• CMDB blir irrelevant

Lösningen:

Utse en Configuration Manager:

• Äger Configuration Management-processen
• Ansvarar för datakvalitet
• Har mandat att driva förbättringar
• Arbetar med alla team för att säkerställa compliance

CI Ownership:

• Varje CI eller CI-kategori ska ha en ägare
• Ägaren ansvarar för korrekthet av data
• Tydlig RACI för vem som gör vad

Data Quality metrics:

• Completeness: Hur många CI:s av typ X är dokumenterade vs. faktiskt antal?
• Accuracy: Hur ofta är data korrekt vid verifiering?
• Timeliness: Hur snabbt uppdateras ändringar i CMDB?
• Consistency: Konflikter mellan olika källor?

Regelbundna audits:

• Stickprovskontroller
• Jämförelse mellan CMDB och discovery-data
• Verifiering av kritiska CI:s
• Rapportering av kvalitet till ledning

Configuration Management policy:

• Dokumentera vad som ska vara i CMDB
• Definiera attribut för olika CI-typer
• Regler för när CI:s skapas, uppdateras, retireras
• Konsekvenser för non-compliance

Integration med ändringsprocess:

• Alla ändringar ska uppdatera CMDB
• Change record ska länka till påverkade CI:s
• Post-implementation review inkluderar CMDB-verifiering

CMDB i moderna, molnbaserade och DevOps-miljöer

En vanlig missuppfattning är att CMDB är "föråldrad" i modern cloud-native och DevOps-värld. Motsatsen är sann – behovet av Configuration Management är större än någonsin, men approach:en måste anpassas.

Utmaningen med dynamiska miljöer

Traditionell IT:

• Servrar lever i år
• Ändringar är sällsynta
• Manuell CMDB-uppdatering är hanterbar

Modern cloud/DevOps:

• Containers lever i minuter eller timmar
• Hundratals deployments per dag
• Auto-scaling skapar och förstör resurser dynamiskt
• Microservices-topologi ändras konstant

Detta gör traditionell CMDB-approach omöjlig. Men behovet av att förstå miljön är större än någonsin.

CMDB för cloud-native miljöer

Service-centric vs. resource-centric:

Traditionellt (resource-centric):

• Fokus på individuella servrar, storage, networks
• Detaljerad dokumentation av varje komponent

Cloud-native (service-centric):

• Fokus på tjänster och applikationer
• Abstrahera infrastruktur-detaljer
• Dokumentera logiska komponenter

Exempel: Istället för att spåra 1000 individuella containers, dokumentera:

• Microservice "Payment Processing"
  • Körs i Kubernetes cluster "Prod-EU"
  • Exponerar API v2.3
  • Depends on Database "PaymentDB"
  • Ingress via Load Balancer "LB-Prod-01"

De individuella containers är ephemerala och mindre intressanta. Tjänsten är det som spelar roll.

Integration med Infrastructure as Code (IaC)

IaC som CMDB-källa: Modern infrastruktur definieras i kod (Terraform, CloudFormation, ARM templates). Detta är en fantastisk källa för CMDB:

Terraform State as CMDB source:

• Terraform state file vet exakt vad som finns
• Automatiskt importera till CMDB
• Ändringar via Terraform uppdaterar CMDB automatiskt

GitOps och CMDB:

• Infrastructure definitions finns i Git
• Git commits = Configuration changes
• CMDB synkas med Git-repository
• Full audit trail automatiskt

Service Mesh och API-gateway som data-källor

Service Mesh (Istio, Linkerd, Consul):

• Vet exakt vilka microservices som finns
• Kartlägger kommunikation mellan services
• Dependency mapping automatiskt
• Real-time uppdatering i CMDB

API Gateway:

• Vilka API:er exponeras?
• Vilka services konsumerar vilka API:er?
• Dependency graph automatiskt

Observability och CMDB

Modern observability (Datadog, New Relic, Dynatrace) ger enorm insikt:

Automatic Application Discovery:

• Identifiera applikationer automatiskt
• Kartlägga beroenden genom observerad trafik
• Uppdatera CMDB med faktisk, observerad verklighet

Advantages:

• Data baseras på faktiskt beteende, inte antaganden
• Uppdateras real-time
• Hittar "shadow services" automatiskt

Federation vs. centraliserad CMDB

I mycket dynamiska miljöer kan en fullständigt centraliserad CMDB bli en flaskhals. Alternativ approach:

Federated CMDB:

• Varje team/domain har sin egen "source of truth":
  • Kubernetes cluster har sin egen service registry
  • Cloud platform har sitt resource inventory
  • Network team har sin DCIM
• Centraliserad CMDB aggregerar och federerar:
  • Samlar data från alla källor
  • Skapar unified view
  • Upprätthåller relationer mellan domains

Fördelar:

• Teams kan arbeta i sin egen hastighet
• Mindre beroende av central funktion
• Scala bättre
• Respekterar domain-driven design

Utmaningar:

• Komplexare arkitektur
• Reconciliation mellan källor
• Behöver sofistikerade verktyg

Event-driven CMDB

Traditionellt:

• Periodisk scanning (varje timme/dag)
• Pull-based uppdatering

Modern event-driven:

• Cloud events (AWS CloudTrail, Azure Activity Log)
• Kubernetes events
• CI/CD pipeline events
• Real-time push-based uppdatering

När en ny container startas:

1. Kubernetes skickar event
2. Event broker (Kafka, RabbitMQ) fångar event
3. CMDB konsumerar event och uppdaterar
4. Latens: sekunder istället för timmar

Nyckelinsikten för modern CMDB

CMDB är viktigare än någonsin i moderna miljöer, men approach måste anpassas:

• Automatisk discovery och integration (inte manuellt)
• Service-centric (inte resource-centric för ephemerala resurser)
• Event-driven (inte batch-baserat)
• Federation (inte rigid centralisering)
• Relationships och dependencies (inte bara inventory)

Modern CMDB är "living documentation" – den uppdateras kontinuerligt och automatiskt när miljön ändras.

De 5 viktigaste framgångsfaktorerna

För att få Service Configuration Management och CMDB att fungera i praktiken krävs fokus på dessa kritiska områden:

1. Tydliga affärsdrivna use cases och värdemätning

Varför det är viktigt: Utan tydlig affärsnytta blir CMDB ett akademiskt övningsprojekt som aldrig får resurser eller prioritet det behöver.

Vad det innebär i praktiken:

Definiera konkreta use cases:

• Incident Management: "Minska Mean Time to Identify (MTTI) från 30 minuter till 5 minuter"
• Change Management: "Förbättra change success rate från 85% till 95% genom bättre impact-analys"
• Security: "Identifiera alla exponerade system inom 1 timme vid ny sårbarhet"
• Cost optimization: "Minska software licensing cost med 15% genom bättre synlighet"
• Compliance: "Klara audits utan manuellt förberedelsearbete"

Mät och kommunicera värdet:

• Dashboard över CMDB-användning
• Metrics från supported use cases
• ROI-beräkning: Kostnad för CMDB vs. värde skapat
• Success stories och case studies internt

Iterativ expansion:

• Börja med 1-2 high-value use cases
• Bevisa värdet
• Få budget för expansion baserat på bevisad ROI
• Lägg till fler use cases gradvis

Exempel på värdemätning:

Use case: Incident Impact Analysis

• Före CMDB: Genomsnittlig tid att identifiera påverkade tjänster: 35 minuter
• Efter CMDB: Genomsnittlig tid: 4 minuter
• Värde: 31 minuter × 200 incidenter/månad × genomsnittlig incident cost = Besparingen per månad

2. Rätt scope och granularitetsnivå

Varför det är viktigt: För mycket data är lika dåligt som för lite. Rätt granularitet är kritiskt för användbarhet och underhållbarhet.

Vad det innebär i praktiken:

Definiera CI-typer baserat på use cases: Inte allt är en CI. Fråga: "Behöver vi hantera denna komponent separat för våra use cases?"

Exempel på rätt nivå:

• Ja, separate CI: Server, Database, Application, Router, Load Balancer
• Nej, för detaljerat: CPU, RAM stick, Network cable, Log file

Hierarki och aggregation:

Business Service: "E-commerce Platform"
├─ Application Service: "Web Frontend"
│  ├─ Kubernetes Cluster: "Prod-Web-EU"
│  └─ Application: "webshop-app v2.5"
├─ Application Service: "Payment Processing"
│  ├─ Application: "payment-gateway v3.1"
│  └─ Database: "PaymentDB"
└─ Infrastructure Service: "CDN"
   └─ CDN Service: "Cloudflare"

Olika granularitet för olika miljöer:

• Production: Detaljerad dokumentation, alla CI:s
• Pre-production: Medium detalj
• Development: Hög nivå, fokus på services

Olika granularitet för olika CI-typer:

• Kritiska business systems: Mycket detaljerat
• Standard desktops: Hög nivå, gruppering

Attribut per CI-typ: Definiera relevanta attribut för varje CI-typ. Inte alla CI:s behöver alla attribut.

Server CI attribut (exempel):

• Hostname
• IP Address
• Operating System + Version
• Environment (Prod/Test/Dev)
• Owner
• Support Group
• Location
• Virtualization platform (om virtuell)

Men INTE:

• CPU temperature
• Last logged in user
• Disk free space percentage (Dessa är monitoring-data, inte configuration data)

Regeln:

• Configuration data: Relativt statisk, beskriver vad något ÄR
• Monitoring data: Dynamisk, beskriver hur något MÅDDE
• Event data: Händelser som inträffar

CMDB fokuserar på configuration data.

3. Automatisering och integration i hela value chain

Varför det är viktigt: Manuell CMDB-hantering skalas inte och håller inte datakvalitet. Automatisering är inte "nice to have" – det är ett måste.

Vad det innebär i praktiken:

Discovery automation:

Nätverksbaserad discovery:

• Periodisk nätverkscanning
• Identifierar devices via SNMP, SSH, WMI
• Uppdaterar servers, routers, switches, storage

Agent-baserad discovery:

• Agenter installerade på servers/workstations
• Rapporterar detaljerad information
• Kontinuerlig uppdatering

Cloud discovery:

• AWS: AWS Config, CloudTrail
• Azure: Azure Resource Graph
• GCP: Cloud Asset Inventory
• Automated import av alla cloud resources

Container/Kubernetes discovery:

• Kubernetes API integration
• Service mesh data (Istio, Linkerd)
• Automatic service registration

Reconciliation automation: När data kommer från flera källor behöver den reconcilieras:

• Identifiera samma CI från olika källor
• Merge data baserat på prioritetsregler
• Flagga conflicts för manuell resolution
• Automated de-duplication

Lifecycle automation:

Provisionering:

User requests VM → Service Catalog
    ↓
Automation provisions VM
    ↓
CI automatically created in CMDB
    ↓
Relationships established
    ↓
Monitoring configured

Ändring:

Change executed → IaC updates infrastructure
    ↓
Event triggered
    ↓
CMDB updated automatically
    ↓
Dependent processes notified

Decommissioning:

VM deleted → Event captured
    ↓
CI marked as "Retired"
    ↓
Relationships archived
    ↓
License reclaimed

Integration i ITSM-processer:

Incident Management:

• Incident ticket automatically links to affected CI:s
• CI relationships show impacted services
• Known errors linked to CI:s
• Historical incident data per CI

Change Enablement (Change Management):

• Change record must specify affected CI:s
• Impact analysis queries CMDB
• Change approval considers CI criticality
• Successful change updates CI as documented

Problem Management:

• Problem record links to affected CI:s
• Trend analysis per CI-type
• Known errors documented per CI
• Root cause tied to specific CI or relationship

Service Request Management:

• Requests provision/modify CI:s
• CMDB updated automatically
• Asset assignment tracked

4. Stark data governance och ägande

Varför det är viktigt: Utan tydligt ägande och governance eroderar datakvaliteten obönhörligt. CMDB blir snabbt värdelös om ingen ansvarar för korrekthet.

Vad det innebär i praktiken:

Configuration Manager-rollen:

• Äger Configuration Management-processen
• Driver CMDB-strategi och roadmap
• Säkerställer datakvalitet
• Faciliterar mellan olika teams
• Rapporterar till ledning

Configuration Manager är INTE data entry-person – de är strateg och facilitator.

CI-ownership model:

Modell 1: Domain-based ownership

• Network team äger network CI:s
• Server team äger server CI:s
• Application team äger application CI:s

Modell 2: Service-based ownership

• Service Owner för "E-commerce" äger alla CI:s för den tjänsten
• Tydligt från business ner till teknisk implementation

Modell 3: Hybrid

• Technical CI:s ägs av tekniska team
• Business Service CI:s ägs av business/service owners
• Relationships mellan domains kureras centralt

Vilket som väljs, kritiskt är:

• Varje CI har en dokumenterad owner
• Owner ansvarar för korrekthet
• Owner har process för uppdatering

Data quality framework:

Automated quality checks:

• Completeness: CI:s utan mandatory attributes
• Accuracy: CI:s som inte matchat discovery data
• Timeliness: CI:s inte uppdaterade på X dagar
• Relationships: CI:s utan relationer
• Orphans: CI:s utan owner
• Duplicates: Potentiella duplicates

Quality dashboards:

• Overall data quality score
• Quality per CI-type
• Quality per owning team
• Trend över tid

Regular audits:

• Quarterly review av kritiska CI:s
• Sampling av random CI:s
• Comparison med discovery data
• Verification med CI owners

Governance policies:

Configuration Management Policy: Dokumentera:

• Vad är en CI i vår organisation?
• Vilka CI-typer finns?
• Vilka attribut är mandatory vs. optional?
• Vilka relationer ska dokumenteras?
• Vem äger vad?
• Hur ofta uppdateras data?

Change Integration Policy:

• Alla ändringar måste dokumentera affected CI:s
• Successful changes ska update CI configuration
• Failed changes ska dokumentera varför

Consequences för non-compliance:

• Escalation för teams me