Привет, Хабр!

Меня зовут Александра Васильева, я руковожу группой BIM-поддержки в ПИК Технологии.

В этой статье я расскажу:

• что такое BIM-поддержка в ПИК и почему это не просто «техподдержка САПР» (системы автоматизированного проектирования);

• для кого мы работаем, какие задачи проектировщиков закрываем и зачем изучаем их боли;

• как устроен сервис: от приёма заявки до системной профилактики;

• какие метрики и дашборды используем, чтобы не тушить пожары, а предотвращать их;

• и почему по-настоящему эффективная поддержка — это та, куда почти не обращаются.

Почему вообще появилась BIM-поддержка

BIM-поддержка в ПИК — это сервисная команда, обеспечивающая стабильную, эффективную и предсказуемую работу проектировщиков за счёт экспертной помощи, аналитики и системной профилактики ошибок в BIM-среде.

Типичный сценарий в крупной проектной организации: проектировщик открывает файл и сталкивается с непонятной ошибкой. Казалось бы, в эпоху интернета решение можно найти за пару минут, просто «погуглив». С другой стороны, когда речь идёт о компании с более 2 тыс. специалистов из разных городов, такая ошибка легко становится цепной реакцией в условиях дедлайнов и общей модели.

До появления BIM-поддержки большинство технических вопросов решались «вручную» — через личные сообщения и звонки в духе «а можешь посмотреть?». Не было общей системы, фиксированных сроков и единого канала обращения. Всё держалось на энтузиазме отдельных специалистов и их личной вовлечённости. 

При этом сложность и уникальность нашей внутренней BIM-технологии создаёт множество вопросов даже у опытных проектировщиков. Без централизованной поддержки значительное количество времени тратилось на консультации и оперативные задачи, что замедляло не только повседневную работу, но и само внедрение новых решений. С ростом численности сотрудников и увеличением объёмов проектирования такой подход просто перестал работать.

Попытки проектировщика «разобраться самому» часто заканчиваются так:

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

• Риски срыва сроков. Особенно критично при работе над общими моделями, где задержка одного участника тормозит всю команду.

• Неконтролируемые изменения. «Костыльные» решения часто создают новые проблемы в будущем.

Чтобы избежать этих потерь, в ПИК была запущена BIM-поддержка — не просто точка реагирования, а сервис, встроенный в производственный процесс.

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

• Экспертная поддержка — решение сложных технических вопросов, требующих глубокого понимания специфики работы в САПР.

• Снижение нагрузки на проектировщиков — специалисты могут сосредоточиться на своей основной работе и не тратить время на технические мелочи.

• Профилактика проблем — анализ повторяющихся ошибок и их устранение на уровне систем, процессов и обучения.

Цифровая среда сегодня — это не просто вспомогательный инструмент, а основа всего проектного процесса. В этих условиях BIM-поддержка — уже не дополнительная служба, а ключевой элемент производственной системы компании, обеспечивающий её устойчивость и развитие.

Как устроен сервис BIM-поддержки

Чтобы BIM-поддержка работала как сервис, а не как «группа чатов», мы выстроили чёткую систему: с ролями, линиями ответственности, SLA (соглашением об уровне сервиса), аналитикой и постоянной обратной связью. Это не «доброжелательные эксперты по вызову», а производственный сервис, обеспечивающий бесперебойность цифрового проектирования.

В составе BIM-поддержки — профильные специалисты по направлениям, а не универсальные «люди на всё»:

• АР / АИ / ТХ — архитектура, технологии, интерьеры;

• КР — конструктив;

• ВК / ОВ / ЭОМ / СС — инженерные системы;

• ГП / НС — генплан и наружные сети.

Также есть чёткое должностное разделение:

• BIM-мастер — первая линия поддержки. Отвечает за типовые заявки.

• BIM-координатор — вторая линия. Решает нестандартные задачи и участвует в анализе сложных обращений.

• Ведущий BIM-координатор — третья линия. Курирует направление, распределяет нагрузку, обучает команду.

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

Несмотря на широкий спектр задач, BIM-поддержка — это не «решение всего подряд». Вот что входит и что не входит в зону ответственности команды:

 

Мы фокусируемся на поддержке пользователей, стабилизации среды и устранении технических препятствий в САПР ПО и BIM-процессах.

Все обращения попадают в централизованную систему — Jira. Никаких голосовых сообщений, личных чатов, «привет, можешь посмотреть». Это обеспечивает:

• прозрачность и отслеживаемость процесса;

• равномерное распределение нагрузки;

• контроль сроков исполнения;

• формирование аналитики и отчётности;

• соблюдение SLA (вплоть до критических заявок с временем реакции до 2 часов).

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

SLA: как мы управляем ожиданиями и приоритетами

Чтобы BIM-поддержка была предсказуемой и эффективной, мы работаем по принципу SLA (Service Level Agreement) — это внутренние стандарты времени реакции и решения заявки в зависимости от её приоритета.

SLA помогает:

• устанавливать прозрачные ожидания для пользователей;

• рационально распределять ресурсы внутри команды;

• измерять и контролировать качество сервиса;

• при необходимости — аргументировать приоритетность задач на стыке команд.

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

*Время ИТ (чистое время) = Время от создания заявки до предоставления решения 

Приоритет зависит от типа запроса (далее Подача), оценки диспетчера и сотрудника BIM-поддержки. Оценивается масштаб влияния (проблема у одного пользователя, группы или всей команды), срочность (влияние на срок сдачи документации), наличие типового решения или необходимости аналитики.

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

Путь заявки — от создания до решения 

1. Подача

Пользователь направляет запрос в Jira, выбирая тип из преднастроенного списка, основанного на аналитике частых обращений.

 

2. Распределение

Заявка попадает в диспетчерскую, где определяется направление, степень сложности и полнота данных. Распределение осуществляется по таблице зон ответственности и линий поддержки.

3. Назначение

Диспетчер фиксирует заявку за специалистом на ближайшее время в Jira-календаре с учетом приоритета (массовый сбой, срочная, типовая, обычная).

4. Обработка

Исполнитель работает с заявкой по очереди, ориентируясь на установленный приоритет (низкий → блокирующий).

5. Закрытие и аналитика

После решения исполнитель фиксирует пошаговый алгоритм и ставит теги. Эти данные потом идут в аналитику и отчёты.

Теги — как работают и для чего нужны

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

Основные теги, введённые в работу:

 

Теги позволяют:

• классифицировать заявки по категориям: раздел, ПО, симптом, тип решения и т.п.;

• группировать повторы без ручного анализа;

• формировать отчёты;

• собирать данные для аналитики и дашбордов (например, определить количество файлов, которые были восстановлены за прошедший месяц или количество заявок по работе с определённым плагином).

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

Опыт клиента — как пользователь узнаёт статус и получает фидбек

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

При смене статуса заявки или поступлении комментария от исполнителя также поступает уведомление:

При закрытии заявки статус соответственно меняется:

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

Наша цель — не просто «закрыть тикет», а выявить системную причину и устранить её. Повторяющиеся ошибки мы разбираем, фиксируем, оформляем в решения и инструкции. Так BIM-поддержка становится не просто оперативным каналом помощи, а механизмом устойчивости и самообучающейся системы.

Аналитика и дашборды: как мы предотвращаем ошибки

Если BIM-поддержка — это полноценный сервис, а не просто оперативная помощь, у неё должны быть метрики. Без аналитики даже самая доброжелательная поддержка со временем превращается в хаотичный чат, где всё держится на энтузиазме и ручном контроле.

Мы изначально строили систему с прицелом на управляемость и масштабирование. Поэтому все обращения фиксируются в Jira, а ключевые показатели регулярно собираются в дашборды. Это позволяет нам понимать, что именно, почему и как часто ломается. А значит — не тушить пожары, а предотвращать их.

Аналитика строится по нескольким ключевым срезам:

• Типы заявок. Помогают выделять системные ошибки, связанные с шаблонами, плагинами и технологиями.

• Производственная нагрузка и скорость обработки. Нагрузка влияет на скорость обработки заявки. Чем нагрузка выше, тем ниже может быть скорость обработки.

• Источники и причины проблемы. Анализируем, откуда растёт ошибка: из файла, инструмента, обновления или это «человеческий фактор».

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

Большинство аналитик выросли из реальных запросов пользователей. Вот ключевые виды:

1. Аналитика потенциально типовых запросов

Если заявка имеет высокий шанс повториться, она помечается как «потенциально типовая». Мы анализируем такие обращения, оформляем их в инструкции и пополняем базу знаний.

За 1-й квартал 2025 года было создано 7 новых инструкций, 9 обновлено. Это позволяет снижать количество повторных обращений и ускорять решение типовых кейсов.

2. Аналитика по времени открытия и весу файлов

В определённый момент количество жалоб на «долгое открытие моделей» резко выросло. Что мы сделали:

1. Сформировали дашборд, отслеживающий вес и скорость открытия по всем проектам.

2. Идентифицировали проблемные модели — по росту веса и резкому увеличению времени загрузки.

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

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

5. Сформировали отчёты с конкретными рекомендациями — они направляются главспецам и руководителям.

Вот как выглядит дашборд по времени открытия моделей:

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

3. Аналитика потенциальных рекрутов в Учебном центре ПИК

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

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

4. Предрелизное тестирование инструментов PikTools

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

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

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

5. Анализ загрузки Revit Server

Мы используем дашборды для мониторинга ключевых метрик — работоспособности серверов и времени открытия моделей. Это помогает нам оперативно реагировать на возможные проблемы и поддерживать стабильную работу серверов. Мы ведём мониторинг нагрузки на Revit-серверах (более 50 серверов, более 60 тыс. моделей, более 1 тыс. пользователей ежедневно). 

Для этого мы используем: 

• Дашборд RS Log для отслеживания состояния Revit Server в реальном времени (технические характеристики серверов, их загрузку и активность на них). С его помощью анализируем логи серверов для выявления «узких мест» и перенаправляем ресурсы в случае необходимости.
  

  

• Дашборд «План загрузки серверов» на основе объёмов и плановой трудоёмкости.
  

  

  
  

  

Это позволяет планировать размещение моделей и заранее выявлять перегрузки.

Можно заключить, что аналитика в BIM-поддержке — это не просто отчётность. Это инструмент, который позволяет:

• видеть повторяющиеся проблемы до того, как они вырастут в инциденты;

• устранять первопричины, а не бороться с последствиями;

• повышать зрелость сервиса и снижать количество обращений.

Именно поэтому наша цель — не «ответить быстрее», а сделать так, чтобы вопросов не возникало вовсе.

Ключевые выводы

1. BIM-поддержка — это не техподдержка, а производственный сервис
   
   Она не просто решает ошибки, а предотвращает их, анализируя причины и устраняя системные сбои. Это часть производственной цепочки, а не внешний помощник.

2. Проактивность важнее скорости реакции

   Сервис эффективен не тогда, когда быстро отвечает, а когда заявок становится всё меньше — за счёт обучения, инструкций, анализа и доработок.

3. Без системности поддержка не масштабируется

   Личные сообщения, чаты и «дружеская помощь» не работают в компании с более 2 тыс. проектировщиков. Нужны централизованные каналы (например, Jira), SLA и прозрачные правила.

4. Аналитика — это основа устойчивости

   Повторяющиеся ошибки, загруженность, «узкие места» процессов — всё это становится видно только через цифры. Метрики позволяют не тушить пожары, а избегать их.

5. Профильные специалисты и разделение ролей — ключ к эффективности

   Универсалы перегреваются и не успевают вникать в сложные кейсы. Узкое направление (АР, КР, ИОС) + понятная зона ответственности = стабильный результат.

6. Сопровождение внедрения технологий — не опция, а обязанность поддержки

   Без выделенного сервиса любые цифровые инновации буксуют: люди не успевают разобраться, начинают изобретать «костыли» и дублируют ошибки.

Рекомендации для тех, кто хочет запустить или прокачать BIM-поддержку:

• Определите нужды пользователей

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

• Стройте систему  на базе процессов, а не чатов

Введите единый канал (Jira, Helpdesk) и уберите личные сообщения как основной способ обращения. Зафиксируйте роли, SLA и регулярный ритм.

• Сделайте аналитику доступной и полезной

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

• Закладывайте «поддержку внедрения» в запуск любой технологии

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

• Думайте не о том, как ответить быстро, а как сделать так, чтобы не спрашивали

Профилактика — главный KPI зрелой поддержки. Разбирайте повторы, формализуйте инструкции, обновляйте шаблоны и гайды.

• Работайте не за проектировщика, а рядом с ним

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

Таким образом, настоящая BIM-поддержка — это не отдел, а функция зрелости всей проектной среды. Она работает не ради себя, а ради устойчивости бизнеса.