Architektur Programme

Modellierung und Zeichnen

Die Basis muss stimmen. Wie schnell setzt du eine Wand, wie einfach ziehst du eine Treppe, wie sauber verbinden sich Bauteile an den Ecken. Das entscheidet sich nicht in der Featureliste, sondern wenn jemand acht Stunden am Tag damit arbeitet. Achte auf die Bibliotheken für Bauteile und Objekte: Türen, Fenster, Sanitär. Wenn du jedes Standardelement selbst bauen musst, verlierst du Zeit.

Planableitung und Bemaßung

Aus dem Modell müssen Pläne fallen, die dem Standard deines Büros entsprechen. Prüfe, wie flexibel die Bemaßung ist, ob du Planköpfe und Schriftfelder an deine Vorlagen anpassen kannst und wie die Software mit Detailmaßstäben umgeht. Ein Programm, das schöne 3D-Bilder macht, aber bei der 2D-Werkplanung schwächelt, ist im Alltag ein Problem.

Mengen und Auswertung

Wenn das Modell Bauteile kennt, kann es sie zählen. Flächen nach Wohnflächenverordnung, Bauteilmengen, Raumbücher. Achte darauf, wie die Auswertung mit deinen Anforderungen zusammenpasst und ob du die Listen in Formate exportieren kannst, die dein Ausschreibungsprogramm oder die Kostenberechnung versteht.

Zusammenarbeit und Schnittstellen

Kein Büro arbeitet allein. Tragwerksplaner, Haustechniker, Bauphysiker: alle wollen an das Modell. Hier ist das IFC-Format der zentrale Punkt, es ist der offene Standard für den Austausch von BIM-Modellen. Frag konkret, wie sauber der IFC-Export und -Import läuft, denn zwischen Anspruch und Realität liegen hier oft Welten. Prüfe auch, wie mehrere Personen gleichzeitig am selben Projekt arbeiten können.

Visualisierung

Renderings und Schnittperspektiven verkaufen Projekte an Bauherren. Manche Programme haben das eingebaut, andere setzen auf Export in spezialisierte Software. Kläre, was du wirklich brauchst: Für die meisten reicht eine solide interne Darstellung, fotorealistische Renderings sind oft ein separater Arbeitsschritt.

Der erste Filter ist deine Bürogröße und dein Projekttyp. Ein Einzelkämpfer, der Einfamilienhäuser plant, hat andere Anforderungen als ein Büro mit fünfzehn Leuten, das Gewerbebauten macht. Schreib auf, was deine typischen drei Projekte sind, und prüfe die Software gegen diese Realität, nicht gegen einen abstrakten Idealfall.

Der zweite Punkt ist das Ökosystem, in dem du dich bewegst. Mit welchen Fachplanern arbeitest du regelmäßig zusammen, welche Formate erwarten deine Auftraggeber. Wenn deine Statiker alle ein bestimmtes Format verlangen, muss deine Software das sauber bedienen. Frag deine Partner, bevor du entscheidest.

Der dritte Punkt ist der Umstieg. Wenn du bereits Projekte in einem alten System hast, kläre, ob und wie du die Altdaten übernehmen kannst. Oft ist die ehrliche Antwort: Bestandsprojekte laufen im alten System aus, neue starten im neuen. Das kostet dich eine Übergangszeit mit zwei Systemen, und das solltest du einplanen.

Der wichtigste Rat zur Demo: Lass die Software in der Demo von der Person bedienen, die später täglich damit arbeitet, nicht vom Chef und nicht vom Vertriebler. Gib ihr eine konkrete Aufgabe aus einem echten Projekt: einen Grundriss zeichnen, eine Änderung durchziehen, einen Plan ableiten. Wenn das nach zwei Stunden noch hakt, wird es im Alltag nicht besser.

Die Lizenzkosten sind bei Architektur Programmen fast nie der größte Posten. Trotzdem fangen wir dort an. Verbreitet sind zwei Modelle: der einmalige Kauf einer Lizenz mit optionalem Wartungsvertrag und das Abonnement, bei dem du monatlich oder jährlich zahlst. Beim Kauf zahlst du vorne viel, beim Abo verteilt sich die Last, addiert sich über die Jahre aber auf. Rechne beide Modelle über einen Zeitraum von fünf Jahren durch, dann wird der Vergleich ehrlich.

Was gern übersehen wird:

• Schulung und Einarbeitung. Ein BIM-Programm lernt niemand nebenbei. Rechne mit Kurszeiten und, noch teurer, mit der reduzierten Produktivität in den ersten Monaten. Diese Anlaufkosten sind oft höher als die Lizenz.
• Hardware. Modellierung und Rendering brauchen Rechenleistung. Wenn dein alter Rechner das neue Programm nur zäh stemmt, gehört die neue Hardware zur Rechnung.
• Wartung und Updates. Beim Kaufmodell ist der Wartungsvertrag oft optional, aber ohne ihn bekommst du keine neuen Versionen. Kläre, was der Vertrag jährlich kostet.
• Zusatzmodule. Manche Funktionen wie erweiterte Ausschreibung oder spezielle Auswertungen kosten extra. Frag, was im Basispreis steckt und was nachgekauft werden muss.
• Support. Prüfe, ob Support inklusive ist oder pro Fall abgerechnet wird, und in welcher Sprache und Zeitzone du Hilfe bekommst.

Mein Rat: Die günstigste Lizenz nützt dir nichts, wenn dein Team drei Monate braucht, um produktiv zu werden. Rechne die Zeit deiner Leute mit in die Gesamtkosten ein, das ist der Posten, der wirklich weh tut.

Die Software nach den Wünschen statt nach den Projekten aussuchen

Ein Büro kauft das Programm mit den meisten Funktionen, weil man ja vielleicht irgendwann mal Großprojekte macht. Zwei Jahre später nutzt niemand die Hälfte, und die Leute stolpern über die Komplexität. Kauf für das, was du tust, nicht für das, was du dir erträumst.

Keine Standards und Vorlagen aufbauen

Wer ohne Bürostandard startet, hat nach einem Jahr fünf verschiedene Planköpfe, drei Ebenenstrukturen und keine Konsistenz. Bevor das erste Projekt läuft, gehören Vorlagen, Ebenenstruktur und Bauteilbibliotheken definiert. Das ist mühsam und wird gern verschoben, rächt sich aber sicher.

IFC-Austausch nicht vorher testen

Ein Büro plant sauber, exportiert das Modell für den Statiker, und der bekommt einen Datensalat, weil die Bauteile falsch klassifiziert waren. Teste den Austausch mit deinen echten Partnern an einem echten Modell, bevor du dich auf einen Ablauf verlässt.

Nur eine Person schulen

Der eine Kollege, der alles kann, geht in Urlaub oder wechselt den Job, und plötzlich steht das Büro. Verteile Wissen von Anfang an auf mehrere Schultern und dokumentiere die Bürostandards schriftlich.

Updates ungeprüft in laufende Projekte ziehen

Ein neues Update mitten im Projekt kann Dateien so verändern, dass ältere Versionen sie nicht mehr sauber öffnen. Aktualisiere zwischen Projekten oder halte laufende Projekte bewusst auf einer Version, bis sie abgeschlossen sind.

Beim Thema Recht geht es bei Architektur Programmen um mehrere Ebenen. Erstens die fachlichen Normen: Deine Pläne und Berechnungen müssen den geltenden Bauvorschriften und Normen entsprechen. Die Software unterstützt dich dabei, verantwortlich bleibst aber du. Prüfe, ob das Programm die für deinen Markt relevanten Normen und Vorlagen mitbringt, etwa für Flächenberechnungen, und ob diese aktuell gehalten werden.

Zweitens der Datenschutz. Sobald du personenbezogene Daten verarbeitest, etwa Kontaktdaten von Bauherren im Projektmanagement der Software, gilt die DSGVO. Bei cloudbasierten Lösungen brauchst du einen Vertrag zur Auftragsverarbeitung mit dem Anbieter. Kläre, wo die Server stehen, denn der Serverstandort innerhalb der EU vereinfacht vieles. In der Schweiz gilt zusätzlich das dortige Datenschutzgesetz, das der DSGVO ähnlich, aber nicht identisch ist.

Drittens Archivierung und Nachweispflichten. Bauunterlagen musst du über lange Zeiträume aufbewahren, und die Fristen unterscheiden sich je nach Land und Art der Unterlage. Achte darauf, dass du deine Projektdaten auch in Jahren noch öffnen kannst. Das ist ein Argument für offene Formate und gegen eine reine Abhängigkeit von einem proprietären Dateiformat, das du nur öffnen kannst, solange du die Lizenz zahlst.

Viertens die Lizenzbedingungen selbst. Prüfe, ob eine Lizenz an einen Rechner oder an eine Person gebunden ist und wie es mit Heimarbeit aussieht. Bei Abomodellen ist die Frage entscheidend, was mit deinen Daten passiert, wenn du das Abo kündigst. Kannst du sie exportieren, in welchem Format, und wie lange hast du Zugriff.

Ein Hinweis zur Ehrlichkeit: Ich bin kein Anwalt, und die konkrete rechtliche Lage hängt von deinem Standort und deinen Projekten ab. Bei größeren Entscheidungen, etwa zum Datenschutz in der Cloud, hol dir eine fachkundige Einschätzung.

Schritt 1: Anforderungen aufschreiben

Nimm dir deine letzten drei bis fünf Projekte und schreib auf, was du dabei gebraucht hast. Welche Planarten, welche Auswertungen, welche Fachplaner, welche Formate. Daraus wird deine Anforderungsliste. Trenne dabei sauber zwischen Pflicht und Wunsch.

Schritt 2: Das Team einbeziehen

Die Leute, die täglich zeichnen, wissen am besten, wo es hakt. Frag sie, was am aktuellen Werkzeug nervt und was sie sich wünschen. Wer das Team übergeht, kauft am Bedarf vorbei und bekommt später Widerstand.

Schritt 3: Auf zwei bis drei Kandidaten eingrenzen

Mit deiner Anforderungsliste filterst du das Feld. Mehr als drei ernsthafte Kandidaten machen den Vergleich unübersichtlich. Die Kategorieübersicht oben auf dieser Seite hilft dir bei der Vorauswahl.

Schritt 4: Echte Tests mit echten Aufgaben

Hol dir Testversionen und lass dein Team an einem echten Projektausschnitt arbeiten. Definiere vorher Aufgaben: einen Grundriss modellieren, eine Änderung durchziehen, einen Plan ableiten, ein IFC an einen Partner geben. Notiert, wo es hakt.

Schritt 5: Referenzen und Austausch prüfen

Sprich mit Büros, die die Software einsetzen, am besten in ähnlicher Größe. Frag nach dem, was im Verkaufsgespräch nicht vorkommt: Wie war die Einarbeitung, wie läuft der Support, wo sind die Grenzen.

Schritt 6: Gesamtkosten über fünf Jahre rechnen

Stell Lizenz, Wartung, Schulung, Hardware und Zusatzmodule für beide Modelle über fünf Jahre gegenüber. Erst diese Zahl ist ehrlich vergleichbar.

Schritt 7: Einführung planen

Entscheide dich, plane die Schulung, definiere die Bürostandards und lege fest, wie Altprojekte behandelt werden. Ein sauberer Start spart dir Monate Chaos. Setz einen Termin, an dem ihr prüft, ob die Entscheidung sich bewährt hat.