Was bei Bau-Dokumenten tatsächlich automatisiert wird
Im Bau- und Projektgeschäft entstehen Pläne, Bautagesberichte, Fotos, Prüfprotokolle, Lieferscheine, Nachträge, Rechnungen und Abnahmen in unterschiedlichen Kanälen. Die Automatisierung wandelt diese Eingänge in einen strukturierten Vorgang um. Das Original bleibt erhalten; zusätzlich entstehen Projektbezug, Dokumentart, Absender, Datum, Version, Bearbeitungsstatus und offene Prüfpunkte.
Das Ziel ist keine zweite Ablage neben Projektsoftware, DMS und ERP. Die Prozessschicht erkennt den Eingang, prüft definierte Merkmale und steuert die Übergabe. Das DMS führt freigegebene Dokumente und Versionen, die Projektsoftware führt Aufgaben und Mängel, das ERP führt kaufmännische Vorgänge. Unklare Fälle bleiben in einer sichtbaren Prüfwarteschlange statt in einem Sammelpostfach zu verschwinden.
- Originaldatei, Nachricht und Anhänge unverändert mit Eingangszeit sichern
- Projekt, Bauabschnitt, Gewerk und Vorgang über belastbare Referenzen zuordnen
- Dokumentart und Pflichtangaben erkennen, aber fachliche Bewertung nicht vorwegnehmen
- Freigabe, Rückfrage oder Übergabe als nachvollziehbaren Status führen
Projektzuordnung, Planstände und Dubletten vor jeder Übergabe klären
Die wichtigste Automatisierungsregel ist eine eindeutige Referenz. Projekt- oder Auftragsnummer, Plan- beziehungsweise Dokumentnummer, Revision, Gewerk, Bauteil oder Ort müssen aus Eingang, Stammdaten oder einer kontrollierten Auswahl zusammengeführt werden. Eine hohe KI-Konfidenz reicht nicht aus, wenn zwei laufende Projekte ähnlich heißen oder derselbe Plan in mehreren Revisionen vorliegt.
Für Pläne und freigaberelevante Dokumente benötigt der Prozess eine eigene Versionslogik. Eine neue Datei darf eine ältere nicht still überschreiben. Das System prüft, ob Nummer, Revision und Status zusammenpassen, kennzeichnet mögliche Dubletten und hält konkurrierende Stände bis zur Klärung getrennt. Auf mobilen Geräten sollte der freigegebene Stand erkennbar sein; veraltete Kopien dürfen nicht wie aktuelle Arbeitsgrundlagen wirken.
- fehlende Projektreferenz: Eingang halten und gezielte Zuordnung verlangen
- unbekannte Revision: mit Vorgängerversion und Freigabestatus zur Prüfung vorlegen
- mögliche Dublette: vorhandenen Vorgang verlinken, aber nicht automatisch überschreiben
- nachträgliche Änderung: neuen Versions- oder Änderungsprozess auslösen
Prüfregeln und Ausnahmen dokumentenspezifisch festlegen
Ein Bautagesbericht braucht andere Pflichtangaben als ein Lieferschein oder eine Abschlagsrechnung. Deshalb erhält jede Dokumentklasse eine fachliche Prüfmatrix: erwartete Merkmale, zulässige Quellen, verantwortliche Rolle, Frist, Freigabegrenze und Zielsystem. Formale Vollständigkeit lässt sich automatisiert prüfen; technische Richtigkeit, Abnahme, Leistungsbestätigung und kostenwirksame Entscheidung bleiben bei berechtigten Personen.
Gute Ausnahmebehandlung zeigt nicht nur, dass etwas fehlt, sondern woher die Information stammt und welche Folgeaktion vorgesehen ist. Bei einem fehlenden Prüfdatum entsteht eine konkrete Rückfrage. Bei einer nicht zuordenbaren Rechnung bleibt der Beleg im Prüfstatus. Bei widersprüchlichem Planstand sehen Verantwortliche beide Fundstellen. So wird menschliche Prüfung schneller, ohne Verantwortung zu verschleiern.
- Bautagesbericht: Projekt, Datum, Abschnitt, Beteiligte und bestätigende Rolle prüfen
- Foto oder Mangel: Ort, Gewerk, Zeitpunkt, Aufgabe und Status zusammenführen
- Lieferschein oder Rechnung: Auftrag, Leistung, Belegreferenz und Freigabeweg abgleichen
- Abnahme oder Nachweis: verbindliche Freigabe ausschließlich durch zuständige Personen
CDE, DMS, Projektsoftware und ERP mit klaren Systemrollen verbinden
BIM Deutschland beschreibt eine Common Data Environment als zentrale Umgebung, in der Projektinformationen gespeichert, versioniert, freigegeben und archiviert werden. Für die Automatisierung folgt daraus: Die CDE oder das DMS bleibt die vertrauenswürdige Dokumentquelle. Aufgaben, Mängel und Termine können in der Projektsoftware liegen; Auftrag, Bestellung und Rechnung im ERP. Die Integrationsschicht verbindet diese Objekte über stabile Kennungen und dokumentierte Statuswechsel.
Jeder Schreibweg braucht eine Eigentümerschaft. Das DMS vergibt Dokument-ID und Version, die Projektsoftware die Vorgangs-ID, das ERP die kaufmännische Belegnummer. Bei einem technischen Wiederanlauf muss dieselbe Übergabe wiederholbar sein, ohne doppelte Dokumente oder Aufgaben anzulegen. Antwortet ein Zielsystem nicht, bleibt der Vorgang mit Fehlergrund und Wiederanlaufstatus sichtbar. Eine Schattenakte in E-Mail oder Automatisierungsplattform ist kein belastbarer Ersatz.
- führendes System, erlaubte Schreibfelder und Rückmeldung je Übergabe festlegen
- Dokument-, Projekt- und Vorgangs-ID systemübergreifend zurückschreiben
- Berechtigungen für interne Rollen und externe Projektpartner getrennt prüfen
- Wiederanlauf, Protokollierung, Aufbewahrung und Löschung vor dem Pilotbetrieb testen
Offene BIM-Standards gezielt nutzen, aber nicht mit Dokumentenablage verwechseln
IFC beschreibt Bauwerksinformationen in einem herstellerneutralen Datenmodell. BCF überträgt modellbezogene Themen und Prüfpunkte zwischen BIM-Anwendungen. Beide Standards können Systemgrenzen entschärfen: Ein BCF-Vorgang kann beispielsweise einen modellbezogenen Mangel mit Ansicht und Objektbezug transportieren; IFC kann definierte Bauwerksinformationen zwischen Werkzeugen austauschbar machen.
Damit ist jedoch nicht jedes PDF, Foto oder Protokoll automatisch strukturiert. Vor der Umsetzung muss entschieden werden, welche Information als Datei, Metadatum, DMS-Dokument, BCF-Thema oder IFC-Eigenschaft geführt wird. Auch Auftraggeber-Informationsanforderungen und Datenvorlagen aus dem BIM-Portal ersetzen keine interne Zuständigkeits- und Freigabelogik. Sie helfen, erwartete Informationen und Formate vorab eindeutiger festzulegen.
- IFC für vereinbarte Bauwerks- und Modelldaten einsetzen
- BCF für modellbezogene Themen, Kommentare und Bearbeitungsstände prüfen
- PDF, Foto und Nachricht mit eindeutigen Metadaten im vorgesehenen Dokumentensystem führen
- Informationsanforderungen vor Projektstart in prüfbare Übergabekriterien übersetzen
Mit einer Dokumentklasse pilotieren und Qualität vor Automatisierungsgrad messen
Ein guter Pilot beginnt nicht mit allen Baustellen und Dokumentarten. Geeignet ist eine häufige Dokumentklasse mit klarer Projektzuordnung, erreichbarer Fachverantwortung und einem definierten Zielsystem. Vor dem Start werden reale Testfälle gesammelt: korrekte Dokumente, fehlende Referenzen, falsche Revisionen, Dubletten, Änderungen, beschädigte Dateien und technische Ausfälle.
Gemessen werden Durchlaufzeit bis zum prüfbaren Vorgang, Anteil korrekt zugeordneter Dokumente, Korrekturen je Datenfeld, Dublettenquote, Gründe für Rückfragen und Zeit bis zur Fehlerbehebung. Der Automatisierungsgrad steigt erst, wenn die Fehler sichtbar bleiben und der Wiederanlauf zuverlässig funktioniert. Eine hohe Erkennungsquote allein belegt noch keinen stabilen Bauprozess.
- eine Dokumentklasse, wenige Projekte und klare Ausnahmefälle auswählen
- Ausgangsbasis und Qualitätskriterien vor der technischen Umsetzung festhalten
- Korrekturen als Qualitätsdaten auswerten, nicht ungeprüft als Wahrheit übernehmen
- weitere Dokumentklassen erst nach bestandener fachlicher Abnahme ergänzen
Quellen und fachliche Grundlagen
Die Einordnung stützt sich auf die folgenden offiziellen Veröffentlichungen. Datenschutzrechtliche Anforderungen sind für den konkreten Einsatz zu prüfen.
- BIM Deutschland: Common Data Environment und digitales Informationsmanagement, abgerufen am 30. September 2026
- BIM Deutschland: BIM-Portal, Informationsanforderungen und standardisierte Vorlagen, abgerufen am 30. September 2026
- buildingSMART International: Industry Foundation Classes (IFC), abgerufen am 30. September 2026
- buildingSMART International: BIM Collaboration Format (BCF), abgerufen am 30. September 2026