Organisationen, die ServiceNow Discovery implementieren, stehen vor einer häufigen Herausforderung.Erste Scans identifizieren Tausende von Configuration Items. Das führt zu Datenüberlastung statt zu operativer Klarheit.

Dieser Leitfaden befasst sich mit der Post-Discovery-Phase. Er bietet ein strukturiertes Framework, um Rohdaten in eine vertrauenswürdige, umsetzbare CMDB zu transformieren.

Wichtige Erkenntnisse:

• Der Erfolg von Discovery wird an der Datenqualität gemessen, nicht an der Menge
• 85 % Genauigkeit bei geschäftskritischen CIs liefern mehr Wert als 50 % über alle Assets hinweg
• Eine korrekte IRE-Konfiguration, Governance-Frameworks und Service Mapping sind essenziell
• Strategische Bereinigung, Priorisierung und Automatisierung treiben den ROI

Die Herausforderung: Von Discovery-Erfolg zu Datenüberlastung

Die Initiale Implementierungsphase

Deine Organisation hat gerade ihren ersten umfassenden Discovery-Scan abgeschlossen.
Monate der Planung haben sich ausgezahlt. MID-Server wurden bereitgestellt. Credentials konfiguriert. IP-Bereiche definiert. Discovery erfolgreich ausgeführt.
Die Ergebnisse übertrafen die Erwartungen. Tausende Geräte entdeckt. Detaillierte Asset-Informationen befüllt. Die CMDB wuchs rasant.
Doch der anfängliche Erfolg offenbarte schnell erhebliche Herausforderungen.

Häufige Post-Discovery-Probleme:

• Datenmenge vs. Datenqualität Discovery identifizierte über 10.000 CIs. Aber 40–60 % verfügen nicht über vollständige oder korrekte Informationen.
• Erstellung doppelter CIs Einzelne Geräte erscheinen als mehrere CIs. Die Identification & Reconciliation Engine (IRE) war nicht korrekt konfiguriert.
• Fehlender Business-Kontext Du hast ein technisches Asset-Inventar. Aber keine Ownership-Daten. Keine Service-Beziehungen. Keine Indikatoren zur Geschäftskritikalität.
• Wartungskomplexität Es existiert kein nachhaltiger Prozess für laufendes Datenqualitätsmanagement. Tausende CIs manuell zu verwalten ist unmöglich.
• Verlust des Nutzervertrauens Ungenaue oder unvollständige Daten untergraben das Vertrauen. Teams hören auf, die CMDB als maßgebliche Quelle zu nutzen.

Die Grundursache: Implementierung ohne Strategie

Die meisten Organisationen gehen Discovery mit einem technologiegetriebenen Ansatz an. Sie konfigurieren das Tool. Führen Scans aus. Befüllen die Datenbank.
Doch sie überspringen die kritische Planungsphase: Was passiert, nachdem Discovery alles gefunden hat?

Die typische Abfolge:

• Discovery-Infrastruktur bereitstellen
• Umfassende Scans ausführen
• Tausende Geräte entdecken
• Erkennen, dass es keinen Plan für Datenmanagement gibt
• Monate mit Bereinigungsversuchen verbringen

Dieser Ansatz erzeugt von Tag eins an technische Schulden.

Die Kernprobleme verstehen

Problem 1: Discovery findet alles unterschiedslos

ServiceNow Discovery ist leistungsstark. Vielleicht zu leistungsstark für Erstimplementierungen.
Discovery-Scans identifizieren jedes Gerät in deinem Netzwerk:

Produktions-Assets (Was Du wolltest)

• Produktionsserver
• Geschäftskritische Anwendungen
• Netzwerkinfrastruktur
• Zentrale Rechenzentrums-Hardware

Nicht-Produktions-Assets (Was Du nicht eingeplant hast)

• Test- und Entwicklungsumgebungen
• Laborequipment, das wöchentlich neu aufgebaut wird
• Stillgelegte Geräte, die noch verbunden sind
• Private Geräte im Unternehmens-WLAN
• IoT-Geräte (Drucker, Kameras, Smart Devices)

Deine CMDB besteht nun zu 60 % aus Signal und zu 40 % aus Rauschen. Kritische Assets zu finden wird zunehmend schwieriger.

Problem 2: Doppelte Configuration Items

Gleicher physischer Server. Fünf verschiedene CIs in deiner CMDB.

Wie Duplikate entstehen:
→ Discovery fand das Gerät über die IP-Adresse → CI #1 erstellt
→ Discovery fand dasselbe Gerät über den Hostnamen → CI #2 erstellt
→ Zweiter Scan mit anderen Credentials → CI #3 erstellt
→ Integration aus einem anderen Monitoring-Tool → CI #4 erstellt
→ Manueller Import aus einer Asset-Tabelle → CI #5 erstellt

Die IRE nutzt Identifikationsregeln, um Duplikate zu verhindern. Doch die Standardregeln berücksichtigen deine spezifische Umgebung nicht.
Ohne korrektes IRE-Tuning ist die Erstellung von Duplikaten unvermeidlich.

Problem 3: Fehlender Business-Kontext

Du hast 10.000 Geräte in deiner CMDB dokumentiert. Doch entscheidende Fragen bleiben unbeantwortet:

• Welche Assets sind geschäftskritisch und welche nur unterstützend?
• Wer ist Eigentümer jedes Configuration Items?
• Welche Business Services hängen von diesen Assets ab?
• Welche finanziellen Auswirkungen hat ein Ausfall?
• Welche Geräte können sicher stillgelegt werden?

Discovery liefert ein technisches Inventar. Es liefert keine Business-Intelligenz.

Problem 4: Schlechte Datenqualität

Analysen typischer Post-Discovery-CMDBs zeigen:

• 40 % fehlen Ownership-Informationen
  Geräte haben keinen zugewiesenen Business- oder technischen Owner
• 30 % sind der Abteilung „Unknown“ zugeordnet
  Organisatorische Zuordnung ist unvollständig oder falsch
• 25 % sind doppelte Datensätze
  Gleiche Assets sind mehrfach vorhanden
• 15 % sind stillgelegt, aber noch in der CMDB
  Kein Prozess zur Entfernung ausgemusterter Assets
• 10 % haben unvollständige oder falsche Daten
  Kritische Felder fehlen oder enthalten falsche Informationen

Durchschnittliche CMDB-Genauigkeit: 50–60 %
Dieses Genauigkeitsniveau ist für den operativen Einsatz unzureichend. Teams können den Daten nicht vertrauen. Sie greifen wieder auf informelles Wissen und Tabellen zurück.

Problem 5: Nicht nachhaltige Wartungsanforderungen

Glückwunsch. Du hast jetzt 10.000 CIs, die aktiv gemanagt werden müssen.

Laufende Wartungsherausforderungen:
→ Discovery läuft kontinuierlich und fügt weitere Geräte hinzu
→ Asset-Konfigurationen ändern sich ständig
→ Teams nehmen Änderungen vor, ohne die CMDB zu aktualisieren
→ Stillgelegte Geräte bleiben monatelang bestehen
→ Keine zugewiesenen Ressourcen für Datenqualitätsmanagement

Innerhalb von 90 Tagen sinkt die CMDB-Genauigkeit typischerweise unter 50 %. Ohne nachhaltige Governance verschlechtert sich die Datenqualität kontinuierlich.

 

Der strategische Ansatz: 10-Schritte-Framework zur CMDB-Optimierung

Schritt 1: Reduzierung des Discovery-Scopes implementieren

Sofortmaßnahme: Pausiere nicht essenzielle Discovery-Zeitpläne.
Das erscheint kontraintuitiv. Du hast in Discovery investiert, um Transparenz zu gewinnen. Doch alles zu entdecken erzeugt nicht nachhaltige Datenmengen.

Deaktiviere Discovery für:

• Test- und Entwicklungsumgebungen
• Labornetzwerke mit häufigen Neuaufbauten
• Gast-WLAN- und Besuchernetzwerke
• Nicht kritische IoT-Gerätebereiche
• Legacy-Infrastruktur, die zur Stilllegung geplant ist

Behalte Discovery nur für:

• Produktionsinfrastruktur zur Unterstützung von Business Services
• Geschäftskritische Anwendungen
• Zentrale Netzwerkgeräte (Router, Switches, Firewalls, Load Balancer)
• Rechenzentrums-Equipment mit Compliance-Anforderungen

Beginne mit fokussierter Discovery. Erweitere gezielt, wenn die Governance reift.

Schritt 2: Identification & Reconciliation Engine (IRE) konfigurieren

Die IRE ist der ServiceNow-Mechanismus zur Vermeidung doppelter CIs. Sie nutzt Identifikationsregeln, um festzustellen, ob entdeckte Geräte neu oder bereits vorhanden sind.

Zentrale IRE-Konzepte:
Identifikationsregeln
Definieren, welche Attribute jede CI-Klasse eindeutig identifizieren. Gängige Identifier sind Seriennummern, MAC-Adressen und Fully Qualified Domain Names.

Reconciliation-Priorität
Legt fest, welche Datenquelle bei Konflikten maßgeblich ist.

Häufige IRE-Konfigurationsprobleme:
→ Standardregeln sind nicht auf deine Umgebung optimiert
→ Seriennummern werden bei Discovery nicht konsistent erfasst
→ Hostname- vs. FQDN-Abgleich erzeugt Duplikate
→ Dynamische IP-Adressierung führt zu mehreren Datensätzen

Erforderliche Maßnahme: Binde ServiceNow-Expertise ein, um IRE-Regeln zu tunen, bevor Discovery-Operationen fortgesetzt werden.

Schritt 3: CI-Klassifizierung und Priorisierung implementieren

Nicht alle Configuration Items erfordern den gleichen Aufwand. Klassifiziere Assets nach Business-Impact, um Ressourcen effektiv einzusetzen.

Klassifizierungs-Framework:

Tier 1: Geschäftskritische Assets

• Produktions-Datenbankserver
• Kundennahe Anwendungsinfrastruktur
• Zentrale Netzwerkgeräte
• Zahlungsabwicklungssysteme
• Umsatzgenerierende Plattformen

Tier 2: Wichtige unterstützende Assets

• Interne Business-Anwendungen
• Entwicklungs- und Staging-Umgebungen
• Nicht kritische Netzwerkinfrastruktur
• Unterstützende Services

Tier 3: Niedrig priorisierte Assets

• Testsysteme mit häufigen Änderungen
• Endnutzergeräte, die separat gemanagt werden
• IoT- und Peripheriegeräte
• Laborequipment

Strategischer Fokus: Erreiche 95 % Genauigkeit bei Tier-1-Assets, bevor niedrigere Tiers adressiert werden.

Schritt 4: Umfassende Datenbereinigung durchführen

Bevor weitere Assets entdeckt werden, behebe bestehende Datenqualitätsprobleme in der CMDB.

Identifikation und Behebung von Duplikaten:
→ Nutzung der ServiceNow-Deduplizierungsfunktionen
→ Identifikation von Geräten mit identischen Hostnamen, aber unterschiedlichen IP-Adressen
→ Auffinden mehrerer CIs mit derselben Seriennummer
→ Zusammenführen bestätigter Duplikate gemäß etablierter Protokolle

Entfernung veralteter Assets:
→ Stilllegung von CIs, die seit über 90 Tagen nicht durch Discovery gesehen wurden
→ Entfernung außer Betrieb genommener Systeme aus der CMDB
→ Löschen von Testgeräten mit regelmäßigen Neuaufbauten

Anreicherung kritischer CIs:
→ Zuweisung von Business- und technischen Ownern
→ Zuordnung zu Business Services
→ Dokumentation kritischer Abhängigkeiten
→ Ergänzung finanzieller Daten (Anschaffungskosten, Wartungsverträge)

Fokussiere die Bereinigung zuerst auf geschäftskritische Assets.

Schritt 5: Ownership für Configuration Items etablieren

Jedes CI benötigt einen zugewiesenen Owner. Nicht IT-Mitarbeitende, sondern Business-Stakeholder.

Warum Business-Ownership wichtig ist:
→ Business Owner validieren die CI-Genauigkeit
→ Owner genehmigen Änderungen, die ihre Assets betreffen
→ Owner bestätigen, ob Assets noch benötigt werden
→ Owner liefern Business-Kontext, den IT nicht hat

Implementierungsansatz:

• Identifiziere Business Services in deiner Organisation
• Weise jedem Service einen Business Owner zu
• Mappe Configuration Items auf Business Services
• Der Service Owner wird per Vererbung zum CI Owner

Starte CI-Zertifizierungskampagnen, bei denen Owner die Genauigkeit der Assets in ihrem Verantwortungsbereich prüfen und bestätigen.
Dieser Prozess deckt stilllegungsreife Geräte auf, korrigiert fehlerhafte Informationen und identifiziert Ownership-Lücken.

Schritt 6: Data-Governance-Framework implementieren

ServiceNow Discovery arbeitet kontinuierlich. Ohne Governance verschlechtert sich die CMDB-Datenqualität in Echtzeit.

Wesentliche Governance-Komponenten:

• CI-Lifecycle-Management
  Definiere Prozesse für das Hinzufügen, Ändern und Stilllegen von Configuration Items.
• Datenqualitätsstandards
  Lege Pflichtfelder je CI-Klasse fest. Implementiere Validierungsregeln. Konfiguriere automatisierte Qualitätsprüfungen.
• Integration ins Change Management
  Erfordere CMDB-Updates als Teil der Change-Umsetzung. Keine Change-Freigabe ohne CI-Validierung.
• Discovery-Zeitplan-Management
  Definiere, wann Discovery läuft. Lege fest, was entdeckt wird. Etabliere Ausnahmeprozesse.

Ohne Governance beschleunigst Du den Datenverfall.

Schritt 7: Service Mapping für Business-Kontext einsetzen

Discovery identifiziert, welche Geräte existieren. Service Mapping erklärt, warum sie relevant sind.

Vor Service Mapping:
„Datenbankserver DB-PROD-01 hat Probleme.“

Nach Service Mapping:
„Der Ausfall von DB-PROD-01 beeinträchtigt das Kundenportal (500 aktive Nutzer), die Auftragsverarbeitung (15.000 € Umsatz pro Stunde) und das Executive Reporting. Geschätzter Business-Impact: 15.000 € pro Stunde Ausfallzeit.“

Service Mapping liefert:
→ Dokumentation von CI-zu-Service-Beziehungen
→ Visualisierung von Applikationsabhängigkeiten
→ Business-Impact-Bewertung bei Incidents
→ Kontext zur Service-Kritikalität

Damit wird die CMDB von einem technischen Inventar zu einer Business-Intelligence-Plattform.

Schritt 8: CMDB-Wartungsprozesse automatisieren

Manuelle CMDB-Pflege skaliert nicht über ein paar Hundert CIs hinaus. Automatisierung ist für Enterprise-Umgebungen zwingend erforderlich.

Automatisierungspotenziale:

• Discovery-Zeitplanung
  Tägliche Scans für geschäftskritische Infrastruktur. Wöchentliche Scans für unterstützende Assets. Echtzeit-Discovery für Cloud-Ressourcen.
• Datenqualitätsüberwachung
  Automatisierte Duplikaterkennung. Alerts bei fehlenden Ownern. Identifikation veralteter CIs. Vollständigkeitsbewertungen.
• CI-Lifecycle-Automatisierung
  Automatisches Stilllegen von Assets, die seit über 90 Tagen nicht gesehen wurden. Automatisierte Hinweise zum Ablauf von Garantien. Kennzeichnung potenzieller Stilllegungskandidaten.
• Multi-Plattform-Integration
  Discovery von Cloud-Plattformen (AWS, Azure, GCP). Discovery von Container-Orchestrierung (Kubernetes). Discovery von SaaS-Anwendungen. Updates von Netzwerkgeräte-Konfigurationen.

Behalte menschliche Eingriffe nur für Ausnahmen vor.

Schritt 9: Business-orientiertes Reporting entwickeln

Traditionelle CMDB-Kennzahlen fokussieren technische Daten. Business-Stakeholder benötigen andere Einblicke.

CMDB-Health-Dashboard:
→ Datenvollständigkeit nach CI-Klasse
→ Configuration Items ohne Ownership
→ Assets, die seit über 90 Tagen nicht entdeckt wurden
→ Duplikat-Kandidaten zur Bereinigung
→ Trendanalyse der Datenqualität

Business-Service-Reports:
→ Services und zugehörige CIs
→ Service-Health-Indikatoren
→ Abhängigkeitsvisualisierung
→ Impact-Analyse-Funktionen

Asset-Lifecycle-Reports:
→ Geräte nahe End-of-Life
→ Tracking von Garantieabläufen
→ Anforderungen an Refresh-Zyklen
→ Identifikation von Stilllegungskandidaten

Discovery-Operations-Reports:
→ Bewertung der Discovery-Abdeckung
→ Erfolgs- und Fehlerraten-Trends
→ Muster bei der Identifikation neuer Geräte

Berichte den gelieferten Business-Wert, nicht die abgeschlossene technische Aktivität.

Schritt 10: Performance-Kennzahlen etablieren

Verfolge Kennzahlen, die kontinuierliche Verbesserung fördern:

Datenqualitätsindikatoren:
→ CMDB-Genauigkeitsquote
→ CI-Vollständigkeit je Klasse
→ Duplikatrate von CIs
→ Messung der Datenaktualität

Business-Value-Kennzahlen:
→ Business Services, die auf Infrastruktur gemappt sind
→ CIs mit zugewiesenen Business Ownern
→ Reduktion der Mean Time to Identify (MTTI)
→ Verbesserung der Change-Erfolgsquote

Operative Effizienzkennzahlen:
→ Discovery-Erfolgsquote
→ Zeit zur Aufnahme neuer CIs
→ Performance von CMDB-Abfragen
→ Nutzerzufriedenheit mit der Datenqualität

Überwache Trends über die Zeit, nicht nur Momentaufnahmen.

 

Implementierungszeitplan: 30-Tage-Aktionsplan

Woche 1: Ist-Zustandsanalyse

Aktivitäten:
→ Gesamtanzahl der CIs und geschätzte Genauigkeit prüfen
→ Geschäftskritische Assets identifizieren, die sofortige Aufmerksamkeit erfordern
→ Aktuellen Ownership-Status dokumentieren
→ Reifegrad der IRE-Konfiguration bewerten

Ergebnisse: Ist-Zustandsanalysebericht mit Basiskennzahlen.

Woche 2: Durchführung der Datenbereinigung

Aktivitäten:
→ Nicht essenzielle Discovery-Zeitpläne aussetzen
→ Bereinigung doppelter CIs durchführen
→ Bestätigt stillgelegte Assets entfernen
→ Anreicherungsmaßnahmen auf die 100–500 wichtigsten kritischen CIs fokussieren

Ergebnisse: Bereinigte CMDB mit verbesserter Genauigkeit für kritische Assets.

Woche 3: Implementierung der Governance

Aktivitäten:
→ Owner für geschäftskritische CIs zuweisen
→ Datenqualitätsstandards und -regeln dokumentieren
→ CI-Lifecycle-Prozesse etablieren
→ Service Mapping für kritische Services planen

Ergebnisse: Dokumentierte Governance-Frameworks und erste Owner-Zuweisungen.

Woche 4: Etablierung der Basis

Aktivitäten:
→ IRE auf Deine spezifische Umgebung abstimmen
→ CMDB-Health-Monitoring-Dashboard bereitstellen
→ Erste CI-Zertifizierungskampagne starten
→ Lessons Learned und Pläne für die nächste Phase dokumentieren

Ergebnisse: Operative CMDB mit Governance, verbesserter Genauigkeit und Nachhaltigkeits-Framework.

Häufige Implementierungsfallen

Falle 1: Aufgeschobene Datenbereinigung

Symptom: „Wir bereinigen die Daten später, lasst uns weiter entdecken.“
Auswirkung: Die Datenqualität verschlechtert sich schneller, als die Bereinigung erfolgen kann. Der Rückstau wird unbeherrschbar.
Lösung: Stoppe die Ausweitung von Discovery, bis bestehende Daten die Qualitätsstandards erfüllen.

Falle 2: Streben nach perfekter Genauigkeit

Symptom: „Wir können die CMDB erst nutzen, wenn sie zu 100 % korrekt ist.“
Auswirkung: Perfektion wird zum Feind des Guten. Die CMDB wird nie produktiv genutzt.
Lösung: Setze 85 % Genauigkeit für geschäftskritische Assets als Ziel. Diese Schwelle liefert operativen Mehrwert und bleibt realistisch erreichbar.

Falle 3: Reines IT-Ownership-Modell

Symptom: „IT pflegt alle CMDB-Daten.“
Auswirkung: IT fehlt der Business-Kontext, um Genauigkeit zu validieren oder die Relevanz von Assets zu bewerten.
Lösung: Business-Stakeholder besitzen die Daten. IT betreibt und wartet die Plattform-Infrastruktur.

Falle 4: Fokus auf Volumen statt Qualität

Symptom: „Unsere CMDB hat 50.000 CIs, das beweist den Erfolg.“
Auswirkung: Große Mengen ungenauer Daten liefern keinen Mehrwert. Nutzer vertrauen den Informationen nicht.
Lösung: Konzentriere Dich auf die Qualität kritischer Assets, nicht auf die Menge der Datensätze.

Fallstudie: CMDB-Transformation eines Finanzdienstleisters

Organisationsprofil

Mittelgroße Finanzdienstleistungsorganisation. Mehrere Standorte. Komplexes Applikationsportfolio. Initiale Discovery identifizierte 8.500 Geräte bei geschätzter CMDB-Genauigkeit von 45 %.

Implementierungsansatz

 

Monate 1–2: Fundament
→ Alle Discovery-Zeitpläne ausgesetzt
→ 500 geschäftskritische CIs identifiziert
→ 95 % Genauigkeit für den kritischen Asset-Bestand erreicht

Monate 3–4: Expansion
→ Service Mapping für die Top-10-Business-Services implementiert
→ Business Owner organisationsweit zugewiesen
→ CI-Zertifizierungsprozess etabliert

Monate 5–6: Optimierung
→ IRE abgestimmt, um zukünftige Duplikate zu verhindern
→ 2.000 veraltete und doppelte CIs entfernt
→ Discovery ausschließlich für Produktionsumgebungen wieder aktiviert

Monate 7–12: Reifephase
→ Erweiterung auf 1.500 aktiv gemanagte CIs bei 85 % Genauigkeit
→ Integration der CMDB in Change-Management-Prozesse
→ Automatisierte Wartungs-Workflows bereitgestellt

 

Erzielte Ergebnisse

✅ Die CMDB wurde zur vertrauenswürdigen, maßgeblichen Quelle
Teams beziehen sich konsistent auf die CMDB für operative Entscheidungen

✅ Mean Time to Identify um 40 % reduziert
Schnellere Ursachenanalyse bei Incidents durch korrekte CI-Beziehungen

✅ Change-Erfolgsquote um 25 % verbessert
Besseres Verständnis von Change-Auswirkungen durch Service Mapping

✅ 1.200 unnötige Geräte stillgelegt
Identifikation von Assets, die keine Business-Operationen mehr unterstützen

✅ Jährliche Kosteneinsparungen: 500.000 €
Reduzierte Wartungskosten und verbesserte operative Effizienz

Kritischer Erfolgsfaktor

Der Wert wurde aus 1.500 korrekten, gut governeden CIs gewonnen. Nicht aus 8.500 schlecht gepflegten Datensätzen.

Fazit

Dass ServiceNow Discovery 10.000 Geräte identifiziert, ist ein Anfang – kein Endpunkt. Erfolg wird nicht an der Menge entdeckter Assets gemessen, sondern an der Qualität und dem Business-Wert der CMDB-Daten.

Kritische Erfolgsfaktoren:
→ Qualität vor Quantität: 85 % Genauigkeit bei kritischen Assets liefern mehr Wert als 50 % über alle Geräte hinweg
→ Strategischer Scope: Entdecke, was Du effektiv governieren kannst – nicht alles, was technisch möglich ist
→ Business-Ownership: IT betreibt die Plattform, das Business besitzt die Daten
→ Kontinuierliche Governance: Ohne nachhaltige Prozesse verschlechtert sich die Datenqualität kontinuierlich
→ Service-Kontext: Technisches Inventar ohne Business-Kontext liefert nur begrenzten Mehrwert

Organisationen, die strukturierte CMDB-Optimierungs-Frameworks implementieren, erreichen:

• Vertrauenswürdige, maßgebliche Datenquellen
• Reduzierte Incident-Lösungszeiten
• Verbesserte Change-Erfolgsquoten
• Signifikante Kosteneinsparungen durch Asset-Optimierung
• Ein belastbares Fundament für fortgeschrittene ITOM-Fähigkeiten

Der Weg von Discovery-Chaos zu CMDB-Reife erfordert Disziplin, strategischen Fokus und ein klares Bekenntnis zu Datenqualität statt Datenmenge.

Transformiere Deine CMDB: Experten-Consulting-Services

Ich spezialisiere mich auf ITOM-Implementierungen, die messbaren Business-Wert liefern. Meine Beratungspraxis hat Organisationen branchenübergreifend dabei unterstützt, Discovery-Datenüberlastung in strategische CMDB-Assets zu transformieren.

CMDB-Optimierungsservices:
✅ Optimierung und Tuning der Discovery-Infrastruktur
✅ Umfassende CMDB-Bereinigung und Deduplizierung
✅ IRE-Konfiguration für Deine spezifische Umgebung
✅ Implementierung und Rollout von Service Mapping
✅ Entwicklung von Data-Governance-Frameworks
✅ Team-Trainings und Wissenstransfer-Programme