Bauplanungssoftware

Modellierung und Zeichnung

Das Herzstück ist die Art, wie du Gebäude aufbaust. Achte darauf, wie schnell du eine typische Wand, eine Tür oder ein Fenster setzt und wie flexibel du diese Elemente später anpassen kannst. Ein Bauteilkatalog, der zu deinen üblichen Projekten passt, spart mehr Zeit als jede Zusatzfunktion, die du einmal im Jahr brauchst.

Plan- und Ableitungslogik

Aus dem Modell entstehen Grundrisse, Schnitte, Ansichten und Details. Prüfe, ob sich diese Ableitungen automatisch aktualisieren, wenn du im Modell etwas änderst. Bei manchen Programmen musst du Schnitte teilweise nachzeichnen, das kostet im Projektverlauf viel Zeit, weil sich Pläne ständig ändern.

Mengen und Auswertung

Wenn die Software Mengen aus dem Modell zieht (Flächen, Volumen, Bauteilanzahl), kannst du diese für Kostenschätzungen und Ausschreibungen nutzen. Hier lohnt es sich, in der Demo eine echte Auswertung zu machen und zu schauen, ob die Zahlen nachvollziehbar sind und sich exportieren lassen.

Zusammenarbeit und Datenaustausch

Sobald mehrere Personen oder mehrere Büros an einem Projekt arbeiten, wird der Austausch zum Knackpunkt. Achte auf offene Formate für den Modellaustausch, damit du nicht an einen einzigen Hersteller gebunden bist. Frag konkret nach, wie mehrere Bearbeiter gleichzeitig an einem Projekt arbeiten und wie Konflikte aufgelöst werden.

Detailtiefe und Bibliotheken

Gerade bei Details entscheidet sich, ob eine Software im Alltag trägt. Prüfe, ob du eigene Bauteile, Vorlagen und Detailzeichnungen anlegen und wiederverwenden kannst. Ein gut gepflegter eigener Standard beschleunigt jedes Folgeprojekt.

Lass die Person testen, die damit arbeitet

Der wichtigste Punkt zuerst: Lass die Software in der Demo von der Person bedienen, die später täglich damit plant, nicht vom Chef und nicht vom Vertriebler. Ein Vertriebler klickt jede Software flüssig durch, weil er die Demo hundertmal gemacht hat. Entscheidend ist, ob deine Zeichnerin nach zwei Stunden eine typische Aufgabe allein schafft.

Nimm ein echtes Projekt in die Demo

Statt das vorbereitete Musterprojekt anzuschauen, bring einen eigenen, realen Grundriss mit. So siehst du, wo es hakt, wenn die Geometrie nicht so glatt ist wie im Werbevideo. Achte darauf, wie das Programm mit schrägen Wänden, Bestandsgebäuden und unsauberen Ausgangsdaten umgeht.

Prüfe die Import- und Exportwege

Überlege, mit wem du Daten austauschst: Statiker, Haustechnik, Vermesser, Behörden. Teste in der Demo genau diese Wege mit einer echten Datei. Ein Format, das laut Broschüre unterstützt wird, kann in der Praxis trotzdem Informationen verlieren.

Denk an Skalierung und Personalwechsel

Eine Software, mit der nur eine einzige Person umgehen kann, ist ein Risiko. Frag dich, wie schnell ein neuer Mitarbeiter eingearbeitet ist und wie gut Schulungsmaterial und Support verfügbar sind. Verbreitung am Markt hat den praktischen Vorteil, dass du leichter Leute findest, die das Programm schon kennen.

Achte auf die Update-Politik

Kläre, wie oft es Updates gibt, ob diese im Preis enthalten sind und ob alte Projektdateien nach einem Update noch problemlos laufen. Ein Wechsel des Dateiformats kann bedeuten, dass ältere Projekte nachbearbeitet werden müssen.

Die Lizenzkosten sind nur ein Teil der Wahrheit. Wer nur auf den Anschaffungspreis schaut, unterschätzt die echten Kosten oft deutlich. Ich nenne dir bewusst keine Zahlen, weil sie je nach Anbieter, Ausbaustufe und Vertragsmodell stark schwanken. Wichtiger ist, dass du alle Kostenblöcke kennst und in der Angebotsphase konkret danach fragst.

Kauflizenz oder Abonnement

Es gibt grob zwei Modelle: den einmaligen Kauf einer Lizenz und das laufende Abonnement (monatlich oder jährlich). Beim Kauf zahlst du vorab mehr, bist aber danach unabhängiger. Beim Abo verteilst du die Kosten, hast aber eine dauerhafte Verpflichtung, und die Software funktioniert oft nur, solange du zahlst. Rechne beide Varianten über einen realistischen Zeitraum von mehreren Jahren durch, nicht nur über das erste Jahr.

Diese Kostenblöcke werden gern vergessen

• Wartung und Updates, falls sie nicht im Grundpreis enthalten sind.
• Schulungen für neue und bestehende Mitarbeiter.
• Zusatzmodule, die du erst im Projektverlauf brauchst.
• Support, teils nach Stufen gestaffelt.
• Hardware, weil modellbasiertes Arbeiten leistungsfähige Rechner verlangt.
• Arbeitszeit für die Einführung, das ist oft der größte versteckte Posten.

Der teuerste Posten ist selten der Preisschild

Die Einführungsphase, in der die Produktivität sinkt, weil alle noch lernen, kostet real oft mehr als die Lizenz selbst. Plane diese Phase ein und rechne sie in deine Entscheidung mit ein, statt sie schönzureden.

Die Software wird nach dem Entwurf gekauft, nicht nach dem Alltag

Viele lassen sich von schönen Renderings und flüssigen Entwurfsdemos überzeugen und merken erst später, dass die tägliche Detail- und Ausführungsplanung mühsam ist. Der Entwurf ist ein kleiner Teil der Arbeitszeit, die Ausführungsplanung der große. Bewerte die Software nach dem, was du am häufigsten tust.

Niemand pflegt die Bibliotheken

Ein Betrieb kauft die Software, aber niemand baut die eigenen Bauteile, Vorlagen und Standards auf. Dann arbeitet jeder anders, und der Vorteil des modellbasierten Arbeitens verpufft. Lege von Anfang an fest, wer für Vorlagen und Standards zuständig ist.

Der Datenaustausch wird erst im Projekt getestet

Ein Klassiker: Das Modell geht zum Statiker, kommt zerschossen zurück, und plötzlich sitzen zwei Büros in einer Krisenschleife. Teste den Austausch mit deinen realen Partnern, bevor du dich festlegst, nicht mitten im laufenden Projekt.

Zu viele Module auf einmal

Manche kaufen den vollen Ausbau mit allen Zusatzmodulen und nutzen die Hälfte nie. Fang mit dem an, was du wirklich brauchst, und erweitere, wenn ein echter Bedarf da ist. Ungenutzte Module kosten trotzdem Geld und verwirren neue Mitarbeiter.

Insellösung bei einer einzigen Person

Wenn nur ein Mitarbeiter die Software beherrscht und dieser das Büro verlässt, steht das Wissen still. Sorge dafür, dass mindestens zwei Personen die zentralen Abläufe kennen, und dokumentiere eure Standards schriftlich.

Bauplanung ist in Deutschland, Österreich und der Schweiz stark reguliert, und die Software muss zu diesem Rahmen passen. Ich gebe dir hier die Richtung, kläre die konkreten Vorgaben aber immer mit deiner Kammer und den zuständigen Behörden, weil sie sich je nach Land, Bundesland und Kanton unterscheiden.

Bauordnungen und Normen

Bauen ist Ländersache. In Deutschland gelten die jeweiligen Landesbauordnungen, in Österreich und der Schweiz eigene Regelwerke. Die Software muss dir erlauben, Pläne so aufzubereiten, dass sie den Anforderungen der zuständigen Behörde entsprechen, etwa bei Maßstäben, Beschriftung und Planinhalten. Prüfe, ob sich Planvorlagen an die bei dir üblichen Vorgaben anpassen lassen.

BIM-Anforderungen bei öffentlichen Projekten

Bei öffentlichen Auftraggebern wird modellbasiertes Arbeiten zunehmend gefordert, teils mit konkreten Vorgaben zu Formaten und Datenstrukturen. Wenn du solche Projekte anstrebst, achte darauf, dass die Software offene Austauschformate sauber unterstützt.

Datenschutz

Sobald du personenbezogene Daten verarbeitest, etwa von Bauherren, gilt die Datenschutz-Grundverordnung. Bei Cloud-Lösungen ist wichtig, wo die Daten gespeichert werden und ob der Anbieter einen Vertrag zur Auftragsverarbeitung bereitstellt. Kläre das vor der Einführung, nicht danach.

Archivierung und Nachweispflichten

Pläne und Projektunterlagen müssen über lange Zeiträume nachvollziehbar bleiben. Achte darauf, dass du deine Daten in einem Format sichern kannst, das du auch in vielen Jahren noch öffnest, unabhängig davon, ob du die Software dann noch im Einsatz hast. Diese Unabhängigkeit vom Anbieter ist ein oft unterschätzter Punkt.

Schritt 1: Prozesse aufschreiben

Bevor du eine einzige Demo buchst, schreib auf, wie ein typisches Projekt bei dir vom ersten Entwurf bis zur Ausführung läuft. Notiere, mit wem du Daten austauschst und wo es heute hakt. Diese Liste ist dein Prüfstein für jede Software.

Schritt 2: Anforderungen priorisieren

Trenne zwischen Muss und Kann. Ein Programm muss deine Kernaufgaben gut erledigen, alles andere ist nachrangig. Vermeide es, eine lange Wunschliste zu bauen, die am Ende jede Entscheidung blockiert.

Schritt 3: Zwei bis drei Kandidaten auswählen

Mehr als drei ernsthafte Kandidaten kannst du kaum sauber vergleichen. Wähle sie danach aus, wie gut sie zu deiner Betriebsgröße und deinem Arbeitsschwerpunkt passen.

Schritt 4: Echte Testphase mit echtem Projekt

Lass die späteren Nutzer ein reales Projekt in der Testversion bearbeiten, nicht das Musterbeispiel. Miss, wie lange typische Aufgaben dauern und wo es hängt. Teste dabei zwingend den Datenaustausch mit einem realen Partner.

Schritt 5: Gesamtkosten über mehrere Jahre rechnen

Stell alle Kostenblöcke gegenüber: Lizenz, Wartung, Schulung, Support, Hardware und Einführungszeit. Rechne über einen realistischen Zeitraum, nicht nur über das erste Jahr.

Schritt 6: Ausstiegsszenario prüfen

Frag dich, wie du im Zweifel wieder herauskommst. Kannst du deine Daten in einem offenen Format mitnehmen? Ein Anbieter, der dich nicht einsperrt, ist auf lange Sicht der sicherere.

Schritt 7: Standards festlegen und Verantwortliche benennen

Bevor der Regelbetrieb startet, lege eure Vorlagen, Bauteilbibliotheken und Namenskonventionen fest und benenne jemanden, der sie pflegt. So wird aus der neuen Software ein echter Vorteil und nicht nur ein teures Zeichenprogramm.