Проблема обычно обнаруживается не в офисе, а на объекте. Прораб открывает присланный PDF, видит старую раскладку перегородок и заказывает материал. Дизайнер уверен, что актуальная версия лежит «рядом», только называется план_финал_новый_2. Ошибка возникла раньше заказа: команда не договорилась, где хранится действующий документ и кто меняет его статус.
Папки сами по себе порядок не создают. Рабочий регламент должен связать три вещи: место файла, понятное имя и состояние документа. Если хотя бы одно звено выпало, сотрудник начинает уточнять в чате. Переписка быстро превращается в параллельный архив, который невозможно проверить после сдачи.
Один корень проекта
Для каждого объекта нужен один корневой каталог с постоянным кодом, например 26-014_Krylatskoe. Код не меняется вместе с названием жилого комплекса, фамилией заказчика или стадией работ. Его повторяют в документах и письмах, чтобы два объекта с похожими именами не смешались.
Внутри достаточно шести верхних разделов:
00_Admin— договор, бриф, график и протоколы решений;01_Input— обмеры, исходные планы и требования управляющей компании;02_Design— концепции, модели и рабочие материалы команды;03_Documentation— листы рабочего проекта по разделам;04_Specification— ведомости, подборы и согласования образцов;05_Issue— только официально выданные комплекты.
Нумерация удерживает разделы в одном порядке на сервере, в облаке и в локальной копии. Глубину лучше ограничить: если до нужного плана приходится открывать семь папок, люди сохранят копию на рабочий стол. В рабочих разделах допустимо деление по дисциплине, но не по сотруднику.
Имя файла без ребусов
Имя должно читаться слева направо без открытия документа: код проекта, дисциплина, содержание, стадия, номер версии. Например: 26-014_AR_PlanFurniture_WD_R03.pdf. Здесь AR обозначает архитектурный раздел, WD — рабочий документ, R03 — третью редакцию.
Дата полезна в комплекте выдачи, но плохо заменяет версию. Файл мог быть исправлен дважды за день, а системная дата меняется при копировании. Слова final, last и new тоже не дают проверяемой последовательности. После final неизбежно появляется final2.
Формат фиксируют в регламенте: один разделитель, латиница или кириллица, согласованный словарь дисциплин. Универсального набора сокращений нет. Работает тот, который команда понимает одинаково и не меняет от проекта к проекту.
Статусы вместо слова «финал»
Версия и статус отвечают на разные вопросы. R04 сообщает, сколько раз документ меняли. Статус показывает, что с ним разрешено делать. Студии обычно хватает четырёх состояний:
- WIP — работа внутри команды, выдавать наружу нельзя;
- CHECK — документ передан на внутреннюю проверку;
- APPROVED — согласован ответственным лицом, но ещё не выдан;
- ISSUED — включён в зарегистрированный комплект для заказчика или стройки.
Менять статус должен не автор листа, а назначенный проверяющий или руководитель проекта. Иначе автор одновременно выполняет работу и подтверждает её готовность. При возврате с проверки документ не перезаписывают: создают следующую редакцию, а замечания сохраняют в листе проверки или журнале задач.
Статус ISSUED нельзя присваивать одиночному файлу по просьбе из мессенджера. Он возникает только вместе с записью в реестре выдачи: номер комплекта, дата, получатель, состав листов и причина выпуска. Так через три недели можно установить, что именно видел подрядчик.
Как выдавать комплект
Каталог 05_Issue работает как неизменяемый архив. Каждая выдача получает отдельную папку: ISS-007_2026-08-18_Electrics. В неё копируют PDF и таблицы из согласованных рабочих разделов, добавляют реестр и после отправки закрывают для редактирования. Исходники остаются в работе; выданный пакет не обновляется «по-тихому».
Если после выдачи изменилась одна розетка, появляется новый комплект или официальное дополнение. Старый сохраняется. Для стройки это может казаться лишней формальностью, пока не возникает спор о том, по какому листу выполнен монтаж. Тогда история выдач заменяет поиск по чатам и устные воспоминания.
Перед отправкой руководитель проекта проверяет четыре позиции: совпадает ли номер редакции на листе и в имени файла, есть ли все листы в реестре, удалены ли комментарии и служебные слои, указан ли получатель. Проверка занимает несколько минут и ловит самые дорогие ошибки до объекта.
Регламент на одной странице
Новый порядок не стоит начинать с переноса всего архива. Выберите один активный проект и на неделю сделайте его пилотным. Создайте дерево папок, словарь дисциплин, таблицу статусов и шаблон реестра. Затем попросите сотрудника, который не ведёт объект, найти актуальный план света и последнюю официальную выдачу. Если ему нужна подсказка автора, структура ещё не работает.
Сам регламент помещается на одной странице. На ней нужны пример дерева, формула имени, права на смену статуса, порядок выдачи и правило архивации. Отдельно назначают владельца процесса: он разбирает исключения и обновляет словарь. Без владельца каждый новый проект постепенно возвращается к личным привычкам ведущего дизайнера.
Продуктовая интеграция: Экосистема ReFloor. При подборе напольных материалов студия может передавать партнёру не россыпь ссылок из чата, а зарегистрированный пакет: актуальный план, ведомость помещений, требования к основанию и статус согласования. Такой вход снижает риск, что подбор сделают по устаревшей площади или уже отменённой раскладке.
Новый участник должен за десять минут понять, где исходные данные, над чем сейчас работают и какой комплект ушёл на стройку. Всё, что приходится объяснять голосом, следует дописать в правила.
Что меняется в работе
Единая система не отменяет ошибок дизайнера, но делает их видимыми до выдачи. У документа появляется владелец, у изменения — номер, у отправки — запись. Самое полезное следствие проявляется на объекте: прораб больше не выбирает между тремя файлами со словом «финал», потому что рабочим считается только комплект из архива выдач.
Источники
- ISO 19650-1: принципы управления информацией и понятие единой среды данных.
- ISO 19650-2: требования к выпуску, проверке и обмену проектной информацией.
- Project Management Institute, Practice Standard for Work Breakdown Structures: правила иерархической декомпозиции проектной работы.
- Git Reference: различие между историей версий, метками и состоянием рабочей копии.
Обсуждение