BIM ist beständiges Development

BIM wird häufig als ein sehr starrer Prozess angesehen – eine Ansammlung nicht standardisierter Software und Workflows, die wenig mit dem bisher gewohnten Planungsgeschehen zu tun haben. Damit gehen bei den Betroffenen oftmals Sorgen einher:

• Auf Planerseite die Angst, dieses BIM würde mit Katalogobjekten den Entwurf diktieren und jeder Eingriff in bei Projektstart aufgesetzte Prozesse einer Operation am offenen Herzen gleichkommen.
• Auf Auftraggeberseite häufig Bedenken, dass bisherige Workflows ausgehebelt würden oder nur mit großem Entwicklungsaufwand und den damit verbundenen Kosten mit bestehenden Prozessen verknüpft werden könnten.

Des Weiteren wird oft die Frage laut, was BIM-Development überhaupt im aktiven Projektgeschehen eines Planungsprojekts zu suchen hat. „Die Softwarehersteller versprechen ja den berühmten roten BIM-Knopf, den die Planer lediglich bedienen müssen, damit es ein erfolgreiches Projekt wird!“, ist tatsächlich in leicht abgewandelter Sprache eine weit verbreitete Haltung. Es sei doch bereits alles Notwendige für den Prozess entwickelt.

Warum also BIM-Development, das Entwickeln am offenen Herzen?

Zum einen hat jedes Projekt, unabhängig von BIM, seine Eigenheiten, auf die alle Projektbeteiligten individuell eingehen müssen:

• Der Architekt passt beispielsweise einen Block aus seiner über Jahre gepflegten 2D-Detailbibliothek auf projektspezifische Bedingungen an, um veränderte Materialeigenschaften mit aufzunehmen.
• Der Architekt ändert eventuell die projektübergreifenden BIM-Objekte der Türfamilien, um diese um Gelerntes anzureichern.
• Oder er überarbeitet die bürointerne Projektvorlage anstelle der Vorlage, die im Projekt von einem externen BIM-Berater kommt, um schneller und vertrauter ins Projektgeschehen eintauchen zu können.

All diese Anpassungen lassen sich bereits als Entwicklung identifizieren – aus Erfahrenem lernen, um beim nächsten Mal besser aufgestellt zu sein. BIM-Objekte und Detailzeichnungen sind in diesen Beispielen die Werkzeuge des Architekten, ähnlich wie Prozesse und Kommunikation die Werkzeuge des BIM-Managers und Gesamtkoordinators sind. Auch wir lernen aus dem, was in unserer Arbeit noch Entwicklungsbedarf hat.

Wir, in diesem Falle die Formitas AG, sind ein Team aus 50 BIM- und IT-Experten. Wir erfahren in zahlreichen Projekten, wo der Prozess hakt und sich wiederkehrende Zeitfresser bemerkbar machen. In solche Fälle entwickeln wir automatisierte Workflows oder neue Tools, die oftmals aus der Synthese zwischen laufenden Prozessen und projektübergreifender Erfahrung hervorgehen. Aus unserer Sicht ähneln sich die Ursachen eines bestimmten Problemfelds häufig, und so sind alle unsere Entwicklungen darauf ausgelegt, mit wenigen Anpassungen von einem Projekt ins andere übertragen zu werden.

Ein BIM-Prozess lebt davon, dass er agil und flexibel bleibt. Da jedes Projekt individuell ist, ist nichts prozessual in Stein gemeißelt. Viel eher bedient sich ein gelungener BIM-Prozess aus einem Best-Practice-Katalog vergangener Erfahrungen und steckt sich so für das jeweilige Projekt sinnvolle Leitplanken. Innerhalb dieser Leitplanken gilt es für alle Projektteilnehmer, sich auch während des Projektes Gedanken zu machen, was nicht rund läuft und ob es der Einführung oder Entwicklung weiterer Hilfestellungen bedarf. Nicht für das nächste Projekt, sondern für das aktuelle. Am wichtigsten ist hierbei die initiale Festlegung, wen welches Problem betrifft und für wen das Problem gelöst werden soll. Daraus resultiert häufig ein Ansatz des Wie.

In unserer Arbeit als BIM-Manager vergleichen wir über Projekte hinweg ähnliche Fragestellungen und haben dadurch eine breite Basis, um Prozesse anreichern oder verbessern zu können. Meistens ist das Resultat eine Vereinfachung, die aus Verknüpfung zwischen Best-Practice und Automatisierung hervorgeht oder bestehende Workflows und dahinterliegende Systeme für weitere Anwendungsbereiche öffnet. Beispiele hierfür sind vielfältig. In diesem Artikel konzentrieren wir uns deshalb auf vier Entwicklungen, die dabei helfen, zwischen verschiedenen Projektbeteiligten zu vermitteln.

Automatische Qualitätsberichte mit Dynamo Skript

In unseren BIM-Management- und Gesamtkoordinationsprojekten vereinbaren wir zu Beginn des Projekts mit den Planern, dass sie beim Upload zur Koordination eine Checkliste auf Vollständigkeit des Modells ausfüllen sollen. Die Checkliste prüft auf die im BAP niedergelegten Aspekte, z. B. Modellierungsrichtlinien oder zu pflegende Attribute. Diese Vereinbarung dient der Kommunikation zwischen Planer und Gesamtkoordinator, dass das Modell iterativ entsprechend der geltenden Fassung des BAP aufgebaut wird, und ist eine nützliche Ergänzung zu den Datadrops, da daran die Qualität des Modells abgeschätzt werden kann.

In unserer Arbeit als Gesamtkoordinator oder qualitätsprüfende Instanz haben wir projektübergreifend bei jedem Iterationszyklus denselben Arbeitsablauf: Wir überprüfen den Input der Checkliste, und die Planer müssen entsprechend fortlaufend dieselbe Liste erstellen. Daher haben wir beschlossen, reaktiv zu entwickeln, mit dem Ziel, wiederkehrenden Arbeitsaufwand zu minimieren.

In einigen unserer Closed-BIM-Projekte setzen wir ein kleines Dynamo-Prüfskript ein, maßgeschneidert auf die Planer im Projekt. Ziel des Skriptes ist die Erstellung eines automatisierten Qualitätsprüfungsberichts, der die manuelle Checkliste ersetzt. Als Analysebasis werden hierbei in dem Skript Abfragen geschaffen, die mit den Spielregeln aus AIA und BAP gefüllt werden. Auch wird das Skript aktualisiert, sobald der Prozess im Projektverlauf angepasst wird. Als zweite Analyseebene wird grundlegend Bezug auf die VDI 2552 (Blatt 1 & 7) genommen, genau wie auf konkrete Fragestellungen aus der Planung, um keine Unruhe in das Projekt hineinzubringen.

Anreicherung des Prozesses

Der Bericht beinhaltet eine Sammlung von Informationen, die automatisch aus den verschiedenen Fachmodellen in einem Dokument zusammengefasst werden. Geprüft wird nicht wie in einer Clashdetection nach Überschneidung von Geometrien, sondern vielmehr nach fehlenden und fehlerhaften Eingaben. So dient das Tool neben der Sichtprüfung schon bei der Fachkoordination dazu, schnell Diskrepanzen bei z. B. Bearbeitungsbereichen, Ebenen, Höhen sowie bei den Metadaten zu Raumzuweisung und -benennung aufzudecken. Anstelle einer binären Falsch-/Richtig-Ausgabe unterscheidet eine Farbkodierung nach Ampelsystem zwischen kritischen (rot), pflegebedürftigen (gelb) und akzeptierten (grün) Ergebnissen.

Am besten geeignet ist das Tool für die Fach- sowie Gesamtkoordination. Wir haben jedoch die Erfahrung gemacht, dass es vor allem zu Beginn des Projekts sinnvoll ist, die Resultate zunächst vorzustellen und zu relativieren, da meist Skepsis und ein hoher emotionaler Wert gegen eine automatisierte Fehlersuche vorherrschen. Neben Clashdetection, Bauregel- und Attributprüfung stellen wir den Bericht den BIM-Autoren als weitere Hilfestellung zur Verfügung. Nach einer Eingewöhnungsphase wird das Tool jedoch in der Regel gut angenommen, oft sogar zur planerseitigen Selbstüberprüfung. Es den Planern zur Verfügung zu stellen, bedingt jedoch ein Verständnis im Umgang mit dem Tool sowie das Updaten der Einstellungen. Dementsprechend ist es für uns keine Selbstverständlichkeit, sondern ein Angebot, das wir den Planern unterbreiten.

Kollaboration nicht-modellierender Planer mithilfe von Desite

BIM-Projekte werden hauptsächlich objektbasiert bearbeitet: Objektbasierte Modellierung in den Hauptgewerken, objektbasierte Analyse, objektbasierte Kommunikation – immer steht das Modell im Mittelpunkt. Bisher hatten wir Schwierigkeiten, Planer, die nicht modellieren, am BIM-Prozess zu beteiligen. Was aus unserer Sicht fehlt, ist die projektspezifisch ausgerichtete Anreicherung des Abstimmungsprozesses zwischen modellierenden und nichtmodellierenden Planern.

Als Beispiel hierfür dient der Brandschutzplaner, der in der Regel für seine Aufgabe einen vom Modell abgeleiteten Plansatz seitens der Architektur zur Verfügung bekommt. Brandschutzplaner arbeiten gewöhnlich in Zonen, nicht bauteilorientiert – ganz anders als der im Projekt eingesetzte BIM-Prozess, der komplett bauteilorientiert ausgerichtet ist.

Die vom Brandschutz erarbeiteten Erkenntnisse werden zumeist umständlich kommuniziert und die Ergebnisse noch umständlicher wieder durch den Architekten ins Modell eingepflegt. Der Architekt fragt sich dabei zurecht, ob die Attributpflege des Brandschutzes überhaupt in seiner Verantwortung liegen sollten. Dadurch entsteht nicht zuletzt eine rechtliche Dissonanz, da diese Verantwortung aktuell bei demjenigen liegt, der als Autor die Informationen ins Modell bringt.

Zusätzlich zu der Möglichkeit, dass der Brandschützer durch BCF und einen BIM-Viewer den Architekten über die notwendige Aufteilung von Objekten aufgrund von Brandschutzanforderungen informieren kann, liegt unsere derzeitige Antwort in der Entwicklung eines Applet-Tools auf Basis von Desite zur einfachen Vergabe von Attributen.

Die Attribute werden in einer intuitiven Benutzeroberfläche im Tool vom Brandschützer direkt an die Objekte vergeben und entweder per SQL, Excel, JSON oder direkt per Revit-Plugin mit dem Autorenmodell des Architekten ausgetauscht. Dadurch können Ergebnisse in beinahe jede Autorensoftware zurückgespielt werden. Gemapped werden die Attribute dann in der Autorensoftware automatisch über die GUIDS der Objekte. So bekommt die Frage nach der Autorenschaft eine gewisse rechtliche Sicherheit, da die Verantwortung für die Planungsleistung bei den jeweiligen Planern (in diesem Fall Brandschutz) bleibt.

Die Kernanforderungen an dieses Tool bestehen darin, dass es einfach zu verstehen und zu bedienen, simpel aufgebaut sowie eine sehr niedrige Fehleranfälligkeit haben muss. Es gibt wenige Ansätze in der BIM-Tool-Landschaft, zumeist auf BIM-Autorensoftware aufsattelnd, die ähnliche Funktionalitäten bieten. Jedoch wird in vielen dieser Ansätze nicht bedacht, dass Autorensoftware-Unkundige die Attribute einpflegen. Der Planer braucht neben einer kostspieligen Lizenz auch vertieftes Wissen in der BIM-Autorensoftware – das ist z. B. bei Brandschützern nicht unbedingt notwendig und somit nicht voraussetzbar.

Zusammenarbeit mit planungsexternen Stakeholdern

Mittlerweile kann das Tool einfach angepasst für viele Szenarien zum Einsatz kommen. Unseren Erkenntnissen nach überall da, wo der Nutzer Input in Form von Attributen liefert, egal ob planungsfachkundig oder nicht. Somit ist eine weitere Kommunikationsschnittstelle z. B. für Bauherren, Nutzer, Vermieter, Facility Manager oder Kalkulation möglich. Die Liste der Anwendungsbereiche wird in der Regel in jedem Projekt länger.

Schlitz- und Durchbruchs-Toolbox

Ein wenig umständlicher wird es, wenn die Planer der Fachgewerke zwar BIM-konforme Arbeit leisten können, die technische Kommunikation zwischen ihren Systemen aber nicht reibungslos funktioniert. Gerade beim Open-BIM-Prozess kommt es immer wieder vor, dass es zunächst an den Grundeinstellungen, z. B. beim Export der IFC, zu Komplikationen kommt. Auch kommt es vor, dass im Workflow definierte Systeme nicht optimal miteinander kommunizieren können.

Während ersteres in Form von angeleiteten Proof of Concept-Workshops einfach zu beseitigen ist, muss sich das Planungsteam bei letzterem genau überlegen, an welchem Punkt im Prozess es ansetzt und wem im Zweifel ein erhöhtes Maß an Mehraufwand zugemutet werden kann, um den Prozess am Laufen zu halten. So auch im folgenden Beispiel, in dem sich der Fachplaner der TGA zwar modellbasiert in die Koordination aufnehmen ließ, seine Software jedoch nur über fehleranfällige Umwege in die modellbasierte Kommunikation integriert werden konnte. Da die Schlitz- und Durchbruchsplanung laut BAP auch am Modell durchgeführt werden sollte, musste eine einfachere Möglichkeit her, den Koordinations- und Freigabeprozess der einzelnen Voids zu unterstützen.

Im Projekt wurden BCFs für die modellbasierte Kommunikation und das Verteilen von Issues bereits über einen Server ausgetauscht. Es lag also nahe, an den BCF-Workflow anknüpfend zu entwickeln, um die Haustechnik in die Kommunikation zu integrieren.

Das entwickelte Tool verfolgt den Ansatz, softwareunabhängig zu durchleuchten, zu welchem Objekt mit welcher GUID es bereits zu einem bestimmten Etikett Issues auf dem BCF-Server gibt. Exportiert die Haustechnik nun aus ihrer Autorensoftware eine IFC mit Voids oder deren Änderungen, kann der Planer das Tool starten. Es generiert automatisch für die Voids, die noch nicht auf dem Server zu finden sind, neue Issues. Gleichzeitig schreibt es die Issue-Informationen direkt an das jeweilige Objekt als neue Attribute in die IFC, mit den Informationen zu Issue-Nr., Status und Freigabeanforderung. Die Issues werden wie gewohnt mit dem BCF-Server synchronisiert, die IFC aus dem Tool automatisch exportiert und entsprechend verteilt.

Konkrete Anreicherung des Workflows

Die Vereinfachung entsteht dadurch, dass der TGAler nicht in seiner Autorensoftware parallel zu einem BCF-fähigen Viewer navigieren muss, um nachzuvollziehen, welche Voids entsprechend durch die Architektur bearbeitet wurden und was der Status des Freigabeprozesses aussagt. Er kann nun über die Issue-Nr. in seinem Modell filtern und entsprechend die Paramater sichten.

Sein einziger Mehraufwand ist es, die exportierte IFC vor dem Verteilen noch durch das Tool laufen zu lassen, statt bei jeder Kommunikation umständlich zwei Programme zu bedienen. Kombiniert mit dem vorgestellten Attributtool ist es ihm sogar noch möglich, weitere Parameter anzuhängen. So wird der abgesprochene fehlerbelastete Kommunikationsprozess deutlich verschlankt und zielgerichtet umgesetzt, ohne dass der Prozess dafür langwierig umgestellt werden muss.

BCF-Integration in Echtzeitvisualisierungen & Virtual Reality (VR)

Problematisch wird es, wenn die aktuell aufkommende Technologie zwar hervorragend zum BIM-Prozess passt, dadurch aber weitere Kommunikationsbarrieren in der Umsetzung entstehen. Echtzeitvisualisierungen und VR-Begehungen scheinen mittlerweile die perfekte Form, um planungsrelevante Inhalte auf sehr einfache und intuitive Art zu kommunizieren. Vor allem in Kombination mit einem BIM-Projekt ist die Darbietungsform mittlerweile stark vertreten, da das Visualisierungsmodell ohne großen Mehraufwand vom Planungsmodell abgeleitet werden kann.

Jedoch entsteht gerade bei der Echtzeitvisualisierung im BIM-Prozess bislang immer eine Sackgasse. Denn es ist nicht möglich, die durch die Visualisierung gewonnenen Erkenntnisse direkt ins Planungsmodell zurückzuführen. Die Fülle an spontanen Reaktionen der User, beispielsweise bei nichtplanenden Stakeholdern (z. B. in Nutzerworkshops), ist nur eingeschränkt katalogisierbar. Umwege über Gedächtnisprotokolle und Notizen sind möglich, müssen jedoch mühsam wieder mit dem Modell verknüpft werden. Meist herrscht eine schwammige Lokalisierbarkeit der zum Ausdruck gebrachten Erkenntnisse in den Planungsunterlagen.

Inspiration aus anderen Workflows

Um den Einsatz von Echtzeitvisualisierungen und VR-Begehungen sinnvoller zu gestalten, haben wir uns mit der Frage auseinandergesetzt, ob Erkenntnisse nicht auf dieselbe Weise wie z. B. Issues einer Clashdetection systematisch aufgenommen und verarbeitet werden können.

Das Resultat ist eine einfache Eingabemaske in der Visualisierung, über welche Issues aufgenommen und über einen BCF-Server synchronisiert werden können. So wird die punkt- oder objektscharfe Zuordnung von Erkenntnissen möglich: der Input wird gepaart mit lokalisierten Screenshots, die nahtlos in die Autorensoftware eingelesen werden können – analog zum oben beschriebenen BCF-Workflow, der sich mittlerweile als beinahe selbstverständlich in BIM-Projekten platziert hat. So kann der Nutzer einen direkten Sprung zur räumlichen Situation vollziehen, in der Erkenntnisse gewonnen und als Kommentare verfasst wurden – ganz gleich, ob in der Visualisierung, im BIM-Viewer oder in der Autorensoftware. Dadurch schrumpfen die möglichen Fehlerquellen, da die Dokumentation keine räumliche Interpretation mehr zulässt.

Fazit

Diese und viele weitere Beispiele sind Indikatoren dafür, dass BIM neben einer Methodik auch beständiges Development ist: zwischen der Anpassung des jeweiligen Best Practice und dem Einsatz sowie der Verbesserung neuer Tools. Für uns lässt sich diese Entwicklung aufteilen in zwei Hauptkategorien: die aktive und reaktive Entwicklung.

Reaktive Entwicklung geht der Frage nach, was verbessert werden kann. Sie ist eine in kleiner Granularität hervortretende Konstante, die in jeder Ebene eines BIM-Prozesses permanent stattfindet: Aus Gelerntem iterativ Best Practices weiter ausbauen und für das nächste Projekt in Anwendung bringen.

Die aktive Entwicklung verknüpft hingegen auf deutlich breiterer Basis Best Practice mit prozessualem Wissen und Gelerntem aus verschiedenen Projekten sowie Technologie, um übergeordnet fehlende Prozesse und Tools zu identifizieren, zu erstellen und so kollaborative Verbesserung zu systematisieren. Dabei kommt es auf die Replizierbarkeit von Prozessen an und auf die akute Notwendigkeit, die die jeweiligen Stakeholder an solche Toolentwicklungen stellen. Ohne Input aus den Projekten – dem Input von denjenigen, die die Tools und Prozesse nutzen – kann kein zielführender Beitrag entstehen.

Dementsprechend schlecht lässt sich im theoretischen Elfenbeinturm entwickeln. Development lebt vom konstanten Kontakt mit laufenden Prozessen, der beständigen Operation am offenen Herzen. Die beste Grundlage für Veränderung bleibt somit das aktive Projektgeschehen, in dem neue Herausforderungen zu neuen Entwicklungen inspirieren.