Konfigurierbarkeit:<\/strong> Die Workflows m\u00fcssen an die Besonderheiten jedes Projekts angepasst werden k\u00f6nnen.<\/li>\n<\/ul>\nRollenbasierte Workflows: Standardisieren ohne Starrheit<\/h2>\n
Der wahre qualitative Sprung eines ausgereiften CDE ist die Verwaltung von rollenbasierten Workflows – nicht von Personen.<\/p>\n
Das Problem der benutzerbasierten Workflows<\/h3>\n
Ein Workflow, der auf spezifischen Benutzern konfiguriert ist, hat ein strukturelles Problem: er ist starr und fragil<\/strong>. Wenn Mario der strukturelle Pr\u00fcfer ist und in den Urlaub geht, blockiert der Workflow. Wenn Luisa die Rolle wechselt, muss der Workflow neu konfiguriert werden. Wenn das Projekt den Besitzer wechselt, muss alles neu \u00fcberdacht werden.<\/p>\nDie rollenbasierten Workflows<\/h3>\n
Die L\u00f6sung besteht darin, jeden Schritt einer logischen Funktion<\/strong> und nicht einer Person zuzuordnen. Typische Rollen:<\/p>\n\n- BIM-Manager<\/strong>: Gesamtaufsicht \u00fcber das Informationsmanagement;<\/li>\n
- BIM-Koordinator<\/strong>: disziplinarische Koordination;<\/li>\n
- CDE-Manager:<\/strong> operative Verwaltung der Umgebung;<\/li>\n
- Informationsmanager:<\/strong> umfassende Informationsgovernance;<\/li>\n
- Struktureller Pr\u00fcfer, MEP, Architekt:<\/strong> Fachverantwortliche;<\/li>\n
- Vertreter der beauftragenden Partei:<\/strong> Vertreter des Auftraggebers.<\/li>\n<\/ul>\n
Zum Zeitpunkt des Starts des Workflows fordert die Plattform dazu auf, jede Rolle der richtigen Person<\/strong> im Projektteam zuzuordnen. Die Vorlage bleibt somit standardisiert, die Anwendung ist flexibel und anpassbar.<\/p>\nBetriebliche Vorteile<\/h3>\n\n- Resilienz<\/strong>: Wenn die zugewiesene Person abwesend ist, kann die Zuordnung von Rolle und Person ge\u00e4ndert werden, ohne den Workflow zu ber\u00fchren;<\/li>\n
- Skalierbarkeit<\/strong>: dieselbe Vorlage kann auf Dutzende von Projekten mit unterschiedlichen Teams angewendet werden;<\/li>\n
- Konformit\u00e4t mit UNI 11337-7<\/strong>: die italienische Norm zu BIM-Rollen wird zum semantischen Rahmen der Workflows;<\/li>\n
- Einfachheit der Verwaltung<\/strong>: die operative Konfiguration reduziert sich auf eine Zuordnung von Rollen zu Personen.<\/li>\n<\/ul>\n
Ein fortschrittlicher CDE-Dokumentenworkflow beschr\u00e4nkt sich nicht auf die Verwaltung von Genehmigungen: Er sammelt strukturierte Daten<\/strong> im Verlauf des Prozesses. Der Mechanismus sind die Formulare<\/strong> (digitale Checklisten, Pr\u00fcfbl\u00e4tter, Qualit\u00e4tskontrollen), die den Schritten des Workflows zugeordnet sind.<\/p>\nWas sind Formulare?<\/h3>\n
Ein Formular ist eine strukturierte Ansammlung von Feldern – textuell, numerisch, boolesch, mit Mehrfachauswahl, mit Anh\u00e4ngen – die spezifische Informationen \u00fcber einen Informationscontainer zu einem bestimmten Zeitpunkt seines Lebenszyklus sammelt.<\/p>\n
Konkrete Beispiele:<\/p>\n
\n- Strukturelles Pr\u00fcfformular:<\/strong> ausgef\u00fcllt vom Pr\u00fcfer im Schritt der \u00dcberpr\u00fcfung, mit Feldern zu den geltenden Normen, Sicherheitskoeffizienten, \u00dcbereinstimmung mit den Projektlasten;<\/li>\n
- Brandschutzpr\u00fcfformular:<\/strong> ausgef\u00fcllt am Ende der Bauphase, mit Feldern zu REI, zu Brandabschnitten, zu Fluchtwegen;<\/li>\n
- FM-Handover-Formular:<\/strong> ausgef\u00fcllt in der letzten Phase des Projekts, mit technischen Daten f\u00fcr die operative Verwaltung (Handb\u00fccher, Wartung, Anbieter, Garantien).<\/li>\n<\/ul>\n
Bedingte Sichtbarkeit nach Phase<\/h3>\n
Das Unterscheidungsmerkmal ist die bedingte Sichtbarkeit<\/strong>: Die Formulare k\u00f6nnen nur in bestimmten Phasen des Workflows sichtbar oder bearbeitbar sein, um sicherzustellen, dass jeder Benutzer ausschlie\u00dflich auf die Informationen zugreift, die in seinem Verantwortungsbereich liegen.<\/p>\nDas strukturelle Pr\u00fcfformular ist:<\/p>\n
\n- unsichtbar<\/strong> w\u00e4hrend der WIP-Phase;<\/li>\n
- nur vom strukturellen Pr\u00fcfer ausf\u00fcllbar<\/strong> w\u00e4hrend der \u00dcberpr\u00fcfungsphase;<\/li>\n
- nur lesbar<\/strong> f\u00fcr das Task-Team in der \u00dcberpr\u00fcfungsphase;<\/li>\n
- eingefroren und konsultierbar<\/strong> nach der Genehmigung.<\/li>\n<\/ul>\n
Dies erm\u00f6glicht eine gef\u00fchrte, kontrollierte und schrittweise Verwaltung von Pr\u00fcfungen, Ausf\u00fcllungen und Validierungen.<\/p>\n
Formulare als Fortschrittsbedingung<\/h3>\n
In anspruchsvolleren Workflows wird das Ausf\u00fcllen eines Formulars zur Fortschrittsbedingung;<\/strong> ohne das Ausf\u00fcllen des Pr\u00fcfmoduls kann der Workflow nicht fortschreiten. Dies verwandelt die Formulare von einfachen Formularen in echte Prozessgate<\/strong>, die sicherstellen, dass kritische Daten vor dem Fortschritt gesammelt werden.<\/p>\nVom einzelnen Formular zur Projektdatenbank<\/h3>\n
Die in den Formularen gesammelten Daten bleiben nicht isoliert im einzelnen Container. Ein fortschrittlicher CDE aggregiert sie auf Projektebene und macht sie in tabellarischer Form einsehbar, filterbar, sortierbar und abfragbar. Dies ist der \u00dcbergang von der Dokumentenverwaltung zur intelligenten Informationsverwaltung.<\/strong><\/p>\nVerwaltung der Revisionen: Workflows und neue Versionen<\/h2>\n
Ein oft untersch\u00e4tztes Thema ist, wie ein fortschrittlicher CDE die Beziehung zwischen Workflows und Revisionen des Informationscontainers verwaltet. Was passiert, wenn eine neue Version einer Datei hochgeladen wird, w\u00e4hrend ein Workflow zur vorherigen Version l\u00e4uft?<\/p>\n
Das Prinzip: Der Workflow wird unterbrochen, die Historie bleibt<\/h3>\n
Wenn eine aktualisierte Revision eines Informationscontainers hochgeladen wird, wird der eventuell laufende Workflow zur vorherigen Version im aktuellen Zustand unterbrochen und bleibt als historische Referenz einsehbar<\/strong>. Auf der neuen Version kann dann ein neuer Prozess beginnen, der mit dem aktualisierten Inhalt der Datei \u00fcbereinstimmt.<\/p>\nDieses Verhalten hat einen wichtigen normativen und operativen Wert:<\/p>\n
\n- Die R\u00fcckverfolgbarkeit<\/strong> des unterbrochenen Prozesses geht nicht verloren;<\/li>\n
- Es entsteht keine Verwirrung<\/strong> zwischen dem Workflow der alten und der neuen Version;<\/li>\n
- Der Audit-Trail<\/strong> h\u00e4lt vollst\u00e4ndige Nachweise dar\u00fcber, was bei jeder Revision passiert ist.<\/li>\n<\/ul>\n
Konkretes Beispiel<\/h3>\n
Der BIM-Koordinator l\u00e4dt die Version 02 eines strukturellen Modells hoch. Der Pr\u00fcfworkflow wird aktiviert, der bis zum Schritt der \u00dcberpr\u00fcfung fortschreitet. In der \u00dcberpr\u00fcfung werden Unstimmigkeiten mit dem architektonischen Modell festgestellt, und das Task-Team beschlie\u00dft, das Modell zu \u00fcberarbeiten.<\/p>\n
Er l\u00e4dt die Version 03 hoch. An diesem Punkt:<\/p>\n
\n- Der Workflow zur Version 02 bleibt „in \u00dcberpr\u00fcfung unterbrochen“, mit allen Kommentaren und offenen Problemen, die als Historie einsehbar sind;<\/li>\n
- Auf der Version 03 beginnt ein neuer Pr\u00fcfworkflow von Anfang an;<\/li>\n
- Der Audit-Trail dokumentiert sowohl den teilweisen Verlauf der Version 02 als auch den neuen Verlauf der Version 03;<\/li>\n
- Es gehen keine Daten verloren, und kein Prozess wird vermischt.<\/li>\n<\/ul>\n
Implikationen f\u00fcr die Wahl der Plattform<\/h3>\n
Nicht alle Plattformen verwalten dieses Szenario korrekt. Einige \u00fcberschreiben den Workflow, andere behalten ihn bei, ohne ihn mit der neuen Version zu verkn\u00fcpfen, und wieder andere l\u00f6schen ihn stillschweigend. Ein CDE, das ISO 19650-konform ist, muss das korrekte Verhalten gew\u00e4hrleisten: nachverfolgbare Unterbrechung, keine L\u00f6schung, permanente Einsichtnahme in die Historie.<\/strong><\/p>\nWiederkehrende Workflow-Muster im AEC-Sektor<\/h2>\n
Im Laufe der Jahre haben sich einige wiederkehrende Workflow-Muster etabliert, die als anerkannte Best Practices gelten. Hier sind die h\u00e4ufigsten.<\/p>\n
Muster 1 \u2014 Klassischer dreistufiger CRA-Workflow<\/h3>\n
Der Standard-Workflow ISO 19650-2:<\/p>\n
\n- Check<\/strong> (Produzenten-Task-Team) \u2192 interne technische \u00dcberpr\u00fcfung;<\/li>\n
- Review<\/strong> (andere Task-Teams + Lead Appointed Party) \u2192 interdisziplin\u00e4re \u00dcberpr\u00fcfung;<\/li>\n
- Approve<\/strong> (Appointing Party) \u2192 formelle Genehmigung.<\/li>\n<\/ul>\n
Dieser Workflow wird f\u00fcr Informationscontainer verwendet, die den \u00dcbergang vom Status Shared zum Status Published mit vertraglichem Wert darstellen.<\/p>\n
Muster 2 \u2014 Automatisierter IDS-Validierungs-Workflow<\/h3>\n
Er ist spezifisch f\u00fcr IFC-Modelle:<\/p>\n
\n- Upload des IFC-Modells<\/strong><\/li>\n
- automatische IDS-Validierung<\/strong> (automatischer Trigger)<\/li>\n
- manuelle \u00dcberpr\u00fcfung<\/strong> bei positiver Validierung<\/li>\n
- Korrekturbenachrichtigung<\/strong> bei negativer Validierung<\/li>\n<\/ul>\n
Es ist ratsam, diesen Workflow f\u00fcr alle IFC-Modellcontainer in Projekten zu verwenden, die IDS-Standards anwenden (empfohlen f\u00fcr komplexe BIM-Projekte).<\/p>\n
Muster 3 \u2014 Digitaler Workflow mit Zeitstempel<\/h3>\n
Er ist f\u00fcr vertragliche Dokumente:<\/p>\n
\n- \u00dcberpr\u00fcfung<\/strong> des Dokuments;<\/li>\n
- \u00dcberpr\u00fcfung<\/strong> durch die Lead Appointed Party;<\/li>\n
- digitale Unterschrift<\/strong> durch die Appointing Party;<\/li>\n
- Anbringung des Zeitstempels<\/strong>;<\/li>\n
- Ver\u00f6ffentlichung mit vertraglichem Eignungscode<\/strong>;<\/li>\n<\/ul>\n
Dieser Workflow sollte f\u00fcr Informationscontainer mit rechtlich relevanten vertraglichen Werten verwendet werden.<\/p>\n
Muster 4 \u2014 Strukturierter Rework-Loop-Workflow<\/h3>\n
Er ist f\u00fcr das Management von Iterationen:<\/p>\n
\n- Hauptworkflow (z.B. CRA)<\/li>\n
- bei Ablehnung<\/strong> \u2192 automatische Er\u00f6ffnung eines Sub-Workflows zur Korrektur mit:\n
\n- Zuweisung an das Produzenten-Task-Team;<\/li>\n
- Liste der zu l\u00f6senden Probleme;<\/li>\n
- Antwort-SLA;<\/li>\n
- \u00dcberpr\u00fcfung, dass alle Probleme geschlossen sind, bevor zum Hauptworkflow zur\u00fcckgekehrt wird.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
Dieser Workflow ist f\u00fcr komplexe Projekte mit hoher Wahrscheinlichkeit von Iterationen geeignet (z.B. komplexe Neubauten, Infrastruktur).<\/p>\n
Muster 5 \u2014 Paralleler Genehmigungs-Workflow<\/h3>\n
Wenn mehrere Parteien gleichzeitig genehmigen m\u00fcssen, ohne sequenzielle Abh\u00e4ngigkeit:<\/p>\n
\n- Upload<\/strong> des Containers;<\/li>\n
- paralleler Versand<\/strong> an Pr\u00fcfer A + Pr\u00fcfer B + Pr\u00fcfer C;<\/li>\n
- Sammlung der Genehmigungen<\/strong> mit Konfliktmanagement;<\/li>\n
- abschlie\u00dfende Genehmigung<\/strong> nur, wenn alle genehmigt haben.<\/li>\n<\/ul>\n
Dieser Workflow eignet sich f\u00fcr Container, die eine multidisziplin\u00e4re Validierung erfordern (z.B. ein Koordinierungsdokument, eine komplexe Variante).<\/p>\n
Muster 6 \u2014 \u00dcbergabe-Workflow an das Facility Management<\/h3>\n
Am Ende des Projekts:<\/p>\n
\n- Vollst\u00e4ndigkeitspr\u00fcfung<\/strong> der ver\u00f6ffentlichten Container;<\/li>\n
- Validierung der technischen Daten<\/strong> f\u00fcr das FM;<\/li>\n
- Ausf\u00fcllen von \u00dcbergabeformularen<\/strong> (Handb\u00fccher, Garantien, Wartung);<\/li>\n
![\"Schema](\"https:\/\/biblus.accasoftware.com\/de\/wp-content\/uploads\/sites\/6\/2026\/05\/Diagramm-eines-CDE-Dokumenten-Workflows.jpg\")
![\"CRA-Prozess](\"https:\/\/biblus.accasoftware.com\/de\/wp-content\/uploads\/sites\/6\/2026\/05\/CRA-Prozess-im-CDE-Dokumenten-Workflow.jpg\")