В крупных девелоперских компаниях среда общих данных (СОД) появляется не тогда, когда просто «хочется порядка», а тогда, когда проекты действительно начинают терять свою управляемость. Документация есть, процессы описаны, роли распределены, но внутри команды все чаще возникает вопрос — на основании какой версии документа сейчас принимаются решения?
Пока этот вопрос возникает на уровне отдельных специалистов, ситуация кажется контролируемой. Когда он появляется у руководителей проектов и ГИПов, становится ясно: проблема не в объеме данных и не в дисциплине сотрудников. Ключевая сложность — в отсутствии единого пространства, где зафиксированы: статус документа, его версия, история изменений и ответственность участников.
В этом материале пресейл-инженер Sarex Дарья Демьянова делится классической методологией внедрения СОД — поэтапным подходом, основанным на практическом опыте девелопера из Санкт-Петербурга, который позволил избежать типовых ошибок уже на старте проекта.
Шаг 1. Рабочая группа
Одна из самых частых ошибок на старте — формирование рабочей группы. Например, в рабочую группу «на всякий случай» сразу включают максимальное количество участников: представителей всех подразделений, подрядчиков, будущих пользователей. В результате — обсуждения растягиваются, решения размываются, а система настраивается как компромисс между десятками мнений. Ответственность за итоговую логику при этом размыта.
Обратный пример: рабочая группа, наоборот, оказывается слишком маленькой. Так, в одном из проектов по внедрению СОД в крупной девелоперской компании настройка начиналась с двух человек. Структура была выстроена, маршруты согласований настроены, но уже на этапе демонстрации руководству стало ясно, что часть процессов не соответствует реальной работе. Согласующие не участвовали в проектировании маршрутов, и логика согласований не совпадала с фактическими сценариями. В результате после настройки систему пришлось пересобирать, теряя драгоценное время.
Оптимальный вариант рабочей группы — небольшая, но функциональная команда. В нее входят те, кто отвечает за движение документации и может принимать решения, а также те, кто разбирается в процессах и структуре: представители проектного управления, специалисты по настройке системы и т.п.
Такая группа позволит с самого начала грамотно и функционально выстроить процессы, чтобы они соответствовали реальности.
На старте внедрения СОД достаточно 5–7 человек, чтобы быстро принимать решения, но при этом достаточно компетентных, чтобы эти решения не пришлось переделывать завтра.
Остальные участники подключаются позже — когда базовая логика уже выстроена и протестирована. Такой подход снижает сопротивление и упрощает дальнейшее масштабирование системы.
Шаг 2. Структура данных
Распространенная ошибка — стремление сразу выстроить «идеальную» структуру в СОД, рассчитанную на все возможные сценарии. Попытка учесть каждую деталь оборачивается сложной и перегруженной иерархией, в которой пользователи начинают путаться уже на этапе обучения
В рассматриваемом кейсе на старте также обсуждалась сложная, детализированная иерархия, учитывающая десятки вариантов работы с документацией. От этого подхода отказались сознательно — за основу взяли текущую логику хранения документации в девелопере, но упростили ее до управляемого минимума.
Ключевым решением стало разделение работы с документами и хранения утвержденных версий. Пока файл находится в работе, он живет в пространстве, где допустимы замечания, комментарии. После согласования система фиксирует итоговую версию в отдельном разделе, который становится единственным источником правды для проекта.
Такой подход минимизирует риск того, что участники проекта будут использовать устаревшую версию документа в работе.
Отдельное внимание было уделено шаблонам. Проект в СОД не собирается каждый раз вручную. Формируется типовая структура, которая копируется для новых объектов. Это позволяет обеспечить единый подход ко всем проектам и существенно снижает нагрузку на администраторов.
Структура документации в СОД Sarex
Шаг 3. Ролевая модель
При настройке прав доступов компании часто переносят в систему существующую оргструктуру, создавая отдельные роли под каждую должность. Платформа это позволяет, и в ряде случаев такой подход оправдан. В описываемом проекте команда также начала с детализированной модели, где роли полностью соответствовали штатным позициям.
Однако при большом числе должностей администрирование быстро становится ресурсозатратным. Любое изменение состава команды требует ручной корректировки, а управление правами превращается в самостоятельное направление работы.
Уже в первые недели эксплуатации стало ясно: модель перегружена, пользователи путаются в доступах, а поддержка структуры требует постоянного вмешательства администратора.
В результате роли были укрупнены. Теперь они отражают не должности, а тип доступа и функциональную роль в процессе работы с документацией. Автор, проверяющий, согласующий, наблюдатель — эти роли описывают реальные сценарии взаимодействия с информацией. Они настраиваются один раз и применяются ко всем проектам. При подключении нового участника достаточно назначить роль, и необходимый уровень доступа вступает в силу автоматически.
Роль — это инструмент группировки пользователей по функционалу и доступам. Она может соответствовать должности, но не обязана полностью повторять оргструктуру.
В компаниях с 10–20 ключевыми позициями модель «по должностям» управляемая, а при большем числе позиций именно «укрупнение» снижает нагрузку на администрирование и упрощает сопровождение системы. В данном проекте такой подход показал свою эффективность.
Распределение прав доступа в рамках ролевой модели
Остальные шаги методологии — в полной версии на сайте Sarex.