«Журнал сетевых решений/LAN» , № 07, 2005 94 прочтения
Руководство по укладке парашюта
Многие проблемы начинают проявляться, как правило, на территории конечного заказчика, и ответственность за их предвидение и умение разобраться с первопричинами несут в значительной мере вендоры, дистрибьюторы и системные интеграторы.
Многие проблемы начинают проявляться, как правило, на территории конечного заказчика, и ответственность за их предвидение и умение разобраться с первопричинами несут в значительной мере вендоры, дистрибьюторы и системные интеграторы. Обсуждению некоторых проблем реального бизнеса и рецептам их преодоления и посвящена данная статья.
Решения на базе сетей хранения, с одной стороны, отвечают реальным задачам широкого круга корпоративных заказчиков, а с другой — соответствующие технологии достигли требуемой степени зрелости как в отношении надежности и совместимости, так и в понимании путей их дальнейшего развития. Однако темпы и масштабы внедрений проектов с использованием сетей хранения могут и должны быть значительно бо?льшими, а для этого необходимо научиться справляться с рядом трудностей, большинство из которых отнюдь не связано с ограничениями технологий, устройств, продуктов и, как ни странно, даже бюджетов, а лежат в области подготовки и сопровождения подобных проектов.
ПЕРЕВОД С РУССКОГО НА РУССКИЙ
Как свидетельствует опыт общения с заказчиками и представителями вендоров, реализация проектов тормозится из-за нарушений коммуникаций как минимум в двух областях. Представители ИТ-сообщества, как вендоры, так и партнеры в канале, общаются между собой на «диалекте» либо специалистов по технологиям, либо «продвинутых» бизнес-консультантов — а ведь ни тот, ни другой заказчик не воспринимает, он занят насущными вопросами жизнедеятельности конкретного предприятия, перспективами его развития, озабочен специфическими трудностями — видимыми/понимаемыми или только косвенно ощущаемыми.
Конечно, любой специалист согласится с тем, что критичные для бизнеса задачи не могут иметь «простых, тривиальных, само собой разумеющихся» решений и требуют подробного анализа вариантов, изучения применимости тех или иных технологий: как говорится, «мелочи определяют совершенство, а совершенство — уже не мелочь». И при описании решения невозможно не использовать понятий из области технологий ИТ.
Вместе с тем, многочисленные «бизнес-ориентированные» консультанты любят пожонглировать модными (справедливости ради добавим, абсолютно верными) терминами, наподобие «управление жизненным циклом информации» (Information Litecycle Management, ILM), «совокупная стоимость владения» (сразу почему-то оговариваясь, что ее совершенно невозможно подсчитать в условиях российской экономики) и т. п. При этом все они понимают друг друга, и даже иногда «синие воротнички» могут объясниться с «белыми»: «вот в той стойке у нас находится «ситуационный центр обработки данных».
В каждой шутке есть доля шутки, но давайте попробуем встать на позицию владельца бизнеса из «реального сектора экономики» (ну что за чудо эти термины — дают работу сотням людей самых разных профессий). Например, компания добывает нефть, газ или руду либо варит сталь, выпускает самолеты, автомобили. Что же услышит акционер или генеральный директор (о директорах по ИТ речь пойдет ниже), когда ему говорят об ILM как о методе управления рисками основных бизнес-процессов? Скорее всего, он сделает для себя одно из двух заключений.
- «О, эти парни отлично понимают в управлении информацией, даже придумали умную вещь — «жизненный цикл». Однако мой завод выпускает (нужное вписать), а не занимается подготовкой аналитических отчетов или он-лайн контента. Я должен управлять производством и коллективом, противостоять атакам конкурентов, осуществлять контроль за себестоимостью продукции, инвестициями, в конце концов, но не упорядочивать жизненный цикл информации. Пусть все это замечательно работает, но пользы никакой».
- «Все это — сговор компаний из отрасли ИТ: чтобы продать что-то ненужное, они ищут тех, кто купит это ненужное. Операторам надо загрузить трафиком их дорогущие каналы связи, производителям ПК продавать новые модели и т. д. А потом как будто «невзначай» обнаружится, что «просто жизненно необходимы принципиально новые» КИС и АСУ ТП. Причем для воплощения их «новых принципов» потребуется тотальный реинжиниринг бизнеса. Зачем все эти «модные решения и технологии с переднего края», если и работа по старинке приносит прибыль?»
Как ни печально, в обоих случаях решение одинаково: чтобы ноги их здесь больше не было, если кто-то еще в моем присутствии произнесет «ILM», пусть пеняет на себя.
Читатель улыбнется, однако подобный исход — скорее правило, нежели исключение. Ведь причина краха «дот-комов» и философии «новой экономики» — не что иное, как следствие необоснованных попыток внедрить технологии (от социально-экономических до парадигм «мобильных работников» и «повсеместного проникновения Сети») без учета реального контекста (состояния экономики, требований бизнеса, менталитета и многого другого). Да разве мало история последних 10—15 лет знает примеров, когда огромные усилия были затрачены на продвижение невостребованных (либо здесь и сейчас, либо вообще) решений? Вспомним, к примеру, «АТМ до рабочего стола», «тонкий клиент — единственный выбор». Ну а пресловутая «проблема 2000 года» — это просто хит всех времен и народов!
Тем обиднее наступать на те же грабли в области систем/сетей хранения (или, если угодно, ILM — пусть этот термин не пугает, его содержание наполнено реальным смыслом), ведь появление соответствующих решений вызвано конкретными задачами реального бизнеса, причем потребность в них возникла более десятка лет назад. Как только обработка цифровой информации превратилась в один из основных бизнес-процессов любой крупной организации, многие поняли, «что нужно делать», однако до поры до времени осуществить задуманное с помощью имеющихся технологий и программно-аппаратных средств не представлялось возможным.
Нередко консультанты по-прежнему ограничиваются лишь показательными, но далекими от российской действительности историями о потере архивов Enron и коллапсе «башен-близнецов» вместо того, чтобы перевести обсуждение в область практических задач и продемонстрировать варианты их решения. К чему все это говорится? Да к тому, что ценность как технического специалиста, так и бизнес-консультанта вовсе не в умении обрушить на собеседника водопад «сокровенных знаний с передовых рубежей», а в способности объяснить полезность предлагаемого — без априорной убежденности в том, что «это просто необходимо всем и каждому», но с желанием найти общий язык и наладить диалог с владельцем бизнеса или топ-менеджером. Не «показывать на пальцах», упрощать и т. п., а учитывать, что внимание заказчика приковано к его собственным задачам и проблемам, что «нужды отрасли ИТ» ему в целом далеки. Взаимопониманию будут способствовать отнюдь не тезисы о «предложениях от мирового лидера» или о «безграничных перспективах в эпоху глобализации», а стремление помочь именно его компании. Для этого сложные вещи надо уметь объяснить очень коротко и на языке, доступном неспециалисту, фокусируясь на конкретике, на собственном опыте, на гарантиях реального успеха. Положительный опыт «коллег по цеху» будет гораздо более действенным аргументом, чем «качественный скачок во всех сферах бизнеса» ведущих компаний той или иной отрасли (а их на весь мир, как ни странно, всего двое — Other Inc. да ACME Corp.).
Такой подход действительно работает (можете поверить, но еще лучше — проверить), но для этого необходимо осознать, что, общаясь с потенциальными заказчиками, ты уже не вещаешь со стенда выставки или трибуны конференции, а выступаешь в роли советчика и помощника. Свои возможности необходимо соотносить с предлагаемыми вариантами, чувствовать ответственность за сказанное, стараться узнать мнение собеседника. Результат оказывается просто поразительным: вместо очередного недвусмысленного взгляда на часы, он вдруг просит секретаря ни с кем не соединять, отменить все визиты, вызвать замов и начинает рассказывать о своих головных болях и реальных желаниях... Но это — только начало пути, фарватер которого усеян подводными камнями — впрочем, обо всем по порядку...
ПРОДАТЬ ВСЕ, ЧТО УГОДНО, МОЖНО ТОЛЬКО РАЗ
Поняв, как разговаривать с заказчиком, нужно быстро оценить, о чем конкретно надо вести речь. Нередко высококвалифицированные специалисты, знающие до тонкостей не только специфику работы оборудования или ПО, но и реальные преимущества решений с использованием сетей хранения, оказываются зажаты в рамках рекомендаций, рассчитанных на абстрактного заказчика. Стоит нити разговора уйти чуть в сторону, свернув на тему, для которой домашние заготовки отсутствуют, как в голосе консультанта исчезают уверенность и бодрость, а беседа зацикливается на этапе «схода с рельс». В результате разговор заканчивается в лучшем случае ничем, в худшем — отказом от дальнейшего общения на данную тему.
Зная, что «нужно выявить реальную задачу заказчика», эксперт зачастую не имеет понятия, как это сделать. Не прибегая к маркетинговым лозунгам и заранее подготовленным предложениям (кстати, напрасно, поскольку рояль в кустах никому не мешал, только хорошо бы еще уметь играть на нем), он строит диалог по тупиковой схеме, задавая с наигранным участием стандартные вопросы о случаях потери данных, исчерпании дискового пространства на сервере, копировании информации на резервную площадку и т. п. Когда же выясняется, что потеря данных не нанесла серьезного ущерба бизнесу, что проблема исчерпания ресурсов решается доустановкой дисков без всякой виртуализации, что ленты с резервными копиями просто хранятся на другой площадке, он не находит что сказать, так что остается сделать хорошую мину при плохой игре, предложив заказчику помощь, когда она все-таки понадобится (так и не поняв, чем ему можно было помочь уже сейчас).
Все это отнюдь не выдуманные, а вполне реальные случаи, свидетелем которых приходилось быть не раз и не два, причем всякий раз консультант обладал весьма обширными знаниями, посещал тренинги по коммуникациям, а заказчик в целом был положительно настроен на выявление собственных проблем и их решение. Результат же оказывался хуже некуда. Почему? На мой взгляд, из-за излишней веры в стереотипы и априорного мнения о превосходстве собственных знаний, на основании чего делается неоправданное заключение, что все предложения будут с интересом выслушаны. С какой стати? C каждым закрытым вопросом «эксперта» у заказчика лишь крепнет ощущение, что собеседник не в курсе его задач, и, скорее всего, ему ни разу не приходилось выполнять проект в подобных условиях, а про конкурентов он знает только понаслышке.
Читатель может (да и должен) возразить, что я намеренно сгущаю краски, но ведь тема обсуждения — проблемы взаимопонимания. Не было бы их, не было бы и статьи.
Несмотря на высокие, на первый взгляд противоречивые, требования к сотруднику, претендующему на роль эксперта, в российском ИТ-бизнесе подобные специалисты есть, и с течением времени их становится все больше. Если компания намеревается предложить именно решение, а не просто продать как можно больше, то ей необходимо воспитывать настоящих экспертов, сочетающих глубину знаний с широтой охвата, умением договариваться с собеседником и способностью к достижению цели. Да, в его подготовку необходимо вложить немалые средства и еще больше времени, но другого пути нет: попытки «сколачивать» рабочие группы из инженеров по системам и сетям хранения и деловому программному обеспечению все равно окажутся бесплодными без участия в процессе главного инженера проекта, сочетающего в себе вышеописанные качества. Причем речь идет не только об умении управлять проектом, но и о способности к лидерству — ведь многое приходится осуществлять впервые, и кто-то должен взять на себя ответственность за выбор. Когда заказчик видит, что ему предстоит быть первопроходцем в использовании ILM на своем вертикальном рынке или в регионе, то уверенность эксперта передается и ему, и тогда желание вырваться вперед в конкурентной борьбе перевешивает опасения по поводу ошибок.
Опыт в работе с партнерами показывает: системный подход важен во всем — как развивать подобные проекты, готовить специалистов, предоставлять помощь или сервис и т. п. Самое пристальное внимание нужно уделять сотрудникам, их умению рассматривать проект с позиции заказчика, заранее выделять проблемы, открыто обсуждать ограничения любого из вариантов, быть мотивированными на успешность компании через успех ее клиентов. Просто отправить людей на курсы — верный способ выбросить деньги на ветер, если заранее не определить, как полученные знания будут использоваться в реальной работе. Надежды на то, что стоит лишь начать, а дальше маховик спроса раскрутит рынок, опасны: первые ошибки в силу размера и критичности проектов способны заморозить этот самый спрос на длительное время.
ВОПРОС ЦЕНЫ И ЦЕНА ВОПРОСА
Еще одной особенностью сложных проектов в области ILM является необходимость уже на этапе эскизного проектирования оптимизировать проект с точки зрения стоимости. Типичные варианты выбора между встроенной в ОС или коммерческой файловой системой, способами организации кластера, тиражированием и созданием клонов средствами массива или с помощью инфраструктурного ПО, немедленной активизацией функциональности массива и установкой как можно большего числа дисков, платформами управления, местом использования iSCSI на СХД или на коммутаторе и многим другим — сами по себе могут изменить стоимость проекта на десятки процентов, а иногда и в десятки раз, что уж говорить о кумулятивном эффекте, когда хотя бы часть вариантов неоптимальна. Например, определенные функции системы хранения лицензируются по числу подключаемых хостов, некоторые — по числу установленных дисков, взаимодействующие же с ними модули СУБД — по количеству процессоров на серверах и т. п.
Не следует уповать на то, что, подготовив эскизный проект и оценив его стоимость, можно будет изменить ее в меньшую сторону с помощью незначительных количественных изменений в составе проекта. Если это и удается, то чрезвычайно редко, поскольку проект подобен зданию, где нагрузка сложным образом распределена между элементами конструкции: чтобы вынуть несколько кирпичей, понадобится перестроить все здание. Повторяющиеся попытки изменить эскизный проект приведут к тому, что оптимальное по стоимости решение превратится в далеко не лучшее по времени, затраченному на его разработку. К тому же нужно учесть косвенные затраты на эксплуатацию системы — как инвестиции заказчика в обучение персонала, так и затраты самого исполнителя на гарантийную и постгарантийную поддержку системы, договорившись, куда важнее вложить средства: в повышение доступности системы как целого или в подробное изучение процесса изменения ценности информации с целью минимизации числа участков, где требуется использование отказоустойчивых конфигураций.
Будем откровенны, при всех разговорах об открытых стандартах, совместимости и взаимозаменяемости, системы и сети хранения основаны на наборах фирменных закрытых протоколов, применение которых, впрочем, оправдывается богатой функциональностью, надежностью и возможностью заранее спрогнозировать производительность. Однако заказчик должен понимать, что ему (и, что важнее, его основным бизнес-процессам) придется длительное время «жить» в той среде обитания, фундамент которой был заложен в исходном проекте, и не все недочеты можно будет исправить с помощью модернизации. В таком случае адекватным решением для управления рисками будет вложение средств (причем всеми участниками, начиная с вендора) в пилотный проект с целью выявления всех проблемных зон — это окупится сторицей во время «боевой» эксплуатации полноценного проекта.
Отсюда вытекает еще одно нетипичное для «обычных» проектов в области ИТ требование к эксперту — способность досконально разбираться в схеме ценообразования применяемых продуктов и решений, умение обсуждать с заказчиком различные варианты управления стоимостью проекта и рисками, что отнюдь не сводится к заучиванию структуры прайс-листов, а предполагает изучение и использование соответствующей методологии управления проектами. Можно сказать, круг замкнулся: проект имеет цену, но и цена во многом определяет проект. Тем не менее в итоге мы получим не парадокс и тупик, а сбалансированное решение, ведь интересен не сам факт его существования, но способы достижения результата.
ВМЕСТО ЭПИЛОГА
Корень проблем при внедрении проектов ILM вовсе не в технологиях и устройствах, не в превосходстве одних вендоров и недостатках других, а в отсутствии системного подхода, в желании пойти в инновационных решениях проторенной дорожкой, которой на самом деле нет, в стремлении решать задачи «в порядке их поступления». Столь же очевидно, что рост числа и масштабность успешных внедрений всецело зависят от взаимодействия конкретных людей — их участников. Не только усложняются требования к профессиональной подготовке специалистов, но теперь в большей степени, чем прежде, нужны полноценные эксперты, а успех зависит от взаимодействия всех звеньев цепи — от вендора и его партнеров до заказчика. Все они должны научиться видеть задачу по возможности одинаково, договариваться о результате и прогнозировать будущее — не пытаться угадать, а именно прогнозировать. Реальный бизнес показал не только жизнеспособность, но и оптимальность подобного подхода.
Руслан Чиняков — технический директор компании OCS. На протяжении последних 10 лет специализируется в области экспертизы, проектирования и развития проектных решений современных мультисервисных сетей и систем хранения данных. С ним можно связаться по адресу: rchiniakov@ocs.ru.
