Design-Build (DB) Delivery Method · Управление проектами
Модель DB (Design-Build, проектирование-строительство) — это модель подряда, при которой заказчик поручает проектирование и строительство объекта единому генеральному подрядчику (или консорциуму), который несет ответственность за весь процесс — проектирование, закупки, строительство, пусконаладку — и в конечном итоге передает заказчику готовый объект, отвечающий функциональным требованиям.
Ключевая характеристика — единый ответственный субъект: проектировщик и строитель больше не находятся в отношениях «заказчик-исполнитель», как в традиционной модели DBB, а являются участниками одного договорного субъекта. Заказчик подписывает один контракт и взаимодействует с одним ответственным лицом, что позволяет избежать классической проблемы взаимных обвинений между проектировщиком и строителем при возникновении дефектов.
Появление модели DB обусловлено тремя ключевыми проблемами традиционной модели DBB (Design-Bid-Build) при реализации крупных сложных проектов:
В этих условиях модель DB за счет интеграции проектирования и строительства обеспечивает параллельное выполнение работ и быстрый путь (Fast-Track), что делает ее широко востребованной на международном рынке. FIDIC (Международная федерация инженеров-консультантов) в 1995 году выпустила «Условия контракта на проектирование-строительство и сдачу под ключ» (так называемая «Оранжевая книга»), а в 2017 году обновила их до «Условий контракта на производственное оборудование и проектирование-строительство» (Желтая книга), которые стали основным контрактным шаблоном для международных DB-проектов. С 2016 года Китай активно продвигает генеральный подряд (EPC/DB): Министерство жилищного и городского строительства последовательно выпустило «Мнения о дальнейшем развитии генерального подряда» и другие программные документы, обеспечив институциональную поддержку для выхода центральных госкомпаний на международный рынок с DB-проектами.
Модель DB не является универсальной — ее применимость зависит от характеристик проекта:
| Применимые случаи | Неприменимые случаи |
|---|---|
| Заказчик четко определил функциональные требования, но не ограничивает способы реализации | Заказчик стремится жестко контролировать проектирование и требует постраничного согласования чертежей |
| Сжатые сроки, необходим быстрый путь | Техническое решение проекта крайне неопределенно и требует многократного обоснования |
| Единый ответственный субъект упрощает управление | Заказчик располагает собственной сильной командой по управлению проектированием и строительством |
| Проекты с высокой степенью стандартизации в промышленности/инфраструктуре | Высококастомные объекты с повышенными художественными требованиями |
| Заказчик хочет зафиксировать общую цену и передать риски | Геологические/политические риски чрезвычайно велики, точная ценовая оценка затруднена |
В зарубежной инженерной практике модель DB часто применяется в таких сферах, как энергетика, водоснабжение, дорожное строительство, гражданское строительство, промышленные парки, и особенно подходит центральным госкомпаниям-генподрядчикам для реализации преимуществ интеграции «проектирование + строительство + цепочка поставок».
Структура контракта в модели DB по своей сути представляет собой двусторонние отношения «заказчик — генеральный подрядчик». Внутри генеральный подрядчик интегрирует проектные институты, строительные бригады и поставщиков оборудования через субподряды, соглашения о консорциуме и другие механизмы.
Перечень ключевых положений:
Сравнение распределения рисков:
| Категория риска | Модель DBB | Модель DB |
|---|---|---|
| Ошибки проектирования | Заказчик (договор на проектирование) | DB-подрядчик |
| Интерфейс проектирование-строительство | Координирует заказчик | Внутренняя координация DB-подрядчика |
| Задержки сроков | Склонность к спорам | Единая ответственность |
| Геологические условия | Обычно заказчик | Зависит от контракта, часто подрядчик |
Главная ценность модели DB — Fast-Track: строительство может начинаться по завершенным частям проекта, пока проектирование еще не закончено, обеспечивая глубокое пересечение проектирования и строительства.
Ключевые аспекты реализации:
Типичный параллельный процесс:
```
Концептуальное проектирование → Базовое проектирование → Детальное проектирование A → Детальное проектирование B → Рабочие чертежи
↓ ↓ ↓
Подготовка к строительству Строительство участка A Строительство участка B
```
В DB-проектах чаще всего применяются контракты с твердой ценой под ключ (Lump Sum Turnkey) или с гарантированной максимальной ценой (GMP). Подрядчик уже на стадии тендера должен оценить полную стоимость проектирования, закупок и строительства, принимая риски на себя.
Риски, которые подрядчик должен тщательно оценить:
Инструменты управления:
В DB-контрактах основой приемки обычно служат гарантии производительности (Performance Guarantee), а не просто ведомость объемов работ.
Типичные показатели производительности:
| Тип проекта | Типичные показатели |
|---|---|
| Электростанция | Мощность, удельный расход тепла, выбросы, коэффициент готовности |
| Водоочистная станция | Производительность, качество воды, энергопотребление |
| Автомобильная дорога | Пропускная способность, ровность, долговечность |
| Гражданское строительство | Площадь, высота этажей, класс энергоэффективности, комфорт |
Процедура приемки:
1. Механическое завершение (Mechanical Completion);
2. Пусконаладка (Commissioning);
3. Испытания производительности (Performance Test);
4. Временная приемка (Taking Over);
5. Период ответственности за дефекты (Defects Liability Period);
6. Окончательная приемка (Final Acceptance).
В модели DB при внесении заказчиком функциональных изменений подрядчик вправе скорректировать цену контракта и сроки; однако изменения, вызванные собственными проектными ошибками подрядчика, относятся на его счет.
Ключевые аспекты управления изменениями:
| Критерий сравнения | Китайские национальные стандарты/Положения о генеральном подряде | Международные стандарты (Желтая книга FIDIC) | Местные стандарты принимающей страны |
|---|---|---|---|
| Контрактный шаблон | «Типовой договор генерального подряда на строительство» | Желтая/Оранжевая книга FIDIC | Определяются каждой страной; в Саудовской Аравии, ОАЭ есть местные шаблоны |
| Ответственность за проектирование | Подрядчик отвечает за пригодность проекта | Подрядчик отвечает за пригодность проекта | Зависит от местного законодательства; в некоторых странах требуется печать местного проектного института |
| Распределение рисков | Склонность к принятию заказчиком непредвиденных геологических рисков | Четкое разграничение, подрядчик несет больше рисков | Различия велики, требуется страновой due diligence |
| Критерии приемки | Национальные стандарты + условия контракта | Контракт + международные нормы | Обязательные местные нормы, часто параллельно с международными стандартами |
| Разрешение споров | Внутренний арбитраж/суд | Международный арбитраж (ICC/CIETAC) | Местные суды или международный арбитраж |
Практическое замечание: в зарубежных DB-проектах часто возникает «наложение трех стандартов» — контракт ссылается на FIDIC, проектирование опирается на китайские национальные стандарты, а строительство должно соответствовать местным обязательным нормам. Подрядчик обязан на стадии тендера четко определить приоритет стандартов, чтобы избежать споров при приемке.
По данным открытых источников, ряд проектов угольных электростанций в рамках Китайско-пакистанского экономического коридора реализуется по модели EPC/DB, где китайский центральный госкомпания-генподрядчик отвечает за проектирование, закупки, строительство и пусконаладку. Такие проекты имеют сжатые сроки и строгие показатели производительности, а модель DB позволяет эффективно интегрировать проектный институт и строительные бригады для реализации быстрого пути. Конкретные названия проектов и суммы следует искать в официальных открытых источниках.
Вдоль маршрута «Одного пояса, одного пути» некоторые проекты скоростных автомагистралей реализуются по модели DB, где подрядчик отвечает за проектирование трассы, строительство земляного полотна и дорожного покрытия, а также монтаж транспортной инфраструктуры. Такие проекты характеризуются сложными геологическими условиями, и DB-подрядчик снижает сложность строительства и затраты за счет оптимизации проектных решений (например, корректировки трассы, оптимизации откосов). Открытые источники можно найти на официальных сайтах соответствующих центральных госкомпаний и на сайте Департамента зарубежных инвестиций и сотрудничества Министерства коммерции.
Проекты промышленных парков на Ближнем Востоке часто реализуются по модели DB: заказчик предоставляет генеральный план и функциональные требования, а подрядчик отвечает за детальное проектирование, строительство и частичный монтаж оборудования. Такие проекты должны соответствовать местным обязательным нормам гражданской обороны, охраны окружающей среды, пожарной безопасности, и DB-подрядчик обязан интегрировать местных проектных консультантов с международными стандартами. Конкретные примеры следует искать в открытых источниках.
В1: В чем разница между DB и EPC?
DB и EPC весьма схожи по структуре контракта — обе представляют собой интеграцию проектирования и строительства. Различие в том, что EPC в большей степени акцентирует «сдачу под ключ»: подрядчик несет более широкую ответственность за закупки и пусконаладку; DB иногда охватывает только проектирование и строительство, а закупки осуществляет заказчик. В международной практике эти термины часто используются взаимозаменяемо — ключевое значение имеет объем работ по контракту (Scope of Work).
В2: Как заказчик контролирует качество проектирования в модели DB?
Заказчик определяет показатели производительности через документ функциональных требований (Employer's Requirements) и участвует в подтверждении ключевых проектных решений через точки экспертизы проекта, но не должен чрезмерно вмешиваться в детали проектирования, иначе может нести соответствующую ответственность. Рекомендуется включить положение «экспертиза проекта не снимает ответственности с подрядчика».
В3: Как DB-подрядчик выстраивает отношения с местным проектным институтом?
Распространенные подходы: создание консорциума с местным проектным институтом или привлечение его в качестве субподрядчика на проектирование. Местный институт отвечает за соответствие местным нормам, получение разрешений и согласований; международный/китайский институт — за общие решения и ключевые технологии. В соглашении о консорциуме необходимо четко определить разделение труда, ответственность и интеллектуальную собственность.
В4: Какой глубины должно достигать проектирование на стадии тендера DB-проекта?
Обычно требуется глубина базового проектирования (Basic Design) или концептуального проектирования+, достаточная для оценки объемов работ и стоимости. Слишком детальное тендерное проектирование увеличивает затраты, слишком поверхностное — ведет к недооценке рисков. Рекомендуется определять исходя из требований тендерной документации заказчика.
В5: Кто несет риск непредвиденных геологических условий в модели DB?
Зависит от условий контракта. По Желтой книге FIDIC подрядчик обычно несет геологические риски, но если предоставленные заказчиком данные изысканий содержат существенные расхождения, подрядчик может требовать корректировки цены. Рекомендуется провести независимые изыскания до тендера и четко определить геологическую базовую линию (Geotechnical Baseline) в контракте.
1. Тщательный due diligence до тендера: законодательство, налогообложение, валютное регулирование, трудовое право, экологические нормы, система стандартов принимающей страны — проверить по каждому пункту, чтобы избежать ситуации «выиграл тендер — получил убыток».
2. Четко определить границы функциональных требований: преобразовать каждый пункт Employer's Requirements в проверяемые показатели производительности, неясные места уточнить письменно.
3. Ранняя интеграция проектирования и строительства: сразу после победы в тендере сформировать объединенную проектную команду, подключить строителей на раннем этапе, провести оценку технологичности.
4. Создать механизм контроля изменений: все изменения оформлять письменно, создать CCB, четко определять влияние на стоимость и сроки, предотвращать изменения по принципу «варки лягушки в теплой воде».
5. Зафиксировать приоритет ключевых стандартов: в контракте четко указать порядок применения: «местные обязательные нормы > международные стандарты по контракту > китайские национальные стандарты» — во избежание споров при приемке.
6. Заложить резерв в гарантиях производительности: при тендерном ценообразовании предусмотреть разумный запас по показателям производительности, чтобы избежать крупных штрафов за их невыполнение.
7. Активно использовать страхование и гарантии: оформить страхование профессиональной ответственности, страхование всех рисков строительства, требовать от субподрядчиков банковские гарантии исполнения — передать часть рисков.
8. Уделять внимание управлению периодом ответственности за дефекты: заранее разработать план устранения дефектов, сохранить достаточный гарантийный фонд и персонал, чтобы избежать затягивания окончательной приемки.
9. Предусмотреть положения о разрешении споров: отдавать предпочтение международному арбитражу (например, ICC, SIAC), четко указать место арбитража, язык и применимое право.
10. Сочетать локализацию и комплаенс: привлекать местных консультантов, юристов, бухгалтеров для обеспечения соответствия при получении разрешений, налогообложении, трудовом законодательстве — снижать страновые риски.
---
*Настоящий документ подготовлен на основе открытых источников и отраслевой практики; конкретные данные проектов и номера стандартов следует уточнять по официальным документам и условиям контрактов.*