Привет, Хабр! Меня зовут Станислав Пуртов, я заместитель директора по автоматизации проектного блока в ПИК.
В этой статье хочу кратко описать наш опыт формирования команды.
За последние 6 лет внедрения BIM в компании мы прошли путь от небольшой группы развития из 7 человек до самостоятельной дирекции численностью до 150 сотрудников. Прошли этапы исследования, робкого внедрения, агрессивного внедрения, внедрения на этапах кратного роста наших проектных институтов. И несколько кризисов!
Материал будет полезен руководителям BIM-направлений и руководителям проектных компаний, принявших непростое решение о переходе на BIM. Всех нюансов в одном рассказе не раскрыть — если после прочтения останутся вопросы, пишите мне или моим коллегам лично, и мы с радостью постараемся вам помочь.
Дисклеймер:
Все варианты, описанные ниже — это не теория из интернета, а наш реальный опыт и последовательно описанные этапы того, как менялась наша команда и наши подходы в зависимости от внешних факторов.
BIM-команда: что это и как работает
Большинство бенефитов от BIM-технологий возникают за пределами проектирования, но проектирование остается одним из самых важных этапов. Здесь формируются геометрия и данные, на основе которых реализуются дальнейшие BIM-сценарии.
К сожалению, когда у проектирования появляется приставка «BIM-», это часто превращается для проектировщиков в настоящее испытание.
Конечно, на первом этапе компания приглашает консалтера с рынка, проводит обучение, запускает пилотный проект, подводит итоги. Но затем взаимодействие с консалтером переходит в режим точечной поддержки, а проектировщик остается наедине как со своими старыми проблемами, так и с новыми BIM-проблемами, которые в моменте приходится решать самостоятельно.
И здесь наша первая простая истина.
Простая истина #1. Во главе BIM процесса стоит тот, кто зарабатывает деньги
Сроки проектирования берутся не с потолка. Как правило, они завязаны на сроки строительства. Если проектировщик переходит на BIM, это не значит, что ему позволят раздуть сроки выдачи документации. Соответственно, переход должен проходить так, чтобы проектировщик оставался проектировщиком — и мог сохранять фокус задач.
Вокруг проектировщика должна быть организована такая среда, которая будет позволять ему делать то, что он умеет делать хорошо. А все сопутствующие вопросы, связанные с BIM-технологиями, должны быть делегированы инструментам или команде BIM-специалистов.
Простая истина #2. За BIM-командой должны быть закреплены конкретные функции и полномочия
Зачастую при внедрении компания забывает чётко сформулировать, что именно делает отдел BIM. Можно найти множество примеров, когда команда есть, а изменений нет. Поэтому важно, чтобы за командой по BIM были закреплены конкретные процессы, функции и полномочия.
Ещё на берегу нужно зафиксировать, какие конкретно у BIM-команды роли в процессе проектирования и достаточно ли у неё полномочий, чтобы менять процессы и инфраструктуру.
Если коротко, BIM-команда должна иметь возможность забрать на себя задачи:
создание среды проектирования (в т.ч. контроль правил именования / хранения / передачи);
формирование BIM-технологии и регулярная адаптация её под проектировщика и заказчика;
выполнение сложных операций проектирования, связанных с BIM-технологией (координация / проверки на коллизии / параметризация / и т.п.);
анализ рутин и автоматизация;
взаимодействие с BIM заказчика или подрядчика;
изменение процессов.
Формирование BIM-команды
В BIM-команде существуют три основных должности:
BIM-менеджер
BIM-координатор
BIM-мастер
Далее, в зависимости от размера вашей компании и того, насколько вы продвинулись в технологиях, могут быть несколько вариантов сочетания команд, инструментов и компетенций.
Вариант №1. Маленькая компания / Зачатки BIM
Инструменты:
Внешние.
Шаблоны ADSK в сочетании с известными линейки плагинов (ModPlus, BIMStep, FutureBIM и т.п.)
Недостающие компетенции (ресурс):
В случае необходимости в разработке специфических инструментов, библиотек семейств и т.п. привлекается подрядчик.
Команда:
Один BIM-менеджер, отвечающий за все вопросы по всем дисциплинам.
Вариант №2. Компания среднего размера / Внедрён BIM
Инструменты:
Для средней компании по-прежнему эффективно применять внешние инструменты.
Недостающие компетенции (ресурс):
В случае необходимости в разработке специфических инструментов, библиотек семейств и т.п. привлекается подрядчик. Но здесь уже важно начинать развивать внутренние компетенции, обучать BIM-специалистов и разрабатывать собственные плагины.
Команда:
BIM-менеджер. Отвечает за управление командой, инфраструктуру, взаимодействие с заказчиками и подрядчиками, является идеологом BIM-требований и технологии.
BIM-координаторы по дисциплинам. Отвечают за нюансы технологии, обучение, поддержку проектировщиков, разработку семейств и т.д.
BIM-мастера (опционально). В случае есть постоянный запрос на разработку семейств.
Вариант №3. Большая компания / Индустриальный BIM
Инструменты:
Крупные компании характеризуются сложной спецификой процессов, многообразием инструментов в смежных подразделениях. На стороне проектирования должны формироваться собственные специфические продукты — и, соответственно, собственная команда разработки. Для автоматизации мелкой рутины допустимо использование внешних инструментов.
Недостающие компетенции (ресурс):
Подрядчик (в исключительных случаях).
Команда:
С точки зрения организации команды есть два подхода.
Подход 3.1: Клонировать звенья под объекты
На каждый объект (группу объектов) собирается своя команда (или звено) аналогичная варианту №2.
Процессы и должности в таких командах привычные и простые, что дает следующие плюсы:
Возможность быстро подключать новые команды на новые объекты.
Команда HR уже имеет опыт подбора спецов.
Возможность нанимать готовых крутых специалистов с рынка, с запросом на опыт управления командой.
Минусы:
Сложность роста. В такой структуре очень узкая вертикаль роста, а расти в горизонталь нет смысла, так как соседние команды занимаются теми же задачами.
Команды заняты конкретным объектом, снижена потребность команд во взаимодействии. Как следствие, могут формироваться разные базы знаний, разрабатываться аналогичные инструменты и т.п.
Высокая средняя стоимость сотрудников.
Подводя итог: способ рабочий, лёгок во внедрении на этапе активного роста, но приводит к выгоранию в долгосрочной перспективе. А еще когда рост компании замедлится, вы начнете ощущать, что это дорого.
Подход 3.2: Перевод обязанностей на отдельные должности
Здесь команды создаются по дисциплинам и по зонам ответственности — мы отказываемся от сотрудников-многостаночников в угоду более крепкой и гибкой организационной структуры.
У каждого специалиста своя роль и задачи, которые чаще всего не пересекаются с другими сотрудниками, а дополняют их. Например, мы вводили должность BIM-технолога, который занимался только проработкой технологии. Ограничив пул задач сотрудников, мы получали более качественный продукт.
Если пытаться нарисовать схему такой команды, то выглядеть она будет сложнее. Но плюсов у такого варианта гораздо больше. Главный — возможность расти вертикально и горизонтально, создавая новые зоны ответственности.
Допустим, компании нужно разработать специфическую технологию, а этот процесс требует полного рабочего дня как минимум одного специалиста. В таком случае бессмысленно разбрасывать задачи на многих сотрудников. Лучше нанять одного человека, который возьмёт на себя эту задачу.
У каждого специалиста появляется возможность проявить инициативу и взять на себя ответственность за какую-то новую зону. Если много специалистов работают над одной задачей — у них появляется руководитель. Если компания построила собственную серверную, то нужен отдельный человек, который о ней позаботится.
Еще можно сделать группу, которая занимается только разработкой семейств. Таким образом, мы избегаем ситуаций, когда соседи по офису делают одно и то же.
Правда, минусы тоже есть, но они сводятся к сложности наращивания. Узкопрофильных специалистов искать сложнее и дольше. А ещё сложнее объяснить команде подбора, какой именно сотрудник нужен.
Попробуйте объяснить HR разницу между BIM-аналитиком и BIM-технологом — поймете, о чем речь.
Для удобства сравнения двух вариантов представим их в виде небольшой таблицы:
Почти по всем ключевым позициям вариант №2 выигрывает. Вот несколько пунктов, на которых также хотелось бы остановиться подробнее.
«Скорость выгорания сотрудников». В первом подходе специалист зарабатывает больше, но находится в стрессе из-за постоянно меняющихся задач и сложности карьерного роста. Сотрудники довольны в короткой перспективе, но подвержены эмоциональному выгоранию в долгосрочной.
Во втором подходе наблюдаем обратную ситуацию. За понятные задачи работодатель платит меньше, плюс однообразие задач может демотивировать. Но при этом для инициативных специалистов всегда есть возможность роста как в обязанностях так и в доходе.
«Требуемая численность подразделений». Когда объём проектирования быстро растёт, команду наращивают самым простым способом (вариант 3.1) и инвестируют в неё много денег. Но когда рост замедляется, инвестор начинает думать об эффективности и искать «жирок».
Когда такое произошло у нас, мы заморозили численность проектировщиков и начали думать, как нам стать не таким дорогим IT, но при этом выполнять функции, которые от нас требуют. Здесь также второй подход становится более выигрышным.
Какой подход выбрать?
Лучше всего на вопрос ответит этот мем:
Круто, если вам подойдет какой-то из наших вариантов. Но надо понимать, что в каждой компании есть своя специфика. Возможно, у вас родится новый подход.
В любом случае, в развитии любой команды, важно:
Зафиксировать зоны ответственности команды и возможность влиять на различные процессы.
Сохранять гибкость для возможности быстро адаптироваться к контексту.
Думать о счастье сотрудников не только в моменте, но и в долгосрочной перспективе.
Давать возможность роста тем, кто к этому стремится.
Помнить, что целью любой автоматизации является экономическая эффективность компании.
Если вам помогла эта статья, если вы нашли лучшие решения или хотите что-то обсудить, пишите! Мой контакт — t.me/purtovsy.