ПИМ ⚪️ Место, где мечты заказчика встречаются с техническими возможностями исполнителей

ПИМ – план реализации проекта с использованием информационного моделирования. Может напоминать BEP, адаптированный под российские реалии.

Нужен, чтобы все участники инвестиционно-строительного проекта (ИСП) действовали не как привыкли, а согласованно, прозрачно и предсказуемо.

❔ Кто вообще пишет этот ПИМ
Важно понимать, что ПИМ создаётся совместно. Это не авторское произведение одного BIM-менеджера.
По СП 404.1325800.2018 к разработке ПИМ следует привлекать всех заинтересованных участников ИСП

Кто именно участвует, зависит от:
➖ типа заключаемых контрактов
➖ этапности работ
➖ целей и задач, которые заказчик ставит перед проектом
➖ уровня и глубины применения информационного моделирования
То есть состав команды не фиксированный – он формируется под конкретный проект и под конкретный результат.

❔ Как СП предлагает его собирать

🤍Этап I. Анализ целей ИСП
Определяем, зачем проекту вообще нужен BIM

Какие задачи должен решить? Какие риски снять? Какие данные дать?

🤍Этап II. Разработка процессов информационного моделирования

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

🤍Этап III. Разработка структуры и содержания цифровых информационных моделей и процедур
обмена информацией

Определяется состав моделей, форматы, правила обмена. IFC, LOD, СОД – всё сюда.

🤍Этап IV. Определение потребности в ресурсах, разработка процедур совместной работы,
контроля процесса информационного моделирования и качества цифровых информационных моделей.

Люди, инструменты, качество. Чтобы поддерживался порядок.

🧐 То есть структура ПИМ является отражением реальной команды и её задач. Хороший ПИМ служит документом, который помогает проекту случиться и не мешает ему развиваться.

❔ Как договориться с заказчиком о пунктах в ПИМ
Здесь начинаются не только технические, но и человеческие задачи. Опираясь личный опыт и нынешней моей команды, могу выделить основные моменты:

➖ Переводите технические требования, которые хотите пересогласовать, на язык последствий
Например, заказчик для стадии П решил уменьшить допуск проверки на коллизии до 5 мм. Очевидно, вас это не устраивает. Говорить «нужен допуск 50 мм» - бесполезно. Лучше объяснить: «иначе получим тысячу ложных коллизий и потеряем месяц на обработку ложных».
Говорите о последствиях. Тогда заказчик быстрее видит ценность корректного решения и охотнее соглашается на изменения.

➖ Запаситесь терпением на согласование «мелочи»
Две недели обсуждать систему именования уровней для уникального объекта – звучит безумно, но это реальность.
В моменте мне казалось, что сейчас моя крыша поедет, но это инвестиция в год работы без путаницы.
Особенно если заказчик присылает систему наименований, которая не стыкуется ни со здравым смыслом для конкретного объекта, ни с архитектурной логикой, ни с требованиями СП.
Терпение + нормативная база + готовность к техническому компромиссу = заказчик получает свою систему, но она не ломает логику модели.

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

➖ Давайте запасной план для «а вдруг»
Чтобы снять тревогу, достаточно предложить: «Если понадобится, добавим отдельной задачей или приложением».
Заказчик понимает, что решение обратимо. Гибкость – отличный инструмент переговоров.

➖Предлагайте технические компромиссы
Если вместо жёсткого «нет» вы предлагаете рабочую альтернативу, заказчик видит, что вы ищете решение, а не создаёте препятствия.
Компромисс + аргументация = доверие.

Рубрика Насти Голованёвой
#ГолосНастасьи #BIMsisters