Заказчик строит фабрику, например, шоколадную, ну а почему нет. Заказчик нанимает EPC подрядчика, чтобы иметь в проекте turnkey liability, то есть ответственность под ключ в лице EPC подрядчика.
Во-первых, потому что это удобно, а, во-вторых, потому что проектные кредиторы не всегда готовы предоставлять финансирование если завод строится по схеме multi lot, то есть с множеством подрядчиков. Почему? Потому что для проектных кредиторов, то есть банков, это риски: чем больше подрядчиков в проекте, тем больше вероятность, что кто-то из них нарушит сроки работ или не выполнит иные договорные обязательства, следовательно риск задержки ввода шоколадной фабрики в эксплуатацию повышается, а за ним и риск дефолта заёмщика.
Проектирование шоколадной фабрики
В части проектирования фабрики возможны несколько векторов. Давайте рассмотрим каждый из них как в плоскости российского права, так и английского права, применяемого к EPC договору.
Вектор 1 · Сам себе проектировщик
EPC подрядчик проектирует собственными силами, что бывает редко, но бывает. То есть EPC подрядчик не берет на субподряд проектный институт, в его штате есть проектировщики. Это идеальный вариант для всех сторон EPC контракта, потому что, если EPC подрядчик допускает ошибку в расчётах при разработке FEED документации или проектной документации, ввиду чего завод не выходит на гарантированные показатели либо в ходе 72 часовых тестов, либо в иной срок, установленный EPC контрактом, это целиком ответственность EPC подрядчика.
Вектор 2 · EPC подрядчик нанимает проектировщиков
На практике чаще всего встречается ситуация, когда EPC подрядчик заключает договор субподряда с одним или несколькими проектировщиками.
В зависимости от технологической сложности EPC проекта проектировщик (как правило, иностранный) может разрабатывать только FEED пакет (front end engineering design), то есть базовое или предварительное проектирование, куда заложена технология производства, сам EPC подрядчик адаптирует базовый пакет под российские проектные нормы согласно Постановлению 87 «О составе разделов проектной документации и требованиях к их содержанию» от 16 февраля 2008 года.
Либо EPC подрядчик отдаёт базовый проект на субподряд российскому проектировщику для целей адаптации под российские проектные нормы и получает от него пакет проектной документации, соответствующий российским нормам.
Вектор 3 · Заказчик отдаёт FEED документацию как исходные данные
Бывает так, что заказчик заключает договор на разработку базового проектирования с лицензиаром (владельцем технологии) напрямую и потом отдаёт FEED пакет как исходные данные EPC подрядчику для целей включения в состав российской проектной документации в адаптированном виде.
Что такое rely upon и non rely upon information в проекте
Иногда EPC подрядчик не хочет нести ответственность за технологические решения, которые «сидят» в проекте. Рассмотрим на примере нашей шоколадной фабрики. EPC подрядчик чаще всего не лицензиар, то есть он знает как построить фабрику, но не знает какие технологические решения надо заложить в проект, чтобы фабрика выпускала шоколад с определёнными характеристиками.
Поэтому EPC подрядчик нанимает лицензиара, то есть лицо, которое обладает технологией выпуска шоколада с требуемыми характеристиками. Лицензиар выполняет pre-FEED или FEED проектирование, а EPC подрядчик дорабатывает базовый проект под российские нормы.
«Я готов отвечать за недостижение шоколадной фабрикой гарантированных показателей, за исключением случаев, если они не достиглись ввиду ошибки в FEED. Базовый проект лицензиара для меня — rely upon information».
Что с этим делать?
История с тем, являются ли какие-либо исходные данные rely upon information или non rely upon information в большинстве случаев это вопрос коммерческих переговоров, но есть и ряд технических аспектов, на которые сложно повлиять.
Особенно чувствительна и важна данная тема для EPC подрядчиков при приёмке исходных данных от заказчика перед началом проекта. EPC подрядчик должен чётко понимать и письменно фиксировать в EPC контракте, какие переданные заказчиком исходные данные могут быть проверены EPC подрядчиком, а какие — нет.
- Non rely upon information — информация, на которую нельзя полагаться и надо проверять.
- Rely upon information — информация, на которую следует полагаться и не надо проверять.
Для чего это нужно? Любая ошибка в исходных данных от заказчика, выявленная в ходе реализации проекта, может повлечь существенное увеличение сроков строительства той самой шоколадной фабрики. И если в EPC контракте подрядчик не зафиксировал за корректность каких исходных данных он отвечает, то де-юре он будет отвечать за всё, особенно если к EPC контракту будет применяться английское право.
Пример: древнее поселение под фундаментом
Например, заказчик передал EPC подрядчику результаты изысканий (геология, геодезия), которые выполнены отдельным подрядчиком. При начале строительных работ EPC подрядчик обнаружил древнее поселение, которое не было найдено подрядчиком, выполнявшим изыскания.
Что это значит для проекта? Верно, приостановка работ до года. Это так называемые subsurface risks. Но кто будет отвечать за просрочку сроков строительства в случае, если в EPC контракте ничего не сказано, обязан ли EPC подрядчик проверять исходные данные на корректность? В приведённом примере EPC подрядчик оказывается в очень плохой ситуации.
Когда мы представляем EPC подрядчика в проектах, мы обязательно садимся с его технической командой и поясняем им, почему нужно делать приложение, где чётко будет разграничено, какие исходные данные подлежат проверке EPC подрядчиком, а какие нет. Например, все результаты изысканий мы относим к rely upon information. И если в ходе свайных работ найдут древнее поселение, то EPC подрядчик не отвечает за задержку работ и не платит заказчику delay liquidated damages.
Тут ещё важен критерий разумности и здравого смысла. Ясно, что подрядчик в теории может проверить результаты изысканий, если пойдёт и заново всё раскопает площадку, но это не разумно, именно поэтому в мировой практике реализации EPC проектов так называемые subsurface risks лежат на EPC заказчике как владельце площадки.
Со стороны заказчика и кредиторов
Когда мы представляем заказчика в EPC проекте, вопрос rely upon information также играет важную роль как для заказчика, так и для проектных кредиторов. Часто акционеры компании-заказчика не в курсе, что выбрали EPC подрядчика, который спустя несколько месяцев переговоров как бы невзначай на кофе-брейке говорит, что отвечает только за свою часть проектирования, российскую. А тот базовый пакет проектирования, что сделал иностранный лицензиар, которого сам же EPC подрядчик и нанял, он проверять не будет.
Поэтому если шоколадная фабрика будет производить меньше шоколада, чем было согласовано в техническом задании, и экспертиза скажет, что ошибка «сидит» в FEED пакете, который «лег» в основу российской проектной документации, то заранее оцененные убытки за невыход на гарантированные показатели (performance liquidated damages) взыскивать будет не с кого.
Кредиторы скажут, что подобное условие делает EPC контракт non bankable, проще говоря, денег на строительство фабрики с таким условием не дадут.
Прямой договор между заказчиком и лицензиаром на FEED пакет
Бывают случаи, когда заказчик нанимает иностранного проектировщика напрямую для разработки базового пакета проектирования, а затем отдаёт данный базовый пакет EPC подрядчику для адаптации под российские проектные нормы. И если при такой схеме EPC подрядчик говорит, что он не будет проверять FEED пакет на корректность, по тому, что у него нет экспертизы, то в таком варианте заказчик может пойти с требованиями о взыскании убытков к иностранному проектировщику.
Однако такой вариант не понравится кредиторам и коммерчески плох для заказчика тем, что лимит ответственности иностранного проектировщика будет рассчитываться от цены контракта с таким иностранным проектировщиком, которая априори будет меньше цены EPC контракта, следовательно заказчик получит меньшую сумму убытков, чем мог бы получить с EPC подрядчика.
Подводя итог: прежде, чем потратить месяцы на подготовку и согласование условий EPC контракта, включите в тендерный пакет или в term-sheet условие о том, за корректность каких исходных данных EPC подрядчик должен отвечать по мнению заказчика, уделив особое внимание проверке базового проектирования от лицензиара.