Digitales Engineering: Was vor der Systemwahl zu prüfen ist

Der Softwarekauf ist kein Erstschritt

Die Lizenz wird erworben, Schulungen werden gebucht — und erst danach stellt sich heraus, dass das gewählte System die im Projekt geforderten Fachmodelle nur unvollständig abbilden kann oder dass der IFC-Export Attribute verliert, die für die Mengenermittlung oder die Tragwerksbemessung notwendig wären. Was als Digitalisierungsoffensive begann, endet in einer aufwendigen Migrationsdiskussion, während der Projekttermin unverändert näher rückt und die Modellkoordination mit den Fachplanern ins Stocken gerät.

Diese Erfahrung ist kein Einzelfall, sondern ein strukturelles Muster. Die Systemwahl wird häufig als technische Beschaffungsfrage behandelt, vergleichbar mit der Auswahl eines CAD-Arbeitsplatzes vor zwanzig Jahren. Doch digitales Engineering im Sinne von Building Information Modeling ist kein CAD-Ersatz, sondern ein Informationsmanagement, dessen Anforderungen sich aus dem konkreten Projekt ergeben. Wer die Reihenfolge umkehrt und zuerst die Software festlegt, läuft Gefahr, im laufenen Projekt nachverhandeln zu müssen — über IFC-Schemata, über Attributlisten, über Zuständigkeiten in der gemeinsamen Datenumgebung. Wir haben in den letzten Jahren mehrere solcher Fälle begleitet, sowohl bei Neubauprojekten als auch bei anspruchsvollen Bestandssanierungen, und die Erkenntnis ist immer dieselbe: Die Systemwahl ist eine Folge der Anforderungen, nicht umgekehrt.

AIA und BAP als Fundament: Warum die Systemwahl am Projektbedarf ansetzt

Bevor eine Softwareliste überhaupt aufgestellt wird, müssen zwei Dokumente vorliegen, die in der Praxis oft erst nach der Systembewertung entstehen — was die gesamte Argumentation auf den Kopf stellt. Die Auftraggeber-Informationsanforderungen, kurz AIA, definieren, welche Informationen der Auftraggeber zu welchen Zeitpunkten und in welcher Qualität vom Auftragnehmer benötigt. Der BIM-Abwicklungsplan, kurz BAP, beschreibt darauf aufbauend, wie diese Anforderungen umgesetzt werden, und regelt dabei BIM-Prozesse, Datenstrukturen und Verantwortlichkeiten über alle Beteiligten hinweg.

Wer AIA und BAP vor der Systemwahl finalisiert, kann Anbieter gezielt nach ihren Fähigkeiten befragen — und erkennt schnell, wer vom Informationsmanagement spricht und wer nur vom 3D-Modell.

In unserer Arbeit mit Tragwerksplanern zeigt sich, dass die AIA-Qualität über Erfolg und Misserfolg einer BIM-Einführung entscheidet. Vage Formulierungen wie "BIM ab Leistungsphase 3" oder "3D-Modell mit Mengenermittlung" lassen jeden Anbieter scheinbar geeignet erscheinen. Erst wenn festgelegt ist, welche Fachmodelle geliefert werden, welche Attributmengen erforderlich sind, welche Austauschzeitpunkte gelten und welche Prüfmechanismen greifen, wird die Auswahl tatsächlich entscheidbar. Wir empfehlen daher, die AIA-Vorlage nicht als formales Anhängsel zu behandeln, sondern als Pflichtenheft für die Softwareprüfung. Ein Anbieter, der in der Angebotsphase die im AIA geforderten IFC-Versionen, Austauschansichten und Prüfregeln nicht konkret benennen kann, wird diese Anforderungen im Projektbetrieb kaum zuverlässig erfüllen. Wer hingegen schon im BAP darlegt, wie das eigene Team die definierten Anwendungsfälle umsetzen will, verschiebt die Systembewertung von einer Marketingfrage zu einer ingenieurtechnischen Prüfung.

Informationsbedarf definieren: LOIN und die Rolle der Attributverwaltung

Ein IFC-Export allein garantiert noch keine Interoperabilität — diese Aussage gehört in jede Systempräsentation, die wir uns anhören. Die Schnittstelle trägt zwar die Geometrie, aber ob die im Projekt geforderten Eigenschaften, Klassifikationen und Werte vollständig und in der richtigen Einheit ankommen, hängt davon ab, ob das System den im AIA beschriebenen Informationsbedarf überhaupt verwalten kann. Genau an dieser Stelle kommt der Level of Information Need, kurz LOIN, ins Spiel, der für die Muster-AIA in Deutschland über die Norm DIN EN 17412-1 aufgegriffen wird.

LOIN definiert, welche Informationen in welcher Qualität, zu welchem Zeitpunkt und für welchen Zweck bereitgestellt werden müssen. Für die Tragwerksplanung bedeutet das konkret: Eine Stahlbetonstütze wird nicht nur als Volumenkörper modelliert, sondern trägt Merkmale wie Materialgüte, Querschnittsbezeichnung, Bemessungslast, Verformungsgrenzwert und brandschutztechnische Klassifikation. Hinzu kommen im Sanierungsfall Attribute aus der Bestandsaufnahme — etwa die ermittelte Betondruckfestigkeit, das Ergebnis der Karbonatisierungsmessung oder die Restnutzungsdauer nach einer Instandsetzungsplanung. Ob ein Softwaresystem diese Attribute strukturiert verwalten, versionieren und in IFC-Sichten ausgeben kann, lässt sich nicht am Demo-Modell beurteilen, sondern nur anhand eines realen Fachmodells mit projektbezogener Attributliste.

In der Praxis testen wir die Kandidaten mit einem kleinen, aber anspruchsvollen Ausschnitt — typischerweise ein Knoten aus dem Bereich Bestandssanierung, wo die Schnittstelle zwischen Bestandsbauteil und neuer Konstruktion hohe Anforderungen an die Attributverwaltung stellt. Dabei achten wir auf drei Aspekte:

• Können Attribute projektweit einheitlich definiert und über Modellansichten hinweg konsistent exportiert werden, ohne dass nationale Erweiterungen und benutzerdefinierte Eigenschaften miteinander kollidieren?
• Wie verhält sich das System bei Attributänderungen im Projektverlauf — bleiben Verknüpfungen zu Bauteilen und Bemessungsergebnissen erhalten oder brechen sie bei jeder Modellrevision?
• Werden nicht-IFC-Eigenschaften so mitgeführt, dass sie in der CDE sichtbar bleiben, ohne den IFC-Standard durch proprietäre Erweiterungen zu verletzen?

Diese Prüfungen fallen je nach System sehr unterschiedlich aus, und genau darin liegt der Wert der LOIN-Betrachtung. Wer nur auf die sichtbare Geometrie schaut, übersieht den eigentlichen Engineering-Anspruch, der in den Daten steckt.

Interoperabilität sichern: IFC-Standards und IDS für den modellbasierten Austausch

IFC ist seit Langem als ISO-Standard ISO 16739-1 verankert, und die buildingSMART Standards Library führt diesen Status auch heute noch. Doch ein standardkonformer Export ist nicht dasselbe wie ein prüfbarer Austausch. Wir erleben regelmäßig, dass zwei Fachmodelle technisch IFC 4.3 sprechen, aber die für das jeweilige Projekt relevanten Eigenschaften unterschiedlich interpretieren — einmal als Property Set in einer nationalen Erweiterung wie IFC4ADD2, einmal als benutzerdefinierte Eigenschaft mit anderer Einheit, einmal schlicht als fehlender Eintrag.

Die Information Delivery Specification, kurz IDS, setzt genau an dieser Stelle an: Sie beschreibt maschinenlesbar, welche Anforderungen der Austausch erfüllen muss — von der Objektklasse über Klassifikationen bis hin zu Eigenschaften, Werten und Einheiten. IDS-Dateien können zur automatisierten Prüfung eingehender IFC-Lieferungen eingesetzt werden, was die Qualitätssicherung im Projekt erheblich verändert. Statt manuell durch ein Modell zu klicken, lässt sich über eine IDS-Validierung in Minuten prüfen, ob die gelieferten Modelle den projektspezifischen Regeln entsprechen, und zwar bevor die Tragwerksplanung ihre Bemessung auf diesen Daten aufbaut.

Ein IFC-Export ist eine notwendige, aber keine hinreichende Bedingung. Erst die IDS-Validierung macht den Austausch überprüfbar.

In der Systemwahl bedeutet das: Wir befragen die Anbieter nicht nur nach IFC-Import und -Export, sondern konkret nach IDS-Fähigkeiten — sowohl beim Erstellen als auch beim Prüfen von Lieferobjekten. Ein System, das IDS-Validierungen lediglich als externe Skript-Aufgabe am Rand unterstützt, ist gegenüber einer Lösung im Nachteil, die die Validierung als integralen Workflow-Schritt mit eigenen Dialogoberflächen und Berichten behandelt. Für die Tragwerksplanung, die oft mit mehreren Fachmodellen aus Architektur, TGA, Vermessung und Geotechnik koordiniert, ist diese Fähigkeit kein Bonus, sondern Voraussetzung, weil sich andernfalls die Prüfung der Eingangsdaten nicht reproduzierbar dokumentieren lässt.

Wir kombinieren die IDS-Prüfung mit einem klassischen Koordinationstest: Zwei bis drei Fachmodelle aus unterschiedlichen Quellen werden über die IFC-Schnittstelle zusammengeführt und auf Kollisionen, Attributverluste und Einheitentreue untersucht. Erst danach fällen wir eine vorläufige Eignungsentscheidung. Die Erfahrung zeigt, dass sich viele Schwächen erst in dieser Kombination zeigen, nicht im Einzelmodell.

Kollaborations-Workflows: BCF und CDE-Statuscodes in der Praxis

Ein Koordinationsmodell nützt wenig, wenn die daraus resultierenden Hinweise als E-Mails mit Screenshots in Postfächern verloren gehen. Das BIM Collaboration Format, kurz BCF, setzt hier den offenen Standard: BCF dient dem softwareübergreifenden Austausch modellbezogener Vorgänge und kann sowohl dateibasiert als auch über einen Webdienst beziehungsweise eine REST-Schnittstelle genutzt werden. Ein BCF-Markup verweist auf Ansichten, IFC-Koordinaten und konkrete Elemente über IFC-GUIDs, sodass ein Hinweis im Architekturmodell exakt dasselbe Bauteil adressiert wie in der Tragwerksplanung oder in der TGA-Koordination. Laut buildingSMART kann ein solches Markup bis zu 1.000 Komponenten referenzieren, was die Arbeit in komplexen Modellen mit vielen Schnittstellen deutlich erleichtert.

Für die Systemwahl bedeutet das: Wir prüfen, ob die Anbieter BCF sowohl beim Erstellen als auch beim Empfang stabil unterstützen, wie die Verknüpfung mit dem zugrunde liegenden Modell über Versionsstände hinweg erhalten bleibt und wie sich BCF-Einträge in das Projekt-Reporting integrieren lassen. In der Bestandssanierung, wo Bestandsmodelle häufig aus Punktwolken abgeleitet werden, ist die korrekte GUID-Verknüpfung zwischen BCF und Modellelement besonders kritisch, weil die geometrische Referenz sonst bei jeder Punktwolken-Aktualisierung verloren geht und die Hinweise ins Leere laufen.

Parallel zum BCF-Workflow steht das Common Data Environment, kurz CDE. Die ISO-19650-orientierte Anleitung sieht Statuscodes als Metadaten für Informationscontainer vor, also für den zulässigen Verwendungszweck eines Modells oder Dokuments in einer bestimmten Projektphase. Ein Container im Status "In Arbeit" darf nicht für Bemessungsentscheidungen herangezogen werden, ein Container im Status "Geteilt" oder "Veröffentlicht" schon. Die CDE muss diese Statusinformation technisch durchsetzen und sichtbar machen, andernfalls bleibt die Workflow-Logik ein Papiertiger, der nur in der Projektmappe existiert.

Wir achten bei der Auswahl darauf, dass die CDE Zugriffe auf unreife oder sensible Informationen beschränken kann, dass Statuswechsel dokumentiert und nachvollziehbar bleiben und dass eine Anbindung an die gewählten Autorensysteme reibungslos funktioniert. Gerade bei Sanierungsprojekten, in denen alte Pläne, neue Modelle und Bemessungsergebnisse parallel laufen, ist die klare Trennung zwischen Bestands-, Bearbeitungs- und freigegebenen Daten ein praktischer Sicherheitsgewinn, der den Projektalltag spürbar entlastet.

Rechtliche Rahmenbedingungen: DSGVO-Konformität bei Cloud-basierten Engineering-Systemen

Sobald eine CDE als Cloud-Lösung betrieben wird, berührt die Systemwahl unmittelbar Fragen des Datenschutzrechts. Personenbezogene Daten — etwa Namen von Planern und Beteiligtenlisten, E-Mail-Verkehr im BCF-Workflow, Login-Protokolle oder auch Fotografien der Baustelle — werden regelmäßig verarbeitet, oft ohne dass die Beteiligten diese Daten als personenbezogen wahrnehmen, weil sie im Modellkontext als Metadaten auftauchen.

Artikel 28 DSGVO setzt hier einen klaren Maßstab: Wenn ein Cloud-System personenbezogene Daten im Auftrag verarbeitet, darf der Verantwortliche nur Auftragsverarbeiter einsetzen, die hinreichende Garantien für geeignete technische und organisatorische Maßnahmen bieten. Der Vertrag muss unter anderem Gegenstand und Dauer der Verarbeitung, Art und Zweck, Datenarten sowie Rechte und Pflichten festlegen. Hinzu kommen Anforderungen an die Nachvollziehbarkeit etwaiger Unterauftragsverarbeiter, die der CDE-Anbieter einsetzt — sei es für Hosting, Backup oder Support. Wer Cloud-CDEs allein nach Funktionsumfang auswählt, übersieht diese Ebene und muss sie im laufenden Projekt nachverhandeln, was erfahrungsgemäß teurer wird als eine vorgeschaltete Prüfung.

In unserer Praxis bedeutet das konkret drei Anforderungen an die Anbieterprüfung:

1. Vorlage eines Auftragsverarbeitungsvertrags, der die Anforderungen des Artikels 28 vollständig abbildet und die konkrete Verarbeitung im Projekt beschreibt.

2. Nachvollziehbarkeit der Unterauftragsverarbeiter — also der Subunternehmer, die der CDE-Anbieter einsetzt, einschließlich ihrer Standorte und ihrer eigenen Garantien.

3. Dokumentation der technischen und organisatorischen Maßnahmen, insbesondere Verschlüsselung, Zugriffsprotokollierung, Auftragskontrolle und Standort der Datenverarbeitung.

Pauschalaussagen wie "unsere Cloud ist DSGVO-konform" reichen für eine verantwortliche Auswahl nicht aus. Die Konformität entsteht nicht durch den Anbieter allein, sondern durch das Zusammenspiel von Vertrag, Konfiguration und Projektkontext. Wer das in der Systemwahl berücksichtigt, schützt nicht nur personenbezogene Daten, sondern auch das eigene Büro vor aufwendigen Korrekturen im Projektablauf und vor Unsicherheiten gegenüber dem Auftraggeber.

Abschließend: Die Reihenfolge entscheidet

Die Systemwahl im digitalen Engineering lässt sich nicht von den Anforderungen des Projekts trennen. AIA, BAP, LOIN, IFC, IDS, BCF, CDE und DSGVO bilden zusammen ein Prüfgerüst, das die Marketingversprechen der Anbieter in konkrete, nachvollziehbare Kriterien übersetzt. Wir haben die Erfahrung gemacht, dass Büros, die diese Reihenfolge einhalten, ihre Einführungsphase deutlich verkürzen — nicht, weil die ausgewählte Software grundsätzlich besser wäre, sondern weil die Erwartungen vorher geklärt sind und die Nachverhandlung im Projekt entfällt.

Gleichzeitig bleibt festzuhalten, dass es nicht die eine richtige Systemkombination gibt. Die Eignung hängt von den Fachdisziplinen, den Austauschpartnern, den projektspezifischen Anwendungsfällen und der eigenen Teamstruktur ab. Auch Lizenzmodelle, Schulungsaufwand und Supportqualität spielen in der Praxis eine Rolle, lassen sich aber nicht als universelle Empfehlung formulieren, sondern nur im jeweiligen Projektkontext bewerten. Was sich als belastbar erweist, ist ein methodisches Vorgehen: zuerst die Anforderungen, dann die Prüfung, dann die Entscheidung — und nicht umgekehrt.

Für unser Ingenieurbüro in Fulda hat sich dieser Pfad bewährt, gerade weil wir sowohl im Neubau als auch in der Bestandssanierung arbeiten und die Schnittstellen zwischen Bestand und neuer Konstruktion täglich prüfen müssen. Wer hier mit klaren Anforderungen in die Systemwahl geht, gewinnt keine theoretische Souveränität, sondern ganz praktisch Zeit im Projekt — und damit die Möglichkeit, sich auf das zu konzentrieren, was am Ende zählt: eine Tragwerksplanung, die sowohl ingenieurtechnisch als auch informationstechnisch belastbar ist.