Když se ve stavebnictví řekne CDE, často se tím myslí „máme složku na cloudu“. To je nebezpečně zjednodušené.

CDE – Common Data Environment, česky společné datové prostředí – není primárně místo. Je to řízený způsob, jak projektové informace vznikají, mění stav, schvalují se, předávají a archivují.

Od roku 2027 navíc pojem společného datového prostředí získává v Česku ještě větší význam v souvislosti se zákonem č. 330/2025 Sb.

Co musí dobré CDE vyřešit

Představte si běžnou situaci:

D.1.1_100_PUDORYS.pdf
D.1.1_100_PUDORYS_final.pdf
D.1.1_100_PUDORYS_final2.pdf
D.1.1_100_PUDORYS_OPRAVA.pdf
D.1.1_100_PUDORYS_REALLY_FINAL.pdf

Pokud se projekt dostane do tohoto stavu, problém není v názvu souboru. Problém je, že tým nemá spolehlivou odpověď na otázky:

  • která verze je aktuální,
  • která byla schválená,
  • kdo ji změnil,
  • co se změnilo,
  • pro jaký účel ji lze použít,
  • kdo ji převzal.

CDE musí tento chaos převést do řízeného procesu.

CDE není totéž co cloud storage

Cloudové úložiště řeší hlavně dostupnost souboru.

CDE musí navíc řešit jeho informační stav.

Příklad:

Soubor Revize Stav Účel
Model A P01 Work in progress interní práce
Model A S01 Shared koordinace
Model A A01 Published schválený výstup
Model A ARC Archived historie

Přesná terminologie se může lišit podle systému a projektu, ale princip je stejný: uživatel musí vědět, jakou důvěru může dané informaci přisoudit.

Co říká český zákon

Zákon č. 330/2025 Sb. v § 9 stanoví, že společné datové prostředí musí umožňovat mimo jiné:

  • správu informací o stavbě,
  • tvorbu transakčních protokolů a dalších systematicky uspořádaných záznamů chráněných proti zpětným změnám,
  • výběr a předání informačního modelu nebo jeho části prostřednictvím API.

To je velmi silný signál.

Budoucí CDE není pouze webová složka. Musí být schopné fungovat jako auditovatelná datová infrastruktura.

1. Identita informace

Každý důležitý informační kontejner potřebuje jednoznačnou identitu.

Nemělo by záležet jen na tom, že uživatel pozná soubor podle názvu.

Systém by měl pracovat s metadaty jako:

  • disciplína,
  • typ dokumentu,
  • část stavby,
  • revize,
  • stav,
  • autor,
  • datum,
  • účel vydání.

To umožňuje informace vyhledat a filtrovat bez ručního procházení stovek složek.

2. Revize a verze

Verze a revize nemusí být totéž.

Během práce může vzniknout mnoho interních verzí. Oficiální revize se mění při řízeném vydání.

Dobré CDE musí:

  • zachovat historii,
  • zabránit nechtěnému přepsání historie,
  • ukázat aktuální stav,
  • umožnit porovnání nebo dohledání změny.

„Přepsali jsme soubor novým souborem stejného názvu“ není robustní verzování.

3. Workflow schválení

Projektové informace procházejí kontrolou.

Typický proces může být:

Autor
  ↓
Interní kontrola
  ↓
BIM koordinace
  ↓
Vedoucí projektu
  ↓
Zadavatel / TDS
  ↓
Schváleno pro konkrétní účel

CDE by nemělo pouze zobrazit poslední soubor. Mělo by uchovat informaci, kdo co schválil a kdy.

4. Auditní stopa

Auditní stopa je jeden z nejcennějších prvků systému.

U významné operace by mělo být dohledatelné:

  • kdo ji provedl,
  • kdy,
  • nad jakým objektem,
  • jaký byl původní stav,
  • jaký je nový stav.

To pomáhá při:

  • reklamaci,
  • sporu,
  • interním auditu,
  • předávání mezi týmy,
  • zpětném hledání rozhodnutí.

5. Role a oprávnění

Ne každý má mít přístup ke všemu.

CDE typicky potřebuje jemnější logiku než „může otevřít složku / nemůže otevřít složku“.

Role mohou například určovat:

  • kdo smí nahrávat,
  • kdo smí měnit metadata,
  • kdo schvaluje,
  • kdo publikuje,
  • kdo vidí smluvně citlivé dokumenty,
  • kdo může exportovat celý model.

U velkých projektů je řízení oprávnění bezpečnostní i smluvní otázka.

6. API a integrace

API požadavek v zákoně je zajímavý, protože umožňuje propojit CDE s dalšími systémy.

Například:

CDE
 │
 ├──→ IFC checker
 │
 ├──→ Document review
 │
 ├──→ ERP / cost system
 │
 ├──→ Asset management
 │
 └──→ reporting / BI

Bez API často vzniká ruční export a import souborů, čímž se ztrácí aktuálnost a auditní stopa.

Jak vybírat CDE

Nezačínejte seznamem značek.

Začněte seznamem procesů.

Otázky pro výběr

Dokumenty

  • umí systém řídit revize a stavy?
  • umí metadata?
  • je historie neměnná a dohledatelná?

Modely

  • podporuje potřebné formáty?
  • lze model zobrazit bez authoring software?
  • umí issues a vazbu na model?

Workflow

  • lze definovat schvalování?
  • jsou notifikace a termíny?
  • lze workflow auditovat?

Integrace

  • existuje API?
  • jaké jsou limity?
  • lze data exportovat bez vendor lock-inu?

Bezpečnost

  • jak fungují role?
  • SSO?
  • logování?
  • retention?
  • zálohy?

Předání

  • co dostanete při ukončení smlouvy?
  • v jakém formátu?
  • zachováte metadata a historii?

Poslední otázka bývá podceňovaná.

Nejhorší implementace CDE

Typický neúspěšný scénář:

  1. vedení koupí licenci,
  2. nikdo nedefinuje workflow,
  3. vytvoří se 80 složek podle starého fileserveru,
  4. každý nahrává soubory jinak,
  5. metadata se nepoužívají,
  6. týmy si stejně posílají PDF e-mailem,
  7. při předání se exportuje ZIP.

Software byl nasazen. CDE proces ale nevznikl.

Doporučený implementační postup

1. Zmapujte současný tok informace

Odkud dokument vzniká? Kdo ho kontroluje? Kdo ho schvaluje? Kdo ho používá?

2. Omezte stavy

Nevytvářejte dvacet statusů. Začněte jednoduchým modelem, kterému rozumí celý tým.

3. Definujte metadata

Pouze ta, která opravdu využijete pro filtraci, reporting nebo automatizaci.

4. Nastavte role

Podle odpovědnosti, ne podle jména konkrétního člověka.

5. Vytvořte naming a revizní pravidla

A automaticky je validujte, pokud to systém umožňuje.

6. Pilotujte na reálném projektu

Ne na prázdném demo workspace.

7. Měřte obcházení systému

Pokud tým stále používá paralelní e-mailové předávání, zjistěte proč.

CDE a AI

AI může v CDE přinést zajímavé funkce:

  • vyhledávání přirozeným jazykem,
  • automatické metadata,
  • klasifikaci dokumentů,
  • sumarizaci změn,
  • porovnání revizí,
  • identifikaci chybějících dokumentů,
  • přípravu issue reportu.

Ale zásadní architektura musí zůstat deterministická.

AI nesmí rozhodovat, která revize je smluvně platná, jen na základě pravděpodobnosti. To musí být jednoznačný stav systému.

AIprojektant verdikt

Pokud vám někdo prezentuje CDE pouze jako „cloud pro BIM soubory“, ptejte se dál.

Dobrý systém musí pomoci odpovědět:

Co je to za informaci, v jakém je stavu, kdo ji změnil, kdo ji schválil a můžeme její historii prokázat?

Pokud tyto otázky systém neřeší, pravděpodobně používáte storage, ne plnohodnotné informační prostředí.

Zdroje