1 Das Projektfenster (links) ist die »Schalt- zentrale« von California 3000
2 Der Import der Daten aus ArchiCAD erfolgt im Modul »RGB« (Raum- und Gebäudebuch)
3 Im Fenster »Bauteilvarianten« können (nicht nur) die aus ArchiCAD übernommenen Elementtypen mit LV-Positionen verknüpft werden. Auf Basis der hier festgelegten Zuordnungen erzeugt California Leistungsverzeichnisse bei Bedarf »auf Knopfdruck«
California 3000 mit »direkter Datenanbindung« an ArchiCAD

Software unter der Lupe

California 3000 mit »direkter Datenanbindung« an ArchiCAD

Noch immer steht ein großer Teil der Architekten dem Thema »Datenaustausch zwischen CAD und AVA« wenn nicht ablehnend, so doch kritisch oder zumindest mit gemischten Gefühlen gegenüber. Und das nicht völlig zu unrecht. Denn eine in jeder Hinsicht und für jeden Anwender ideale Lösung zur Verzahnung von CAD- und Kostenplanung konnte bislang noch kein Softwarehaus präsentieren. Hinzu kommt, dass die Konzepte jenseits einer einfachen Übergabe von Massenlisten in der Mehrzahl ausschließlich »hausintern« funktionieren, sprich CAD und AVA vom selben Anbieter (beispielsweise Nemetschek, RIB oder Softtech) voraussetzen. Zu den wenigen Ausnahmen gehört mittlerweile die »direkte Datenanbindung« von Graphisofts ArchiCAD an die AVA-Kostenplanungsprogramme von G&W und BauerSoftware. Im Test wurde untersucht, wie gut dies an G&Ws California 3000 gelungen ist.
California 3000 Da es sich bei California um ein sehr umfangreiches Programm handelt, ist im Rahmen dieses Berichts weder eine vollständige Beschreibung noch ein umfassender, alle Funktionen beurteilender Test möglich. Zweifelsohne handelt es sich um eine praxistaugliche Software, was allein schon der Umstand belegt, dass das Programm hier zu Lande schon seit Jahren zu den verbreitetsten AVA- und Kostenplanungssystemen zählt.
California speichert seine Daten in einer Datenbank, wobei wahlweise Oracle oder Microsoft SQL-Server als so genannte Engine verwendet werden können. Im Fall, dass keine von beiden vorhanden ist, installiert das Setup zunächst eine »Light-Version« des Microsoft SQL-Servers (Größe der Datenbank auf zwei Gigabyte begrenzt). Kleine Tücke: Sollte dies nötig sein, wird die Installation von California unterbrochen und muss dann nochmals gestartet werden.
Dem Neuling bietet das Menü der Installations-CD einen »Leitfaden für den Einstieg«. Aufgrund des Standes dieses PDF-Dokuments vom Juli 2003 kam hier zunächst der Verdacht auf, dass sein Inhalt womöglich nicht mehr ganz mit der aktuellen Programmversion und deren Oberfläche übereinstimmt. Dieser war jedoch unbegründet – die Beispiele waren in dieser Hinsicht problemlos nachvollziehbar. Allerdings ist der Leitfaden nicht als durchgängige Anleitung konzipiert, sondern behandelt verschiedene Aspekte unabhängig voneinander. Dies ist grundsätzlich kein Problem, da aber manche Arbeitsschritte nur bis einem bestimmten Projektstadium ausgeführt werden können, muss man zum kontinuierlichen Durcharbeiten des Leitfadens gelegentlich ein neues Projekt beginnen. Leider fehlen in der Anleitung deutliche Hinweise darauf. Eine kleine Schwäche stellen auch die enthaltenen Abbildungen der Programmoberfläche dar. Diese sind zwar nur wenig verkleinert, dadurch aber etwas verschwommen. Das spielt zum Verständnis meist keine Rolle, hin und wieder wünscht man sich trotzdem, die Schrift in den Bildern wäre noch lesbar. Dass man sich beim Durchlesen des Leitfadens des Öfteren an den Kopf fassen muss, ist übrigens nicht durch diese kleinen inhaltlichen Mängel bedingt. Vielmehr dadurch, dass an verschiedenen Stellen bestimmte Features des Programms mit »Einfach toll!«, »Einfach praktisch!« oder »Genial!« gelobt wurden – kann California auch im Teleshopping erworben werden?
California ist eine so genannte MDI-Anwendung, innerhalb des Hauptfensters können also beliebig viele Dokumentenfenster geöffnet sein. Wichtigstes davon ist das Projektfenster mit einer Baumstrukturdarstellung der gesamten Datenbank. Oberste Hierarchieebene sind die Projekt- und Stammtext-Gruppen, darunter verzweigt sich der Baum (gegebenenfalls über Untergruppen) über einzelne Projekte und Projektbereiche bis zu den Dokumenten. Im Test erwies sich die Oberfläche von California über weite Strecken als sehr zweckmäßig und (sofern dies bei einem Programm mit einem so großen Funktionsumfang möglich ist) auch als recht »intuitiv«. Den positiven Eindruck störten lediglich drei Eigenheiten. Die unangenehmste zuerst: Sobald mehr als zwei oder drei Unterfenster geöffnet sind, zum Beispiel weil mit drag&drop Positionen aus verschiedenen Stamm-LVs übernommen werden sollen, leidet die Übersicht durch Überlappungen. Zwar gibt es die Windows-üblichen Möglichkeiten, alle geöffneten Fenster nebeneinander oder untereinander anordnen zu lassen. Die Aufteilung des Bildschirms erfolgt dabei jedoch (ebenfalls Windows- üblich) nach rein geometrischen und nicht nach inhaltlichen Aspekten. So nimmt beispielsweise das Projektfenster in einer solchen automatischen Anordnung unnötig viel Platz weg, weil für die Darstellung seiner Baumstruktur ein querformatiges Fenster völlig ungeeignet ist. Zweckmäßiger wäre es, wenn zumindest das Projektfenster unabhängig von der gewählten Anordnung am linken Bildschirmrand fixiert werden könnte. Eine weitere, lästige oder zumindest gewöhnungsbedürftige Eigenheit von California ist das »Doppelklick-Verhalten«: Erst wenn das entsprechende Feld zuvor mit einem einfachen Mausklick aktiviert wird, kann das gewünschte zusätzliche Fenster hierzu oder der Dialog per Doppelklick geöffnet werden.
Für den California-Neuling ebenfalls ungewohnt ist die Bedeutung von grau hinterlegten Zellen in Tabellen. Hier vermutet man eigentlich, dass sich deren Inhalt nicht bearbeiten lässt. In California bedeutet der graue Hintergrund lediglich, dass keine direkten Eingaben möglich sind. Ist die Spaltenüberschrift eines grauen Feldes mit einem kleinen Dreieck gekennzeichnet, kann sein Inhalt doch geändert werden, indem per Doppelklick ein weiteres Fenster geöffnet und dort beispielsweise aus einer Liste ein neuer Wert ausgewählt wurde.
Konzept der »direkten Datenanbindung«
Prämisse des von G&W verwendeten Konzeptes zur Datenübernahme ist, dass der Ausschreibende über keine oder allenfalls rudimentäre Kenntnisse des CAD-Systems – in diesem Fall ArchiCAD – verfügen muss. Aus diesem Grund kann an dieser Stelle auf eine nähere Beschreibung der CAD-Software verzichtet werden. (Für Interessierte: Ein Test von ArchiCAD mit Schwerpunkt auf dem neuen Zusatztool »MaxonForm« folgt in der nächsten db). California greift zwar direkt auf die Zeichnungsdateien zu, deren grafische Darstellung bekommt der AVA-Nutzer jedoch nicht zu Gesicht. Genauer gesagt wird auch gar nicht mit der aktuell in Arbeit befindlichen CAD-Planung gearbeitet, sondern mit den im ArchiCAD Archivformat abgespeicherten Daten. Dies ist kein Nachteil, ist so doch sichergestellt, dass die Ausschreibung auf einem fixierten und damit auch nachvollziehbaren Planungsstand basiert.
Änderungen der CAD-Planung können jedoch jederzeit berücksichtigt werden, indem die entsprechende Archivdatei in ArchiCAD überschrieben und in California ein Abgleich der Massen ausgeführt wird. Dieses Verfahren hat zwei wesentliche Vorteile gegenüber einer »Live-Kopplung« zwischen CAD und AVA: Zum einen benötigt der für die Kostenplanung Zuständige kein CAD-System auf seinem PC. Damit California auf die in einem Datenbankformat abgelegten Zeichnungen zugreifen kann, muss lediglich ein spezieller ODBC-Treiber installiert sein, der von Graphisoft kostenlos erhältlich ist. Zum andern wirken sich Änderungen in der CAD-Planung nur dann auf Kostenplanung und Ausschreibung aus, wenn dies wirklich gewollt ist.
Praxis der »direkten Datenanbindung« Die Übernahme der CAD-Daten erfolgt in California in das so genannte Raum- und Gebäudebuch (RGB). Dieses wird dabei entsprechend der Struktur der CAD-Daten gegliedert. Und zwar in der Hierarchieabfolge Elementtyp (Raum, Wand, Decke usw.), Geschoss und Ebene (Layer). Innerhalb der untersten Hierarchiestufe sind die einzelnen Elemente dann nach spezifischen, vom CAD übernommenen Eigenschaften sortiert. Eine automatische Summenbildung der Mengen findet dabei nicht statt und wäre in den meisten Fällen auch gar nicht sinnvoll. Addiert werden lediglich die Kosten – was natürlich erst dann möglich ist, wenn die Elementmengen mit Leistungen verknüpft worden sind. Dies geschieht über die Definition von aus Einzelpositionen zusammen-gesetzten Bauteilen. Nun wäre es zwar möglich, aber doch sehr mühsam und fehlerträchtig, jedem einzelnen Element die jeweiligen Positionen separat zuzuordnen. Denn in aller Regel enthält ein Plan eine große Zahl von gleichartigen Einzelelementen. Die übliche Vorgehensweise ist deshalb eine andere: California ermittelt beim Einlesen der CAD-Daten automatisch zu jedem Element, zu welchem Typ es gehört. Dieser Typ ist über den Typ des CAD-Elements, dessen Ebene (Layer) und je nach Element durch bestimmte Abmessungen (beispielsweise Fenstergröße, Wandstärke oder Deckendicke) sowie die in ArchiCAD zugewiesene Schraffur und Oberfläche (Rendering-Material) definiert. Über die Funktion »Bearbeiten Bauteilvarianten« kann man sich sämtliche vorhandenen Typen in einer Tabelle anzeigen lassen und diesen die jeweiligen Leistungspositionen zuweisen. Sozusagen auf Knopfdruck erfolgt dann die Aktualisierung des Raum- und Gebäudebuchs, wobei alle Elemente entsprechend ihres Typs mit den für diesen festgelegten Leistungen und Preisen verknüpft werden. Beim Verlassen des Raum- und Gebäudebuchs generiert California aus den den Elementen zugeordneten Positionen auf Wunsch die entsprechenden Leistungsverzeichnisse.
Leider zeigte sich bei einigen Versuchen, dass das Verfahren noch nicht ganz fehlerfrei funktioniert. Beispiel: Es wurde ein einfaches CAD-Modell mit vier Außenwänden, einer Reihe von Innenwänden (eine mit 17,5 cm, alle anderen mit 11,5 cm Dicke) sowie ein paar Stützen erstellt und als Archivdatei (Dateiendung ».pla«) gespeichert. Der Import in California funktionierte problemlos; das Programm ermittelte drei verschiedene Wandtypen, denen anschließend unterschiedliche Leistungspositionen zugeordnet wurden. Nachfolgend eine Änderung der CAD-Planung: Eine der 11,5er Innenwände erhält eine andere Schraffur und wird im Plan zur Ziegelwand. Erneut wird der Plan archiviert und in California importiert. Im Raumbuch ist die Bezeichnung der Wand nun entsprechend geändert. Die angezeigten Kosten für die Wand blieben jedoch unverändert, obwohl es sich doch offensichtlich um einen neuen Typ handelte, für den noch gar keine Leistungen hinterlegt waren. Ein Blick ins Fenster »Bearbeiten der Bauteilvarianten« ließ erkennen, dass California beim Import einen neuen Wandtyp ermittelt hatte, der aber – wie die 17,5er Wand – mit Wandtyp 3 ermittelt wurde.
Allerdings differenziert California wohl nicht nur nach dieser Bezeichnung, sondern auch nach den mit dem Typ verbundenen Stichworten (in diesem Fall aus Ebene, Wandstärke, Schraffurmuster und Material zusammengesetzt), so dass die Zuordnung trotzdem eindeutig ist.
Aber auch nachdem der neue Wandtyp mit Leistungspositionen bestückt und das RGB aktualisiert worden war, behielt die geänderte Wand den alten Preis bei. Des Rätsels Lösung offenbarte sich erst beim Öffnen des Fensters »Bauteilparameter«. Dort war der Wand nach wie vor der ursprüngliche Wandtyp 2 zugeordnet!
Bei weiteren Versuchen, bei denen Ebenen von Wänden im CAD geändert wurden, reagierte California korrekt – abgesehen davon, dass auch hier Bezeichnungen für Wandtypen mehrfach auftraten. Probleme bereiteten hingegen Änderungen der Dicke einer Wand. Auch hier erkannte California beim Import den geänderten Elementtyp, tauschte diesen in den Bauteilparametern der Wand jedoch nicht aus, sondern fügte ihn hinzu – mit der Folge, dass diesem Wandelement nun zwei Bauteile zugeordnet waren, deren Kosten sich addierten. Bei den Stützen arbeitete das Programm noch schlampiger: Hier wurden unterschiedliche Schraffuren und Materialien bei der Typenbildung grundsätzlich ignoriert, selbst die in ArchiCAD festgelegte Form der Stützen (rund oder rechteckig) wurde nicht berücksichtigt.
Fenster und Türen tauchen übrigens im RGB nicht als eigenständige Elemente auf, sondern stets in Wandelemente integriert. Dies ist aber kein grundsätzlicher Nachteil, da bei den Türen und Fenstern ebenfalls mit Elementtypen gearbeitet werden kann. Allerdings unterscheidet California bei den Typen nicht nach der Wanddicke, in die sie eingebaut sind. So kann beispielsweise ein LV, in dem Türen mit Umfassungszarge nach Maulweiten differenziert sind, nur durch manuelle Nachbearbeitung erstellt werden.
Stärken und Schwächen Prinzipbedingt hat die »direkte Datenanbindung« von ArchiCAD und California einen grundsätz- lichen Nachteil – wie auch alle anderen, nicht-grafischen Verfahren der Massen- Leistungen-Zuordnung: Die Möglichkeiten zur Kontrolle sind sehr begrenzt, also auf eine allgemeine Plausibilitätsprüfung beschränkt. Allerdings sollten sich dadurch, dass grafische Attribute (Schraffuren) bei der Unterscheidung der AVA-Bauteile berücksichtigt werden, Unterschiede zwischen den Plänen und der Ausschreibung weitgehend vermeiden lassen. Zumindest dann, wenn unterschiedliche Ausführungen im Plan durch die entsprechende Grafik der Bauteile differenziert werden und nicht (nur) durch Texthinweise. Abgesehen von den in der Testversion von California noch enthaltenen Fehler (die hoffentlich bis zum Erscheinen dieses Artikels beseitigt sind), sind aber zweifellos noch eine Reihe von Verbesserungen möglich. Zwar ist von G&W zu hören, dass bestimm-te Beschränkungen durch die von ArchiCAD gelieferten Daten bedingt seinen, ob dies in jedem Fall zutrifft, konnte jedoch nicht beurteilt werden. Aber selbst wenn California auf sämtliche Daten des ArchiCAD-Gebäudemodells zugreifen kann, dürfte es für Graphisoft aufgrund des vorhandenen Know-hows leichter sein, diese für die Belange einer Ausschreibung gleich passend aufbereitet zu liefern. Unabhängig davon sollte man sich bei G&W darüber Gedanken machen, wie man die Bildung von Typen, denen dann AVA-Bauteile zugeordnet werden, flexibler und praxisgerechter gestalten könnte. Denn auch wenn es sicherlich kaum möglich ist, sämt-liche für eine Ausschreibung benötigten Mengen der CAD-Planung zu entnehmen: Der Anwender einer »intelligenten« CAD-AVA-Schnittstelle wird nicht einsehen, dass er trotzdem noch einige, im CAD-Plan offensichtlich vorhandene Informationen manuell auswerten muss. Im Moment krankt das Verfahren daran, dass man dem Nutzer nicht zu viele Elementtypen zumuten will, weil er diese einzeln mit Positionen zu versehen hat. Dafür bleiben aber auch einige durchaus sinnvolle Unterscheidungen auf der Strecke. Dieses Dilemma ließe sich durch eine Hierarchie bei der Zuordnung von Positionen (oder kompletten Bauteilen) zu den Elementtypen lösen: Gegebenenfalls sinnvolle, genaue Differenzierungen (wie die von Türzargen nach Wandstärke bei Umfassungszargen) könnten dann bei Bedarf genutzt werden – wenn dies nicht nötig ist (wie bei Türen mit Eckzarge), werden sämtliche Positionszuordnungen bereits in der darüberliegenden Hierarchieebene getroffen.
Fazit California ist zweifellos ein Kostenplanungs- und AVA-System mit einer sehr ausgereiften Funktionalität. Besonders hervorzuheben sind die bislang noch nicht erwähnten Möglichkeit zur komfortablen Auswertung nach unterschiedlichen Kostengliederungen, das Kostenträger-Splitting, die integrierte Textverarbeitung und das Dokumenten-Management. Bedienung und Oberfläche sind größtenteils gelungen, lassen aber noch ein paar Wünsche offen.
Hauptaugenmerk des Tests galt jedoch der »direkten Datenanbindung« an ArchiCAD: Diese Schnittstelle ist im Prinzip durchaus praxistauglich, wies in der getesteten Version aber noch Fehler auf, wenn Änderungen der CAD-Planung in California übernommen werden sollten. Auch sind die Möglichkeiten des Konzepts noch nicht wirklich ausgereizt, da eine Reihe, im Gebäudemodell eigentlich enthaltener Informationen nicht zur automatischen, differenzierten Ermittlung der Massen für die Ausschreibung herangezogen werden können.
Dass mit California 3000 die Übernahme von Daten aus ArchiCAD auch AVA-seitig das Arbeiten mit Bauteilen voraussetzt, ist keineswegs ein Manko, auch wenn nicht wenige Anwender davor vielleicht zurückschrecken dürften. Sicher: Das Zusammenstellen von Bauteilen mit den korrekten Mengenansätzen für die einzelnen Positionen erfordert eine gewisse Vorarbeit (die Dynamischen Baudaten von Dr. Schiller & Partner versprechen hierbei Zeitersparnis). Ist diese aber einmal geleistet, kann das Verfahren seine Vorteile ausspielen; unter anderem, weil die voraussichtlichen Bau-kosten in einem recht frühen Planungsstadium mit geringem Aufwand relativ präzise bestimmt werden können. jr
G&W Software Entwicklung Bayerstraße 13 80335 München Tel. (089) 515064 Fax (089) 51506999 www.gw-software.de