#простоосложном_EPC
Автор: Елена Стюарт
Управляющий партнер
Глава практики «Промышленное строительство»
Stuarts Legal LLC
Итак, заказчик строит фабрику, например, шоколадную, ну а почему нет. Заказчик нанимает EPC подрядчика, чтобы иметь в проекте turnkey liability, то есть ответственность под ключ в лице EPC подрядчика.
Во-первых, потому что это удобно, а, во-вторых, потому что проектные кредиторы не всегда готовы предоставлять финансирование, если завод строится по схеме multi lot, то есть с множеством подрядчиков. Почему? Потому что для проектных кредиторов, то есть банков, это риски: чем больше подрядчиков в проекте, тем больше вероятность, что кто-то из них нарушит сроки работ или не выполнит иные договорные обязательства, следовательно риск задержки ввода шоколадной фабрики в эксплуатацию повышается, а за ним и риск дефолта заемщика, то есть владельца фабрики, потому что не запущенный вовремя объект — это неполученная вовремя выручка от продажи продукции, которая в 90% случаев по кредитному соглашению находится в залоге у кредиторов, а это заставляет банки нервничать, и небезосновательно, надо отметить.
Проектирование шоколадной фабрики
В части проектирования фабрики возможны несколько векторов. Давайте рассмотрим каждый из них как в плоскости российского права, так и английского права, применяемого к 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 заказчик и кредиторы.
Поэтому EPC подрядчик нанимает лицензиара, то есть лицо, которое обладает технологией выпуска шоколада с требуемыми характеристиками. Лицензиар выполняет pre-FEED или FEED проектирование, то есть базовое проектирование, куда закладывает технологию производства шоколада, а EPC подрядчик дорабатывает базовый проект под российские нормы, получая из него полноценную проектную документацию.
Однако в ходе согласования условий EPC контракта с заказчиком EPC подрядчик может сказать примерно следующее: “Я, разумеется, готов отвечать за недостижение шоколадной фабрикой согласованных в контракте гарантированных показателей, за исключением случаев, если такие гарантированные показатели не достиглись ввиду ошибки в FEED (базовом проекте). Потому что я не обладаю квалификацией для проверки FEED пакета на ошибки за лицензиаром. Базовый проект лицензиара для меня это rely upon information, то есть информация, на которую я полагаюсь как на достоверную и не обязан ее проверять”.
Что с этим делать?
История с тем, являются ли какие-либо исходные данные rely upon information или non rely upon information в большинстве случаев — вопрос коммерческих переговоров, но есть и ряд технических аспектов, на которые сложно повлиять.
Особенно чувствительна и важна данная тема для EPC подрядчиков при приемке исходных данных от заказчика перед началом проекта. EPC подрядчик должен четко понимать и письменно фиксировать в EPC контракте, какие переданные заказчиком исходные данные, могут быть проверены EPC подрядчиком, а какие — нет. В случаях, когда часть исходных данных может быть проверена EPC подрядчиком на предмет корректности, мы ведем речь о non rely upon information, то есть об информации, на которую нельзя полагаться и надо проверять.
В случаях, когда часть исходных данных не может быть проверена EPC подрядчиком на предмет корректности, мы ведем речь о 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 подрядчик действительно не может: например, различные технические условия на подключение, состав сырья для тестов если его дает заказчик и т.д.
Техническая команда подрядчика должна проделать важную работу, чтобы определить за достоверность каких исходных данных EPC подрядчик не отвечает и прямо прописать, что такие исходные данные рассматриваются сторонами EPC контракта как rely upon information, то есть информация, на которую подрядчик полагается.
Когда мы представляем заказчика в EPC проекте, вопрос rely upon information также играет важную роль как для заказчика, так и для проектных кредиторов. Часто акционеры компании — заказчика не в курсе, что выбрали EPC подрядчика, которые спустя три-четыре месяца переговоров как бы невзначай на кофе-брейке говорит, что отвечает только за свою часть проектирования, российскую. A тот базовый пакет проектирования, что сделал иностранный лицензиар, которого сам же EPC подрядчик и нанял, он проверять не будет, потому что он не владелец технологии и не может проверить базовый проект за лицензиаром.
Поэтому если шоколадная фабрика будет производить меньше шоколада, чем было согласовано в техническом задании, и экспертиза скажет, что ошибка «сидит» в FEED пакете, который «лег» в основу российской проектной документации, то заранее оцененные убытки за невыход на гарантированные показатели (performance liquidated damages) взыскивать будет не с кого.
Кроме того, кредиторы, прочитав такое условие в EPC контракте, скажут, что подобное условие делает EPC контракт non bankable (небанкуемым), проще говоря, денег на строительство шоколадной фабрики с таким условием в EPC контракте, не дадут. Потому что ценность реализации строительных проектов по схеме EPC и их более дорогая стоимость для заказчика состоит как раз в ответственности EPC подрядчика под ключ, что в свою очередь дает комфорт кредиторам и заказчику, так как они понимают, что проект, управляемый одним лицом, который за все отвечает, и для кредиторов это менее рисково, чем строительство фабрики тридцатью разными подрядчиками.
Прямой договор между заказчиком и лицензиаром на FEED пакет
Как мы писали выше, бывают случаи, когда заказчик нанимает иностранного проектировщика напрямую для разработки базового пакета проектирования, а затем отдает данный базовый пакет EPC подрядчику для адаптации под российские проектные нормы. И если при такой схеме EPC подрядчик говорит, что он не будет проверять FEED пакет на корректность, по тому, что у него нет экспертизы, то в таком варианте заказчик может пойти с требованиями о взыскании убытков к иностранному проектировщику.
Однако такой вариант не понравится кредиторам и коммерчески плох для заказчика тем, что лимит ответственности иностранного проектировщика будет рассчитываться от цены контракта с таким иностранным проектировщиком, которая априори будет меньше цены EPC контракта, следовательно заказчик получит меньшую сумму убытков, чем мог бы получить с EPC подрядчика.
Подводя итог вышенаписанному, следует помнить о том, что прежде, чем потратить месяцы на подготовку и согласование условий EPC контракта, включите в тендерный пакет или в term-sheet (основные условия контракта) условие о том, за корректность каких исходных данных EPC подрядчик должен отвечать по мнению заказчика, уделив особое внимание проверке базового проектирования от лицензиара.
EPC подрядчикам также рекомендуется крайне ответственно относиться к данному вопросу, чтобы потом не нести многомиллионные убытки за чужие ошибки, проверить которые не представлялось возможным.
#всебудетEPC
