# 6. Service Configuration Management # 6.1 Service Configuration Management – Ziele, Begriffe und Grundlagen > **Kurz erklärt** > > Service Configuration Management sorgt dafür, dass wichtige Informationen über Services, Systeme, Komponenten und deren Beziehungen nachvollziehbar gepflegt werden. > > Ziel ist, zu wissen: > > - welche Komponenten vorhanden sind, > - wie sie zusammenhängen, > - wer verantwortlich ist, > - welche Versionen genutzt werden, > - und welche Services von welchen Bestandteilen abhängig sind. > > Dadurch können Incidents, Problems, Changes und Releases besser bewertet und gesteuert werden. --- **Warum Service Configuration Management wichtig ist** IT-Services bestehen selten aus nur einer einzelnen Komponente. Ein scheinbar einfacher Service kann abhängig sein von: - Anwendung, - Datenbank, - Server, - Netzwerk, - DNS, - Zertifikaten, - Identitätsdienst, - Storage, - Cloud-Ressourcen, - Schnittstellen, - Lieferanten, - Monitoring, - Backup, - und Berechtigungen. Wenn diese Zusammenhänge unbekannt sind, entstehen Risiken: - Incidents werden langsamer analysiert, - Changes werden falsch bewertet, - Auswirkungen werden unterschätzt, - Verantwortlichkeiten bleiben unklar, - Problems werden nicht richtig eingegrenzt, - Dokumentation ist veraltet, - und Serviceabhängigkeiten werden erst im Fehlerfall sichtbar. Service Configuration Management schafft dafür eine nachvollziehbare Informationsbasis. --- **Was ist eine Configuration?** Eine Configuration beschreibt, wie ein Service oder System aufgebaut ist. Dazu gehören beispielsweise: - eingesetzte Komponenten, - Versionen, - Einstellungen, - Abhängigkeiten, - Beziehungen, - Standorte, - Verantwortlichkeiten, - Lieferanten, - technische Schnittstellen, - und unterstützende Services. Beispiel: Der Service „VPN-Zugang“ besteht nicht nur aus dem VPN-Gateway. Er kann abhängig sein von: - VPN-Client, - Zertifikaten, - Identity Provider, - MFA, - Firewall, - DNS, - Netzwerkverbindung, - Monitoring, - und Benutzergruppen. --- **Configuration Item** Ein **Configuration Item (CI)** ist ein Bestandteil, der für die Bereitstellung oder Verwaltung eines Service relevant ist. Beispiele: - Server, - Anwendung, - Datenbank, - Netzwerkgerät, - Firewall-Regel, - Zertifikat, - Cloud-Ressource, - Benutzergruppe, - Schnittstelle, - Lizenz, - Dokumentation, - Lieferantenvertrag, - Arbeitsplatzgerät, - Drucker, - Service selbst. Nicht jedes technische Objekt muss automatisch ein CI sein. Die Organisation muss festlegen, welche Elemente wichtig genug sind, um verwaltet zu werden. --- **Beispiele für Configuration Items** | CI-Typ | Beispiel | |---|---| | **Service** | Mitarbeiterportal | | **Anwendung** | Warenwirtschaft | | **Server** | APP-WEB-01 | | **Datenbank** | SQL-Cluster Produktion | | **Netzwerk** | Standort-Firewall | | **Cloud** | Azure App Service | | **Sicherheit** | TLS-Zertifikat | | **Identität** | Entra-ID-Gruppe | | **Dokumentation** | Betriebsrunbook | | **Lieferant** | Supportvertrag Provider | | **Arbeitsplatz** | Notebook | | **Peripherie** | Etikettendrucker | Welche CI-Typen sinnvoll sind, hängt von Organisation, Services und Steuerungsbedarf ab. --- **Ziel von Service Configuration Management** Service Configuration Management soll sicherstellen, dass verlässliche Informationen verfügbar sind über: - Services, - Configuration Items, - Beziehungen, - Versionen, - Status, - Eigentümer, - Standorte, - Lieferanten, - Abhängigkeiten, - und Änderungen. Diese Informationen unterstützen andere ITIL Practices. Beispiele: - Incident Management erkennt betroffene Services schneller. - Problem Management erkennt gemeinsame Ursachen. - Change Enablement bewertet Auswirkungen besser. - Release Management kennt betroffene Komponenten. - Service Level Management versteht Serviceabhängigkeiten. - Information Security Management erkennt kritische Assets. --- **Service Configuration Management ist mehr als Inventarisierung** Inventarisierung beantwortet oft nur: > Was ist vorhanden? Service Configuration Management beantwortet zusätzlich: > Wie hängt es zusammen und warum ist es für den Service wichtig? Beispiel: Eine Inventarliste zeigt: - Server APP-01, - Datenbank DB-01, - Firewall FW-01. Service Configuration Management zeigt zusätzlich: - APP-01 betreibt das Mitarbeiterportal. - APP-01 nutzt DB-01. - FW-01 ermöglicht Zugriff vom Standort Süd. - Das Mitarbeiterportal ist kritisch für interne Anträge. - Service Owner ist die interne IT. - Provider X unterstützt die Firewall. Diese Beziehungen machen die Informationen im Betrieb wertvoll. --- **CI-Beziehungen** Beziehungen zwischen CIs sind besonders wichtig. Typische Beziehungen: - Service nutzt Anwendung, - Anwendung nutzt Datenbank, - Datenbank nutzt Storage, - Server läuft auf Virtualisierungsplattform, - Anwendung ist abhängig von Identity Provider, - Standort nutzt Firewall, - Zertifikat schützt Webservice, - Monitoring überwacht Server, - Lieferant unterstützt Komponente, - Benutzergruppe erhält Zugriff auf Anwendung. Beziehungen helfen zu verstehen, welche Auswirkungen ein Ausfall oder Change haben kann. --- **Beispiel: Serviceabhängigkeiten** Benutzer ↓ Mitarbeiterportal ↓ Webserver ↓ Anwendungsdienst ↓ Datenbank ↓ Storage Zusätzlich abhängig von: - DNS, - Zertifikat, - Identity Provider, - Netzwerk, - Monitoring, - Backup, - Firewall. Wenn die Datenbank ausfällt, ist das Mitarbeiterportal betroffen. Wenn das Zertifikat abläuft, kann die Anmeldung scheitern. Wenn DNS fehlerhaft ist, erscheint der Service möglicherweise komplett unerreichbar. --- **CMDB** Eine **Configuration Management Database (CMDB)** ist ein System oder Datenbestand, in dem Configuration Items und ihre Beziehungen verwaltet werden. Eine CMDB kann enthalten: - CI-Name, - CI-Typ, - Status, - Version, - Umgebung, - Standort, - Owner, - Lieferant, - Kritikalität, - Beziehungen, - letzte Änderung, - verknüpfte Incidents, - verknüpfte Problems, - verknüpfte Changes, - Dokumentationslinks. Eine CMDB muss nicht zwingend ein einzelnes großes Werkzeug sein. Wichtig ist, dass die benötigten Informationen zuverlässig verfügbar und gepflegt sind. --- **CMDB und CMS unterscheiden** Der Begriff **Configuration Management System (CMS)** kann breiter verstanden werden als eine einzelne CMDB. Ein CMS kann mehrere Datenquellen verbinden. Beispiele: - CMDB, - Asset Management, - Monitoring, - Cloud-Inventar, - Netzwerkdokumentation, - Virtualisierungsplattform, - Endpoint Management, - Softwareverteilung, - Dokumentationssystem, - ITSM-Tool. Die CMDB kann ein Teil dieses größeren Systems sein. --- **Configuration Management und Asset Management unterscheiden** | Configuration Management | Asset Management | |---|---| | Fokus auf Servicebeziehungen und Betriebsrelevanz | Fokus auf Besitz, Kosten, Lebenszyklus und Vertragsdaten | | betrachtet CIs und Abhängigkeiten | betrachtet Assets als wirtschaftliche oder verwaltete Objekte | | wichtig für Incident, Problem und Change | wichtig für Einkauf, Lizenzierung und Lifecycle | | Beispiel: Datenbank ist abhängig von Storage | Beispiel: Server wurde am 12.03.2025 gekauft | Ein Objekt kann gleichzeitig Asset und CI sein. Beispiel: Ein produktiver Server ist wirtschaftlich ein Asset und betrieblich ein CI. --- **Welche Informationen sind sinnvoll?** Nicht jedes Detail muss erfasst werden. Sinnvolle CI-Informationen können sein: - eindeutiger Name, - CI-Typ, - Beschreibung, - Servicezuordnung, - Umgebung, - Status, - Version, - Standort, - Owner, - Supportgruppe, - Lieferant, - Kritikalität, - Beziehungen, - Dokumentationslink, - letzte Prüfung, - letzte Änderung, - Sicherheitsklassifizierung. Zu viele ungenutzte Felder machen Pflege schwer. Zu wenige Informationen machen die Daten im Betrieb wertlos. --- **CI-Status** Ein CI kann unterschiedliche Status besitzen. Beispiele: - geplant, - bestellt, - im Aufbau, - aktiv, - in Wartung, - außer Betrieb, - ersetzt, - archiviert. Der Status hilft zu erkennen, ob ein CI produktiv genutzt wird oder nicht. Beispiel: Ein alter Server darf nicht mehr als aktive Abhängigkeit eines produktiven Services erscheinen, wenn er bereits außer Betrieb genommen wurde. --- **Umgebungen kennzeichnen** CIs sollten ihrer Umgebung zugeordnet werden. Beispiele: - Entwicklung, - Test, - Abnahme, - Staging, - Produktion, - Disaster Recovery, - Labor, - Schulung. Das ist wichtig, weil ein Change an einem Testsystem anders bewertet wird als ein Change an einem produktiven System. Unklare Umgebungskennzeichnung kann zu gefährlichen Verwechslungen führen. --- **Kritikalität erfassen** Die Kritikalität beschreibt, wie wichtig ein CI oder Service für die Organisation ist. Beispiele: - geschäftskritisch, - hoch, - mittel, - niedrig, - unterstützend, - nicht produktiv. Die Kritikalität hilft bei: - Priorisierung von Incidents, - Risikobewertung von Changes, - Notfallplanung, - Monitoring, - Patchplanung, - Lieferantensteuerung, - und Service Reviews. Wichtig: Die Kritikalität eines CIs sollte aus der Servicebedeutung abgeleitet werden. --- **Owner und Verantwortlichkeiten** Für wichtige CIs sollte klar sein: - Wer ist fachlich verantwortlich? - Wer ist technisch verantwortlich? - Wer betreibt das CI? - Wer darf Änderungen genehmigen? - Wer pflegt die Dokumentation? - Wer ist Ansprechpartner bei Incidents? - Welcher Lieferant unterstützt das CI? Ohne Owner veralten Informationen schnell. Ungeeignet: > Niemand fühlt sich für das System verantwortlich. Besser: > Service Owner, technischer Owner und Supportgruppe sind dokumentiert. --- **Service Owner und CI Owner unterscheiden** | Rolle | Bedeutung | |---|---| | **Service Owner** | Verantwortung für den gesamten Service und dessen Wertbeitrag | | **CI Owner** | Verantwortung für ein bestimmtes Configuration Item | | **Supportgruppe** | bearbeitet Incidents, Changes oder Betriebsaufgaben | | **Lieferant** | unterstützt oder betreibt bestimmte Komponenten | Ein Service kann viele CIs besitzen. Ein CI kann mehrere Services unterstützen. Deshalb sind Beziehungen und Verantwortlichkeiten wichtig. --- **Datenqualität** Service Configuration Management ist nur hilfreich, wenn die Datenqualität ausreichend ist. Typische Probleme: - veraltete Einträge, - fehlende Beziehungen, - falsche Owner, - doppelte CIs, - unklare Namen, - fehlende Versionen, - nicht dokumentierte Changes, - außer Betrieb genommene Systeme bleiben aktiv, - Cloud-Ressourcen werden nicht erfasst, - manuelle Pflege wird vergessen. Schlechte Datenqualität kann gefährlicher sein als keine Daten, weil sie falsche Sicherheit erzeugt. --- **Datenqualität prüfen** Mögliche Prüffragen: - Existiert das CI noch? - Ist der Status korrekt? - Ist der Owner aktuell? - Stimmen Version und Umgebung? - Sind Beziehungen vollständig? - Ist der betroffene Service verknüpft? - Wurde der letzte Change berücksichtigt? - Sind Lieferant und Supportgruppe korrekt? - Gibt es Dubletten? - Wird das CI noch aktiv genutzt? Regelmäßige Prüfung ist notwendig, besonders bei kritischen Services. --- **Discovery** Discovery bezeichnet das automatische Erkennen von Systemen, Komponenten oder technischen Eigenschaften. Beispiele: - Server erkennen, - installierte Software erfassen, - Netzwerkgeräte finden, - Cloud-Ressourcen inventarisieren, - offene Ports erkennen, - Zertifikate finden, - Versionen auslesen, - Beziehungen ableiten. Discovery kann helfen, Daten aktuell zu halten. Es ersetzt aber nicht jede fachliche Bewertung. Ein Tool kann erkennen, dass ein Server existiert. Es weiß nicht automatisch, welcher Geschäftsprozess davon abhängig ist. --- **Manuelle Pflege** Manche Informationen müssen manuell oder organisatorisch gepflegt werden. Beispiele: - Service Owner, - fachliche Kritikalität, - Geschäftsprozessbezug, - Lieferantenverantwortung, - genehmigte Ausnahme, - Risikoakzeptanz, - Dokumentationslink, - geplante Außerbetriebnahme. Automatische Erkennung und manuelle Pflege müssen zusammenarbeiten. --- **Namenskonventionen** Klare Namenskonventionen helfen, CIs eindeutig zu identifizieren. Beispiele: - Standort, - Umgebung, - Funktion, - laufende Nummer, - Servicebezug. Ungeeignet: - Server1, - Testneu, - Alt-System, - Backup-neu-final, - App2. Besser: - PRD-APP-PORTAL-01, - TST-DB-ERP-02, - BER-FW-STANDORT-01. Die konkrete Namenskonvention muss zur Organisation passen. --- **Configuration Baseline** Eine Configuration Baseline beschreibt einen bekannten, freigegebenen Zustand. Beispiele: - Standardkonfiguration eines Servers, - genehmigte Version einer Anwendung, - geprüfte Firewall-Regelbasis, - freigegebene Client-Konfiguration, - definierter Stand eines Release-Pakets. Baselines helfen bei: - Vergleich mit aktuellem Zustand, - Audit, - Fehlersuche, - Rollback, - Compliance, - Standardisierung. Wenn ein System von der Baseline abweicht, sollte bekannt sein, warum. --- **Abweichungen erkennen** Abweichungen können entstehen durch: - manuelle Änderungen, - ungeplante Changes, - Notfallmaßnahmen, - fehlerhafte Automatisierung, - Lieferantenänderungen, - Schatten-IT, - Konfigurationsdrift, - fehlende Dokumentation. Abweichungen sind nicht automatisch falsch. Sie müssen aber nachvollziehbar und bewertet sein. --- **Service Configuration Management und Incident Management** Bei Incidents helfen Configuration-Daten zu verstehen: - welcher Service betroffen ist, - welche Komponenten beteiligt sind, - welche Abhängigkeiten bestehen, - wer zuständig ist, - welche Changes zuletzt durchgeführt wurden, - welche Known Errors existieren, - ob weitere Services betroffen sein könnten. Beispiel: Eine Anwendung ist nicht erreichbar. Durch CI-Beziehungen wird sichtbar, dass Anwendung, Datenbank und Identity Provider relevant sind. Die Diagnose wird schneller und gezielter. --- **Service Configuration Management und Problem Management** Problem Management nutzt Configuration-Daten, um Ursachen zu erkennen. Beispiele: - mehrere Incidents betreffen dieselbe Version, - mehrere Services hängen vom gleichen Datenbankcluster ab, - ein Standort hat wiederkehrende Netzwerkprobleme, - mehrere Anwendungen nutzen dasselbe Zertifikat, - gleiche Hardwaremodellserie verursacht Ausfälle. Ohne Beziehungen bleiben solche Muster oft verborgen. --- **Service Configuration Management und Change Enablement** Bei Changes helfen Configuration-Daten bei der Auswirkungsbewertung. Zu prüfen ist: - Welche CIs werden geändert? - Welche Services hängen davon ab? - Welche Benutzergruppen sind betroffen? - Welche anderen Changes laufen parallel? - Welche Owner müssen beteiligt werden? - Welche Dokumentation muss aktualisiert werden? - Welche Risiken entstehen? Ein Change ohne Kenntnis der Abhängigkeiten kann unerwartete Incidents erzeugen. --- **Service Configuration Management und Release Management** Release und Deployment benötigen verlässliche Informationen über: - Zielumgebungen, - Versionen, - Komponenten, - Abhängigkeiten, - unterstützte Plattformen, - Konfigurationen, - Schnittstellen, - und Rollback-Zustände. Nach einem Release müssen CI-Daten aktualisiert werden. Sonst stimmen spätere Analysen nicht mehr. --- **Service Configuration Management und Information Security Management** Configuration-Daten unterstützen Sicherheitsarbeit. Beispiele: - kritische Systeme identifizieren, - veraltete Versionen erkennen, - fehlende Patches priorisieren, - Zertifikate überwachen, - externe Schnittstellen erfassen, - Administratorzugänge nachvollziehen, - Datenklassifizierung berücksichtigen, - Shadow IT erkennen, - Notfallpläne erstellen. Sicherheitsmaßnahmen hängen stark davon ab, zu wissen, welche Systeme und Abhängigkeiten existieren. --- **Praxisbeispiel: Abgelaufenes Zertifikat** **Incident** Benutzer können sich nicht am Mitarbeiterportal anmelden. **Analyse** Das TLS-Zertifikat ist abgelaufen. **Configuration Management hilft durch:** - Verknüpfung des Zertifikats mit dem Mitarbeiterportal, - Owner des Zertifikats, - Ablaufdatum, - betroffene Services, - Abhängigkeit zum Identity Provider, - Link zum Erneuerungs-Runbook. **Verbesserung** Zertifikate werden künftig als CIs mit Ablaufdatum, Owner und Monitoring erfasst. --- **Praxisbeispiel: Datenbankcluster** **Situation** Mehrere Anwendungen melden Fehler. **Ohne CI-Beziehungen** Jedes Anwendungsteam sucht getrennt. **Mit CI-Beziehungen** Es wird sichtbar: - alle betroffenen Anwendungen nutzen denselben Datenbankcluster, - der Datenbankcluster nutzt denselben Storage, - Storage zeigt Fehler. **Nutzen** Die Ursache wird schneller eingegrenzt. --- **Praxisbeispiel: Change-Auswirkung** **Change** Firewall-Regel soll angepasst werden. **Configuration Management zeigt:** - welche Services über diese Regel kommunizieren, - welche Standorte betroffen sind, - welche Schnittstellen genutzt werden, - welcher Service Owner beteiligt werden muss, - welche Monitoringprüfungen nach dem Change notwendig sind. **Nutzen** Der Change wird besser bewertet und sicherer umgesetzt. --- **Typische Fehler** **Fehler 1** CMDB wird als reine Inventarliste verstanden. --- **Fehler 2** CIs werden erfasst, aber Beziehungen fehlen. --- **Fehler 3** Daten werden einmal erstellt und danach nicht gepflegt. --- **Fehler 4** Owner sind unbekannt oder veraltet. --- **Fehler 5** Changes aktualisieren die CMDB nicht. --- **Fehler 6** Discovery-Daten werden ungeprüft übernommen. --- **Fehler 7** Zu viele unwichtige Details werden gepflegt, aber wichtige Servicebeziehungen fehlen. --- **Fehler 8** Cloud-Ressourcen und externe Services werden nicht berücksichtigt. --- **Fehler 9** CMDB-Daten werden in Incident, Problem und Change nicht genutzt. --- **Fehler 10** Dubletten und uneinheitliche Namen erschweren die Nutzung. --- **Fehler 11** Kritikalität wird technisch statt geschäftlich bewertet. --- **Fehler 12** Dokumentation und CMDB widersprechen sich. --- **Checkliste CI erfassen** - [ ] eindeutiger Name vergeben - [ ] CI-Typ festgelegt - [ ] betroffener Service verknüpft - [ ] Umgebung dokumentiert - [ ] Status gesetzt - [ ] Version oder Konfiguration erfasst - [ ] Standort oder Plattform dokumentiert - [ ] Owner benannt - [ ] Supportgruppe benannt - [ ] Lieferant erfasst, falls relevant - [ ] Kritikalität bewertet - [ ] Beziehungen zu anderen CIs erfasst - [ ] Dokumentationslink ergänzt --- **Checkliste Beziehungen prüfen** - [ ] Service zu Anwendung verknüpft - [ ] Anwendung zu Datenbank verknüpft - [ ] Anwendung zu Identity Provider verknüpft - [ ] Anwendung zu Netzwerk oder Firewall verknüpft - [ ] Zertifikate verknüpft - [ ] Schnittstellen verknüpft - [ ] Monitoring verknüpft - [ ] Backup oder Wiederherstellung berücksichtigt - [ ] Lieferantenbezug verknüpft - [ ] wichtige Benutzergruppen oder Standorte berücksichtigt --- **Checkliste Datenqualität** - [ ] CI existiert tatsächlich - [ ] Status ist aktuell - [ ] Owner ist aktuell - [ ] Version stimmt - [ ] Umgebung stimmt - [ ] Beziehungen sind plausibel - [ ] keine Dublette vorhanden - [ ] letzter Change wurde berücksichtigt - [ ] Dokumentationslink funktioniert - [ ] Kritikalität ist nachvollziehbar - [ ] nicht mehr genutzte CIs sind archiviert --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker arbeiten täglich mit Configuration Items. Beispiele: - Server, - Netzwerke, - Firewalls, - Clients, - Drucker, - Benutzergruppen, - Zertifikate, - Storage, - Backups, - Monitoring, - Cloud-Ressourcen. Wichtig ist nicht nur, diese Komponenten technisch zu betreiben. Wichtig ist auch zu dokumentieren: - wozu sie gehören, - welche Services davon abhängen, - wer verantwortlich ist, - welche Version genutzt wird, - welche Änderungen erfolgt sind, - und welche Risiken bestehen. Gute Configuration-Daten machen Fehleranalyse, Changes und Servicebetrieb deutlich sicherer. --- **Zusammenfassung** > Service und Komponenten identifizieren > ↓ > wichtige Configuration Items festlegen > ↓ > Eigenschaften und Owner dokumentieren > ↓ > Beziehungen zwischen CIs erfassen > ↓ > Datenqualität prüfen > ↓ > Changes und Releases einbeziehen > ↓ > Informationen in Incident, Problem und Change nutzen > ↓ > CMDB oder CMS kontinuierlich pflegen und verbessern --- **Merksätze** > Service Configuration Management ist mehr als Inventarisierung. > Beziehungen zwischen CIs sind oft wichtiger als einzelne technische Details. > Eine CMDB ist nur so wertvoll wie ihre Datenqualität. > Discovery hilft, ersetzt aber keine fachliche Verantwortung. > Ohne aktuelle Configuration-Daten werden Incidents, Problems und Changes riskanter. > Jede wichtige Änderung sollte auch die Configuration-Daten aktualisieren. --- **Verwandte Seiten** - 6.2 Configuration Items und Beziehungen - 6.3 Configuration Management Database - 6.4 Discovery, Pflege und Datenqualität - 6.5 Service Configuration Management im Zusammenspiel mit Incident-, Problem- und Change-Management - Incident Management - Problem Management - Change Enablement - Release Management - Information Security Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Configuration Management - PeopleCert – ITIL Practice Guide: IT Asset Management - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Problem Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - CI-Beispiele, - CMDB-Inhalte, - Beziehungsmodelle, - Checklisten, - Praxisbeispiele, - und Datenqualitätskriterien sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - CMDB-Struktur, - CI-Typenliste, - Pflichtfeldliste, - Namenskonvention, - Discovery-Pflicht, - oder konkrete Toolauswahl für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Risiken, - Organisationsgröße, - Toollandschaft, - Datenqualität, - Sicherheitsanforderungen, - Supportmodell, - Change-Modell, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 6.2 Configuration Items und Beziehungen > **Kurz erklärt** > > Ein **Configuration Item (CI)** ist ein Bestandteil, der für einen IT-Service wichtig ist und deshalb verwaltet werden soll. > > Beziehungen zwischen CIs zeigen, wie Services, Anwendungen, Systeme, Netzwerke, Datenbanken, Zertifikate, Lieferanten und andere Bestandteile zusammenhängen. > > Der eigentliche Wert entsteht nicht nur durch die Liste einzelner CIs, sondern durch das Verständnis ihrer Abhängigkeiten. --- **Warum Configuration Items wichtig sind** IT-Services bestehen meistens aus mehreren technischen und organisatorischen Bestandteilen. Beispiel: Ein Mitarbeiterportal kann abhängig sein von: - Webserver, - Anwendung, - Datenbank, - Identity Provider, - MFA, - DNS, - Zertifikat, - Load Balancer, - Firewall, - Storage, - Backup, - Monitoring, - Schnittstellen, - Lieferant, - Dokumentation, - und Supportgruppe. Wenn diese Bestandteile nicht bekannt sind, werden Incidents, Problems und Changes schwieriger. Configuration Items helfen dabei, diese Bestandteile strukturiert zu erfassen. --- **Was ist ein Configuration Item?** Ein Configuration Item ist ein Element, das für die Bereitstellung, den Betrieb, die Steuerung oder die Unterstützung eines Service relevant ist. Ein CI kann technisch oder nicht-technisch sein. Beispiele: - Server, - Anwendung, - Datenbank, - Netzwerkgerät, - Firewall-Regel, - Zertifikat, - Cloud-Ressource, - Benutzergruppe, - Service, - Schnittstelle, - Dokumentation, - Lieferantenvertrag, - Lizenz, - Monitoringregel, - Backupjob, - Arbeitsplatzgerät, - Drucker. Nicht jedes vorhandene Objekt muss automatisch ein CI sein. Entscheidend ist, ob das Objekt für Servicebetrieb, Risiko, Support, Change oder Steuerung relevant ist. --- **CI ist nicht gleich Asset** Ein Asset ist häufig ein wirtschaftlich oder vertraglich relevantes Objekt. Ein CI ist ein für den Servicebetrieb relevantes Objekt. | Asset | Configuration Item | |---|---| | Fokus auf Besitz, Kosten, Vertrag oder Lebenszyklus | Fokus auf Servicebeziehung, Abhängigkeit und Betrieb | | wichtig für Einkauf und Lizenzierung | wichtig für Incident, Problem, Change und Release | | Beispiel: Notebook mit Kaufdatum | Beispiel: Notebook als Teil eines verwalteten Arbeitsplatzservices | | Beispiel: Server als Anlagegut | Beispiel: Server als Bestandteil einer produktiven Anwendung | Ein Objekt kann gleichzeitig Asset und CI sein. Beispiel: Ein produktiver Datenbankserver ist ein Asset und gleichzeitig ein CI. --- **Welche Objekte sollten als CI erfasst werden?** Ein Objekt sollte eher als CI erfasst werden, wenn: - ein Service davon abhängig ist, - ein Ausfall Benutzer betrifft, - Changes daran risikoreich sind, - es für Sicherheitsbewertung wichtig ist, - es für Incident-Diagnose benötigt wird, - es eine relevante Version oder Konfiguration besitzt, - es durch einen Lieferanten unterstützt wird, - es eine wichtige Beziehung zu anderen Komponenten hat, - es für Compliance, Audit oder Nachvollziehbarkeit wichtig ist, - oder es in Problem- und Change-Analysen regelmäßig benötigt wird. Ein Objekt muss nicht erfasst werden, nur weil es technisch existiert. Die Pflege muss einen praktischen Nutzen haben. --- **Beispiele für CI-Typen** | CI-Typ | Beispiel | |---|---| | **Business Service** | Mitarbeiterportal | | **Technical Service** | Datenbankplattform | | **Anwendung** | Warenwirtschaft | | **Server** | PRD-APP-PORTAL-01 | | **Datenbank** | SQL-Cluster Produktion | | **Netzwerkgerät** | Standort-Firewall | | **Cloud-Ressource** | App Service, Storage Account | | **Sicherheit** | TLS-Zertifikat, MFA-Richtlinie | | **Identität** | Entra-ID-Gruppe | | **Schnittstelle** | REST-API zum ERP-System | | **Monitoring** | Alarmregel für Zertifikatsablauf | | **Backup** | Backupjob für Datenbank | | **Dokumentation** | Betriebsrunbook | | **Lieferant** | Supportvertrag Provider | Die CI-Typen sollten zur Organisation passen. Zu viele CI-Typen können die Pflege unnötig erschweren. Zu wenige CI-Typen können wichtige Unterschiede verdecken. --- **Service-CI und technische CIs unterscheiden** Ein Service selbst kann als CI betrachtet werden. Beispiel: - Service: Mitarbeiterportal - Anwendung: Portal-App - Server: Webserver - Datenbank: Portal-DB - Zertifikat: portal.example.tld - Identity Provider: zentrale Anmeldung - Supportgruppe: Application Support Der Service ist das, was Benutzer wahrnehmen. Die technischen CIs sind Bestandteile, die den Service ermöglichen. Diese Unterscheidung hilft, technische Informationen mit Benutzer- und Geschäftsbezug zu verbinden. --- **Attribute eines Configuration Items** Ein CI sollte nur so viele Attribute besitzen, wie sinnvoll gepflegt und genutzt werden können. Mögliche Attribute: - CI-Name, - CI-Typ, - Beschreibung, - Status, - Umgebung, - Version, - Standort, - Servicezuordnung, - Owner, - Supportgruppe, - Lieferant, - Kritikalität, - Sicherheitsklassifizierung, - Dokumentationslink, - letzte Änderung, - letzte Prüfung, - Beziehungen, - verknüpfte Incidents, - verknüpfte Problems, - verknüpfte Changes. Wichtig ist nicht maximale Datenmenge. Wichtig ist nutzbare Datenqualität. --- **CI-Name** Der CI-Name sollte eindeutig und verständlich sein. Ungeeignet: - Server1, - AppNeu, - TestAlt, - FirewallFinal, - Datenbank2. Besser: - PRD-APP-PORTAL-01, - TST-DB-ERP-02, - BER-FW-STANDORT-01, - PRD-CERT-PORTAL-2026, - PRD-API-ERP-PARTNER. Eine Namenskonvention kann enthalten: - Umgebung, - Standort, - Funktion, - Servicebezug, - laufende Nummer. Die konkrete Namenskonvention muss zur Organisation passen. --- **CI-Status** Der Status zeigt, in welchem Zustand sich ein CI befindet. Mögliche Status: - geplant, - bestellt, - im Aufbau, - aktiv, - in Wartung, - gesperrt, - außer Betrieb, - ersetzt, - archiviert. Der Status ist wichtig für: - Incident-Diagnose, - Change-Planung, - Sicherheitsbewertung, - Lizenz- und Asset-Abgleich, - Außerbetriebnahme, - und Dokumentationspflege. Ein CI, das außer Betrieb ist, sollte nicht mehr als aktive Abhängigkeit eines produktiven Services erscheinen. --- **Umgebung** Die Umgebung zeigt, wo ein CI genutzt wird. Beispiele: - Entwicklung, - Test, - Integration, - Abnahme, - Staging, - Produktion, - Disaster Recovery, - Labor, - Schulung. Ein Change an einem Testsystem ist anders zu bewerten als ein Change an einem produktiven System. Fehlende Umgebungskennzeichnung kann gefährlich sein. Beispiel: Ein Administrator führt eine Änderung auf einem System aus, das für Test gehalten wird, tatsächlich aber produktiv ist. --- **Version und Konfiguration** Für viele CIs ist die Version wichtig. Beispiele: - Betriebssystemversion, - Anwendungsversion, - Datenbankversion, - Firmwareversion, - Clientversion, - Konfigurationsstand, - Zertifikatslaufzeit, - API-Version, - Treiberversion. Versionen helfen bei: - Incident-Diagnose, - Known Errors, - Sicherheitsbewertung, - Patchmanagement, - Release Management, - Problem Management, - und Change-Bewertung. Beispiel: Wenn nur VPN-Client-Version 5.8 betroffen ist, muss diese Information auffindbar sein. --- **Owner und Supportgruppe** Für wichtige CIs sollte klar sein: - Wer ist fachlich verantwortlich? - Wer ist technisch verantwortlich? - Wer betreibt das CI? - Wer unterstützt bei Incidents? - Wer darf Changes genehmigen? - Wer pflegt Dokumentation? - Welcher Lieferant ist beteiligt? Unklare Verantwortlichkeiten führen zu Verzögerungen. Ungeeignet: > Niemand weiß, wem dieser Server gehört. Besser: > Service Owner, technischer Owner, Supportgruppe und Lieferant sind dokumentiert. --- **Kritikalität** Die Kritikalität beschreibt, wie wichtig ein CI oder der zugehörige Service ist. Mögliche Stufen: - geschäftskritisch, - hoch, - mittel, - niedrig, - nicht produktiv. Die Kritikalität beeinflusst: - Incident-Priorisierung, - Change-Risikobewertung, - Monitoring, - Backup-Anforderungen, - Patchplanung, - Notfallplanung, - Lieferantensteuerung, - und Service Reviews. Wichtig: Die Kritikalität sollte nicht nur technisch bewertet werden. Ein unscheinbarer Server kann geschäftskritisch sein, wenn ein zentraler Prozess davon abhängt. --- **Sicherheitsklassifizierung** Manche CIs benötigen zusätzliche Sicherheitsinformationen. Beispiele: - enthält personenbezogene Daten, - verarbeitet vertrauliche Daten, - besitzt Internetzugang, - ist extern erreichbar, - besitzt Administratorzugänge, - ist Teil kritischer Infrastruktur, - ist auditrelevant, - verarbeitet Zahlungsdaten, - besitzt erhöhte Verfügbarkeitspflichten. Solche Informationen helfen bei: - Risikobewertung, - Change Enablement, - Sicherheitsvorfällen, - Patchpriorisierung, - Zugriffskontrolle, - und Compliance. --- **Was sind CI-Beziehungen?** CI-Beziehungen beschreiben, wie Configuration Items miteinander verbunden sind. Beispiele: - Service nutzt Anwendung, - Anwendung läuft auf Server, - Server nutzt Storage, - Anwendung nutzt Datenbank, - Anwendung authentifiziert gegen Identity Provider, - Webservice nutzt Zertifikat, - Standort nutzt Firewall, - Anwendung kommuniziert mit API, - Monitoring überwacht Service, - Backupjob sichert Datenbank, - Lieferant unterstützt System. Beziehungen machen sichtbar, welche Auswirkungen ein Ausfall oder Change haben kann. --- **Warum Beziehungen wichtiger sind als Einzelinformationen** Eine Liste einzelner CIs beantwortet nur: > Was gibt es? Beziehungen beantworten: > Was hängt wovon ab? Beispiel: CI-Liste: - APP-01, - DB-01, - FW-01, - CERT-01. Beziehungen: - Mitarbeiterportal läuft auf APP-01. - APP-01 nutzt DB-01. - APP-01 ist über FW-01 erreichbar. - Mitarbeiterportal nutzt CERT-01. - DB-01 nutzt Storage-Cluster PRD-STO-01. Erst durch Beziehungen wird klar, welche Komponenten gemeinsam einen Service ermöglichen. --- **Typische Beziehungstypen** | Beziehung | Bedeutung | |---|---| | **nutzt** | Ein CI verwendet ein anderes CI | | **läuft auf** | Anwendung läuft auf Server oder Plattform | | **ist abhängig von** | Service funktioniert nur mit anderem CI | | **verbindet zu** | Netzwerk- oder Schnittstellenbeziehung | | **wird überwacht von** | Monitoringbeziehung | | **wird gesichert durch** | Backupbeziehung | | **wird unterstützt von** | Lieferanten- oder Supportbeziehung | | **ist Teil von** | Komponente gehört zu größerem Service | | **ersetzt** | neues CI ersetzt altes CI | | **kommuniziert mit** | technische Schnittstelle zwischen Systemen | Die Beziehungsarten sollten verständlich und einheitlich genutzt werden. --- **Beispiel: Mitarbeiterportal** Mitarbeiterportal ↓ nutzt Portal-Anwendung ↓ läuft auf Webserver PRD-APP-PORTAL-01 ↓ nutzt Datenbank PRD-DB-PORTAL-01 ↓ nutzt Storage PRD-STO-01 Weitere Beziehungen: - Mitarbeiterportal nutzt DNS-Eintrag portal.example.tld. - Mitarbeiterportal nutzt TLS-Zertifikat PRD-CERT-PORTAL. - Mitarbeiterportal nutzt Identity Provider. - Webserver wird durch Monitoring überwacht. - Datenbank wird durch Backupjob gesichert. - Anwendung wird durch Application Support betreut. --- **Beispiel: VPN-Service** VPN-Service ↓ nutzt VPN-Gateway ↓ nutzt Firewall ↓ nutzt Internetanbindung Zusätzliche Abhängigkeiten: - VPN-Client, - Zertifikat, - MFA, - Identity Provider, - Benutzergruppen, - DNS, - Monitoring, - Netzwerkteam, - Lieferant. Wenn MFA ausfällt, kann der VPN-Service betroffen sein, obwohl das VPN-Gateway technisch läuft. --- **Beispiel: Druckservice** Druckservice ↓ nutzt Druckserver ↓ verwaltet Netzwerkdrucker ↓ nutzt Netzwerksegment Weitere Abhängigkeiten: - Druckertreiber, - Benutzerberechtigungen, - Spooler-Dienst, - Papier- und Verbrauchsmaterial, - Standortnetz, - Fachanwendung, - Etikettenvorlagen. Ein Druckproblem kann also viele Ursachen haben. Ohne Beziehungen wird oft nur der Drucker selbst betrachtet. --- **Beispiel: Schnittstelle zwischen Anwendungen** Anwendung A ↓ sendet Daten an API-Gateway ↓ leitet weiter an Anwendung B ↓ schreibt in Datenbank B Zusätzliche Abhängigkeiten: - Zertifikat, - Firewall-Regel, - DNS, - API-Token, - Berechtigungen, - Monitoring, - Lieferant, - Datenformat. Eine kleine Änderung am API-Token kann den gesamten Datenaustausch stoppen. --- **Beziehungen und Incident Management** Bei Incidents helfen Beziehungen, die Auswirkung zu verstehen. Beispiele: - Welcher Service ist betroffen? - Welche CIs sind beteiligt? - Gibt es eine gemeinsame Abhängigkeit? - Welche anderen Services könnten betroffen sein? - Wer ist zuständig? - Welche Changes wurden zuletzt an beteiligten CIs durchgeführt? - Gibt es Known Errors für diese Version oder Komponente? Beispiel: Mehrere Anwendungen melden Fehler. CI-Beziehungen zeigen, dass alle denselben Datenbankcluster nutzen. Die Diagnose wird schneller eingegrenzt. --- **Beziehungen und Problem Management** Problem Management nutzt CI-Beziehungen, um Muster zu erkennen. Beispiele: - wiederkehrende Incidents betreffen dieselbe Hardwaremodellserie, - mehrere Services nutzen dasselbe Zertifikat, - mehrere Anwendungen sind von derselben Schnittstelle abhängig, - ein Standort hat Probleme mit derselben Firewall, - eine bestimmte Clientversion erzeugt viele Tickets. Ohne Beziehungen bleiben solche Muster oft unsichtbar. --- **Beziehungen und Change Enablement** Bei Changes sind Beziehungen besonders wichtig. Zu prüfen ist: - Welche CIs werden geändert? - Welche Services hängen davon ab? - Welche Benutzergruppen sind betroffen? - Welche Schnittstellen werden beeinflusst? - Welche anderen Teams müssen beteiligt werden? - Welche Dokumentation muss aktualisiert werden? - Welche Tests sind notwendig? - Welche Rollback-Auswirkungen gibt es? Ein Change an einem kleinen CI kann große Auswirkungen haben, wenn viele Services davon abhängen. --- **Beispiel: Change-Auswirkung durch Beziehung** **Change** Ein Zertifikat soll erneuert werden. **Ohne Beziehung** Es wird nur der Webserver betrachtet. **Mit Beziehung** Es wird sichtbar: - Zertifikat wird vom Mitarbeiterportal genutzt, - Anmeldung läuft über Identity Provider, - externe Schnittstelle prüft Zertifikatskette, - Monitoring muss nach Erneuerung geprüft werden, - Service Desk muss mögliche Anmeldefehler kennen. Dadurch wird der Change besser geplant. --- **Beziehungen und Release Management** Release Management benötigt Beziehungen, um zu verstehen: - welche Komponenten Bestandteil des Releases sind, - welche Zielumgebungen betroffen sind, - welche Abhängigkeiten bestehen, - welche Versionen zusammenpassen, - welche Benutzergruppen betroffen sind, - welche Knowledge-Artikel aktualisiert werden müssen. Ein Release kann fehlschlagen, wenn eine abhängige Komponente vergessen wird. --- **Beziehungen und Information Security Management** Sicherheitsarbeit benötigt CI-Beziehungen. Beispiele: - Welche Services sind extern erreichbar? - Welche Systeme verarbeiten vertrauliche Daten? - Welche Anwendungen nutzen ein gefährdetes Zertifikat? - Welche Server verwenden eine verwundbare Softwareversion? - Welche Benutzergruppen haben Zugriff? - Welche Schnittstellen übertragen sensible Daten? - Welche Systeme sind von einem kompromittierten Konto betroffen? Ohne Beziehungen ist Sicherheitsbewertung unvollständig. --- **Beziehungen und Notfallplanung** Für Notfallplanung sind Abhängigkeiten entscheidend. Zu klären ist: - Welche Services sind geschäftskritisch? - Welche CIs werden für Wiederherstellung benötigt? - Welche Reihenfolge ist beim Wiederanlauf notwendig? - Welche Datenbanken müssen zuerst verfügbar sein? - Welche Netzwerkverbindungen sind erforderlich? - Welche Lieferanten müssen erreichbar sein? - Welche Backupjobs gehören zu welchem Service? - Welche Dokumentation wird im Notfall benötigt? Ein Wiederanlaufplan ohne Abhängigkeiten ist häufig unvollständig. --- **Tiefe der Beziehungspflege** Nicht jede Beziehung muss bis ins kleinste Detail gepflegt werden. Zu klären ist: - Welche Beziehungen werden wirklich genutzt? - Welche Beziehungen helfen bei Incident, Problem und Change? - Welche Services sind kritisch? - Welche CIs ändern sich häufig? - Welche Daten können automatisiert gepflegt werden? - Welche Daten müssen manuell gepflegt werden? Zu wenig Beziehungspflege macht die CMDB nutzlos. Zu viel Detailtiefe macht sie schwer wartbar. --- **Beispiel für sinnvolle Detailtiefe** Für einen geschäftskritischen Service sinnvoll: - Service, - Anwendung, - Datenbank, - Server, - Netzwerk, - Zertifikat, - Identity Provider, - Backup, - Monitoring, - Owner, - Lieferant, - wichtigste Schnittstellen. Für einen einfachen Testservice kann weniger Detail genügen. Die Pflege muss zum Risiko passen. --- **Horizontale und vertikale Beziehungen** **Vertikale Beziehungen** zeigen den Aufbau eines Service von oben nach unten. Beispiel: Service ↓ Anwendung ↓ Server ↓ Plattform ↓ Storage **Horizontale Beziehungen** zeigen Verbindungen zwischen gleichartigen oder verbundenen Komponenten. Beispiel: Anwendung A ↔ API ↔ Anwendung B Beide Beziehungstypen sind wichtig. Vertikale Beziehungen helfen bei Auswirkungsanalyse. Horizontale Beziehungen helfen bei Schnittstellen- und Kommunikationsproblemen. --- **Upstream und Downstream** Bei Schnittstellen wird oft zwischen Upstream und Downstream unterschieden. | Begriff | Bedeutung | |---|---| | **Upstream** | vorgelagertes System, von dem Daten oder Dienste kommen | | **Downstream** | nachgelagertes System, das Daten oder Dienste erhält | Beispiel: CRM-System ↓ sendet Kundendaten an ERP-System ↓ sendet Rechnungsdaten an Buchhaltungssystem Wenn das CRM-System fehlerhafte Daten liefert, können downstream weitere Probleme entstehen. --- **Single Point of Failure erkennen** CI-Beziehungen können Single Points of Failure sichtbar machen. Beispiel: Mehrere Services nutzen denselben Datenbankserver. Wenn dieser Server ausfällt, sind alle Services betroffen. Mögliche Maßnahmen: - Hochverfügbarkeit prüfen, - Backup und Restore testen, - Monitoring verbessern, - Kapazität planen, - Change-Risiko erhöhen, - Notfallverfahren dokumentieren. Beziehungen helfen also nicht nur bei Dokumentation, sondern auch bei Risikobewertung. --- **Dubletten und Namensprobleme** CI-Beziehungen werden unbrauchbar, wenn CIs mehrfach oder uneinheitlich erfasst sind. Beispiele: - APP-01, - app01, - AppServer Portal, - PRD-APP-PORTAL-01 beschreiben möglicherweise dasselbe System. Folgen: - Incidents werden falsch verknüpft, - Changes wirken unvollständig, - Beziehungen fehlen, - Reports werden ungenau, - Owner erscheinen widersprüchlich. Namenskonventionen und Dublettenprüfung sind deshalb wichtig. --- **Veraltete Beziehungen** Beziehungen können veralten durch: - Migrationen, - Releases, - Servertausch, - Cloud-Umzug, - neue Schnittstellen, - Außerbetriebnahme, - Notfalländerungen, - Lieferantenwechsel, - Prozessänderungen. Veraltete Beziehungen sind riskant. Beispiel: Ein Change wird als unkritisch bewertet, weil eine alte Beziehung fehlt. Nach Umsetzung fällt ein abhängiger Service aus. --- **Beziehungen durch Changes aktualisieren** Jeder relevante Change sollte prüfen: - Wurde ein CI geändert? - Wurde ein CI neu erstellt? - Wurde ein CI entfernt? - Hat sich eine Version geändert? - Hat sich eine Beziehung geändert? - Hat sich ein Owner geändert? - Hat sich eine Schnittstelle geändert? - Hat sich ein Zertifikat geändert? - Muss die CMDB aktualisiert werden? Configuration Management darf nicht getrennt von Change Enablement betrachtet werden. --- **Beziehungen durch Discovery erkennen** Technische Beziehungen können teilweise automatisch erkannt werden. Beispiele: - Server kommuniziert mit Datenbank, - Anwendung öffnet Verbindung zu API, - Zertifikat ist auf Webserver installiert, - Softwareversion ist vorhanden, - Netzwerkgerät ist erreichbar, - Cloud-Ressource existiert. Aber: Discovery erkennt nicht immer fachliche Bedeutung. Ein Tool kann eine Verbindung sehen. Es weiß nicht automatisch, ob diese Verbindung geschäftskritisch ist. --- **Manuell gepflegte Beziehungen** Manuell gepflegt werden oft: - Service Owner, - fachliche Kritikalität, - Geschäftsprozessbezug, - Supportmodell, - Lieferantenverantwortung, - Risikoakzeptanz, - geplante Ablösung, - Dokumentationslinks, - fachliche Schnittstellenbedeutung. Diese Informationen brauchen Verantwortliche und regelmäßige Prüfung. --- **Beziehungen visualisieren** CI-Beziehungen können als Diagramm, Tabelle oder Abhängigkeitsansicht dargestellt werden. Mögliche Formen: - Service Map, - Abhängigkeitsdiagramm, - Schnittstellenübersicht, - Tabellenansicht, - Netzwerkplan, - CMDB-Beziehungsansicht, - Architekturdiagramm. Wichtig ist, dass die Darstellung für den Zweck geeignet ist. Ein Management-Review benötigt andere Details als eine technische Fehleranalyse. --- **Service Map** Eine Service Map zeigt die wichtigsten Bestandteile eines Services. Beispiel: Service: Mitarbeiterportal Benutzer ↓ DNS ↓ Load Balancer ↓ Webserver ↓ Anwendung ↓ Datenbank ↓ Storage Zusätzlich: Identity Provider, Zertifikat, Monitoring, Backup, Supportgruppe Eine Service Map muss nicht jedes Detail enthalten. Sie soll die wichtigsten Abhängigkeiten verständlich machen. --- **Tabellarische Beziehungspflege** Eine einfache Tabelle kann für kleinere Umgebungen ausreichend sein. | Service | CI | Beziehung | Abhängig von | Owner | |---|---|---|---|---| | Mitarbeiterportal | Portal-App | läuft auf | PRD-APP-PORTAL-01 | App-Team | | Mitarbeiterportal | Portal-App | nutzt | PRD-DB-PORTAL-01 | DB-Team | | Mitarbeiterportal | Portal-App | nutzt | Identity Provider | IAM-Team | | Mitarbeiterportal | Webservice | nutzt | TLS-Zertifikat | Plattform-Team | Wichtig ist, dass die Tabelle gepflegt und genutzt wird. --- **CI-Beziehungen in Tickets nutzen** Tickets sollten relevante CIs enthalten. Das hilft bei: - Auswirkungsanalyse, - Priorisierung, - Eskalation, - Trendanalyse, - Problem Management, - Change-Verknüpfung, - Reporting. Beispiel: Ein Incident wird nicht nur als „Anwendung gestört“ erfasst. Er wird mit Service, Anwendungsversion, Datenbank und betroffener Schnittstelle verknüpft. Dadurch können spätere Muster erkannt werden. --- **CI-Beziehungen in Changes nutzen** Ein Change Request sollte betroffene CIs enthalten. Beispiele: - Zielserver, - Anwendung, - Datenbank, - Zertifikat, - Firewall-Regel, - Schnittstelle, - Monitoringregel, - Dokumentation. Zusätzlich sollten abhängige Services geprüft werden. Ein Change an einer zentralen Komponente muss anders bewertet werden als ein Change an einem isolierten Testsystem. --- **CI-Beziehungen in Problems nutzen** Ein Problem Record sollte relevante CIs und Beziehungen enthalten. Beispiel: Mehrere Incidents betreffen verschiedene Anwendungen. Problem Management erkennt: - alle Anwendungen nutzen dieselbe API, - API nutzt ein ablaufendes Zertifikat, - Zertifikatsmonitoring fehlt. Die CI-Beziehung hilft, eine gemeinsame Ursache zu finden. --- **Praxisbeispiel: Datenbank als gemeinsame Abhängigkeit** **Situation** Drei Anwendungen melden Performance-Probleme. **Einzelbetrachtung** Jedes Team sucht zunächst in seiner Anwendung. **CI-Beziehungen zeigen** - alle drei Anwendungen nutzen denselben Datenbankcluster, - Datenbankcluster nutzt denselben Storage, - Storage zeigt hohe Latenz. **Nutzen** Die Analyse wird schneller auf die gemeinsame Abhängigkeit gelenkt. --- **Praxisbeispiel: Zertifikat als CI** **Situation** Anmeldung am Service schlägt fehl. **CI-Beziehungen zeigen** - Service nutzt Webzertifikat, - Zertifikat läuft heute ab, - Identity Provider prüft Zertifikatskette, - Monitoring überwacht nur HTTP-Status, nicht Zertifikatslaufzeit. **Verbesserung** Zertifikate werden künftig als eigene CIs mit Ablaufdatum, Owner und Monitoringbeziehung gepflegt. --- **Praxisbeispiel: Standort-Firewall** **Situation** Ein Standort meldet Zugriffsstörungen. **CI-Beziehungen zeigen** - Standort nutzt bestimmte Firewall, - mehrere Services laufen über dieselbe VPN-Verbindung, - letzte Änderung war eine Firewall-Regel, - betroffene Benutzergruppe sitzt nur an diesem Standort. **Nutzen** Die Fehlersuche wird auf Standortnetz, Firewall und VPN eingegrenzt. --- **Praxisbeispiel: Veraltete Beziehung** **Situation** Eine alte Datenbank wird abgeschaltet. **Problem** In der CMDB ist nicht dokumentiert, dass ein Reporting-Service noch darauf zugreift. **Folge** Nach Abschaltung fällt das Reporting aus. **Lerneffekt** Vor Außerbetriebnahme müssen Abhängigkeiten geprüft und alte Beziehungen bereinigt werden. --- **Typische Fehler** **Fehler 1** Nur technische Geräte werden als CIs betrachtet. --- **Fehler 2** Services selbst werden nicht als CIs erfasst. --- **Fehler 3** Beziehungen zwischen CIs fehlen. --- **Fehler 4** Beziehungen werden einmal erstellt und danach nicht gepflegt. --- **Fehler 5** Zu viele unwichtige Details werden gepflegt, aber wichtige Abhängigkeiten fehlen. --- **Fehler 6** CIs haben keinen Owner. --- **Fehler 7** CI-Namen sind uneinheitlich oder doppelt. --- **Fehler 8** Discovery-Daten werden ohne fachliche Prüfung übernommen. --- **Fehler 9** Changes aktualisieren CI-Beziehungen nicht. --- **Fehler 10** Tickets werden nicht mit betroffenen CIs verknüpft. --- **Fehler 11** Kritikalität wird ohne Servicebezug bewertet. --- **Fehler 12** Schnittstellen, Zertifikate und Cloud-Ressourcen werden vergessen. --- **Checkliste: Ist ein Objekt ein sinnvolles CI?** - [ ] unterstützt es einen Service? - [ ] kann ein Ausfall Benutzer betreffen? - [ ] ist es für Incidents relevant? - [ ] ist es für Problems relevant? - [ ] ist es für Changes relevant? - [ ] besitzt es wichtige Beziehungen? - [ ] besitzt es relevante Versionen oder Konfigurationen? - [ ] hat es Sicherheits- oder Compliance-Bedeutung? - [ ] braucht es einen Owner? - [ ] muss es regelmäßig geprüft werden? - [ ] lohnt sich der Pflegeaufwand? --- **Checkliste CI-Attribute** - [ ] eindeutiger Name - [ ] CI-Typ - [ ] Beschreibung - [ ] Status - [ ] Umgebung - [ ] Version oder Konfigurationsstand - [ ] betroffener Service - [ ] Owner - [ ] Supportgruppe - [ ] Lieferant, falls relevant - [ ] Kritikalität - [ ] Sicherheitsklassifizierung, falls relevant - [ ] Dokumentationslink - [ ] letzte Prüfung - [ ] relevante Beziehungen --- **Checkliste CI-Beziehungen** - [ ] Service zu Anwendung verknüpft - [ ] Anwendung zu Server oder Plattform verknüpft - [ ] Anwendung zu Datenbank verknüpft - [ ] Anwendung zu Schnittstellen verknüpft - [ ] DNS-Abhängigkeit geprüft - [ ] Zertifikate verknüpft - [ ] Identity Provider oder MFA verknüpft - [ ] Netzwerk und Firewall berücksichtigt - [ ] Storage berücksichtigt - [ ] Backup berücksichtigt - [ ] Monitoring berücksichtigt - [ ] Lieferant berücksichtigt - [ ] Supportgruppe verknüpft - [ ] Dokumentation verknüpft --- **Checkliste Beziehungspflege nach Changes** - [ ] neue CIs angelegt - [ ] entfernte CIs archiviert - [ ] geänderte Versionen aktualisiert - [ ] geänderte Schnittstellen dokumentiert - [ ] neue Abhängigkeiten ergänzt - [ ] entfernte Abhängigkeiten gelöscht - [ ] Owner aktualisiert - [ ] Lieferantenbezug aktualisiert - [ ] Dokumentationslinks geprüft - [ ] Monitoring- und Backupbeziehungen geprüft - [ ] Service Map aktualisiert - [ ] Ticket oder Change Record verknüpft --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker arbeiten praktisch mit vielen Configuration Items. Beispiele: - Server, - Clients, - Firewalls, - Switches, - VPN, - Drucker, - Benutzergruppen, - Zertifikate, - Backupjobs, - Monitoringregeln, - Cloud-Ressourcen, - Anwendungen, - Schnittstellen. Wichtig ist nicht nur, diese Komponenten technisch zu kennen. Wichtig ist auch zu verstehen: - welcher Service davon abhängt, - welche Benutzer betroffen wären, - welche Changes riskant sind, - welche Beziehungen bei Fehleranalyse helfen, - wer zuständig ist, - und welche Informationen aktuell gehalten werden müssen. Gute CI-Beziehungen machen technische Arbeit schneller, sicherer und nachvollziehbarer. --- **Zusammenfassung** > wichtige Services identifizieren > ↓ > relevante Configuration Items bestimmen > ↓ > sinnvolle Attribute erfassen > ↓ > Owner und Kritikalität festlegen > ↓ > Beziehungen zwischen CIs dokumentieren > ↓ > Serviceabhängigkeiten sichtbar machen > ↓ > CIs in Incidents, Problems und Changes nutzen > ↓ > Beziehungen nach Changes aktualisieren > ↓ > Datenqualität regelmäßig prüfen --- **Merksätze** > Ein CI ist nur dann wertvoll, wenn es für den Servicebetrieb relevant ist. > Beziehungen zeigen, welche Auswirkungen ein Ausfall oder Change haben kann. > Eine CI-Liste ohne Beziehungen ist nur begrenzt hilfreich. > Technisch kleine Komponenten können geschäftlich sehr wichtig sein. > Discovery erkennt Technik, aber nicht automatisch fachliche Bedeutung. > CI-Beziehungen müssen nach Changes gepflegt werden. > Gute Configuration-Daten verbessern Incident, Problem, Change und Security Management. --- **Verwandte Seiten** - 6.1 Service Configuration Management – Ziele, Begriffe und Grundlagen - 6.3 Configuration Management Database - 6.4 Discovery, Pflege und Datenqualität - 6.5 Service Configuration Management im Zusammenspiel mit Incident-, Problem- und Change-Management - Incident Management - Problem Management - Change Enablement - Release Management - Information Security Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Configuration Management - PeopleCert – ITIL Practice Guide: IT Asset Management - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Problem Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - CI-Beispiele, - Beziehungstypen, - Service-Maps, - Tabellen, - Checklisten, - und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - CI-Typenliste, - Beziehungstypenliste, - Attributliste, - Service-Map-Struktur, - Namenskonvention, - oder konkrete Modellierungstiefe für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Risiken, - Supportmodell, - Organisationsgröße, - Toollandschaft, - Datenqualität, - Sicherheitsanforderungen, - Change-Modell, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 6.3 Configuration Management Database > **Kurz erklärt** > > Eine **Configuration Management Database (CMDB)** ist ein Datenbestand oder Werkzeug, in dem Configuration Items und ihre Beziehungen verwaltet werden. > > Sie hilft dabei, Services, Systeme, Komponenten, Versionen, Verantwortlichkeiten und Abhängigkeiten nachvollziehbar zu dokumentieren. > > Der Wert einer CMDB entsteht nicht durch möglichst viele Einträge, sondern durch aktuelle, verlässliche und nutzbare Informationen für Incident, Problem, Change, Release und Security Management. --- **Warum eine CMDB wichtig ist** IT-Services bestehen aus vielen abhängigen Bestandteilen. Ohne zentrale oder verlässliche Configuration-Daten entstehen typische Probleme: - niemand weiß genau, welcher Service betroffen ist, - Changes werden mit unvollständiger Auswirkungsbewertung durchgeführt, - Incidents werden langsamer analysiert, - Problems werden nicht richtig eingegrenzt, - veraltete Systeme bleiben unentdeckt, - Zertifikate laufen ab, - Abhängigkeiten zu Lieferanten fehlen, - Dokumentation widerspricht der Realität, - und Verantwortlichkeiten bleiben unklar. Eine CMDB soll diese Informationen strukturiert nutzbar machen. --- **Was eine CMDB leisten soll** Eine CMDB soll helfen zu beantworten: - Welche Services gibt es? - Welche Configuration Items gehören dazu? - Welche Systeme sind produktiv? - Welche Versionen sind im Einsatz? - Welche Komponenten hängen voneinander ab? - Welche Changes wurden zuletzt durchgeführt? - Welche Incidents betreffen ein CI? - Welche Problems oder Known Errors sind verknüpft? - Wer ist verantwortlich? - Welche Lieferanten sind beteiligt? - Welche Dokumentation gehört dazu? - Welche Risiken bestehen? Damit unterstützt die CMDB nicht nur Dokumentation, sondern tägliche Betriebsentscheidungen. --- **CMDB ist kein Selbstzweck** Eine CMDB ist nur sinnvoll, wenn sie genutzt wird. Ungeeignet: > Wir erfassen alles, weil eine CMDB vollständig sein muss. Besser: > Wir erfassen die Informationen, die für Servicebetrieb, Support, Changes, Risiken und Entscheidungen wirklich benötigt werden. Eine zu große, ungepflegte CMDB wird schnell unübersichtlich und unzuverlässig. Eine kleine, gut gepflegte CMDB kann deutlich nützlicher sein. --- **CMDB und Configuration Management System** Eine CMDB ist ein Datenbestand für Configuration Items und Beziehungen. Ein **Configuration Management System (CMS)** kann breiter sein. Ein CMS kann mehrere Quellen verbinden, zum Beispiel: - CMDB, - Asset Management, - Monitoring, - Cloud-Inventar, - Endpoint Management, - Netzwerkdokumentation, - Softwareverteilung, - Virtualisierungsplattform, - Dokumentationssystem, - ITSM-Tool, - Security-Werkzeuge. Die CMDB kann also Teil eines größeren Configuration Management Systems sein. --- **CMDB und Inventarliste unterscheiden** | Inventarliste | CMDB | |---|---| | zeigt häufig nur vorhandene Geräte oder Assets | zeigt Configuration Items und Servicebeziehungen | | Fokus auf Bestand | Fokus auf Betrieb, Abhängigkeiten und Wirkung | | Beispiel: Server existiert | Beispiel: Server betreibt Service X und nutzt Datenbank Y | | wichtig für Übersicht | wichtig für Incident, Problem, Change und Risiko | | oft objektbezogen | service- und beziehungsbezogen | Eine Inventarliste beantwortet: > Was haben wir? Eine CMDB beantwortet zusätzlich: > Wofür wird es genutzt und wovon hängt es ab? --- **Typische Inhalte einer CMDB** Eine CMDB kann enthalten: - Configuration Items, - CI-Typen, - CI-Status, - Servicezuordnung, - Versionen, - Umgebungen, - Standorte, - Owner, - Supportgruppen, - Lieferanten, - Kritikalität, - Sicherheitsklassifizierung, - Beziehungen, - Dokumentationslinks, - verknüpfte Incidents, - verknüpfte Problems, - verknüpfte Changes, - verknüpfte Releases, - letzte Prüfung, - letzte Änderung. Nicht jede CMDB benötigt alle Felder. Die Felder müssen zum Zweck und Pflegeaufwand passen. --- **Beispiel für einen CMDB-Eintrag** | Feld | Beispiel | |---|---| | **CI-Name** | PRD-APP-PORTAL-01 | | **CI-Typ** | Server | | **Status** | aktiv | | **Umgebung** | Produktion | | **Service** | Mitarbeiterportal | | **Owner** | Plattform-Team | | **Supportgruppe** | Application Support | | **Version** | Linux Server Version X | | **Standort** | Rechenzentrum Berlin | | **Kritikalität** | hoch | | **Lieferant** | interner Betrieb | | **Dokumentation** | Betriebsrunbook Mitarbeiterportal | | **Beziehungen** | läuft Portal-App, nutzt Datenbank PRD-DB-PORTAL-01 | | **letzte Prüfung** | 02.08.2026 | Dieses Beispiel ist bewusst einfach gehalten. Die tatsächlichen Felder hängen von Organisation und Werkzeug ab. --- **Wichtige CI-Typen in einer CMDB** Mögliche CI-Typen: - Business Service, - Technical Service, - Anwendung, - Server, - Datenbank, - Netzwerkgerät, - Firewall, - Cloud-Ressource, - Zertifikat, - DNS-Eintrag, - Benutzergruppe, - Schnittstelle, - Monitoringregel, - Backupjob, - Dokumentation, - Lieferantenvertrag, - Arbeitsplatzgerät, - Drucker. Wichtig ist eine klare interne Definition. Wenn Teams CI-Typen unterschiedlich verwenden, werden Auswertungen ungenau. --- **Service als zentrales Element** Eine CMDB sollte nicht nur technische Komponenten sammeln. Wichtig ist die Verbindung zum Service. Beispiel: Mitarbeiterportal ↓ nutzt Portal-Anwendung ↓ läuft auf PRD-APP-PORTAL-01 ↓ nutzt PRD-DB-PORTAL-01 ↓ nutzt PRD-STO-01 Zusätzlich: - Zertifikat, - DNS, - Identity Provider, - Monitoring, - Backup, - Supportgruppe, - Service Owner. Erst diese Serviceperspektive macht die CMDB im Betrieb wertvoll. --- **Beziehungen in der CMDB** Beziehungen sind einer der wichtigsten Bestandteile einer CMDB. Typische Beziehungen: - Service nutzt Anwendung, - Anwendung läuft auf Server, - Anwendung nutzt Datenbank, - Server nutzt Storage, - Service nutzt Zertifikat, - Anwendung kommuniziert mit Schnittstelle, - Standort nutzt Firewall, - Monitoring überwacht CI, - Backupjob sichert Datenbank, - Lieferant unterstützt Komponente. Ohne Beziehungen ist eine CMDB oft nur eine Inventarliste. --- **Beispiel: Beziehungskette** Benutzer ↓ Mitarbeiterportal ↓ Webserver ↓ Anwendung ↓ Datenbank ↓ Storage Weitere Abhängigkeiten: - DNS, - Zertifikat, - Identity Provider, - MFA, - Firewall, - Monitoring, - Backup, - Lieferant. Wenn eine Komponente ausfällt, hilft die CMDB zu erkennen, welche Services betroffen sein können. --- **CMDB und Incident Management** Bei Incidents hilft eine CMDB durch: - schnelle Erkennung betroffener Services, - Zuordnung zu verantwortlichen Teams, - Sicht auf Abhängigkeiten, - Anzeige letzter Changes, - Verknüpfung zu Known Errors, - Priorisierung nach Kritikalität, - bessere Eskalation, - schnellere Kommunikation. Beispiel: Ein Benutzer meldet, dass das Mitarbeiterportal nicht erreichbar ist. Die CMDB zeigt: - Portal läuft auf PRD-APP-PORTAL-01, - nutzt PRD-DB-PORTAL-01, - ist abhängig vom Identity Provider, - letzter Change betraf das Zertifikat. Dadurch kann die Diagnose gezielter beginnen. --- **CMDB und Problem Management** Problem Management nutzt CMDB-Daten, um gemeinsame Ursachen zu erkennen. Beispiele: - mehrere Incidents betreffen dieselbe Version, - mehrere Services hängen vom gleichen Datenbankcluster ab, - viele Probleme treten an einem Standort auf, - mehrere Anwendungen nutzen dasselbe Zertifikat, - wiederkehrende Störungen betreffen denselben Lieferanten. Ohne CMDB-Beziehungen werden solche Muster oft erst spät sichtbar. --- **CMDB und Change Enablement** Change Enablement benötigt CMDB-Daten für die Auswirkungsbewertung. Zu prüfen ist: - Welche CIs werden geändert? - Welche Services hängen davon ab? - Welche Benutzer oder Standorte sind betroffen? - Welche Owner müssen einbezogen werden? - Welche anderen Changes betreffen dieselben CIs? - Welche Dokumentation muss aktualisiert werden? - Welche Tests sind notwendig? - Welche Risiken entstehen? Ein Change ohne CMDB-Prüfung kann unerwartete Auswirkungen verursachen. --- **CMDB und Release Management** Release und Deployment benötigen verlässliche Informationen über: - Zielumgebungen, - betroffene Komponenten, - Versionen, - Abhängigkeiten, - Schnittstellen, - Konfigurationen, - Rollback-Zustände, - Monitoring, - Dokumentation. Nach einem Release müssen CMDB-Daten aktualisiert werden. Sonst zeigt die CMDB einen veralteten Zustand. --- **CMDB und Information Security Management** Eine CMDB unterstützt Sicherheitsarbeit durch Informationen über: - kritische Systeme, - externe Erreichbarkeit, - veraltete Versionen, - Zertifikate, - Datenklassifizierung, - privilegierte Systeme, - Schnittstellen, - Lieferanten, - Cloud-Ressourcen, - betroffene Services bei Schwachstellen. Beispiel: Eine Sicherheitslücke betrifft eine bestimmte Softwareversion. Mit CMDB-Daten kann schneller erkannt werden, welche Systeme und Services betroffen sind. --- **CMDB und Service Level Management** Service Level Management kann CMDB-Daten nutzen, um zu verstehen: - welche Komponenten kritische Services unterstützen, - welche Abhängigkeiten Service Levels gefährden, - welche Lieferanten beteiligt sind, - welche CIs besonders hohe Verfügbarkeit benötigen, - welche Changes Service Levels beeinflussen können. Ein Service Level ist schwer zu steuern, wenn die technischen Abhängigkeiten unbekannt sind. --- **CMDB-Datenquellen** Mögliche Datenquellen für eine CMDB: - manuelle Pflege, - Discovery-Werkzeuge, - Monitoring, - Asset Management, - Endpoint Management, - Cloud-Plattformen, - Virtualisierungsplattformen, - Netzwerkmanagement, - Softwareverteilung, - ITSM-Tickets, - Change Records, - Lieferanteninformationen, - Dokumentationssysteme. Keine einzelne Datenquelle ist automatisch vollständig. Die CMDB muss aus passenden Quellen aufgebaut und geprüft werden. --- **Automatische Discovery** Discovery kann technische Informationen automatisch erfassen. Beispiele: - Server, - IP-Adressen, - installierte Software, - Betriebssystemversionen, - Cloud-Ressourcen, - Zertifikate, - offene Dienste, - Netzwerkgeräte, - virtuelle Maschinen, - Container, - Datenbankinstanzen. Discovery ist hilfreich für Aktualität. Aber Discovery erkennt nicht immer: - fachliche Kritikalität, - Service Owner, - Geschäftsprozessbezug, - Risikoakzeptanz, - Dokumentationsqualität, - geplante Ablösung, - oder organisatorische Verantwortung. --- **Manuelle Pflege** Manuelle Pflege bleibt wichtig für Informationen wie: - Service Owner, - fachliche Kritikalität, - Supportmodell, - Lieferantenverantwortung, - Sicherheitsklassifizierung, - Geschäftsprozessbezug, - Runbook-Link, - Notfallinformationen, - Risikoakzeptanz, - geplante Außerbetriebnahme. Diese Informationen benötigen Verantwortliche. Ohne klare Pflegeverantwortung veralten sie schnell. --- **Datenqualität in der CMDB** Eine CMDB ist nur so gut wie ihre Datenqualität. Wichtige Qualitätskriterien: - Vollständigkeit, - Aktualität, - Eindeutigkeit, - Richtigkeit, - Konsistenz, - Nachvollziehbarkeit, - Nutzbarkeit, - Verantwortlichkeit. Schlechte Daten können gefährlich sein. Sie führen zu falschen Entscheidungen, weil Teams der CMDB vertrauen, obwohl sie veraltet ist. --- **Typische Datenqualitätsprobleme** | Problem | Folge | |---|---| | doppelte CIs | Incidents und Changes werden falsch verknüpft | | veraltete Owner | Eskalation dauert länger | | fehlende Beziehungen | Auswirkung wird unterschätzt | | falscher Status | außer Betrieb genommene Systeme erscheinen aktiv | | fehlende Versionen | Sicherheitsbewertung wird ungenau | | fehlende Servicezuordnung | Priorisierung wird schwieriger | | falsche Umgebung | Test und Produktion werden verwechselt | | fehlende Dokumentationslinks | Betrieb dauert länger | --- **Dubletten vermeiden** Dubletten entstehen, wenn dasselbe CI mehrfach erfasst wird. Beispiele: - APP-01, - app01, - Portal Server, - PRD-APP-PORTAL-01. Folgen: - Beziehungen verteilen sich auf mehrere Einträge, - Reports werden falsch, - Changes erscheinen unvollständig, - Incidents werden nicht richtig gebündelt, - Owner widersprechen sich. Gegenmaßnahmen: - Namenskonvention, - eindeutige IDs, - Dublettenprüfung, - klare Erfassungsregeln, - regelmäßige Datenbereinigung. --- **Namenskonventionen** Eine gute Namenskonvention unterstützt Eindeutigkeit. Mögliche Bestandteile: - Umgebung, - Standort, - Funktion, - Servicebezug, - laufende Nummer. Beispiele: - PRD-APP-PORTAL-01, - TST-DB-ERP-02, - BER-FW-STANDORT-01, - PRD-CERT-PORTAL-2026. Die Namenskonvention sollte einfach genug sein, damit sie konsequent genutzt wird. --- **Pflichtfelder und optionale Felder** Nicht jedes Feld sollte verpflichtend sein. Zu viele Pflichtfelder führen dazu, dass Benutzer falsche Werte eintragen, nur um den Datensatz speichern zu können. Sinnvolle Pflichtfelder können sein: - CI-Name, - CI-Typ, - Status, - Umgebung, - Owner oder Supportgruppe, - Servicezuordnung bei produktiven CIs. Optionale Felder können abhängig vom CI-Typ sein. Beispiel: Ein Zertifikat benötigt Ablaufdatum. Ein Drucker benötigt Standort. Eine Anwendung benötigt Version und Service Owner. --- **CMDB-Modell** Das CMDB-Modell beschreibt, welche CI-Typen, Attribute und Beziehungen verwendet werden. Zu klären ist: - Welche CI-Typen gibt es? - Welche Attribute sind notwendig? - Welche Beziehungen sind erlaubt? - Welche Felder sind Pflicht? - Welche Datenquellen werden genutzt? - Wer darf CIs erstellen? - Wer darf CIs ändern? - Wie werden Dubletten verhindert? - Wie wird Qualität geprüft? Ein einfaches, verstandenes Modell ist besser als ein komplexes Modell, das niemand pflegt. --- **Granularität** Granularität beschreibt, wie detailliert CIs erfasst werden. Beispiel: Sehr grob: - Service: Mitarbeiterportal Mittel: - Service, - Anwendung, - Webserver, - Datenbank, - Zertifikat. Sehr fein: - einzelne Konfigurationsdateien, - einzelne Firewall-Regeln, - einzelne Bibliotheken, - einzelne Schnittstellenparameter. Die richtige Granularität hängt vom Nutzen ab. Zu grob hilft bei technischer Analyse wenig. Zu fein ist schwer pflegbar. --- **Beispiel für passende Granularität** Für einen kritischen Webservice sinnvoll: - Service, - Anwendung, - Datenbank, - Server, - Load Balancer, - Zertifikat, - DNS, - Identity Provider, - Monitoring, - Backup, - wichtige Schnittstellen. Nicht immer sinnvoll: - jede einzelne Konfigurationszeile, - jede temporäre Datei, - jedes unkritische Testobjekt. Die CMDB soll Entscheidungen unterstützen, nicht jede technische Kleinigkeit abbilden. --- **CMDB-Lebenszyklus** Ein CI durchläuft einen Lebenszyklus. geplant ↓ erstellt oder beschafft ↓ in Betrieb genommen ↓ geändert ↓ regelmäßig geprüft ↓ außer Betrieb genommen ↓ archiviert oder gelöscht Die CMDB sollte diesen Lebenszyklus abbilden. Besonders wichtig ist die saubere Außerbetriebnahme. --- **Außerbetriebnahme von CIs** Vor dem Entfernen eines CIs sollte geprüft werden: - Welche Services nutzen das CI? - Gibt es noch aktive Beziehungen? - Gibt es offene Incidents oder Problems? - Gibt es geplante Changes? - Wird das CI noch überwacht? - Gibt es Backups oder Archivdaten? - Gibt es Lizenz- oder Vertragsbezug? - Muss Dokumentation angepasst werden? - Muss ein Lieferant informiert werden? Ein CI einfach zu löschen kann spätere Nachvollziehbarkeit zerstören. Oft ist Archivierung sinnvoller. --- **CMDB und Change-Prozess** Changes sollten CMDB-Daten aktualisieren. Beispiele: - neue Version nach Update, - neue Beziehung nach Schnittstellenänderung, - neues Zertifikat nach Erneuerung, - neuer Owner nach Übergabe, - neuer Status nach Außerbetriebnahme, - neue Cloud-Ressource nach Deployment, - neue Monitoringbeziehung nach Alarmregel. Wenn Changes die CMDB nicht aktualisieren, veraltet sie automatisch. --- **CMDB und Dokumentation** Die CMDB ersetzt nicht jede Dokumentation. Sie kann aber auf Dokumentation verweisen. Beispiele: - Betriebsrunbook, - Architekturdiagramm, - Notfallhandbuch, - Installationsanleitung, - Schnittstellendokumentation, - Lieferantenvertrag, - Sicherheitskonzept, - Backup- und Restore-Anleitung. Die CMDB zeigt, welche Dokumentation zu welchem CI oder Service gehört. --- **CMDB und Monitoring** Monitoring und CMDB sollten sich ergänzen. Monitoring zeigt: - Zustand, - Alarme, - Verfügbarkeit, - Performance, - Kapazität, - Fehlerereignisse. CMDB zeigt: - Servicezuordnung, - Kritikalität, - Owner, - Beziehungen, - Version, - Dokumentation. Beispiel: Monitoring meldet Ausfall eines Servers. Die CMDB zeigt, welche Services davon abhängen und wer informiert werden muss. --- **CMDB und Cloud** Cloud-Umgebungen verändern sich oft schnell. Herausforderungen: - Ressourcen entstehen automatisch, - Ressourcen werden schnell gelöscht, - Namen sind uneinheitlich, - Tags fehlen, - Owner sind unklar, - Kostenstellen fehlen, - Beziehungen sind dynamisch, - externe Dienste sind beteiligt. Für Cloud-Ressourcen sind klare Tags, automatisierte Erkennung und regelmäßige Prüfung besonders wichtig. --- **CMDB und Tags** Tags oder Labels können helfen, Cloud- und Plattformressourcen zuzuordnen. Mögliche Tags: - Service, - Umgebung, - Owner, - Kostenstelle, - Kritikalität, - Datenklasse, - Ablaufdatum, - Projekt, - Supportgruppe. Beispiel: | Tag | Wert | |---|---| | Service | Mitarbeiterportal | | Umgebung | Produktion | | Owner | Plattform-Team | | Kritikalität | hoch | | Datenklasse | intern | Tags ersetzen keine vollständige CMDB, können aber wichtige Daten liefern. --- **CMDB und Container** Auch Container-Umgebungen können CMDB-relevant sein. Mögliche CIs: - Container-Plattform, - Cluster, - Namespace, - Anwendung, - Image-Version, - Datenbank, - Volume, - Ingress, - Secret, - Zertifikat, - Monitoring, - Backupjob. Wichtig ist, nicht jeden kurzlebigen Container einzeln dauerhaft zu pflegen. Oft sind Service, Anwendung, Plattform, Version und Abhängigkeiten wichtiger als einzelne temporäre Instanzen. --- **CMDB und Schnittstellen** Schnittstellen werden oft vergessen. Dabei sind sie für Services kritisch. Zu erfassen sind: - Quellsystem, - Zielsystem, - Protokoll, - Authentifizierung, - Zertifikat, - Datenformat, - Owner, - Lieferant, - Kritikalität, - Monitoring, - bekannte Fehler, - Abhängigkeiten. Ein Schnittstellenfehler kann mehrere Services gleichzeitig betreffen. --- **CMDB und Zertifikate** Zertifikate sollten bei wichtigen Services als relevante CIs betrachtet werden. Sinnvolle Informationen: - Name, - betroffener Service, - Hostname, - Ablaufdatum, - Aussteller, - Owner, - Erneuerungsprozess, - Monitoring, - abhängige Systeme, - Dokumentationslink. Viele vermeidbare Incidents entstehen durch abgelaufene oder falsch erneuerte Zertifikate. --- **Berechtigungen und Gruppen als CIs** Auch Benutzergruppen oder Berechtigungskonzepte können CI-relevant sein. Beispiele: - Administratorgruppe, - Rollen für Fachanwendung, - VPN-Zugriffsgruppe, - MFA-Ausnahmegruppe, - Servicekonto, - API-Berechtigung. Solche CIs sind besonders wichtig für: - Sicherheit, - Change Enablement, - Audits, - Incident-Diagnose, - Berechtigungsprobleme, - und Compliance. --- **CMDB-Reports** Nützliche Reports können sein: - aktive produktive Services, - Services ohne Owner, - CIs ohne Servicezuordnung, - CIs ohne aktuelle Prüfung, - ablaufende Zertifikate, - veraltete Versionen, - kritische CIs ohne Monitoring, - Changes pro CI, - Incidents pro CI, - Known Errors pro Service, - CIs mit fehlenden Beziehungen. Reports sollen nicht nur Zahlen liefern. Sie sollen konkrete Verbesserungen ermöglichen. --- **CMDB-Einführung schrittweise beginnen** Eine CMDB sollte nicht zwingend sofort alles abbilden. Sinnvoller Start: 1. kritische Services auswählen 2. wichtigste CIs erfassen 3. zentrale Beziehungen dokumentieren 4. Owner festlegen 5. Change-Prozess anbinden 6. Datenqualität prüfen 7. Nutzung in Incident und Change etablieren 8. schrittweise erweitern Eine CMDB scheitert häufig, wenn zu Beginn zu viel auf einmal erfasst werden soll. --- **Minimal sinnvolle CMDB für kleine Umgebungen** Für kleine Umgebungen kann auch eine einfache Struktur ausreichen. Mögliche Mindestinformationen: - Service, - wichtige Komponenten, - Owner, - Umgebung, - Status, - Version, - wichtigste Abhängigkeiten, - Dokumentationslink, - letzter Change, - letzte Prüfung. Das kann auch in einem einfachen ITSM-Tool, Wiki oder einer strukturierten Tabelle beginnen. Wichtig ist Pflege und Nutzung. --- **Governance der CMDB** CMDB-Governance legt Regeln fest. Zu klären ist: - Wer ist für das CMDB-Modell verantwortlich? - Wer darf CIs erstellen? - Wer darf CIs ändern? - Wer prüft Datenqualität? - Welche Felder sind Pflicht? - Wie werden Dubletten behandelt? - Wie werden Changes eingebunden? - Wie oft werden kritische CIs geprüft? - Welche Reports werden genutzt? - Wie werden Fehler korrigiert? Ohne Governance wird eine CMDB schnell unzuverlässig. --- **Rollen im CMDB-Betrieb** Mögliche Rollen: | Rolle | Aufgabe | |---|---| | **Configuration Manager** | steuert Modell, Qualität und Regeln | | **Service Owner** | verantwortet Serviceinformationen | | **CI Owner** | verantwortet einzelne CIs | | **Supportgruppe** | nutzt und ergänzt Betriebsinformationen | | **Change Manager** | sorgt für Aktualisierung nach Changes | | **Security Team** | nutzt Daten für Sicherheitsbewertung | | **Asset Manager** | liefert Asset- und Vertragsdaten | Die Rollen müssen nicht überall als eigene Stellen existieren. Die Verantwortlichkeiten müssen aber klar sein. --- **Praxisbeispiel: Incident mit CMDB-Nutzen** **Situation** Mehrere Benutzer melden, dass das Mitarbeiterportal nicht erreichbar ist. **CMDB hilft durch:** - Servicezuordnung, - betroffene Anwendung, - Datenbankbeziehung, - Zertifikatsbeziehung, - letzter Change, - zuständige Supportgruppe, - Kritikalität des Services. **Ergebnis** Die Analyse konzentriert sich schneller auf Datenbank, Zertifikat und letzten Change. --- **Praxisbeispiel: Change mit CMDB-Nutzen** **Situation** Ein Datenbankserver soll aktualisiert werden. **CMDB zeigt:** - drei Anwendungen nutzen diesen Server, - eine Anwendung ist geschäftskritisch, - ein Lieferant muss für Test erreichbar sein, - Backupjob muss vor dem Change geprüft werden, - Service Desk muss informiert werden. **Ergebnis** Der Change wird nicht als isoliertes Serverupdate behandelt, sondern als Serviceänderung mit Abhängigkeiten. --- **Praxisbeispiel: Sicherheitslücke** **Situation** Eine kritische Schwachstelle betrifft eine bestimmte Softwareversion. **CMDB hilft durch:** - Liste betroffener Systeme, - Servicezuordnung, - Kritikalität, - Owner, - Umgebung, - externe Erreichbarkeit, - Patchstatus, - Changes zur Behebung. **Ergebnis** Patchpriorisierung wird schneller und nachvollziehbarer. --- **Praxisbeispiel: Abgelaufenes Zertifikat verhindern** **Situation** Mehrere Zertifikate wurden bisher nur in einzelnen Runbooks erwähnt. **Problem** Ablaufdaten wurden nicht zentral überwacht. **Verbesserung** Zertifikate werden als CIs erfasst mit: - Ablaufdatum, - Servicebezug, - Owner, - Monitoring, - Erneuerungsprozess, - Dokumentationslink. **Nutzen** Ausfälle durch abgelaufene Zertifikate werden besser vermeidbar. --- **Typische Fehler** **Fehler 1** CMDB wird als reine Inventarliste aufgebaut. --- **Fehler 2** Zu viele CIs werden erfasst, aber nicht gepflegt. --- **Fehler 3** Services und Beziehungen fehlen. --- **Fehler 4** Owner sind nicht definiert. --- **Fehler 5** Daten werden nicht durch Changes aktualisiert. --- **Fehler 6** Discovery-Daten werden ungeprüft übernommen. --- **Fehler 7** Dubletten und uneinheitliche Namen werden nicht bereinigt. --- **Fehler 8** CMDB wird im Incident- und Change-Prozess nicht genutzt. --- **Fehler 9** Kritikalität wird technisch statt servicebezogen bewertet. --- **Fehler 10** Cloud-Ressourcen, Zertifikate und Schnittstellen fehlen. --- **Fehler 11** Reports zeigen Probleme, aber niemand verfolgt Verbesserungen. --- **Fehler 12** CMDB-Ziel und Pflegeaufwand passen nicht zusammen. --- **Checkliste CMDB-Modell** - [ ] Ziel der CMDB ist klar - [ ] relevante Services sind definiert - [ ] CI-Typen sind festgelegt - [ ] Pflichtfelder sind definiert - [ ] Beziehungstypen sind festgelegt - [ ] Namenskonvention ist beschrieben - [ ] Rollen und Verantwortlichkeiten sind klar - [ ] Datenquellen sind bekannt - [ ] Datenqualitätsregeln sind definiert - [ ] Change-Prozess ist angebunden - [ ] Reporting ist festgelegt - [ ] regelmäßige Prüfung ist vorgesehen --- **Checkliste CMDB-Eintrag** - [ ] CI-Name eindeutig - [ ] CI-Typ korrekt - [ ] Status aktuell - [ ] Umgebung korrekt - [ ] Servicezuordnung vorhanden - [ ] Owner oder Supportgruppe eingetragen - [ ] Version oder Konfigurationsstand gepflegt - [ ] Kritikalität nachvollziehbar - [ ] Beziehungen gepflegt - [ ] Dokumentationslink vorhanden - [ ] letzte Änderung nachvollziehbar - [ ] letzte Prüfung dokumentiert --- **Checkliste Datenqualität** - [ ] keine Dubletten vorhanden - [ ] veraltete CIs archiviert - [ ] produktive CIs besitzen Owner - [ ] kritische CIs besitzen Servicebezug - [ ] wichtige Beziehungen sind gepflegt - [ ] Versionen sind aktuell - [ ] Statuswerte sind plausibel - [ ] Cloud-Ressourcen sind berücksichtigt - [ ] Zertifikate sind erfasst - [ ] Schnittstellen sind erfasst - [ ] Changes aktualisieren CMDB-Daten - [ ] Reports werden regelmäßig geprüft --- **Checkliste CMDB im Change nutzen** - [ ] betroffene CIs im Change verknüpft - [ ] abhängige Services geprüft - [ ] Owner identifiziert - [ ] Kritikalität bewertet - [ ] letzte Changes geprüft - [ ] parallele Changes geprüft - [ ] Dokumentationsbedarf erkannt - [ ] CMDB-Aktualisierung nach Change geplant - [ ] neue Beziehungen ergänzt - [ ] entfernte Beziehungen bereinigt --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker nutzen und pflegen CMDB-Daten im praktischen Betrieb. Wichtig ist: - Systeme eindeutig benennen, - produktive und nicht produktive Umgebungen unterscheiden, - Versionen und Konfigurationen sauber dokumentieren, - Abhängigkeiten erkennen, - Owner und Supportgruppen eintragen, - Changes mit CIs verknüpfen, - veraltete Daten melden, - und CMDB-Daten bei Incidents, Problems und Changes aktiv nutzen. Eine gute CMDB macht technische Arbeit nicht bürokratischer. Sie macht sie nachvollziehbarer, sicherer und schneller. --- **Zusammenfassung** > Ziel der CMDB festlegen > ↓ > relevante Services und CI-Typen bestimmen > ↓ > Attribute und Beziehungen definieren > ↓ > Datenquellen anbinden > ↓ > Owner und Pflegeverantwortung klären > ↓ > CIs und Beziehungen erfassen > ↓ > CMDB in Incident, Problem und Change nutzen > ↓ > Datenqualität regelmäßig prüfen > ↓ > CMDB schrittweise verbessern --- **Merksätze** > Eine CMDB ist nur wertvoll, wenn ihre Daten genutzt und gepflegt werden. > Beziehungen sind wichtiger als eine lange Liste einzelner Systeme. > Eine CMDB ersetzt keine Betriebsdokumentation, sie verknüpft relevante Informationen. > Discovery hilft bei Technik, ersetzt aber keine fachliche Verantwortung. > Jede relevante Änderung sollte auch die CMDB aktualisieren. > Schlechte CMDB-Daten können zu falschen Entscheidungen führen. > Klein anfangen und konsequent pflegen ist besser als groß planen und nicht aktuell halten. --- **Verwandte Seiten** - 6.1 Service Configuration Management – Ziele, Begriffe und Grundlagen - 6.2 Configuration Items und Beziehungen - 6.4 Discovery, Pflege und Datenqualität - 6.5 Service Configuration Management im Zusammenspiel mit Incident-, Problem- und Change-Management - Incident Management - Problem Management - Change Enablement - Release Management - Information Security Management - IT Asset Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Configuration Management - PeopleCert – ITIL Practice Guide: IT Asset Management - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Problem Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - CMDB-Inhalte, - Feldbeispiele, - Datenqualitätsregeln, - Rollen, - Checklisten, - Reports, - und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - CMDB-Struktur, - Pflichtfeldliste, - CI-Typenliste, - Beziehungsmatrix, - Namenskonvention, - Discovery-Pflicht, - oder konkrete Toolarchitektur für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Risiken, - Organisationsgröße, - Toollandschaft, - Datenqualität, - Supportmodell, - Sicherheitsanforderungen, - Change-Modell, - Cloud-Nutzung, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 6.4 Discovery, Pflege und Datenqualität > **Kurz erklärt** > > Discovery, Pflege und Datenqualität sorgen dafür, dass Configuration-Daten nicht nur einmal erfasst, sondern dauerhaft aktuell, korrekt und nutzbar bleiben. > > **Discovery** hilft, technische Informationen automatisch zu erkennen. > > **Pflege** sorgt dafür, dass fachliche, organisatorische und servicebezogene Informationen ergänzt und aktuell gehalten werden. > > **Datenqualität** entscheidet, ob Configuration-Daten im Betrieb wirklich verlässlich sind. --- **Warum dieses Thema wichtig ist** Eine CMDB oder ein Configuration Management System ist nur dann hilfreich, wenn die Daten stimmen. Veraltete oder falsche Configuration-Daten führen zu Problemen: - Incidents werden falsch priorisiert, - Changes werden mit falscher Auswirkungsbewertung geplant, - Problems werden nicht richtig eingegrenzt, - Owner sind nicht erreichbar, - Serviceabhängigkeiten fehlen, - Sicherheitslücken werden übersehen, - Zertifikate laufen ab, - Cloud-Ressourcen bleiben unbekannt, - und Dokumentation widerspricht der Realität. Datenqualität ist deshalb kein Nebenthema. Sie ist die Grundlage dafür, dass Service Configuration Management im Alltag funktioniert. --- **Discovery** Discovery bedeutet, technische Informationen automatisch oder halbautomatisch zu erkennen. Mögliche Discovery-Ergebnisse: - Server, - Clients, - Netzwerkgeräte, - virtuelle Maschinen, - Container-Plattformen, - Cloud-Ressourcen, - installierte Software, - Betriebssystemversionen, - IP-Adressen, - offene Dienste, - Zertifikate, - Datenbankinstanzen, - Schnittstellen, - Hardwareinformationen, - Speicher, - Netzwerkverbindungen, - und technische Abhängigkeiten. Discovery kann Daten schneller und regelmäßiger erfassen als rein manuelle Pflege. --- **Was Discovery leisten kann** Discovery kann helfen bei: - Erstbefüllung einer CMDB, - Erkennung unbekannter Systeme, - Aktualisierung technischer Daten, - Abgleich von Ist-Zustand und Soll-Zustand, - Erkennung veralteter Versionen, - Sicherheitsbewertung, - Audit-Vorbereitung, - Cloud-Transparenz, - Netzwerkübersicht, - und Datenqualitätsprüfung. Beispiel: Ein Discovery-Werkzeug erkennt, dass ein Server noch eine alte Softwareversion verwendet. Diese Information kann für Security, Change Enablement und Problem Management wichtig sein. --- **Was Discovery nicht automatisch leisten kann** Discovery erkennt Technik. Discovery versteht aber nicht automatisch den fachlichen Zusammenhang. Ein Discovery-Werkzeug erkennt vielleicht: - ein Server existiert, - ein Dienst läuft, - eine IP-Adresse ist erreichbar, - ein Zertifikat ist installiert, - eine Anwendung kommuniziert mit einer Datenbank. Es weiß aber nicht automatisch: - welcher Geschäftsprozess betroffen ist, - welcher Service Owner verantwortlich ist, - welche Kritikalität der Service besitzt, - ob eine Abweichung genehmigt ist, - ob ein System bald abgelöst wird, - welcher Lieferant verantwortlich ist, - oder welcher Workaround im Störungsfall gilt. Deshalb muss Discovery durch fachliche Pflege ergänzt werden. --- **Discovery und manuelle Pflege ergänzen sich** | Discovery | Manuelle oder organisatorische Pflege | |---|---| | erkennt technische Objekte | ergänzt fachliche Bedeutung | | erkennt Versionen und Eigenschaften | ergänzt Owner und Verantwortlichkeiten | | erkennt Verbindungen | bewertet Serviceabhängigkeiten | | erkennt neue Ressourcen | prüft, ob sie relevant sind | | erkennt Abweichungen | klärt, ob sie erlaubt sind | | liefert Ist-Daten | ergänzt Soll-Zustand und Kontext | Gute Configuration-Daten entstehen durch Kombination aus Automatisierung, Prozessen und Verantwortung. --- **Typische Discovery-Quellen** Mögliche Quellen für technische Erkennung: - Netzwerk-Scanner, - Monitoring-System, - Endpoint-Management, - Softwareverteilung, - Virtualisierungsplattform, - Cloud-Plattform, - Container-Plattform, - Verzeichnisdienst, - Zertifikatsverwaltung, - Backup-System, - Datenbankverwaltung, - Sicherheitswerkzeuge, - ITSM-System, - Asset-Management-System. Keine Quelle ist vollständig. Mehrere Quellen müssen oft abgeglichen werden. --- **Discovery in Cloud-Umgebungen** Cloud-Umgebungen verändern sich häufig schneller als klassische Rechenzentrumsumgebungen. Typische Herausforderungen: - Ressourcen werden automatisch erstellt, - Ressourcen werden schnell gelöscht, - Tags fehlen oder sind uneinheitlich, - Owner sind unklar, - Kostenstellen fehlen, - Testressourcen bleiben aktiv, - Dienste werden extern bereitgestellt, - Abhängigkeiten sind dynamisch. Wichtige Maßnahmen: - verbindliche Tags definieren, - Owner erfassen, - Umgebung kennzeichnen, - automatische Exporte nutzen, - Cloud-Ressourcen regelmäßig prüfen, - nicht genutzte Ressourcen bereinigen, - Sicherheitsklassifizierung ergänzen. --- **Discovery in Container-Umgebungen** In Container-Umgebungen entstehen und verschwinden technische Instanzen oft sehr schnell. Nicht jeder kurzlebige Container sollte dauerhaft als einzelnes CI gepflegt werden. Sinnvoller können sein: - Service, - Anwendung, - Namespace, - Cluster, - Deployment, - Image-Version, - Datenbank, - Volume, - Ingress, - Zertifikat, - Secret, - Monitoring, - Backupjob. Wichtig ist, servicebezogene Informationen zu erfassen, nicht jede temporäre Laufzeitinstanz dauerhaft zu dokumentieren. --- **Discovery und Sicherheitsbewertung** Discovery ist für Sicherheit besonders wichtig. Beispiele: - unbekannte Systeme erkennen, - veraltete Software finden, - offene Dienste prüfen, - externe Erreichbarkeit feststellen, - ablaufende Zertifikate identifizieren, - nicht genehmigte Cloud-Ressourcen erkennen, - nicht inventarisierte Geräte finden, - Systeme mit kritischen Schwachstellen priorisieren. Aber auch hier gilt: Discovery zeigt technische Tatsachen. Die Risikobewertung benötigt zusätzlich Kritikalität, Datenklasse, Servicebezug und Owner. --- **Discovery-Ergebnisse prüfen** Discovery-Daten sollten nicht ungeprüft übernommen werden. Zu prüfen ist: - Ist das erkannte Objekt wirklich relevant? - Ist es bereits als CI vorhanden? - Ist der Name eindeutig? - Ist die Umgebung korrekt? - Ist der Status korrekt? - Gibt es Dubletten? - Ist der Owner bekannt? - Gibt es einen Servicebezug? - Handelt es sich um ein temporäres Objekt? - Muss das Objekt dauerhaft gepflegt werden? Automatisierung ohne Prüfung kann die CMDB mit unbrauchbaren Daten füllen. --- **Datenpflege** Datenpflege bedeutet, Configuration-Daten aktuell und nutzbar zu halten. Dazu gehören: - neue CIs erfassen, - veränderte CIs aktualisieren, - entfernte CIs archivieren, - Beziehungen pflegen, - Owner aktualisieren, - Versionen korrigieren, - Dokumentationslinks prüfen, - Dubletten bereinigen, - Statuswerte anpassen, - und veraltete Einträge entfernen oder archivieren. Pflege ist keine einmalige Projektarbeit. Sie ist eine laufende Betriebsaufgabe. --- **Pflege durch Change Enablement** Changes sind eine der wichtigsten Quellen für CMDB-Aktualisierungen. Nach einem Change kann sich ändern: - Version, - Konfiguration, - Beziehung, - Status, - Umgebung, - Owner, - Lieferant, - Zertifikat, - Schnittstelle, - Monitoring, - Backup, - Dokumentation. Deshalb sollte jeder relevante Change prüfen: > Müssen Configuration-Daten aktualisiert werden? Wenn Changes die CMDB nicht pflegen, veraltet sie automatisch. --- **Pflege durch Release und Deployment** Nach Releases und Deployments ändern sich häufig: - Anwendungsversionen, - Zielumgebungen, - Infrastrukturkomponenten, - Schnittstellen, - Datenbankversionen, - Konfigurationsstände, - Container-Images, - Dokumentation, - Known Errors, - Monitoringregeln. Release- und Deployment-Prozesse sollten deshalb CMDB-Aktualisierung als Abschlussaufgabe enthalten. --- **Pflege durch Incident und Problem Management** Incident und Problem Management können Datenfehler sichtbar machen. Beispiele: - falscher Owner im Incident, - fehlende Servicebeziehung, - veraltete Version, - nicht dokumentierte Schnittstelle, - fehlender Known Error, - nicht erfasstes Zertifikat, - falsche Kritikalität, - fehlender Dokumentationslink. Solche Erkenntnisse sollten nicht im Ticket verschwinden. Sie sollten zur Verbesserung der Configuration-Daten genutzt werden. --- **Pflege durch Service Owner** Service Owner sind wichtig für fachliche Informationen. Sie können prüfen: - stimmt die Servicebeschreibung, - stimmt die Kritikalität, - stimmt der Geschäftsprozessbezug, - stimmen Supportzeiten, - stimmen Benutzergruppen, - stimmen Lieferanten, - sind Abhängigkeiten vollständig, - sind Dokumentationslinks aktuell, - sind Risiken korrekt bewertet. Technische Teams kennen oft die Komponenten. Service Owner kennen den fachlichen Wert und die Auswirkung. --- **Pflege durch technische Teams** Technische Teams pflegen vor allem technische Informationen. Beispiele: - Versionen, - Konfigurationsstände, - Plattformen, - Server, - Datenbanken, - Netzwerkkomponenten, - Zertifikate, - Backupjobs, - Monitoringregeln, - Schnittstellen, - Betriebshandbücher. Wichtig ist, dass technische Änderungen nicht nur umgesetzt, sondern auch nachvollziehbar dokumentiert werden. --- **Pflegeintervalle** Nicht alle Configuration-Daten müssen gleich häufig geprüft werden. Mögliche Prüfintervalle: | CI oder Information | mögliches Prüfintervall | |---|---| | geschäftskritischer Service | regelmäßig und nach jedem relevanten Change | | Zertifikate | automatisch überwachen und regelmäßig prüfen | | produktive Server | nach Changes und in festen Reviews | | Cloud-Ressourcen | häufig oder automatisiert | | Dokumentationslinks | regelmäßig oder nach Releases | | Testsysteme | nach Bedarf | | archivierte CIs | selten, aber nachvollziehbar | Die Häufigkeit sollte sich nach Risiko, Kritikalität und Änderungsdynamik richten. --- **Datenqualität** Datenqualität beschreibt, ob Configuration-Daten für den vorgesehenen Zweck geeignet sind. Wichtige Qualitätsmerkmale: - korrekt, - aktuell, - vollständig genug, - eindeutig, - konsistent, - nachvollziehbar, - auffindbar, - verantwortet, - und nutzbar. Perfekte Vollständigkeit ist selten realistisch. Entscheidend ist, dass die Daten für Incident, Problem, Change, Release und Security Management ausreichend zuverlässig sind. --- **Korrektheit** Korrektheit bedeutet: > Die Information stimmt mit der Realität überein. Beispiele: - Version ist richtig, - Owner ist richtig, - Status ist richtig, - Servicezuordnung ist richtig, - Beziehung ist richtig. Falsche Daten sind gefährlich. Beispiel: Die CMDB zeigt einen Server als Testsystem, obwohl er produktiv genutzt wird. Ein Change wird dadurch zu niedrig bewertet. --- **Aktualität** Aktualität bedeutet: > Die Information ist nicht veraltet. Beispiele für veraltete Daten: - alter Owner, - alte Version, - außer Betrieb genommener Server ist noch aktiv, - neues Zertifikat fehlt, - Cloud-Ressource wurde gelöscht, - Schnittstelle wurde geändert, - Dokumentationslink zeigt auf alte Anleitung. Aktualität entsteht durch Anbindung an Changes, Releases, Reviews und Discovery. --- **Vollständigkeit** Vollständigkeit bedeutet nicht, jedes Detail zu erfassen. Sie bedeutet: > Die für den Zweck notwendigen Informationen sind vorhanden. Beispiel: Für einen kritischen Service sollten mindestens vorhanden sein: - Service Owner, - technische Supportgruppe, - wichtigste CIs, - zentrale Abhängigkeiten, - Kritikalität, - Dokumentation, - Notfallinformationen, - und relevante Lieferanten. Ein unwichtiger Testdienst benötigt weniger Detailtiefe. --- **Eindeutigkeit** Eindeutigkeit bedeutet: > Jedes CI ist klar identifizierbar. Probleme entstehen durch: - doppelte Einträge, - unterschiedliche Schreibweisen, - unklare Namen, - fehlende IDs, - unklare Umgebungen, - ähnliche Systemnamen. Beispiel: - APP01 - app01 - Portal-App-Server - PRD-APP-PORTAL-01 könnten dasselbe CI beschreiben. Solche Dubletten erschweren Reports, Changes und Incidents. --- **Konsistenz** Konsistenz bedeutet: > Daten folgen einheitlichen Regeln. Beispiele: - gleiche Statuswerte, - gleiche CI-Typen, - einheitliche Namenskonvention, - klare Beziehungstypen, - einheitliche Umgebungsbezeichnungen, - definierte Pflichtfelder. Ungeeignet: - Produktion, - Prod, - PRD, - Live werden ohne Regel gemischt. Besser: > Eine definierte Schreibweise wird verbindlich genutzt. --- **Nachvollziehbarkeit** Nachvollziehbarkeit bedeutet: > Es ist erkennbar, woher eine Information kommt und warum sie geändert wurde. Hilfreich sind: - letzter Änderungszeitpunkt, - letzter Prüftermin, - verknüpfter Change, - verantwortliche Person oder Gruppe, - Datenquelle, - Kommentar zur Abweichung, - Archivierung statt unkontrollierter Löschung. Nachvollziehbarkeit ist besonders wichtig bei Sicherheitsfragen, Audits und Major Incidents. --- **Nutzbarkeit** Daten sind nur wertvoll, wenn sie genutzt werden können. Nutzbarkeit bedeutet: - Informationen sind auffindbar, - Felder sind verständlich, - Beziehungen sind sichtbar, - Reports sind sinnvoll, - Daten passen zu Prozessen, - Teams vertrauen den Informationen, - Pflegeaufwand ist realistisch. Eine CMDB mit vielen Feldern, die niemand versteht oder nutzt, erzeugt keinen Mehrwert. --- **Datenqualitätsregeln** Eine Organisation sollte Datenqualitätsregeln definieren. Beispiele: - produktive CIs benötigen Owner, - produktive CIs benötigen Servicezuordnung, - kritische Services benötigen dokumentierte Abhängigkeiten, - Zertifikate benötigen Ablaufdatum und Owner, - Changes müssen betroffene CIs verknüpfen, - außer Betrieb genommene CIs werden archiviert, - Dubletten werden regelmäßig bereinigt, - Cloud-Ressourcen benötigen Tags. Solche Regeln müssen kontrollierbar sein. --- **Datenqualitätskennzahlen** Mögliche Kennzahlen: | Kennzahl | Aussage | |---|---| | CIs ohne Owner | Verantwortlichkeit fehlt | | CIs ohne Servicezuordnung | Servicebezug unklar | | kritische Services ohne Abhängigkeiten | Auswirkungsanalyse unvollständig | | CIs ohne letzte Prüfung | Aktualität unsicher | | ablaufende Zertifikate ohne Owner | hohes Betriebsrisiko | | Dublettenquote | Eindeutigkeit schlecht | | Changes ohne CI-Verknüpfung | CMDB wird im Change-Prozess nicht genutzt | | Incidents ohne CI-Verknüpfung | Trendanalyse erschwert | Kennzahlen sollten nicht nur gemessen werden. Sie müssen zu Verbesserungen führen. --- **Datenqualitätsberichte** Datenqualitätsberichte können regelmäßig zeigen: - welche CIs unvollständig sind, - welche Owner fehlen, - welche Beziehungen fehlen, - welche CIs lange nicht geprüft wurden, - welche Zertifikate bald ablaufen, - welche Versionen veraltet sind, - welche Changes keine CIs verknüpft haben, - welche Services keine Abhängigkeiten besitzen. Solche Berichte sollten Verantwortliche und nächste Schritte enthalten. Nur eine Fehlerliste reicht nicht aus. --- **Dubletten bereinigen** Dubletten entstehen leicht durch manuelle Pflege, Discovery oder unterschiedliche Datenquellen. Vorgehen: 1. mögliche Dubletten erkennen 2. prüfen, ob es wirklich dasselbe CI ist 3. führenden Datensatz festlegen 4. Beziehungen zusammenführen 5. verknüpfte Incidents, Problems und Changes prüfen 6. Dublette archivieren oder löschen 7. Ursache der Dublette beheben Wichtig ist, nicht versehentlich unterschiedliche CIs zusammenzuführen. --- **Veraltete CIs archivieren** Nicht mehr aktive CIs sollten nicht einfach unkontrolliert gelöscht werden. Besser ist oft: - Status auf außer Betrieb setzen, - Beziehungen prüfen, - offene Incidents oder Changes prüfen, - Dokumentation verknüpft lassen, - Archivierungsdatum erfassen, - Grund der Außerbetriebnahme dokumentieren. So bleibt Nachvollziehbarkeit erhalten. Das ist besonders wichtig bei Audits, Sicherheitsvorfällen oder späteren Analysen. --- **Abweichungen erkennen** Abweichungen zwischen CMDB und Realität können entstehen durch: - ungeplante Changes, - manuelle Änderungen, - Notfallmaßnahmen, - nicht dokumentierte Deployments, - fehlerhafte Discovery, - Cloud-Automatisierung, - Lieferantenänderungen, - Schatten-IT, - vergessene Außerbetriebnahmen. Abweichungen sollten nicht nur korrigiert werden. Es sollte geprüft werden, warum sie entstanden sind. --- **Soll-Zustand und Ist-Zustand unterscheiden** | Zustand | Bedeutung | |---|---| | **Soll-Zustand** | freigegebener oder erwarteter Zustand | | **Ist-Zustand** | tatsächlich erkannter Zustand | | **Abweichung** | Unterschied zwischen Soll und Ist | Beispiel: Soll-Zustand: > Server nutzt Version 5.9. Ist-Zustand: > Discovery erkennt Version 5.8. Mögliche Ursachen: - Update fehlgeschlagen, - CMDB nicht aktualisiert, - falscher Server gescannt, - Rollback wurde durchgeführt, - Change nicht dokumentiert. --- **Configuration Drift** Configuration Drift bedeutet, dass Systeme im Laufe der Zeit vom gewünschten Zustand abweichen. Ursachen: - manuelle Änderungen, - Hotfixes, - ungeplante Anpassungen, - unterschiedliche Skriptversionen, - nicht dokumentierte Changes, - Lieferantenarbeiten, - fehlende Automatisierung, - fehlende Kontrolle. Folgen: - Tests werden unzuverlässig, - Deployments schlagen fehl, - Sicherheitslücken entstehen, - Incidents werden schwerer analysiert, - Rollback wird schwieriger. Baselines und regelmäßige Prüfungen helfen gegen Configuration Drift. --- **Baselines nutzen** Eine Configuration Baseline beschreibt einen bekannten, freigegebenen Zustand. Beispiele: - Standardserverkonfiguration, - genehmigte Anwendungsversion, - geprüfte Firewall-Regelbasis, - Standardclient, - freigegebene Cloud-Tag-Struktur, - definierter Release-Stand. Baselines helfen bei: - Vergleich mit aktuellem Zustand, - Fehleranalyse, - Rollback, - Audit, - Standardisierung, - Sicherheitsprüfung. Wenn ein System von der Baseline abweicht, sollte dokumentiert sein, warum. --- **Pflegeverantwortung** Ohne Verantwortung veraltet Configuration Management. Zu klären ist: - Wer ist für das CMDB-Modell verantwortlich? - Wer pflegt technische Daten? - Wer pflegt Serviceinformationen? - Wer prüft Datenqualität? - Wer bereinigt Dubletten? - Wer kontrolliert Reports? - Wer aktualisiert Daten nach Changes? - Wer genehmigt Modelländerungen? - Wer ist Ansprechpartner bei Datenfehlern? Verantwortung kann auf mehrere Rollen verteilt sein. Sie muss aber eindeutig sein. --- **Rollen bei der Datenpflege** | Rolle | mögliche Aufgabe | |---|---| | **Configuration Manager** | Regeln, Modell und Datenqualität steuern | | **Service Owner** | Servicebezug, Kritikalität und fachliche Daten prüfen | | **CI Owner** | einzelne CIs verantworten | | **Supportgruppe** | technische Informationen ergänzen | | **Change Manager** | CMDB-Aktualisierung nach Changes sicherstellen | | **Security Team** | sicherheitsrelevante Daten nutzen und prüfen | | **Asset Manager** | Asset-, Vertrags- und Lebenszyklusdaten liefern | Die Rollen müssen nicht immer eigene Stellen sein. Wichtig sind klare Zuständigkeiten. --- **Pflege durch Prozesse erzwingen** Datenpflege funktioniert besser, wenn sie in Prozesse eingebaut ist. Beispiele: - Change kann nicht abgeschlossen werden, ohne betroffene CIs zu prüfen. - Release-Abschluss enthält CMDB-Aktualisierung. - Incident-Kategorien verlangen Servicezuordnung. - Zertifikate benötigen Owner und Ablaufdatum. - Cloud-Ressourcen ohne Pflicht-Tags werden gemeldet. - Außerbetriebnahme verlangt Abhängigkeitsprüfung. Datenpflege sollte nicht nur auf freiwilliger Erinnerung beruhen. --- **Pflegeaufwand realistisch halten** Zu viel Detailtiefe führt zu Pflegeproblemen. Fragen zur Begrenzung: - Wird dieses Feld wirklich genutzt? - Wer pflegt es? - Wie oft ändert es sich? - Kann es automatisiert werden? - Hilft es bei Incident, Problem, Change oder Security? - Ist es für einen kritischen Service notwendig? - Entsteht durch fehlende Information ein echtes Risiko? Daten, die niemand nutzt und niemand pflegt, sollten kritisch hinterfragt werden. --- **Toolunterstützung** Tools können unterstützen durch: - Pflichtfelder, - Workflows, - Discovery-Import, - Dublettenprüfung, - Beziehungsansichten, - Reports, - Erinnerungen, - Datenqualitätsregeln, - Rollenrechte, - Schnittstellen zu Monitoring und Cloud, - Verknüpfung mit Incidents und Changes. Ein Tool löst aber kein organisatorisches Problem. Ohne klare Regeln und Verantwortung wird auch ein gutes Tool schlechte Daten enthalten. --- **Integration mit ITSM-Prozessen** Configuration-Daten sollten nicht isoliert gepflegt werden. Sie sollten aktiv genutzt werden in: - Incident Management, - Problem Management, - Change Enablement, - Release Management, - Service Level Management, - Information Security Management, - IT Asset Management, - Continual Improvement. Je häufiger die Daten im Alltag genutzt werden, desto eher fallen Fehler auf. Ungenutzte Daten veralten schneller. --- **Datenqualität durch Nutzung verbessern** Wenn Service Desk und Fachteams CMDB-Daten aktiv nutzen, werden Fehler sichtbar. Beispiele: - falscher Owner wird bei Eskalation bemerkt, - fehlende Beziehung fällt bei Change-Bewertung auf, - veraltete Version fällt bei Security-Prüfung auf, - fehlender Dokumentationslink fällt im Incident auf. Wichtig ist, dass solche Fehler einfach gemeldet und korrigiert werden können. --- **Praxisbeispiel: Discovery findet unbekannten Server** **Situation** Discovery erkennt einen Server, der nicht in der CMDB steht. **Prüfung** - Ist der Server produktiv? - Welcher Service nutzt ihn? - Wer ist Owner? - Warum wurde er nicht erfasst? - Gibt es Sicherheitsrisiken? - Gibt es offene Ports? - Muss ein Change oder Problem erstellt werden? **Ergebnis** Der Server wird entweder als CI aufgenommen oder kontrolliert außer Betrieb genommen. --- **Praxisbeispiel: Falscher Owner** **Situation** Ein Incident betrifft eine Anwendung. Die CMDB nennt ein Team, das seit Monaten nicht mehr zuständig ist. **Folge** Eskalation verzögert sich. **Verbesserung** - Owner wird korrigiert, - ähnliche Services werden geprüft, - regelmäßige Owner-Reviews werden eingeführt, - Change-Übergaben müssen künftig Owner aktualisieren. --- **Praxisbeispiel: Veraltete Version** **Situation** Die CMDB zeigt Version 5.9. Discovery erkennt Version 5.8. **Mögliche Ursachen** - Update wurde nicht durchgeführt, - Rollback wurde nicht dokumentiert, - CMDB wurde zu früh aktualisiert, - Discovery scannt falsches System, - mehrere ähnliche CIs existieren. **Verbesserung** Abweichung wird geprüft, korrigiert und mit Change Record verknüpft. --- **Praxisbeispiel: Fehlende Zertifikatsdaten** **Situation** Ein produktives Zertifikat läuft ab. In der CMDB ist kein Ablaufdatum gepflegt. **Folge** Anmeldedienst fällt aus. **Verbesserung** - Zertifikate als eigene CIs erfassen, - Ablaufdatum verpflichtend machen, - Owner festlegen, - Monitoring für Ablaufdaten einführen, - Erneuerungs-Runbook verknüpfen. --- **Praxisbeispiel: Cloud-Ressource ohne Tags** **Situation** Cloud-Report zeigt mehrere Ressourcen ohne Service-Tag. **Risiko** - Kostenstelle unklar, - Owner unbekannt, - Kritikalität unbekannt, - Sicherheitsbewertung schwierig, - Außerbetriebnahme riskant. **Verbesserung** - Pflicht-Tags definieren, - Erstellung ohne Tags technisch verhindern oder melden, - Ressourcen nachträglich zuordnen, - Verantwortliche benennen. --- **Typische Fehler** **Fehler 1** Discovery-Daten werden ungeprüft in die CMDB übernommen. --- **Fehler 2** Manuelle Pflege wird niemandem eindeutig zugeordnet. --- **Fehler 3** CMDB wird einmal aufgebaut und danach nicht gepflegt. --- **Fehler 4** Changes aktualisieren Configuration-Daten nicht. --- **Fehler 5** Dubletten werden ignoriert. --- **Fehler 6** Datenqualitätsberichte werden erstellt, aber nicht bearbeitet. --- **Fehler 7** Zu viele Felder werden gepflegt, obwohl sie niemand nutzt. --- **Fehler 8** Wichtige Beziehungen fehlen trotz vieler technischer Details. --- **Fehler 9** Cloud- und Container-Ressourcen werden nicht berücksichtigt. --- **Fehler 10** Zertifikate, Schnittstellen und Benutzergruppen werden vergessen. --- **Fehler 11** Owner und Kritikalität werden nicht regelmäßig geprüft. --- **Fehler 12** Teams vertrauen der CMDB nicht mehr, weil Fehler nicht korrigiert werden. --- **Checkliste Discovery** - [ ] relevante Datenquellen festgelegt - [ ] Discovery-Bereich definiert - [ ] erkannte Objekte geprüft - [ ] Dublettenprüfung durchgeführt - [ ] Servicebezug ergänzt - [ ] Owner ergänzt - [ ] Umgebung geprüft - [ ] Status geprüft - [ ] technische Versionen übernommen - [ ] fachliche Kritikalität ergänzt - [ ] Sicherheitsrelevanz geprüft - [ ] nicht relevante Objekte ausgeschlossen oder archiviert --- **Checkliste Datenpflege** - [ ] neue CIs werden erfasst - [ ] geänderte CIs werden aktualisiert - [ ] entfernte CIs werden archiviert - [ ] Owner werden gepflegt - [ ] Versionen werden aktualisiert - [ ] Beziehungen werden gepflegt - [ ] Dokumentationslinks werden geprüft - [ ] Zertifikate werden überwacht - [ ] Cloud-Tags werden geprüft - [ ] Changes aktualisieren CMDB-Daten - [ ] Releases aktualisieren CMDB-Daten - [ ] Datenfehler können einfach gemeldet werden --- **Checkliste Datenqualität** - [ ] produktive CIs haben Owner - [ ] produktive CIs haben Servicezuordnung - [ ] kritische Services haben Abhängigkeiten - [ ] CIs haben eindeutige Namen - [ ] Dubletten werden bereinigt - [ ] Statuswerte sind aktuell - [ ] Versionen sind korrekt - [ ] Umgebungen sind eindeutig - [ ] Zertifikate besitzen Ablaufdatum - [ ] Dokumentationslinks funktionieren - [ ] letzte Prüfung ist dokumentiert - [ ] Datenqualitätsberichte werden bearbeitet --- **Checkliste nach Changes** - [ ] betroffene CIs geprüft - [ ] neue CIs angelegt - [ ] entfernte CIs archiviert - [ ] Versionen aktualisiert - [ ] Beziehungen aktualisiert - [ ] Owner geprüft - [ ] Dokumentationslinks aktualisiert - [ ] Monitoringbeziehungen geprüft - [ ] Backupbeziehungen geprüft - [ ] Known Errors aktualisiert, falls relevant - [ ] Service Map aktualisiert - [ ] Change Record mit CMDB verknüpft --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker tragen stark zur Datenqualität bei. Im Alltag bedeutet das: - technische Änderungen nicht nur ausführen, sondern dokumentieren, - Versionen und Konfigurationen korrekt erfassen, - falsche CMDB-Daten melden, - Owner und Servicebezug prüfen, - Discovery-Ergebnisse fachlich einordnen, - nach Changes Beziehungen aktualisieren, - Zertifikate, Schnittstellen und Monitoring berücksichtigen, - und Datenqualität als Teil stabilen Betriebs verstehen. Eine gute CMDB entsteht nicht allein durch ein Tool. Sie entsteht durch saubere technische Arbeit, klare Prozesse und konsequente Pflege. --- **Zusammenfassung** > technische Daten durch Discovery erkennen > ↓ > Ergebnisse prüfen und Dubletten vermeiden > ↓ > fachliche Informationen ergänzen > ↓ > Owner, Servicebezug und Kritikalität pflegen > ↓ > Changes und Releases zur Aktualisierung nutzen > ↓ > Datenqualität regelmäßig messen > ↓ > Abweichungen korrigieren > ↓ > Pflegeaufwand realistisch halten > ↓ > Configuration-Daten aktiv in ITSM-Prozessen nutzen --- **Merksätze** > Discovery erkennt Technik, aber nicht automatisch fachliche Bedeutung. > Datenpflege ist eine laufende Betriebsaufgabe, kein einmaliges Projekt. > Eine CMDB veraltet automatisch, wenn Changes sie nicht aktualisieren. > Datenqualität ist wichtiger als Datenmenge. > Schlechte Configuration-Daten können zu falschen Entscheidungen führen. > Je häufiger Daten im Alltag genutzt werden, desto schneller fallen Fehler auf. > Gute Datenqualität braucht Toolunterstützung, Prozesse und Verantwortung. --- **Verwandte Seiten** - 6.1 Service Configuration Management – Ziele, Begriffe und Grundlagen - 6.2 Configuration Items und Beziehungen - 6.3 Configuration Management Database - 6.5 Service Configuration Management im Zusammenspiel mit Incident-, Problem- und Change-Management - Change Enablement - Release Management - Incident Management - Problem Management - Information Security Management - IT Asset Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Configuration Management - PeopleCert – ITIL Practice Guide: IT Asset Management - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Release Management - PeopleCert – ITIL Practice Guide: Information Security Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - Discovery-Beispiele, - Datenqualitätsregeln, - Pflegeprozesse, - Prüffragen, - Checklisten, - Datenqualitätskennzahlen, - und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Discovery-Methode, - Datenqualitätskennzahl, - Pflegefrequenz, - Pflichtfeldstruktur, - Toolintegration, - oder CMDB-Governance-Struktur für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Risiken, - Organisationsgröße, - Toollandschaft, - Datenquellen, - Cloud-Nutzung, - Sicherheitsanforderungen, - Change-Modell, - Supportmodell, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 6.5 Service Configuration Management im Zusammenspiel mit Incident-, Problem- und Change-Management > **Kurz erklärt** > > Service Configuration Management liefert wichtige Informationen über Services, Configuration Items, Versionen, Verantwortlichkeiten und Abhängigkeiten. > > Diese Informationen werden besonders in Incident Management, Problem Management und Change Enablement benötigt. > > Ohne aktuelle Configuration-Daten werden Störungen langsamer analysiert, Ursachen schwerer erkannt und Changes riskanter bewertet. --- **Warum das Zusammenspiel wichtig ist** Configuration-Daten sind keine reine Dokumentation. Sie unterstützen tägliche Entscheidungen im IT-Betrieb. Beispiele: - Welcher Service ist von einer Störung betroffen? - Welche Systeme hängen von einer Datenbank ab? - Wer ist Owner eines betroffenen Configuration Items? - Welche Changes wurden zuletzt an einem System durchgeführt? - Welche Version ist installiert? - Welche Services nutzen ein bestimmtes Zertifikat? - Welche Benutzergruppen sind betroffen? - Welche Lieferanten müssen eingebunden werden? - Welche Abhängigkeiten müssen vor einem Change geprüft werden? Service Configuration Management liefert die Informationsbasis. Incident, Problem und Change Management nutzen diese Informationen für Analyse, Bewertung und Steuerung. --- **Grundidee des Zusammenspiels** Service Configuration Management ↓ liefert Services, CIs, Beziehungen, Owner und Versionen ↓ Incident Management nutzt diese Daten für schnelle Diagnose ↓ Problem Management nutzt diese Daten für Ursachenanalyse ↓ Change Enablement nutzt diese Daten für Auswirkungs- und Risikobewertung ↓ Changes, Incidents und Problems liefern neue Erkenntnisse zurück ↓ Configuration-Daten werden aktualisiert und verbessert Der Kreislauf funktioniert nur, wenn Configuration-Daten gepflegt und aktiv genutzt werden. --- **Zusammenspiel mit Incident Management** Incident Management benötigt Configuration-Daten, um Störungen schneller einzuordnen. Wichtige Fragen: - Welcher Service ist betroffen? - Welche CIs gehören zum Service? - Welche Abhängigkeiten bestehen? - Wer ist zuständig? - Welche Kritikalität besitzt der Service? - Welche Changes wurden zuletzt durchgeführt? - Gibt es Known Errors? - Welche anderen Services könnten betroffen sein? - Welche Dokumentation oder Runbooks sind verknüpft? Je besser diese Informationen verfügbar sind, desto schneller kann der Incident bearbeitet werden. --- **Incident Management liefert Informationen zurück** Incidents können zeigen, dass Configuration-Daten falsch oder unvollständig sind. Beispiele: - falscher Owner im Ticket, - fehlende Servicezuordnung, - unbekannte Abhängigkeit, - nicht erfasstes Zertifikat, - veraltete Version, - falscher CI-Status, - fehlender Dokumentationslink, - nicht dokumentierte Schnittstelle. Diese Erkenntnisse sollten nicht im Incident verschwinden. Sie sollten genutzt werden, um die CMDB oder das Configuration Management System zu verbessern. --- **Beispiel: Incident mit fehlender Beziehung** **Situation** Benutzer melden, dass das Mitarbeiterportal nicht erreichbar ist. **Analyse** Der Webserver ist erreichbar. Die Anwendung kann sich aber nicht mit der Datenbank verbinden. **Problem** In der CMDB war die Datenbankbeziehung nicht gepflegt. **Folge** Die Diagnose dauert länger. **Verbesserung** Die Beziehung zwischen Mitarbeiterportal, Anwendung, Datenbank, Storage und Backup wird nachgetragen. --- **Zusammenspiel mit Problem Management** Problem Management nutzt Configuration-Daten, um Ursachen und Muster zu erkennen. Wichtige Fragen: - Betreffen mehrere Incidents dasselbe CI? - Gibt es eine gemeinsame Abhängigkeit? - Ist eine bestimmte Version auffällig? - Sind bestimmte Standorte oder Netzwerkkomponenten betroffen? - Gibt es mehrere Services mit gleichem Zertifikat? - Gibt es bekannte Lieferantenprobleme? - Wurden ähnliche Problems bereits dokumentiert? - Gibt es offene Known Errors? Configuration-Daten helfen, einzelne Incidents in einen größeren Zusammenhang einzuordnen. --- **Problem Management liefert Informationen zurück** Problem Management kann Configuration-Daten verbessern. Beispiele: - neue CI-Beziehung wird erkannt, - Known Error wird mit CI verknüpft, - fehlerhafte Version wird dokumentiert, - gemeinsame Abhängigkeit wird sichtbar, - fehlender Owner wird erkannt, - Zertifikat wird als eigenes CI aufgenommen, - Schnittstelle wird nachträglich dokumentiert, - Service Map wird ergänzt. Eine Ursachenanalyse sollte deshalb auch prüfen, ob Configuration-Daten angepasst werden müssen. --- **Beispiel: Problem durch gemeinsame Abhängigkeit** **Situation** Drei Anwendungen erzeugen ähnliche Fehlermeldungen. **Einzelbetrachtung** Jedes Team untersucht zunächst seine eigene Anwendung. **Configuration-Daten zeigen** - alle Anwendungen nutzen denselben Datenbankcluster, - der Datenbankcluster nutzt denselben Storage, - Storage zeigt erhöhte Latenz. **Ergebnis** Problem Management erkennt eine gemeinsame Ursache schneller. **Verbesserung** Die Serviceabhängigkeiten werden in der CMDB klarer gepflegt. --- **Zusammenspiel mit Change Enablement** Change Enablement benötigt Configuration-Daten für die Auswirkungs- und Risikobewertung. Wichtige Fragen: - Welche CIs werden geändert? - Welche Services hängen davon ab? - Welche Benutzer oder Standorte sind betroffen? - Welche Owner müssen eingebunden werden? - Welche Lieferanten sind beteiligt? - Welche Versionen sind betroffen? - Welche Sicherheitsrisiken entstehen? - Welche anderen Changes betreffen dieselben CIs? - Welche Tests sind erforderlich? - Welche Dokumentation muss aktualisiert werden? Ohne Configuration-Daten wird ein Change schnell zu niedrig bewertet. --- **Change Enablement liefert Informationen zurück** Changes verändern Configuration-Daten. Beispiele: - neue Version, - neue Anwendung, - neue Schnittstelle, - neue Cloud-Ressource, - geänderte Firewall-Regel, - erneuertes Zertifikat, - geänderte Datenbank, - neuer Owner, - außer Betrieb genommenes System, - geänderte Monitoringregel. Nach einem Change muss geprüft werden: > Welche Configuration-Daten müssen aktualisiert werden? Wenn Changes die CMDB nicht aktualisieren, veraltet sie automatisch. --- **Beispiel: Change mit unvollständiger Auswirkungsbewertung** **Situation** Eine Firewall-Regel wird geändert. **Annahme** Nur eine kleine technische Anpassung. **Tatsächliche Auswirkung** Die Regel betrifft eine Schnittstelle zwischen Warenwirtschaft und Versand. Nach dem Change können Aufträge nicht mehr übertragen werden. **Ursache** Die Beziehung zwischen Firewall-Regel, Schnittstelle und Geschäftsprozess war nicht dokumentiert. **Verbesserung** Schnittstellen und Firewall-Abhängigkeiten werden als relevante CIs und Beziehungen gepflegt. --- **Configuration-Daten im Change Request** Ein Change Request sollte relevante Configuration-Daten enthalten. Dazu gehören: - betroffene CIs, - betroffene Services, - Umgebung, - Kritikalität, - Owner, - Supportgruppe, - Version, - Beziehungen, - letzte Changes, - Dokumentationslinks, - bekannte Problems, - Known Errors, - Sicherheitsklassifizierung, - und betroffene Lieferanten. So wird aus einer technischen Änderung eine bewertbare Serviceänderung. --- **Zusammenspiel mit Release und Deployment Management** Release und Deployment Management benötigen Configuration-Daten für kontrollierte Bereitstellung. Wichtige Fragen: - Welche Version wird deployed? - Welche Zielumgebung ist betroffen? - Welche Komponenten gehören zum Release? - Welche Abhängigkeiten bestehen? - Welche Schnittstellen müssen funktionieren? - Welche Services sind betroffen? - Welche Knowledge-Artikel müssen aktualisiert werden? - Welche CIs erhalten einen neuen Status? - Welche CMDB-Daten ändern sich nach dem Deployment? Nach einem Release müssen Versionen, Beziehungen und Dokumentation aktualisiert werden. --- **Beispiel: Release mit Versionsänderung** **Situation** Eine neue Anwendungsversion wird ausgerollt. **Configuration Management muss aktualisieren** - Anwendungsversion, - betroffene Server, - Datenbankversion, falls geändert, - Schnittstellen, - Known Errors, - Dokumentationslink, - Service Map, - Monitoringbeziehung. **Nutzen** Bei späteren Incidents ist sofort sichtbar, welche Version produktiv läuft. --- **Zusammenspiel mit Knowledge Management** Configuration-Daten und Knowledge Management ergänzen sich. Die CMDB zeigt: - welche CIs betroffen sind, - welche Services abhängen, - wer zuständig ist, - welche Versionen genutzt werden, - welche Beziehungen bestehen. Knowledge Management liefert: - Runbooks, - Workarounds, - Known Errors, - Diagnoseanleitungen, - Benutzerinformationen, - Eskalationshinweise, - Betriebsdokumentation. Beide müssen verknüpft sein. Eine CMDB ohne Dokumentationslinks ist weniger nützlich. Eine Knowledge Base ohne Service- und CI-Bezug ist schwerer auffindbar. --- **Beispiel: Knowledge und CMDB** **Situation** Ein VPN-Problem tritt wiederholt auf. **CMDB zeigt** - VPN-Service, - VPN-Gateway, - Clientversion, - MFA-Abhängigkeit, - Identity Provider, - Supportgruppe. **Knowledge Base zeigt** - Known Error, - Workaround, - Prüfschritte, - Eskalationsweg. **Nutzen** Der Service Desk kann neue Incidents schneller erkennen und bearbeiten. --- **Zusammenspiel mit Information Security Management** Information Security Management benötigt Configuration-Daten für Risikobewertung und Schutzmaßnahmen. Wichtige Fragen: - Welche Systeme sind kritisch? - Welche CIs sind extern erreichbar? - Welche Systeme verarbeiten vertrauliche Daten? - Welche Versionen sind verwundbar? - Welche Zertifikate laufen bald ab? - Welche Benutzergruppen haben Zugriff? - Welche Schnittstellen übertragen sensible Daten? - Welche Lieferanten haben Zugriff? - Welche Systeme sind nicht inventarisiert? Ohne Configuration-Daten ist Sicherheitsarbeit unvollständig. --- **Beispiel: Sicherheitslücke** **Situation** Eine kritische Schwachstelle betrifft eine bestimmte Softwareversion. **Mit guter CMDB** Es ist erkennbar: - welche Server diese Version nutzen, - welche Services betroffen sind, - welche Systeme produktiv sind, - welche Systeme extern erreichbar sind, - wer Owner ist, - welche Changes zur Behebung nötig sind. **Nutzen** Patchpriorisierung wird schneller und nachvollziehbarer. --- **Zusammenspiel mit IT Asset Management** IT Asset Management und Service Configuration Management überschneiden sich. IT Asset Management liefert Informationen über: - Besitz, - Beschaffung, - Kosten, - Lizenzen, - Verträge, - Lebenszyklus, - Garantie, - Lieferanten, - wirtschaftliche Nutzung. Service Configuration Management ergänzt: - Servicebezug, - Abhängigkeiten, - Betriebsrelevanz, - Changes, - Incidents, - Problems, - technische Beziehungen. Ein Server kann gleichzeitig Asset und CI sein. Beide Sichten sollten zusammenpassen. --- **Zusammenspiel mit Service Level Management** Service Level Management benötigt Configuration-Daten, um Service Levels realistisch zu bewerten. Wichtige Fragen: - Welche Komponenten unterstützen einen kritischen Service? - Welche CIs benötigen hohe Verfügbarkeit? - Welche Lieferanten beeinflussen Service Levels? - Welche Abhängigkeiten können SLA-Verletzungen verursachen? - Welche Changes gefährden Service Levels? - Welche Incidents betreffen kritische CIs? Service Levels sind schwer steuerbar, wenn die Serviceabhängigkeiten unbekannt sind. --- **Zusammenspiel mit Monitoring** Monitoring und Configuration Management ergänzen sich. Monitoring zeigt: - aktueller Zustand, - Alarme, - Fehler, - Performance, - Kapazität, - Verfügbarkeit. Configuration Management zeigt: - Servicebezug, - Owner, - Kritikalität, - Beziehungen, - Version, - Dokumentationslink. Beispiel: Monitoring meldet einen Serverausfall. Die CMDB zeigt, dass daran ein geschäftskritischer Service hängt. Dadurch kann der Incident korrekt priorisiert und kommuniziert werden. --- **Zusammenspiel mit Continual Improvement** Configuration Management liefert viele Verbesserungsansätze. Beispiele: - CIs ohne Owner, - Services ohne Abhängigkeiten, - Changes ohne CI-Verknüpfung, - Incidents ohne Servicezuordnung, - veraltete Versionen, - Zertifikate ohne Ablaufdatum, - Cloud-Ressourcen ohne Tags, - kritische CIs ohne Monitoring, - Dubletten, - veraltete Dokumentationslinks. Diese Erkenntnisse sollten in Continual Improvement einfließen. --- **Typischer Informationsfluss** Incident erkennt Datenfehler ↓ Datenfehler wird dokumentiert ↓ Configuration Management prüft und korrigiert ↓ Change aktualisiert CI oder Beziehung ↓ Problem Management erkennt Muster ↓ Knowledge Management ergänzt Workaround ↓ Reporting zeigt Datenqualität ↓ Continual Improvement verbessert Prozess und Pflege Configuration Management ist dadurch Teil eines Lernkreislaufs. --- **Wichtige Schnittstelleninformationen** Für das Zusammenspiel mit anderen Practices sind besonders wichtig: - Servicezuordnung, - CI-Beziehungen, - Owner, - Supportgruppe, - Kritikalität, - Umgebung, - Status, - Version, - letzte Changes, - Known Errors, - Dokumentationslinks, - Sicherheitsklassifizierung, - Lieferantenbezug, - Monitoringbezug, - Backupbezug. Diese Informationen sollten nicht nur vorhanden sein, sondern auch aktiv genutzt werden. --- **Praxisbeispiel: Major Incident** **Situation** Ein zentraler Service fällt aus. **Incident Management benötigt** - betroffener Service, - abhängige CIs, - Owner, - Supportgruppen, - Kritikalität, - Kommunikationskontakte, - letzte Changes, - Known Errors. **Configuration Management liefert** - Service Map, - CI-Beziehungen, - betroffene Komponenten, - Dokumentationslinks. **Nachbereitung** - fehlende Beziehungen ergänzen, - falsche Owner korrigieren, - Service Map aktualisieren, - Monitoringbeziehungen prüfen. --- **Praxisbeispiel: Wiederkehrende Druckerprobleme** **Situation** Ein Standort meldet regelmäßig Druckprobleme. **Incident-Daten zeigen** - mehrere Tickets, - gleicher Standort, - unterschiedliche Benutzer. **Configuration-Daten zeigen** - gleicher Druckserver, - gleicher Treiber, - gleiche Standort-Firewall, - gleiche Fachanwendung. **Problem Management erkennt** Der Fehler hängt mit einem alten Treiber und einer bestimmten Anwendung zusammen. **Verbesserung** Treiber wird über Change Enablement aktualisiert. Knowledge-Artikel und CMDB werden angepasst. --- **Praxisbeispiel: Zertifikatsmanagement** **Situation** Ein Zertifikat läuft ab und verursacht einen Incident. **Problem Management erkennt** - Zertifikat war nicht als CI erfasst, - kein Owner dokumentiert, - kein Ablaufmonitoring, - kein Erneuerungs-Runbook. **Change Enablement setzt um** - Zertifikat erneuern, - Monitoring ergänzen, - Owner festlegen, - Runbook erstellen. **Configuration Management aktualisiert** - Zertifikat als CI, - Ablaufdatum, - Servicebeziehung, - Owner, - Monitoringbeziehung, - Dokumentationslink. --- **Praxisbeispiel: Cloud-Ressource ohne Owner** **Situation** Eine Cloud-Ressource erzeugt Kosten und ist sicherheitsrelevant. **Problem** Kein Owner, kein Service-Tag, keine Dokumentation. **Risiko** - niemand fühlt sich verantwortlich, - Sicherheitsbewertung unklar, - Außerbetriebnahme riskant, - Kosten nicht zuordenbar. **Verbesserung** - Tag-Regeln einführen, - Owner verpflichtend machen, - Cloud-Discovery anbinden, - Ressourcen ohne Tags regelmäßig berichten, - Change-Prozess anpassen. --- **Typische Fehler im Zusammenspiel** **Fehler 1** CMDB wird gepflegt, aber im Incident Management nicht genutzt. --- **Fehler 2** Incidents zeigen Datenfehler, aber niemand korrigiert sie. --- **Fehler 3** Problem Management erkennt neue Abhängigkeiten, aber sie werden nicht dokumentiert. --- **Fehler 4** Changes ändern CIs, ohne die CMDB zu aktualisieren. --- **Fehler 5** Release und Deployment aktualisieren Versionen nicht. --- **Fehler 6** Knowledge-Artikel sind nicht mit Services oder CIs verknüpft. --- **Fehler 7** Security bewertet Risiken ohne aktuelle Configuration-Daten. --- **Fehler 8** Monitoring-Alarme enthalten keine Serviceinformationen. --- **Fehler 9** Asset-Daten und CI-Daten widersprechen sich. --- **Fehler 10** Owner und Supportgruppen sind veraltet. --- **Fehler 11** Configuration-Daten werden nur für Audits gepflegt, nicht für den Betrieb. --- **Fehler 12** Datenqualitätsprobleme werden gemessen, aber nicht verbessert. --- **Checkliste Zusammenspiel mit Incident Management** - [ ] Incident enthält betroffenen Service - [ ] relevante CIs sind verknüpft - [ ] Kritikalität ist sichtbar - [ ] Owner und Supportgruppe sind erkennbar - [ ] letzte Changes sind prüfbar - [ ] Known Errors sind auffindbar - [ ] Dokumentationslinks sind vorhanden - [ ] Datenfehler können gemeldet werden - [ ] fehlende Beziehungen werden nachgetragen - [ ] wiederkehrende CI-bezogene Incidents werden ausgewertet --- **Checkliste Zusammenspiel mit Problem Management** - [ ] Problems sind mit relevanten CIs verknüpft - [ ] gemeinsame Abhängigkeiten werden geprüft - [ ] betroffene Versionen werden dokumentiert - [ ] Known Errors werden mit CIs verknüpft - [ ] neue Beziehungen aus RCA werden ergänzt - [ ] fehlende Owner werden korrigiert - [ ] Service Maps werden nach Analyse aktualisiert - [ ] Workarounds werden mit Knowledge verknüpft - [ ] Problem-Erkenntnisse verbessern Configuration-Daten --- **Checkliste Zusammenspiel mit Change Enablement** - [ ] Change Request enthält betroffene CIs - [ ] abhängige Services wurden geprüft - [ ] Kritikalität wurde berücksichtigt - [ ] Owner wurden einbezogen - [ ] Sicherheitsklassifizierung wurde geprüft - [ ] parallele Changes an gleichen CIs wurden geprüft - [ ] CMDB-Aktualisierung ist Teil des Change-Abschlusses - [ ] neue CIs werden erstellt - [ ] entfernte CIs werden archiviert - [ ] geänderte Beziehungen werden aktualisiert --- **Checkliste Zusammenspiel mit Release und Deployment** - [ ] Release enthält betroffene CIs - [ ] Zielumgebung ist korrekt dokumentiert - [ ] Versionen werden nach Deployment aktualisiert - [ ] Schnittstellen werden geprüft - [ ] Known Errors werden aktualisiert - [ ] Service Desk erhält relevante CI-Informationen - [ ] Dokumentationslinks werden aktualisiert - [ ] Monitoringbeziehungen werden geprüft - [ ] CMDB-Abschluss ist Teil der Nachbereitung --- **Checkliste Zusammenspiel mit Security** - [ ] kritische CIs sind gekennzeichnet - [ ] externe Erreichbarkeit ist dokumentiert - [ ] Datenklassifizierung ist gepflegt - [ ] Zertifikate sind als CIs erfasst - [ ] Ablaufdaten werden überwacht - [ ] privilegierte Gruppen sind dokumentiert - [ ] veraltete Versionen sind auswertbar - [ ] Schwachstellen können Services zugeordnet werden - [ ] Lieferantenbezug ist sichtbar - [ ] Sicherheitsrelevante Changes nutzen CI-Daten --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker arbeiten täglich an der Schnittstelle zwischen Technik, Support und Betrieb. Für sie bedeutet das: - bei Incidents betroffene CIs korrekt erfassen, - bei Problems Abhängigkeiten erkennen, - bei Changes betroffene Services prüfen, - nach Änderungen CMDB-Daten aktualisieren, - Versionen und Konfigurationen nachvollziehbar dokumentieren, - falsche Owner oder Beziehungen melden, - Knowledge-Artikel mit Services oder CIs verknüpfen, - und technische Beobachtungen in nutzbare Betriebsinformationen überführen. Gute Configuration-Daten entstehen nicht nur durch ein Tool. Sie entstehen durch konsequente Nutzung im Alltag. --- **Zusammenfassung** > Configuration-Daten bereitstellen > ↓ > Incident Management nutzt sie für Diagnose und Priorisierung > ↓ > Problem Management nutzt sie für Muster und Ursachen > ↓ > Change Enablement nutzt sie für Risiko- und Auswirkungsbewertung > ↓ > Release und Deployment aktualisieren Versionen und Beziehungen > ↓ > Knowledge Management verknüpft Workarounds und Runbooks > ↓ > Security nutzt Daten für Risiko- und Schwachstellenbewertung > ↓ > Datenfehler und neue Erkenntnisse fließen zurück > ↓ > CMDB, Service Maps und Dokumentation werden verbessert --- **Merksätze** > Configuration-Daten sind nur wertvoll, wenn sie im Betrieb genutzt werden. > Incident Management braucht Service- und CI-Bezug für schnelle Diagnose. > Problem Management braucht Beziehungen, um gemeinsame Ursachen zu erkennen. > Change Enablement braucht Abhängigkeiten für realistische Risikobewertung. > Jeder relevante Change sollte Configuration-Daten aktualisieren. > Knowledge ohne CI-Bezug ist schwerer auffindbar. > Monitoring ohne Servicebezug erschwert Priorisierung. > Gute Configuration-Daten verbessern Support, Stabilität, Sicherheit und Veränderungsfähigkeit. --- **Verwandte Seiten** - 6.1 Service Configuration Management – Ziele, Begriffe und Grundlagen - 6.2 Configuration Items und Beziehungen - 6.3 Configuration Management Database - 6.4 Discovery, Pflege und Datenqualität - Incident Management - Problem Management - Change Enablement - Release Management - Knowledge Management - Information Security Management - IT Asset Management - Continual Improvement --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Configuration Management - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Release Management - PeopleCert – ITIL Practice Guide: Knowledge Management - PeopleCert – ITIL Practice Guide: Information Security Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - Schnittstellen, - Informationsflüsse, - Praxisbeispiele, - Checklisten, - Rollenhinweise, - und Datenqualitätsbezüge sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Schnittstellenmatrix, - CMDB-Prozessintegration, - Pflichtverknüpfung, - Service-Map-Struktur, - Reporting-Form, - oder Toolintegration für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Risiken, - Organisationsgröße, - Supportmodell, - Change-Modell, - Toollandschaft, - Datenqualität, - Sicherheitsanforderungen, - Cloud-Nutzung, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026