BIM-Standardisierung: Projekte an mehreren Standorten effizient und lokal angepasst verwalten

Die BIM-Standardisierung ist einer der Hauptfaktoren für Effizienz in Multi-Standort-Programmen, die auf reproduzierbaren Modellen basieren. Sie ermöglicht die Definition eines gemeinsamen Informationsprototyps, dessen Wiederverwendung an mehreren Standorten und die Aufrechterhaltung der Konsistenz zwischen Planung, Bau und Verwaltung des Assets. Standardisierung bedeutet jedoch nicht, dass dasselbe Projekt überall kopiert wird. Jeder Standort erfordert Anpassungen an rechtliche, technische, klimatische, logistische und operationale Gegebenheiten.

Eine wachsende Anzahl zeitgenössischer Bauprogramme besteht nicht mehr nur in der Planung eines einzelnen Gebäudes, sondern in der koordinierten Verwaltung eines gemeinsamen Prototyps an Dutzenden oder Hunderten von Standorten. Dies gilt für Hotelketten, die denselben Markenstandard in verschiedenen Ländern anwenden, für Gesundheitsdienstleister, die modulare Krankenhäuser in Regionen mit unterschiedlichen regulatorischen Rahmenbedingungen replizieren, für Einzelhandelsnetzwerke, die neue Verkaufsstellen gemäß einem Corporate-Manual eröffnen, für öffentliche Programme, die Schulen oder Verkehrsstationen standardisieren, sowie für Wohnungsentwickler, die Wohnformen industrialisieren und Hyperscaler, die Rechenzentren basierend auf einem Typenprojekt in mehreren Märkten bauen.

All diese Programme teilen dasselbe zugrunde liegende Problem: Der wirtschaftliche Wert entsteht aus der Standardisierung, während die Durchführbarkeit aus der Lokalisierung resultiert. Einmal zu entwerfen, einmal zu validieren und viele Male zu replizieren, schafft Skaleneffekte, reduziert das Risiko und beschleunigt die Lieferung. Jede Replikation muss jedoch mit Bauvorschriften, städtebaulichen Auflagen, klimatischen Bedingungen, verfügbaren Materialien, Kapazität der lokalen Lieferkette, kulturellen Sensibilitäten und nationalen BIM-Vorgaben konfrontiert werden.

Zu viel Standardisierung kann ein nicht genehmigungsfähiges, nicht funktionierendes oder nicht mit den lokalen Erwartungen übereinstimmendes Gebäude erzeugen. Zu viel Lokalisierung kann die wirtschaftlichen Vorteile der Replikation zunichte machen.

Die These dieses Artikels ist, dass die BIM-Standardisierung nur funktionieren kann, wenn sie als informationsgestützter Programmprozess gesteuert wird, nicht als einfacher Wiederverwendung von Modellen oder Dateien. In dieser Perspektive sind ISO 19650, CDE, openBIM, IFC, BCF, bSDD und IDS keine separaten Themen, sondern Komponenten einer einzigen Managementarchitektur: derjenigen, die es einem Masterprototyp ermöglicht, repliziert, angepasst, überprüft und während des gesamten Lebenszyklus des Assets konsistent gehalten zu werden.

Was ist die BIM-Standardisierung in reproduzierbaren Programmen?

Die BIM-Standardisierung ist der Prozess, durch den eine Organisation Regeln, Informationsmodelle, Voraussetzungen, Arbeitsabläufe, Klassifikationen und gemeinsame Verfahren definiert, um die Verwaltung von Projekten und Vermögenswerten konsistenter und wiederholbarer zu gestalten.

In einem einzelnen Projekt bedeutet Standardisierung oft, Vorlagen, Kodierungen, Austauschformate, Benennungsrichtlinien, Informationsniveaus und Genehmigungsverfahren zu vereinheitlichen. In einem reproduzierbaren Programm hingegen hat die BIM-Standardisierung eine breitere Bedeutung: Sie muss das Verhältnis zwischen einem Masterprototyp und vielen lokalen Instanzen steuern.

Ein reproduzierbares BIM-Programm kann als eine koordinierte Gruppe von Projekten definiert werden, die auf einem gemeinsamen Informationsprototyp basieren und an verschiedene lokale Kontexte angepasst sind. Diese Definition ist wichtig, da sie klarstellt, dass die Replikation nicht nur die Geometrie des Gebäudes betrifft, sondern auch Daten, Voraussetzungen, Entscheidungsprozesse, Verantwortlichkeiten, Informationsaustausch und Validierungskriterien.

Die BIM-Standardisierung entspricht daher nicht der Duplikation eines Modells. Es handelt sich um eine Governance-Strategie, die festlegt, was unverändert bleiben muss, was lokalisiert werden kann, wer eine Abweichung genehmigen kann, wie eine Variante verfolgt wird und wie die Informationen in das Informationsvermögen der Organisation zurückfließen.

In diesem Zusammenhang ist die Frage nicht: „Können wir dasselbe BIM-Modell wiederverwenden?“. Die korrekte Frage lautet: Können wir die Beziehungen zwischen einem Informationsmaster und seinen lokalen Varianten nachvollziehbar steuern?

Warum bedeutet die Standardisierung eines Multi-Site-BIM-Programms nicht, dass dasselbe Projekt kopiert wird?

Missverständnis Nummer eins ist zu denken, dass ein reproduzierbares Programm eine Sequenz von Kopien ist. In Wirklichkeit ist ein reproduzierbares Programm eine Sequenz kontrollierter Anpassungen.

Der Wert des Masterprototyps liegt in seiner Fähigkeit, bereits validierte Entscheidungen zu konzentrieren: Layouts, technische Systeme, Leistungsanforderungen, Informationsvoraussetzungen, Standardobjekte, Koordinierungsschemata und Operationslogiken. Aber kein Master kann in jedem Land oder an jedem Standort identisch angewendet werden.

Ein Rechenzentrum in Australien unterliegt nicht dem gleichen Genehmigungsrahmen wie ein Rechenzentrum in Deutschland. Ein modulares Krankenhaus, das in mehreren Regionen repliziert wird, muss sich mit unterschiedlichen Gesundheitsanforderungen und Akkreditierungen auseinandersetzen. Ein Verkaufsstandort in einem historischen europäischen Zentrum muss sich an städtebauliche Auflagen anpassen, die sich von denen eines Einzelhandelsparks außerhalb der Stadt unterscheiden. Eine öffentliche Schule muss möglicherweise je nach Region unterschiedliche energetische, erdbebensichere und barrierefreie Standards einhalten.

Deshalb beseitigt eine effektive BIM-Standardisierung nicht die Lokalisierung. Sie macht sie steuerbar.

Standardisierung bedeutet, einen stabilen Informationskern und ein kontrolliertes System von Variationen zu definieren. Der Masterprototyp stellt den Kern dar. Die lokalen Varianten repräsentieren die Anpassungen. Das CDE, wenn es auf Programmebene konfiguriert ist, ist die Umgebung, in der Master und Varianten verbunden bleiben. ISO 19650 liefert die Prozessgrammatik. Der openBIM® Stack macht Modelle, Issues, Klassifikationen und Anforderungen portabel.

Der BIM-Masterprototyp

Der BIM-Masterprototyp ist das Referenzmodell des Programms. Es handelt sich nicht nur um ein geometrisches Modell, sondern um einen Container für technische Entscheidungen, Informationsanforderungen, Koordinierungslogiken und Validierungskriterien.

Im Masterprototyp können folgende Aspekte definiert werden:

• wiederkehrende Layouts und räumliche Konfigurationen;
• standardisierte Tragwerks- und TGA-Systeme;
• BIM-Objekte und Property Sets;
• Klassifikationen und Nomenklaturen;
• Informationsanforderungen OIR, AIR, PIR und EIR;
• Regeln für interdisziplinäre Koordination;
• Lieferstandards für Bau und Betrieb;
• Validierungskriterien für Informationen über IDS.

In einem ausgereiften Programm darf der Master nicht frei kopiert und modifiziert werden. Er muss versioniert, gesteuert und mit seinen Instanzen verknüpft sein. Wenn eine Änderung am Master genehmigt wird, sollte jeder aktive Rollout für eine Impact-Überprüfung gemeldet werden. Das Team muss verstehen können, welche Standorte betroffen sind, welche lokalen Varianten in Konflikt geraten können und welche Genehmigungen aktualisiert werden müssen.

Dies ist einer der Hauptunterschiede zwischen einer einfachen Modellbibliothek und einer echten Strategie zur BIM-Standardisierung.

Die versionierten lokalen Varianten

Die lokalen Varianten sind die Anpassungen des Masterprototyps, die von einem konkreten Kontext gefordert werden. Sie können aus Brandschutzvorschriften, energetischen Anforderungen, klimatischen Bedingungen, Verfügbarkeit von Materialien, Kapazität der Lieferkette, städtebaulichen Auflagen, nationalen Vorschriften oder operativen Entscheidungen resultieren.

Eine lokale Variante sollte kein eigenständiger Abzug des Masters sein. Sie sollte ein versioniertes Delta sein: eine strukturierte, gerechtfertigte und mit der Regel oder dem Erfordernis verbundene Änderung, die sie hervorgebracht hat.

Wenn beispielsweise eine nationale Brandschutzvorschrift eine Abweichung vom Masterprototyp vorschreibt, sollte diese Abweichung mit folgenden Punkten dokumentiert werden:

• Verweis auf die geänderte Klausel des Masters;
• Verweis auf die lokale Norm oder Anforderung;
• betroffene Disziplin;
• verantwortliche Person für die Entscheidung;
• Genehmigungsdatum;
• Auswirkungen auf Kosten, Zeit, Genehmigungen und Abläufe;
• Kompatibilität mit zukünftigen Änderungen des Masters.

Dieser Ansatz verhindert, dass die Varianten in unkontrollierte Fragmentierung umschlagen. Wenn der Master aktualisiert wird, kann die Plattform überprüfen, welche Varianten potenziell betroffen sind. Wenn dieselbe Abweichung in mehreren Ländern auftritt, kann dies ein Signal sein: Vielleicht muss der Master korrigiert werden.

Der Masterprototyp BIM und lokale Varianten

Die Rolle der ISO 19650 in der BIM-Standardisierung

Die ISO 19650-Serie wird häufig zitiert, aber manchmal auf einen Projektstandard reduziert. In Wirklichkeit ist ihre Struktur besonders nützlich in reproduzierbaren Programmen, da sie es ermöglicht, Projektinformationen, Vermögenswerte und Organisationen zu verknüpfen.

Im Hinblick auf die BIM-Standardisierung dient die ISO 19650 nicht nur dazu, festzulegen, wie Dateien ausgetauscht oder Lieferungen genehmigt werden. Sie dient dazu, zu bestimmen, wie Informationen angefordert, produziert, überprüft, geteilt, veröffentlicht und archiviert werden müssen, während des Lebenszyklus des Vermögenswerts.

Die ISO 19650-1 legt eine Hierarchie der Informationsanforderungen fest, die ausdrücklich auf Ebene des Vermögenswerts und des Programms arbeitet:

• Organizational Information Requirements (OIR), also die Informationsanforderungen der Organisation;
• Asset Information Requirements (AIR), also die Informationsanforderungen des Vermögenswerts;
• Project Information Requirements (PIR), also die Informationsanforderungen des Projekts;
• Exchange Information Requirements (EIR), also die Informationsanforderungen für den Austausch.

Der PIR ist die einzige Anforderung zu Projektzwecken. Die anderen drei existieren genau, um die Informationskontinuität über mehrere Projekte hinweg auf einem gemeinsamen Vermögenswert oder durch ein Programm verwandter Vermögenswerte zu steuern.

Für einen Betreiber, der ein Vermögensportfolio verwaltet – sei es ein Hyperscaler, ein nationaler Gesundheitsdienstleister, eine Hotelkette oder eine öffentliche Verwaltung, die ein Programm für Schulbau verwaltet – beantwortet das OIR die Frage: Welche Informationen benötigt die Organisation, um Entscheidungen über das Programm und das Portfolio zu treffen?

Das AIR befasst sich mit dem Facility Management: Welche Lieferdaten sind erforderlich, um diesen Vermögenswert in den nächsten fünfzehn Jahren zu betreiben?

Der PIR wird vom Team des einzelnen Rollouts verwaltet. Das EIR ist das, was jedem Teilnehmer der Lieferkette an jedem Standort auferlegt wird.

Vom CDE des Projekts zum CDE des Programms

Das Common Data Environment, oder CDE, wird oft als digitaler Raum zum Hochladen, Teilen und Genehmigen von Dateien interpretiert. Diese Sichtweise ist jedoch einschränkend, insbesondere bei reproduzierbaren Programmen.

In einem einzelnen Projekt organisiert das CDE Informationscontainer, Bearbeitungsstände, Revisionen, Genehmigungen und Archivierung. In einem BIM-Programm mit mehreren Standorten muss das CDE mehr leisten: Es muss die Beziehung zwischen Masterprototyp und lokalen Instanzen modellieren.

Ein CDE auf Programmebene behandelt jede Einführung nicht als isolierte Projektumgebung. Es behandelt den Masterprototyp als Informationscontainer auf Programmebene, wobei jede Standorteinführung als Tochterinstanz fungiert, die Informationen erbt, lokalisiert und zurückgibt. Das Modell der Informationsstände, die ISO 19650 definiert — Work in Progress, Shared, Published, Archived — funktioniert sowohl auf Master- als auch auf Instanzebene, mit expliziten Propagierungsregeln zwischen den beiden Ebenen.

Das Konzept mag abstrakt erscheinen, aber die operativen Konsequenzen sind konkret. Die Genehmigung einer strukturellen Revision des Masterprototyps sollte beispielsweise eine Wirkungsprüfung für alle betroffenen Rollout-Instanzen aktivieren. Wenn ein nationaler Brandschutzcode eine Abweichung vom Master erfordert, wird diese als lokalisierte Variante erfasst, mit vollständiger Rückverfolgbarkeit der Begründung und Verknüpfung sowohl mit der Ursprungsnorm als auch mit der modifizierten Masterklausel. Ebenso kann eine Quermodifikation, die vom Programmoperator gefördert wird — wie der Austausch eines Kältemittels gemäß der F-Gas-Verordnung, ein Upgrade der Sicherheitssysteme oder eine Aktualisierung der energetischen Spezifikation — im gesamten Portfolio mit Audit-Rückverfolgbarkeit verwaltet werden.

Ein CDE für Projektzwecke kann dies nicht leisten. Ein korrekt konfiguriertes CDE für Programmzwecke behandelt dies als Standardverhalten.

Drei Druckpunkte in der BIM-Standardisierung von Multi-Site-Programmen

Die BIM-Standardisierung wird insbesondere dann kritisch, wenn sie auf drei zentrale Herausforderungen trifft: die länderübergreifende Lokalisierung, die hochdichte fachübergreifende Koordination zusammengeführter Modelle und die kontinuierliche Bereitstellung von Informationen für die Betriebsphase.

Diese werden am extremsten durch Hyperscale-Datenzentren veranschaulicht, gelten jedoch für jedes im BIM verwaltete Replikationsprogramm.

Drei Druckpunkte der BIM-Standardisierung in reproduzierbaren Programmen

Multi-Länder-Lokalisierung des standardisierten Prototyps

Ein reproduzierbares Programm, das denselben Prototyp in fünf Ländern verteilt, sieht sich fünf unterschiedlichen regulatorischen Umgebungen gegenüber, noch bevor andere Variablen berücksichtigt werden.

Im Fall von Hyperscale-Datenzentren sind der australische National Construction Code und der Bauzertifizierungsprozess von New South Wales nicht mit den deutschen Bauvorschriften austauschbar. Die indischen CPWD-Spezifikationen regeln die Schnittstellen zur öffentlichen Infrastruktur auf eine Weise, die die europäischen Normen nicht vorsehen; die malaysischen Brandschutzstandards und die mexikanische NOM-Regulierungsfamilie legen Spezifikationen fest, die den Prototyp an verschiedenen Punkten betreffen. Dieselbe Logik gilt für Krankenhausprogramme (nationale Akkreditierungsregime im Gesundheitswesen), für Schulprogramme (regionale Sicherheits- und Zugänglichkeitsanforderungen), für Einzelhandelsketten (städtebauliche Vorschriften und Vorschriften für historische Zentren) und für Verkehrsinfrastrukturen (technische Spezifikationen der Betreiber). Über all dem liegt die regulatorische Drift hin zu nationalen BIM-Vorgaben: die portugiesische BIM-Pflicht bis 2030 gemäß Resolução do Conselho de Ministros n.º 89/2026, die italienischen Schwellenwerte des DM 312/2021, das UK BIM Framework, die deutsche BIM-Strategie und die aufkommenden Verpflichtungen in NSW und Singapur.

Ein CDE auf Programmebene verwaltet diese Vielfalt durch die versionierte Lokalisierung: Der Masterprototyp lebt im Root des Programms, jede nationale Instanz bringt ihr eigenes Lokalisierungsdelta mit, und das Delta ist selbst ein versioniertes und prüfbares Artefakt. Wenn eine lokale Vorschrift eine Abweichung vorschreibt, ist diese Abweichung keine Kopie des Masters mit Änderungen; es handelt sich um eine strukturierte Variante, deren Beziehung zum Master explizit und abfragbar bleibt. Wenn der Master aktualisiert wird, wird die Variante automatisch auf Kompatibilität und Konflikte überprüft, und das Planungsbüro wird über jede Instanz informiert, die eine erneute Validierung erfordern könnte.

Dies ist der Unterschied zwischen einem CDE, das Dateien hostet, und einem CDE, das die strukturelle Beziehung zwischen einem Masterdesign und seinen Varianten auf Programmebene modelliert. Das erste skaliert linear mit dem Aufwand; das zweite skaliert sublinear, da die Plattform selbst die Regeln der Propagation kodiert.

Koordination bei hoher Anlagendichte und interdisziplinärer Komplexität

Die zweite Herausforderung betrifft die Koordination. Bei komplexen Programmen besteht die Herausforderung nicht nur darin, BIM-Modelle zu erstellen, sondern zahlreiche Fachdisziplinen kontinuierlich aufeinander abzustimmen.

Die Anlagendichte eines Rechenzentrums ist nicht mit der TGA eines konventionellen Gebäudes vergleichbar. Die elektrische Verteilung muss Redundanz gewährleisten. Die Kühlsysteme können gekühltes Wasser, CRAH-Einheiten, Flüssigkeitskühlung und Free Cooling kombinieren. Der Brandschutz kann Frühwarnsysteme und Löschsysteme integrieren. Das Netzwerk-Design kann Dichtevorgaben auferlegen, die mit Anlagen, Strukturen und Architektur interferieren. Dieses Prinzip erstreckt sich auf viele andere Anlagen: Krankenhäuser, pharmazeutische Labore, Halbleiterfabriken, Verkehrsinfrastrukturen, Energieanlagen, Flughäfen und große öffentliche Komplexe.

Ein BIM-Workflow mit koordinierten Fachmodellen in einem solchen Programm umfasst typischerweise zwanzig oder mehr kontinuierlich abgestimmte Fachmodelle. Dabei werden zu jedem Zeitpunkt Hunderte von Clashs und Issues zur baulichen Umsetzbarkeit bearbeitet und gelöst. Das BIM Collaboration Format (BCF) ist die operative Sprache dieser Koordinierung, jedoch nur, wenn das CDE BCF als erstklassiges Workflow-Objekt behandelt und nicht als Dateianhang. Die Probleme müssen über organisatorische Grenzen hinweg zuweisbar, auf Modellversionen zurückführbar, mit Designentscheidungen des Masterprototyps verknüpfbar und durch die Programminstanzen abfragbar sein, um wiederkehrende Muster zu erkennen — ein Clash, der in drei Rollouts von zwölf auftritt, ist kein Zufall; es handelt sich um ein Designproblem auf Masterebene, das als lokales Problem maskiert ist.

Das native openBIM-Management des BCF, wie es in Umgebungen wie usBIM.bcf implementiert ist, existiert aus diesem Grund: um der Programmabwicklung denselben operativen rigor zu verleihen, den die Branche seit langem auf Zeichnungen und Dokumente anwendet.

Nachvollziehbare Kontinuität der Informationen zwischen Design, Bau und Betrieb

Der dritte Druckpunkt betrifft die Informationskontinuität. Ein komplexes Asset endet nicht mit der Übergabe der Baustelle.
Ein Rechenzentrum kann eine Betriebsdauer von fünfzehn oder zwanzig Jahren haben. Ein Krankenhaus kann jahrzehntelang in Betrieb bleiben. Eine Verkehrsinfrastruktur kann eine noch längere Lebensdauer haben.

In diesen Fällen ist die Informationsübergabe keine Formalität zum Abschluss der Arbeiten. Sie ist die Grundlage des operativen digitalen Zwillings, der Wartung, des Retrofits und des Portfoliomanagements.

Das Problem der Übergabe ist akut, da die Informationen zu Design und Bau im Kontext eines Programms generiert wurden, aber an einen Betrieb übergeben werden, der das Asset ein Jahrzehnt oder länger verwalten wird. Das CDE muss nicht nur das As-Built-Modell bewahren, sondern auch die Nachverfolgbarkeit der Entscheidungen — welche Normklausel hat geleitet, welche Designentscheidung getroffen wurde, aus welcher Version des Prototyps stammt diese Instanz, gegen welche Standards wurden die Spezifikationen der Ausrüstung validiert.

Hier kommt die Information Delivery Specification, oder IDS, ins Spiel, die von buildingSMART als maschinenlesbares Schema zur Spezifikation und Überprüfung der Informationsanforderungen veröffentlicht wurde. IDS verwandelt OIR, AIR, PIR und EIR von subjektiv interpretierbaren PDF-Dokumenten in automatisch überprüfbare Regeln für IFC-Modelle.

Für ein reproduzierbares Programm ist die Konsequenz strategisch: Die Informationsanforderungen des Masterprototyps werden einmal als IDS-Programm ausgedrückt, jede lokalisierte Instanz kann ihr eigenes Delta-IDS hinzufügen, und jeder Informationsaustausch während der Lebensdauer des Assets — vom Designer zum Bauunternehmer, vom Bauunternehmer zum Facility Manager, vom Facility Manager zum nächsten Retrofit — wird automatisch gegen ihr eigenes IDS validiert.

In der Praxis bedeutet dies, dass die Übergabe an den Betrieb nicht mehr ein einmaliges Ereignis (ein Export, ein Dateitransfer, eine Checkliste) ist, sondern eine kontinuierliche Validierung: Das Asset Information Model muss ein IDS erfüllen, das die maschinenlesbare Übersetzung des AIR ist. Dieselbe Logik gilt während des Baus: Jeder Fortschrittsstatus kann gegen das IDS validiert werden, das die EIR für diese Phase ausdrückt. Und während der Entwicklung des Masterprototyps: Wenn das Programm das Master-IDS aktualisiert, wird jede Instanz automatisch auf nachträgliche Nichtkonformität hingewiesen. Es ist der Unterschied zwischen Anforderungen als in einem PDF geschriebenem Text und Anforderungen als validierbaren Regeln im Modell.

BIM-Standardisierung und geospatiale Integration

Die geospatiale Dimension ergänzt die BIM-Standardisierung, wenn ein Betreiber ein Portfolio von Vermögenswerten verwaltet, die über mehrere Länder verteilt sind: Standortanalysen zur Auswahl, Routing von Glasfaser in Rechenzentren oder Zugänglichkeit in Krankenhaus- und Einzelhandelsprogrammen, Validierung der energiepolitischen Strategie, die vom Klima geleitet wird, Telemetrie nach der Belegung im Vergleich zu Leistungszielen (PUE und WUE in Rechenzentren, EPC-Indikatoren im Wohnbau, klinische Indikatoren und Energieeffizienz-Indikatoren in Krankenhäusern).

Dafür sollte eine wirklich programmfähige BIM-Standardisierungsstrategie BIM-Daten mit territorialen Daten integrieren. Plattformen wie usBIM.geotwin integrieren die geospatiale Dimension innerhalb der BIM-Umgebung, anstatt sie als externes GIS-Layer zu behandeln — eine strukturelle Wahl, die erheblichen Einfluss darauf hat, wie ein Programm Entscheidungen zur Standortwahl und die Leistung nach der Belegung über ein globales Portfolio verwaltet.

Die Logik ist einfach: Ein reproduzierbares Programm existiert nicht nur in den Modellen, sondern an den Orten, an denen diese Modelle zu physischen Vermögenswerten werden.

Datensouveränität als strategische Entscheidung bei der CDE-Auswahl

Ein häufig unterschätzter Aspekt bei der Auswahl eines CDE ist die Datensouveränität. Bei länder- und rechtsraumübergreifenden Programmen sind der physische Speicherort und die rechtliche Governance der Datenumgebung keine reinen IT-Details. Sie sind strategische Programmentscheidungen.

Dies gilt insbesondere für Rechenzentren, Gesundheitswesen, kritische Infrastrukturen, Verteidigung, öffentliche Verwaltung und kommerzielle Programme mit sensibler Planungskompetenz.

Ein Betreiber, der dasselbe gemeinsame Informationsprototyp in mehreren Ländern vertreibt, muss wissen, wo die Daten gespeichert sind, unter welcher Jurisdiktion sie verarbeitet werden, welche Zugriffsrichtlinien gelten, wie die Rückverfolgbarkeit verwaltet wird und welche Garantien in Bezug auf die Compliance bestehen.

In Programmen, die mehrere Jurisdiktionen durchqueren, führt das Hosting des gesamten Planungs-Korpus auf einem CDE, das physisch außerhalb der Zieljurisdiktionen angesiedelt ist, zu einer Exposition, die von den Rechts- und Compliance-Funktionen immer weniger bereitwillig akzeptiert wird.

Die Frage ist operativ: Wo läuft das CDE, unter welchem Gesetz, mit welcher Rückverfolgbarkeit, mit welcher Konfigurierbarkeit der Datenresidenz? Für einen Betreiber, dessen Masterprototyp kommerziell sensible Ingenieurdaten enthält und dessen nationale Instanzen regulierte technische Informationen enthalten können, ist die Antwort auf diese Frage Teil der Programm-Governance und nicht eine Fußnote.

Dies begünstigt CDE-Anbieter mit konfigurierbarer Datenresidenz, transparenter juristischer Offenlegung und unabhängigen proprietären Strukturen, die das CDE nicht mit angrenzenden Plattforminteressen verknüpfen. Es tendiert auch dazu, Anbieter mit Sitz in Jurisdiktionen zu bevorzugen, die über etablierte Informationsschutzrahmen verfügen, anstatt in Jurisdiktionen, in denen die Datenhoheit über bestehende Infrastrukturen hinweg nachgerüstet wird. Für Planungsbüros und Betreiber in Europa verschiebt diese Überlegung die CDE-Auswahl von einer rein capability-basierten Entscheidung zu einer hybriden Entscheidung zwischen Capability und Governance.

Die Implikation für die Programmabwicklung ist, dass die Auswahl des CDE nicht vollständig der BIM-Funktion delegiert werden kann. Es muss eine gemeinsame Entscheidung zwischen der BIM-Leitung, der Rechtsabteilung, der Compliance und der Unternehmensfunktion, die für die Strategie der Informationssicherheit verantwortlich ist, sein.

Der standardisierte Prototyp in der Praxis: openBIM als Ermöglicher der Portabilität

Der standardisierte Prototyp funktioniert nur, wenn er tatsächlich portabel ist — über Entwurfsstudien, Geografien, Software-Ökosysteme und die gesamte Betriebsdauer des Assets. Portabilität ist kein Ziel; sie ist eine ingenieurtechnische Konsequenz des openBIM Stacks, korrekt angewendet.

IFC, BCF, bSDD und IDS spielen unterschiedliche, aber komplementäre Rollen:

• IFC regelt Geometrien, Objekte und Daten;
• BCF regelt Issues und Koordination;
• bSDD regelt Wörterbücher, Klassifikationen und Eigenschaften;
• IDS regelt überprüfbare Informationsanforderungen.

ISO 19650 steht über diesen Standards als Prozessgrammatik. Ohne ISO 19650 besteht die Gefahr, dass der openBIM Stack ein Set technischer Fähigkeiten bleibt. Mit ISO 19650 wird er Teil einer informationsgestützten Liefermethode.

Drei Druckpunkte der BIM-Standardisierung in reproduzierbaren Programmen

IFC4 für die Portabilität des Prototyps

IFC4 ist der Referenzstandard, um Modelle lesbar und interoperabel zu machen. In einem reproduzierbaren Programm genügt es jedoch nicht, am Ende der Planungsphase lediglich einen IFC-Export durchzuführen. Das Mastermodell muss von Beginn an so strukturiert werden, dass es portabel, validierbar und effizient mit weiteren Fachmodellen koordinierbar ist.

Ein Prototyp, der nur auf proprietären Formaten basiert, läuft Gefahr, in eine Lock-in-Situation zu geraten. Ein nach openBIM-Logik strukturierter Prototyp kann geöffnet, kontrolliert, angereichert und über die Zeit hinweg gepflegt werden, auch wenn Software, Teams oder Anbieter wechseln.

Für Programme, die darauf ausgelegt sind, länger zu bestehen als die einzelnen Anbieter und Entwurfsbüros, ist diese Portabilität kein nebensächlicher Vorteil. Sie ist eine Bedingung für Kontinuität.

BCF für Issues und Koordination

Das BIM Collaboration Format (BCF) erweitert dieses Prinzip im Bereich Koordination und Issues. BCF ermöglicht es, Konflikte, Entwurfsabsichten und Review-Issues zwischen Autorisierungsumgebungen zu bewegen, ohne den Kontext zu verlieren — essenziell, wenn der Masterprototyp und seine nationalen Instanzen von mehreren Entwurfsbüros während der Lebensdauer des Programms berührt werden können und wenn der Betreiber, der das Asset übernimmt, nicht notwendigerweise ein Kunde derselben Autorisierungssoftware ist, die vom Designer verwendet wurde.

bSDD für Klassifikationen und Eigenschaften

Das buildingSMART Data Dictionary (bSDD) behandelt vielleicht den am meisten unterschätzten Aspekt des Rollouts in mehreren Ländern: die Abweichung von Klassifikationen und der Nomenklatur von Eigenschaften. Der Masterprototyp ist gegen eine Taxonomie klassifiziert; die deutsche Variante muss sich an einen Satz nationaler Konventionen anpassen, die indische an einen anderen, die australische an einen dritten.

Ohne ein strukturiertes Wörterbuch, das diese Klassifikationen miteinander verknüpft und vermittelt, weichen die Varianten hinsichtlich ihrer Informationsstruktur unbemerkt vom Master ab – selbst dann, wenn die Geometrie weiterhin übereinstimmt. bSDD stellt diese Vermittlungsebene bereit; das CDE muss sie nativ unterstützen und nutzen können.

IDS für überprüfbare Informationsanforderungen

Die Information Delivery Specification (IDS) ist das neueste Element und in vielerlei Hinsicht das strategisch relevanteste für die Programmabwicklung. Während IFC das Modellformat ist, BCF das Koordinationsformat und bSDD das Klassifikationswörterbuch, ist IDS das Format der Informationsanforderungen: Es drückt in maschinenlesbarer Form aus, was das Modell enthalten muss, um bei einem bestimmten Austausch akzeptiert zu werden.

Für ein reproduzierbares Programm ist IDS das, was verhindert, dass lokal angepasste Varianten stillschweigend von den Anforderungen des Masters abweichen: Jede nationale Instanz kann IDS für die Lokalisierung hinzufügen, muss jedoch dennoch die IDS des Programms erfüllen. Es ist der Unterschied zwischen Anforderungen, die als Text in einem PDF ausgedrückt werden, und Anforderungen, die als validierbare Regeln im Modell vorliegen — der Unterschied letztendlich zwischen deklarierter Governance und überprüfbarer Governance.

Nativ openBIM CDE-Plattformen und BIM-Standardisierung

Eine CDE-Plattform, die nativ um den openBIM Stack herum entwickelt wurde, kann die BIM-Standardisierung kontrollierbarer machen als eine Plattform, die Interoperabilität lediglich als einfachen Export behandelt.

In diesem Sinne können Lösungen wie usBIM.platform als Umgebungen präsentiert werden, die darauf ausgelegt sind, IFC-Modelle, BCF-Issues, bSDD-Wörterbücher, IDS-Anforderungen, informationsgestützte Arbeitsabläufe und ISO 19650-Logiken zu verbinden.

Der Wert der Plattform liegt nicht im einfachen Hochladen von Dokumenten. Er liegt in der Fähigkeit, Informationen, Versionen, Verantwortlichkeiten, Anforderungen, Koordinationsmodell, lokale Varianten und Kontinuität in den Betrieb zu steuern.

Für ein einzelnes Projekt kann eine CDE auf Projektebene ausreichend sein. Für ein reproduzierbares Programm hingegen ist eine Logik auf Programmebene erforderlich.

Der Unterschied ist folgender:

• Eine Projekt-CDE organisiert die informationsgestützte Lieferung eines Auftrags;
• Eine Programm-CDE steuert die kontrollierte Replikation eines Prototyps über mehrere Instanzen;
• Eine CDE auf Programmebene muss Standardisierung, Lokalisierung, openBIM und Daten-Governance verbinden.

Checkliste zur Bewertung der BIM-Standardisierung in Multi-Standort-Programmen

Für einen BIM-Direktor oder einen Digital Construction Lead, der ein CDE für die Bereitstellung eines reproduzierbaren BIM-Programms bewertet, tendieren die folgenden Fragen dazu, Plattformen, die auf Programmebene arbeiten, von Plattformen, die auf Projektebene arbeiten, zu trennen:

• Modelliert das CDE nativ die Beziehung zwischen einem Masterprototyp und seinen Instanzen auf Programmebene, oder lebt jede Instanz als unabhängige Projektumgebung?
• Ist die Versionierung des Master-Prototyps strukturell von der Versionierung der länderspezifisch angepassten Varianten getrennt, mit klar definierten Regeln für die Weitergabe von Änderungen zwischen den beiden Ebenen?
• Unterstützt die Plattform nativ die Zusammenführung mehrerer koordinierter IFC4-Fachmodelle oder erfolgt dies ausschließlich durch Konvertierung?
• Wird BCF als erstklassiges Workflow-Objekt verwaltet, mit abteilungsübergreifender Abfragbarkeit, oder als Dateianhang?
• Werden OIR, AIR, PIR und EIR auf Programmebene als maschinenlesbare (IDS) Spezifikationen ausgedrückt, die automatisch an den Modellen validierbar sind, oder als PDF-Dokumente gespeichert?
• Unterstützt das CDE die kontinuierliche Validierung des Asset Information Models gegen IDS über den gesamten Lebenszyklus des Assets, oder nur den Export des As-Built Modells zum Zeitpunkt der Übergabe?
• Erfüllt die Audit-Trail den sicherheitsorientierten Ansatz, der in ISO 19650-5 definiert ist, einschließlich der Rückverfolgbarkeit des Zugriffs basierend auf Rollen und der Klassifizierung der Informationen?
• Ist der Datenstandort konfigurierbar für Programme oder Standorte, mit transparenter Offenlegung der rechtlichen Governance?
• Ist die openBIM-Konformität der Plattform durch eine Zertifizierung von buildingSMART nachweisbar oder nur im Marketing deklariert?
• Stimmt die rechtliche und proprietäre Struktur des Anbieters der Plattform mit den Anforderungen an die Datensouveränität der Zielmärkte des Programms überein?

Diese Fragen haben keine universell richtigen Antworten. Sie haben richtige Antworten für das einzelne Programm, und die Aufgabe der Programm Governance besteht darin, diese Antworten explizit vor der Auswahl des CDE zu definieren, nicht sie während des Rollouts zu entdecken. Ein CDE, das diese Arbeit transparent unterstützt — indem es seine Fähigkeiten auf Programmebene zur Bewertung offenlegt, anstatt sie zu verbergen — ist das, was sich seinen Platz in der Programmabwicklung verdient.

Der standardisierte Prototyp ist die wirtschaftliche Architektur reproduzierbarer BIM-Programme — von Hyperscalern, die dies in extremer Form anwenden, bis hin zu Hotelketten, öffentlichen Gesundheitssystemen, Verkehrsnetzen, Schulbauprogrammen, von jedem Betreiber, der Skaleneffekte und lokale Anpassung ausbalancieren möchte.

Das CDE auf Programmebene, das auf ISO 19650 und dem openBIM Stack (IFC4, BCF, bSDD, IDS) basiert, ist die Architektur, wie dieses Modell physisch über Länder, Vorschriften und Jahrzehnte hinweg übergeben werden kann. Die beiden sind nicht trennbar.

Das eigentliche Ziel ist nicht, ein Standardmodell zu haben. Es besteht darin, die Beziehung zwischen Standard und Lokalisierung beherrschbar zu halten.

Wenn diese Beziehung klar ist, ermöglicht die BIM-Standardisierung, einmal zu entwerfen, kontrolliert zu validieren, konsistent zu reproduzieren und die Assets über die Zeit zu verwalten. Wenn diese Beziehung jedoch nicht geregelt ist, fragmentiert sich das Programm: Jeder Standort wird zu einer autonomen Kopie, die Varianten verlieren die Rückverfolgbarkeit und der Wert der Replikation verringert sich schrittweise.

Deshalb ist die Standardisierung in reproduzierbaren BIM-Programmen nicht nur eine technische Wahl. Sie ist eine Strategie für die Bereitstellung, Governance und das Management des Wertes über den gesamten Lebenszyklus des Assets.

FAQ zur “BIM-Standardisierung in reproduzierbaren Programmen”

Was versteht man unter BIM-Standardisierung?

Die BIM-Standardisierung ist der Prozess, durch den eine Organisation Regeln, Informationsmodelle, Anforderungen, Verfahren und gemeinsame Kriterien definiert, um Projekte und Vermögenswerte konsistent zu verwalten. In reproduzierbaren Programmen bedeutet dies nicht, immer dasselbe Modell zu verwenden, sondern festzulegen, welche Elemente unverändert bleiben müssen, welche angepasst werden können und wie die lokalen Varianten kontrolliert werden.

Warum ist die BIM-Standardisierung in reproduzierbaren Programmen wichtig?

In reproduzierbaren Programmen entsteht der Wert aus der Möglichkeit, ein gemeinsames Informationsprototyp auf mehreren Standorten zu entwerfen, zu validieren und wiederzuverwenden. Ohne eine Strategie zur BIM-Standardisierung besteht das Risiko, dass jede neue Wiederholung zu einem eigenständigen Projekt wird, was zu einem Verlust der Kohärenz, einer Zunahme unkontrollierter Varianten und einer Verringerung der wirtschaftlichen Vorteile der Wiederholbarkeit führt.

Bedeutet die Standardisierung eines BIM-Modells, es auf mehrere Projekte zu kopieren?

Nein. Ein BIM-Modell auf mehrere Projekte zu kopieren, entspricht nicht der Standardisierung. Ein reproduzierbares Programm erfordert normative, technische, klimatische und operative Anpassungen. Die BIM-Standardisierung dient dazu, diese Anpassungen zu steuern und die Beziehung zwischen dem Masterprototyp und seinen lokalen Varianten nachvollziehbar zu halten.

Welche Rolle spielt der Masterprototyp BIM?

Der Masterprototyp BIM ist das Informationsreferenzmodell des Programms. Er umfasst nicht nur Geometrien, sondern auch Anforderungen, Eigenschaften, Klassifikationen, Validierungskriterien und Koordinierungslogiken. Sein Wert liegt in der Fähigkeit, bereits genehmigte Entscheidungen zu konzentrieren und wiederverwendbar zu machen, ohne die Kontrolle über die Änderungen zu verlieren, die an den verschiedenen Standorten vorgenommen werden.

Wie werden lokale Varianten in einem BIM-Programm verwaltet?

Lokale Varianten sollten als versionierte und begründete Änderungen verwaltet werden, nicht als unabhängige Kopien des Masters. Jede Abweichung muss mit dem Requirement, das sie erzeugt hat, der beteiligten Disziplin, der genehmigenden Entscheidung und den Auswirkungen auf Genehmigungen, Kosten, Zeit und Vermögensverwaltung verknüpft sein.

Wie steht die BIM-Standardisierung im Verhältnis zu ISO 19650?

ISO 19650 liefert die Prozesslogik zur Anforderung, Produktion, Überprüfung, Weitergabe und Archivierung von Informationen über den Lebenszyklus des Vermögenswerts. In reproduzierbaren Programmen hilft sie, organisatorische Anforderungen, Anforderungen des Vermögenswerts, Projektanforderungen und Austauschanforderungen zu verknüpfen, wodurch die Informationsgovernance strukturierter wird.

Warum ist das CDE zentral für die BIM-Standardisierung?

Das CDE ist die Umgebung, in der Informationen, Modelle, Revisionen, Genehmigungen und Varianten kontrolliert verwaltet werden. In einem reproduzierbaren Programm sollte das CDE nicht nur Dateien hosten: Es sollte helfen, die Beziehung zwischen dem Masterprototyp, lokalen Instanzen, Issues, Informationsanforderungen und Daten für die operative Verwaltung aufrechtzuerhalten.

Wie unterstützt openBIM die BIM-Standardisierung?

openBIM ermöglicht es, den Prototyp zwischen Software, Teams, Disziplinen und Lebenszyklusphasen portabler zu machen. IFC unterstützt den Austausch von Geometrien und Daten, BCF das Management von Issues, bSDD die Konsistenz von Klassifikationen und Eigenschaften, während IDS es ermöglicht, überprüfbare Informationsanforderungen an die Modelle zu formulieren.

Wozu dient IDS in reproduzierbaren BIM-Programmen?

IDS ermöglicht es, Informationsanforderungen in einer von der Software überprüfbaren Form zu beschreiben. In einem reproduzierbaren Programm kann es helfen, sicherzustellen, dass jede lokale Instanz weiterhin die Anforderungen des Masters erfüllt und dass der Informationsaustausch mit den in den verschiedenen Phasen geforderten Anforderungen übereinstimmt, von der Planung bis zur Verwaltung des Vermögenswerts.

Warum ist Datensouveränität bei der Auswahl eines CDE wichtig?

Bei länderübergreifenden Programmen werden der physische Speicherort der Daten, die geltenden rechtlichen Rahmenbedingungen, Zugriffsrichtlinien und der Audit-Trail zu strategischen Faktoren. Die Wahl eines CDE betrifft nicht nur die BIM-Funktionalitäten, sondern auch Aspekte wie Sicherheit, Compliance, Datenmanagement und die Fähigkeit, sensible technische Daten zu schützen.