Тендер на EPC без сюрпризов

02 сентября 2025

Почему EPC дорожает, когда тендерный пакет слабый

 

 

 

EPC-контракт («под ключ») выглядит для заказчика как способ переложить на подрядчика проектирование, закупки и строительство. Но рынок работает рационально: подрядчик либо сразу включает риски в цену, либо принимает риск, выигрывает тендер и потом пытается компенсировать его через претензии, вариации, пересмотр сроков и «допработы».

1. Описать функциональную цель и критерии приемки,
2. Дать достаточные исходные данные для разумной оценки,
3. Определить границы и интерфейсы (кто за что отвечает),
4. Установить процедуры изменений (как фиксируем объем/стоимость/влияние на сроки).
5. Если этого нет, EPC превращается в «сделаем как-нибудь», а это противоречит самой природе EPC.

Ключевой принцип: тендерный пакет должен быть «проверяемым»

Хороший тендерный пакет обеспечивает:

• сравнимость предложений (apples-to-apples),
• измеримость обязательств (что именно должен поставить подрядчик),
• управляемость изменений (вариация - не конфликт, а процедура).

Это достигается не количеством страниц, а правильной архитектурой документов.

 

12 ДОКУМЕНТОВ ТЕНДЕРНОГО ПАКЕТА EPC, КОТОРЫЕ РЕАЛЬНО СНИЖАЮТ РИСК

Ниже - практический перечень документов и пояснения - зачем нужен документ и где чаще всего делают ошибки.

1) Invitation to Tender / Request for Proposal (ITT/RFP)

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

2) Draft Contract (проект договора) + Conditions of Contract

Это «скелет» будущих обязательств: сроки, цена, изменения, гарантии, приемка, ответственность.
Ошибка: проект договора дается «как шаблон», без привязки к ER, тестам и графику платежей.

3) Employer’s Requirements (ER) / Требования заказчика

Функциональные, нормативные и интерфейсные требования.
Ошибка: ER превращают в «энциклопедию», но забывают критерии приемки и границы ответственности.

4) Scope of Work / Statement of Work (SOW)

Четкое описание объема подрядчика: что входит в EPC, что исключено, что будет предоставлено заказчиком.
Ошибка: SOW дублирует ER, но не задает границы.

5) Battery Limits & Interface Register (границы и интерфейсы)

Список точек подключения, входов/выходов, «кто дает что и когда».
Ошибка: интерфейсы описаны словами без схем/таблиц и без ответственности за исходные данные.

6) Site & Data Package (площадка и исходные данные)

Топография, геология, существующие сети, ограничения логистики, условия доступа.
Ошибка: данные «для справки», без статуса применимости и без оговорки, что считается достоверным.

7) Codes & Standards Register (реестр норм)

Нормы/стандарты и их приоритет, язык документации.
Ошибка: «применять все нормы» - невыполнимое требование, которое превращается в риск-премию в цене.

8) Tender Pricing Forms / BOQ / Schedule of Prices

Коммерческие формы цены (структура, допущения, валюта, налоговая модель).
Ошибка: цена одной строкой → потом невозможно спорить, что было включено.

9) Payment Schedule / Milestones (график платежей)

Платежи привязаны к проверяемым результатам: документы, поставка long-lead, FAT/SAT и т.д.
Ошибка: «проценты по готовности» без доказательной базы ведет к конфликту при оплате.

10) Quality Requirements (QMP, ITP, hold/witness points)

Требования к контролю качества, испытаниям, инспекциям, приемке оборудования.
Ошибка: контроль качества описан общими фразами ведет к спору «какой уровень качества был обещан».

11) HSE Requirements

Требования по безопасности, допускам, обучению, отчетности.
Ошибка: HSE как «приложение ради галочки», без интеграции в план работ.

12) Bid Compliance Table + Deviations Register (матрица соответствия и реестр отклонений)

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

 

МАТРИЦА ПРИОРИТЕТОВ ДОКУМЕНТОВ: МАЛЕНЬКИЙ ПУНКТ, КОТОРЫЙ СПАСАЕТ ПРОЕКТ

В EPC почти неизбежны противоречия между документами (ER, чертежи, нормы, спецификации). Поэтому в договоре и тендерном пакете должна быть Document Priority (Order of Precedence).

Практика показывает: если приоритеты не определены, конфликт неизбежно превращается в спор «кто прав», а это задержки, вариации и юридические издержки.

Как писать Employer’s Requirements, чтобы не получить «лавину изменений»

ER должна отвечать на 5 вопросов:

1. Что объект должен делать? (производительность, режимы, качество продукта, доступность)
2. Как это проверяется? (протокол испытаний, критерии успеха, условия теста)
3. Где границы? (battery limits, интерфейсы)
4. Какие нормы и в каком приоритете?
5. Какой состав документации и сроки? (проектирование, as-built, O&M manuals)

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

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

В практике UDG это обычно делается как короткий аудит тендерного пакета с выпуском:

• реестра пробелов и рисков,
• корректировок ER и интерфейсов,
• шаблонов compliance/deviations,
• рекомендаций по структуре цены и платежей.