In der Baubranche wird noch immer lebhaft darüber diskutiert, ob BIM wirklich zu geringeren Kosten – bei der Planung, Errichtung oder im Betrieb – bringt. Die meisten Unternehmen halten sich dabei jedoch ziemlich bedeckt, konkrete Zahlen werden hier kaum herausgegeben. Hinter vorgehaltener Hand wird jedoch oft gesagt, dass (zumindest auf Seiten der Planer) BIM nicht zu einem finanziellen Vorteil führt. Wie kann das sein, wo doch die Softwarehersteller eine Einsparung im zweistelligen Prozentbereich „versprechen“?
Regionale Unterschiede in der Planungstiefe
Die Planungstiefe von Bauprojekten unterscheidet sich von Land zu Land. Dies wird einem sehr deutlich bewusst, wenn man die Beispielprojekte vergleicht, welche z.B. mit Autodesk Revit ausgeliefert werden. Ein Geschoß im „advanced“ Modell für den angelsächsischen Raum besteht aus einer Ebene. Im deutschen Bespiel gibt es vier Bauteile, 12 „Geschoße“ (Höhenlage der unteren Geschoße nicht gleich, weil Alt- und Zubau) und nicht weniger als 96 Ebenen. Dadurch steigt natürlich auch der Aufwand, um dieses Modell „im Griff“ zu haben. Die konstruktiven Entscheidungen, so scheint es, werden „drüben“ erst später im Projekt von den Generalunternehmern getroffen, während hierzulande sehr viel vom Planer festgelegt wird. Welche Vorgehensweise sinnvoller ist sei dahingestellt; aber es führt natürlich hierzulande zu einem vergleichsweise höheren Aufwand in der Planung.
Planungstiefe im Vergleich zu CAD vs. Phasenmodell
In der konventionellen Projektbearbeitung wurde zu jedem Zeitpunkt möglichst nur so viel festgelegt wie nötig. Die Abstraktion einer Wand bestand zu Beginn einfach nur zwei Linien; dies genügte, um die Raum- und Gebäudegrenzen zu erfassen. Fenster und Türen waren einfach nur „kein Wand“. Schrittweise wurde das Gebäude während des Entwurfs erarbeitet, Breiten und Abstände definiert, die Höhenentwicklung großteil zu Beginn nur „mitgedacht“ und an neuralgischen Punkten kontrolliert. Was definiert war, wurde dokumentiert.
So fehleranfällig diese Vorgehensweise auch sein kann, so entspricht sie der bisherigen Denkweise und Ausbildung der meisten Planer. Architekten entwickeln ihre Gebäudeentwurfe nun mal großteils aus der Funktion, also aus dem Grundriss heraus (Ausnahmen gibt es natürlich immer). Wurde an einer Stelle ein Fenster angedacht, so musste man sich noch keine genauen Gedanken darüber machen, wie breit oder hoch es sein musste, wie das Fenster geöffnet wurde, wie hoch das Parapet sein musste etc.
Genau diese Fragen tauchen jedoch jetzt mit der objektbasierten Planungsweise auf. Es gibt hier keine Möglichkeit, „Platzhaltereigenschaften“ von realen zu unterscheiden. All das müsste mit Kommentaren gemacht werden, was aber einen hohen Aufwand bedeutet, und somit kaum in der Praxis angewendet wird. Somit sehen alle Bauteilattribute gleich relevant und „richtig“ aus. Es ist kaum möglich, ein Fenster in einem BIM-Modell zu platzieren, ohne Einstellungen über die Parapethöhe zu machen. Um diesen Bauteil später nicht nochmals „angreifen“ zu müssen, beschäftigt man sich also mit der endgültigen Position und Ausprägung desselben; und das meist zu einem Zeitpunkt, an dem noch jede Festlegung im Projekt grundsätzlich in Frage gestellt werden kann. Das besagte Fenster kann bereits bei der nächsten Gelegenheit vom Auftraggeber „entfernt“ werden. Der Aufwand, der in solche Bauteile gesteckt wird, ist somit verloren, und führt wiederum zu höheren Kosten.
Es existieren allerdings keine BIM-tauglichen Programme, die eine effiziente Vorentwurfsgestaltung möglich machen, weshalb die vorhandenen, stark ausführungsorientierten Programme (verfrüht) eingesetzt werden. Es wird also noch früher und noch detaillierter geplant, ohne dass die erforderlichen Entscheidungen von Seiten der Auftraggeber getroffen worden wären (dass diese gerne bis zur Baufertigstellung Änderungen vornehmen steht auf einem ganz anderen Blatt).
Deliverables
Die konventionelle Planung war sehr stark an den zu liefernden Dokumenten (Pläne, Listen, Beschreibungen etc.) orientiert. Es wurde alles definiert, was auf diesen Dokumenten darzustellen war. Bei Unklarheiten wurden diese weiter ausdetaiilliert oder zusätzliche Unterlagen erstellt. Was nicht sichtbar war, existierte formal also gar nicht.
Im Gegensatz dazu strebt BIM die vollständige und umfassende Dokumentation jedes einzelnen Bauteils im Gebäude an, selbst wenn diese auf keinem Plan oder in keiner Liste aufgeführt werden. Natürlich könnten andere Projektbeteiligte diese Information weiter nutzen uns sich somit die Eingabe ihrerseits „sparen“; dies setzt aber voraus, dass diese die Eigenschaften auch tatsächlich weiterverarbeitet werden können, wollen und dürfen. Andernfalls werden diese Informationen „auf Vorrat“ produziert. Die mögliche Kostenersparnis zu einem späteren Zeitpunkt muss der Auftraggeber natürlich entsprechend vergüten.
Fehlende / Falsche Anforderungen
Als Grundvoraussetzung für ein erfolgreiches BIM-Projekt wird eine eindeutige und vollständige Vorgabe durch den Auftraggeber gesehen. Wenn diese Auftraggeber-Informationsanforderungen („AIA“, neuerdings wird dies entsprechende der ISO 19650 mit Austauschinformationsanforderung bezeichnet) vorhanden ist, so der generelle Tenor, dann „funktioniert“ BIM auch. Dann braucht es „nur mehr“ eine Spezifizierung in einem BIM-Abwicklungsplan („BAP“), und jede am Projekt beteiligte Person bzw. Firma muss nur mehr ihre Punkte abarbeiten, es entstehen Synergien, insgesamt wird das Projekt billiger. Soweit die Theorie.
In der Praxis schaut es leider ganz anders aus. DIes beginnt damit, dass entweder derartige Vorgaben gänzlich fehlen oder diese widersprüchlich, falsch oder unnötig sind. In einer AIA legt der Auftraggeber fest, welche Informationen wann geliefert werden müssen, dies wird im BAP noch genauer dargestellt. In weiterer Folge werden wir uns in diesem Artikel auf den BAP beziehen.
Eine solche Vorgabe setzt mehrere Dinge voraus.
Der AG weiß, wann er welche Information von wem in welcher Form benötigt
Dies ist bereits der erste Unsicherheitsfaktor, denn zumeist sind nicht einmal die eigentlichen Projektvorgaben (die tatsächliche Planungsaufgabe) nicht vollständig definiert. Es ist unrealistisch, dass der Auftraggeber darüber hinaus die Kompetenz hat, die digitale Abwicklung zu konzipieren bzw. zu „dirigieren“. Die Projektleitung ist schon ein „Spezialgebiet“, die digitalen Aspekte noch ein weiteres. Auch wenn der seltene Fall eintritt, dass die eigenen Informationsanforderungen bekannt sind, so können niemals die Zusammenhänge und Abhängigkeiten im Projekt vollständig erfasst und vorab definiert werden.
Daraus lässt sich Folgendes ableiten: führen diese Informationen nur auf Seiten des AG zu Mehrwerten (in der weiteren Nutzung des Gebäudedatenmodells), können aber von den anderen Parteien nicht (automatisiert) genutzt werden, so bedeutet diese Dateneingabe Mehrarbeit für den Auftragnehmer und – selbstverständlich – zu höheren Kosten. Sind die Vorgaben der AIA darüber hinaus so definiert, dass die Informationen nur „auf Vorrat“ im Modell eingepflegt werden – diese also auf absehbare Zeit nicht genutzt werden (können) – so wird es auch insgesamt teurer.
Der AG weiß, wie der Informationsbedarf der anderen Beteiligten ist
Betrachtet man den BAP als einfache Weiterentwicklung der AIA, so entsteht der Eindruck, dass der AG sämtliche Zusammenhänge im Projekt verstehte. Selbst wenn sich alle Beteiligten an die Liefertermine halten, gibt es doch immer wieder Abhängigkeiten, die vorab nicht ersichtlich waren, und welche eine vorfristige Lieferung von Informationen erfordert hätten. Dies kann eine Lawine von Abhängigkeiten in Gang setzen, welche die ganze „Lieferkette“ durcheinander bringt.
Das bedeutet, dass der AG nur seine eigenen Anforderungen definieren kann, und jeder andere Projektebeteiligte dies für sich selbst genauso machen muss. Und nein, eine Norm kann das nicht für jeden übernehmen. Womit wir wieder beim oberen Punkt angekommen sind; dass nämlich auch die Auftragnehmer nicht vollständig erfassen können, was sie wann an Information brauchen. Aber diese Erkenntnis und der Umgang damit ist bereits ein großer Schritt.
Die Informationen haben ein Format, das alle weiterverarbeiten können
Damit kommen wir zu einem eher technischen Aspekt der Thematik. Wir haben oben gesehen, dass jedes Unternehmen ihre Informationsbedürfnisse selbst festlegen muss, um diese mit den internen Prozessen in Einklang zu bringen. Dazu braucht es Schnittstellen nach außen, damit dieser Informationsaustausch auch effizient passiert. Eine solche Schnittstellendefinition ist jedoch nur selten der Fall.
Die Schnittstelle heißt zumeist „Mensch“. Baufirmen modellieren Projekte neu, um diese schneller und vollständiger kalkulieren zu können. Manchmal wird nochmals modelliert, um nach gewonnenem Auftrag die Baustelle (und Ausschreibungen für die Nachunternehmen) besser organisieren zu können. Tragwerksplaner bauen Wände nach, die bereits im Architekturmodell enthalten sind. Informationen werden händisch eingegeben, weil die Formate nicht kompatibel sind. Ein Paradies für Schnittstellen- und Softwarehersteller, frei nach dem Prinzip „teile und herrsche“.
Auch hier gibt es mehrere Strömungen, wie diesem Wirrwarr entgegnet werden kann. Einerseits existieren Normen, welche Begriffe und ihre Formate vorschlagen. Diese müssten allerdings in sämtliche internen Systeme aller Unternehmen in der Baubranche implementiert werden. Unrealistisch, gelinde gesagt, sofern nicht eine Lösung durch die Softwarehersteller bereitgestellt wird (wobei hier kaum Interesse besteht, an dem lukrativen Status Quo etwas zu ändern). Andererseits müsste jedes Unternehmen von sich aus eine „Übersetzung“ in ein neutrales Format bzw. in den Standard eines anderen Unternehmens schaffen. Das ist zwar ebenfalls viel Kleinarbeit, stört aber die internen Abläufe (und somit das „Geschäft“) in wesentlich geringerem Ausmaß. Voraussetzung sind natürlich dokumentierte Standards und kompetente Personen, die diese Schnittstelle erarbeiten.
Entkopplung von Planung und Umsetzung
Die sich immer stärker spezialisierenden Personen in der Planung – BIM-Tool setzen eine gewisse IT-Affinität voraus – führt dazu, dass es zu einer weiteren Entkopplung zwischen den Planenden und Ausführenden kommt. Es wird zwar oftmals festgelegt, dass so modelliert werden so, wie auch gebaut wird; wenn allerdings das Wissen um die praktische Umsetzung fehlt, kann eine detaillierte Planung – zu den höheren Stundensätzen, die für die Spezialisten anfallen – nur bedingt „richtig“ sein, jedoch teuerer kommen als bisher. Die Technologie führt dazu, dass noch weniger Austausch zwischen den Personen im Büro und jenen auf der Baustelle stattfindet. Oftmals werden Bauteile wenn nicht falsch dann zumindest unnötig modelliert, weil die Umsetzung jedem Handwerker augenscheinlich klar ist. Eine Systemskizze kann hier besser weiterhelfen, als wenn alle Anschlüsse im Detail (vermeintlich) richtig modelliert wurden.
Dieses Augenmaß bzw. die direkte Kommunikation mit den ausführenden Personen fehlt leider immer mehr, und die BIM-Technologie in der derzeitigen Form ist hier eher hinderlich. Damit wird nämlich in erster Linie versucht, Methoden aus dem Büro auf die Baustelle zu bringen, was zumeist nicht von Erfolg gekrönt ist.
Zusammenfassung
BIM birgt also das Risiko, dass zu früh und zu detailliert ein (Daten-)Modell erstellt wird, das nicht weiter verwendet werden kann. Wenn diese Punkte gelöst sind, dann – allerdings nur dann – kann BIM zu einer signifikanten branchenweiten Produktivitätssteigerung führen. Bis dahin wird man sich mit kleinen Verbesserungen zufrieden geben müssen, und – auch das – mit dem Bezahlen von jeder Menge Lehrgeld, um – wenn es so weit ist – für die Zukunft gewappnet zu sein.
Klingt das alles nicht sehr pessimistisch? Vielleicht. Ich höre gerne von positiven Gegenbeispielen. Allerdings sehe ich auch im Kleinen erhebliches Potential, ohne alle tradierten Prozesse und Aufgaben neu erfinden zu müssen. Wie, das werde ich in einem der nächsten Artikel etwas näher erörtern.