Digitale Souveränität im Immobilienportfolio

Ein kleiner Umbau mit erstaunlich vielen Folgen

Zwei Seminarräume werden zu einem größeren Raum zusammengelegt. Die Trennwand wird entfernt, eine Tür entfällt. Baulich ist das ein überschaubarer Vorgang. Für die Informationen über das Gebäude ist die Änderung deutlich weitreichender.

In der Planung ändern sich Grundriss und gegebenenfalls das BIM-Modell. Aus zwei Raumobjekten wird ein neuer Raum; Wand und Tür entfallen. Für den Gebäudebetrieb müssen Flächen und Zuordnungen angepasst werden. Die Vermietung kann künftig nicht mehr zwei Seminarräume anbieten, sondern einen größeren Raum mit anderer Kapazität, Ausstattung und möglicherweise einer anderen Preislogik. Auch Reinigung, technische Gebäudeausrüstung, Kostenstellen, Brandschutz oder spätere Nachhaltigkeitsauswertungen können betroffen sein.

Damit stellt sich eine einfache Frage: Wo befindet sich nach dem Umbau die gültige Information über diesen Raum?

Die naheliegende Antwort lautet nicht: in einem bestimmten System. Sie lautet vielmehr: Das hängt davon ab, um welche Information es geht.

Die Geometrie kann aus einem BIM-Modell stammen. Die Buchbarkeit kommt aus der Vermietung. Eine Kostenstelle wird im ERP verantwortet. Wartungsinformationen liegen im Betrieb. Ein Energiemanagementsystem kennt Verbrauchsdaten. Keine dieser Informationen ist allein deshalb weniger relevant, weil sie außerhalb eines Gebäudemodells entsteht.

Genau an diesem Punkt beginnt die Frage nach digitaler Souveränität im Immobilienportfolio.

Ein Gebäude hat nicht nur eine digitale Darstellung

In einem größeren Immobilienbestand existieren Informationen über dasselbe Gebäude gleichzeitig in vielen fachlichen Zusammenhängen. Das ist zunächst kein Mangel, sondern eine Folge unterschiedlicher Aufgaben.

Für die Planung ist ein Raum unter anderem ein geometrisches Objekt. Für die Vermietung ist er eine buchbare Ressource. Der technische Betrieb betrachtet Ausstattung, Anlagen und Betreiberpflichten. Das Rechnungswesen benötigt kaufmännische Zuordnungen. Für die Gebäudeautomation kann derselbe Raum Teil einer Regelzone sein. Nachhaltigkeitsverantwortliche benötigen wiederum Flächen-, Verbrauchs- oder Nutzungsinformationen.

Diese Sichtweisen lassen sich nicht sinnvoll auf eine einzige reduzieren.

In der Softwareentwicklung beschreibt Domain Driven Design ein vergleichbares Prinzip: Fachbereiche besitzen eigene Begriffe, Regeln und Verantwortlichkeiten. Entscheidend ist nicht, diese Unterschiede abzuschaffen. Entscheidend ist, dass die Beteiligten erkennen können, wann sie über dasselbe reale Objekt sprechen und wie ihre Informationen zusammengehören.

Für den Seminarraum bedeutet das: Die Vermietung muss keine Türgeometrie verwalten. Das BIM-Modell muss keine Buchungspreise enthalten. Das ERP benötigt keine vollständige technische Ausstattung des Raums. Trotzdem müssen die Systeme und Fachbereiche einen gemeinsamen Bezug herstellen können.

Eine gemeinsame Sprache ist daher etwas anderes als eine gemeinsame Datenbank.

Das zeigt sich bereits an den etablierten Standards selbst: IBPDI (International Building Performance & Data Initiative), ein branchenweites Datenmodell für Portfolio-Reporting und ESG-Benchmarking, beschreibt vor allem die Portfolio- und ESG-Ebene. RealEstateCore, eine offene Ontologie für Smart-Building- und IoT-Daten, deckt die Betriebs- und IoT-Ebene ab. IFC (Industry Foundation Classes), gepflegt von buildingSMART International, die Gebäude- und Bauteilebene. Die Asset Administration Shell mit ihrem Austauschformat AASX, entwickelt von der IDTA (Industrial Digital Twin Association), bildet Herstellerdaten zu Anlagen und Komponenten herstellerneutral ab – vom Typenschild bis zur Wartungsdokumentation. Mit dem kommenden digitalen Produktpass, den die EU für immer mehr Produktgruppen vorschreibt, gewinnt die AAS zusätzlich an Bedeutung: Sie kann dafür die technische Basis bilden. Brick Schema beschreibt als offene Ontologie Sensoren, Anlagen und ihre Beziehungen in Gebäudeautomation und HVAC-Technik. Keiner dieser Standards deckt allein das gesamte Bild ab, weil sie für unterschiedliche fachliche Zwecke entstanden sind.

Daraus folgt kein Plädoyer für einen weiteren, alles umfassenden Standard. Ein solcher Standard wäre auch kaum sinnvoll zu entwickeln: Jeder der genannten Standards ist in seiner Domäne gewachsen und dort ausgereift. Zielführend ist nicht der eine große Standard, sondern die sinnstiftende Kombination der vorhandenen – jeweils dort eingesetzt, wo er seine Stärke ausspielt, und an den Rändern miteinander verbunden.

Unter diesen Standards nimmt BIM im Bau- und Immobilienkontext dennoch eine besondere Stellung ein: Es ist nicht nur Datenquelle für IFC, sondern in vielen Organisationen auch gelebte Arbeitsweise und erster Bezugspunkt, wenn es um Gebäudeinformationen geht. Wie viel Gewicht BIM in einer gemeinsamen Informationsschicht tatsächlich tragen sollte, verdient deshalb einen genaueren Blick.

BIM dort, wo BIM vorhanden ist

BIM spielt dabei eine wichtige Rolle. Wo ein belastbares Modell vorhanden ist, sollte es selbstverständlich genutzt werden. Geometrie, Räume, Bauteile, technische Anlagen und räumliche Beziehungen können daraus mit hoher Qualität übernommen werden. Es wäre weder wirtschaftlich noch fachlich sinnvoll, diese Informationen parallel noch einmal zu erfassen.

Problematisch wird es erst, wenn aus dieser Stärke eine generelle Voraussetzung gemacht wird: Erst müsse modelliert werden, bevor Informationen strukturiert genutzt werden könnten. Oder in der Gegenrichtung: Alle im Betrieb entstehenden Informationen müssten wieder zurück in das BIM-Modell, damit eine vollständige Datenbasis entsteht.

Für Neubauprojekte mit durchgängigem BIM-Prozess kann ein solches Vorgehen für ausgewählte Informationen funktionieren. Auf große Bestandsportfolios lässt es sich jedoch nicht ohne Weiteres übertragen.

Ein Bestandshalter, der beispielsweise 50.000 Wohnungen bewirtschaftet und nur für einen Teil davon aktuelle BIM-Modelle besitzt, steht vor einer anderen wirtschaftlichen Realität. Gebäudestammdaten können im ERP vorliegen, Flächen in einem CAFM-System, Energieinformationen in einer Spezialanwendung und weitere Bestandsinformationen in Excel-Dateien. Müssen all diese Wohnungen zuerst detailliert modelliert werden, bevor die vorhandenen Informationen miteinander genutzt werden können, wird das Informationsmanagement von einem zusätzlichen Modellierungsprojekt abhängig.

Der Aufwand muss aber zum jeweiligen Zweck passen. Für eine Portfolioauswertung werden möglicherweise zunächst Gebäude, Nutzung, Fläche, Baujahr und Energieinformationen benötigt. Dafür ist nicht zwingend ein geometrisches Gebäudemodell erforderlich.

Das führt zu einem pragmatischen Grundsatz: „Das Informationsmanagement muss sich an der Realität des Bestands orientieren – nicht der Bestand an einem bevorzugten Datenformat.“

Wo BIM vorhanden ist, kann BIM eine maßgebliche Quelle sein. Wo ein CAFM-System die verlässlichsten Betriebsinformationen enthält, ist dieses die geeignete Quelle. Kaufmännische Informationen können aus dem ERP kommen. Und wenn eine belastbare Excel-Liste derzeit die beste verfügbare Quelle ist, muss auch sie eingebunden werden können.

Excel ist damit nicht das Zielbild. Es ist eine mögliche Ausgangsquelle.

Der entscheidende Schritt besteht darin, die darin enthaltenen Informationen aus ihrer isolierten Datei- oder Systemlogik zu lösen und mit den Informationen anderer Fachbereiche in Beziehung setzen zu können.

Digitale Souveränität ist mehr als der Speicherort

Bei digitaler Souveränität richtet sich die Diskussion häufig zuerst auf Cloudanbieter, Serverstandorte und die Frage, ob Software im eigenen Rechenzentrum betrieben werden kann. Diese Fragen sind wichtig. Für den Umgang mit Immobilieninformationen reichen sie jedoch nicht aus.

Ein Unternehmen kann sämtliche Daten auf eigenen Servern speichern und trotzdem nur eingeschränkt souverän mit ihnen umgehen.

Das zeigt sich an einfachen Fragen:

• Was bedeutet eine bestimmte Information im Unternehmen?
• Auf welches reale Gebäude, welchen Raum oder welche Anlage bezieht sie sich?
• Woher stammt sie?
• Welcher Fachbereich verantwortet sie?
• Welche Änderung hat zu ihrem heutigen Zustand geführt?
• Wer darf sie lesen oder verändern?
• Kann sie außerhalb des Ursprungssystems weiterverwendet werden?

Fehlen darauf verlässliche Antworten, besteht zwar technischer Datenbesitz, aber nur begrenzte Handlungsfähigkeit.

Für Immobilienportfolios lassen sich deshalb drei Aspekte unterscheiden:

Bedeutungshoheit bedeutet, dass die Organisation selbst festlegt, wie Gebäude, Räume, Anlagen und weitere Informationen beschrieben und miteinander verbunden werden.

Herkunftshoheit bedeutet, dass nachvollziehbar bleibt, woher Informationen stammen, wer sie verantwortet und wie sie sich verändert haben.

Betriebshoheit bedeutet, dass die dafür notwendige Informationsinfrastruktur unter eigener Kontrolle betrieben werden kann.

Digitale Souveränität entsteht aus dem Zusammenspiel dieser drei Ebenen.

Gemeinsame Sprache statt „Single Source of Truth“

Der häufig verwendete Begriff einer „Single Source of Truth“ greift für diese Aufgabe zu kurz. Er legt nahe, dass es für ein Gebäude eine zentrale Quelle geben müsse, aus der alle anderen Systeme ihre Wahrheit beziehen. In der Praxis gibt es jedoch unterschiedliche fachlich verantwortete Quellen.

Beim Beispiel der Seminarräume könnte die Zuordnung so aussehen:

Die konkrete Zuordnung unterscheidet sich von Organisation zu Organisation. Entscheidend ist das Prinzip: „Nicht jedes System muss jede Information besitzen. Die Organisation muss aber wissen, welche Quelle für welche Information maßgeblich ist und wie die Informationen zusammenhängen.“

Data Mesh beschreibt dafür einen organisatorischen Ansatz: Datenverantwortung bleibt möglichst dort, wo die fachliche Kompetenz liegt. Die einzelnen Bereiche stellen ihre Informationen in einer vereinbarten Form bereit, sodass andere Bereiche sie nutzen können.

Damit entsteht keine zentrale Wahrheit, sondern ein Netz fachlich verantworteter Informationen. Eine gemeinsame Sprache sorgt dafür, dass aus diesem Netz kein neues Durcheinander entsteht. Wenn das ERP von „Objekt 4711“, die Vermietung vom „Seminarzentrum 1.OG“ und das BIM-Modell von einem Raum mit eigener GUID sprechen, muss die Informationsarchitektur diese Bezüge verständlich machen können.

Warum ist der Raum heute so, wie er ist?

Nach einigen Jahren ist im System nur noch Raum C sichtbar. Für den aktuellen Betrieb mag das zunächst genügen. Spätestens bei einem Umbau, einer Prüfung oder einer Datenbereinigung wird jedoch die Vorgeschichte relevant.

Warum gibt es Raum C? Welche beiden Räume gab es vorher? Wann wurde die Trennwand entfernt? Warum existiert die ehemalige Tür nicht mehr? Woher stammt die aktuelle Fläche? Wann wurde die Vermietung auf den neuen Raum umgestellt?

Solche Fragen führen zur Herkunft und Entwicklung der Information. Im Datenmanagement wird dafür häufig der Begriff Data Lineage verwendet.

Für den Immobilienbetrieb lässt sich das untechnisch als nachvollziehbare Informationsgeschichte verstehen: Aus Raum A + Raum B + Tür T17 wird durch einen dokumentierten Umbau Raum C.

Die geometrische Veränderung kann aus dem BIM-Modell kommen. Die neue Kapazität stammt aus der Vermietung. Die kaufmännische Zuordnung wird im ERP geändert. Die einzelnen Fachbereiche behalten ihre Verantwortung, gleichzeitig bleibt nachvollziehbar, welche Veränderungen miteinander zusammenhängen.

Das ist mehr als technische Protokollierung. Für einen Betreiber entscheidet diese Nachvollziehbarkeit darüber, ob Informationen später erklärt, geprüft, korrigiert und für neue Zwecke verwendet werden können.

Die ISO 19650 entwickelt sich in Richtung Asset Lifecycle weiter

Auch die laufende Revision der ISO 19650 ist in diesem Zusammenhang interessant. Die derzeit gültige ISO 19650-1:2018 beschreibt Informationsmanagement bereits über den gesamten Lebenszyklus eines gebauten Assets. Der aktuelle Revisionsentwurf ISO/DIS 19650-1 legt diesen Lebenszyklusgedanken nochmals stärker in den Mittelpunkt und befindet sich weiterhin im Revisionsprozess.

Dr. Volker Krieger, langjähriges Mitglied der zuständigen internationalen Arbeitsgruppe, beschreibt im Juni 2026 in einem Interview mit buildingSMART Deutschland die bisherige Trennung zwischen Projekt- und Assetmanagement als einen „Geburtsfehler“ der ersten Fassung. Die modernere Perspektive sei der Asset Lifecycle. Informationsfluss soll entsprechend nicht als isoliertes Projekt mit einer Datenübergabe am Ende verstanden werden, sondern als Teil eines Lebenszyklus.

Für die vorliegende Fragestellung ist das relevant, ohne den noch nicht abgeschlossenen Normungsprozess überzuinterpretieren.

Die ISO 19650 beantwortet nicht, welches konkrete Softwaresystem ein Immobilienbetreiber einsetzen sollte. Sie liefert Begriffe, Konzepte und Prozesse für das Informationsmanagement. Der aktuelle Draft empfiehlt zudem freie und offene Standards, bleibt aber bewusst technologieoffen.

Der Perspektivwechsel passt jedoch zu einer Realität, die Betreiber täglich erleben: Informationen entstehen nicht einmalig im Bauprojekt. Sie werden im Betrieb ergänzt, korrigiert und neu erzeugt. Umbauten verändern den Bestand. Vermietung und Nutzung verändern sich. Anlagen werden ausgetauscht. Anforderungen kommen hinzu.

Informationsmanagement endet deshalb nicht mit der Übergabe eines BIM-Modells. 

Standards sind notwendig – aber sie führen sich nicht selbst aus

Die Bau- und Immobilienwirtschaft verfügt bereits über zahlreiche Standards, Datenmodelle und Regelwerke. Sie können Begriffe definieren, Informationsanforderungen formulieren oder den Austausch zwischen Systemen vereinheitlichen.

Das ist eine notwendige Grundlage für Interoperabilität.

Es löst aber noch nicht das organisatorische Problem eines Betreibers.

Ein Standard verbindet nicht automatisch das BIM-Modell eines Gebäudes mit den Raumdaten der Vermietung. Er klärt nicht von selbst, dass zwei unterschiedliche Identifikatoren dasselbe reale Objekt meinen. Er entscheidet nicht, welcher Fachbereich eine Information verantwortet. Und er betreibt keine dauerhaft verfügbare Infrastruktur, in der Herkunft, Rechte und Beziehungen nachvollziehbar bleiben.

Eine Informationsschicht muss diese Standards dafür nicht ersetzen. Sie kann etablierte Standards wie IFC, IBPDI oder RealEstateCore implementieren und an ihren Rändern miteinander verbinden, statt einen weiteren, eigenen Standard hinzuzufügen.

Damit verschiebt sich die Frage: Braucht die Immobilienwirtschaft wirklich noch einen weiteren Standard – oder braucht sie zunehmend Systeme, mit denen vorhandene Standards und Datenmodelle praktisch angewendet werden können?

Für einen Betreiber ist letztlich nicht entscheidend, dass eine gemeinsame Sprache auf dem Papier existiert. Sie muss im täglichen Informationsfluss funktionieren.

Eine Informationsschicht zwischen den Fachwelten

Dafür ist eine zusätzliche Informationsschicht denkbar, die nicht versucht, die vorhandenen Fachsysteme zu ersetzen.

Sie muss weder das nächste CAFM-System noch das nächste BIM-System sein. Ihre Aufgabe besteht darin, Informationen aus unterschiedlichen Fachwelten verständlich miteinander zu verbinden.

Eine solche Schicht müsste beispielsweise:

• unterschiedliche Informationsquellen anbinden können,
• gemeinsame Begriffe und Identitäten verwalten,
• Beziehungen zwischen Informationen abbilden,
• fachliche Verantwortlichkeiten respektieren,
• Herkunft und Veränderungen nachvollziehbar machen,
• Zugriffe und Nutzungsrechte steuern,
• und unterschiedliche Anwendungen auf derselben Informationsgrundlage ermöglichen.

Man kann sie bildlich als ein „Betriebssystem für Betreiberdaten“ verstehen: nicht als Betriebssystem eines Rechners, sondern als dauerhaft verfügbare Grundlage, auf der unterschiedliche Fachanwendungen miteinander arbeiten können.

Wichtig ist dabei der hybride Ansatz.

Das BIM-Modell bleibt dort Quelle, wo es die geeignete Quelle ist. Das ERP bleibt ERP. Die Vermietung behält ihre Fachlogik. Bestehende CAFM- und GIS-Systeme müssen nicht zunächst abgelöst werden. Selbst Excel-Daten können als Ausgangspunkt eingebunden werden.

Die gemeinsame Informationsschicht sorgt nicht dafür, dass alle Systeme dasselbe wissen. Sie sorgt dafür, dass ihre Informationen anschlussfähig werden.

Eine gemeinsame Sprache allein reicht dafür allerdings nicht aus. Begriffe können noch so einheitlich definiert sein: Wenn nirgendwo festgehalten ist, welches konkrete Objekt mit welchem anderen zusammenhängt, bleibt die Verbindung zwischen den Systemen unvollständig. Es reicht nicht, dieselben Begriffe zu verwenden – die tatsächlichen Objekte müssen über Fachgrenzen hinweg konkret miteinander verknüpft und diese Verknüpfungen dauerhaft festgehalten werden.

Für den Seminarraum aus dem Eingangsbeispiel heißt das: Ein Sensor ist in einem bestimmten Raum verbaut. Die frühere Tür T17 war über eine Brandmeldezentrale sicherheitstechnisch mit einem bestimmten Melder verknüpft. Und ein vollständiges Raumprofil ergibt sich erst, wenn Geometrie aus der Bauabteilung, Wartungsdaten aus dem CAFM-System, Belegungsdaten aus der Vermietung und Klimadaten aus der Gebäudeautomation zusammengeführt werden. Solche Verbindungen entstehen im laufenden Betrieb, oft erst beim Einbau oder bei der Instandhaltung. Kein Planungsmodell bildet sie vorab ab.

Warum künstliche Intelligenz auf verknüpfte Objekte angewiesen ist

Ein wachsender Anwendungsfall für eine solche Informationsschicht ist der Einsatz KI-gestützter Assistenzsysteme im Immobilienbetrieb – etwa um Fragen zum Bestand zu beantworten, Auffälligkeiten zu erkennen oder Auswertungen automatisiert zu erstellen.

Ein Sprachmodell kann Texte aus unterschiedlichen Systemen lesen und sprachlich sinnvoll zusammenfassen. Es weiß aber nicht von sich aus, dass sich eine Meldung aus dem CAFM-System, eine Kostenstelle im ERP und ein Raum im BIM-Modell auf dasselbe reale Objekt beziehen, solange diese Verbindung nirgendwo festgehalten ist. Ohne einen solchen Bezug bleibt der KI nur, plausibel klingende Zusammenhänge zu vermuten – mit dem Risiko, dass daraus falsche oder nicht belastbare Aussagen entstehen.

Sind die Objekte dagegen konkret miteinander verknüpft, kann eine KI-Anwendung auf gesicherten Beziehungen aufsetzen, statt sie aus Freitext zu erraten. Eine Frage wie „Welche Räume mit überfälliger Wartung stehen aktuell leer?“ lässt sich dann zuverlässig beantworten, weil Raum, Wartungsstatus und Belegung nachvollziehbar demselben Objekt zugeordnet sind – nicht, weil ein Sprachmodell die passenden Begriffe in verschiedenen Dokumenten zufällig richtig kombiniert.

Damit wird dieselbe Grundlage, die Bedeutungs- und Herkunftshoheit für Menschen schafft, auch zur Voraussetzung für belastbare KI-Ergebnisse.

Die Souveränitätsschicht muss betreibbar sein

Diese Anforderung lässt sich allerdings nicht allein auf dem Papier lösen. Es reicht nicht, Beziehungen, Verantwortlichkeiten und Herkunft konzeptionell zu beschreiben – dafür braucht es eine konkrete, betreibbare Software. Sonst droht derselbe Weg, den viele Standards in der Bau- und Immobilienwirtschaft bereits gegangen sind: Jahre der Abstimmung, bevor überhaupt praxistaugliche Werkzeuge entstehen.

Den Gegenbeweis liefert gerade die aktuelle KI-Entwicklung: Standards setzen sich dort besonders schnell durch, wenn von Anfang an eine aktive Implementierung mitgeliefert wird, statt nur eine Spezifikation zu veröffentlichen. Ein Beispiel ist das Model Context Protocol (MCP), das sich innerhalb weniger Monate branchenübergreifend durchgesetzt hat – nicht weil das Dokument überzeugender war als andere, sondern weil von Beginn an lauffähige Software dazu verfügbar war.

Die Souveränitätsschicht darf nicht zum nächsten Lock-in werden

Genau diese Software wirft aber eine eigene Frage auf. Wenn sie langfristig eine zentrale Rolle für ein Immobilienportfolio übernimmt, entsteht ein neues Problem.

Was passiert, wenn genau diese Software wiederum vollständig von einem einzelnen Anbieter und dessen Cloud abhängig ist?

Dann wären zwar verschiedene Datensilos miteinander verbunden, die strategische Abhängigkeit würde aber lediglich eine Ebene verschoben.

Die Gegenposition – jeder Betreiber entwickelt seine eigene Plattform – ist ebenso wenig überzeugend. Immobilienunternehmen wollen Gebäude und Portfolios bewirtschaften. Sie wollen in aller Regel kein eigenes Softwareprodukt mit Release-Management, Sicherheitsupdates, Fehlerbehebung und langfristiger Produktpflege entwickeln.

Auch die bloße Veröffentlichung von Quellcode löst dieses Problem nicht automatisch. Eine für den Betrieb relevante Software benötigt aktive Wartung. Abhängigkeiten müssen aktualisiert, Sicherheitslücken geschlossen, Schnittstellen gepflegt und neue Anforderungen umgesetzt werden.

Digitale Souveränität darf deshalb nicht mit „alles selbst machen“ verwechselt werden.

Source Available: Kontrolle ohne Selbstbau

An dieser Stelle wird das Lizenz- und Geschäftsmodell Teil der Architekturfrage. Unter einem Source-Available-Modell lässt sich in diesem Zusammenhang ein Ansatz verstehen, der zwei Interessen miteinander verbindet: Die Organisation soll die Software und ihre Daten unter eigener Kontrolle betreiben können. Gleichzeitig muss es einen wirtschaftlich tragfähigen Hersteller geben, der die Software aktiv weiterentwickelt und wartet.

Das unterscheidet sich sowohl von einer vollständig geschlossenen Plattform als auch von einem Open-Source-Projekt, bei dem langfristige Pflege und Produktverantwortung unklar sind.

Für einen Betreiber ist die Zielsetzung pragmatisch: Ich möchte die Informationsinfrastruktur in meinem Unternehmen betreiben können, ohne sie selbst bauen und dauerhaft warten zu müssen.

Ein solches Modell kann Quellcodezugang, eigene Betriebsfähigkeit und Erweiterbarkeit mit professioneller Maintenance, Releases, Support und Service Levels verbinden.

Entscheidend ist die Balance. Die Software soll wirtschaftlich weiterentwickelt werden können, ohne die Informationsbasis des Kunden in einer proprietären Sackgasse einzuschließen.

Nicht alles modellieren – alles anschlussfähig machen

Zurück zu den beiden Seminarräumen.

Nach dem Umbau muss die Vermietung keine BIM-Software bedienen. Das BIM-Modell muss keine Buchungspreise speichern. Das ERP muss die ehemalige Tür nicht kennen. Und der technische Betrieb muss keine eigene Kopie sämtlicher kaufmännischer Informationen führen.

Trotzdem sollte die Organisation eindeutig nachvollziehen können, dass alle Beteiligten über denselben neuen Raum sprechen. Sie sollte wissen, wer welche Information verantwortet und woher diese Information stammt. Und sie sollte Informationen für neue Aufgaben verwenden können, ohne sie jedes Mal aus verschiedenen Systemen manuell neu zusammensuchen zu müssen.

Das ist für große Bestandsportfolios wichtiger als die Vorstellung eines vollständig modellierten digitalen Abbilds, das alle Informationen in sich vereint.

Digitale Souveränität bedeutet deshalb nicht, sämtliche Informationen in ein einziges Modell oder System zu überführen. Sie bedeutet, die vorhandenen Informationsquellen so miteinander zu verbinden, dass das Unternehmen selbst über Bedeutung, Herkunft und Verwendung seiner Daten bestimmen kann.

Dafür braucht es offene Standards. Aber es braucht ebenso eine Software, die diese Standards im Unternehmen anwendbar macht – dauerhaft betreibbar, wirtschaftlich gepflegt und ohne die nächste unnötige Abhängigkeit zu schaffen.