Status von Informationscontainers ISO 19650: vollständiger Leitfaden zu WIP, Shared, Published und Archived

Wer mit einem CDE, das der ISO 19650 entspricht, arbeitet, sieht sich früher oder später mit einer scheinbar banalen Frage konfrontiert: „In welchem Zustand befindet sich diese Datei?“. Die Antwort ist nicht technisch. Sie ist normativ, vertraglich, operativ.

Die Zustände des Informationscontainers sind die vier Phasen des Lebenszyklus einer Projektinformation, die durch die Norm ISO 19650 definiert sind: Work in Progress (WIP), Shared, Published, Archived. Jeder Zustand bestimmt, wer den Informationscontainer sehen, ändern und nutzen kann, mit dokumentierten und autorisierten Übergangsregeln.

Zu verstehen, wie diese Zustände funktionieren, ist der Schlüssel, um ein CDE von einem einfachen Archiv zu einem Governance-Werkzeug zu transformieren. In diesem Artikel erklären wir im Detail, was jeder Zustand bedeutet, wie die Übergänge erfolgen und wie ein fortschrittliches CDE diese Schritte operativ verwaltet.

Wenn Sie unseren einführenden Artikel über das CDE gemäß ISO 19650 noch nicht gelesen haben, empfehlen wir Ihnen, dort zu beginnen: Hier gehen wir ins Detail über einen der technischsten Aspekte.

Der Lebenszyklus des Informationscontainers: vier Zustände, ein Prozess

Die ISO 19650-1 (§12) definiert vier Hauptzustände, die jeder Informationscontainer während des Projekts durchläuft. Es handelt sich nicht um eine starre Abfolge: Ein Container kann zu vorherigen Zuständen zurückkehren, wenn Mängel festgestellt werden, und nicht alle Container erreichen gleichzeitig den Archivierungszustand.

Die Zustände sind:

• Work in Progress (WIP) – intern im Team, das den Inhalt erstellt;
• Shared – mit anderen Teams oder Disziplinen zum Koordinieren geteilt;
• Published (oder Published for use) – veröffentlicht und für die vertragliche Nutzung genehmigt;
• Archived – archiviert als historische Referenz.

Jeder Zustand ist durch vier Elemente gekennzeichnet: wer Zugang zum Container hat, was er tun kann, wie der Übergang zum nächsten Zustand erfolgt, warum sich der Container in dieser Phase befindet.

Das allgemeine Schema des Zyklus

Der Übergang zwischen den Zuständen erfolgt durch den Prozess CRA (Check, Review, Approve) – Überprüfung, Revision und Genehmigung – geregelt durch die ISO 19650-2. Jeder Übergang hinterlässt eine Spur im Audit-Trail des CDE.

Allgemeines Schema des Zyklus der Zustände eines CDE

Status 1 — Work in Progress (WIP): der Arbeitsbereich des Teams

Der Work in Progress ist der anfängliche Status jedes Informationscontainers. Es ist der Raum, in dem das Team, das den Inhalt produziert – typischerweise ein Task Team in der Terminologie ISO 19650 – frei arbeitet, ohne das Material anderen auszusetzen.

Wer hat Zugang zum WIP

Nur die Mitglieder des Task Teams, das den Informationscontainer produziert. Andere Disziplinen, der Auftraggeber, der Prüfer und andere Teams haben keine Sichtbarkeit auf den Inhalt im WIP.

Was kann man tun

Im WIP behält das Team die volle operative Kontrolle über den Informationscontainer, mit der Freiheit zu:

• Inhalte frei zu erstellen, zu ändern und zu löschen;
• Lösungen zu testen, zu iterieren, Fehler zu machen;
• intern im Team ohne Formalitäten zu kollaborieren;
• vorläufige, aber noch nicht endgültige Metadaten zuzuordnen.

Betriebliche Merkmale

Der WIP ist der einzige Status, in dem der Informationscontainer gelöscht werden kann (vor der formalen Freigabe). Sobald der Container zu Shared übergeht, führt jede Änderung zu einer neuen, nachverfolgten Revision.

Typischer Eignungscode

Der zugeordnete Eignungscode ist in der Regel S0 (Initialstatus) oder äquivalent, was anzeigt, dass der Container noch nicht einer internen Überprüfung unterzogen wurde.

Der Übergang zu Shared

Wenn das Task Team der Meinung ist, dass der Container bereit ist, mit anderen Disziplinen geteilt zu werden, leitet es den Prozess der internen Überprüfung (technische Selbstüberprüfung) ein. Nur nach einer positiven Überprüfung kann der Container zu Shared übergehen. Dieser Übergang wird in der Regel vom Task Team Manager oder vom BIM Coordinator genehmigt.

Status 2 — Shared: die gemeinsame Nutzung zur Koordination

Der Status Shared markiert den Übergang von der internen Nutzung zur interdisziplinären Nutzung. Der Container ist nun für andere Projektteams und die Lead Appointed Party (die koordinierende Stelle des gesamten Informationsauftrags) sichtbar.

Wer hat Zugang zum Shared-Container

Wenn ein Container in den Status Shared übergeht, erweitert sich seine Sichtbarkeit auf:

• das Task Team, das ihn produziert hat (mit eingeschränkten Änderungsrechten);
• die anderen Task Teams des Projekts (in Leserechte, zur Koordination);
• die Lead Appointed Party (zur Überprüfung und Verifizierung);
• den Auftraggeber (Appointing Party) je nach den Regeln des Informationsverzeichnisses.

Was kann man tun

Im Status Shared wird der Informationscontainer zu einem Koordinationsinstrument zwischen den Disziplinen, daher kann er verwendet werden für:

• konsultieren des Containers für Koordinationsaktivitäten;
• anmerken, kommentieren, Issues eröffnen (typischerweise über BCF);
• überprüfen von Konsistenz, Clash Detection, disziplinarischer Koordination;
• Änderungen beim produzierenden Task Team über den formalen Prozess anfordern.

Im Status Shared kann der Inhalt nicht für den Bau oder für vertragliche Entscheidungen verwendet werden: es handelt sich um Koordinationsmaterial, nicht um veröffentlichtes Material.

Typische Eignungscodes

Der Status Shared sieht verschiedene Eignungscodes je nach Zweck der Freigabe vor:

• S1 – Suitable for Coordination (geeignet für Koordination);
• S2 – Suitable for Information (geeignet für Informationen);
• S3 – Suitable for Internal Review and Comment (geeignet für interne Überprüfung und Kommentare);
• S4 – Suitable for Stage Approval (geeignet für Phasenfreigabe);
• S6/S7 – Suitable for PIM Authorization / AIM Authorization.

Jeder Code hat unterschiedliche vertragliche und operative Implikationen und muss mit der Phase des Projekts übereinstimmen.

Der Übergang zu Published

Wenn der Container den Überprüfungs- und Genehmigungsprozess (Check, Review, Approve) durch die Lead Appointed Party und/oder die Appointing Party besteht, wechselt er zu Published. Wenn jedoch Nichtkonformitäten festgestellt werden, kehrt der Container zu WIP mit den Korrekturhinweisen (Rework-Schleife) zurück.

Staat 3 — Published: der genehmigte Behälter zur Nutzung

Der Status Published markiert die offizielle Genehmigung des Informationsbehälters durch die beauftragende Partei (den Auftraggeber). Ab diesem Moment hat der Behälter vertragliche Gültigkeit und kann für die operativen Entscheidungen des Projekts verwendet werden — Ausführungsplanung, Bau, Prüfungen, Management.

Wer hat Zugang zu Published

Der Lesezugang wird typischerweise allen Beteiligten am Projekt gemäß den Regeln des Informationsverzeichnisses gewährt. Die Änderungsrechte sind hingegen extrem eingeschränkt: Ein Published-Behälter kann nicht direkt geändert werden. Jede Änderung erfordert die Eröffnung einer neuen Revision, die den Zyklus vom WIP neu beginnt.

Was kann man tun

Sobald der Status Published erreicht ist, übernimmt der Informationsbehälter eine andere Rolle im Vergleich zu den vorherigen Phasen und man kann:

• den Behälter nutzen für vertragliche Aktivitäten, Bau, Management;
• definitiv und autoritativ konsultieren;
• in vertraglichen Dokumenten und formalen Mitteilungen zitieren;
• NICHT direkt ändern: es ist notwendig, eine neue Revision zu eröffnen.

Typische Eignungscodes

• A1-AN – Authorized for [scope] (genehmigt für einen bestimmten Zweck);
• B1-BN – Partially signed-off (teilweise genehmigt, mit Vorbehalten);
• CR – As Constructed Record (Aufzeichnung des Gebauten);
• PR – Published Record (endgültige Archivveröffentlichung).

Der Code spezifiziert den genehmigten Anwendungsbereich: Zum Beispiel kann A1 „Authorized for Construction“, CR „As-built record“ usw. bedeuten.

Revisionscodes

Parallel zu den Eignungscodes werden die Revisionen des Behälters mit Revisionscodes verfolgt:

• P01, P02, P03… – Revisionen in der Planungsphase (Pre-construction)
• C01, C02, C03… – Revisionen in der Bauphase (Construction)

Die Kombination aus Eignungscode und Revisionscode identifiziert eindeutig den semantischen Status des Behälters: „S2-P03“ bedeutet „geeignet für Informationen, dritte Revision in der Planungsphase“.

Der Übergang zu Archived

Am Ende der operativen Nutzung des Informationsbehälters – typischerweise am Ende der Projektphase oder am Ende des Auftrags – wird der Behälter archiviert. Dies bedeutet nicht, ihn zu entfernen: es bedeutet, ihn in einem permanenten Nur-Lese-Zustand einzufrieren.

Staat 4 — Archived: der unveränderliche historische Bezug

Der Status Archived bewahrt den Informationsbehälter als historischen Bezug. Es ist der endgültige Status des Lebenszyklus, bedeutet jedoch nicht Obsoleszenz: im Gegenteil, er stellt das autoritative Gedächtnis des Projekts dar.

Wer hat Zugang zu Archived

Der Zugang wird typischerweise in Nur-Lese-Form allen Personen gewährt, die das Recht auf Einsichtnahme in den Published-Behälter hatten. Die Archivierung entfernt nicht die Einsichtsrechte, blockiert jedoch jede Änderung.

Was kann man tun

Im Status Archived verliert der Informationsbehälter jede aktive operative Funktion und wird als stabile Evidenz des Informationsverlaufs des Projekts aufbewahrt, in dem man:

• den Behälter für historische Referenzen, Audits, Rechtsstreitigkeiten konsultieren;
• für Übertragungen an Drittsysteme exportieren (z.B. CAFM in der Phase von Facility Management);
• NICHT ändern, NICHT löschen: der Behälter ist eingefroren.

Warum die Archivierung kritisch ist

Aus normativer und vertraglicher Sicht ist der Status Archived der objektive Beweis für das, was während des Projekts produziert, genehmigt und verwendet wurde. Es ist die Dokumentationsbasis für:

• Konformitätsaudits (ISO 9001, ISO 19650-5, Sicherheit)
• Vertragliche Streitigkeiten zwischen Auftraggeber und beauftragten Parteien
• Drittprüfungen (Prüfer, Kontrollbehörden)
• Informationsübertragung an das Facility Management (Übergabe)
• Umweltbewertung nach dem Bau (LCA, EPD-Verifizierung).

Wie ein fortschrittliches CDE die Zustände operativ verwaltet

Die Norm beschreibt die Zustände, aber die CDE-Plattform macht sie operativ. Die Verhaltensweisen, die ein reifes CDE von einer Cloud-Speicherlösung unterscheiden, betreffen genau die Verwaltung der Zustände.

Klare Anzeige des Status

Jeder Informationsbehälter muss seinen aktuellen Status sofort und eindeutig mit Textetiketten anzeigen. Ein fortschrittliches CDE bietet filterbare Ansichten nach Status, sodass der CDE-Manager die Verteilung der Behälter entlang des Zyklus in Echtzeit überwachen kann.

Übergänge, die durch Workflows geregelt sind

Der Übergang zwischen den Zuständen erfolgt nicht willkürlich: er ist das Ergebnis eines strukturierten Workflows, den das CDE automatisch aktiviert. Der Workflow identifiziert die beteiligten Personen (nach Rolle oder Benutzer), benachrichtigt sie, sammelt die Genehmigungen und dokumentiert den Übergang im Audit-Trail.

Eine fortschrittliche CDE-Plattform ermöglicht es, verschiedene Workflows für verschiedene Arten von Behältern zu konfigurieren: ein strukturelles IFC-Modell folgt einem anderen Workflow als ein Vertragsdokument, und ein reifes CDE ermöglicht es, diese Flüsse granular zu definieren.

Berechtigungen, die vom Status abhängen

Der Zugang und die erlaubten Aktionen hängen vom Status ab: Ein Benutzer kann Änderungsrechte auf dem Behälter im WIP haben, aber nur Lesezugriff, wenn er zu Shared wechselt. Das CDE muss diese dynamische Berechtigungsmatrix automatisch verwalten, ohne manuelle Eingriffe bei jedem Übergang zu verlangen.

Konsistentes Versioning mit den Zuständen

Jeder Statusübergang kann eine neue Version des Behälters erzeugen. Insbesondere der Rückkehr von Shared zu WIP nach einer Revision erzeugt eine neue Version des Inhalts, wobei die vorherige als historische Referenz sichtbar bleibt. Wenn eine Revision hochgeladen wird, wird der laufende Workflow auf der vorherigen Version in dem Zustand unterbrochen, in dem er sich befindet, und bleibt als Archiv des Prozesses konsultierbar. Auf der neuen Version kann ein neuer Prozess beginnen, der mit dem aktualisierten Inhalt übereinstimmt.

Formulare, die mit den Zuständen verbunden sind

Ein fortschrittliches CDE ermöglicht es, strukturierte Formulare (Checklisten, Prüfblätter, technische Validierungen) mit den Zuständen des Behälters zu verknüpfen. Ein Formular kann nur ausgefüllt werden, wenn der Behälter in Shared ist, oder es kann obligatorisch werden, bevor der Übergang zu Published genehmigt wird. Dies ermöglicht es, die Übergänge an die Erfassung strukturierter Daten zu koppeln, nicht nur an eine allgemeine Genehmigung.

Eignungscodes: das Referenzhandbuch

Die Eignungscodes sind das semantische Ergänzung zu den Zuständen. Während der Zustand sagt „wo“ sich der Container im Zyklus befindet, sagt der Eignungscode „wofür“ er zu diesem Zeitpunkt geeignet ist.

Vollständige Tabelle der Eignungscodes ISO 19650

Hinweis zur Variabilität

Die hier aufgeführten Eignungscodes sind die von den Standards UK BIM Framework empfohlenen und weit verbreitet als internationales Referenzsystem angenommen. Die ISO 19650 schreibt keine genauen Codes vor: Jede Organisation oder jedes Projekt kann eine eigene Konvention übernehmen, solange sie im Informationshandbuch definiert ist.

Revisionscodes: die Nachverfolgbarkeit der Versionen

Neben den Eignungscodes verfolgen die Revisionscodes die Version des Containers. Die am weitesten verbreitete Konvention:

• P01, P02, P03… für Revisionen in der Entwurfsphase (Vorbereitung);
• C01, C02, C03… für Revisionen in der Bauphase (Bau);
• Einige Organisationen fügen D01 für die Revisionen nach der Übergabe an den Auftraggeber (bereitgestellt) hinzu.

Die Kombination „Eignung – Revision“ (z.B. „S2 – P03“, „A1 – C02“) identifiziert eindeutig den semantischen Zustand des Containers zu einem bestimmten Zeitpunkt.

Wie sie im CDE verwaltet werden

Ein fortschrittliches CDE generiert automatisch die Revisionscodes, indem es sie bei jeder neuen Version erhöht und so manuelle Benennungsfehler vermeidet. Das System muss auch die „Wiederverwendung“ bereits verwendeter Codes verhindern (z.B. von P01 zu P03 springen, ohne P02 zu durchlaufen), um Konsistenz und Nachverfolgbarkeit zu gewährleisten.

Häufige Fehler bei der Verwaltung von Zuständen

Nach Jahren der Implementierung des CDE in AEC-Projekten treten einige wiederkehrende Fehler auf, die es wert sind, bekannt zu sein, um sie zu vermeiden:

• Shared mit Published verwechseln: Shared ist nicht veröffentlicht. Es hat keinen vertraglichen Wert, kann nicht für operative Entscheidungen verwendet werden und rechtfertigt nicht den Bau. Die Verwendung eines Shared-Containers, als wäre er Published, ist eine der häufigsten Ursachen für Streitigkeiten.
• Die Shared-Phase überspringen: Einige Teams laden Container direkt im Zustand Published hoch, ohne durch Shared zu gehen. Dies umgeht den Prozess der interdisziplinären Koordination und kann zu nicht erkannten Konflikten, Inkonsistenzen zwischen Disziplinen und fehlender Übereinstimmung mit den Informationsanforderungen führen.
• Archivierung als Löschung behandeln: Der archivierte Container darf nicht gelöscht werden: Er muss schreibgeschützt eingefroren werden. Eine endgültige Löschung kann vertragliche und gesetzliche Aufbewahrungspflichten verletzen und die Verteidigungsfähigkeit im Falle eines Rechtsstreits gefährden.
• Published direkt ändern: Ein Published-Container darf nicht geändert werden; jede Änderung erfordert eine neue Revision, die den Zyklus durchläuft. Ein „stilles“ Ändern eines Published-Containers (oft für „kleine Korrekturen“) setzt die Nachverfolgbarkeit außer Kraft und untergräbt die Gültigkeit des gesamten Informationsprozesses.
• Rechte nicht konsistent mit dem Zustand: Es ist ein schwerwiegender Konfigurationsfehler im CDE, einem Task-Team zu erlauben, einen Shared-Container oder schlimmer noch, einen Published-Container einer anderen Disziplin frei zu ändern. Die Berechtigungen müssen vom Zustand abhängig und nach Rolle segregiert sein.

Die 10 Anforderungen an eine ISO 19650-konforme CDE-Plattform

Die korrekte Verwaltung der Zustände ist nur eine der zehn grundlegenden Anforderungen an eine konforme CDE-Plattform. Wenn Sie eine Plattform bewerten oder die Konformität der von Ihnen verwendeten Plattform überprüfen möchten, haben wir ein kostenloses Tool vorbereitet:

Testen Sie den Interaktiven Zustandsimulator — Visualisieren Sie den Lebenszyklus des Informationscontainers, klicken Sie auf jeden Zustand, um Berechtigungen, Akteure, Codes und Übergänge zu entdecken. Ideal für die Schulung des Teams und das Onboarding neuer Benutzer.

Der CDE als Ökosystem: die Verwaltung der Zustände in realen Plattformen

Fortschrittliche CDE-Plattformen implementieren die Verwaltung der Zustände auf eine Weise, die über bloße Etikettierung hinausgeht. Im usBIM-Ökosystem von ACCA beispielsweise verwaltet usBIM.platform — die ISO 19650-konforme CDE — die Zustände des Informationscontainers als aktive Elemente des Workflows, mit regulierten Übergängen, klarer Visualisierung des Fortschritts und vollständiger Nachverfolgbarkeit.

Rund um usBIM.platform bietet das Ökosystem spezifische Werkzeuge für die Aktivitäten, die in den verschiedenen Zuständen stattfinden:

• im WIP arbeitet das Team mit Apps wie usBIM.editor, usBIM.writer zur Erstellung und Bearbeitung von Inhalten;
• im Shared kommen usBIM.clash für die Koordination, usBIM.bcf für das interdisziplinäre Issue-Tracking, usBIM.compare für den Vergleich zwischen Revisionen, usBIM.federation für die Federation der Fachmodelle zum Einsatz;
• für die Informationsqualität, die den Übergang zum Zustand Shared und Published beeinflusst, kommt usBIM.dataquality mit der IDS-Validierung gemäß den Anforderungen des Informationsblatts ins Spiel;
• im Published und im Archived gewährleistet die Plattform den Zugriff im Nur-Lese-Modus, vollständige Audit-Trails, konsistente Versionierung und Export zu nachgelagerten Systemen (z.B. usBIM.maint für das Facility Management in der Übergabephase).

Der Wert liegt darin, dass die Zustände nicht nur von der Plattform verwaltet, sondern orchestriert werden mit den Fachanwendungen: Jeder Zustand aktiviert automatisch die entsprechenden Werkzeuge und Workflows, wodurch das Risiko operativer Fehler verringert wird.

Häufig gestellte Fragen (FAQ)

Was sind die Zustände des Informationscontainers?

Die Zustände des Informationscontainers sind die vier Phasen des Lebenszyklus einer Projektinformation, die durch die ISO 19650 definiert sind: Work in Progress (WIP), Shared, Published, Archived. Jeder Zustand bestimmt, wer den Container sehen, ändern und nutzen kann, mit nachverfolgten und autorisierten Übergangsregeln.

Was sind die vier Zustände der ISO 19650?

Die vier Zustände sind: Work in Progress (WIP), intern im Team in Bearbeitung; Shared, zur interdisziplinären Koordination geteilt; Published, für die vertragliche Nutzung genehmigt; Archived, als unveränderlicher historischer Referenz archiviert.

Was bedeutet WIP im CDE?

WIP (Work in Progress) ist der anfängliche Zustand des Informationscontainers, auf den nur das produzierende Team (Task Team) Zugriff hat. In diesem Zustand kann der Inhalt frei bearbeitet und gelöscht werden. Es ist der einzige Zustand, in dem der Container vor der formalen Freigabe gelöscht werden kann.

Was ist der Unterschied zwischen Shared und Published?

Der Shared-Container wird zwischen Disziplinen zur Koordination geteilt, hat jedoch keinen vertraglichen Wert. Der Published-Container ist formal vom Auftraggeber (Appointing Party) genehmigt und kann für operative Entscheidungen, Bau und Vertragsabschlüsse verwendet werden. Shared entspricht nicht Published.

Was ist der CRA-Prozess?

Der CRA (Check, Review, Approve) ist der Prozess der Überprüfung, Revision und Genehmigung, der die Übergänge zwischen den Zuständen des Informationscontainers regelt. Er ist durch die ISO 19650-2 normiert und ist der Mechanismus, durch den ein Container von Shared zu Published übergeht.

Kann ein Published-Container geändert werden?

Nein, ein Informationscontainer im Zustand Published kann nicht direkt geändert werden. Jede Änderung erfordert die Eröffnung einer neuen Revision, die den Zyklus vom Zustand WIP neu beginnt. Dies gewährleistet die Nachverfolgbarkeit und die vertragliche Unveränderlichkeit der veröffentlichten Versionen.

Was passiert, wenn eine neue Version einer Datei im CDE hochgeladen wird?

Wenn eine neue Version eines Informationscontainers hochgeladen wird, wird die vorherige Version im Verlauf aufbewahrt. Wenn ein Workflow auf der vorherigen Version lief, wird dieser typischerweise im Zustand unterbrochen, in dem er sich befindet, und bleibt als historische Referenz einsehbar, während auf der neuen Version ein neuer Prozess gestartet werden kann.

Ist die Archivierung im CDE dasselbe wie die Löschung?

Nein, das Archivieren eines Informationscontainers bedeutet, ihn dauerhaft im Nur-Lese-Modus einzufrieren. Er sollte nicht gelöscht werden: Der archivierte Container stellt den objektiven Nachweis dessen dar, was während des Projekts produziert und genehmigt wurde, und ist entscheidend für Audits, Rechtsstreitigkeiten und Übergaben an das Facility Management.

Wer autorisiert die Übergänge zwischen den Zuständen?

Die Genehmigungen hängen vom Übergang ab: Der Übergang WIP → Shared wird typischerweise vom Task Team Manager oder dem BIM-Koordinator genehmigt. Der Übergang Shared → Published wird vom Lead Appointed Party und/oder der Appointing Party (Auftraggeber) genehmigt. Der Übergang Published → Archived erfolgt gemäß den Regeln des Informationsblatts, typischerweise am Ende einer Phase oder eines Auftrags.

Was sind Task Teams, Lead Appointed Party und Appointing Party?

Dies sind die drei Ebenen von Informationsrollen, die durch die ISO 19650-1 definiert sind. Die Appointing Party ist der Auftraggeber, der die Informationen anfordert. Die Lead Appointed Party ist die Hauptbeauftragte (z.B. Generalunternehmer), die die anderen Parteien koordiniert. Die Task Teams sind die spezifischen Arbeitsteams, die die Informationscontainer produzieren (z.B. strukturelles Team, MEP-Team).

Wie wird die Nacharbeit eines Informationscontainers verwaltet?

Wenn während der Überprüfung eines Shared-Containers Nichtkonformitäten festgestellt werden, wird der Container in den Zustand WIP zurückversetzt mit den Korrekturhinweisen. Das Task Team nimmt die Änderungen vor und stellt den Container als neue Revision wieder in Shared. Der CRA-Zyklus beginnt von neuem. Der gesamte Verlauf — einschließlich des unterbrochenen Workflows — bleibt im Audit-Trail einsehbar.

Wie werden die Zustände im CDE dargestellt?

Eine fortschrittliche CDE-Plattform muss den Status jedes Informationscontainers sofort und eindeutig anzeigen, typischerweise durch Farbkennzeichnungen, Textlabels und Suitability-Codes, die direkt in der Dateiliste sichtbar sind. Außerdem sollte sie filterbare Ansichten nach Status sowie ein Projekt-Dashboard mit der aggregierten Statusverteilung bieten.

Was passiert, wenn ein Informationscontainer niemals den Status „Published“ erreicht?

Nicht alle Container erreichen den Status „Published“. Einige können im Status „WIP“ verbleiben oder vor der Freigabe gelöscht werden. Andere können geteilt werden, aber später durch neuere Versionen ersetzt werden, die an ihrer Stelle veröffentlicht werden. Wichtig ist, dass der Audit-Trail den tatsächlich durchlaufenen Weg jedes Containers dokumentiert.

Wesentliches Glossar

Appointing Party – Auftraggeber, die Partei, die Projektinformationen anfordert.

Archived – Endstatus des Informationscontainers: archiviert als schreibgeschichtliche Referenz.

CDE – Common Data Environment. Datenumgebungs-Management gemäß ISO 19650.

Informationscontainer – Basiseinheit von Informationen im CDE mit strukturierten Metadaten.

CRA – Check, Review, Approve. Prozess der Prüfung, Überarbeitung und Freigabe.

Lead Appointed Party – Hauptbeauftragte Partei, Koordinator des Informationsauftrags.

Published – Status des Informationscontainers, der für die vertragliche Nutzung freigegeben ist.

Revision code – Code zur Identifikation der Version des Containers (P01, P02, C01, C02…).

Rework – Rückführung des Containers in den Status WIP nach einer negativen Prüfung.

Shared – Status des Containers, der zur interdisziplinären Koordination geteilt wurde.

Suitability code – Eignungscode, der den Verwendungszweck des Containers angibt (S0-S7, A1-AN, B1-BN, CR, PR).

Task Team – Arbeitsteam, das einen spezifischen Informationscontainer erstellt.

WIP – Work in Progress. Anfangsstatus des Containers, in interner Bearbeitung im Team.