Модель прав доступа Autodesk Docs для подрядчиков: папки и роли

Какая проблема с доступом подрядчиков возникает чаще всего

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

Дальше появляется привычка выдавать доступ "на всякий случай". Подрядчику дают больше прав, чем нужно, чтобы он не упирался в ограничения на каждом шаге. Потом подключается субподрядчик, ему копируют те же права. В какой-то момент кто-то открывает общий доступ к папке с исходниками, сметами или рабочими версиями, и границы ответственности стираются.

Риски здесь обычно не теоретические. Самые частые:

• утечки данных (скачали не то, отправили не туда, сохранили локально без контроля);
• случайные правки или удаление (особенно если есть права на загрузку и замену файлов);
• потеря ответственности (сложно понять, кто делал изменения и по чьему поручению, если роли размыты).

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

• выдается по роли, а не по фамилии;
• ограничивается папкой, а не всем проектом;
• получает срок действия сразу при выдаче;
• оставляет понятный след в аудите, чтобы потом быстро разобраться.

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

• Заказчик: читает согласованные материалы и принимает, без доступа к рабочим черновикам.
• ГИП или руководитель проекта: видит все разделы, управляет процессом согласований.
• Подрядчик: работает в своей зоне, загружает результаты, но не трогает чужие разделы.
• Субподрядчик: доступ еще уже, часто только чтение или загрузка в одну папку.

Если такого каркаса нет, любая схема со временем расползается в исключения: каждому добавили "чуть-чуть", а потом уже невозможно аккуратно закрыть доступ, не сломав работу.

Принципы модели доступа, чтобы она жила весь проект

Схема прав в Autodesk Docs работает устойчиво только тогда, когда ее можно поддерживать без героизма. Базовый принцип простой: сначала строите понятный каркас папок, и только потом накладываете на него роли и права. Если начать с раздачи прав конкретным людям, структура быстро превратится в набор исключений, которые никто не помнит.

Сначала каркас папок, потом роли

Папки должны отражать то, как проект живет в реальности: по этапам (например, концепция, проект, рабочая документация, строительство) и по дисциплинам (АР, КР, ОВиК, ЭОМ и так далее). Тогда подрядчика можно подключать ровно к его "куску" работы, не открывая лишнего.

Отдельно разведите "рабочее" и "для выдачи". Рабочие файлы постоянно меняются, там много черновиков и промежуточных версий. Папка "для выдачи" должна быть спокойной зоной, куда попадает только то, что можно официально передать: пакеты, PDF, согласованные модели. Тогда подрядчик не скачает неактуальный файл, а заказчик не увидит то, что еще рано показывать.

Минимально необходимый доступ как правило, а не просьба

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

Чтобы модель держалась весь проект, договоритесь о правилах заранее:

• подрядчик получает доступ только к своим папкам и только на свой этап работ;
• все выдачи наружу идут через папку "для выдачи", а не из рабочих папок;
• права расширяются только по заявке и с понятной причиной, не "на всякий случай";
• у каждой папки есть владелец со стороны заказчика или генподрядчика;
• любое исключение фиксируется: кто дал, кому, зачем и на какой срок.

Кто утверждает схему и кто поддерживает

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

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

Структура папок: простой каркас, который не ломается

Хорошая структура папок решает половину задач доступа. Когда подрядчику выдаются права не на "все подряд", а на понятные зоны, модель становится управляемой и не требует ежедневной ручной проверки. В Autodesk Docs удобнее думать не "кто что увидит", а "в какую папку это попадет".

Обычно работает каркас из нескольких верхних разделов. Важно, чтобы они отражали статус материалов, а не список людей или организаций:

• Общие (правила, шаблоны, справочники, контакты)
• По дисциплинам (рабочие материалы команд)
• Для согласования (пакеты на проверку и комментарии)
• Для выдачи (утвержденное, то, что можно использовать на площадке)
• Архив (закрытые этапы и устаревшие версии)

Главный принцип: отделяйте "исходники" от "опубликованного". Исходники живут в папках дисциплин и доступны только тем, кто реально редактирует. В "Для выдачи" должно лежать только то, что можно брать в работу без лишних вопросов: утвержденные PDF, спецификации, отчеты, снимки моделей.

Для обмена с подрядчиком выделите отдельную зону, чтобы не раздавать доступ ко всему дереву. Часто удобна схема "две папки на подрядчика":

• "Входящие" - что подрядчик присылает.
• "Исходящие" - что вы ему передаете.

Во "Входящих" обычно достаточно разрешить добавление файлов (без просмотра чужого). В "Исходящих" наоборот: чтение и скачивание без правки.

Именование папок тоже влияет на контроль доступа. Если названия размытые, люди начинают складывать туда все, и вам приходится расширять права. Обычно хватает простых правил: код раздела или этапа в начале (AR, KR, MEP, Stage-01), статус в конце (WIP, Review, Issue, Archive) и отдельная папка "00_README" с короткими правилами.

Если хотите, чтобы схема повторялась от объекта к объекту, сделайте шаблон структуры под типовой проект. Тогда при старте меняются роли и сроки, а не дерево папок.

Роли и права: как раздать доступ без лишних привилегий

Роли в Autodesk Docs полезно воспринимать как набор действий, а не как должность. Одна и та же компания может быть подрядчиком по монтажу и при этом вести авторский надзор по своему разделу. Поэтому роль задают под задачу и конкретные папки, а не "чтобы было".

Базовый набор, который чаще всего закрывает потребности проекта: администратор (управляет доступами), заказчик (читает и утверждает), проектировщик (готовит и публикует документацию), подрядчик (получает актуальные материалы и сдает результаты), наблюдатель (только просмотр). Важно, чтобы администраторов было мало, а наблюдателей - много, если людям нужно просто видеть прогресс.

Самая частая ошибка - дать подрядчику широкий доступ "на всякий случай", чтобы не отвлекаться на запросы. Но права в Docs различаются по смыслу, и это помогает выдать ровно то, что нужно: просмотр, скачивание, редактирование, публикация. Публикация почти никогда не нужна подрядчику, если он не выпускает проектную документацию.

Практичный подход простой: сначала определить, что подрядчик должен сдать и где это должно появиться. Тогда права выдаются на папку с актуальными исходными (чтение) и на папку сдачи (загрузка), а остальное остается закрытым или доступным только для просмотра.

Минимальный профиль для подрядчика в большинстве случаев

Обычно хватает следующего:

• чтение и скачивание в папках "Для выдачи", чтобы брать актуальную версию;
• загрузка и замена файлов только в папке "Сдача подрядчика";
• запрет на удаление, особенно на больших проектах;
• отсутствие прав на публикацию, если выпуск и контроль версий делает проектировщик или BIM-координатор;
• отдельная папка для рабочих черновиков и переписки, чтобы они не смешивались с официальным.

Субподрядчиков и временных специалистов лучше выделять в отдельные роли, даже если они работают на одну компанию. Так проще поддерживать порядок, чем потом вычищать лишние доступы по всему дереву.

Чтобы не скатиться в модель "всем все можно", держите несколько правил неизменными:

• администратор управляет доступами, а не работает с файлами;
• публикует только тот, кто отвечает за выпуск документации;
• права выдаются на конкретные папки, не на весь проект;
• все, что не нужно для задачи, закрыто по умолчанию;
• исключения оформляются как отдельная временная роль, а не как правка основной.

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

Сроки доступа: правила на входе, продление и закрытие

Сроки доступа лучше задавать как часть модели. Иначе подрядчики остаются в проекте дольше нужного, а админы тратят время на ручные отключения. Удобнее мыслить периодами работ: когда доступ открывается, к каким папкам и что считается поводом его закрыть.

Доступ по этапам проекта

Проще всего привязать доступ к этапам. У каждого этапа должен быть свой минимум папок и свой срок.

• Тендер: чтение ТЗ и исходных данных без доступа к рабочим чертежам и внутренним протоколам.
• Мобилизация: добавляются планы, требования по охране труда, шаблоны отчетов.
• СМР: доступ к рабочим папкам своей дисциплины плюс обменные папки.
• Сдача: загрузка исполнительной документации и закрывающих актов, остальное - по необходимости.
• Гарантия: чтение финальных версий и работа по замечаниям без права правок.

Так появляется понятный ответ на вопрос "когда открывать и закрывать доступ": по переходу этапа, а не по просьбе в чате.

Временные окна для чувствительных папок

Есть папки, которые нужны на короткий срок: коммерческие предложения, ведомости объемов, итоговые сметы, претензионная переписка. Для них удобно вводить временные окна доступа: например, чтение на 5 рабочих дней для согласования, затем возврат к закрытому состоянию.

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

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

Ориентир простой: если вы не можете за 30 секунд объяснить, почему у подрядчика доступ еще открыт, значит срок не задан или не контролируется.

Пошаговая настройка модели доступа в проекте

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

Дальше настройка идет быстрее, если использовать повторяемые заготовки: один каркас папок и несколько базовых ролей.

Шаги настройки

1. Подготовьте шаблон папок и определите, что лежит в верхнем уровне. Сразу решите, где рабочие материалы, где согласования, где финальные версии.

2. Создайте базовые роли по смыслу (например: "Просмотр", "Загрузка и комментирование", "Редактирование в рабочей зоне", "Администратор проекта"). Права описывайте простыми глаголами: смотреть, загружать, менять, удалять.

3. Назначайте роли группам, а не отдельным людям, где это возможно. Группа = один подрядчик или одна функция (например, "Проектировщик ОВиК - подрядчик А"). Тогда замены сотрудников не превращаются в ручную рутину.

4. Настройте права на верхнем уровне и проверьте наследование вниз по структуре. Если приходится чинить доступ на каждой папке, значит каркас папок или роли выбраны неудачно.

5. Проверьте доступ тестовым пользователем: что видно в папках, какие действия доступны, можно ли случайно удалить или перезаписать важное.

После этого зафиксируйте правила в коротком регламенте на 1-2 страницы: кто создает группы, кто утверждает доступ, за сколько дней запрашивать расширение прав, что считается основанием для закрытия доступа.

Типичные ошибки и ловушки при доступе подрядчиков

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

Вторая ловушка - когда в одной папке лежат и рабочие версии, и материалы "на выдачу". Подрядчик берет не тот файл, вы правите не ту модель, а спор потом выглядит как "кто последним загрузил, тот и виноват".

Самые болезненные промахи

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

Еще один тихий риск - отсутствие владельца процесса. Если никто не отвечает за изменения прав, они копятся хаотично: один админ добавил доступ "на всякий случай", другой забыл снять, третий создал новую папку без корректного наследования.

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

Как обезопасить проект за один час

Если быстро привести доступы в порядок, начните с пяти проверок:

• доступ выдавайте только на нужные папки, а не на верхний уровень проекта;
• разделите "Работу" и "Выдачу";
• запретите удаление и переименование для подрядчиков в папках, которые задают структуру;
• назначьте владельца прав (и резервного) с понятным регламентом изменений;
• ставьте дату окончания доступа сразу при приглашении и проверяйте ее хотя бы раз в неделю.

Журнал действий часто есть, но "никто не знает, что искать". Для старта хватит трех сигналов: массовые загрузки или скачивания, переименования и удаления, неожиданные перемещения файлов между папками.

Пример: подрядчику по инженерии нужен доступ только к "03_Модели/ОВ" и "05_Выдача/ОВ". Если он внезапно перемещает файлы в "01_Админ", это повод быстро уточнить, кто и зачем получил лишние права.

Аудит действий: что смотреть и как не утонуть в событиях

Аудит в Autodesk Docs нужен не для тотального контроля, а чтобы быстро отвечать на простые вопросы: кто что сделал, когда и с каким файлом.

Чаще всего полезно смотреть два слоя истории:

• активность внутри Docs по файлам и папкам: загрузки, скачивания, создание новых версий, перемещения и удаления;
• административные изменения на уровне проекта: добавление людей, изменения ролей и прав.

Чтобы проверка занимала 10-15 минут в неделю, задайте ритм и простые фильтры. Например, один ответственный просматривает события только по папкам подрядчиков за последние 7 дней и углубляется точечно, если видит необычное.

Рутина, которая обычно работает:

• еженедельно: активность по ключевым папкам подрядчиков;
• после дедлайнов: выборочная проверка новых версий по критичным файлам;
• при инциденте: история конкретного файла и связанные скачивания;
• раз в месяц: сверка административных изменений прав.

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

Если нужно собрать доказательства для разбора, фиксируйте одно и то же: дата и время, пользователь и компания, путь к папке, имя файла, номер версии, действие (скачал, загрузил, удалил) и чем подтверждается (история файла, журнал активности, скриншот). Обычно этого достаточно, чтобы восстановить цепочку событий.

Пример сценария: один проект и несколько подрядчиков

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

Папки сделали одинаковыми для всех разделов. В верхнем уровне две зоны: "Для выдачи" и "Рабочие". В "Для выдачи" лежат утвержденные исходные данные и актуальные версии. "Рабочие" устроены по разделам и стадиям, но доступ туда ограничен.

Маршрут файлов закрепили заранее: подрядчик не кладет ничего напрямую в рабочие папки проектировщика. Он сдает материалы через "Входящие" своей дисциплины, а ответственный со стороны генпроектировщика проверяет и переносит дальше.

Роли настроили под задачи:

• Подрядчик по электрике: чтение в "Для выдачи" и загрузка в "Входящие/Электрика".
• Подрядчик по ОВиК: загрузка во "Входящие" плюс право обновлять файлы в своей зоне "Рабочая/ОВиК/Черновики" (без доступа к "Для выдачи").
• Подрядчик по слаботочке: только "Для выдачи" и "Входящие/СС".

Срок доступа каждому подрядчику выдают на 60 дней. Продление - только по заявке: руководитель работ подтверждает участие, администратор продлевает на следующий период. Если заявки нет, доступ закрывают по правилу.

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

Быстрый чеклист и следующие шаги

Если модель настроена правильно, доступ подрядчиков в Autodesk Docs работает предсказуемо: людям хватает прав для работы, а риск случайных удалений и утечек заметно ниже. Перед стартом этапа и после каждой смены подрядчика полезно пробежаться по короткой проверке.

Короткий чеклист перед запуском работ

• Папки: есть каркас (входящие, рабочие, согласование, выдача, архив), а критичные зоны отделены от рабочих.
• Роли: подрядчики добавлены группами, а не набором отдельных пользователей.
• Права на действия: понятно, кто может загружать, заменять версии и удалять. Удаление включено только там, где это действительно нужно.
• Доступ по времени: у каждого подрядчика есть дата окончания, правило продления и план закрытия.
• Аудит: назначен ответственный и понятны признаки, которые требуют проверки.

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

Следующие шаги, чтобы не возвращаться к ручной рутине

Чтобы процесс переживал отпуск администратора и смену команды, закрепите стандарт:

• шаблон проекта (структура папок, роли, базовые права, правила именования);
• владелец процесса (и резервный), плюс понятный канал для заявок;
• правило двух вопросов для выдачи прав: что человек делает и на какой срок;
• простые метрики контроля: сколько активных подрядчиков, сколько просроченных доступов, сколько ролей с правом удаления.

Если нужна помощь с внедрением Autodesk Construction Cloud и настройкой прав под внутренние регламенты, это часто делают вместе с системным интегратором. Например, GSE.kz занимается комплексными ИТ-решениями и интеграцией, и такую задачу можно включить в общую настройку проекта вместе с поддержкой и регламентами.