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

На стадии выработки стратегии

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

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

Несомненно, будет полезна разработка организационной модели с расписанными ролями и ответственностями для новой утвержденной команды проекта.

И подчеркнем: все эти вопросы необходимо решить до старта проекта, а не тогда, когда проект запущен и набирает обороты.

Ближе к проектной документации

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

Следующий важный этап — проведение предпроектного обследования, финалом и документальным результатом которого должен стать отчет о предпроектном обследовании (ППО). Этот отчет должен в сжатом виде собрать всю исходную информацию, собранную в ходе обследования и необходимую для двух последующих этапов — разработки техниче­ского задания и проектирования Среди важных частей отчета о предпроектном обследовании можно назвать:

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

Вся эта информация будет опорной и исходной для будущего проектировщика. Именно отчет о ППО и техническое задание — фундаментальная основа для дальнейшей успешной реализации проекта.

При создании технического задания мы рекомендуем придерживаться рекомендаций «ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».

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

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

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

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

  • отчет о предпроектном обследовании (источник исходных данных и исходных требований);
  • техническое здание на создание ЦОД (источник требований к техническому решению и составу и организации работ).

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

Значение третьей стороны

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

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

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

Поэтому для такого сложного и ответственного проекта, как создание корпоративного ЦОД международного уровня, желательно применить трехстороннюю модель построения проектной команды:

  • команда специалистов клиента;
  • команда специалистов исполнителя;
  • команда экспертной организации.

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

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

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

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

Проектировать, избегая крайностей

Игорь Сюртуков,
заместитель технического директора компании «Verysell Проекты»

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

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

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

Следует предостеречь от другой крайности — формирования технического задания таким образом, чтобы оборудование только определенных производителей удовлетворяло его требованиям. Даже если такой подход оправдан по каким‑либо причинам, для заказчика всегда существует риск излишних финансовых затрат. Ведь, как известно, только конкуренция играет на руку покупателю (чего не происходит, если круг производителей ограничен).

Необходим комплексный подход к вопросу выбора вендоров. С одной стороны, не следует ограничивать выбор одной-двумя компаниями, с другой — сформированные требования к оборудованию или работам должны четко описывать качество и технические характеристики соответствующих продуктов (услуг).