IFCLint
Registrieren
Lektion 1.37 min Lesezeit

Warum BIM-Projekte scheitern

BIM-Projekte scheitern selten an der Software. Sie scheitern an unklaren Anwendungsfällen, nicht prüfbaren Anforderungen und fehlender Modellprüfung. Diese Lektion zeigt die wiederkehrenden Muster — und wo man frühzeitig ansetzen kann.

KonstrukteureIngenieureBIM-KoordinatorenBIM-Manager

Lektion 1.3 — Warum BIM-Projekte scheitern

Lernziel

Nach dieser Lektion kannst du die häufigsten strukturellen Ursachen erkennen, warum BIM-Projekte nicht das halten, was sie versprochen haben. Du weisst, an welchen wenigen Stellen früh angesetzt werden muss, damit Modelle am Projektende tatsächlich nutzbar sind — und woran man erkennt, dass ein Projekt gerade in eine dieser Lücken läuft.

Praxisproblem

Kurz vor der Übergabe an die Bauphase trifft sich das Team zur Abnahme der Fachmodelle. Es sind viele Modelle vorhanden, gut detailliert, in IFC exportiert. Der Auftraggeber fragt: „Welche Brandschutzklasse hat diese tragende Wand im zweiten Obergeschoss?" Stille. Die Information steht im Plan, nicht im Modell. Im Vertrag wurde „in BIM erstellt" verlangt — was genau geliefert werden sollte, blieb offen.

So endet ein nicht unerheblicher Teil von Projekten, die unter dem Label BIM laufen. Es gibt Modelle. Es wird modelliert. Es wird exportiert. Aber das, was am Ende nutzbar wäre, fehlt — meist nicht aus technischen Gründen, sondern weil die Methode den Weg nicht durchgehalten hat.

Diese Lektion sortiert die typischen Ursachen. Sie sind erstaunlich konstant, projektgrössen- und länderübergreifend.

1. Anwendungsfälle wurden nie festgelegt

Wer ein Modell bestellt, ohne den Zweck zu definieren, bekommt am Ende, was geht, nicht was er braucht. Wie in Lektion 1.1 erklärt, machen die Anwendungsfälle (Use Cases) aus einem 3D-Projekt erst ein BIM-Projekt: Mengenermittlung, Koordination, Bauablaufplanung, Auswertung, Betrieb.

In der Praxis steht in Ausschreibungen oft „Die Modelle werden in BIM erstellt", aber nicht, wofür sie konkret genutzt werden sollen. Folge: Fachplaner modellieren nach eigenem Bauchgefühl. Das eine Team rüstet alles mit Property Sets aus, das andere liefert geometrisch saubere, aber semantisch leere Modelle. Beides passt für sich, aber nicht für den gemeinsamen Zweck — denn der Zweck wurde nie benannt.

2. Informationsanforderungen sind nicht prüfbar formuliert

Wenn Anwendungsfälle benannt sind, folgt die nächste Hürde: Welche Informationen müssen am Bauteil hängen, damit der Anwendungsfall funktioniert? Eine Mengenermittlung verlangt Bauteilklasse und Material. Eine Brandschutz-Auswertung verlangt eine Feuerwiderstands-Eigenschaft an jeder relevanten Komponente. Eine Bauablauf-Simulation verlangt eine Verknüpfung von Bauteilen mit Vorgängen.

Solche Anforderungen sollten schriftlich, eindeutig und prüfbar festgehalten sein. Auftraggeber-Informationsanforderungen und ein BIM-Abwicklungsplan sind die Werkzeuge dafür (diese Begriffe vertiefen wir später im Kurs). Wenn sie fehlen oder so vage formuliert sind, dass jede Lieferung als „erfüllt" durchgewunken werden könnte, ist die Lieferqualität nicht steuerbar.

Eine Anforderung wie „Modelle in hoher Qualität liefern" ist nicht prüfbar. „Jede tragende Wand trägt die nach geltender Brandschutz-Norm definierte Feuerwiderstandsklasse als Property" ist prüfbar.

3. Modellprüfung fehlt oder findet zu spät statt

Selbst gut formulierte Anforderungen helfen nicht, wenn niemand prüft, ob sie erfüllt sind. Modellprüfung ist kein optionaler Schritt — sie ist das, was die Anforderung mit der Lieferung verbindet.

In vielen Projekten passiert die erste Prüfung erst, wenn das Modell schon übergeben wurde. Dann ist es spät: Fehler, die hunderte Bauteile betreffen, müssen rückwirkend korrigiert werden. Bauteiltypen sind nicht klassifiziert, Property Sets fehlen, Disziplinen widersprechen sich räumlich. Wäre das alles zwei Monate früher aufgefallen, wären es Korrekturen am Modell. So sind es Korrekturen am Vertrag.

Eine wiederholbare Modellprüfung — automatisiert oder im Workflow — verschiebt diesen Aufwand nach vorn. Das ist der einzige Punkt, an dem die strukturellen Schwächen aus Kapitel 1 und 2 noch eingefangen werden können.

4. Verantwortung ist verteilt, niemand kuratiert

In klassischen Bauprojekten ist die Rollenverteilung über Jahrzehnte gewachsen: Architekt, Tragwerksplaner, Haustechnik, Bauleitung, Bauherr. Jede Disziplin kennt ihren Beitrag. In BIM-Projekten kommt eine Querschnittsfunktion dazu — jemand muss die Modelllieferung über alle Disziplinen koordinieren, prüfen und in Beziehung setzen. Diese Funktion heisst BIM-Koordination oder BIM-Management.

Wenn diese Funktion nicht klar besetzt ist oder ohne Mandat arbeitet, fallen die Verbindungen zwischen den Disziplinen aus. Jedes Team liefert intern korrekt, aber niemand sieht das Gesamtbild. Konflikte zwischen Fachmodellen werden zu spät erkannt. Informationsanforderungen werden teilweise umgesetzt, teilweise nicht. Am Ende ist das Modell die Summe vieler Insellieferungen.

Die vier Bruchstellen im Überblick

Vier strukturelle Bruchstellen in BIM-Projekten Schematischer Projektverlauf von Anwendungsfällen über Anforderungen, Modell, Prüfung bis zur Lieferung. Vier rote Marker zeigen die typischen Bruchstellen, an denen BIM-Projekte scheitern: Anwendungsfälle nie festgelegt, Anforderungen nicht prüfbar, Modellprüfung fehlt oder zu spät, Koordination ohne Mandat. Vier strukturelle Bruchstellen im BIM-Projekt Anwendungsfälle Wofür wird modelliert? Anforderungen Was muss geliefert werden? Modell Bauteile, Properties Prüfung Stimmt die Lieferung? Lieferung Nutzung 1. Anwendungsfälle nie festgelegt Modell ohne Zweck. Jede Disziplin liefert nach Bauchgefühl. 2. Anforderungen nicht prüfbar „In hoher Qualität" ist keine Anforderung, sondern eine Hoffnung. 3. Modellprüfung fehlt oder zu spät Fehler werden erst in der Abnahme sichtbar. 4. Koordination ohne Mandat Niemand kuratiert das Gesamtbild über die Disziplinen. Wer früh klärt, korrigiert in Wochen. Wer es nicht tut, korrigiert in Monaten — oder gar nicht.

Diese vier Stellen sind nicht alles, was schiefgehen kann. Aber sie sind die häufigsten, sie greifen ineinander, und sie lassen sich früh erkennen.

5. Beispiel: Ein Spital in der Abgabe

Ein Spital mit 18'000 m² Bruttogeschossfläche wird unter BIM-Auflagen geplant. Vier Fachplaner modellieren Architektur, Tragwerk, HLK und Sanitär. Alle exportieren am Meilenstein in IFC. Erst in der Abnahmesitzung fällt auf, dass die Brandschutzklassen — explizit Bestandteil der Auftraggeber-Anforderung — nur in den Architekturplänen vorhanden sind, nicht aber als Property an den Bauteilen.

Die Korrektur dauert sechs Wochen. Drei davon sind Diskussion über Verantwortung, drei sind tatsächliche Anpassung. Das Projekt verliert kein Geld am Modellieren — es verliert es an der Lücke zwischen Anforderung, Lieferung und Prüfung. Die Methode war im Vertrag, aber sie war nie durchgespielt.

Es ist nicht das spektakulärste Szenario. Es ist das häufigste.

6. Typische Fehler

Diese Anti-Pattern tauchen in scheiternden BIM-Projekten besonders oft auf:

  1. „Wir klären den Anwendungsfall später." Später ist im BIM-Kontext der Punkt, an dem die Korrektur teurer wird als die Neuplanung.
  2. Anforderungen ohne Prüfkriterium. Sätze wie „Modelle in hoher Qualität" oder „IFC-konform" sind keine Anforderungen, sondern Wunschäusserungen.
  3. Modellprüfung nur am Projektende. Eine Prüfung, die nicht regelmässig stattfindet, ist eine Abschlusskritik — keine Steuerung.
  4. BIM-Koordination ohne Mandat. Wer Modelle koordinieren soll, aber gegenüber den Fachplanern keinen formalen Hebel hat, ist Berater, nicht Koordinator.
  5. Software-Entscheidung vor Methode. Welche Werkzeuge sinnvoll sind, ergibt sich aus den Anwendungsfällen und Standards — nicht aus Lizenzpolitik oder Bürogewohnheit. Werkzeuge sind nicht egal, aber sie kommen nach der Methode.
  6. „BIM" als Marketing-Etikett im Vertrag. Steht das Wort im Auftrag, ohne dass Anwendungsfälle, Anforderungen und Prüfprozesse definiert sind, ist die Lieferform offen — und damit das Risiko vertraglich nicht greifbar.

7. Mini-Checkliste

Wenn du beurteilen willst, ob ein laufendes oder anstehendes BIM-Projekt in eine dieser Lücken läuft, prüfe:

  • Sind die Anwendungsfälle des Modells schriftlich festgehalten?
  • Sind die Informationsanforderungen so formuliert, dass eine Lieferung sich daran objektiv prüfen lässt?
  • Gibt es einen vereinbarten Rhythmus für Modellprüfung — nicht nur am Ende?
  • Ist die BIM-Koordination personell besetzt und mit Mandat ausgestattet?
  • Sind die Verantwortlichkeiten für jede Modelllieferung dokumentiert?
  • Sind die Werkzeuge an den Anwendungsfällen ausgerichtet, nicht umgekehrt?

Sind drei oder mehr Punkte mit „Nein" beantwortet, ist das Projekt nicht zwingend verloren — aber es läuft auf einer der bekannten Bruchstellen. Wer den Hebel früh ansetzt, korrigiert mit Wochen Aufwand, was später Monate kostet.

8. Reflexionsfrage

Denke an ein BIM-Projekt aus deiner Erfahrung, in dem die Lieferung anders ausgesehen hat als erwartet. An welcher der vier strukturellen Ursachen lag es vermutlich? Und wenn du es heute neu aufsetzen müsstest — welche eine Massnahme aus der Checkliste hätte den grössten Unterschied gemacht?

Manchmal lohnt es sich, die gleiche Frage mit zwei oder drei früheren Projekten durchzugehen. Oft erkennt man, dass es immer dieselbe Ursache war — nur in anderer Verkleidung.

Merksätze

BIM-Projekte scheitern selten an der Software. Sie scheitern an der Methode dahinter.

Anwendungsfälle, prüfbare Anforderungen, regelmässige Modellprüfung und klar mandatierte Koordination sind die vier Stellen, an denen sich BIM-Projekte entscheiden — lange bevor das erste Modell exportiert wird.

Wer früh klärt, korrigiert in Wochen. Wer es nicht tut, korrigiert in Monaten oder gar nicht.

Quellen und weiterführende Literatur

Nächste Lektion
BIM-Anwendungsfälle

Lektion 1.4 · 8 min Lesezeit