CDE простыми словами: зачем она, если есть общая папка

Среда общих данных без теории: статусы WIP, Shared, Published, права доступа, версии и счёт потерь от работы в обычной сетевой папке. Структура папок и права.

В папке проекта на сервере лежало четырнадцать файлов: АР_итог.rvt, АР_итог_2.rvt, АР_финал_испр.rvt и так далее. Вопрос «по какому файлу выпускали третий комплект» разбирали полтора часа втроём. Нашли по дате изменения, и то не наверняка.

Это не разгильдяйство, это нормальный итог работы в обычной сетевой папке. Папка не умеет хранить статус файла. Она хранит только имя, а имя пишет человек, у которого пятница и дедлайн.

Что такое CDE, если убрать красивые слова

Среда общих данных это место, где у каждого файла есть четыре вещи, которых нет в папке:

• Статус. Черновик, отдан на проверку, выпущен, архив.
• Версия. Не в имени файла, а в системе. Старые версии никуда не исчезают.
• Права. Кто может править, кто только смотреть, кто согласовывает.
• История. Кто загрузил, когда, что изменилось, кто скачивал.

Всё. Никакой магии, ни трёхмерности, ни искусственного интеллекта. CDE это дисциплина обращения с файлами, зафиксированная программно, чтобы её нельзя было нарушить второпях.

Вариантов много: от отраслевых платформ до связки облачного диска с продуманной структурой и регламентом. Разница в удобстве и цене, но принцип одинаковый.

Четыре состояния файла

Логика взята из ISO 19650, но её ценность не в стандарте, а в том, что она отвечает на вопрос «можно ли этому файлу верить».

Ключевой переход это WIP → Shared. Файл попадает в общий доступ не тогда, когда он готов, а тогда, когда автор его проверил и подписал: координаты на месте, мусор вычищен, версия обозначена. Именно этот шаг чаще всего и пропускают, а потом смежник берёт в работу чужой черновик.

Второй важный момент: Published никто не правит. Ни автор, ни ГИП, ни руководитель. Нужно изменение, выпускается следующая ревизия. Файл, лежавший в статусе «выпущено», остаётся неприкосновенным навсегда, потому что именно на него ссылаются акты, задания и переписка.

Что делает автор перед публикацией

Переход из WIP в Shared это не кнопка, а короткая процедура. Занимает 10-15 минут.

• Модель открывается без сообщений о потерянных связях.
• Координаты на месте, файл встаёт в общую сборку.
• Черновая геометрия и временные объёмы удалены или спрятаны в отдельный рабочий набор.
• Имя файла принятое, без хвостов вроде «испр» и «моё».
• В сопроводительной строке написано, что изменилось с прошлой публикации.

Последний пункт делают реже всего, а пользы от него больше всех. Одна фраза «переехала шахта в осях Б-В» экономит смежнику полчаса сравнения версий и один звонок.

Чем это отличается от общей папки

Сравнение по пунктам, которые реально болят.

Отдельно про доступ извне. Стоит подключить к проекту подрядчика или второго проектировщика, и сетевая папка перестаёт работать физически: обмен уезжает в мессенджеры и почту. Каждый такой обходной путь создаёт свою локальную копию правды.

Права: трёх ролей достаточно

Раздувать матрицу доступа не нужно. На типовом проекте хватает трёх ролей.

Автор раздела. Пишет в свою папку WIP, публикует в Shared. В чужие разделы доступ только на чтение. Это защищает от классики жанра: «я поправил у них стену, чтобы не ждать».

Координатор и ГИП. Читают всё, переводят статусы, публикуют выпуски, ведут папку координации с отчётами и протоколами. Как это стыкуется с встречами по коллизиям, разобрано в статье про регламент BIM-координации.

Про ссылки для внешних скажу отдельно. Доступ выдаём на конкретный адрес, а не ссылкой «для всех, у кого она есть». Ссылки пересылают, они живут годами и всплывают там, где не ждали. Срок доступа привязываем к этапу: закончился этап, доступ закрыли.

Внешний участник. Заказчик, подрядчик, эксперт. Видят только Published, скачивают, комментируют. В WIP и Shared им заходить незачем: сырой файл в руках заказчика оборачивается вопросами, на которые придётся отвечать неделю.

Версии: как выглядит на практике

Имя файла остаётся постоянным: AR_Building01.rvt. Версия живёт в системе, а не в названии. Слова «финал», «испр», «новый» из имён исчезают полностью, и это самая заметная перемена в первые недели.

Для выпущенных комплектов добавляется индекс ревизии: P01, P02 для стадии проектирования, C01 и дальше для выпущенного в производство. Каждая ревизия сопровождается одной строкой: что изменилось и почему.

Отдельное правило про выпуски: файл, ушедший заказчику, кладём в архив ровно в том виде, в каком его отправили, вместе с сопроводительным письмом. Через год спор «что именно вы нам сдавали» решается одним файлом, а не раскопками в почте.

История хранится вся. Место дешевле разбирательств: модель на 400 МБ с двадцатью версиями это 8 ГБ, то есть стоимость пары часов работы инженера в месяц.

Что кладут в среду, кроме моделей

Модели это половина содержимого. Вторая половина решает споры.

• Отчёты по коллизиям и протоколы координации, с датами.
• Задания смежникам и ответы на них.
• Замечания экспертизы и подтверждения устранения.
• Согласованные точки привязки, системы координат, расчётные допущения.
• Решения из переписки, хотя бы выжимкой в один абзац.

Правило одно: документ, влияющий на проектное решение, лежит в среде, а не в почте у автора. Через год проект будут разбирать по этим файлам, а почтовый ящик к тому времени может принадлежать уже другому человеку.

Пример структуры, которая работает и без платформы:

• 01_WIP, внутри папки по разделам: AR, KR, OV, VK, EOM.
• 02_SHARED, та же разбивка, дата публикации в имени вложенной папки.
• 03_PUBLISHED, по комплектам и ревизиям.
• 04_COORDINATION, отчёты, протоколы, файлы BCF.
• 05_INCOMING, всё пришедшее извне в исходном виде, без переименований.
• 99_ARCHIVE.

Права нарезаются по верхнему уровню. Пять правил вместо тридцати, и новичка не надо учить полдня.

Во что обходится отсутствие CDE

Считаем на команде из десяти человек.

Поиск актуального файла и уточнения в чате: 20-30 минут в неделю на человека. Это 4 часа в неделю на команду, около 170 часов в год.

Работа по устаревшей версии: 2-4 случая за средний проект. Каждый стоит от нескольких часов до недели переделки, если ошибка дошла до выпуска.

Восстановление после сбоя или случайного удаления: один раз за проект почти гарантированно. С бэкапом это полдня, без бэкапа считайте сами.

Плюс невидимая часть. На разборе «кто виноват» уходит время руководителя, а осадок остаётся у всей команды.

Три истории, которые повторяются

Выпустили по старой версии. Инженер скачал модель смежника в понедельник и работал по ней две недели. Новая вышла во вторник, о чём ему никто не сказал. Лечится не дисциплиной, а устройством: в общем доступе лежит одна актуальная версия, прошлые уходят в историю сами.

Файл затёрли. Двое открыли модель с сетевого диска, второй сохранил поверх первого. В среде общих данных вторая запись создаёт версию, а не убивает первую. Восстановление занимает минуту вместо вечера.

Заказчик увидел черновик. Кто-то отправил ссылку на папку целиком, а там незаконченный третий этаж. Права по верхнему уровню закрывают этот сценарий физически: внешний участник просто не видит WIP.

Признаки, что папки вам уже мало

• В именах файлов встречаются слова «финал», «новый», «испр» или номера версий.
• Вопрос «какой файл актуальный» звучит в чате чаще раза в неделю.
• Хотя бы раз за проект работали по устаревшей версии смежника.
• Модели уходят заказчику архивом по почте или через файлообменник.
• Никто не скажет за минуту, что именно сдавали в прошлый выпуск.

Три пункта из пяти означают, что нынешний порядок обмена уже стоит вам денег. Просто счёт за него приходит не бухгалтеру, а инженерам, часами их рабочего времени.

Где CDE не помогает

Она не наводит порядок сама. Платформа без описанных статусов и правил превращается в ту же папку, только платную и с более сложным интерфейсом. Мы видели среду, купленную на год, где все файлы лежали в WIP, потому что никто не объяснил людям, зачем нажимать «опубликовать».

Совместную работу в Revit среда тоже не заменяет. Центральный файл с рабочими наборами это другой механизм, и он живёт внутри раздела. CDE управляет обменом между разделами и организациями, а не одновременной правкой одной модели. Путать их вредно: попытка положить центральный файл в синхронизирующуюся облачную папку заканчивается повреждением модели.

На маленьких работах она не окупается. Команда из трёх человек на объекте в 500 квадратных метров прекрасно живёт на одном диске с внятной структурой папок. Смысл начинается от пяти разделов, от двух организаций в проекте или когда объект тянется дольше полугода.

Качество моделей средой не лечится. В ней прекрасно хранится плохая модель со статусом «выпущено». Проверку никто не отменял, механика описана в статье про коллизии в Navisworks.

Что обычно спрашивают

Обязательно ли покупать платформу? Нет. Первый проект честно проживается на том, что уже есть, если статусы и права описаны на бумаге. Платформа снимает ручную работу, а не заменяет правила.

Облачный диск подойдёт? Для файлов обмена и документов вполне. Для центрального файла Revit нет: синхронизирующий клиент рано или поздно его повредит.

Кто ведёт среду, если BIM-отдела нет? Тот, кто собирает выпуски: обычно ГИП или ведущий инженер. Работы там 2-3 часа в неделю на проект, отдельный человек не нужен.

Что делать с перепиской? Решения из почты и чатов переносить в среду выжимкой в один абзац. Полностью почту не победить, но ключевые договорённости должны лежать рядом с моделями.

Как быть с моделями подрядчиков? Отдельная папка входящих, куда они кладут файлы как есть. Переименовывать и править чужое нельзя: при разборе нужен оригинал в том виде, в каком он пришёл.

Сколько места закладывать? Считайте вес всех моделей на десять и добавьте половину на документы. Для среднего жилого дома это 200-400 ГБ на весь срок проекта.

С чего начать, не покупая платформу

Порядок, который мы советуем командам без опыта.

1. Опишите статусы на одной странице: что означает каждый, кто переводит, что проверяется перед публикацией.
2. Сделайте структуру папок под эти статусы на том, что уже есть: сервер, облачный диск, корпоративное хранилище.
3. Введите правило имени файла без слов «финал» и «версия2». Индекс ревизии только у выпущенных комплектов.
4. Проживите так один проект. Записывайте, где было неудобно.
5. Только после этого выбирайте платформу. Вы будете знать, какие функции нужны, а за какие вам продают воздух.

Обратный порядок, когда сначала покупают систему, а потом придумывают процесс, мы наблюдали несколько раз. Заканчивается это возвратом в сетевую папку через полгода.

Если хотите пройти этот путь быстрее, мы описываем структуру, статусы и правила под конкретную команду и помогаем внедрить их на первом проекте: смотрите услуги и частые вопросы про сроки и формат работы.

Напишите в Telegram или через контакты, расскажите, как сейчас устроен обмен файлами. Скажем, что менять в первую очередь и нужна ли вам платформа вообще.