Konvertierung von Word-, Excel- und PDF-Dateien in GAEB-XML

Facility Management (FM) umfasst das ganzheitliche Betreiben und Verwalten von Immobilien und Liegenschaften. Dazu gehört oft die Vergabe von Dienstleistungen – etwa Instandhaltung, Reinigung, Wartung technischer Anlagen, Sicherheitsdienste usw. Diese sogenannten Facility Services werden zunehmend standardisiert ausgeschrieben, um Qualität und Wirtschaftlichkeit sicherzustellen.

• Vergaberechtliche Vorgaben: Die Vergabe von FM-Leistungen unterliegt – insbesondere bei öffentlichen Auftraggebern – dem Vergaberecht. Dies fordert Transparenz, Vergleichbarkeit der Angebote und dokumentierte Verfahren. Der Einsatz von GAEB kann hierzu beitragen: Wie im Bauwesen ermöglicht GAEB eine elektronische Angebotsabgabe nach VOB-Konzept (Verdingungsordnung für Bauleistungen) bzw. entsprechenden Regelungen für Dienstleistungen. Seit Oktober 2018 ist die E-Vergabe für EU-weite Ausschreibungen verpflichtend; in Deutschland müssen öffentliche Auftraggeber elektronische Angebote akzeptieren. Während im Bau die VOB/A GAEB-Dateien als gängiges Format nennt, können im Bereich Dienstleistungen (nach UVgO/VgV) strukturierte Formate freiwillig genutzt werden. Allerdings empfiehlt z.B. GEFMA, schon bei FM-Ausschreibungen alle Beteiligten früh einzubeziehen und konsistente Unterlagen „aus einem Guss“ zu erstellen. GAEB-konforme Dateien könnten hier helfen, Spezifikation und Preisteil synchron zu halten. Zudem lassen sich mit GAEB Preisspiegel (Angebotsvergleiche) einfach generieren, was der in GEFMA 520 geforderten eindeutigen Preisabfrage und Kalkulationsvorgaben entspricht. FM-spezifisch sind oft komplexe Vertragskonstrukte (Rahmenvereinbarungen, Leistungs- und Qualitätskennzahlen, ESG-Vorgaben); ein Konverter muss sicherstellen, dass z.B. Qualitätskriterien oder Leistungskennzahlen nicht verloren gehen. Hier sind gegebenenfalls Erweiterungen oder Notlösungen nötig (z.B. als freie Texte in GAEB, wenn keine spezifischen Felder existieren).

• Lebenszyklus- und Betriebsphase: Im Gegensatz zum einmaligen Bauprojekt werden im FM Leistungen fortlaufend erbracht. Daher gibt es Anforderungen an Datenkontinuität: Von der Bauphase (wo z.B. ein GAEB-LV für die Ausstattung erstellt wurde) zur Betriebsphase (wo Wartungsleistungen an diesen Ausstattungen ausgeschrieben werden). Eine Herausforderung besteht darin, relevante Informationen aus Bau-LVs in FM-Leistungsverzeichnisse zu übernehmen. Denkbar ist etwa, die während der Bauausschreibung verwendeten GAEB-Daten (z.B. für Wartungsverträge oder Betriebsmittel) weiterzuverwenden, damit der FM-Bereich nahtlos anknüpfen kann. Hier könnten Konverter helfen, GAEB-Dateien aus der Bauphase auszulesen und in FM-Ausschreibungen (ggf. mit Anpassungen) einzubringen. Außerdem wird zunehmend BIM im FM relevant – digitale Gebäudemodelle enthalten FM-Daten. GAEB 3.3’s GUIDs und erweiterte Strukturen sind auch darauf ausgelegt, FM-relevante Informationen (z.B. Bauteil-IDs) zu transportieren.

• Integration mit CAFM und ERP-Systemen: In der Betriebsphase nutzen Facility Manager oft CAFM-Systeme (Computer Aided Facility Management) oder ERP-Systeme (z.B. SAP) zur Verwaltung von Verträgen, Leistungen und Kosten. Diese Systeme benötigen strukturierte Daten und Schnittstellen. Ein Beispiel ist die GAEB-Schnittstelle in SAP®, die von PROMOS entwickelt wurde, um GAEB-LVs direkt ins SAP-System zu importieren. Dadurch können FM-Ausschreibungen, die als GAEB-Datei vorliegen, in SAP PM/CS Module übernommen werden, wo sie als Leistungsverzeichnis in Bestellungen oder Verträgen weiterverarbeitet werden. Für den FM-Bereich bedeutet dies, dass ein Word-Dokument mit Leistungsbeschreibungen erst in GAEB konvertiert werden muss, um von solchen Systemen automatisch eingelesen zu werden. Die Anforderungen hierbei sind u.a., dass die Struktur den SAP-Leistungsverzeichnis-Vorgaben entspricht (z.B. keine zu langen Texte, sinnvolle Gliederung). Auch andere CAFM-Software könnte GAEB unterstützen, wenn FM-Leistungen als „virtuelles Bauprojekt“ behandelt werden. Konverter sollten daher möglichst allgemeine GAEB-konforme LVs erzeugen, die von gängigen FM-Systemen verstanden werden.

• Qualitätssicherung und Rechtssicherheit: FM-Ausschreibungen müssen klar definierte Leistungsgegenstände haben, um spätere Betreiberverantwortung und Vertragsabwicklung wasserdicht zu gestalten. Hier knüpfen Normen und Richtlinien an, z.B. die VDI 6022 (Raumlufttechnik, Wartungsinhalte), VDI 3810 (Betreiben von Gebäuden) etc., die beschreiben, was in Leistungsverzeichnissen stehen muss. Ein Konverter kann prüfen, ob z.B. alle Positionen eine Einheit und Menge haben (eine Anforderung nach VOB für prüfbare Angebote). Weiterhin ist sicherzustellen, dass keine kritischen Informationen verloren gehen: Häufig enthalten Word-Dokumente neben dem eigentlichen Leistungs-Text noch Hinweise, Bilder oder Tabellen (z.B. Reinigungsintervalle als Matrix). Solche Anhänge müssen im GAEB entweder als Text übernommen oder separat beigefügt werden (GAEB erlaubt z.B. Anlagen als separate Dateien, aber es gibt dafür keinen Standardmechanismus in GAEB 3.2 außer evtl. Verweise). Ein guter Konvertierungsprozess erkennt diese FM-typischen Inhalte und integriert sie angemessen (etwa als Z-Flächen Positionen mit Beschreibung, oder Hinweiszeilen).

Die Kernherausforderung bei der Konvertierung nach GAEB ist die Gewinnung strukturierter Ausschreibungsdaten (Positionen, Mengen, Hierarchien, Texte) aus unterschiedlichen quellformaten. Word, Excel und PDF weisen jeweils spezifische Eigenschaften und Tücken auf. Im Folgenden werden für jedes Format Techniken und bewährte Verfahren zur Datenerfassung vorgestellt.

Viele Ausschreibenden – auch im FM – verfassen Leistungsbeschreibungen als Word-Dokument, oft basierend auf eigenen Vorlagen. Diese Dokumente enthalten typischerweise Überschriften für Gewerke/Leistungsbereiche, Positionsbeschreibungen mit Leistungsumfang (Langtext), und manchmal tabellarisch aufgeführte Mengen und Einheiten. Für eine GAEB-Konvertierung muss dieser Inhalt analysiert und in die formale Struktur übertragen werden.

• Textbasierte Analyse: Konverter lesen Word-Dateien meist als einfachen Text aus (ggf. über Export in .txt oder .rtf). Dabei ist zu beachten, dass bestimmte Word-Elemente keine echten Textzeichen sind. Insbesondere automatische Nummerierungen und Gliederungen (Outline-Nummerierung der Überschriften oder Aufzählungen) werden von Word intern als Formatierung verwaltet und nicht als Zeichenkette gespeichert. Ein Konverter „sieht“ also z.B. nicht die Gliederungspunkte „1.1“ etc., wenn diese nicht explizit als Text in der Datei stehen. Daher wird empfohlen, Word-Dokumente vor dem Import als RTF oder TXT zu speichern, um alle Inhalte als reinen Text vorliegen zu haben. Alternativ kann man in Word die Gliederungsnummern in Text umwandeln (durch Entfernen der automatischen Nummerierung). Auch Tabellen in Word (z.B. für Mengenangaben) sollten nach Möglichkeit in Fließtext umgewandelt werden, falls der Konverter keine Tabellenerkennung bietet.

• Erkennung von Positionsstrukturen: Ein guter Konverter verfügt über Algorithmen, um in einem Textdokument die einzelnen Positionen zu erkennen. Typischerweise wird nach Positionsnummern gesucht – z.B. Zahlen oder alphanumerische Codes am Zeilenanfang. Da aber Formatierungen entfallen können, müssen flexible Muster verwendet werden. Viele Tools (wie der GAEB-Konverter von T&T) bieten hier mehrere Modi an:

• Vollautomatische Analyse: Das Programm versucht anhand typischer Muster (z.B. „<Nummer><Tab><Text><Tab><Menge><Einheit>“) die Struktur zu erkennen. Es gibt meist Optionen, dieses Parsing anzupassen (z.B. Trennzeichen definieren, Mindestlängen, etc.), um möglichst viele Fälle abzudecken.

• Halbautomatisch mit Makro-Recorder: Wenn die automatische Erkennung nicht perfekt greift, aber das Dokument dennoch ein einheitliches Muster je Position hat, kann der Benutzer dem Konverter ein „Beispiel“ vorgeben. Via Makro-Recorder klickt man z.B. einen Beispielsatz an („Position 1 – Reinigung – 10 – m²“) und markiert die Bereiche für Positionsnummer, Text, Menge, Einheit. Das Tool generiert daraus eine Regel, die dann auf alle Zeilen angewandt wird.

• Manuell im Dialog: Bei uneinheitlichen Dokumenten (Positionsdarstellungen unterscheiden sich) kann der Konverter Schritt für Schritt den Nutzer fragen, wie die nächste Zeile zu interpretieren ist. Dies ist zwar zeitaufwändig, gewährleistet aber, dass jedes Fragment richtig zugeordnet wird.

• Umgang mit Langtexten und Gliederungen: In GAEB gibt es Kurz- und Langtexte je Position sowie Überschriften (Knoten ohne Mengeneinheiten). Ein Word-Dokument enthält diese oft als Absätze unterschiedlicher Ebenen (Überschrift 1, 2,... für Gliederung; Standardtext für Positionen; evtl. eingerückte oder kursiv formatierte Zusatztexte). Ein Konverter sollte idealerweise anhand von Formatvorlagen oder typografischen Merkmalen erkennen, was Überschrift und was Position ist. In der Praxis gelingt das nur begrenzt. Daher ist es sinnvoll, Word-Dokumente konsequent zu strukturieren: z.B. jede Position beginnt mit einer Nummer und endet mit einem Umbruch; Langtexte von Positionen werden eventuell eingerückt oder durch Anstrichzeichen markiert. Solche Konventionen kann man im Vorfeld definieren. Einige Tools erlauben auch, in Word ein Makro/Plugin zu verwenden, das das Dokument entsprechend „vorbereitet“. T&T z.B. bietet ein Word-Add-In, das per Knopfdruck die Word-Inhalte in die benötigte Zwischenform bringt.

• Keine Preisübernahme aus Word: Wichtig zu erwähnen – Preise werden generell nicht aus Word/Text importiert. Falls im Word-Dokument bereits Preise stehen (z.B. aus einer früheren Ausschreibung), ignorieren die meisten Konverter diese bewusst. GAEB-Ausschreibungen (X83) enthalten keine Preise, und Angebote (X84) sollten von Bietern separat kalkuliert werden. Deshalb müssen etwaige Preisangaben aus dem Word-Dokument vom Konverter ausgelassen werden, um das GAEB-Format nicht zu verletzen.

Zusammenfassend ist die Konvertierung von Word nach GAEB möglich, aber vom Dokumentenaufbau abhängig. Die Praxis zeigt, dass es mit kleinen Anpassungen gut funktioniert, wenn einheitliche Muster vorliegen. Für heterogene oder komplex formatierte Dokumente bieten Tools wie der GAEB-Konverter interaktive Methoden an. Oftmals lohnt es sich, den Verfassern der Leistungsbeschreibung Richtlinien an die Hand zu geben, damit ihre Word-Datei „GAEB-konvertierbar“ ist (z.B. Verwendung einer Tabstop-Tabelle für Position/Menge/Einheit, Verzicht auf mehrspaltige Layouts etc.). Notfalls können spezialisierte Dienstleister hinzugezogen werden, die per manueller Nachbereitung das Dokument konvertierbar machen – T&T etwa bietet an, Word- oder PDF-Ausschreibungen als Service ins GAEB-Format umzusetzen.

Excel wird im FM häufig zur Erstellung von Preisblättern oder kleinen Leistungsverzeichnissen genutzt. In Wartungsverträgen oder Reinigungsleistungen etwa existieren tabellarische Leistungsverzeichnisse mit Spalten für Leistung, Einheit, Menge, Preis. Excel hat gegenüber Word den Vorteil, dass Daten bereits in Zellen organisiert sind – dies kann ein Vorteil für den Konverter sein, sofern die Tabellenstruktur den Erwartungen entspricht.

• Erwartete Tabellenstruktur: Ein GAEB-Konverter muss wissen, in welchen Spalten welche Informationen stehen. Daher verlangen viele Tools eine definierte Spaltenanordnung. Typischerweise muss die erste Tabellenzeile Überschriften enthalten, z.B. "Pos.", "Kurztext", "Menge", "Einheit", "EP". Die Reihenfolge kann oft konfiguriert werden, aber jede Information sollte in genau einer Spalte stehen (keine zusammengefügten Zellen). Eine Zeile in Excel entspricht idealerweise genau einer Position im LV. Mehrzeilige Texte (Langtexte) sind problematisch, wenn sie in Excel über mehrere Zeilen verteilt wurden – besser ist es, eine Zelle kann auch Zeilenumbrüche intern enthalten. Wichtig: Mindestens eine leere Zeile markiert das Ende des Leistungsverzeichnisses. In manchen Konvertern bedeuten z.B. 5 Leerzeilen das Ende. All dies dient dazu, dem Programm eindeutig zu signalisieren, wo welche Daten stehen.

• Vorverarbeitung mit Makros: Falls das Excel nicht dem gewünschten Format entspricht, können Hilfs-Makros eingesetzt werden. Die Firma T&T liefert etwa Excel-Makros mit, die auf Knopfdruck aus einem frei gestalteten Excel-Sheet eine importfähige Tabelle generieren. Diese Makros können z.B. automatisch Spalten umbenennen, leere Spalten einfügen oder verbundene Zellen auflösen. In der Praxis bedeutet das: der Anwender lädt das gegebene Excel, führt ggf. ein Makro aus („Makro: Excel auf GAEB vorbereiten“), und speichert das Ergebnis ab. Dieses wird dann in den Konverter eingelesen.

• Importprozess in Konvertern: Das Einlesen erfolgt meist, indem man im Konverter Datei > Öffnen wählt und die Excel-Datei angibt. Daraufhin erscheint ein Dialog, in dem Einstellungen vorgenommen werden können: Auswahl, welches Tabellenblatt oder Zellbereich das LV enthält (manchmal erwartet das Tool ein Blatt namens z.B. "LV"), Zuordnung der Spaltenüberschriften zu GAEB-Feldern (falls nicht Standardbezeichnungen verwendet wurden), und weitere Optionen. Ein Konverter könnte z.B. nachfragen, ob die Excel-Positionen bereits Preise enthalten (dann könnte er entscheiden, ob er eine X81 oder X84 Datei erzeugt). In den meisten Fällen werden Excel-Daten ohne Preise als Ausschreibung (X81/X83) interpretiert, mit Preisen als Angebot (X84). Der Nutzer sollte dies entsprechend auswählen.

• Rückexport nach Excel: Interessant ist, dass viele GAEB-Programme auch den umgekehrten Weg anbieten – GAEB nach Excel. Bieter nutzen dies gerne: Sie importieren die GAEB-Ausschreibung in Excel, kalkulieren dort mit bekannten Formeln, und importieren dann die fertigen Preise zurück ins GAEB. Ein guter Konverter unterstützt dies verlustfrei. Für den Export gibt es Optionen, etwa AutoFilter in Excel zu setzen, Preise ein/ausblenden usw.. Zudem können beim GAEB->Excel-Export Zusatzblätter generiert werden, z.B. eine Kalkulationsvorlage oder ein Preisspiegel-Formular. Diese dienen dann der internen Weiterverarbeitung.

Für die eigentliche Konvertierung Excel -> GAEB ist aber entscheidend, dass das Excel sauber aufgebaut ist. Zusammengefasst gelten die Regeln: Eine Zeile = eine Position; alle relevanten Felder in separaten Spalten mit Kopfzeile; keine versteckten/verbundenen Zellen; ein Tabellenblatt pro LV. Werden diese eingehalten, ist der Import sehr zuverlässig und weitgehend automatisierbar. In vielen Fällen sind Excel-Daten besser strukturiert als Word-Dokumente, was den Konvertierungsaufwand reduziert. Allerdings muss man auch hier aufpassen: Excel verleitet dazu, Berechnungen einzubauen (Summen, Formeln). Solche Summenzeilen dürfen nicht als Position fehlinterpretiert werden – oft kann man sie einfach vor dem Import entfernen oder der Konverter ignoriert nicht numerische Positionsnummern. Ein potenzielles Problem sind ebenfalls Mehrfachzeilen pro Position (wenn jemand z.B. Langtext unter der Mengenzeile als eigene Zeile notiert hat); hierfür müsste der Konverter die Zeilen zusammenschieben. Fortgeschrittene Konverter können anhand gleicher Positionsnummer erkennen, dass mehrere Excel-Zeilen zu einer GAEB-Position gehören.

Abschließend sei erwähnt, dass Excel im FM so verbreitet ist, dass manche FM-Ausschreibungsstandards dieses Format mit vorsehen. Excel fungiert hier quasi als Zwischensprache zwischen Mensch und GAEB. Es ist jedoch ratsam, das Excel wirklich nur zur Dateneingabe zu nutzen und für den Austausch mit Bietern dann GAEB bereitzustellen, da GAEB eine höhere Datensicherheit (keine Formeln veränderbar, klar definierte Felder) gewährleistet.

PDF-Dateien stellen einen Sonderfall dar: PDF ist ein Output-Format, optimiert für Darstellung und Druck, nicht für Weiterverarbeitung. Trotzdem liegen viele Leistungsbeschreibungen ausschließlich als PDF vor – entweder von externen Planern geliefert oder aus früheren Vergaben archiviert.

• Direkte Konvertierung nicht möglich: Kein GAEB-Konverter kann ein PDF direkt in GAEB umwandeln, ohne Zwischenschritte. PDFs enthalten textuelle Informationen (bei digitalen PDFs) oder nur Bilddaten (bei eingescannten). Die *GAEB-Tools-Empfehlung lautet klar: „Eine direkte Konvertierung von PDF ins GAEB-Format ist leider nicht möglich.“.

• Vorgehensweise für digitale PDFs: Ist die PDF-Datei nicht gescannt, sondern z.B. aus Word/Excel exportiert, so lässt sie sich oft mit Adobe Acrobat (Vollversion) oder anderen PDF-Tools zurückwandeln ins Ursprungsformat. Acrobat bietet z.B. „Speichern als Word“ oder „Speichern als Excel“. Dabei wird versucht, die ursprünglichen Strukturen wiederherzustellen. Erfahrungsgemäß klappt dies bei tabellarischen LVs in PDF nach Excel recht gut – man erhält eine Tabelle, die man wie oben beschrieben weiterverarbeiten kann. Bei rein textuellen PDFs kann der Export nach Word die ursprünglichen Überschriften und Absätze zurückbringen. Dieser Schritt ist also: PDF -> Word/Excel (via PDF-Software), dann Word/Excel -> GAEB (via Konverter). Es ist zwar ein Umweg, aber meist der effizienteste, da man so die speziellen PDF-Hürden umgeht.

• Vorgehensweise für gescannte PDFs: Ist die PDF-Datei ein Scan (reines Bild, etwa eingescanntes Papier-LV), führt kein Weg an OCR (Optical Character Recognition) vorbei. D.h., man benötigt ein Texterkennungsprogramm (z.B. ABBYY FineReader, Tesseract), um das Bild in maschinenlesbaren Text zu überführen. Moderne OCR kann auch Tabellenstrukturen erkennen, aber bei komplexen Layouts (Spalten, Rahmen) sind Nachkorrekturen nötig. Nach dem OCR-Vorgang hat man idealerweise ein Word-Dokument oder einen Text, den man dann wiederum wie unter 4.1 behandeln kann. Wichtig: OCR kann Fehler einführen (z.B. „O“ statt „0“), deshalb ist eine sorgfältige Prüfung erforderlich, bevor man die Daten ins GAEB übernimmt. Manche Dienstleister bieten spezialisierte OCR für Bauleistungsverzeichnisse, die etwa typische Abkürzungen oder Maßeinheiten besser erkennen.

• Nachbearbeitung des extrahierten Inhalts: Egal ob via PDF->Word oder via OCR, das Resultat muss geprüft und evtl. editiert werden, um den Konverter zufrieden zu stellen. Oft fehlen z.B. Positionsnummern, wenn die PDF keine hatte (in PDFs werden Aufzählungen manchmal als Einrückungen dargestellt). Dann muss der Mensch eingreifen und Nummern ergänzen. Auch Seitenumbrüche in PDFs können mitten in einer Position passieren, was im extrahierten Text zu unsinnigen Zeilenumbrüchen führt – diese sind händisch zu entfernen. Kurzum, bei PDFs ist der Prozess meist teilmanuell.

• Tools und Automatisierung: Es gibt keine vollautomatische „PDF zu GAEB“-Lösung am Markt, was dem komplexen Problem geschuldet ist. Die gängigen Anbieter (z.B. MWM mit PRIMO, T&T mit GAEB-Konverter) empfehlen das oben beschriebene Vorgehen. MWM PRIMO Handbuch erwähnt: „PDF-Dateien wandeln Sie erst mittels optionaler Texterkennung in TXT oder RTF um und konvertieren sie dann... in GAEB“. Dieses zweistufige Vorgehen hat sich als Standard etabliert. Einige Workflows könnten teilautomatisiert werden (z.B. ein Script, das PDF2Text ausführt und dann GAEB-Konverter anstößt), aber aufgrund der Vielfalt der PDF-Layouts ist fast immer eine manuelle Sichtkontrolle nötig.

• Sonderfall: PDF mit Formularfeldern: Manchmal werden GAEB-Ausschreibungen ins PDF-Format exportiert, wo sie ausfüllbare Felder für Preise haben (sogenannte GAEB-Online-Formulare für Bieter ohne Software). Diese PDFs enthalten die LV-Daten im Text und der Bieter füllt nur Preise ein. Die Rückführung solcher ausgefüllten PDFs in GAEB ist kaum vorgesehen – hier müsste man entweder den Bieter bitten, die Daten in GAEB zu übertragen, oder man schreibt ein spezielles Skript, das die Formularfeld-Inhalte extrahiert und ins GAEB einträgt. Da dies selten verlangt wird, sparen wir weitere Details aus.

Zusammengefasst: PDF -> GAEB erfordert einen Zwischenschritt. Optimal ist die Rückwandlung ins Ursprungsformat (Word/Excel) mit einem Tool wie Adobe Acrobat, sofern das PDF nicht nur ein Scan ist. Andernfalls muss OCR-Technologie eingesetzt werden. In beiden Fällen folgt dann die normale Verarbeitung wie in 4.1/4.2 beschrieben. Eine direkte Verarbeitung von PDF durch GAEB-Konverter existiert nicht. Daher sollte bereits bei der Ausschreibung darauf hingewirkt werden, dass neben PDF immer ein editierbares Format verfügbar ist – das erspart diesen Konvertierungsaufwand. Wo dies nicht gegeben ist, muss entsprechend mehr Zeit für die Datenaufbereitung eingeplant werden.

Abschließend sei noch erwähnt, dass ungeachtet des Quellformats bestimmte inhaltliche Grundvoraussetzungen erfüllt sein sollten, damit ein GAEB-LV entsteht: Jede Position braucht zumindest Ordnungszahl, Menge, Einheit und einen Beschreibungstext. Wenn eine dieser Angaben im Quelldokument fehlt, muss sie ergänzt oder erschlossen werden (z.B. Einheit "Stück" annehmen, wenn aus Kontext klar). Auch müssen die Hierarchien klar erkennbar sein: Ob eine Zeile eine Überschrift (Titel) ist oder eine Position mit zugehöriger Leistung, entscheidet sich oft an der fehlenden Mengenangabe oder besonderen Formatierung. Der Konverter bzw. der Bediener muss darauf achten, dass Überschriften als solche angelegt werden (GAEB-Positionsart = Titel) und nicht als normale Position mit Null-Menge. Diese inhaltliche Nachbereitung gehört mit zum Extraktionsprozess.

Im nächsten Kapitel wird nun beschrieben, wie auf Basis der so gewonnenen Daten eine Konvertierung in GAEB DA XML 3.2 konkret abläuft, welche Datenmodellierung dahinter steht und wie die GAEB-Datei erzeugt wird.

In diesem Kapitel wird der Gesamtprozess skizziert, der nötig ist, um aus den ursprünglich extrahierten Informationen (vgl. Kap. 4) eine valide GAEB DA XML 3.2 Datei zu erzeugen. Dies umfasst Schritte der Datenaufbereitung, die Abbildung auf das GAEB-Datenmodell und schließlich die Ausgabe der XML-Datei. Wir orientieren uns an einem idealtypischen Ablauf, wie er in Software-Konvertern oder auch in individuell programmierten Skripten umgesetzt wird.

Nachdem die Quelldaten aus Word/Excel/PDF gelesen wurden, steht zunächst eine Normalisierung an. Hier werden z.B. führende oder trailing Whitespaces entfernt, konsistente Dezimaltrennzeichen eingesetzt (Komma vs. Punkt bei Mengen), Einheiten vereinheitlicht (z.B. alle Schreibweisen von "Std.", "Stunden" angleichen). Auch wird geprüft, ob alle Positionen eine eindeutige Ordnungszahl haben. Falls nicht, kann das Programm Nummern generieren (z.B. fortlaufend, oder basierend auf Gliederungsebenen). Ebenso müssen Gliederungsebenen erkannt werden: Häufig werden sie aus der Numerierung abgeleitet – etwa "1.0" ist ein Titel, "1.1" eine Position darunter. Manchmal geben Einrückungen in Text oder Excel-Hierarchie (Gruppierung) das vor. Diese Hierarchie-Informationen werden in einem Zwischendatenmodell festgehalten, z.B. als Baumstruktur von Knoten (Titel) und Blättern (Positionen). Im Zuge der Strukturierung werden außerdem Textteile zugewiesen: Wenn z.B. eine Position aus mehreren Zeilen Text bestand (Kurztext + Langtext), werden diese in einem Feld kombiniert oder getrennt. Das interne Datenmodell könnte pro Position Felder haben für Titel, Kurztext, Langtext, Einheit, Menge, Preis, Positionsart. Positionsart meint: Titel, normale Position, Eventuell auch Zwischensummen oder Alternativposition – solche speziellen Arten müssen gekennzeichnet werden, damit sie korrekt ins GAEB übertragen werden (GAEB kennt z.B. "Alternativposition" als eigene Kennung). Hier fließen ggf. Nutzer-Einstellungen ein, z.B. "Zeilen ohne Menge, aber mit Doppelpunkt im Text sind Titel".

GAEB DA XML 3.2 definiert eine Reihe von Datenfeldern, die im XML ausgefüllt sein müssen oder können.

• Kopf- und Metadaten: Projektnummer, Projektname, Erstellungsdatum, Ersteller, ggf. eindeutige LV-ID. Diese Informationen sind oft nicht im Word/Excel-Dokument enthalten, müssen aber in den GAEB-Datei-Kopf eingearbeitet werden. Manche Konverter fragen diese beim Export explizit ab oder übernehmen sie aus den Projekteinstellungen. Beispielsweise kann der GAEB-Konverter beim Speichern nach „LV-Name“ und „Auftraggeber“ fragen, falls diese Daten nicht aus der Vorlage hervorgingen.

• Leistungsverzeichnisstruktur: Das Kernstück – bestehend aus einer Liste von Positionen und Titeln. Im GAEB-XML werden Titel als <OutlineItem> oder als Item mit speziellen Attributen realisiert (je nach Schema). Positionen werden als <Item> mit untergeordneten Elementen für Texte, Mengen, usw. modelliert. Ein Konverter wird nun aus jeder Position des Zwischendatenmodells ein solches XML-Element generieren. Wichtig ist, dass die Hierarchie erhalten bleibt: Das Datenmodell-Baum wird ins XML-Baum überführt. Dazu erhalten Titel und Positionen eine level oder parent Information, damit das XML sie korrekt verschachtelt (z.B. in GAEB-XML sind Titel oft container tags, unter denen ihre Positionen einsortiert werden).

• Texte: Kurztext und Langtext müssen ggf. getrennt in entsprechende Felder. GAEB erlaubt z.B. einen <ShortText> (eine Zeile, knapp) und <Description> oder <LongText> für ausführlichere Beschreibung. Einfache Konverter nehmen die erste Zeile als Kurztext und den Rest als Langtext. In FM-Leistungsverzeichnissen kann es sein, dass kein ausgeprägter Kurztext existiert (z.B. "Hausmeisterdienst" als Titel und dann detaillierte Beschreibung über mehrere Absätze). Hier entscheidet der Konverter oft pragmatisch, z.B. erster Satz als Kurztext, Rest als Langtext. Wichtig ist, unerlaubte Zeichen zu vermeiden (XML-Notation verlangt z.B. Escaping von &, < etc. in Texten). Auch Listen oder Aufzählungen im Langtext müssen in GAEB eventuell mit speziellen Steuerzeichen codiert werden (GAEB kann bestimmte Text-Formatierungen wie Aufzählungspunkte über Textattribute ausdrücken). Allerdings sind in GAEB XML 3.2 Formatierungen wie Fett/Kursiv nicht standardisiert übertragbar – solche gehen typischerweise verloren oder werden allenfalls als Markup im Text belassen (z.B. *fett*).

• Mengen und Einheiten: Diese Werte werden aus dem Datenmodell direkt übernommen. Der Konverter muss aber ggf. Einheitenschlüssel benutzen: GAEB kennt einen Katalog von Einheiten (in GAEB 3.2 evtl. über X400-Katalog definierbar). Oft reicht die Einheit als Text (z.B. "m²") und sie wird ins XML geschrieben; einige Systeme erwarten allerdings gültige GAEB-Einheitenkürzel. Da GAEB 3.2 auf SI-Einheiten basiert, sind gängige Einheiten problemlos (m, m², St., h etc.). Wenn im Word-Dokument exotische Einheiten stehen (z.B. "Portionen"), sollte man diese vorab anpassen oder im GAEB-Feld "UnitDescription" unterbringen.

• Preise: Abhängig von der Zielphase (Ausschreibung oder Angebot) werden Preisfelder gefüllt oder nicht. Bei Konvertierung von Word/Excel, die nur eine Leistungsbeschreibung enthält, erzeugen wir z.B. eine X81/X83 – dort bleiben Preisfelder leer. Der Konverter setzt ggf. Price=0 oder lässt das Element weg. Wenn wir hingegen ein bereits kalkuliertes Excel importieren (z.B. aus einem FM-Preisspiegel) und wollen ein Angebot (X84) generieren, dann müssen die Preise ins <UnitPrice> Feld jeder Position. Wichtig: GAEB X84 erwartet auch Summen (z.B. Positionsgesamtbetrag, aber den berechnet das importierende AVA-Programm meist selbst aus Menge*EP). Manche Konverter geben dennoch den Gesamtpreis je Position mit, oder zumindest am Ende eine Angebotssumme in den Dokumentendaten.

• Besonderheiten GAEB-XML 3.2: GAEB 3.2 fordert einige obligatorische Felder, z.B. <Currency> (Währung), <Language> etc., sowie eine Schema-Versionsangabe im Header. Diese werden vom Konverter typischerweise statisch eingefügt (Euro, de-DE, Version). Außerdem kann GAEB 3.2 jedes Element mit einem Guid ausstatten. Ein Konverter kann GUIDs generieren, ist aber nicht zwingend – nur falls BIM-Kompatibilität gewünscht. Einige Konverter (wie Dangl’s Tools) fügen standardmäßig GUIDs hinzu. Bei reiner Konvertierung kann man auch Dummy-GUIDs nutzen, solange Schema erfüllt ist.

Nachdem alle Daten im internen Modell den GAEB-Feldern zugeordnet sind, wird die XML-Datei geschrieben. Dabei läuft idealerweise eine Schema-Validierung entweder parallel oder anschließend (siehe Kap. 6). Technisch werden alle geöffneten Tags korrekt geschlossen, Sonderzeichen escaped und die Datei in UTF-8 gespeichert. GAEB DA XML 3.2 hat oft die Endung .x83, .x84 etc. je nach Phase – der Konverter sollte also den Dateinamen entsprechend wählen (z.B. "Ausschreibung_XYZ.x83").

Viele Konverter nutzen fertige GAEB-Bibliotheken im Hintergrund, um diesen Prozess zu vereinfachen. So gibt es z.B. .NET-Klassenbibliotheken, die GAEB-Dateien schreiben können, indem man Objekte befüllt und die Library das XML erzeugt. Ein Beispiel ist die GAEB & AVA .NET Library – hier könnte man im Code ein TenderFile-Objekt erstellen, Positionslisten anhängen und die Bibliothek generiert die .x83-Datei automatisch GAEB-konform. Solche Bibliotheken berücksichtigen die Feinheiten des Schemas und sparen Entwicklungszeit.

• Parser: Liest das Input-Dokument (Word/Excel/PDF->Text) und erzeugt eine rohe Liste von Elementen (Strings).

• Struktur-Interpreter: Wandelt die Liste in eine hierarchische Struktur um (Leistungsverzeichnis mit Titeln/Positionen), füllt dabei ein internes LV-Datenmodell.

• Mapper: Mapt die Felder des LV-Datenmodells auf GAEB-spezifische Felder, ergänzt Metadaten.

• Generator: Schreibt das GAEB XML mittels Schema.

Während dieser Pipeline sind einige Qualitätssicherungen schon integriert, z.B. prüft der Mapper, ob erforderliche Angaben vorhanden sind, und der Generator wirft Fehlermeldungen, wenn etwas wesentliches fehlt (z.B. keine <ItemNumber> in einer Position). Professionelle Konverter integrieren an dieser Stelle bereits einen GAEB-Konformitätstest. So hat der GAEB-Konverter von T&T einen Eingabeassistenten, der Pflichtfelder gelb markiert und den Nutzer zwingt, diese zu füllen, bevor die GAEB-Datei erstellt wird. Fehlende Eingaben (z.B. keine Einheit bei einer Position) werden angemahnt. Zudem läuft beim Speichern ein GAEB-Tester, der die erzeugte Datei auf Standardkonformität prüft und etwaige Abweichungen protokolliert. Diese sofortige Validierung ist Teil des Erstellungsprozesses, um fehlerhafte GAEB-Dateien gar nicht erst in Umlauf zu bringen.

Datenmodellierung im FM-Kontext: Bei Konvertierungen speziell für Facility Management Leistungen könnten einige Besonderheiten im Datenmodell beachtet werden. Beispielsweise haben FM-Leistungen manchmal Leistungszeiträume (z.B. "monatlich", "jährlich") – solche Angaben finden in GAEB als Teil der Positionsbeschreibung Platz, da es kein eigenes Feld dafür gibt. Ebenso gibt es oft Pauschalpositionen (keine Menge, sondern "pauschal 1 Stk") – der Konverter würde hier Menge=1, Einheit=Psch (Pauschale) setzen und den Langtext ggf. mit "für die Dauer von...". Solche Interpretationen sollten konsistent erfolgen. Falls im FM-Vertrag Vergütung z.B. nach Aufwand (Stundensätze) vereinbart wird, könnte man das als eigene LV-Position "Mehrstunden" anlegen mit Einheit "Stunden" – all dies kann in der Modellierung berücksichtigt werden, wenn es aus dem Ursprungsdokument hervorgeht.

Nach Durchlaufen aller Schritte liegt schließlich eine GAEB-XML-Datei vor, die den Inhalt des ursprünglichen Dokuments in strukturierter, maschinenlesbarer Form abbildet.

Die Qualität der GAEB-Datei ist entscheidend für ihre Akzeptanz in AVA-Programmen und die rechtliche Verwendbarkeit (insbesondere bei Vergaben).

• Syntaktische Validierung (Schema-Validität): GAEB DA XML 3.2 definiert XML-Schemata (*.xsd) für jede Austauschphase. Eine grundsätzliche Anforderung ist, dass die erzeugte XML-Datei dieses Schema einhält. Das bedeutet z.B., dass alle erforderlichen Elemente vorhanden sind, die Datentypen stimmen (Zahlenfelder korrekt als Zahl formatiert, Datumsfelder im ISO-Format etc.) und die Hierarchie den Vorgaben entspricht. Viele Konverter integrieren einen Schema-Check automatisch. Falls man selbst ein Skript schreibt, sollte man am Ende die Datei gegen das offizielle XSD prüfen (es ist Teil der GAEB-Dokumentation, erhältlich über Beuth Verlag als PAS 1067, aber auch oft bei BVBS oder GAEB-Toolbox verfügbar). Tools wie xmllint oder .NET-System.Xml können ein XML gegen ein XSD validieren. Bei Fehlern erhält man z.B. Meldungen wie "Element 'ItemNumber' fehlt" oder "Wert 'xyz' ist für Element 'Quantity' ungültig". Diese Fehler sind strikt zu beheben, da sonst viele AVA-Programme die Datei ablehnen. Beispiel: GAEB X83 erwartet zwingend ein <ExchangePhase> Element mit Code "83" – fehlt das oder ist falsch, schlägt Import fehl.

• GAEB-Regel-Check (Inhaltliche Konformität): Über das Schema hinaus gibt es Konventionen, die nicht maschinell im Schema kodiert sind, aber für reibungslosen Datenaustausch eingehalten werden sollen. Hier kommt der GAEB-Checker ins Spiel, den der GAEB auf seiner Website bereitstellt. Dieser prüft eine GAEB-Datei auf Konformität mit den GAEB-Regeln und gibt ein Protokoll aus, in dem Befunde als Fehler, Warnungen oder Hinweise klassifiziert werden. Fehler wären z.B.: doppelte Positionsnummern, ungültige Einheitenbezeichnungen, unzulässige Hierarchietiefe, fehlende Summen bei bestimmten Kontierungsarten etc. Warnungen könnten sein: sehr lange Texte ohne Gliederung, ungewöhnliche Zeichen. Hinweise evtl.: "Kein LV-Preis angelegt" – je nach Phase. Ein konkretes Beispiel: Der GAEB-Tester könnte bemängeln, wenn in einer X84 Angebotsdatei kein Angebotsendbetrag angegeben ist (manche AVAs erwarten diesen an bestimmter Stelle, auch wenn er berechenbar ist). Oder eine Warnung wäre, wenn die Datei zwar Schema-valid ist, aber z.B. Positions-IDs nicht durchgängig sind.

• Der T&T GAEB-Konverter enthält einen solchen Prüfer direkt integriert: Beim Einlesen und nach Erstellung einer GAEB-Datei wird diese GAEB-Konformitätsprüfung durchgeführt und ein Protokoll mit Fehlern, Warnungen und Hinweisen angezeigt. Der Anwender kann dann direkt sehen, ob etwa noch Pflichtfelder fehlen (Fehler) oder ob etwas Unübliches vorliegt (Hinweis). Dieses Vorgehen ist sehr empfehlenswert, um Qualität zu sichern. Falls man einen eigenen Prozess hat, kann man ersatzweise die erzeugte Datei testweise in einem GAEB-Viewer oder einer AVA-Software öffnen – viele Programme melden dann Abweichungen. Die BVBS (Bundesverband Bausoftware) hat auch Zertifizierungskriterien veröffentlicht, inklusive Musterdateien, um Implementierungen zu testen. Daran kann man sich orientieren.

• Manuelle inhaltliche Prüfung: Trotz aller Automatik sollte eine fachkundige Person die konvertierte GAEB-Datei manuell durchsehen oder in einem Viewer kontrollieren. Dabei wird geprüft, ob die Inhalte korrekt übertragen wurden: - Stimmen die Anzahl der Positionen und Titel mit dem Ursprungsdokument überein? - Sind die Texte vollständig und sinngemäß? (Kein Verlust von Sätzen, Umlaute korrekt, Sonderzeichen etc.) - Wurden Mengeneinheiten richtig interpretiert (z.B. falls "Std." in Word war, ist im GAEB "h" oder "Stunden" angekommen?) - Wurden alle Positionen, die Preise haben sollten, auch entsprechend markiert (z.B. keine ungewollte Null-Preis-Position, wenn es eine Pauschale sein sollte)? - Falls Alternativangebote oder Eventualpositionen im Text waren: Sind diese im GAEB durch die vorgesehenen Mechanismen (Kennzeichen oder separate Phasen wie X85) abgebildet?

Gerade im FM könnten bestimmte Vertragsklauseln oder Hinweise im Ursprungstext gewesen sein, die im GAEB-LV keinen Platz haben. Solche sollten nicht "verschwinden". Beispielsweise enthalten FM-Leistungsverzeichnisse manchmal allgemeine Beschreibungstexte am Anfang eines Kapitels. GAEB kennt dafür die LV-Vorbemerkungen (Kopftexts) und Titel-Vorbemerkungen. Man sollte prüfen, dass der Konverter solche allgemeinen Texte als entsprechende GAEB-Texte (z.B. <Description> im Knoten vor erster Position) abgelegt hat. Ein Indiz ist, wenn in der GAEB-Datei am Anfang ein großer Block "Allg. Bedingungen" auftaucht – dann ist das korrekt.

• Testimport in Zielsysteme: Eine praktische Validierungsmethode ist, die GAEB-Datei in den Ziel-AVA-Programmen oder FM-Systemen tatsächlich zu importieren. Wenn die Datei dort ohne Fehler importiert wird und alle Inhalte an der richtigen Stelle erscheinen, ist das ein guter Beleg für die erfolgreiche Konvertierung. Unterschiedliche AVA-Programme haben teils leicht unterschiedliche Toleranzen. Einige sind robust und füllen Fehlendes implizit, andere sind streng und brechen ab. Beispiel: Manche älteren AVA-Programme verlangen bei GAEB 3.2 immer noch eine Projektnummer im Kurztext – fehlt die, gibt’s eine Warnung. Durch Tests mit z.B. ORCA AVA, RIB iTWO, California, SIDOUN, etc., kann man sicherstellen, dass die generierte Datei allgemein verträglich ist.

• Fehlerkorrektur und Iteration: Findet man Fehler oder Warnungen, muss der Konverter entsprechend nachjustiert werden. Wenn z.B. die GAEB-Checker-Meldung "Unzulässige Ordnungszahl an Position 7" kommt, war vielleicht ein Gliederungspunkt doppelt. Dann muss man im Datenmodell nachbessern (Positionsnummern neu vergeben). Oder wenn "Einheit 'Monat' nicht im Katalog" erscheint, könnte man erwägen, statt "Monat" die offizielle Einheit "mo" zu verwenden oder sie in einer X400-Katalogphase zu definieren – letzteres ist allerdings aufwendig, ersteres pragmatisch.

In diesem Zusammenhang ist hilfreich, dass Tools wie der GAEB-Konverter Fehlermeldungen gewichtet ausgeben. Kritische Fehler müssen behoben werden, Warnungen kann man eventuell tolerieren, aber in einem professionellen Umfeld sollte man auch Warnungen minimieren. Beispielsweise könnte eine Warnung lauten: "Langtext länger als 255 Zeichen, GAEB 90 Kompatibilität nicht gegeben". Wenn man nur GAEB XML 3.2 nutzt, kann man das ignorieren; aber wenn man mit Bietern rechnet, die evtl. noch GAEB 90 verwenden, wäre es ein Hinweis, die Texte zu kürzen oder aufzuteilen.

Ein oft übersehener Aspekt ist die Vergabe- und Vertragsordnung. GAEB selbst garantiert eine korrekte Struktur, aber die Vergaberegeln (z.B. VOB/B) verlangen z.B., dass keine „unvollständigen Positionen“ existieren. Bei der Konvertierung sollte darauf geachtet werden, dass keine Position ohne Menge/EInheit rausgeht, da dies sonst in einem Vergabeverfahren angreifbar wäre. Auch müssen Eventualpositionen klar gekennzeichnet sein. Solche Dinge kann ein Konverter schwer automatisch sicherstellen, daher ist hier die Expertise des Fachanwenders gefragt.

Zusammenarbeit mit GAEB-Zertifizierung: Sollte die entwickelte Konvertierungslösung häufiger eingesetzt werden (etwa eine unternehmensinterne Software), kann es sinnvoll sein, eine offizielle GAEB-Zertifizierung (durch BVBS) anzustreben. Dabei muss die Software definierte Testfälle korrekt einlesen und ausgeben können. Für unsere Fragestellung (Konvertierung Office->GAEB) wäre die Ausgabe im GAEB-Format im Fokus. Die Zertifizierung stellt sicher, dass man z.B. alle Pflichtfelder beachtet und bestimmte Sonderfälle abdeckt. Zwar ist das nicht zwingend vorgeschrieben, erhöht aber die Vertrauenswürdigkeit der Lösung.

Eine gründliche Prüfung der erzeugten GAEB-Datei ist unabdingbar. Mit automatisierten Schema-Validierungen, GAEB-Regel-Checks und Testimporten lässt sich die technische Richtigkeit sicherstellen. Zusätzlich sollte eine inhaltliche Kontrolle durch FM-Fachleute erfolgen, um die sachliche Korrektheit und Vollständigkeit der Leistungsbeschreibung zu gewährleisten. Erst wenn beides – Technik und Inhalt – stimmen, gilt die Konvertierung als erfolgreich. Im nächsten Kapitel betrachten wir die Perspektive der AVA-Programme, für die diese GAEB-Dateien erzeugt wurden: Welche Anforderungen und Funktionen haben solche Programme, und wie spielen sie mit den GAEB-Daten zusammen?

AVA-Programme (Ausschreibungs-, Vergabe- und Abrechnungssoftware) sind spezialisierte Anwendungen, die Bau- und FM-Ausschreibungen verwalten. Bekannte Vertreter in Deutschland sind z.B. RIB iTWO, ORCA AVA, California.pro (G&W), SIDOUN Globe, ARRIBA (heute RIB iTWO), AVAPLAN, und im FM-Bereich z.B. auch Module großer ERP-Systeme (SAP) oder CAFM-Software mit Vergabemodulen.

• GAEB-Schnittstelle als Grundfunktion: Nahezu alle AVA-Programme unterstützen den Import und Export von GAEB-Dateien (GAEB 90, 2000, XML). Dies ist essentiell, um Daten mit anderen auszutauschen. Die GAEB-Schnittstelle wird meist vom Hersteller implementiert und teilweise von BVBS zertifiziert. Für den Import erwarten die Programme korrekte GAEB-Dateien – daher die Bedeutung der vorangehenden Validierung. Typischerweise kann der Nutzer in der AVA-Software eine GAEB-Datei öffnen oder in ein bestehendes Projekt importieren. Das Programm prüft dann den Inhalt und fügt die Positionen in die interne Datenbank ein. Einige Programme sind dabei fehlertolerant (korrigieren z.B. falsche Kodierungen automatisch), andere nicht.

• Für den Export erstellen AVA-Programme GAEB-Dateien, um sie an Bieter (als X83) oder an Auftragnehmer (als X86) weiterzugeben. Unsere Konvertierungslösung muss also kompatibel sein: Die vom Konverter erzeugte X83-Datei sollte im AVA-Programm so einlesbar sein, als hätte sie das Programm selbst erstellt. Gleiches gilt für X84: Angebote von Bietern, die ggf. in Excel erstellt und über Konverter in GAEB rücküberführt wurden, sollen im AVA der Vergabestelle eingelesen werden können, um Preisvergleiche (Preisspiegel) zu erzeugen.

• Datenumfang und Detailtiefe: AVA-Programme verwalten nicht nur die reinen LV-Daten, sondern auch zusätzliche Informationen. Dazu gehören z.B. Bieter- bzw. Anbieterinformationen, Vergabeeinheiten, Zuschlagskriterien, Vertragstexte usw. GAEB-Dateien transportieren davon nur einen Teil (hauptsächlich das Leistungsverzeichnis und evtl. Vertragsbedingungen im Langtext). Einige AVA-Systeme haben proprietäre Felder, die in GAEB nicht abbildbar sind. Beispielsweise kann ein AVA-Programm eine Spalte "Kostengruppe (DIN 276)" pro Position führen – GAEB 3.2 hat zwar ein Feld für Kostengruppe, aber wenn das nicht gefüllt wurde, geht die Info verloren. Oder AVAs für FM könnten Wartungspläne mitperiodischen Terminen kennen, die im GAEB-LV nicht enthalten sind. Das heißt, die GAEB-Schnittstelle bildet immer nur einen Ausschnitt der gesamten Daten ab, was dem Standard entspricht (LV, Mengen, Preise, Texte). Unsere Konvertierung sollte sich daher auf diesen Kern konzentrieren. Falls zusätzliche FM-spezifische Daten übergeben werden müssen, braucht es entweder separate Dateien oder man nutzt Freitext in GAEB (z.B. Bemerkungen), was aber unsauber ist.

• Leistungsfähige LV-Bearbeitung und Import-Optionen: Typische Funktionen eines AVA-Programms sind das Bearbeiten von LVs (Positionen hinzufügen, ändern, gliedern), das Durchführen von Preisvergleichen (Preisspiegel), die Angebotswertung und die Erstellung von Auftrags-LVs und Nachträgen. Im Kontext GAEB bedeutet das: ein AVA-Programm kann eine GAEB X83 importieren, dann dort Preise erfassen (oder Angebote einlesen als X84) und schließlich via GAEB X84P einen Preisspiegel exportieren oder den Auftrag via X86 erstellen. Für uns interessant: Importoptionen. Einige Programme bieten beim Import an, z.B. ob Langtexte importiert werden sollen oder nur Kurztexte (um die Übersicht zu wahren). Andere erlauben, Teil-LVs auszuwählen oder Positionen zu filtern. Das heißt, sie sind flexibel gegenüber dem GAEB-Inhalt. Ein robustes AVA-Programm sollte die GAEB-Datei, die wir liefern, ohne viel Nachfragen schlucken und korrekt abbilden. Sollte es doch Abweichungen geben (z.B. ein unbekanntes Einheitensymbol), bieten manche Programme Mapping-Dialoge ("Unbekannte Einheit 'Mon' -> bitte zuordnen zu 'Monat'").

• Für FM-Anwendungen, die GAEB importieren (z.B. PROMOS für SAP), gibt es z.T. spezielle Parser-Komponenten wie wingaebXML. Dieser Parser bereinigt "unsaubere" GAEB-Dateien im Hintergrund, bevor die Daten ins SAP übertragen werden. Das zeigt, dass in der Praxis nicht alle GAEB-Dateien perfekt sind; Softwarehersteller fangen solche Fälle ab. Unser Konverter sollte dennoch den Anspruch haben, möglichst "saubere" Dateien zu erzeugen, damit externe Parser nicht viel korrigieren müssen.

• Schnittstellen zu anderen Formaten: Neben GAEB unterstützen AVA-Programme oft weitere Schnittstellen: z.B. ÖNORM (in Österreich), Excel/CSV-Exporte, und seit neuem die XRechnung (für elektronische Rechnungen, z.T. aus GAEB X89 generierbar). Zwar tangiert das unser Thema nur am Rande, aber z.B. könnte ein AVA-Programm direkt eine Excel ausschütten. Die Software GAEB-Online 2025 erlaubt es etwa, eine GAEB-Ausschreibung mit einem Klick in Word oder Excel zu überführen. Solche Funktionen sind für uns eher Konkurrenz zur Konverter-Lösung, aber sie zeigen: AVA-Hersteller wissen um die Bedürfnisse, GAEB und Office zu verbinden. Unsere Konvertierungslösung füllt hier eine Lücke, wenn die AVA-Software des Auftraggebers keine direkte Office-Übernahme bietet.

• Leistungsfähige Preisspiegel und Angebotsmanagement: Ein Aspekt im FM: Es geht nicht nur um Bauleistungen, sondern Serviceverträge. Hierbei sind manchmal Zuschlagskriterien komplex (Qualität, Zuverlässigkeit etc.). GAEB-Dateien transportieren zwar hauptsächlich Preise, aber manche AVA-Programme erlauben Noten oder Bewertungen je Position. Solches passt nicht in GAEB. Allerdings kann GAEB zumindest verschiedene Angebote positionenweise nebeneinanderstellen, was Preisspiegel-Tools tun. GEFMA 520 z.B. bietet ein Excel für Preisspiegel. Ein AVA-Programm würde stattdessen GAEB X84 von allen Bietern einlesen und intern einen Preisspiegel generieren, der dann exportiert werden kann. Die Funktion der GAEB X84P (Preisspiegelphase) ist noch nicht in allen Programmen umgesetzt, da sie erst mit GAEB 3.2 kam. Manche AVAs bleiben bei internen Auswertungen und ermöglichen ggf. nur den Export als Excel oder PDF.

• Abrechnung und Aufmaß: Im Bau-AVA ist die Abrechnung (auf Grundlage von Aufmaßen, Nachträgen) Teil des Prozesses – GAEB bietet dafür X31 (Aufmaße), X89 (Rechnung). Im FM-Kontext könnten z.B. Leistungen nach Aufwand abgerechnet werden, wo periodisch eine Aufstellung erfasst wird (z.B. tatsächlich geleistete Stunden). Wenn unser Konverter z.B. einen Rahmenvertrag als GAEB X86 erstellt, könnten FM-Dienstleister später Aufmaße als GAEB X31 liefern, falls die Software das unterstützt. Einige AVA/CAFM-Kombinationen (z.B. eine CAFM-Software plus GAEB-Schnittstelle) könnten so die Leistungserfüllung tracken. Für uns heißt das: Die konvertierten Daten sollten die Basis dafür legen – z.B. jede Position so granular definieren, dass eine Abrechnung pro Position möglich ist.

• Benutzerfreundlichkeit und Fehlerbehandlung: Aus der Sicht des AVA-Anwenders ist es wichtig, dass beim Arbeiten mit GAEB möglichst keine Fehler auftreten, die aus Konvertierungsartefakten stammen. Zum Beispiel, falls unsere GAEB-Datei ungewöhnliche Struktur hat (z.B. unnötige tiefe Verschachtelung), könnte dies die Benutzerfreundlichkeit im AVA beeinflussen (z.B. werden zu viele Titel-Ebenen angezeigt). Oder wenn der Konverter jede Zeile des Word-Dokuments als eigene Position interpretiert hätte, könnte das LV unnatürlich aufgebläht wirken. Daher ist es ein Qualitätsmerkmal, wenn AVA-Anwender die importierte GAEB-Datei als ganz normales, manuell erstelltes LV wahrnehmen.

• Zudem verlangen manche AVA-Programme nach dem Import eine manuelle Kontrolle – etwa zeigen sie ein Importprotokoll mit Hinweisen. Der zuständige Sachbearbeiter sollte darin im besten Fall keine kritischen Punkte finden. Typische Meldungen könnten sein: "Hinweis: Langtext in Position 3 gekürzt" oder "Warnung: Unbekannter Textbaustein ignoriert". Durch geschickte Konvertierung (keine zu langen Texte für GAEB 90, keine exotischen Elemente) kann man solche Meldungen minimieren.

• Integration in FM-Prozesse: Zuletzt ist die Rolle von AVA im FM zu beleuchten: In vielen Fällen nutzen FM-Abteilungen keine separate AVA-Software wie in Bauprojekten, sondern fügen Ausschreibungen und Verträge direkt in ERP/CAFM-Systeme ein. Hier kommen dann Module ins Spiel (wie das SAP PROMOS GAEB-Interface). Diese Schnittstellen sind von der Funktionsweise ähnlich: GAEB rein, Daten in interne Strukturen überführen. Aber sie sind oft strenger begrenzt auf bestimmte Phasen (SAP z.B. fokussiert auf X81, X84, X86 laut PROMOS). Auch lassen solche Integrationen u.U. nicht alle GAEB-Felder zu – z.B. ignoriert SAP vielleicht Bieter-Zusatztexte, da sie für Bestellanforderungen irrelevant sind. Das bedeutet, unsere Konvertierung generiert evtl. Daten, die gar nicht alle importiert werden. Das ist per se nicht schlimm, aber man sollte wichtige Inhalte nicht in Felder stecken, die später unter den Tisch fallen. Konkret: Wenn es besondere Hinweise gab, die wir in GAEB als Bietertext eingefügt haben, werden diese beim Import nach SAP ggf. verworfen. Besser wäre es, solche wichtigen Infos als regulären Langtext einer Position zu codieren, denn das wird auf jeden Fall übernommen.

• Insgesamt können wir festhalten: AVA-Systeme erwarten standardkonforme, gut strukturierte GAEB-Dateien und nutzen diese, um den Ausschreibungsprozess effizient abzuwickeln. Unser Konverter muss daher GAEB-Dateien liefern, die diesen Erwartungen entsprechen – d.h. vollständige LV-Struktur, konsistente Daten, keine Schemafehler. Da AVA-Programme das Rückgrat des digitalen Vergabeprozesses sind, dient die Konvertierung letztlich dazu, den Medienbruch zwischen Office-Dokument und AVA-Software zu überbrücken. In der Praxis bedeutet das Zeit- und Kosteneinsparung: Anstatt ein per Word erstelltes LV im AVA mühsam abzutippen, kann es per Konverter eingelesen werden. Alle Beteiligten sparen sich Doppelerfassungen und mögliche Fehler dabei. Dieses Zusammenspiel zwischen Konvertern und AVA-Schnittstellen ist Thema des nächsten Kapitels, in dem wir konkrete Konverter-Lösungen – ob als eigenständige Tools oder Middleware – und ihre Einsatzmöglichkeiten betrachten.

Für die Konvertierung von Office- und PDF-Daten in GAEB existiert bereits eine Reihe von Softwaretools und Bibliotheken. Diese können entweder als Standalone-Konverter arbeiten (Anwender lädt eine Datei und bekommt eine GAEB-Datei zurück) oder als Middleware-Komponenten in bestehende Systeme integriert werden (z.B. als Plugin für CAFM-Software oder als Webservice).

• Die T&T Datentechnik GmbH mit ihrem Produkt GAEB-Konverter (früher auch als GAEB-Tool bekannt). Dieses Softwarepaket bietet über 20 Module für verschiedenste Konvertierungen an. Es unterstützt den Im- und Export zwischen GAEB (90, 2000, XML) und zahlreichen Formaten: Excel, Word, Access, dBASE, DataNorm, UGL sowie dem österreichischen ÖNORM-Format. Für unser Thema relevant sind insbesondere die Module Text-Import Word und der Excel-Import. Der GAEB-Konverter von T&T zeichnet sich dadurch aus, dass er GAEB-konforme LVs erstellen und bearbeiten kann und den Nutzer durch Assistenten und Prüfungen anleitet. Er kann also nicht nur konvertieren, sondern fungiert auch als einfacher LV-Editor. Für Handwerksbetriebe oder kleinere FM-Dienstleister ist dies interessant, da sie so ohne großes AVA-System GAEB-Dateien bearbeiten können. T&T bietet auch einen GAEB-Viewer an sowie Schulungen und sogar Dienstleistungen, falls Anwender die Konvertierung nicht selbst durchführen möchten. Lizenztechnisch ist der GAEB-Konverter modular aufgebaut (Module einzeln erwerbbar, z.B. Word-Import begrenzt auf 25 Dateien, unlimitiert). Im FM-Bereich dürfte diese Investition sich schnell lohnen, wenn regelmäßig Ausschreibungen konvertiert werden müssen.

• MWM (Mittweidaer Software- und Messtechnik) bietet mit MWM-Primo ebenfalls ein GAEB-Konverter-Tool an. MWM-Primo fokussiert zwar primär auf Aufmaß und Abrechnung, beinhaltet aber auch eine GAEB-Schnittstelle. Laut Hersteller kann es Excel in GAEB umwandeln und umgekehrt, sowie PDF nach vorheriger OCR in GAEB konvertieren. MWM-Produkte sind eher im Bauhauptgewerbe bekannt (Aufmaßerstellung), aber FM-Betriebe könnten sie ebenfalls einsetzen. Die genaue Funktionsweise ähnelt wahrscheinlich dem T&T-Ansatz: Der Nutzer muss bei PDF erst OCR machen etc..

Daneben gibt es noch GAEB-Online (von , Entwickler: Volker Schindowski). GAEB-Online ist eigentlich ein kostengünstiges LV-Programm zum Bearbeiten von GAEB-Dateien mit Excel-Integration. Die Version GAEB-Online 2025 unterstützt GAEB DA XML 3.3 und kann Daten aus Excel/OpenOffice in GAEB konvertieren. GAEB-Online hat ein Alleinstellungsmerkmal: es integriert Excel und Word für die Bearbeitung. D.h. man kann aus GAEB-Online heraus ein geöffnetes LV direkt nach Word exportieren, dort ändern, und wieder importieren. Das Programm richtet sich v.a. an Handwerker oder kleine Planer, die kein großes AVA möchten. Im FM könnte es z.B. ein Dienstleister nutzen, der eine GAEB-Ausschreibung erhält, sie mit Excel verpreist und wieder zurückgibt. Als Konverter im engeren Sinne (beliebige Word->GAEB Konvertierung) ist GAEB-Online weniger flexibel als T&T, weil es keine komplexen Parser mit Makros bietet, sondern vom Nutzer strukturierte Excel erwartet.

• Die wingaebXML-Komponente wurde schon erwähnt: Sie ist ein Parser, der GAEB-Dateien einlesen und "säubern" kann, entwickelt von einer Firma WINGAEV (vermutlich im Auftrag von Behörden). PROMOS nutzt diese als Teil der SAP-GAEB Schnittstelle. Für uns interessant: wingaebXML dürfte proprietär sein und wahrscheinlich nicht frei verfügbar, aber es zeigt, dass Unternehmen bereit sind, Konverter-Module zuzukaufen, um GAEB-Funktionalität in eigene Lösungen zu integrieren.

• Dangl IT bietet moderne Lösungen an: Zum einen einen kostenlosen Online-Konverter (WebGAEB), zum anderen die AVACloud-Webservice und die Dangl.AVA .NET Library. WebGAEB ist ein Webportal, wo man GAEB hochladen und nach Excel wandeln kann und umgekehrt – geeignet etwa für Gelegenheitsnutzer, die kein Programm installieren wollen. Die AVACloud ist ein SaaS-Dienst, der eine API bereitstellt, mit der Entwickler GAEB-Funktionen in eigene Anwendungen integrieren können (z.B. eine eigene FM-Plattform könnte per API ein Word-Dokument schicken und ein GAEB erhalten, sofern man die Logik trainiert hat – allerdings ist AVACloud eher GAEB<->GAEB/Excel ausgerichtet). Die Dangl .NET Library schließlich erlaubt das programmgesteuerte Lesen und Schreiben aller GAEB-Formate in .NET-Umgebungen. Sie ist als NuGet-Paket verfügbar und plattformunabhängig. Allerdings ist sie keine Freeware – man muss eine Lizenz erwerben oder Kontakt aufnehmen. Für den Open-Source-Kontext interessant: Dangl stellt viele Beispiele auf GitHub bereit, z.B. eine avacloud-demo-python, wo mittels der AVACloud-API GAEB-Files in Python konvertiert werden. So etwas könnte findige Entwickler in FM dazu nutzen, eigene Skripte zu schreiben.

• GAEB-Toolbox und GAEBlib: Es gibt kleinere Projekte und Sammlungen (z.B. GAEBToolbox vom BRZ oder open source Ideen wie "GAEB4Linux"). Diese sind jedoch entweder nicht voll ausgereift oder inhouse. GAEB4Linux deutet an, dass es Bestrebungen gibt, plattformunabhängige Viewer/Editoren zu bauen. Für FM-IT-Abteilungen könnte es eine Option sein, auf Basis von GAEB-XML und existierenden XML-Bibliotheken eigene Converter zu schreiben, gerade weil GAEB XML im Vergleich zu GAEB90 nicht mehr geheimnisvoll ist (GAEB90 erfordert Kenntnis der 80-Zeichen-Sätze, GAEB XML ist mit Schema selbsterklärend). Dennoch erfordert die Interpretation der Texte (gerade aus Word) einiges an Domänenwissen, weshalb eigenentwickelte Konverter meist in einer Abteilung "hängen bleiben" und nicht allgemein veröffentlicht werden.

Reine Open-Source-Lösungen für GAEB-Konvertierung sind rar. Das liegt einerseits daran, dass GAEB in den letzten Jahrzehnten v.a. von kommerzieller Bausoftware getrieben war und die Spezifikation (PAS 1067) nicht kostenlos ist. Andererseits ist die Zielgruppe begrenzt. Es gibt jedoch quelloffene XML-Parser, mit denen man GAEB-Dateien verarbeiten kann (z.B. Python's lxml für generisches XML und dann XPaths gemäß GAEB-Schema). Auch OCR (für PDF) kann mit Open-Source (Tesseract) gelöst werden. Theoretisch könnte man eine Pipeline aus Open-Source-Komponenten aufbauen: Python script with python-docx (Word lesen), pandas (Excel lesen), Tesseract (OCR), then generate XML via an open GAEB XSD (with an open-source XML library). Einzelne haben solche Ansätze im Netz diskutiert, aber eine fertig nutzbare Software ist uns nicht bekannt.

Praktisch gesehen greifen die meisten Anwender auf bewährte kommerzielle Tools zurück, weil diese den Support und das Regelwissen mitbringen. Beispielsweise in [IT-Management.today] wird explizit der T&T GAEB-Konverter als hilfreiches Tool genannt, und es wird seine Funktionsvielfalt beschrieben. Ebenso gibt es Blogbeiträge von Ninox oder Kinisto, die KMUs empfehlen, bei GAEB-Konvertierungen auf vorhandene Tools zu setzen.

Middleware-Konverter könnten in FM-Unternehmen Anwendung finden, indem sie in bestehende Software integriert werden. Z.B. ein CAFM-System, das Wartungsverträge ausschreibt, könnte im Hintergrund die Dangl-Library nutzen, um dem Nutzer auf Knopfdruck ein GAEB-LV zu generieren, das er dann an Dienstleister verschickt. Oder ein SharePoint-Workflow könnte eingehende Word-Ausschreibungen automatisch nach GAEB umwandeln, damit sie in einem eVergabe-System weiterverarbeitet werden können. Solche Integrationen erfordern Entwicklungsarbeit, sind aber durch modernere Angebote (WebAPI von AVACloud) deutlich einfacher geworden – man muss kein GAEB-Experte sein, um den Webservice zu nutzen.

In diesem Abschnitt betrachten wir einige praktische Szenarien, in denen die Konvertierung von Word/Excel/PDF nach GAEB Anwendung findet. Anhand dieser Beispiele werden typische Herausforderungen illustriert, und wir leiten Empfehlungen für die Praxis ab.

Eine kommunale Vergabestelle plant die Gebäudereinigung für mehrere Liegenschaften neu zu vergeben. Die Fachabteilung Facility Management erstellt dafür eine Leistungsbeschreibung in Word, da intern kein AVA-System vorhanden ist. Dieses Word-Dokument umfasst mehrere Kapitel (Gliederung nach Objekten oder Leistungsarten), detaillierte Reinigungspositionen mit Häufigkeiten und Leistungsumfang, sowie ein Leistungsverzeichnis-Formblatt in Tabellenform für Angebotsangaben. Nun soll die Ausschreibung digital veröffentlicht werden. Die Vergabestelle nutzt eine eVergabe-Plattform, die GAEB X83 Dateien akzeptiert und an Bieter weiterleitet. Die Herausforderung: Aus dem komplex formatierten Word (Mischung aus Fließtext und Tabellen) eine GAEB-Datei zu erzeugen, die alle relevanten Infos enthält.

- Das Word-Dokument hat sowohl Fließtext (Beschreibung der Qualitätsstandards, Turnus etc.) als auch Tabellen (die Räume mit m² und Reinigungshäufigkeit). Ein Konverter muss diese kombinierte Struktur verarbeiten. Vermutlich wird man es zweiteilen: Die Fließtexte kommen als Vorbemerkungen ins GAEB (Kopf- oder Titeltexte), die tabellarischen Leistungsaufstellungen werden zu GAEB-Positionen (z.B. "Unterhaltsreinigung Raum X, Fläche Y m², Frequenz Wöchentlich" – als Position mit Menge = Anzahl der Durchführungen pro Jahr). - Wenn das Word sehr unstrukturiert war, muss evtl. manuell nachgeholfen werden. Vielleicht entschließt man sich, das Dokument in Excel zu zerlegen (gerade die Raumlisten). Hier sieht man, dass manchmal ein Zwischenschritt nötig ist: Word -> Excel -> GAEB, um Tabellen sauber zu importieren. - Ein Problem könnten die vielen unterschiedlichen Positionen sein: Bieter sollen evtl. Preise pro m² pro Reinigungsart angeben. Die GAEB-Struktur muss das klar trennen. Der Konverter muss eventuell Positionstexte generieren, die aus mehreren Zellen des Word/Excel zusammengesetzt sind (z.B. Raumtyp + Turnus + Fläche). - Nach Konvertierung sollte die Vergabestelle die GAEB in ihrem Viewer prüfen: Sind alle Gebäude und Räume als Positionen drin? Stimmen die Mengengerüste? Insbesondere ob die Hierarchie der Liegenschaften korrekt als Titel umgesetzt wurde (Gebäude A als Titel, darunter Räume als Positionen). - Durch die GAEB-Validierung könnten Dinge auffallen wie "Einheit 'pro m² und Jahr' unbekannt". Lösung: Aufteilen in "m²" als Einheit, Menge = Gesamtfläche*Anzahl Reinigungen (somit Preis pro Jahr). Solche inhaltlichen Adjustierungen sind knifflig – sie erfordern FM-Fachwissen und GAEB-Knowhow in Kombination. Empfehlung: Bei solchen komplexen LVs lieber Fachpersonal oder Dienstleister hinzuziehen, die beim Einrichten des Konverters unterstützen, um korrekte Umlagerechnung zu gestalten.

• Frühzeitige Planung der LV-Struktur: Schon bei der Erstellung in Word sollte eine Struktur angelegt werden, die der GAEB-Hierarchie entspricht (z.B. Überschriften für Gebäude/Etagen etc. verwenden, nicht alles in Fließtext).

• Testlauf mit kleinerem Ausschnitt: Vor der finalen Ausschreibung könnte man z.B. ein Gebäude exemplarisch konvertieren und prüfen. So erkennt man früh eventuelle Probleme (z.B. Tabellen, die nicht erkannt werden) und kann das Word-Dokument anpassen.

• Zusammenarbeit zwischen FM und Vergabestelle: Die Vergabestelle, falls mit GAEB vertraut, sollte Input geben, wie das Dokument gestaltet sein muss. Ggf. stellt sie eine Word-Vorlage bereit, die konvertierbar ist (viele Kommunen haben Word-Vorlagen mit bestimmten Formatvorlagen für Leistungspositionen).

Ein mittelständischer Reinigungsdienst erhält vom Kunden eine Ausschreibung als GAEB-X83-Datei für Facility Services (wie im Beispiel 1). Der Dienstleister hat jedoch kein eigenes AVA-Programm. Er möchte das Angebot in Excel kalkulieren, da er dort seine Kalkulationsformeln für Personalaufwand etc. hat. Hier kommt ein Konverter zum Einsatz: Er nutzt z.B. den Online-Konverter von Dangl oder GAEB-Online, um die X83 in Excel umzuwandeln. Dann trägt er in Excel seine Einheitspreise ein. Anschließend konvertiert er das Excel zurück in GAEB X84 und sendet diese an den Kunden.

• Excel-Export/Import muss 100% zuverlässig sein, damit keine Position vergessen wird. Zum Glück sind diese Konverterpfade etabliert; Tools markieren z.B. in Excel farblich die Zellen, wo Preise einzutragen sind, und schützen andere Bereiche. Dennoch muss der Dienstleister sorgfältig arbeiten, z.B. Formeln in Excel dürfen nicht die Strukturen zerstören.

• Eine Herausforderung kann sein, wenn der Dienstleister noch Änderungen am LV vornehmen will (z.B. er bemerkt Unklarheiten und will im Angebotstext etwas ergänzen). In Excel kann er zwar Texte ändern, aber muss aufpassen, Formatierung beizubehalten. Wenn er Zeilen einfügt, würde der Rückkonverter dies vielleicht als zusätzliche Position interpretieren, was problematisch ist. Empfehlung hier: Keine Strukturänderungen in Excel, nur Felder ausfüllen, und falls nötig, im Angebotsschreiben separate Nebenangebote oder Erläuterungen abgeben.

• Wenn der Dienstleister Alternativvorschläge hat (Nebenangebote), sollte er wissen, dass diese separat als X85 zu liefern wären. Ohne AVA ist das schwierig, aber T&T’s Konverter kann auch Nebenangebote erstellen (durch Markierung der entsprechenden Positionen als Variante). In Excel ist das nicht trivial. Evtl. muss er dafür mehrere Excel->GAEB Durchläufe machen (erst Hauptangebot, dann Alternativangebot in zweiter Datei). Hier zeigt sich eine Lücke: GAEB deckt zwar Nebenangebote ab, aber ohne spezialisierte Software ist es komplex. Empfehlung: In solchen Fällen kann man Alternativpositionen im gleichen LV als optional kennzeichnen (etwa im Langtext vermerken "Optionales Angebot"), anstatt eine formale X85 zu erstellen – dies muss aber der Auftraggeber zulassen. Alternativ doch ein GAEB-Experte hinzuziehen.

Dieses Beispiel zeigt, wie Konverter Bietern helfen, die kein AVA haben. Es verdeutlicht auch die Empfehlung: - Auftraggeber sollten den Bietern Hinweise geben, z.B. verweisen auf den kostenlosen WebGAEB-Konverter oder GAEB-Online-Testversion, damit diese die Tools nutzen können. Manche Ausschreibungen (speziell im FM, wo man weiß, dass Dienstleister nicht alle GAEB-affin sind) legen daher zusätzlich ein Excel-Formblatt bei – das ist jedoch redundant. Besser: GAEB plus ein Tipp zum Konverter. So fördern Auftraggeber die Digitalisierung auch bei den Auftragnehmern.

Ein Unternehmen hat ein großes Bauprojekt abgeschlossen. Die technischen Anlagen wurden über Bau-GAEB-LVs beschafft (z.B. Lüftungsanlage, Aufzüge). Nun übernimmt die FM-Abteilung die Betreuung. Sie möchte Wartungsverträge für diese Anlagen ausschreiben. Statt bei Null zu beginnen, nutzt sie die vorhandenen GAEB-Dateien aus der Bauausschreibung: Im LV "Aufzugsanlage" stehen z.B. Posten für Lieferung, Montage, Abnahme. Die FM-Abteilung identifiziert die wartungsrelevanten Teile (z.B. "Wartung Aufzug für 4 Jahre") und erstellt daraus ein neues LV. Mit einem GAEB-Konverter könnte sie z.B. das Bau-LV nach Excel exportieren, irrelevant Positionen löschen, stattdessen neue Wartungs-Positionen einfügen, und das Ergebnis wieder als GAEB X83 speichern. Alternativ liest sie das GAEB in eine Software wie GAEB-Online ein und bearbeitet es dort.

• Verstehen des ursprünglichen LVs: Bau-LVs sind anders strukturiert (nach VOB, oft mit STLB-Texten). Die FM-Abteilung muss die passenden Inhalte filtern. Das ist eher inhaltlich: Ein Konverter hilft da wenig, außer dass Excel-Export die Daten zugänglich macht.

• Neue Positionen erzeugen: Wenn die FM-Abteilung mit Excel arbeitet, fügt sie dort Zeilen ein, was der Konverter beim Rückimport handeln muss. T&T Makros könnten hilfreich sein, um am Ende die Excel wieder konsistent zu machen. Möglicherweise ist es besser, das GAEB in GAEB-Online oder einem einfachen AVA-Tool zu öffnen, neue Positionen hinzuzufügen (das geht komfortabler) und dann zu speichern. Hier sieht man: Konverter stoßen an Grenzen, wenn es um inhaltliche Neuerstellung geht; sie sind besser im 1:1 Überführen vorhandener Inhalte. Bei konzeptionellen Änderungen (Neues LV) sollte vielleicht doch kurz eine Person mit AVA-Software das LV erstellen. Aber unsere FM-Abteilung könnte GAEB-Online 2025 (günstig) nutzen und hat somit quasi ein AVA Light.

• Erhalt der Struktur und Normen: Wenn das Bau-LV nach STLB-Bau formuliert war, enthält es u.U. Katalogverweise oder Normpositionen. Beim Export nach Excel gehen diese verloren (man hat nur Klartext). Für die Wartung muss man eigene Texte schreiben – hier keine große Hürde, aber es bedeutet manuellen Input.

• Validierung des neuen LVs: Der entstandene GAEB X83 muss wieder geprüft werden. Wenn man per Excel was falsch zugeordnet hat, drohen Strukturfehler. Empfehlung: Lieber den GAEB-Konverter dafür nutzen statt reines Excel-Basteln, weil er auf GAEB-Konformität achtet (Pflichtfelder etc.). Wie im Zitat angemerkt, markiert z.B. der GAEB-Konverter Eingabefelder gelb und verhindert Speichern bei Verstößen. Das schützt die FM-Abteilung vor peinlichen GAEB-Fehlern.

GAEB-Daten aus Bauprojekten können im FM weiterverwendet werden.

• Datenübergabe Bau -> FM etablieren: Im Idealfall übergibt die Bauprojektleitung der FM-Abteilung nicht nur PDFs der Dokumentation, sondern auch die GAEB-LVs der wartungsrelevanten Gewerke. Das FM kann daraus leichter Leistungskataloge generieren.

• Schulung und Tools im FM bereitstellen: FM-Mitarbeiter sollten zumindest einen GAEB-Viewer oder einfachen Editor haben (GAEB-Online oder Viewer reicht), um GAEBs lesen zu können. So gehen Informationen nicht verloren und Konvertierungen sind intern möglich.

• Uneinheitliche Quelldokumente: Kein Word-Dokument gleicht dem anderen. Konverter stoßen auf unzählige Formatierungsvarianten. Daher braucht es flexible Tools und oft manuellen Aufwand. Empfehlung: Wo möglich, Standardisierung der Erstellung (Templates, Schulung der Ersteller).

• Sprachliche Unterschiede: GAEB 3.2 ist neutral was Sprache angeht, aber der Inhalt in FM-LVs kann anders formuliert sein als Bau-LVs. Z.B. Leistungsbeschreibungen im FM tendieren zu funktionalen Beschreibungen ("XY fachgerecht durchführen") statt detaillierten Materialvorgaben. Das ist ok, aber man sollte darauf achten, dass in GAEB-Positionen trotzdem greifbare Einheiten und Mengen angegeben werden (für Angebote). Empfehlung: FM-Ausschreibungen sollen zumindest quantifizierbare Leistungsgegenstände definieren (auch wenn es Dienstleistung ist, z.B. "1 Monat Betreuung", "12 Inspektionen").

• Große Positionsanzahl vs. Handhabbarkeit: GAEB kann tausende Positionen handhaben. Aber ein Word-Dokument mit tausenden Einträgen zu konvertieren erfordert Rechenzeit und Speicher. Konverter können bei sehr langen Dokumenten Performance-Probleme haben oder abstürzen. In solchen Fällen: Aufteilung des LVs in Sinnabschnitte (evtl. getrennte GAEB je Los/Leistungsbereich) könnte helfen. Zudem Tools nutzen, die dafür ausgelegt sind (64-bit Anwendungen).

• Revisionssicherheit und Nachvollziehbarkeit: Bei Vergaben muss man jederzeit begründen können, dass keine inhaltliche Änderung beim Konvertieren passiert ist (oder wenn doch, dokumentiert). Daher empfehlen wir, die originalen Dokumente aufzubewahren und die konvertierten GAEBs parallel vorzuhalten. Jede Änderung (manuelle Korrektur in der GAEB-Datei) sollte geloggt werden. Konverter selbst protokollieren z.T. was sie getan haben (z.B. "10 Positionen erkannt, 2 Warnungen: angepasst"). Dieses Protokoll sollte man dem Vergabevorgang beifügen, um transparent zu sein.

• Zukünftige Updates: GAEB 3.2 wird irgendwann von GAEB 3.3 abgelöst. Konverter sollten darauf vorbereitet sein. Einige Tools (GAEB-Online 2025, T&T) haben bereits angekündigt, GAEB 3.3 zu unterstützen bzw. tun es schon. Wenn wir heute eine Lösung einführen, sollte sie updatefähig sein. Sonst könnte in einigen Jahren ein Problem entstehen, falls Bieter z.B. nur noch GAEB 3.3 liefern, wir aber nur 3.2 lesen können. Glücklicherweise sind 3.2 und 3.3 relativ ähnlich; oft können 3.2-Programme 3.3 einlesen (wenn GUIDs ignoriert werden). Dennoch: Plan für Updates einbeziehen.

• Dokumentvorlagen standardisieren: Verwenden Sie für Word/Excel-Eingaben möglichst feste Vorlagen mit definierten Styles und Spalten. Teilen Sie diese auch Dienstleistern mit, falls sie Angebote zurückgeben sollen. Einheitliche Struktur = höhere Automatisierungsquote.

• Konverter sorgfältig auswählen und testen: Nicht jeder Konverter passt für jeden Anwendungsfall. Testen Sie Tools an realen Beispieldateien aus Ihrem FM-Bereich. Achten Sie auf Bedienbarkeit (braucht der Nutzer Programmierkenntnisse oder geht es mit wenigen Klicks?), auf Funktionsumfang (Word + Excel + PDF, oder nur eins davon?) und Support (gerade bei kommerziellen Tools wichtig).

• Schulung der Anwender: Die besten Tools nützen wenig, wenn Anwender die Ausgabe nicht interpretieren können. Schulen Sie FM-Mitarbeiter in Grundbegriffen: Was ist ein GAEB-LV, was bedeuten X83 vs X84, wie lese ich eine GAEB-Datei im Viewer? Ebenso sollten sie wissen, wie man mit dem Konverter umgeht – idealerweise anfangs mit Begleitung (Anbieter wie T&T bieten individuelle Schulungen an).

• Pilotprojekte intern durchführen: Bevor man große Vergaben so abwickelt, lieber bei einem kleineren Vertrag austesten. Dabei alle Schritte (Erstellung, Konvertierung, Import ins AVA, Angebotsrücklauf) einmal durchspielen.

• Kommunikation mit Bietern: Wenn man GAEB-Dateien rausgibt, informiert die möglichen Bieter über Hilfsmittel. So erhöht man die Chance auf korrekte Angebote. Manche Unternehmen legen z.B. dem LV ein Merkblatt bei: "Unsere Ausschreibung können Sie mit Software XY oder online unter URL in eine Excel-Tabelle umwandeln, um Ihr Angebot bequem zu kalkulieren."

• Fallback-Lösungen bereithalten: Trotz aller Technik kann es haken. Haben Sie einen Plan B, falls die Zeit drängt: z.B. einen Dienstleister, der notfalls die Konvertierung manuell übernimmt (T&T bietet Konvertierungsdienstleistung an). Oder im schlimmsten Fall: das LV doch schnell in einer AVA-Software neu erfassen (unangenehm, aber besser als falsch).

• Beachtung rechtlicher Aspekte: Konvertierte GAEB-Dateien sind rechtlich als Ausschreibungsunterlage maßgeblich. Stellen Sie sicher, dass nichts juristisch Relevantes beim Konvertieren verlorengeht – z.B. Vertragsbedingungen, die im Word-Dokument standen. Solche gehören meist in den sogenannten "Zusatztext Bauvertrag" oder als separate Datei. Im Zweifel sollten solche Texte lieber nicht im GAEB selbst, sondern als PDF-Anhang zur Ausschreibung weitergegeben werden, um Formatverluste zu vermeiden. Ein GAEB-LV ist primär für die Leistungspositionen gedacht; Allgemeine Vertragsbedingungen fügt man besser als separate Dokumente bei.

Durch Anwendung dieser Empfehlungen kann die Konvertierungspraxis im Facility Management deutlich verbessert werden. Die beschriebenen Beispiele demonstrieren den Nutzen, aber auch die Verantwortung, die mit dem Einsatz von Konvertern einhergeht: Sie können Prozesse beschleunigen, bedürfen aber sorgfältiger Handhabung.