Augen Aufstudiostoks/stock.adobe.com
 | Software

Augen auf beim Softwarekauf

BIM braucht Software – aber welche?

Christian Fieberg

Ohne Software kein BIM. Doch mit der falschen Software läuft es auch nicht besser. Einmal installiert, begleitet sie die Projekte der nächsten Jahre. Wer dabei nur auf den Preis achtet, wird es möglicherweise bereuen, am falschen Ende gespart zu haben. Zeit für eine Handreichung zur Softwareauswahl – denn billig kauft man zweimal. 

BIM ist eine Methode, die ihr volles Potenzial nur mit der passenden Softwarearchitektur entfalten kann. Dabei benötigen die Beteiligten der einzelnen Gewerke ganz unterschiedliche Programme und Funktionalitäten. Die Festlegung auf das Produkt eines Herstellers sollte daher nicht leichtfertig getroffen werden. Typischerweise werden die Anwendungen jahrelang genutzt und benötigen zu Beginn intensive Schulung und Einarbeitung. Wer hier eine vermeintlich günstige Lösung beschafft, muss mit versteckten Folgekosten rechnen, die sich erst im Projektzusammenspiel ergeben.

In diesem Abschnitt wird zunächst eine allgemeingültige Herangehensweise vorgestellt. Abschließend wird der Beispielprozess für die Architektur beschreiben.

Unabhängig von fachspezifischen Vorgaben sollten alle Programme die kooperative Arbeitsweise unterstützen. Voraussetzung dafür sind 3D-Objekte, die sich mit alphanumerischen Daten verknüpfen lassen. Hierzu gehört der Import und Export der Objekte (Objektdaten). Dabei ist Open-BIM wesentlich, auch wenn zunächst bei der Einführung vielleicht nur von Closed-BIM ausgegangen wird. Eine Übersicht der zertifizierten Programme mit Im- und Export von IFC-Modellen findet sich auf der Website von buildingSMART International

Die Objekte müssen sich in eine hierarchische Struktur einbetten lassen, die eine Zuordnung zu Anlagen, Räumen oder Liegenschaften ermöglichen. Zwischen einzelnen Objekten sollten zusätzlich logische Abhängigkeiten definiert werden können. Wie oben erwähnt heißt das zum Beispiel, dass Lichtschalter mit den Türen verknüpft werden können oder Säulen mit dem Raum, in dem sie sich befinden.

Mit Blick auf konstruktive und planerische Programme sollten sich Schnitte und Ansichten einfach ableiten lassen. Idealerweise ergibt sich die Ableitung über entsprechende Vorlagen (templates), die bei Änderungen des Architekturmodells nicht mehr händisch nachbearbeitet werden müssen. Eingefügte Daten und Objekte sollten als Listen (Massenauszüge) darstellbar sein. Damit können sehr einfach gewerkeübergreifende Informationen ausgetauscht werden, die nicht immer die Position im Modell benötigen. Das trifft insbesondere auf die Ausschreibung und Beschaffung zu.

Für die Auswahl sollten sich die Verantwortlichen (und/oder zukünftigen Nutzer) folgende vier Leitfragen stellen und im Vorfeld beantworten:

  • Für welche Anwendungen und Arbeitsprozesse wird die Software benötigt?
  • Wer soll die Software nutzen?
  • Welche IT-Infrastruktur (Soft- und Hardware) ist bereits vorhanden?
  • Welcher Mehrwert wird durch die Nutzung erwartet?

Die ersten beiden Fragen richten sich an die Personen, die letztlich intensiv mit den Programmen arbeiten müssen. Die weiteren Fragen sollen berücksichtigen, dass die vorhandene (bzw. geplante) Infrastruktur und Geschäftsprozesse mit den Werkzeugen harmonieren müssen. Es ist deutlich einfacher, die Software zu wechseln, als etablierte Unternehmensprozesse neu zu denken, nur weil das der Software-Hersteller für seine Kunden so festgelegt hat.

Die untenstehende Tabelle zeigt einen sinnvollen Ablauf bei der Entscheidungsfindung.

Der Anforderungskatalog legt die grundlegenden Wünsche und Vorstellungen fest. Zusätzlich wird festgelegt, für wen das Programm eingesetzt wird. Die Bewertungsmatrix soll im zweiten Schritt helfen, sich über die Prioritäten klar zu werden. Nicht jeder geäußerte Wunsch ist gleich wichtig, und oft bekommt die Finanzierung (leider) einen hohen Stellenwert und Vorrang vor technischen Funktionalitäten.

Wie detailliert und feingliedrig die Bewertung erfolgt, hängt vom Investitionsvolumen und der Komplexität ab. Letztlich sollte ein Punktesystem dazu führen, dass in Frage kommende Produkte schnell und nach identischen Kriterien bewertet werden können.

Mit der eigenen Vision im Kopf kann nun eine Anbieterübersicht erfolgen. Die Top-Kandidaten sollten zu einer Demonstration und Softwarevorstellung eingeladen werden. Hierbei sollte das Publikum aus Nutzern und Entscheidern bestehen. Da die Hersteller dies regelmäßig und gern tun, haben sie dafür speziell vorbereitete Modelle. Es kann nicht schaden, wenn man im Vorfeld darum bittet, dass auch (soweit vorhanden und freigegeben) eigene Modelle mit dem Programm analysiert werden.

Da die begrenzte Zeit und der Zuschauerstatus nur eine eingeschränkte Erfahrung darstellen, sollte sich eine Testnutzung anschließen. Typischerweise sind dies 30-tägige Testlizenzen. Hierbei ist es wichtig, dass die angehenden Nutzer sich die Zeit nehmen bzw. bekommen, um die Software in Ruhe zu prüfen. Es kommt in der Praxis sehr häufig vor, dass im Projektalltag die Zeit für die Erprobung fehlt und dann auf dem letzten Drücker einmal über die Programme geguckt wird. Das kann zu einer teuren Fehlentscheidung führen. Typischerweise erfolgt die Einarbeitung über Online-Tutorials und ohne intensive Schulung.

Am Ende der Erprobung steht die Entscheidung. Hier lohnt ein Blick auf die ursprüngliche Bewertungsmatrix. Vielleicht haben sich im Prozess Verschiebungen der Schwerpunkte ergeben, oder es sind neue Anforderungen entdeckt worden, die zu Beginn noch nicht klar waren. Neben der selbstgewonnenen Expertise hilft der Blick auf unabhängige Experten. Beispielsweise können über Netzwerke und buildingSMART weitere Bewertungen einbezogen werden.

Mit der Freigabe durch die Geschäftsleitung können dann die Schulung und das roll out starten. Hier entscheidet sich, wer und in welchem Umfang geschult wird. Gibt es sogenannte key user und Multiplikatoren im Unternehmen, oder sollen alle Nutzer zur Schulung gehen? Findet diese inhouse oder extern statt?

Nach der Einführung werden sich in den ersten Projekten viele Fragen ergeben, für die ein guter und schnell reagierender Support hilfreich sind.

Diese allgemeinen Betrachtungen werden nun am Beispiel einer Architektursoftware konkreter analysiert.

Beispielprozess für die Architektur:

(A) Anforderungskatalog

  • Haupt-Leistungsfelder: Planung & Modellerstellung, Bauleitung
  • Open BIM (unterschiedliche Projektbeteiligte)
  • Erstellung des Koordinationsmodells, Landschaftsplanung
  • Fortschreibung der Planung
  • Bidirektionales Arbeiten
  • Integration von eigenen Daten (modifizierte Herstellerdatenbank)
  • Schnittstellen zu Ausschreibungssoftware
  • Support in Deutschland, inhouse-Schulung
  • Begleitung Pilotprojekt
  • Modelchecker zur Qualitätsprüfung und Massenauszügen
  • Preisstaffelung, Lizenzmodelle
  • Kollisionsprüfung
  • Modellbasierte Terminplanung
  • Kostenkontrolle
  • Bauablaufsimulation

(B) Bewertungsmatrix

  • Grobgewichtung der Anforderungspunkte (essenziell – nice to have)
  • Feingewichtung mit Punktesystem für jede Kategorie

(C) Anbieterübersicht

  • Recherche nach Anbietern
  • Neutrale Bewertungen (z. B. buildingSMART)
  • Besuch von BIM-Messen und -Veranstaltungen (Kontaktanbahnung)
  • Was nutzt der Wettbewerb?

(D) Software-Vorstellung

  • Fragenkatalog an Lieferanten (ggf. vorab zusenden)
  • Inhouse-Vorstellung der Programme für ausgewählte Mitarbeiter/zukünftige Nutzer
  • Diskussion und Vergleich
  • Ranking erstellen

(E) Testnutzung

  • Erprobung mit 30/90 Tagen Testlizenz inklusive Supportfreischaltung
  • Feste Zeiten für Probenutzung vorsehen (Mitarbeiter-Workload anpassen)
  • Kleines (abgeschlossenes) Projekt nachmodellieren
  • Mitarbeiterfeedback einholen

(F) Entscheidung

  • Bewertungsmatrix, Mitarbeiterfeedback
  • Kosten/Nutzen-Rechnung (Invest und Folgekosten)
  • Budget IT (Software und Hardware) und Schulungsbedarf

(G) Schulung

  • Inhouse-Schulung, mehrtägig
  • Projektbegleitender Support
  • Konzept zu internen Weiterbildung (Einführung als Prozess, nicht als Projekt)
 

BIM-Datenmanagement in Theorie und Praxis

Dieser Artikel ist ein Auszug aus dem Buch „BIM-Datenmanagement in Theorie und Praxis“ von Prof. Christian Fieberg. Das Buch erscheint im 3. Quartal 2022 im bSD Verlag. Jetzt vorbestellen!

BIM-Datenmanagement

Autor/in

Christian Fieberg

Christian Fieberg

Westfälische Hochschule Gelsenkirchen

Prof. Christian Fieberg studierte und promovierte an der RWTH Aachen im Bereich Maschinenbau/Wärmeübertragung. Seit 2015 beschäftigt er sich mit BIM (Anforderungen an Objektdaten, Workflow zwischen Hersteller, Planer und Installateur). 2017 wurde Christian Fieberg als Professor für Gebäudetechnik mit den Schwerpunkten Klimatechnik und BIM an die Westfälische Hochschule Gelsenkirchen berufen (Mastermodul Virtuelles Bauen mit BIM). Seit 2019 entwickelt und leitet er den VDI-Fachingenieur BIM-Lehrgang. Christian Fieberg forscht im Bereich Bidirektionale Verknüpfung von BIM und Virtual Reality. (w-hs.de)