Иногда исполнитель, пользуясь своим опытом или встречая в лице заказчика откровенно слабую команду, совершает действия, которые нельзя назвать вполне добропорядочными. Что может и должен предпринять в такой ситуации заказчик?
В идеале в отношениях между заказчиком и исполнителем соблюдаются все общепринятые правила игры, как писаные, так и неписаные. Мы же в этой статье рассмотрим случай, когда заказчик готов платить за всё, а оптимизаторы-исполнители пускаются на разные хитрости, чтобы за б'ольшие деньги сделать меньше. Именно такая в некотором смысле вырожденная модель отношений позволит описать все уловки исполнителя и, что не менее важно, дать заказчику рекомендации, как им противодействовать.
Однако нужно понимать, что нередко причиной исключения из состава работ тех или иных элементов является откровенное скряжничество заказчика, а никак не злой умысел исполнителей. В подавляющем большинстве случаев это замечание относится и к составу и содержанию эксплуатационной документации и программы и методики испытаний, и к техническому заданию.
Конкурсные процедуры
Уловка № 1. Приукрашивание информации о проектном опыте
Если выбор исполнителя каких-либо работ в проекте создания ЦОДа ведется на основе конкурса, то почти всегда одним из квалификационных требований является информация об опыте исполнителя, его предыдущих проектах.
Здесь, во-первых, претендент на роль исполнителя может представить некорректную информацию о «величии» выполненных проектов (объемах работ, параметрах созданных систем и т.п.). Во-вторых, можно столкнуться с превратным описанием роли и места претендента в указанных проектах. В-третьих, может быть представлен длинный список реализованных проектов, по своим масштабам не сопоставимых с проектом, которому посвящен конкурс.
Как противодействовать таким уловкам?
Уловка № 2. «Блуждающая» квалификация персонала
Многочисленные проекты и декларируемый исполнителем большой опыт их исполнения – функция персонала, в этих проектах участвующего. Можно столкнуться с ситуацией, когда в заявке на конкурс исполнитель указывает проекты, в которых его участие свелось к посредничеству. В принципе ничего плохого в этом нет – субподряд в современном мире более чем распространен. Но в сложных и больших проектах отсутствие собственного квалифицированного персонала может сказаться на качестве работ субподрядчиков: если последние не суперпрофессионалы или были лишены материальных стимулов качественной работы, то головной исполнитель в отсутствие собственных кадров не сможет «отловить» проблемы, ошибки и некачественные результаты.
Что можно сделать для выявления такой ситуации еще на этапе конкурса?
Уловка № 3. Закладки в техническом задании
Желание исполнителей учесть в техзадании свои коммерческие интересы в отношении будущих поставок оборудования определенных производителей вполне объяснимо с точки зрения их прибылей. Но не всегда такой подход допустим – удобный исполнителю вариант может ухудшить общие характеристики ЦОДа и ввести заказчика в дополнительные расходы при эксплуатации.
Как нивелировать последствия такого подхода?
Уловка № 4. Слишком общие требования в техническом задании
Общие, не детальные требования к системам ЦОДа могут стать причиной ухода проектных разработок в области, не отвечающие первоначально заданным параметрам ЦОДа и его систем: заказчик может получить совсем не то, что ожидал. Виной тому будет скудость формулировок требований и их поверхностный характер. А на испытаниях систем по таким неполным требованиям будет сложно проверить, насколько реализованное отвечает исходным запросам.
Что противопоставить такой практике?
Уловка № 5. Разработка технического задания на проектирование, а не на создание ЦОДа
Техническое задание на создание ЦОДа – важный, основополагающий документ. В общем случае такое ТЗ разительно отличается от традиционного задания на проектирование, требования в котором зачастую не детальны. Да и действует такое задание лишь на стадии проектных работ. Требования же из ТЗ на создание ЦОДа будут применяться не только на стадии проектирования, но и на стадии испытаний, когда придет время поверить реализованные технические решения полевыми тестами.
Когда-то форма и содержание задания на проектирование устанавливались СНиП 11-01-95, уже десять лет как выведенными из обращения. Нередко приходится сталкиваться с тем, что исполнитель не видит ничего, кроме задания на проектирование, и манипулирует заказчиком, отказываясь разрабатывать полноценное техзадание, которое определяло бы требования не только к проектированию, но и к остальным этапам создания ЦОДа – строительству и испытаниям (вводу в эксплуатацию).
С нашей точки зрения, никаких нормативных препятствий для разработки технического задания на создание ЦОДа нет (как мы указывали выше, финансовые аспекты рассматриваемая модель не учитывает). Попытки ограничиться заданием на проектирование и уйти от составления полноценного документа должны пресекаться заказчиком. Практика российского цодостроения последнего пятилетия показывает, что разработка ТЗ на создание ЦОДа значительно облегчает жизнь заказчика и позволяет получить результат высокого качества.
Что можно посоветовать по этому вопросу?
Уловка № 6. Спекулирование нормативами на состав проектной документации и ее содержание
Существует расхожее мнение, что единственным документом, содержащим требования к проектной документации, является Постановление № 87*. Отчасти это верно. Однако никто и ничто не мешает подготовить проектную документацию по какой-либо отдельной инженерной системе в соответствии, например, с ГОСТ 34 или ГОСТ 24. В ряде случаев полезно использовать ГОСТ 2 – базовую систему для всех классов технической документации.
Современные системы, входящие в состав инженерной инфраструктуры ЦОДа, давно перестали быть простыми. Системы мониторинга, видеонаблюдения, контроля и управления доступом, сигнализации, радиопереговоров, телефонной связи и другие по своей структуре, функциям и средствам реализации без какой-либо натяжки могут быть отнесены к автоматизированным системам. Использование при разработке проектной документации для этих систем требований Системы проектной документации в строительстве (СПДС) и Постановления № 87 значительно усугубляет риски недостаточной проработки технических решений и, как следствие, проблемы при реализации решений и их эксплуатации.
Что же делать?
Уловка № 7. Согласование проектной документации одним пакетом
Для сложного ЦОДа объем проектной документации может достигать десятков и сотен томов. Все решения для любой системы нуждаются в тщательной проверке и согласовании.
Зачастую исполнитель пытается сдать весь комплект проектной документации сразу и загнать заказчика в узкие рамки ограниченных сроков ее согласования. При традиционной загруженности персонала заказчика и отсутствии высококвалифицированных кадров изучение и согласование проектной документации может стать формальным и безыдейным. В результате заказчик, поверхностно прочитав и согласовав документацию, при возникновении проблем с техническими решениями будет вынужден нести свою долю ответственности и не сможет противостоять исполнителю.
Как снизить риск реализации такого сценария?
Уловка № 8. Забывчивость при исправлении замечаний
Когда вам удалось создать комфортные условия для ознакомления с проектными решениями и документацией, остается еще одна важная задача – отследить, что все ваши замечания учтены в финальной версии проектной документации. Даже получив замечания официальными письмами или протокольными поручениями, исполнитель может игнорировать неудобные для себя вопросы и про часть замечаний просто «забыть».
Как этой уловке противостоять?
Уловка № 9. Манкирование эксплуатационной документацией
Качественная и содержательная эксплуатационная документация – больная мозоль отечественной отрасли ЦОДов. Существует превратное мнение, что ЭД – это то, что приходит в комплекте с оборудованием. Такой подход допустим, когда инженерные системы просты и состоят из единичных образцов оборудования. Когда же системы сложны и их эксплуатация – задача нетривиальная, комплексная, требуется разработка эксплуатационной документации. Для каждой инженерной системы желательно иметь документ, который описывал бы основные процедуры управления и переключения систем в разных режимах.
Кто должен разрабатывать такую эксплуатационную документацию? Для ответа на этот вопрос стоит вспомнить, кто разрабатывает (придумывает) технические решения для ЦОДа – проектировщик. Кто, как не проектировщик, должен понимать и описать процедуры управления спроектированными им системами? Ответственность за работоспособность решений лежит на проектировщике. Да, монтажная организация может и должна внести в ЭД изменения, которые могут потребоваться по результатам монтажа и пусконаладки. Но базовые эксплуатационные документы на системы ЦОДа – ответственность проектировщиков.
Как исполнитель пытается уйти от этой задачи? В подавляющем большинстве случаев он ссылается на Постановление № 87 (см. уловку № 7) и СПДС, указывая, что эксплуатационная документация не предусмотрена ни первым, ни вторым нормативом.
Что можно противопоставить такой позиции?
Уловка № 10. Ненадлежащее управление подрядчиками со стороны генподрядчика
Традиционное желание заказчика пошить семь больших шапок из одной овцы, в частности построить ЦОД в максимально сжатые сроки, зачастую приводит к тому, что генподрядчик в ходе конкурса соглашается на нереальные для себя сроки, заранее понимая, что он их нарушит. Это болезнь всей отечественной строительной отрасли, но в случае ЦОДов она проявляется особенно ярко, так как плотность размещения инженерных коммуникаций и количество единовременно задействованных в строительстве подрядчиков могут быть даже выше, чем в сложных современных заводах.
Хорошо, если генподрядная организация отлично понимает специфику строительства ЦОДа и на собственном опыте может реально оценить сроки работ. Но порой эта задача ставится перед традиционным строительным генподрядчиком, который по незнанию может промахнуться со сроками, как в одну, так и в другую сторону.
Каких правил стоит придерживаться, дабы избежать подобных конфузов?
Уловка № 11. Внесение изменений в документацию
В ходе строительства ЦОДа порой возникает объективная потребность внесения изменений в технические решения, принятые на этапе проектирования. Она может быть вызвана снятием с производства того или иного оборудования, выявлением различных факторов, препятствующих реализации проектных решений, например, обнаружением скрытых строительных дефектов здания или невозможности прокладки трасс коммуникаций по определенным в проектной документации маршрутам.
Все эти изменения могут повлечь за собой существенные трансформации принятых проектных решений и, как следствие, изменение сметной стоимости. Если возможность таких изменений прописана в договоре, то недобросовестный исполнитель не преминет воспользоваться сложившейся ситуацией в своих интересах. Более того, он может сам спровоцировать подобную ситуацию в надежде на получение дополнительного финансирования.
Безусловно, нельзя исключать, что какие-либо работы не были учтены при разработке проектной документации в силу ошибок проектировщиков или неполноты технического задания, но заказчик всегда должен быть начеку при наступлении подобных событий.
Что надо делать во избежание проблем при изменении проектных решений?
Уловка № 12. «Слепое» актирование работ
Акты скрытых работ – это то, о чем часто забывает неискушенный в строительной науке заказчик. Если источники бесперебойного питания или кондиционеры достаточно легко проверить на соответствие проектной и закупочной документации, то ситуация с кабельными трассами, трубопроводами, строительными работами и т.п. намного сложнее. После окончания монтажа не всегда есть возможность увидеть, какие материалы были использованы, и уж тем более оценить качество произведенных работ.
Этим непременно постараются воспользоваться недобросовестные подрядчики-исполнители. И трубопровод заложат не того диаметра либо не из определенного проектом материала, и кабель протянут не медный, а алюминиевый, и трубопроводную фурнитуру закупят не европейскую, а китайскую. А уж как экономично покрасят металлоконструкции не тремя, а одним слоем огнезадерживающей краски или применят бетон не той марки!
Порой подрядчик может и вовсе не выполнить часть таких работ, как проведение электроизмерений, которые вроде не несут явной функциональности, но отнимают время. Он приходит к заказчику и просит «подмахнуть» очередной акт без реальной приемки работ. А через полгода, например, происходит короткое замыкание, и заказчику приходится останавливать ЦОД и добираться, пусть и в рамках гарантии, до злосчастного кабеля, лежащего на самом дне лотка. А если пожар?
Как не допустить возникновения таких ситуаций?
Уловка № 13. Побег от испытаний
На наш взгляд, это одна из самых больших проблем в нынешнем процессе создания ЦОДов. Она несет на себе печать строительного прошлого инженерной инфраструктуры ЦОДа: в нормативе СНиП 3.01.04-87, на который принято ссылаться при обсуждении испытаний, они упоминаются: «предоставить акты испытаний», но и только. Нормативная база для испытаний значительной части инженерных систем практически отсутствует.
Вдобавок к этому полноценные ТЗ на создание ЦОДа, как правило, не разрабатываются (см. уловку № 5), стало быть, нет документа, который определял бы обязанности исполнителя по подготовке и проведению испытаний. Аналогичная ситуация с занесением этих обязанностей в контракт: в большинстве случаев в контракт вносятся работы по монтажу и пусконаладке. Последняя включает в себя индивидуальные испытания, но они прописаны не так четко и не для всех инженерных систем ЦОДа.
Безусловно, в конце концов испытания удается провести даже в самых запущенных проектных случаях, но на принуждение исполнителя к этой работе уходит много сил и нервов. В такой обстановке испытания проводятся «для галочки» и не достигают своей главной цели – проверить реализованные проектные решения.
Какие инструменты можно использовать, чтобы справиться с этой проблемой?
Уловка № 14. Уход от разработки программы и методики испытаний
Одним из элементов уловки № 13 является «перетягивание каната» по подготовке программы и методики испытаний (ПМИ) – документа, определяющего порядок проведения испытаний, условия, ответственность сторон, требования к персоналу, участвующему в испытаниях, требования к материально-техническому и метрологическому обеспечению испытаний.
Первая фаза такого «перетягивания каната» приходится на этап проектирования: проектировщики в категорической форме отказываются от разработки ПМИ. Что, на наш взгляд, в корне неверно. Только разработчик решения – проектная организация – знает, каким именно испытаниям необходимо подвергнуть реализованную систему для того, чтобы проверить ее работоспособность и функционирование во всех режимах.
Одним из истоков этой проблемы является положение дел, описанное в уловке № 6: спекулирование требованиями Постановления № 87 приводит к тому, что от ПМИ проектировщик открещивается.
Каков же выход из этой ситуации?
Безусловно, мы описали далеко не все проблемы, с которыми приходится сталкиваться на практике: жизнь сложнее любой модели. Хотелось бы выделить основные принципы, положенные в основу большинства данных нами рекомендаций:
___________________________________________________________________
* Постановление Правительства РФ от 16.02.2008 № 87 «О составе разделов проектной документации и требованиях к их содержанию».
Источник: журнал ИКС, №3-4 от 21 апреля 2015 года
DataFloor