BIM-Abnahme ohne Suchrunde: Prüfen Sie, was im Modell wirklich geliefert wurde

Die Datei ist hochgeladen, das Gebäude dreht sich im Viewer, die Übergabe scheint erledigt. Erst bei der Vorbereitung des Betriebs fällt auf: Anlagenkennzeichen fehlen, Wartungsintervalle stehen in verschiedenen Feldern und mehrere Bauteile tragen denselben frei eingegebenen Namen. Das Modell ist sichtbar. Für den nächsten Arbeitsschritt ist es noch nicht zuverlässig nutzbar.

Für deutsche Projektentwickler, Planungsbüros und Betreiber entsteht hier ein sinnvoller Auftrag für Individualsoftware: ein BIM-Prüfportal, das vereinbarte Informationslieferungen nachvollziehbar bewertet und Korrekturen bis zum Abschluss begleitet. Der Nutzen liegt in weniger Sucharbeit bei der Übergabe. Ein weiterer Viewer allein löst dieses Problem nicht.

Machen Sie Informationsanforderungen ausführbar

buildingSMART beschreibt Information Delivery Specification, kurz IDS, als Standard zum Festlegen und Prüfen einfacher Informationsanforderungen an IFC-Modelle. Eine Spezifikation kann etwa verlangen, dass bestimmte Objekte eine definierte Eigenschaft besitzen. Damit werden Teile einer bisher textlichen Lieferbeschreibung maschinenlesbar.

Der entscheidende Schritt findet vor dem Programmieren statt. Nehmen Sie eine konkrete Übergabe auseinander: Welche Person benötigt welche Information für welche Entscheidung? Ein Betreiber braucht möglicherweise eine eindeutige Anlagenzuordnung und einen Herstellerbezug. Die Kostenplanung benötigt andere Angaben. Ein pauschales „alle Eigenschaften müssen gefüllt sein“ schafft viele Meldungen, aber wenig Klarheit.

Ordnen Sie jede Anforderung einem Lieferzeitpunkt und einem Verantwortlichen zu. Ein Wert, der erst nach der Produktauswahl feststeht, darf in einer frühen Planung anders behandelt werden als bei der tatsächlichen Übergabe. Das Portal sollte diese Projektlogik sichtbar machen, statt jeden Zwischenstand wie eine fertige Lieferung zu bewerten.

Binden Sie das Ergebnis an zwei Versionen

Eine grüne Prüfung ohne Versionsbezug ist schwer belastbar. Speichern Sie, welches IFC-Modell gegen welchen IDS-Regelsatz geprüft wurde. Ergänzen Sie einen nachvollziehbaren Zeitpunkt, die eingesetzte Prüferkonfiguration und den ausführenden Prozess. Eine später geänderte Anforderung darf das frühere Ergebnis nicht stillschweigend umdeuten.

Unterscheiden Sie auch eine fehlerhafte Prüfdatei von einem fachlichen Fehler im Modell. Der buildingSMART-Leitfaden für Implementierer trennt die Prüfung der IDS-Struktur von weitergehenden Anforderungen an eine gültige Spezifikation. Eine syntaktisch lesbare XML-Datei allein beweist deshalb noch keinen brauchbaren Prüfumfang.

Im Portal benötigen diese Situationen verschiedene Zustände: Prüfung konnte nicht starten, Modell konnte nicht verarbeitet werden, Anforderungen sind verletzt oder Prüfung ist abgeschlossen. Diese Unterscheidung verhindert, dass ein technischer Abbruch als mangelhafte Planungsleistung in der Aufgabenliste landet.

Übersetzen Sie Meldungen in bearbeitbare Aufgaben

Ein Bericht mit tausend Zeilen hilft einem Fachplaner wenig, wenn er jedes Objekt selbst suchen muss. Eine Meldung sollte die betroffene Modellversion, das Objekt, die erwartete Information und den gefundenen Zustand zeigen. Gruppieren Sie gleichartige Ursachen, damit eine falsche Exportzuordnung nicht als hunderte voneinander unabhängige Probleme erscheint.

Für den Austausch von Problemen zwischen Projektanwendungen bietet die BCF-API von buildingSMART ein offenes Format mit Themen, Kommentaren und Ansichten. Ob Ihr vorhandenes System die benötigten Funktionen tatsächlich unterstützt, gehört in die Integrationsprüfung. Das bloße Auftauchen von „BCF“ in einer Produktbeschreibung ist noch kein getesteter Ablauf.

Legen Sie fest, wer eine Meldung zuweisen, kommentieren, zurückweisen oder schließen darf. Eine begründete Ausnahme braucht einen eigenen Status und eine zuständige Person. Sie sollte nicht durch Löschen der Meldung aus dem Bericht verschwinden. So bleibt nachvollziehbar, weshalb eine Lieferung trotz eines bekannten offenen Punktes weiterbearbeitet wurde.

Prüfen Sie Korrekturen ohne eine neue Suchrunde

Die zweite Modelllieferung ist der eigentliche Produkttest. Erkennt das Portal den zuvor gemeldeten Sachverhalt wieder? Kann es zeigen, dass ein Wert ergänzt wurde? Und was passiert, wenn ein Objekt im Export eine neue Kennung erhält? Für solche Fälle braucht es definierte Vergleichsregeln und einen sichtbaren Hinweis auf unsichere Zuordnungen.

Vergleichen Sie fachliche Zustände, nicht nur Dateinamen. „Modell_final_neu.ifc“ ist keine zuverlässige Versionsstrategie. Lassen Sie Lieferpakete bewusst abschließen und halten Sie spätere Änderungen als neue Stände fest. Eine wiederholbare Prüfung sollte für dieselben Eingaben dieselbe fachliche Aussage liefern oder eine geänderte Prüferkonfiguration ausdrücklich erklären.

Auch der Empfänger eines Berichts braucht Kontext. Ein exportiertes PDF sollte auf die zugehörigen Modell- und Regelversionen verweisen. Wer Monate später einen Ausdruck liest, darf ihn nicht versehentlich als Aussage über den inzwischen aktuellen Projektstand verstehen.

Kaufen Sie zuerst einen vollständigen Lieferdurchlauf

Ein Pilot kann sich auf eine technische Anlage oder eine klar abgegrenzte Objektgruppe beschränken. Er sollte dafür den ganzen Ablauf enthalten: Anforderungen abstimmen, Lieferung übernehmen, prüfen, Rückmeldungen verteilen, korrigiertes Modell empfangen und den Abschluss dokumentieren. Erst dieser Durchlauf zeigt, wo sich eine Integration wirklich lohnt.

Verlangen Sie bei der Abnahme konkrete Beispiele:

• Eine notwendige Eigenschaft fehlt bei mehreren passenden Objekten.
• Die Eigenschaft ist vorhanden, hat aber einen unzulässigen Wert.
• Ein technischer Verarbeitungsfehler wird getrennt vom Modellbefund angezeigt.
• Eine neue Regelversion verändert das Ergebnis nachvollziehbar.
• Ein korrigierter Export löst die richtigen offenen Punkte.
• Ein externer Projektpartner sieht ausschließlich seine freigegebenen Aufgaben.

Bewerten Sie anschließend, wie lange Projektbeteiligte brauchen, um einen Befund zu verstehen und zu bearbeiten. Das ist für den Betrieb des Portals aussagekräftiger als die Anzahl grüner Häkchen in einer Präsentation. Dokumentieren Sie bewusst, welche Prüfarten außerhalb des vereinbarten Umfangs bleiben.

Unsere Beiträge zu eindeutigen Freigaben im Projektportal und zur praktischen Softwareübergabe helfen bei den angrenzenden Entscheidungen. Innovation T verbindet solche Abläufe mit bestehenden Plattformen über seine Software- und Integrationsleistungen. Besprechen Sie ein konkretes BIM-Lieferpaket mit uns. Ein Beispielmodell, die heutigen Anforderungen und ein typischer Rückmeldungsbericht reichen für einen ersten sachlichen Projektvergleich.

Häufige Fragen

Was kann eine IDS-Prüfung bei einer BIM-Lieferung nachweisen?

Sie kann prüfen, ob die im gewählten IDS-Regelsatz beschriebenen Informationsanforderungen im IFC-Modell erfüllt sind. Das Ergebnis gilt für die geprüfte Modell- und Regelversion; es ersetzt keine vollständige geometrische, fachliche oder rechtliche Abnahme.

Brauchen wir dafür eine neue gemeinsame Datenumgebung?

Nicht zwingend. Ein Prüfportal kann vorhandene Ablagen und Projektplattformen ergänzen. Entscheidend sind nachvollziehbare Versionen, geregelte Zugriffe und eine passende Übergabe der Prüfergebnisse in den bestehenden Arbeitsablauf.

Was sollte ein Pilot für ein BIM-Prüfportal enthalten?

Wählen Sie ein konkretes Lieferpaket mit abgestimmten Anforderungen. Der Pilot sollte ein fehlerhaftes Modell prüfen, verständliche Rückmeldungen erzeugen und nach einer Korrektur zeigen, welche Punkte tatsächlich behoben wurden.