# 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