Vom BIM-Erklärungsplan zu Anforderungen, die man prüfen kann

Ich habe angefangen wie alle anderen. Excel-Tabellen mit geforderten Eigenschaften. Word-Dokumente, die Planern sagen sollten, wie sie zu arbeiten haben. Wir nannten das BEP. In meiner Hand war es ein BIM-Erklärungsplan: ein langer Text, der BIM erklärte, in der Hoffnung, dass ihn jemand liest und dann entsprechend modelliert.

Das war 2015. Planern zu sagen, wie sie zu arbeiten haben, funktioniert nicht. Das musste ich selbst lernen.

Zwei Dinge sind hängen geblieben, und sie steuern die Arbeit bis heute.

1. Eine Anforderung taugt nur, wenn ein Nutzen dahintersteckt. Wenn die Daten niemand verwendet, ist die Eigenschaft Theater. Davon habe ich viele geschrieben.
2. Eine Anforderung taugt nur, wenn sie so formuliert ist, dass man sie prüfen kann. Testgetrieben. Wenn Sie ein IFC nicht dagegen durchfallen lassen können, ist es keine Anforderung. Es ist eine Wunschliste mit schönerer Formatierung.

Dieses Problem beschäftigt mich seither. Von Excel-Listen zu offenen Datenverträgen. Von PDFs zu IDS. Von «bitte so modellieren» zu «hier ist die Prüfung». Das neueste pragmaticBIM-Release ist der jüngste Versuch: ein offener Standard, konfiguriert aus Geschäfts- und Projektzielen, nicht aus einer Use-Case-Checkliste.

Zuerst der Nutzen, dann die Anforderung

Die meisten BIM-Anforderungslisten beginnen beim Element. Wände brauchen dieses Property Set. Räume brauchen jenen LongName. Türen eine extra Klassifikation. Die Liste wächst, weil irgendwann irgendwer das Feld gebraucht hat, und niemand derjenige sein will, der es gelöscht hat.

Die Frage, die ich zuerst stellen gelernt habe, ist einfacher: was macht jemand mit diesen Daten? Mengen, Kosten, Übergabe, Betrieb, eine Qualitätsprüfung. Wenn ich den Nutzen nicht benennen kann, sollte ich das Attribut nicht bestellen. Eine Anforderung ohne Nutzen ist ein Aufwand, den Sie jeder modellierenden Person, jeder Phase, jedem Modell auferlegen, für nichts.

Das klingt offensichtlich. So werden BEPs nicht geschrieben. Ein BEP erklärt einen Prozess. Es sagt selten, welcher Workflow welches Feld tatsächlich verbraucht, oder was passiert, wenn das Feld fehlt. Also wird das Dokument unterschrieben, das Modell geliefert, und die Excel-Liste liegt ungenutzt daneben.

So formulieren, dass man prüfen kann

Die zweite Lektion ist die ingenieurmässige. Softwareleute kennen sie: wenn Sie es nicht testen können, haben Sie keine Spezifikation. Sie haben eine Absicht.

BIM-Anforderungen müssen denselben Test überstehen. Erlaubte Werte, Einheiten, IFC-Entity, Property Set, Phase. So geschrieben, dass ein Checker Pass oder Fail sagen kann. So geschrieben, dass ein Planer den Fehler an einem konkreten Element sieht, nicht in einem Absatz über «Informationsmanagement». Dafür ist buildingSMART IDS da, und deshalb ist ein Vertrags-Excel, das man nicht prüfen kann, immer noch ein BIM-Erklärungsplan, nur in einem anderen Dateiformat.

Darum kreise ich seit Jahren: den Nutzen explizit machen, die Anforderung maschinenlesbar machen, dann das Projektteam das Modell gegen dieselbe Quelle prüfen lassen, die es bekommen hat. Kein zweites Werkzeug, keine Rückübersetzung in einen Word-Anhang.

Offener Standard, zielgetriebene Konfiguration

Der neueste Ansatz ist einfach zu sagen und schwer zu bauen.

Der Datenvertrag ist offen. Der Swiss Starter Elementplan liegt auf GitHub: mehr als 40 Workflows, rund 80 Elemente, gemappt auf sieben Projektziele. Lesen, forken oder in ein Projekt kopieren. buildingSMART IDS ist das Austauschformat. Der publizierte Plan ist dasselbe Artefakt für Bauherrschaft, BIM-Manager und Prüfung.

Die Konfiguration beginnt in der Sprache des Geschäfts. Wie kostensensitiv ist das Projekt? Wie hoch der Ausbaustandard? Wie wichtig sind Betrieb und Übergabe? Jedes Ziel hat Ausprägungen. Jede Ausprägung aktiviert die Workflows dahinter. Sie bestellen Daten, weil ein Projektziel sie braucht, nicht weil auf einer Checkliste ein Kästchen leer war.

Danach beantwortet der Information Delivery Plan die Frage, die jede modellierende Person tatsächlich stellt: in welcher Datei, in welcher Phase? Diese Teilung macht modellspezifische IDS-Dateien möglich. Ohne sie publizieren Sie eine riesige Anforderungsliste und hoffen, dass die richtigen Leute die richtigen Zeilen lesen.

Was ausgeliefert wurde

Der aktualisierte Elementplan ist das Produkt dieser Arbeit, keine neue Philosophie. In diesem Release:

• Zielgetriebene Konfiguration - pro Projektziel eine Ausprägung setzen und die Workflows aktivieren lassen.
• IDS-Import und Merge - die Anforderungen anderer Planer in einen Entwurf holen und pro Element und Attribut entscheiden, was bleibt.
• Actions im Viewer - ein IFC hochladen, gegen die publizierte IDS prüfen, einen Report erhalten. Die Prüfung bleibt im Browser.
• Modellspezifische IDS - der Information Delivery Plan legt fest, welches Element in welches Modell und welche Phase gehört.
• Swiss Starter Elementplan - ein öffentlicher Master auf GitHub. Kein Schweizer Standard, und nicht perfekt. Besser als die übliche Excel-Liste, und Sie können einen Fehler flaggen.

Entwurf und Konfiguration auf der Community-Vorlage sind kostenlos. Sie zahlen, wenn Sie publizieren, also in dem Moment, in dem der Plan vertragsrelevant wird und das Projektteam erreicht.

Der Reihe nach ansehen

Die meisten Diskussionen über BIM-Anforderungen bleiben abstrakt, und genau deshalb laufen sie schlecht. Die konkrete Variante ist eine Screenshot-Tour durch den Elementplan, in der Reihenfolge, in der das Werkzeug tatsächlich benutzt wird: was das Projektteam erhält, wie der Plan entsteht, wie Ziele den Katalog schlank machen, und wie Review und Publizieren aus einem Entwurf ein geprüftes Modell machen.

Elementplan im Überblick: vom Datenvertrag zum geprüften Modell

Wenn Sie mit der öffentlichen Vorlage starten wollen, liegt sie auf GitHub. Wenn Sie es an einem Projekt versuchen wollen, melden Sie sich im Elementplan-Editor an mit einem GitHub-Konto, oder fragen Sie uns nach einem Walkthrough.