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

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

ПЕРЕВОД С РУССКОГО НА РУССКИЙ

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

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

Вместе с тем, многочисленные «бизнес-ориентированные» консультанты любят пожонглировать модными (справедливости ради добавим, абсолютно верными) терминами, наподобие «управление жизненным циклом информации» (Information Litecycle Management, ILM), «совокупная стоимость владения» (сразу почему-то оговариваясь, что ее совершенно невозможно подсчитать в условиях российской экономики) и т. п. При этом все они понимают друг друга, и даже иногда «синие воротнички» могут объясниться с «белыми»: «вот в той стойке у нас находится «ситуационный центр обработки данных».

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

  1. «О, эти парни отлично понимают в управлении информацией, даже придумали умную вещь — «жизненный цикл». Однако мой завод выпускает (нужное вписать), а не занимается подготовкой аналитических отчетов или он-лайн контента. Я должен управлять производством и коллективом, противостоять атакам конкурентов, осуществлять контроль за себестоимостью продукции, инвестициями, в конце концов, но не упорядочивать жизненный цикл информации. Пусть все это замечательно работает, но пользы никакой».
  2. «Все это — сговор компаний из отрасли ИТ: чтобы продать что-то ненужное, они ищут тех, кто купит это ненужное. Операторам надо загрузить трафиком их дорогущие каналы связи, производителям ПК продавать новые модели и т. д. А потом как будто «невзначай» обнаружится, что «просто жизненно необходимы принципиально новые» КИС и АСУ ТП. Причем для воплощения их «новых принципов» потребуется тотальный реинжиниринг бизнеса. Зачем все эти «модные решения и технологии с переднего края», если и работа по старинке приносит прибыль?»

Как ни печально, в обоих случаях решение одинаково: чтобы ноги их здесь больше не было, если кто-то еще в моем присутствии произнесет «ILM», пусть пеняет на себя.

Читатель улыбнется, однако подобный исход — скорее правило, нежели исключение. Ведь причина краха «дот-комов» и философии «новой экономики» — не что иное, как следствие необоснованных попыток внедрить технологии (от социально-экономических до парадигм «мобильных работников» и «повсеместного проникновения Сети») без учета реального контекста (состояния экономики, требований бизнеса, менталитета и многого другого). Да разве мало история последних 10—15 лет знает примеров, когда огромные усилия были затрачены на продвижение невостребованных (либо здесь и сейчас, либо вообще) решений? Вспомним, к примеру, «АТМ до рабочего стола», «тонкий клиент — единственный выбор». Ну а пресловутая «проблема 2000 года» — это просто хит всех времен и народов!

Тем обиднее наступать на те же грабли в области систем/сетей хранения (или, если угодно, ILM — пусть этот термин не пугает, его содержание наполнено реальным смыслом), ведь появление соответствующих решений вызвано конкретными задачами реального бизнеса, причем потребность в них возникла более десятка лет назад. Как только обработка цифровой информации превратилась в один из основных бизнес-процессов любой крупной организации, многие поняли, «что нужно делать», однако до поры до времени осуществить задуманное с помощью имеющихся технологий и программно-аппаратных средств не представлялось возможным.

Нередко консультанты по-прежнему ограничиваются лишь показательными, но далекими от российской действительности историями о потере архивов Enron и коллапсе «башен-близнецов» вместо того, чтобы перевести обсуждение в область практических задач и продемонстрировать варианты их решения. К чему все это говорится? Да к тому, что ценность как технического специалиста, так и бизнес-консультанта вовсе не в умении обрушить на собеседника водопад «сокровенных знаний с передовых рубежей», а в способности объяснить полезность предлагаемого — без априорной убежденности в том, что «это просто необходимо всем и каждому», но с желанием найти общий язык и наладить диалог с владельцем бизнеса или топ-менеджером. Не «показывать на пальцах», упрощать и т. п., а учитывать, что внимание заказчика приковано к его собственным задачам и проблемам, что «нужды отрасли ИТ» ему в целом далеки. Взаимопониманию будут способствовать отнюдь не тезисы о «предложениях от мирового лидера» или о «безграничных перспективах в эпоху глобализации», а стремление помочь именно его компании. Для этого сложные вещи надо уметь объяснить очень коротко и на языке, доступном неспециалисту, фокусируясь на конкретике, на собственном опыте, на гарантиях реального успеха. Положительный опыт «коллег по цеху» будет гораздо более действенным аргументом, чем «качественный скачок во всех сферах бизнеса» ведущих компаний той или иной отрасли (а их на весь мир, как ни странно, всего двое — Other Inc. да ACME Corp.).

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

ПРОДАТЬ ВСЕ, ЧТО УГОДНО, МОЖНО ТОЛЬКО РАЗ

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

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

Все это отнюдь не выдуманные, а вполне реальные случаи, свидетелем которых приходилось быть не раз и не два, причем всякий раз консультант обладал весьма обширными знаниями, посещал тренинги по коммуникациям, а заказчик в целом был положительно настроен на выявление собственных проблем и их решение. Результат же оказывался хуже некуда. Почему? На мой взгляд, из-за излишней веры в стереотипы и априорного мнения о превосходстве собственных знаний, на основании чего делается неоправданное заключение, что все предложения будут с интересом выслушаны. С какой стати? C каждым закрытым вопросом «эксперта» у заказчика лишь крепнет ощущение, что собеседник не в курсе его задач, и, скорее всего, ему ни разу не приходилось выполнять проект в подобных условиях, а про конкурентов он знает только понаслышке.

Читатель может возразить, что тогда и остальные решения ИТ должны натыкаться на подобные препятствия и почти не продаваться, но на практике все обстоит гораздо лучше. Несомненно, в действительности все не так плохо. Однако оглянемся лет на 10—12 назад: продажа сервера для установки в локальной сети была большой творческой удачей для любой компании из десятки наиболее крупных представителей «первой волны» российского ИТ-бизнеса. Впоследствии схожая история повторялась со всеми новыми решениями, для осознания нужности которых обеим сторонам необходимо было забыть о мегабайтах, мегабитах в секунду, «килодолларах» и посмотреть на реальную задачу «как есть». Те, кто первым научился это делать, и сейчас среди лидеров...

А теперь поинтересуемся любым из проектов в области ИТ, который затрагивает критичные бизнес-процессы (когда его неудачная реализация может привести к упадку основного бизнеса компании-заказчика), например внедрение АСУ ТП, систем ERP и CRM. Ситуация очень похожая — тем, кто умеет вникнуть в конкретику заказчика, вместе с ним разобраться в причинах проблем, на равных обсудить реалистичность результатов, успех обеспечен. Тех же, кто приходит с гипертрофированной верой в собственную значимость, начинает поучать, самонадеянно решая, что нужно предприятию, очень часто ждет серьезное разочарование в виде перераспределения бюджета в пользу того исполнителя, который не чурается брать уроки у заказчика и развиваться вместе с заказчиком.

На самом деле рецепт успеха в первую очередь в правильном понимании и применении идеологии ILM, и уже потом — в адаптации используемого ею набора технологий и решений. Так, в России нечасто возникает необходимость оперативного доступа к массивам данных объемом свыше 1 Тбайт, но, с другой стороны, сплошь и рядом, даже средним и небольшим компаниям требуется высокая скорость обработки запросов OLAP к относительно компактным множествам данных, и/или резервное копирование без блокировок записей, и/или отладка новых модулей в «условиях, максимально приближенных к рабочим».

Нередко «бумажных» специалистов ставят в тупик конкретные вопросы заказчика: «Насколько быстрее будет работать моя КИС, когда вы внедрите предлагаемую инфраструктуру?»; «Что важнее для моего бизнеса — доступность или скорость восстановления после сбоя, одна большая суперсистема или распределенная сеть?»; «Решение каких задач, которые я не смогу выполнить без предлагаемого вами продукта, даст мне преимущества в повседневной работе?» В какой ситуации нужно уметь вернуться к описанию задачи, но избежать соблазна прибегнуть к общим фразам, наподобие «ваш сервер никогда не справится с вводом/выводом от предлагаемого массива», «ваши сотрудники при всем желании не смогут загрузить систему», «все узкие места могут быть только за пределами создаваемой инфраструктуры», или ссылкам на то, что никто до сих пор не жаловался, и поэтому причин сомневаться нет. В ответ на такие штампы последует вполне резонное предложение ограничиться более дешевым и простым решением, например установкой множества дисков ATA (ведь по емкости они в два-три раза вместительнее дорогостоящих дисков FC) или использованием имеющейся высокоскоростной отказоустойчивой локальной сети для организации выделенных подключений серверов вместо организации SAN, поскольку «осязаемых» аргументов в пользу более дорогих решений, за исключением абстрактной и непонятной «интеграции приложений с сетью хранения данных», приведено не было. И возразить эксперту окажется нечем, ведь он же сам сказал, что заметить разницу трудно.

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

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

ИЗ ЧЕГО ЖЕ, ИЗ ЧЕГО ЖЕ, ИЗ ЧЕГО ЖЕ СДЕЛАНЫ НАШИ СИСТЕМЫ?

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

«Узкий специалист подобен флюсу» — все знают эту поговорку, но не каждый способен быть достаточно честным, чтобы сделать выводы... Конечно, нельзя не учитывать, что в России традиционно под словом «решение» подразумевается в первую очередь оборудование, а программное обеспечение рассматривают как весьма накладное дополнение. В результате в большинстве случаев объяснения концепции ILM идут от системы хранения как ядра системы, но дальше не продвигаются, а потому хранилище данных превращается в панацею от всех проблем, порой даже в самоцель проекта: «Если у вас будет сеть хранения, то все ваши проблемы исчезнут сами собой, ведь это — сотни дисков, мощные процессоры и специализированные микросхемы, гигабайты кэш-памяти!» В ответ же на вопросы заказчика, — а на этом этапе в беседу, как правило, вступает его директор по ИТ, — интересующегося, насколько вырастет производительность КИС, как можно оценить надежность, какой участок считается наиболее отказоустойчивым и где возникает новое «узкое место», консультант часто просит дать ему время подумать (спрашивается, что он делал раньше?).

Вот только заказчик тратит время на обсуждение проекта и поиск источников инвестиций отнюдь не ради того, чтобы консультант придумал нечто. Он рассматривает решение с точки зрения бизнеса, а не «продвижения пионерских технологий» и совершенно справедливо хочет понять все плюсы и минусы проекта, оценить риски, поскольку ему важно, что из «унаследованного» (но еще вполне работоспособного) ПО придется заменять и какова ориентировочная стоимость нового, сколько потребуется специалистов для эксплуатации предлагаемого «самосогласованного» решения, не будет ли при этом его бизнес зависеть от воли или настроения кого-то из его администраторов, не понадобится ли по несколько раз в месяц оплачивать визиты эксперта для выполнения «профилактических работ» и «внесения незначительных изменений в настройки». А если вслед за «экономическим блоком» директор по ИТ спросит о наличии опыта по настройке СУБД (почтовой системы и т. д., нужное вписать) в целях обеспечения оптимального взаимодействия с системой хранения и о возникающих при этом сложностях и способах их устранения, то иные высоколобые поборники ILM воспринимают подобное как удар ниже пояса.

Случается, что, используя недостаточную осведомленность клиента, сам эксперт прибегает к такому маркетинговому приему, как дезинформация, которая на сленге именуется FUD, — именно так можно трактовать «философию ILM», выражаемую в целевой установке: «Вы даже не представляете, что происходит с вашей информацией! Как она портится, теряется, становится неуправляемой». Однако на риторический вопрос «А вы знаете, чем Настоящая сеть хранения отличается от Вашей сети?» следует не безропотное ожидаемое согласие, что «да, несомненно, сеть хранения во всем лучше», а высказывается желание послушать сравнение двух инфраструктур, к чему эксперт оказывается не готов, сбиваясь на маркетингово-технологические уловки.

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

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

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

Эксперт потому и эксперт, а не просто «знающий специалист», что он умеет выбрать наилучшее из возможного, не боится нести ответственность за рекомендованное заказчику решение и не пытается продвинуть только то, что хорошо изучено им самим. С другой стороны, интересам заказчика отнюдь не соответствует «всеядный» подход, при котором демонстрируются внушительные таблицы с названиями продуктов, аппаратными и программными опциями, сопровождаемые комментарием: «из предлагаемых модулей можно собрать подходящее решение, причем несколькими способами — выбор за вами». И как прикажете заказчику или его менеджеру по ИТ выбирать? По правой колонке? Руководствуясь принципами «я что-то об этом слышал» или «у моих друзей такое уже есть»? Либо предложить его сотрудникам пройти обучение и быть готовыми самостоятельно определиться с решением?

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

Несмотря на высокие, на первый взгляд противоречивые, требования к сотруднику, претендующему на роль эксперта, в российском ИТ-бизнесе подобные специалисты есть, и с течением времени их становится все больше. Если компания намеревается предложить именно решение, а не просто продать как можно больше, то ей необходимо воспитывать настоящих экспертов, сочетающих глубину знаний с широтой охвата, умением договариваться с собеседником и способностью к достижению цели. Да, в его подготовку необходимо вложить немалые средства и еще больше времени, но другого пути нет: попытки «сколачивать» рабочие группы из инженеров по системам и сетям хранения и деловому программному обеспечению все равно окажутся бесплодными без участия в процессе главного инженера проекта, сочетающего в себе вышеописанные качества. Причем речь идет не только об умении управлять проектом, но и о способности к лидерству — ведь многое приходится осуществлять впервые, и кто-то должен взять на себя ответственность за выбор. Когда заказчик видит, что ему предстоит быть первопроходцем в использовании ILM на своем вертикальном рынке или в регионе, то уверенность эксперта передается и ему, и тогда желание вырваться вперед в конкурентной борьбе перевешивает опасения по поводу ошибок.

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

ВОПРОС ЦЕНЫ И ЦЕНА ВОПРОСА

Еще одной особенностью сложных проектов в области ILM является необходимость уже на этапе эскизного проектирования оптимизировать проект с точки зрения стоимости. Типичные варианты выбора между встроенной в ОС или коммерческой файловой системой, способами организации кластера, тиражированием и созданием клонов средствами массива или с помощью инфраструктурного ПО, немедленной активизацией функциональности массива и установкой как можно большего числа дисков, платформами управления, местом использования iSCSI на СХД или на коммутаторе и многим другим — сами по себе могут изменить стоимость проекта на десятки процентов, а иногда и в десятки раз, что уж говорить о кумулятивном эффекте, когда хотя бы часть вариантов неоптимальна. Например, определенные функции системы хранения лицензируются по числу подключаемых хостов, некоторые — по числу установленных дисков, взаимодействующие же с ними модули СУБД — по количеству процессоров на серверах и т. п.

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

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

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

ВМЕСТО ЭПИЛОГА

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

Руслан Чиняков — технический директор компании OCS. На протяжении последних 10 лет специализируется в области экспертизы, проектирования и развития проектных решений современных мультисервисных сетей и систем хранения данных. С ним можно связаться по адресу: rchiniakov@ocs.ru.