Lektion 1.4 — BIM-Anwendungsfälle

Lernziel

Nach dieser Lektion kannst du die häufigsten BIM-Anwendungsfälle benennen, ihre typischen Informationsanforderungen einordnen und für ein konkretes Projekt entscheiden, welche Anwendungsfälle sinnvoll sind und welche nicht. Du weisst, warum die Auswahl der Anwendungsfälle vor allen anderen Entscheidungen kommt.

---

Praxisproblem

In der Startbesprechung eines neuen Projekts kommt die Frage auf: „Was machen wir denn jetzt eigentlich mit den Modellen?" Die Antworten reichen von „Koordinationssitzungen abhalten" über „Mengen rausziehen" bis „Wir liefern für den Betrieb". Jede Antwort klingt plausibel. Jede führt zu einem anderen Modell, einer anderen Informationsanforderung und einem anderen Aufwand.

Solange diese Frage offen bleibt, modelliert das Team auf Verdacht. Manche Bauteile werden detailliert ausgearbeitet, weil jemand annimmt, sie würden für eine spätere Mengenermittlung gebraucht. Andere bleiben generisch, weil niemand sicher ist, ob sie für etwas relevant sind. Am Ende ist das Modell überall ungenau, je nachdem, was später wirklich verlangt wird.

Genau hier setzen die Anwendungsfälle (Use Cases) an. Sie sind die Antwort auf die Frage, wofür das Modell konkret verwendet werden soll — und damit die Grundlage für alle weiteren Entscheidungen über Modellqualität, Informationsanforderungen und Lieferprozess.

---

1. Was ein Anwendungsfall ist

Ein BIM-Anwendungsfall beschreibt einen klar abgegrenzten Zweck, für den ein Modell oder Modellteil genutzt wird. Drei Eigenschaften zeichnen einen sauber formulierten Anwendungsfall aus:

Er nennt das Ziel in einer Form, die nachweisbar erreicht oder verfehlt werden kann („Mengen für die Submissionsphase ermitteln" — nicht „Mengen verbessern").

Er nennt die Phase oder den Zeitpunkt, in dem er stattfindet („zum Meilenstein Submission", „in der Vorprojektphase", „beim Übergang in den Betrieb").

Er nennt implizit oder explizit die Informationen am Modell, die er voraussetzt — also welche Eigenschaften und welche Klassifikationen vorhanden sein müssen, damit der Anwendungsfall durchführbar ist.

Wer einen Anwendungsfall in diesem Sinne formuliert, hat schon die Hälfte des Informationsanforderungs-Konzepts. Die andere Hälfte ist die Frage, wer liefert und wer prüft — das ist Thema späterer Module.

---

2. Die häufigsten Anwendungsfälle im Überblick

Die folgende Tabelle zeigt die in der Praxis am meisten verbreiteten Anwendungsfälle, jeweils mit ihrem typischen Hauptzweck und den Informationen, die sie am Modell verlangen.

Die Tabelle ist nicht abschliessend. In Infrastrukturprojekten gibt es weitere Anwendungsfälle wie Trassierung, Vermessungs-Abgleich oder Lebenszyklusberechnungen. In Hochbauprojekten kommt häufig die Schnittstelle zur Tragwerksplanung hinzu. Wichtig ist nicht die Vollständigkeit der Liste, sondern die Erkenntnis: Jede Zeile fordert ein anderes Modell.

---

3. Welche Information jeder Anwendungsfall verlangt

Anwendungsfälle unterscheiden sich nicht nur in ihrem Zweck, sondern auch in der Art der Information, die sie am Modell brauchen. Die folgende Übersicht verdichtet das Muster:

Eine reine Visualisierung kommt mit Geometrie und Oberflächendarstellung aus. Eine Kollisionsprüfung verlangt zusätzlich, dass jedes Volumen eine Klasse trägt — eine Wand muss als Wand erkannt werden, eine Lüftungsleitung als Lüftungsleitung. Eine Mengenermittlung verlangt darüber hinaus konsistente Bauteiltypen und Materialinformationen.

Sobald Anwendungsfälle wie Bauablauf, Kosten oder Betrieb hinzukommen, wächst die Liste verlangter Informationen schnell. Termine erfordern eine Verknüpfung zwischen Bauteilen und Vorgängen. Kosten erfordern eine Klassifikation nach Kostenelementen und konsistente Mengen. Betrieb erfordert Asset-Daten, die in der Planungsphase oft noch nicht entstehen — sie müssen explizit als Lieferanforderung definiert werden.

Die Faustregel: Je weiter ein Anwendungsfall in die Lebenszyklusphasen reicht, desto mehr Information am Modell wird verlangt — und desto teurer ist die Nachrüstung, wenn die Anforderung erst spät auftaucht.

---

4. Wie man Anwendungsfälle priorisiert

Nicht jedes Projekt braucht jeden Anwendungsfall. Eine Wettbewerbspräsentation lebt von Visualisierung und Variantenstudium. Ein Bauvorhaben mit komplexer Haustechnik gewinnt am meisten an Koordination und Kollisionsprüfung. Ein öffentliches Bauwerk mit langem Lebenszyklus rechtfertigt den Aufwand für Betriebsdaten. Eine Sanierung profitiert besonders von präziser Bestandsdokumentation.

Eine pragmatische Priorisierung folgt drei Fragen:

Welche Anwendungsfälle bringen für dieses Projekt den grössten Mehrwert? Hier zählt die fachliche Einschätzung der Beteiligten — wer ein Spital plant, weiss, dass Brandschutz-Nachweise und Haustechnik-Koordination dominieren werden.

Welche Anwendungsfälle sind vertraglich oder regulatorisch ohnehin verlangt? In öffentlichen Projekten in der DACH-Region kommt zunehmend die Forderung nach modellbasierter Lieferung für Betrieb und Asset Management — wer das übersieht, liefert nach.

Welche Anwendungsfälle lassen sich mit vertretbarem Aufwand ergänzen, weil die Information ohnehin entsteht? Eine Mengenermittlung ist beispielsweise oft fast „nebenbei" abgedeckt, sobald sauber klassifiziert wird.

Zwei bis fünf priorisierte Anwendungsfälle sind in der Regel ausreichend. Mehr führt zu Modellen, die im Detail überall ein wenig liefern, aber an entscheidenden Stellen die Tiefe vermissen lassen.

---

5. Beispiel: Ein Schulbau

Ein Schulbau mit 6.000 m² Bruttogeschossfläche wird in Planung gegeben. Das Team einigt sich zu Projektstart auf drei Anwendungsfälle:

Koordination und Kollisionsprüfung zwischen Architektur, Tragwerk und Haustechnik, weil die Aula und der Lehrküchenbereich räumlich anspruchsvoll sind.

Mengenermittlung für die Submission, weil der Auftraggeber konkurrierende Angebote auf Basis vergleichbarer Mengen wünscht.

Bestandsdokumentation für den Betrieb der haustechnischen Anlagen, weil die Schulträgerschaft das Gebäude über mindestens 40 Jahre betreiben wird.

Aus diesen drei Anwendungsfällen lassen sich die Informationsanforderungen ableiten: Bauteilklasse, Disziplin und räumliche Lage für die Koordination; konsistente Klassifikation und Material für die Mengen; Asset-IDs, Hersteller und Wartungsdaten für die Haustechnikbauteile zur Übergabe an den Betrieb. Was nicht zu diesen drei Anwendungsfällen beiträgt, wird nicht systematisch modelliert.

Das Modell wird dadurch nicht ärmer — es wird gezielter. Genau darin liegt der Unterschied zwischen einem überfrachteten und einem nutzbaren Modell.

---

6. Typische Fehler

In Projekten, in denen Anwendungsfälle nicht oder falsch behandelt werden, tauchen wiederkehrend diese Muster auf:

1. Anwendungsfälle erst am Modell entdecken. „Können wir nicht auch noch Kosten daraus ziehen?" — eine Woche vor Lieferung gestellt, ist diese Frage ein Vertragsänderungsantrag.
2. Alle Anwendungsfälle anstreben. Wer Visualisierung, Koordination, Mengen, Termine, Kosten und Betrieb parallel will, bekommt jeden Anwendungsfall zur Hälfte. Die ehrliche Priorisierung ist die kostengünstigere Antwort.
3. Anwendungsfälle ohne Phase festlegen. „Mengenermittlung" ohne Angabe des Zeitpunkts kann alles heissen — von der Submission bis zur Schlussabrechnung. Phase und Zeitpunkt sind Teil des Anwendungsfalls.
4. Anwendungsfälle aus Standardlisten kopieren. Branchenüblich heisst nicht projekttauglich. Eine Liste aus einem fremden Projekt einfach zu übernehmen, führt zu Anwendungsfällen, die niemand wirklich braucht.
5. Modellieren ohne Bezug auf Anwendungsfälle. Wer detailliert, aber ohne Zweck modelliert, produziert nicht Qualität, sondern Dateivolumen.
6. Betrieb erst beim Übergang in Betracht ziehen. Asset-Daten, die in der Planung nicht angefordert wurden, fehlen im As-built. Sie nachträglich zu erheben, ist um ein Vielfaches teurer.

---

7. Mini-Checkliste

Bevor in einem Projekt mit BIM begonnen wird, prüfe für jeden geplanten Anwendungsfall:

• Ist der Zweck so formuliert, dass die Erreichung am Ende objektiv beurteilt werden kann?
• Ist die Phase oder der Zeitpunkt benannt, in dem der Anwendungsfall stattfindet?
• Sind die Informationen am Modell, die dieser Anwendungsfall braucht, in einer Anforderung erfasst?
• Steht fest, wer die Informationen liefert und wer sie prüft?
• Ist die Liste der Anwendungsfälle priorisiert und auf eine handhabbare Anzahl beschränkt?
• Sind Anwendungsfälle für den Betrieb bewusst entschieden — entweder dabei oder bewusst weggelassen?

Sind drei oder mehr Punkte mit „Nein" beantwortet, ist die Grundlage für das BIM-Projekt noch nicht tragfähig. Die Klärung kostet vor Projektstart einige Stunden, später eher Wochen.

---

8. Reflexionsfrage

Denke an ein Projekt, in dem du gerade modellierst oder modelliert hast. Wenn du die Frage „Wofür wird dieses Modell konkret verwendet?" stellst — wieviele klar formulierte Antworten gibt es? Wieviele davon haben eine zugehörige Informationsanforderung, an der die Lieferung später prüfbar wäre?

Oft ist die Lücke zwischen impliziter Erwartung und expliziter Anforderung grösser als angenommen. Die Folgefrage lautet dann: Welche eine Klärung würde im nächsten Projekt den grössten Unterschied machen?

---

Merksätze

Anwendungsfälle sind die Antwort auf die Frage, wofür das Modell verwendet wird. Sie kommen vor allen anderen Entscheidungen.

Zwei bis fünf priorisierte Anwendungsfälle sind in der Regel ausreichend. Mehr führt zu Modellen, die überall ein wenig liefern, aber nirgends genug.

Je weiter ein Anwendungsfall in die Lebenszyklusphasen reicht, desto mehr Information am Modell wird verlangt — und desto teurer ist die Nachrüstung.

---

Quellen und weiterführende Literatur

• buildingSMART — Was ist openBIM: buildingsmart.org/openbim
• buildingSMART — Industry Foundation Classes (IFC): technical.buildingsmart.org/standards/ifc
• UK BIM Framework — ISO 19650 und Informationsmanagement: ukbimframework.org
• BIM Deutschland — BIM-Wissen und Begriffsklärung: bimdeutschland.de/bim-wissen