Ein Inventar ist noch kein digitaler Zwilling

Warum Transparenz erst durch Zusammenhänge entsteht  

Freitagabend, kurz nach 22 Uhr. Ein Core-Switch fällt aus. Innerhalb von Minuten sind drei Teams in der Leitung: Netzbetrieb, Applikationsbetrieb, Service Desk. Die technische Frage ist schnell geklärt, das Gerät ist eindeutig identifiziert, die Ersatzhardware liegt im Lager.  

Die eigentliche Frage bleibt offen: Wer merkt das gerade?  

Welche Geschäftsservices stehen still? Welche Standorte haben ihre Anbindung verloren? Welche Kunden werden die Auswirkungen morgen früh bemerken? Und vor allem: Welches System muss zuerst wieder laufen, damit die Fertigung um sechs Uhr anlaufen kann? Es dauert vierzig Minuten, bis jemand diese Fragen halbwegs verlässlich beantworten kann, und die Antwort entsteht am Telefon, aus dem Erfahrungswissen von zwei Kollegen, nicht aus einem System.  

Dabei ist alles dokumentiert. Es gibt eine CMDB, es gibt Discovery, es gibt Monitoring, es gibt tausende gepflegte Assets.  

Genau hier liegt das Missverständnis, das viele Transparenzinitiativen ausbremst. 

 

Was existiert, ist nicht dieselbe Frage wie was passiert 

Ein Inventar beantwortet, was vorhanden ist. Ein digitaler Zwilling beantwortet, welche Auswirkungen eine Veränderung hat. Das klingt nach einer Nuance und ist ein Unterschied in der Substanz.  

Ein einzelner Server ist zunächst ein Objekt mit Attributen. Entscheidungsrelevant wird er erst, wenn bekannt ist, welche Anwendungen darauf laufen, welche Datenbanken davon abhängen, welche Geschäftsprozesse dadurch gestützt werden, welche Schnittstellen daran hängen, welche Kunden betroffen wären und wer verantwortlich ist.  

Die meisten Unternehmen haben deshalb kein Datenmangelproblem. Sie haben ein Beziehungsproblem. Technische Informationen liegen in ITSM- und CMDB-Lösungen, im Netzwerkmanagement, in Discovery-Werkzeugen, auf Monitoring-Plattformen, in Cloud-Portalen, in Tabellen und in Architekturdiagrammen einzelner Teams. Jedes dieser Systeme kennt einen Ausschnitt der Realität. Jedes dieser Systeme kennt einen Ausschnitt der Realität. Was häufig fehlt, sind die Verbindungen zwischen diesen Ausschnitten.“  

Der Wert entsteht nicht durch weitere Datensätze, sondern durch ihre Verknüpfung. Und, das sei vorweggenommen, deutlich seltener durch ein weiteres Werkzeug als durch eine organisatorische Entscheidung. Dazu später mehr.  

 

"Wir haben doch eine CMDB" 

Das ist der häufigste Einwand an dieser Stelle, und er verdient eine ehrliche Antwort.  

Eine CMDB kann ein zentraler Baustein eines solchen Modells sein. Moderne Lösungen bilden Service Maps, Infrastrukturbeziehungen und tiefe Abhängigkeiten technisch durchaus ab. Die Frage ist nicht, was das Werkzeug könnte, sondern was in der Praxis tatsächlich modelliert und gepflegt wird.  

Und dort zeigt sich ein Muster. Eine CMDB wird prozessgetrieben betrieben. Ihr Datenmodell folgt dem, was ITSM-Prozesse brauchen: Incidents zuordnen, Changes bewerten, Assets im Lebenszyklus führen. Detailtiefe wird nur dort dauerhaft gepflegt, wo ein Prozess sie täglich erzwingt. Unterhalb der Serviceebene tut er das selten.  

Was deshalb häufig fehlt, ist genau die Tiefe, die eine belastbare Impact-Analyse braucht: die physische Ebene mit Rack, Stellplatz, Stromversorgung, Verkabelung, Trassen und Standorten. Die logische Netzebene mit Circuits, Providern, Verträgen und Kündigungsfristen. Die durchgehende Zuordnung von technischer Infrastruktur zu Geschäftsservices über mehrere Schichten hinweg, nicht nur eine Ebene tief.  

Dort bricht die Analyse. Man weiß, welcher Switch betroffen ist, und aber man weiß nicht, welche Kunden das merken. Das ist kein Produktversagen. Es ist die Folge davon, dass niemand je entschieden hat, wer diese Tiefe verantwortet.  

 

Discovery liefert Daten, nicht Bedeutung

Der zweite verbreitete Kurzschluss: Wir haben moderne Discovery im Einsatz, also haben wir ein aktuelles Abbild.  

Discovery ist unverzichtbar. Ohne Automatisierung ist ein aktuelles Modell in hybriden Landschaften ohnehin nicht zu halten. Werkzeuge erkennen Geräte, virtuelle Maschinen, Netzverbindungen, Softwareinstallationen, Cloud-Ressourcen, Container, Ports und Konfigurationen zuverlässig.  

Was sie nicht erkennen, ist Bedeutung. Kein Scanner sagt Ihnen, welcher Geschäftsservice an einem System hängt, welche Kritikalität eine Anwendung im Ausfallfall hat, welche regulatorischen Anforderungen darauf liegen, welcher Bereich das Budget verantwortet und welcher Change-Prozess gilt.  

Automatisierung liefert die Fakten. Die Bedeutung liefert das Unternehmen. Ein belastbarer digitaler Zwilling entsteht erst aus der Verbindung von beidem.  

 

Der regulatorische Druck steigt 

Bis vor kurzem war das primär ein Reifegradthema. Inzwischen kommt Druck von außen dazu.  

DORA gilt seit dem 17. Januar 2025 unmittelbar und verpflichtet Finanzunternehmen unter anderem zu einem Informationsregister über alle vertraglichen Vereinbarungen zur Nutzung von IKT-Dienstleistungen. Für Dienstleistungen, die kritische oder wichtige Funktionen stützen, reicht die erste Ebene ausdrücklich nicht, auch Unterauftragnehmer sind zu erfassen. Der aufwendige Teil dieser Übung war für die meisten Häuser nicht die Meldung selbst, sondern die Zuordnung: Welcher Dienstleister stützt welche Funktion, und wie kritisch ist sie.  

Das NIS2-Umsetzungsgesetz ist in Deutschland seit dem 6. Dezember 2025 in Kraft. Rund 29.500 Unternehmen fallen nun in den Anwendungsbereich. Verlangt werden angemessene Risikomanagementmaßnahmen, unter anderem für Risikoanalyse, Business Continuity und Lieferkettensicherheit, und die Verantwortung liegt ausdrücklich bei der Geschäftsleitung.  

Keines der beiden Regelwerke fordert einen digitalen Zwilling. Beide erhöhen aber den Druck, technische und organisatorische Abhängigkeiten belastbar nachvollziehen und dokumentieren zu können. Ein digitaler Zwilling kann dafür eine wirksame Grundlage schaffen, weil er dieselbe Information liefert, die im Störfall und im Nachweis gebraucht wird. 

 

"Das haben wir schon zweimal versucht" 

Auch dieser Einwand kommt regelmäßig, und meistens stimmt er. Dokumentationsprojekte haben einen schlechten Ruf, weil sie oft nach demselben Muster scheitern: Alles soll vollständig erfasst werden, das Projekt wird groß, es dauert lange, und bei Fertigstellung ist ein Teil der Daten bereits veraltet. Was bleibt, ist ein Datenfriedhof, den niemand mehr verteidigen will.  

Der Fehler liegt selten im Modell. Er liegt in der Ausgangsfrage. Wer fragt "Was müssen wir alles dokumentieren?", bekommt einen unbegrenzten Scope. Wer fragt "Welche Entscheidungen wollen wir künftig sicher treffen können?", bekommt einen definierten.  

Diese Frage lässt sich konkret beantworten. Wollen wir Changes verlässlich bewerten können? Steht eine Cloud-Migration an, bei der wir wissen müssen, welche Systeme gemeinsam ziehen müssen? Geht es um Wiederanlaufreihenfolgen nach einem Ausfall, um den Nachweis gegenüber einer Aufsicht, um die Ablösung eines Providers ohne Blindflug?  

Aus dem Anwendungsfall ergibt sich, welche Objekte, welche Beziehungen und welche Detailtiefe tatsächlich gebraucht werden. Nur so entsteht ein Nutzen, der früh genug sichtbar wird, um das Vorhaben durch das zweite Jahr zu tragen.  

 

Datenqualität ist eine Eigentumsfrage  

Damit sind wir beim eigentlichen Engpass.  

Ein digitaler Zwilling lebt von der Qualität seiner Daten, und die entsteht nicht durch das Modell, sondern durch Betrieb: klare führende Quellen je Objekttyp, automatisierte Aktualisierung wo möglich, regelmäßige Abweichungsanalysen zwischen Soll und Ist, konsistente Benennung, nachvollziehbare Governance.  

Der Widerstand dagegen ist selten technisch. Er ist organisatorisch. Netzbetrieb, IT-Betrieb, Security, Facility und Einkauf beanspruchen dieselben Objekte, in unterschiedlichen Werkzeugen und mit unterschiedlichen Namenskonventionen. Niemand übernimmt gern die Pflege für Daten, deren Nutzen vor allem woanders anfällt.  

Genau daran scheitern diese Vorhaben, nicht am Datenmodell. Und genau deshalb sind es Führungsentscheidungen: Wer ist Eigentümer welcher Daten? Welches System ist im Konfliktfall führend? Woran wird gemessen, ob die Qualität gehalten wird, und welche Konsequenz hat es, wenn sie es nicht wird?  

Diese vier Festlegungen kann keine Software für Sie treffen. Wer sie nicht trifft, kauft am Ende ein Werkzeug und bekommt eine Momentaufnahme.  

 

Vom Dokumentieren zum Steuern

IT-Dokumentation galt lange als administrative Pflicht. In hybriden Landschaften mit Multi-Cloud, SaaS, Managed Services und wachsender Regulierung wird sie zu einer Steuerungsfähigkeit.  

Ein Inventar sagt Ihnen, was Sie besitzen. Ein digitaler Zwilling sagt Ihnen, was passiert, wenn Sie etwas verändern, und was passiert, wenn etwas ausfällt. Diese Fähigkeit entscheidet darüber, wie sicher ein Unternehmen seine Infrastruktur betreibt, wie schnell es Transformationen umsetzt und wie belastbar es Risiken beherrscht.  

Digitale Souveränität beginnt deshalb nicht mit möglichst vielen Daten. Sie beginnt mit dem Verständnis ihrer Zusammenhänge. 

 

Wie FNT Services unterstützt 

Der Weg dorthin beginnt selten auf der grünen Wiese. Die meisten Unternehmen besitzen bereits wertvolle Daten, verteilt über Systeme und Organisationseinheiten.  

Wir helfen dabei, daraus eine belastbare Entscheidungsgrundlage zu machen: Analyse der bestehenden Quellen und ihrer tatsächlichen Qualität, Modellierung technischer und fachlicher Abhängigkeiten entlang konkreter Anwendungsfälle, Integration der geeigneten Quellsysteme sowie der Aufbau von Governance- und Datenverantwortlichkeiten, die den Zwilling dauerhaft aktuell halten.  

Am Ende geht es nicht darum, möglichst viel zu dokumentieren. Es geht darum, im Zweifelsfall in Minuten statt in Stunden entscheiden zu können.  

Nennen Sie uns drei Entscheidungen, die Sie in den nächsten zwölf Monaten sicher treffen müssen, etwa eine Migration, eine Providerablösung oder einen Nachweis gegenüber einer Aufsicht. Wir gehen sie mit Ihnen durch und zeigen Ihnen, welche Informationen und welche Beziehungen Ihnen dafür heute fehlen.

Kontaktanfrage