Авторы: Владимир Нешкес, Екатерина Пужанова, Наталья Мещерекова

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 — относительно критическая важность.

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

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. Типичные сценарии, когда процедуры перестают работать

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

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

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

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

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

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

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

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

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

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

Данное распределение зон концентрации первоочередных усилий для Заказчика и 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