• Новости
• Блоги
• Аналитика
• Новости компаний
• В СНГ и в мире
• Анонсы

Обоюдоострая игра: как исполнители пытаются переиграть заказчика при создании ЦОДа

Иногда исполнитель, пользуясь своим опытом или встречая в лице заказчика откровенно слабую команду, совершает действия, которые нельзя назвать вполне добропорядочными. Что может и должен предпринять в такой ситуации заказчик?

В идеале в отношениях между заказчиком и исполнителем соблюдаются все общепринятые правила игры, как писаные, так и неписаные. Мы же в этой статье рассмотрим случай, когда заказчик готов платить за всё, а оптимизаторы-исполнители пускаются на разные хитрости, чтобы за б'ольшие деньги сделать меньше. Именно такая в некотором смысле вырожденная модель отношений позволит описать все уловки исполнителя и, что не менее важно, дать заказчику рекомендации, как им противодействовать.

Однако нужно понимать, что нередко причиной исключения из состава работ тех или иных элементов является откровенное скряжничество заказчика, а никак не злой умысел исполнителей. В подавляющем большинстве случаев это замечание относится и к составу и содержанию эксплуатационной документации и программы и методики испытаний, и к техническому заданию.

Конкурсные процедуры

Уловка № 1. Приукрашивание информации о проектном опыте

Если выбор исполнителя каких-либо работ в проекте создания ЦОДа ведется на основе конкурса, то почти всегда одним из квалификационных требований является информация об опыте исполнителя, его предыдущих проектах.

Здесь, во-первых, претендент на роль исполнителя может представить некорректную информацию о «величии» выполненных проектов (объемах работ, параметрах созданных систем и т.п.). Во-вторых, можно столкнуться с превратным описанием роли и места претендента в указанных проектах. В-третьих, может быть представлен длинный список реализованных проектов, по своим масштабам не сопоставимых с проектом, которому посвящен конкурс.

Как противодействовать таким уловкам?

• В конкурсной документации формируйте четкий перечень данных о проектном опыте, которые должны быть предоставлены. Рекомендуем следующий минимальный список: даты начала и окончания проекта, роль в проекте, состав выполненных работ, характеристика объектов (площади, количество зданий, подведенная мощность и т.п.).

• Требуйте предоставления референсных писем от заказчиков предыдущих проектов – не менее чем за два последних года. Требуйте указать контактную информацию о заказчиках всех проектов, заявленных исполнителем. Не поленитесь провести выборочный обзвон для получения информации о проекте и мере участия в нем исполнителя (не всегда вам ответят и ответят честно, но проделать такой обзвон все равно стоит).

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

Уловка № 2. «Блуждающая» квалификация персонала

Многочисленные проекты и декларируемый исполнителем большой опыт их исполнения – функция персонала, в этих проектах участвующего. Можно столкнуться с ситуацией, когда в заявке на конкурс исполнитель указывает проекты, в которых его участие свелось к посредничеству. В принципе ничего плохого в этом нет – субподряд в современном мире более чем распространен. Но в сложных и больших проектах отсутствие собственного квалифицированного персонала может сказаться на качестве работ субподрядчиков: если последние не суперпрофессионалы или были лишены материальных стимулов качественной работы, то головной исполнитель в отсутствие собственных кадров не сможет «отловить» проблемы, ошибки и некачественные результаты.

Что можно сделать для выявления такой ситуации еще на этапе конкурса?

• Запрашивайте персональный состав проектной команды исполнителя, подтвержденный копиями кадровых документов.

• Требуйте указать, в каких проектах, ранее реализованных исполнителем, участвовали и какие роли в этих проектах играли его штатные сотрудники.

• Не ограничивайте привлечение субподрядчиков для выполнения работ. Постарайтесь создать условия для того, чтобы головной исполнитель еще на этапе конкурса рассказал вам о своих субподрядчиках.

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

Техническое задание

Уловка № 3. Закладки в техническом задании

Желание исполнителей учесть в техзадании свои коммерческие интересы в отношении будущих поставок оборудования определенных производителей вполне объяснимо с точки зрения их прибылей. Но не всегда такой подход допустим – удобный исполнителю вариант может ухудшить общие характеристики ЦОДа и ввести заказчика в дополнительные расходы при эксплуатации.

Как нивелировать последствия такого подхода?

• Введите в проект стадию разработки технической концепции. На этой стадии вы сможете получить сравнительный анализ различных вариантов решений для отдельных систем ЦОДа.

• ТЗ следует разрабатывать, базируясь на согласованной технической концепции. Тогда все требования в нем достаточно легко проверяются на соответствие эскизным решениям.

• Если ввести стадию технической концепции в проект нельзя, усильте проектную команду консультантами и требуйте от разработчика ТЗ четких обоснований всех положений, записанных в документе.

Уловка № 4. Слишком общие требования в техническом задании

Общие, не детальные требования к системам ЦОДа могут стать причиной ухода проектных разработок в области, не отвечающие первоначально заданным параметрам ЦОДа и его систем: заказчик может получить совсем не то, что ожидал. Виной тому будет скудость формулировок требований и их поверхностный характер. А на испытаниях систем по таким неполным требованиям будет сложно проверить, насколько реализованное отвечает исходным запросам.

Что противопоставить такой практике?

• Заставьте исполнителя максимально детально описать требования к создаваемой системе.

• Вместе с тем не блокируйте внесение изменений в ТЗ по ходу реализации проекта – необходимость в этом может быть не связана с желанием исполнителя облегчить свою участь.

• При формировании требований к отдельным инженерным системам добивайтесь наличия как минимум следующих разделов:

  • назначение;

  • состав;

  • режимы работы;

  • функционирование;

  • требования к смежным системам (электропитания, охлаждения, мониторинга и др.);

  • показатели назначения (какими параметрами определяется работа системы в каждом режиме – штатном, аварийном, обслуживания);

  • обслуживание (специфика эксплуатации и технического обслуживания);

  • ремонтопригодность.

Уловка № 5. Разработка технического задания на проектирование, а не на создание ЦОДа

Техническое задание на создание ЦОДа – важный, основополагающий документ. В общем случае такое ТЗ рази­тельно отличается от традиционного задания на проектирование, требования в котором зачастую не детальны. Да и действует такое задание лишь на стадии проектных работ. Требования же из ТЗ на создание ЦОДа будут применяться не только на стадии проектирования, но и на стадии испытаний, когда придет время поверить реализованные технические решения полевыми тестами.

Когда-то форма и содержание задания на проектирование устанавливались СНиП 11-01-95, уже десять лет как выведенными из обращения. Нередко приходится сталкиваться с тем, что исполнитель не видит ничего, кроме задания на проектирование, и манипулирует заказчиком, отказываясь разрабатывать полноценное техзадание, которое определяло бы требования не только к проектированию, но и к остальным этапам создания ЦОДа – строительству и испытаниям (вводу в эксплуатацию).

С нашей точки зрения, никаких нормативных препятствий для разработки технического задания на создание ЦОДа нет (как мы указывали выше, финансовые аспекты рассматриваемая модель не учитывает). Попытки ограничиться заданием на проектирование и уйти от составления полноценного документа должны пресекаться заказчиком. Практика российского цодостроения последнего пятилетия показывает, что разработка ТЗ на создание ЦОДа значительно облегчает жизнь заказчика и позволяет получить результат высокого качества.

Что можно посоветовать по этому вопросу?

• Вместе с заданием на проектирование разрабатывайте техническое задание на создание ЦОДа.

• Если есть возможность, делегируйте задачу разработки такого ТЗ консультанту.

• Если ТЗ разрабатывает проектировщик, требуйте, чтобы это был свод заданий не только на проектирование.

Проектирование

Уловка № 6. Спекулирование нормативами на состав проектной документации и ее содержание

Существует расхожее мнение, что единственным документом, содержащим требования к проектной документации, является Постановление № 87*. Отчасти это верно. Однако никто и ничто не мешает подготовить проектную документацию по какой-либо отдельной инженерной системе в соответствии, например, с ГОСТ 34 или ГОСТ 24. В ряде случаев полезно использовать ГОСТ 2 – базовую систему для всех классов технической документации.

Современные системы, входящие в состав инженерной инфраструктуры ЦОДа, давно перестали быть простыми. Системы мониторинга, видеонаблюдения, контроля и управления доступом, сигнализации, ра­дио­переговоров, телефонной связи и другие по своей структуре, функциям и средствам реализации без какой-либо натяжки могут быть отнесены к автоматизированным системам. Использование при разработке проектной документации для этих систем требований Системы проектной документации в строительстве (СПДС) и Постановления № 87 значительно усугубляет риски недостаточной проработки технических решений и, как следствие, проблемы при реализации решений и их эксплуатации.

Что же делать?

• Определите те инженерные системы, для разработки документации на которые следует применять ГОСТы из соответствующих отраслей.

• Внимательно отнеситесь к формированию требований в ТЗ по использованию нормативно-технической базы для разработки проектной документации – для каждой системы задайте свою собственную нормативную базу.

Уловка № 7. Согласование проектной документации одним пакетом

Для сложного ЦОДа объем проектной документации может достигать десятков и сотен томов. Все решения для любой системы нуждаются в тщательной проверке и согласовании.

Зачастую исполнитель пытается сдать весь комплект проектной документации сразу и загнать заказчика в узкие рамки ограниченных сроков ее согласования. При традиционной загруженности персонала заказчика и отсутствии высококвалифицированных кадров изучение и согласование проектной документации может стать формальным и безыдейным. В результате заказчик, поверхностно прочитав и согласовав документацию, при возникновении проблем с техническими решениями будет вынужден нести свою долю ответственности и не сможет противостоять исполнителю.

Как снизить риск реализации такого сценария?

• Требуйте от исполнителя четкого планирования проектных работ, при котором подготовка и согласование технических решений будут поэтапными.

• Не бойтесь потратить время на презентации основных принципов технических решений до начала их документирования.

• В плане проектных работ требуйте отвести больше времени на ознакомление и согласование решений и проектной документации.

• Если вам позволяют жизненная позиция и бюджет, наймите консультанта и передайте ему рецензирование проектной документации.

• Ведите протоколы рабочих встреч, посвященных обсуждению решений и документации.

Уловка № 8. Забывчивость при исправлении замечаний

Когда вам удалось создать комфортные условия для ознакомления с проектными решениями и документацией, остается еще одна важная задача – отследить, что все ваши замечания учтены в финальной версии проектной документации. Даже получив замечания официальными письмами или протокольными поручениями, исполнитель может игнорировать неудобные для себя вопросы и про часть замечаний просто «забыть».

Как этой уловке противостоять?

• Ведите реестр замечаний, в который должны заноситься все ваши замечания, комментарии и вопросы. Для каждой записи реестра должны быть предусмотрены такие поля: дата поступления замечания, автор, сведения о документе, его разделе и странице, к которой сделано замечание, формулировка замечания. Все эти данные вместе с исходным документом должны передаваться исполнителю.

• Для каждой записи также должны быть предусмотрены поля, заполняемые исполнителем: дата ответа на замечание, автор ответа, статус замечания (принято, отклонено, принято к сведению и т.п.), комментарий с аргументацией, ссылка на место в новой версии проектной документации, в котором сделано исправление по замечанию.

• Храните реестр замечаний в двух равноценных экземплярах. Например, у руководителей проектных команд заказчика и исполнителя.

• Процедуру работы с реестром замечаний можно описать в техзадании или, при правильном подходе к проектному управлению, в уставе проекта.

Уловка № 9. Манкирование эксплуатационной документацией

Качественная и содержательная эксплуатационная документация – больная мозоль отечественной отрасли ЦОДов. Существует превратное мнение, что ЭД – это то, что приходит в комплекте с оборудованием. Такой подход допустим, когда инженерные системы просты и состоят из единичных образцов оборудования. Когда же системы сложны и их эксплуатация – задача нетривиальная, комплексная, требуется разработка эксплуатационной документации. Для каждой инженерной системы желательно иметь документ, который описывал бы основные процедуры управления и переключения систем в разных режимах.

Кто должен разрабатывать такую эксплуатационную документацию? Для ответа на этот вопрос стоит вспомнить, кто разрабатывает (придумывает) технические решения для ЦОДа – проектировщик. Кто, как не проектировщик, должен понимать и описать процедуры управления спроектированными им системами? Ответственность за работоспособность решений лежит на проектировщике. Да, монтажная организация может и должна внести в ЭД изменения, которые могут потребоваться по результатам монтажа и пусконаладки. Но базовые эксплуатационные документы на системы ЦОДа – ответственность проектировщиков.

Как исполнитель пытается уйти от этой задачи? В подавляющем большинстве случаев он ссылается на Постановление № 87 (см. уловку № 7) и СПДС, указывая, что эксплуатационная документация не предусмотрена ни первым, ни вторым нормативом.

Что можно противопоставить такой позиции?

• Добавьте формальные требования разработки ЭД в техническое задание или контракт.

• Задайте отличные от Постановления № 87 нормативные базы для разработки документации: например, ГОСТ 34, ГОСТ 24, ГОСТ 2. Это облегчит задачу определения состава рабочей документации, в которую должны войти тома ЭД.

Строительство

Уловка № 10. Ненадлежащее управление подрядчиками со стороны генподрядчика

Традиционное желание заказчика пошить семь больших шапок из одной овцы, в частности построить ЦОД в максимально сжатые сроки, зачастую приводит к тому, что генподрядчик в ходе конкурса соглашается на нереальные для себя сроки, заранее понимая, что он их нарушит. Это болезнь всей отечественной строительной отрасли, но в случае ЦОДов она проявляется особенно ярко, так как плотность размещения инженерных коммуникаций и количество единовременно задействованных в строительстве подрядчиков могут быть даже выше, чем в сложных современных заводах.

Хорошо, если генподрядная организация отлично понимает специфику строительства ЦОДа и на собственном опыте может реально оценить сроки работ. Но порой эта задача ставится перед традиционным строительным генподрядчиком, который по незнанию может промахнуться со сроками, как в одну, так и в другую сторону.

Каких правил стоит придерживаться, дабы избежать подобных конфузов?

• Еще на этапе выбора генерального подрядчика, в процессе конкурса, обяжите претендентов предоставить план работ с обязательной детализацией по каждой инженерной системе ЦОДа, с учетом их взаимосвязи и возможностью одновременного проведения работ на одном участке разными подрядными организациями. Это заставит генподрядчика реально оценить сроки выполнения работ.

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

• Не пренебрегайте таким проверенным инструментом, как журнал производства работ, в котором представители подрядчика ежедневно фиксируют выполненные за день объемы работ. Это позволит контролировать актуальность еженедельных отчетов и темпы выполнения тех или иных подзадач.

Уловка № 11. Внесение изменений в документацию

В ходе строительства ЦОДа порой возникает объективная потребность внесения изменений в технические решения, принятые на этапе проектирования. Она может быть вызвана снятием с производства того или иного оборудования, выявлением различных факторов, препятствующих реализации проектных решений, например, обнаружением скрытых строительных дефектов здания или невозможности прокладки трасс коммуникаций по определенным в проектной документации маршрутам.

Все эти изменения могут повлечь за собой существенные трансформации принятых проектных решений и, как следствие, изменение сметной стоимости. Если возможность таких изменений прописана в договоре, то недобросовестный исполнитель не преминет воспользоваться сложившейся ситуацией в своих интересах. Более того, он может сам спровоцировать подобную ситуацию в надежде на получение дополнительного финансирования.

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

Что надо делать во избежание проблем при изменении проектных решений?

• Привлекайте проектную организацию, разработавшую документацию на строительство ЦОДа, для авторского надзора за процессом строительства. Это позволит принимать более взвешенные оперативные решения, которые уменьшат вероятность ухудшения технико-экономических показателей объекта и ограничат попытки генподрядчика вольно интерпретировать проектные решения.

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

Уловка № 12. «Слепое» актирование работ

Акты скрытых работ – это то, о чем часто забывает неискушенный в строительной науке заказчик. Если источники бесперебойного питания или кондиционеры достаточно легко проверить на соответствие проектной и закупочной документации, то ситуация с кабельными трассами, трубопроводами, строительными работами и т.п. намного сложнее. После окончания монтажа не всегда есть возможность увидеть, какие материалы были использованы, и уж тем более оценить качество произведенных работ.

Этим непременно постараются воспользоваться недобросовестные подрядчики-исполнители. И трубопровод заложат не того диаметра либо не из определенного проектом материала, и кабель протянут не медный, а алюминиевый, и трубопроводную фурнитуру закупят не европейскую, а китайскую. А уж как экономично покрасят металлоконструкции не тремя, а одним слоем огнезадерживающей краски или применят бетон не той марки!

Порой подрядчик может и вовсе не выполнить часть таких работ, как проведение электроизмерений, которые вроде не несут явной функциональности, но отнимают время. Он приходит к заказчику и просит «подмахнуть» очередной акт без реальной приемки работ. А через полгода, например, происходит короткое замыкание, и заказчику приходится останавливать ЦОД и добираться, пусть и в рамках гарантии, до злосчастного кабеля, лежащего на самом дне лотка. А если пожар?

Как не допустить возникновения таких ситуаций?

• Обяжите каждую подрядную организацию указывать в плане работ по каждой подсистеме, где и в какой момент времени необходимо присутствие заказчика для приемки тех или иных, в том числе скрытых работ.

• Ни в коем случае не пренебрегайте личным присутствием при приемке промежуточных работ, так как это, пожалуй, основной инструмент контроля, которым неопытный заказчик может существенно повысить уверенность в том, что ЦОД будет работать долго и счастливо.

• Разработайте и согласуйте с исполнителем прозрачную и простую схему информирования об актировании скрытых работ.

• Выделите с вашей стороны специального ответственного за подписание актов скрытых работ, представьте его исполнителю и обяжите исполнителя держать постоянную связь с этим человеком.

Испытания и ввод в эксплуатацию

Уловка № 13. Побег от испытаний

На наш взгляд, это одна из самых больших проблем в нынешнем процессе создания ЦОДов. Она несет на себе печать строительного прошлого инженерной инфраструктуры ЦОДа: в нормативе СНиП 3.01.04-87, на который принято ссылаться при обсуждении испытаний, они упоминаются: «предоставить акты испытаний», но и только. Нормативная база для испытаний значительной части инженерных систем практически отсутствует.

Вдобавок к этому полноценные ТЗ на создание ЦОДа, как правило, не разрабатываются (см. уловку № 5), стало быть, нет документа, который определял бы обязанности исполнителя по подготовке и проведению испытаний. Аналогичная ситуация с занесением этих обязанностей в контракт: в большинстве случаев в контракт вносятся работы по монтажу и пусконаладке. Последняя включает в себя индивидуальные испытания, но они прописаны не так четко и не для всех инженерных систем ЦОДа.

Безусловно, в конце концов испытания удается провести даже в самых запущенных проектных случаях, но на принуждение исполнителя к этой работе уходит много сил и нервов. В такой обстановке испытания проводятся «для галочки» и не достигают своей главной цели – проверить реализованные проектные решения.

Какие инструменты можно использовать, чтобы справиться с этой проблемой?

• В явном виде указывайте в контрактах требование подготовки и проведения всех видов испытаний.

• В ТЗ на создание ЦОДа формируйте требования к проведению испытаний, в том числе минимальный набор проверок для каждой инженерной системы.

• Озаботьтесь проведением комплексных испытаний. Инженерные системы ЦОДа должны работать во взаимодействии – проверить эту работу необходимо в ходе комплексных испытаний.

Уловка № 14. Уход от разработки программы и методики испытаний

Одним из элементов уловки № 13 является «перетягивание каната» по подготовке программы и методики испытаний (ПМИ) – документа, определяющего порядок проведения испытаний, условия, ответственность сторон, требования к персоналу, участвующему в испытаниях, требования к материально-техническому и метрологическому обеспечению испытаний.

Первая фаза такого «перетягивания каната» приходится на этап проектирования: проектировщики в категорической форме отказываются от разработки ПМИ. Что, на наш взгляд, в корне неверно. Только разработчик решения – проектная организация – знает, каким именно испытаниям необходимо подвергнуть реализованную систему для того, чтобы проверить ее работоспособность и функционирование во всех режимах.

Одним из истоков этой проблемы является положение дел, описанное в уловке № 6: спекулирование требованиями Постановления № 87 приводит к тому, что от ПМИ проектировщик открещивается.

Каков же выход из этой ситуации?

• Добавьте формальные требования разработки ПМИ на отдельные инженерные системы в техническое задание или контракт.

• Оставьте за организацией, выполняющей монтаж и пусконаладку, возможность внесения корректив в ПМИ, разработанную проектировщиком.

• Задайте в ТЗ и контракте отличные от Постановления № 87 нормативные базы для разработки документации на отдельные системы: например, ГОСТ 34, ГОСТ 24, ГОСТ 2. Во всех этих сериях стандартов в составе рабочей документации есть ПМИ.

  

Безусловно, мы описали далеко не все проблемы, с которыми приходится сталкиваться на практике: жизнь сложнее любой модели. Хотелось бы выделить основные принципы, положенные в основу большинства данных нами рекомендаций:

• Используйте перспективное планирование и регулярную актуализацию плана, что позволит избежать неожиданностей и предугадывать ход событий.

• Вовремя фиксируйте дополнительные требования к составу и содержанию работ, это сэкономит вам время, нервы и деньги.

• Усиливайте свою проектную команду квалифицированными кадрами, не пренебрегайте опытом консультантов.  

___________________________________________________________________

* Постановление Правительства РФ от 16.02.2008 № 87 «О составе разделов проектной документации и требованиях к их содержанию».