Rambler's Top100
 
 
Статьи ИКС № 10 2012
Андрей ПАВЛОВ  Дмитрий БАСИСТЫЙ  Дмитрий КУСАКИН  16 октября 2012

Управление проектом создания ЦОДа: из российской практики

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

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

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

Инициация проекта, формирование и изменение проектной организации

Как правило, решение о необходимости создания ЦОДа принимается руководством компании по инициативе подразделения ИТ. Именно ИТ-служба формирует первоначальные требования к создаваемому объекту, а значит, по логике рассуждения, является заказчиком.

ИТ-служба начинает формировать техническое задание, искать потенциальных подрядчиков, обсуждать сроки и возможные инженерные решения, оставляя за кадром вопрос формирования проектной организации за пределами своего подразделения. На этом этапе ясно, что ИТ-директор (CIO) выступает как спонсор проекта и только он заинтересован в его завершении, это показатель эффективности его работы, его KPI. ИТ-директор формирует проектную команду из экспертов своего подразделения, назначает руководителя проекта, делегирует ему основные функции управления.

А дальше наступает момент, когда необходимо формировать пошаговый план достижения результата: разработка дизайна всего процесса создания ЦОДа, процедуры отбора подрядчиков, формирование ядра исполнителей и их финансирования, оценка сроков и бюджета, понимание критериев достижения результата. Наличие офиса управления проектами в структуре организации, безусловно, формирует общую культуру управления проектами и переносит отношения в область утвержденных процессов. Но именно на этом этапе возникает вопрос: а кто за все это будет платить? Как правило, ответ следующий: ЦОД – объект капитального строительства, следовательно, его бюджет – это бюджет подразделения капитального строительства (или материально-технического обеспечения, или какого-то еще), но не подразделения ИТ! В российских условиях это означает только одно – ИТ-служба перестает быть заказчиком. Она становится потребителем услуги, потребителем результатов строительства ЦОДа. Собственно ЦОД для нее будет строить другое подразделение, у которого есть свои правила и подходы к решению задачи.

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

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

Отметим, что в идеале мы хотим видеть в организационной структуре проекта такие уровни:

  • уровень спонсоров проекта (управляющего комитета);
  • уровень оперативного управления проектом (руководителя проекта);
  • уровень управления рабочими группами (инженерных консультантов и руководителей группы);
  • группу управления качеством и аудита.

Первые проектные документы, согласование и утверждение

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

Итак, документирование является основополагающим понятием и принципом. Необходимо не просто разослать на согласование и получить «ОК» по электронной почте от участников проекта, а лично и письменно согласовать с членами проектной организации и утвердить у руководства основные проектные документы. К ним относятся:

  • приказ о создании проектной организации и назначении руководителя проекта;
  • устав проекта;
  • дизайн проекта – подход к его реализации;
  • ТЭО/бизнес-план/финансовая оценка/обоснование необходимости создания;
  • отчет о предпроектном обследовании;
  • техническое задание на создание комплекса ЦОДа;
  • процедура проведения конкурса и отбора подрядчиков.

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

 
 
Дизайн проекта или определение подхода к реализации

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

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

Рассмотрим два плана работ: первый – проектирование, затем строительство; второй – проектирование и строительство одновременно. Как видно из рис. 1, сроки окончания работ по обоим вариантам практически совпадают. Однако риски во втором варианте гораздо выше.

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

Заказчик имеет прямые контракты с двумя компаниями, выбранными на конкурсной основе: консультант/генеральный проектировщик и генеральный подрядчик. В зону ответственности консультанта входят подготовка технического задания, разработка и согласование комплекта проектной документации (соответствующей уровню готовности 30–60–85% в терминах Uptime Institute, или стадиям «Эскизный проект» и «Проект»*), сопровождение стадии «Рабочий проект», экспертный надзор за строительством, разработка методики и участие в приемосдаточных испытаниях, а также консультирование заказчика на этапе опытной эксплуатации систем ЦОДа.

Генеральный подрядчик отвечает за создание комплекта «Рабочая документация», по которому выполняются строительно-монтажные работы, и он же собственно выполняет эти работы, проводит приемосдаточные испытания в соответствии с разработанными консультантом программой и методикой и организует передачу объекта в эксплуатацию.

Таким образом, достигаются взаимный контроль решений и согласование документации между генеральным проектировщиком/консультантом и генеральным подрядчиком. На каждом этапе проектирования финансовая оценка уточняется, и погрешность ее может быть сведена от значения ±50% на стадии концептуального (эскизного) проекта до ±10% на стадии «Проект».

Проектирование и сертификация проекта в Uptime Institute

Начиная планирование процесса проектирования, необходимо иметь в виду, что документацию придется выполнять как минимум на двух языках – русском и английском. Русский вариант вам понадобится для российских согласующих и надзорных органов и заказчика, а английская версия – для согласования и сертификации проекта в Uptime Institute. Прекрасно, если вам удалось выбрать подрядчика, способного вести проектирование на двух языках одновременно. Инженерный персонал российских компаний не всегда владеет английским языком, и для подготовки английского комплекта обычно приходится привлекать специализированное переводческое агентство. После перевода документация нуждается в серьезной вычитке. Все это занимает время и не способствует соблюдению сроков создания ЦОДа. Обычно перевод комплекта документации на стадии «Проект» занимает от полутора до двух месяцев. Если же вы выпускаете несколько версий проектной документации, вносите в нее изменения, проводите их согласование, а затем переводите снова и снова, то процесс может затянуться.

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

Приемосдаточные испытания и ввод в эксплуатацию

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

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

1. Испытания компонентов систем на заводе-изготовителе с целью подтвердить соответствие заданных характеристик компонентов системы техническим требованиям к отдельным узлам или блокам системы. Результат: протоколы испытаний завода-изготовителя, сертификаты соответствия.

2. Испытания отдельной системы после сборки на месте инсталляции с целью подтвердить соответствие заданных характеристик системы в целом техническим требованиям на систему. Результат: протоколы испытаний оборудования компанией, проводящей инсталляцию системы.

3. Испытания отдельной системы в различных режимах эксплуатации (зима-лето, непрерывная работа на полной нагрузке, сбои в питающей сети, переходные процессы при разных нагрузках и т.д.) в соответствии с методикой проведения автономных предварительных испытаний. Результат: протоколы испытаний системы приемочной комиссией.

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

5. Опытная эксплуатация комплекса ЦОДа в соответствии со специально разработанной программой. Результат: акт о завершении опытной эксплуатации с выводом о готовности комплекса ЦОДа к приемочным и сертификационным испытаниям.

6. Испытания комплекса ЦОДа с целью прохождения сертификации в Uptime Institute по уровню надежности. Результат: подтверждение со стороны Uptime Institute соответствия реализованных решений требованиям заданного уровня надежности, получение сертификационного письма и отличительного сертификационного знака.

Проведение испытаний типов 1 и 2 обеспечивается силами компаний – изготовителей отдельных компонентов и систем. Сдача-приемка отдельных систем происходит по собственным методикам этих компаний с участием генерального подрядчика, надзорных органов и представителей заказчика.

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

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

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

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

______________________________________________________
* Точного соответствия между этапностью процесса в проектной документации Uptime Institute и российскими стадиями проектирования нет. Можно с некоторыми допущениями сказать, что 30% примерно соответствует стадии «Эскизный проект», 60% – это «проработанный» эскизный проект, 85% соответствует стадии «Проект», а 100% – это рабочая документация, стадия «Рабочий проект».

 
Поделиться:
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!