Кто из трёх убьёт проект: ЛПР, ЛВР или ЛФР?

На старте проекта по автоматизации производства PM получает контакт: «обращайтесь к нашему главному технологу». Через два месяца выясняется: технолог влиял на ТЗ, но не подписывает акты. Акты подписывает главный инженер. А бюджет закрывает финдиректор, которого никто не знал.

Проект встал. Не потому что что-то не сделали. Потому что говорили не с теми людьми.

Карта центра принятия решений у заказчика — первый рабочий документ на нулевом этапе. Не устав проекта, не план коммуникаций. Именно эта карта.

ЛФР — лицо, формирующее решение

Главный технолог, главный энергетик, начальник АСУТП, специалист КИПиА. Эти люди пишут ТЗ, согласовывают архитектуру, формируют список требований к ПЛК, датчикам и SCADA.

Типичная ошибка: прийти к ним уже с решением. Они его зарубят. Просто потому что не участвовали.

Первая встреча с ЛФР — это интервью. Какие узлы автоматизируете? Какой контроллер уже стоит на объекте? Есть ли требования по протоколам связи? Что не устраивало в работе предыдущего поставщика?

ЛФР доверяет тому, кто говорит на его языке. Разговор про I/O-карты, Modbus/Profibus, уставки защит открывает дверь быстрее, чем любая презентация компании.

С ЛФР работают через рабочие совещания — раз в две недели, с фиксированной повесткой и протоколом. Без протокола согласованное на словах к следующей встрече оказывается «мы имели в виду другое».

ЛВР — лицо, влияющее на решение

В оргсхеме проекта их нет. Но без них не выйдет ни один рабочий чертёж. Служба эксплуатации. Отдел снабжения. Проектный институт. Иногда — независимый технический заказчик или инжиниринговая компания на субподряде.

Классический сценарий: PM согласовал архитектуру системы с ЛФР, вышел на проектирование и только тогда подключил снабжение. Результат — 80 замечаний по спецификации и перенос сдачи на квартал.

Правильнее включить ключевых ЛВР в рабочие совещания ещё на стадии выбора решения. Не как наблюдателей, а как участников. Письменные комментарии от них — это и защита PM, и фиксация их вовлечённости.

Со снабжением отдельно. У них свои KPI: сроки поставки, сертификация, наличие на складе. Им не нужна «лучшая SCADA». Им нужна та, что поставится в срок и пройдёт входной контроль.

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

ЛПР — лицо, принимающее решение

Директор по производству, технический директор. Видит проект раз в квартал на статусном совещании.

Ему не нужны детали архитектуры. Три вещи: сроки, бюджет, риски. Нести на встречу технические вопросы — ошибка. Итог предсказуем: размытый статус и ощущение, что проект не под контролем.

Перед каждым статусным совещанием PM готовит одну страницу. Что сделано. Что идёт по плану. Где отклонение и что делается для возврата в график. Какое конкретное решение нужно от ЛПР прямо сейчас.

Последний пункт критичен. Если PM приходит без вопроса к ЛПР, встреча превращается в отчёт. ЛПР остаётся наблюдателем. И когда что-то идёт не так, первый вопрос от него: «Почему мне не сказали раньше?»

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

Эта карта обновляется при каждой смене состава команды заказчика. В длинных проектах люди меняются чаще, чем кажется. Новый начальник АСУТП — новое интервью. Новый директор по производству — новый формат отчётности. Не знать, кто ЛПР на проекте, — такой же риск, как неверная уставка на реле защиты. Незаметно, пока не сработает.

Какую структуру коммуникаций используете на своих проектах?

#УправлениеПроектами #АСУТП #Электротехника #Автоматизация #PMO #Стейкхолдеры #B2B

Кто из трёх убьёт проект: ЛПР, ЛВР или ЛФР? | Сетка — социальная сеть от hh.ru