AVA-Software

Leistungsverzeichnis und Standardtexte

Das Herzstück ist der LV-Editor. Er entscheidet, ob du in einer Stunde ein sauberes Verzeichnis stehen hast oder in drei. Achte darauf, wie die Software mit Standardleistungstexten umgeht. In der DACH-Region sind hier standardisierte Textkataloge verbreitet, die als Grundlage dienen. Prüfe, ob die Software solche Kataloge einlesen kann und ob du eigene Textbausteine anlegen und wiederverwenden kannst. Ein Betrieb, der jedes Projekt neu tippt, verschenkt Zeit und produziert Uneinheitlichkeit.

GAEB-Schnittstelle

Der Datenaustausch am Bau läuft in DACH ganz wesentlich über das GAEB-Format. Ohne saubere GAEB-Unterstützung kannst du ein LV nicht sinnvoll an Bieter geben und deren Angebote nicht zurücklesen. Frage konkret nach den unterstützten Austauschphasen: Die reine Weitergabe eines LV ist etwas anderes als das Zurücklesen bepreiste Angebote. Lass dir in der Demo zeigen, wie eine Datei aus einer fremden Software importiert wird, nicht nur eine, die die Software selbst erzeugt hat.

Preisspiegel

Der Preisspiegel ist der Punkt, an dem sich Geld entscheidet. Gut ist eine Software, die dir mehrere Angebote positionsweise gegenüberstellt, Summen bildet und Ausreißer sichtbar macht. Achte darauf, ob du auch teilweise Vergaben abbilden kannst: also Gewerk A an Bieter 1, Gewerk B an Bieter 2. Wer nur Gesamtsummen vergleicht, übersieht, dass der günstigste Gesamtbieter in einem Einzelgewerk deutlich zu teuer sein kann.

Aufmaß und Abrechnung

Hier trennt sich Bürowerkzeug von Baustellenwerkzeug. Prüfe, ob Aufmaße nach den üblichen Regeln erfasst werden können und ob sich Abschlagsrechnungen kumulativ aufbauen, also jede neue Abschlagsrechnung die vorherigen berücksichtigt. Das ist eine klassische Fehlerquelle: Wenn die Software das nicht sauber kumuliert, zahlst du irgendwann zu viel oder streitest dich am Ende der Schlussrechnung.

Berichte und Kostenverfolgung

Du willst jederzeit sehen, wo ein Projekt gegen das Budget steht. Eine brauchbare AVA-Software zeigt dir Soll und Ist auf Ebene der Kostengruppen, nicht nur als eine große Zahl. Achte auf die Exportformate: Kannst du einen Bericht als PDF für den Bauherren und als strukturierte Datei für die Buchhaltung ausgeben?

Mehrbenutzer und Rechte

Sobald mehr als eine Person mit den Daten arbeitet, brauchst du ein Rechtekonzept. Wer darf ein LV freigeben, wer darf nur lesen, wer darf Rechnungen prüfen? Frage, ob mehrere Personen gleichzeitig an einem Projekt arbeiten können, ohne sich gegenseitig zu überschreiben.

Der erste Filter ist deine eigene Größe und dein Gewerk. Ein Planungsbüro, das ausschreibt und vergibt, hat andere Anforderungen als ein ausführender Betrieb, der vor allem kalkuliert und abrechnet. Kläre für dich, welche der drei Phasen (Ausschreibung, Vergabe, Abrechnung) du wirklich intensiv nutzt. Manche Betriebe kaufen den vollen Umfang und nutzen dauerhaft nur ein Drittel.

Der zweite Punkt ist die Bedienung, und hier ein klarer Rat: Lass die Software in der Demo von der Person bedienen, die später damit arbeitet, nicht vom Chef und nicht vom Vertriebler. Gib dieser Person eine echte Aufgabe: ein kleines LV mit zehn Positionen anlegen, ein GAEB einlesen, einen Preisspiegel bauen. Wenn sie dabei ins Stocken gerät und ständig nachfragen muss, ist das ein Warnsignal, das keine Featureliste aufwiegt.

Der dritte Punkt sind Schnittstellen. Frage nicht nur, ob eine Schnittstelle existiert, sondern zu welchen Systemen bei dir sie konkret passt: deine Buchhaltung, dein CAD, dein Dokumentenmanagement. Eine Schnittstelle, die es theoretisch gibt, aber nicht zu deinem Buchhaltungsprogramm passt, hilft dir nicht.

Der vierte Punkt ist der Datenimport bei der Umstellung. Kläre vor Vertragsabschluss, wie deine bestehenden Projekte und Textkataloge in die neue Software kommen. Wenn du bei null anfangen musst, ist das ein realer Aufwand, den du einplanen musst.

Cloud oder lokal

Eine Grundsatzfrage bleibt, ob die Software lokal installiert oder als Cloud-Lösung betrieben wird. Cloud gibt dir Zugriff von der Baustelle und weniger eigene Wartung, bindet dich aber an eine funktionierende Verbindung und an den Anbieter. Lokale Installation gibt dir mehr Kontrolle über deine Daten, verlagert aber Wartung und Backups zu dir. Es gibt hier kein richtig oder falsch, nur eine Entscheidung, die zu deinem Betrieb passen muss.

Der Anschaffungspreis ist der kleinere Teil der Wahrheit. Rechne über mehrere Jahre, dann siehst du das echte Bild. Ich nenne dir hier keine Zahlen, weil sie stark schwanken und schnell veralten, aber ich zeige dir, welche Posten du zusammensuchen musst.

Lizenzmodell

Verbreitet sind zwei Grundmodelle. Der Kauf einer Lizenz mit einmaliger Zahlung, oft kombiniert mit einem jährlichen Wartungsvertrag für Updates. Und das Abomodell, bei dem du monatlich oder jährlich pro Nutzer zahlst. Beim Kauf zahlst du vorne mehr, beim Abo läuft der Betrag dauerhaft. Rechne beide Varianten über den Zeitraum durch, den du die Software realistisch nutzen willst.

Kosten pro Arbeitsplatz

Achte darauf, wie gezählt wird. Zahlst du pro benanntem Nutzer oder pro gleichzeitigem Zugriff? Ein Betrieb mit zehn Mitarbeitern, von denen selten mehr als drei gleichzeitig ins System gehen, fährt mit einem Modell nach gleichzeitigen Zugriffen anders als mit einem Modell pro Kopf.

Versteckte Posten

Das sind die Kosten, die in der Angebotsphase gern untergehen. Einrichtung und Datenübernahme. Schulung, gerechnet in Tagen oder als Pauschale. Support, der je nach Vertragsstufe unterschiedlich schnell reagiert. Zusatzmodule, die einzeln kosten (etwa eine bestimmte Schnittstelle oder eine mobile Aufmaß-Funktion). Frage explizit, was im Grundpreis enthalten ist und was extra kostet, und lass dir das schriftlich geben.

Der Aufwand auf deiner Seite

Der teuerste unsichtbare Posten ist die Einarbeitungszeit deiner Leute. Während der Umstellung arbeitet das Team langsamer, und das kostet real, auch wenn keine Rechnung dafür kommt. Plane diese Phase mit ein, statt sie zu ignorieren und dann überrascht zu sein.

Der erste Klassiker: Ein Betrieb kauft nach Featureliste. Der Vertrieb hakt dreißig Punkte ab, alles ist grün, der Vertrag wird unterschrieben. Ein halbes Jahr später stellt sich heraus, dass zwei der drei Funktionen, die täglich gebraucht werden, umständlich zu bedienen sind. Die Featureliste hat gestimmt, die Software taugte trotzdem nicht für den Alltag.

Der zweite: Die GAEB-Schnittstelle wird nur mit sauberen, selbst erzeugten Dateien getestet. Auf der Baustelle kommen dann Dateien von Bietern, die mit anderer Software erstellt wurden, und plötzlich fehlen Positionen oder Mengen werden falsch übernommen. Teste den Import immer mit fremden Dateien.

Der dritte: Niemand ist für die Textkataloge und Stammdaten zuständig. Jeder legt seine eigenen Positionen an, und nach einem Jahr hast du drei Varianten desselben Textes. Die Software kann gemeinsame Stammdaten, aber ohne eine verantwortliche Person verwildern sie.

Der vierte: Die kumulative Abrechnung wird nicht verstanden. Abschlagsrechnungen werden nebeneinander geführt statt aufeinander aufbauend, und bei der Schlussrechnung stimmt die Summe nicht mehr. Das führt zu Streit mit dem Auftraggeber, den man sich sparen kann.

Der fünfte: Die Umstellung wird in die heiße Projektphase gelegt. Das Team soll mitten im laufenden Großprojekt auf eine neue Software wechseln. Das geht fast immer schief. Plane die Einführung in eine ruhigere Phase.

Beim öffentlichen Auftraggeber gelten für Ausschreibung und Vergabe formale Regeln, die eingehalten und dokumentiert werden müssen. Die Software soll dir helfen, den Vergabeprozess nachvollziehbar zu machen: Wer hat welches Angebot wann bekommen, wie wurde gewertet, warum fiel die Entscheidung so aus. Achte darauf, dass die Software eine saubere Dokumentation der Vergabeschritte erlaubt, denn im Zweifel musst du sie belegen können.

Für die Rechnungsstellung gelten steuerliche Aufbewahrungspflichten. Rechnungen und die zugehörigen Daten müssen über gesetzlich vorgegebene Zeiträume revisionssicher aufbewahrt werden. Kläre, wie die Software das unterstützt, gerade bei einer Cloud-Lösung: Wo liegen die Daten, wie kommst du im Streitfall an den Originalstand.

Beim Thema Datenschutz gilt in DACH die DSGVO. Sobald personenbezogene Daten verarbeitet werden (etwa Kontaktdaten von Bietern oder Mitarbeitern), brauchst du bei einer Cloud-Lösung in der Regel einen Vertrag zur Auftragsverarbeitung mit dem Anbieter. Frage nach dem Serverstandort und danach, ob ein solcher Vertrag angeboten wird.

Ein wichtiger Hinweis: Ich bin kein Rechtsanwalt, und die genaue Ausgestaltung hängt von deinem Bundesland, deiner Rechtsform und deiner Auftragsstruktur ab. Nutze diesen Abschnitt als Checkliste dafür, welche Fragen du stellen musst, nicht als abschließende Rechtsauskunft. Bei öffentlichen Aufträgen und bei Zweifeln in der Vergabe lohnt sich fachlicher Rat.

Schritt 1: Anforderungen aufschreiben, bevor du Demos ansiehst

Setz dich mit den Leuten zusammen, die täglich damit arbeiten werden. Schreibt auf, welche der drei Phasen ihr wirklich nutzt und welche fünf Aufgaben ihr am häufigsten macht. Diese Liste ist dein Maßstab, nicht die Featureliste des Anbieters.

Schritt 2: Eine echte Testaufgabe definieren

Baue eine kleine, aber realistische Aufgabe: ein LV mit einer Handvoll Positionen, ein GAEB-Import aus einer fremden Datei, ein Preisspiegel aus zwei Angeboten, eine Abschlagsrechnung. Diese Aufgabe legst du jedem Anbieter in der Demo vor. So wird es vergleichbar.

Schritt 3: Die richtige Person testen lassen

Nicht der Chef klickt, sondern die Sachbearbeiterin oder der Kalkulator. Beobachte, wo sie hängen bleiben. Frag am Ende nicht "gefällt es dir", sondern "wo hat es dich genervt".

Schritt 4: Gesamtkosten über Jahre rechnen

Hol dir für jede engere Wahl ein Angebot, das Lizenz, Wartung, Einrichtung, Schulung und Support getrennt ausweist. Rechne beide Preismodelle (Kauf und Abo) über den Zeitraum durch, den du die Software nutzen willst. Frag ausdrücklich nach versteckten Posten.

Schritt 5: Datenübernahme klären

Lass dir zeigen, wie deine bestehenden Textkataloge und Projekte in die neue Software kommen. Kläre, wer diese Migration macht und was sie kostet.

Schritt 6: Referenz aus deinem Gewerk suchen

Bitte den Anbieter um einen Kontakt zu einem Betrieb ähnlicher Größe in deinem Gewerk. Ruf dort an und frag konkret, was im Alltag nervt und wie der Support in einer echten Notlage reagiert hat.

Schritt 7: Einführung in eine ruhige Phase legen

Plane den Umstieg nicht mitten in ein Großprojekt. Nimm ein kleines, überschaubares Projekt als erstes echtes Projekt in der neuen Software, damit Fehler dich nicht teuer treffen.

Wenn du diese sieben Schritte durchgehst, triffst du keine perfekte Entscheidung, aber eine, die du begründen kannst und die im Alltag trägt. Und genau darum geht es: nicht um die Software mit den meisten Häkchen, sondern um die, mit der deine Leute am Montagmorgen wirklich arbeiten wollen.