Статьи

1. Введение: когда «бумажная зрелость» не превращается в реальное управление

Во многих компаниях формально есть всё или почти всё: регламенты управления проектами и программами, процедуры по стадиям (прединвестиционная проработка, FEED, stage‑gate, др.), стандарты по инжинирингу, закупкам, строительству, пусконаладке, множество информационных систем, поддерживающих процессы управления проектами (платформы данных, системы управления графиками и бюджетами, электронный документооборот и архив и т.п.).
Тем не менее проектные решения часто принимаются вне формальных процедур, документы и отчёты заполняются «задним числом», под уже состоявшиеся шаги, на площадках действуют свои «правила игры», отличные от «бумажных», сотрудники перегружены, постоянно «тушат пожары» и утрачивают доверие к формализованным процедурам.
Задача этого обзора — системно разобрать, почему на самом деле так происходит, где лежат корневые причины, почему простое переписывание регламентов и внедрение новых ИТ‑систем не решает проблему.
При этом важно оговориться, что у любой подобной проблемы почти всегда есть не одна, а целый комплекс причин. Мы все склонны выделять в нём прежде всего то, что ближе к нашему опыту и исполняемой нами роли. Так, например, инженер прежде всего фиксирует проблемы инжиниринга, финансист – бюджетные ограничения, юрист – контрактную рамку, ИТ‑специалист – несовершенство систем. Как выглядит картина на самом деле – вопрос сложный и многослойный, и вариантов правдоподобных объяснений здесь может быть довольно много.
В этом обзоре мы, опираясь на 25‑летние наблюдения за реализацией проектов в разных отраслях, предлагаем один из возможных и, как нам представляется, достаточно комплексных взглядов, который обобщает наиболее часто высказываемые участниками проектов мнения о причинах неработающих процедур.

2. Исторический контекст: от отраслевых инструкций к цифровым «надстройкам»

Условно можно выделить три исторические волны, которые сформировали современную ситуацию.
Волна 1: инженерно‑производственная (до 1990‑х)

• Основные правила задавались отраслевыми нормами и ГОСТами, отраслевыми СНиП/СП, ведомственными инструкциями.
• Управление проектами воспринималось как часть инженерии и строительства: ключевой фокус — «построить объект», сроки и стоимость — важны, но часто управлялись «по факту».
• Процедуры имели ярко выраженный функциональный характер: отдельно — проектный институт, отдельно — снабжение, отдельно — функционалы по технологической, организационной и инженерной подготовке строительства;
• целостная методология управления проектом как системой редко оформлялась.

Волна 2: стандартизация управления проектами (1990‑е – 2000‑е)

• Массовое внедрение стандартов PMI PMBOK, IPMA, AACE, TCM, внутрикорпоративных методологий, формирование офисов управления проектами (PMO).
• Появились формализованные процедуры stage‑gate, управления рисками, изменениями, стоимостью, сроками.
• Часто это был «импорт методологий» без глубокой адаптации под отрасль, под культуру и реальный организационный дизайн, под доступные компетенции.

Волна 3: цифровизация и интеграция жизненного цикла (2010‑е – по настоящее время)

• Внедрение информационного моделирования (BIM), электронного документооборота, интеграции с ERP и системами планирования, развитие концепции цифрового двойника.
• Усиление требований регуляторов банков по экологическим, социальным и управленческим аспектам.
• В результате появилось много сложных процедур и ИТ‑контуров, которые часто не соответствуют реальному темпу и способу работы на площадках, подталкивают к «обходу» системы и параллельному «миру Excel», «телефонного права» и неформальных договорённостей.

3. Откуда «растут ноги»: инжиниринг и исходные данные как корневая причина

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

1. Выполняется инжиниринговый цикл (концепт, FEED/ТЭО, ПД, рабочая документация) по определённым процедурам.
2. На выходе возникают технико-технологические решения, оформленные в виде проектной/рабочей документации: чертежи, спецификации, объёмы работ (объёмно‑планировочные и технологические решения), данные о нагрузках, режимах, величинах, геометрии, объёмах и т.д.
3. Эти данные служат «топливом» для остальных процедур: планирование и управление сроками, управление стоимостью и бюджетами, закупки и цепочки поставок, управление изменениями, строительный контроль и ПНР, передача в эксплуатацию и др.
4. Если проект в ходе инжиниринга недостаточно проработан или имеются противоречив, то данные становятся неполными, несогласованными, часто меняются, а исполнители вынуждены «додумывать» решения, самостоятельно пересчитывать объёмы, компенсировать пробелы личным инженерным интеллектом и опытом.

Иными словами, цепочки данных «рвутся» из-за разных версий документации и понимания объёмов, появлением локальных «истин» у разных функций, растущей нагрузки на сотрудников и коммуникации.

5. В условиях перегруза и постоянных «затыканий дыр» сотрудники теряют доверие к формальным процедурам, воспринимая их как «лишнюю бюрократию», не помогающую, а мешающую работать.

4. Основные факторы влияния на работоспособность процедур

Ниже, в Таблице 1 представлен краткий обзор факторов, влияющих на работоспособность проектных процедур, с экспертной оценкой их относительной значимости (важности), как для Заказчика, так и EPC‑подрядчика (по наблюдениям и опросам респондентов в различных отраслях за 25 лет).

Таблица 1. Обзор факторов влияния на работоспособность проектных процедур
Шкала относительной значимости (1–5),
где 1 — относительно низкая важность, 5 — относительно критическая важность.

Группа факторов	Краткое описание факторов	Важность для Заказчика (1–5)	Важность для EPC-подрядчика (1–5)
Несовпадение целей, стимулов и KPI	Разрыв между стратегическими целями, контрактными показателями и реальными стимулами людей; «игра» с цифрами, ориентация на формальное соблюдение процедур, а не на результат	4	3
Организационный дизайн и культура	Разрыв между «центром» и «площадкой», доминирование функциональных «вертикалей» компании над проектными командами, страх эскалации и ответственности, культура избегания «плохих новостей»	4	4
Компетенции и ресурсы	Недостаток квалификации, «перегруз» ключевых сотрудников, текучесть кадров, замещение осмысленного управления механическим следованием (или игнорированием) процедур	3	5
Качество инженерной проработки и процедур формирования исходных данных	Качество инжиниринга на всех стадиях (концепт, FEED/ТЭО, ПД, РД), полнота и согласованность исходных данных и проектной документации Это как раз -то, насколько процедуры инжиниринга реально обеспечивают достоверные данные нужного объёма и формата	5	5
Информационные системы и интеграция данных	Набор и интеграция информационных систем (EDMS, BIM, ERP, системы управления графиками и др.), способы распространения данных; Это вопросы к тому, насколько информационные системы помогают или мешают использовать инженерные и управленческие данные (дублирование ввода, расхождения, отсутствие единого «источника истины» и др.)	2	3
Контрактно-правовая рамка и распределение рисков	Типы контрактов и распределение рисков, стимулирующие минимально допустимое исполнение процедур и максимизацию претензий, а не совместное управление рисками и, по сути, проектом. Второй момент – избыточная жёсткость условий и штрафных механизмов	3	4
Внешние директивные ограничения и финансирование	Директивные сроки и бюджеты (политические, регуляторные, корпоративные), требования банков и госорганов Приводит к смещению процедур в сторону отчётности и «галочек» вместо реального управления	4	5
Временное давление и «пожарный режим»	Хроническое опоздание с базовым инжинирингом, запоздалые инвестрешения, постоянное ощущение, что «строить надо было вчера». Сжатие времени на качественный инжиниринг и выполнение инжиниринговых процедур, работа в режиме постоянного аврала	2	4

Теперь постараемся разобрать каждую группу факторов отдельно.

5. Разбор влияния групп факторов

5.1. Несовпадение целей, стимулов и KPI

Суть вопроса

• У Заказчика на уровне стратегии декларируются рентабельность (NPV, IRR), сроки ввода, эксплуатационная надёжность и безопасность, требования в экологической и социальной сферах, корпоративные требования и т.д.
• На уровне реальных стимулов и KPI для руководства проектом и проектных команд важно следующее: успеть к дате «X» любой ценой, не выходить с запросами о пересмотре бюджета, освоить CAPEX по плану года.
• EPC‑подрядчик видит свои ключевые цели, как обеспечение маржи по контракту, исполнение планового Cash-Flow, минимизация штрафов и претензий, а часть процедур объективно воспринимает, как «навязанную» Заказчиком бюрократию.

Почему это разрушает процедуры

• Любая процедура, которая потенциально может выявить недостоверность исходных допущений, показать, что сроки/стоимость нереалистичны, потребовать дополнительных ресурсов, — оказывается нежелательной.
• В мировых исследованиях (например, у Bent Flyvbjerg) подобная систематическая описывается, как «оптимистическая предвзятость» и «политическая корректировка» оценок и квалифицируется, как один из главных источников провалов мегапроектов.

Отличия Заказчик / EPC-подрядчик

• Для Заказчика - это один из главных «фоновых» драйверов, который определяет, будут ли по‑настоящему инвестировать в качественный инжиниринг и исходные данные.
• Для EPC-подрядчика это также важно, но в значительной степени уже воспринимается, как «данность», выраженная в условиях контракта и директивном графике. Подрядчик адаптируется сообразно ситуации, зачастую усиливая свой блок управления изменениями и претензиями.

5.2. Организационный дизайн и культура

Суть вопроса

• Организационные структуры, где, сильны функциональные вертикали (проектирование, закупки, финансы, юристы, ООС и ПБ, др.) – всегда слабая власть руководителя проекта.
• Разрыв между центром (головной офис, методологии, ИТ), площадкой (выполнение конкретных работ).
• Культура: избегания ответственности, страх их эскалации, нежелание приносить «плохие новости».

Почему это разрушает процедуры

• Решения затягиваются, любая нетривиальная ситуация требует множества согласований.
• Цепочки данных и решений растягиваются и искажаются: информация фильтруется и «подчищается» по пути наверх, а реальные проблемы появляются в отчётах слишком поздно и в смягчённом виде.
• Полезные процедуры (регулярный риск‑анализ, пересмотр допущений, извлеченные уроки) не встроены в реальные механизмы власти и ответственности.

Отличия Заказчик / EPC-подрядчик

• Для обеих участников проекта фактор крайне силён: у Заказчика накладывается ещё и политический/корпоративный контекст, а у EPC-подрядчика происходит давление операционных рисков, субподрядной цепочки и «тонкой» маржи.

5.3. Компетенции и ресурсы

Суть вопроса

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

Почему это разрушает процедуры

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

Отличия Заказчик / EPC-подрядчик

• У Заказчика особенно страдает базовый инжиниринг и блок управления портфелем проектов. Внутренняя компетенция по формированию требований к данным и инжинирингу часто ограничена.
• У EPC-подрядчика компетенции — критический фактор выживания: без сильных инженеров и «полевых» команд даже формально хорошие процедуры останутся на бумаге.

5.4. Качество инженерной проработки и процедур формирования исходных данных, как корневой фактор

Поскольку это представляется корневым фактором, постараемся его рассмотреть более пристально.
Качество инженерной проработки и процедур формирования исходных данных - это не просто наличие выполненных стадий Концепт, FEED/ТЭО, ПД, рабочая документация, а ответ на вопрос, насколько технические решения и инженерные данные по проекту достаточно продуманы, согласованы и оформлены, чтобы по ним можно было реально планировать, считать, закупать и строить, не придумывая всё заново в процессе.
И это сразу «включает» два слоя:

1. Содержание инженерной проработки — что именно и как спроектировано.
2. Процедуры формирования и приёмки исходных данных — как гарантируется, что на выходе любой из стадий инжиниринга данные действительно пригодны для всех последующих процессов.

Требования к качеству инжиниринговой проработки

• Полнота и глубина технических решений

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

• Внутренняя согласованность и отсутствие скрытых противоречий

Речь о том, согласованы ли между собой разделы проекта (технология, конструктив, архитектура, сети, автоматизация и т.д.), насколько и где именно разнятся версии выпущенной документации (учтены ли обновления во всех связанных частях), согласованы ли всеми допущения и расчёты (нет ли ситуации, когда технологи считают одно, конструкторы — из других предпосылок, а сметчики — из третьих).
Типовой антикейс:

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

• Стабильность и управляемость изменений

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

• часть — задокументирована,
• часть — устные договорённости,
• часть — «доделаем на площадке, позже перерисуем».

Качество инженерной проработки - высокое, когда основные ключевые решения приняты до заключения крупных контрактов и закупки оборудования длительного цикла изготовления. Тогда дальнейшие изменения будут относительно редкими, достаточно обоснованными, их влияние на сроки и стоимость будут заранее анализироваться.
Если инженерные решения «плавают» в течение всего проекта — это признак низкого качества проработки, даже если томов документации выпущено очень много.

• Пригодность данных для выполнения последующих процедур

Важно не только то, что инженерные данные существуют, но и то, что они:

• выданы в том виде, который нужен планировщикам (для разбивки по работам и зонам), сметчикам и контролёрам стоимости (для структурирования по статьям затрат), функции комплектации и снабжения (для спецификаций, кодировки, определения сроков поставки и пр.), строителям (для привязки и детального планирования выполнения работ), эксплуатации (для учета режимов, лимитов, учета эксплуатационных показателей и настройки ТОиР);

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

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

Требования к формированию исходных данных

Это не о «бумагах ради бумаг». Речь о наборе правил и шагов, которые обеспечивают:

1. Ясность требований к данным. Какие именно данные должны быть готовы к концу каждой инжиниринговых стадий, в каком виде (формат, разрез, детализация, кодировка), для каких последующих задач (планирование, сметы, закупки, стройка, эксплуатация).
2. Понятные входы и выходы инжиниринговых стадий. Стадия «считается завершённой» не потому, что «написан отчёт», а потому, что определён перечень решений, задокументированы ключевые параметры, исходные данные прошли проверку на полноту и согласованность)
3. Ответственность за данные. Кто конкретный владелец тех или иных наборов данных – какое-либо подразделение проектного института, отдельный главный инженер проекта, внешний инжиниринговый субподрядчик. Кто отвечает за сбор исходных данных, их проверку, внесение в информационные системы, обновление при изменениях и т.п.
4. Критерии качества и приёмка. Как заказчик проектной документации принимает данные, по каким чек‑листам, с какими измеримыми критериями, например «нравится/не нравится» или «достаточно/недостаточно» для перехода к следующей стадии или заключения контракта на выполнение работ). Как фиксируются допущения и ограничения, а также неопределённости, которые неизбежно остаются.
5. Управление версиями и изменениями. Как организована работа с версиями документации и данных, как гарантируется, что планировщик, снабженец и строитель видят одну и ту же актуальную версию, а устаревшие данные не «гуляют» по системе.

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

Почему это видится корневым фактором

Схематично цепочка причинно‑следственных связей выглядит следующим образом (Рисунок 1):

Рисунок 1. Типичная цепочка влияния фактора качества инженерной проработки проекта
Данный фактор мы предлагаем оценивать как корневой, потому что пока «инжиниринг и данные» остаются слабым звеном, любые попытки улучшать процедуры на «верхних этажах» (управление рисками, стоимостью, сроками, портфелем, внедрение цифровых систем и т.п.) дают лишь ограниченный эффект, который необходимо постоянно поддерживать.
Отличия влияния данного фактора на Заказчика и EPC-подрядчика

• У Заказчика: качество инжиниринга определяет реалистичность бизнес‑кейса, риски по срокам, стоимости и эксплуатационным характеристикам.
• У EPC-подрядчика: это прямая зона риска, напрямую влияющая на объём переделок и дополнительных работ, количество «полевых» проблем, объём претензий. А если инжиниринг выполнялся по заказу Заказчика третьими лицами, то EPC-подрядчик унаследует все их дефекты и будет вынужден компенсировать их уже на площадке.

5.5. Информационные системы и интеграция данных (усиливающий слой, а не первопричина)

Суть вопроса
Системы управления документацией (EDMS), информационного моделирования (BIM), ERP, электронных инструментов планирования и различных систем отчётности и др. обеспечивают ли:

• Достаточную степень интеграции, однотипность в способах ввода, хранения и распространения данных и т.п.
• единый ли источник «истины»,
• отсутствие дублирования ввода,
• простоту для пользователей в получении нужной им информации.

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

• Заказчик. Информационные системы — важный, но второй уровень проблем, так как сначала нужно договориться, какие данные и в каком качестве нужны, затем — как их поддерживать и только потом — как это автоматизировать.
• EPC-подрядчик. Информационные системы для него существенно более важны, потому что сильно влияют на ежедневную координацию, оперативную отчётность, связь «офис–поле». Но всё равно они уступают по значимости фактору качества инжиниринговой проработки и компетенциям.

5.6. Контрактно‑правовая рамка и распределение рисков

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

• Контракты формируют рамку стимулов:
• EPC будет минимизировать операции, не приносящие прямой выгоды или не требуемые контрактом;
• Заказчик будет стремиться переложить максимум рисков «вниз» при минимальной цене.
• Но то, как в реалии будет распределён риск, обычно зависит от принятых допущений о качестве инженерной проработки и ожиданий по данным и изменениям.

Отличия Заказчик / EPC-подрядчик

• Для Заказчика контракт это инструмент закрепления желаемых процедур и уровней качества, но, если изначально нет ясной и реалистичной модели инжиниринга и данных, контракт лишь зафиксирует искажения.
• Для EPC-подрядчика контрактная рамка напрямую влияет на набор процедур, которые он (подрядчик) будет выполнять особо тщательно (например, управление изменениями, претензионная работа и др.), и те, которые будут им выполняться формально.

5.7. Внешние директивные ограничения и финансирование

Суть вопроса
Политические, регуляторные, корпоративные директивные сроки и бюджеты, требования государственных органов, банков и т.д. вносят безусловные ограничения на работоспособность процедур, особенно которые не были приспособлены к новым условиям.
Почему это разрушает процедуры
Сроки и бюджеты проектов задаются от желаемого результата, а не от реалистичной оценки ситуации и возможностей. И поскольку время и ресурсы на качественный инжиниринг (особенно на ранних стадиях), изыскания, анализ альтернатив сжимается, такие процедуры, как например, выбор площадки, оценка запасов (для добычных и перерабатывающих проектов), анализ рынка и логистики, сценарный анализ и т.д. превращаются в ритуал: формально что‑то делается, но решения уже приняты.
Отличия Заказчик / EPC-подрядчик

• Заказчик. Данный фактор определяет исходные рамки проекта, но из‑за него инжиниринговая проработка (особенно на ранних стадиях) часто оказывается «усеченной».
• EPC-подрядчик ощущает эту ситуацию его опосредованно — через условия контракта, но не может изменить директивность и вынужден только адаптироваться.

5.8. Временное давление и «пожарный режим»

Суть вопроса
Хроническое опоздание с запуском проектов, с принятием инвестрешений, с началом инжиниринга, постоянное ощущение «надо было начинать вчера».
Почему это разрушает процедуры

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

Отличия Заказчик / EPC-подрядчик
У Заказчика фактор важен, но чаще уже действует, следствие предыдущих решений (в конкретном проекте может ощущаться, но вопросы типа «…почему так поздно начали…» лежат выше.
У EPC-подрядчика – это ежедневная реальность: вся культура процедур подстраивается под авральный режим (работает только то, что прямо поддерживает выполнение СМР, ПНР и закрытие объёмов).

6. Типичные сценарии «развала» проектных процедур

Для иллюстрации приведём несколько укрупнённых сценариев (Таблица 2).
Таблица 2. Типичные сценарии, когда процедуры перестают работать

Сценарий	Краткое описание	Ключевые корневые причины
«Инжиниринг для галочки»	FEED/ТЭО, выбор площадки, оценка рынка и запасов (для добычных и перерабатывающих проектов) выполняются формально; решения о запуске и контрактовании принимаются раньше завершения проработки	Директивные сроки и бюджеты; разрыв целей и KPI; слабые требования к качеству инженерных данных
«Две реальности: документы и площадка»	В EDMS/BIM/ERP красивая картина и процедурная «чистота»; на площадке — постоянные доработки «по месту», иные объёмы и последовательности работ	Плохое качество рабочей документации; слабая интеграция между инжинирингом и строительством; перегруз и дефицит компетенций, особенно на площадке
«Контрактная оборона вместо совместного управления»	Основные усилия EPC направлены на фиксацию оснований для претензий и защиту от штрафов, а не на совместное снижение рисков и управление проектом	Жёсткая передача рисков подрядчику в контрактах; несовпадение стимулов; отсутствие механизмов совместного управления (вместо инструментов типа alliancing / IPD)
«Цифровой фасад»	Внедрены сложные ИТ‑системы, но данные в них неполные, противоречивые; сотрудники параллельно ведут учёт в Excel и мессенджерах	Слабое качество инженерных и исходных данных; отсутствие владельцев данных; попытка автоматизировать «как есть» без переосмысления процессов

7. Приоритизация процедур: что в первую очередь необходимо Заказчику и EPC‑подрядчику

Проектных процедур достаточно много, они синхронизированы со всеми проектными процессами, процедуры связаны между собой, влияют друг на друга. Первый вопрос: насколько компании готовы к немалым затратам на управление качеством, чтобы разработать, а далее поддерживать в актуальном и, главное, в рабочем состоянии ВСЕ процедуры? Второй вопрос: а возможно ли технически удерживать долгое время в рабочем состоянии портфель из 200-300 процедур, даже если их распределить по зонам ответственности?
Соответственно необходимо выстроить приоритеты. При выборе, какие процедуры необходимо в первую очередь «поднимать», важно опираться на причинно‑следственные связи их влияния на проекты. Попробуем это проанализировать.

• Для Заказчика корневой задачей является создание реалистичного, инженерно- и экономически обоснованного проекта, прежде чем выводить его на рынок EPC-услуг и «запускать» стройку. Поэтому в первую очередь должны усиливаться процедуры, которые:

• задают рамки и цели проекта;
• обеспечивают качественную инжиниринговую проработку проекта на ранних стадиях и получение качественных исходных данных;
• фиксируют и защищают базовый объём, сроки, стоимость и риски;
• создают работающий контур управления изменениями, контрактами и закупками;
• обеспечивают корректный ввод / передачу в эксплуатацию.

Если эти контуры слабы, любые требования к EPC‑подрядчику по «красивым процедурам» превращаются в формальность: подрядчик будет вынужден компенсировать дефекты исходных решений «по месту», а у Заказчика получится формально управляемый, но фактически непредсказуемый проект.

• Для EPC‑подрядчика приоритеты несколько отличаются. Подрядчик входит в проект, когда рамки по срокам и бюджету уже заданы, условия контракта зафиксированы, качество исходной инжиниринговой проработки и исходных данных либо задано Заказчиком, либо создаётся уже силами EPC-подрядчика.

В этой ситуации выживание EPC‑подрядчика зависит от того, насколько он:

• взвешенно оценивает свои риски и возможности, входя в проект
• точно понимает объём EPC‑обязательств и умеет его структурировать;
• выстраивает план реализации проекта (Project Execution Plan) и контрольный базис;
• управляет инжинирингом, изменениями, сроками, стоимостью;
• обеспечивает надёжные закупки, поставки и управление строительством;
• умеет грамотно работать с контрактами и претензиями, не разрушая при этом отношения с Заказчиком;
• завершает проект качественным ПНР и вводом в эксплуатацию.

При слабых процедурах в этих зонах EPC‑подрядчик погружается в постоянный «пожарный режим», где формальное соблюдение регламентов и отчётности вытесняет реальное управление.
Исходя из этой логики, ниже, в Таблице 3 предлагается перечень из ТОП-20 процедур, на которых обеим сторонам имеет смысл сосредоточиться в первую очередь (по наблюдениям за 25 лет и результатам опросов респондентов).

Таблица 3. Видение наиболее приоритетных ТОП-20 процедур для Заказчика и EPC-подрядчика
Для каждой процедуры указана её относительная важность внутри ТОП-списка, где
1 — низкий приоритет, 5 — критический приоритет.

Процедура	Приоритет для Заказчика (1–5)	Приоритет для EPC-подрядчика (1–5)
Обоснование инвестиций и бизнес-кейс	5	1
Анализ целесообразности участия в проекте	-	5
Устав проекта и назначение руководителя проекта	4	1
Анализ и управление заинтересованными сторонами	2	2
Коллегиальное управление проектом (проектный/инвестиционный/тендерный комитеты)	4	1
План реализации проекта и контрольный базис	5	5
Управление объёмом работ и границами обязательств	5	5
Планирование и управление инжинирингом	5	5
Управление базисом проектирования и изменениями в технических решениях	5	5
Планирование сроков и управление графиком	3	5
Планирование стоимости и управление бюджетом	4	5
План управления рисками	5	4
План управления закупками и поставками	4	5
Управление качеством в проекте	3	4
Управление охраной труда, безопасностью и экологией	3	4
Управление информацией и документацией, единая среда данных	2	3
Управление изменениями по объёму, срокам и стоимости	5	5
Управление контрактами и претензиями	4	5
Управление строительством и фронтом строительно-монтажных работ	2	5
Пусконаладочные работы, ввод в эксплуатацию и операционная готовность	5	4

Данное распределение зон концентрации первоочередных усилий для Заказчика и EPC-подрядчика демонстрирует объективную разницу в подходах участников:

• Для Заказчика первостепенно:
• формирование реалистичного бизнес-кейса и рамок проекта (обоснование, устав, коллегиальные органы управления);
• обеспечение качественного инжиниринга и исходных данных (управление инжинирингом, базисом проектирования и изменениями);
• фиксация и защита базового объёма, сроков, стоимости и рисков (объем проекта, планирование, риск‑менеджмент, управление бюджетом, управление изменениями);
• выстраивание контрактного, закупочного и вводно‑эксплуатационного контуров.
• Для EPC‑подрядчика важен фокус на:
• чётком понимании объёма и границ EPC‑обязательств;
• практическом плане реализации и управлении инжинирингом;
• реалистичном и управляемом графике, бюджете и рисках;
• надёжных закупках, логистике и управлении строительством;
• зрелом управлении изменениями, контрактами и претензиями;
• подготовке и осуществлении ПНР и ввода без «шока» для эксплуатации.

8. Выводы

1. Качество инжиниринговой проработки и исходных данных — ключевой, корневой фактор. Если инженерные данные плохие, никакая методология и ИТ‑система не сделают процедуры реально работающими.
2. Цели, стимулы, организационный дизайн и директивность. Определяют, будут ли компании инвестировать время и ресурсы в качественный инжиниринг и данные,
   или ограничатся формальными «галочками».
3. ИТ‑системы и регламенты — это важно, но, все-таки вторично. Без переосмысления инженерных процессов и цепочек данных они лишь маскируют проблемы.
4. Приоритет для Заказчика— обеспечить реалистичный базовый инжиниринг, чёткие требования к качеству данных, процессы приёмки инженерных решений и документации, прежде чем нагружать EPC-подрядчика сложными формальными процедурами и отчётностью.
5. Для EPC‑подрядчика ключ к «работающим процедурам» - это, прежде всего, баланс:
• сильные инженерные и «полевые» команды,
• осмысленный (а не формальный) набор процедур,
• понятная ИТ‑поддержка, не разрушающая, а поддерживающая реальные потоки данных.

Источники

• Flyvbjerg B. Megaprojects and Risk: An Anatomy of Ambition. Cambridge University Press, 2003.
• Flyvbjerg B. What You Should Know About Megaprojects and Why: An Overview // Project Management Journal. 2014. Vol. 45, No. 2.
• Merrow E.W. Industrial Megaprojects: Concepts, Strategies, and Practices for Success. John Wiley & Sons, 2011.
• Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK® Guide). 7th ed. PMI, 2021.
• AACE International. Total Cost Management (TCM) Framework: An Integrated Approach to Portfolio, Program, and Project Management. 2nd ed., 2012.
• IPA (Independent Project Analysis). Research briefs and industry reports on capital project performance (обобщены в книге Merrow и в публичных обзорах IPA).
• ISO 21500:2021. Project, programme and portfolio management — Context and concepts.
• ISO 19650‑1:2018. Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) — Information management using building information modelling — Part 1: Concepts and principles.
• McKinsey Global Institute. Reinventing Construction: A Route to Higher Productivity. McKinsey & Company, 2017.
• Bent Flyvbjerg, Alexander Budzier. Why Your IT Project May Be Riskier Than You Think // Harvard Business Review., 2011