От выбора очевидного до поиска невозможного, или
Как приобрести качественное ИТ-решение

О проблеме выбора

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

Задумываясь о приобретении очередного ИТ-продукта для бизнеса, мы мечтаем получить такую «золотую гусыню» и при этом избежать необходимости «вспарывания живота». Как же ее искать? Анализируя опыт «хозяина гусыни» из притчи, надо найти ответ на ряд важных вопросов:

• Как хозяин нашел такую птицу?
• Единственная ли птица была с такими способностями?
• Почему он искал ее среди гусей, а не среди лошадей?
• Если таких способных было много, то почему он выбрал именно эту птицу?
• Устраивала ли хозяина полная ТСО-модель гусыни?
• Кто и на каких условиях был поставщиком уникальной птицы?
• Был ли заключен договор с самой птицей на ежедневное оказание сервисов по ее поддержке?
• И почему, наконец, хозяин не провел тендер по всем правилам своего бизнеса?

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

Движение в область определенности Неопределенность, неизвестность — вот что больше всего пугает человека. Неопределенность будущего, неопределенность понимания, неопределенность отношений — это причины наших постоянных тревог. Любая деятельность — это движение по пути превращения неопределенности в определенность через переживание опыта. При этом мы всегда находимся между двумя полюсами (рис. 1). Нижний полюс (полюс определенности) — это область инстинктов и накопленного опыта, где любое внешнее событие вызывает запрограммированную заранее цепочку реакции. Верхний полюс (полюс неопределенности) — это область интуиции, нового и неизведанного, область проектов и изменений. Кстати, простое математическое правило Лопиталя1 подсказывает очень даже практические способы поведения. Если хочешь определенности — включи первую производную: не стой на месте, просто двигайся. Если хочешь понять нужное тебе направление движения — вычисли вторые производные: изучи не только тренды, но и скорость их изменений, пойми, где в следующий момент окажется шайба и измени направление своего движения. Если хочешь понять скорость требуемых изменений — займись третьими производными и поторопись, а то в нужной точке кто-то окажется раньше тебя и т.д. 1 Правило Лопиталя снимает неопределенность вида 0/0 или ∞/∞, позволяя заменить предел отношения функций в некоторой точке отношением их производных в той же точке.

Ищем или выбираем?

Итак, время от времени нам приходится искать, выбирать и приобретать ИТ-системы. Первый шаг на пути уточнения ситуации, в которой происходит выбор, — анализ степени неопределенности, с которой придется столкнуться. Ведь характер поиска и выбора решения очень сильно зависит именно от степени неопределенности.

Чтобы приблизиться к пониманию, построим квадрант неопределенности по двум осям (рис.2):

• неопределенность наших требований к будущему ИТ-решению;
• неопределенность предложений рынка с целью эти требования удовлетворить.

Опишем особенности ситуации выбора в каждом из квадратов.

Квадрат 1. Зона малой неопределенности. Зона стандартов и стабильности. Ваши требования четко определены, и предложение рынка также хорошо понятно. В этом квадранте находятся, например, оборудование и ПО, которое вы включили в корпоративный стандарт, коробочные продукты, с которыми уже работают многие или которые вы тестировали лично и знаете, что они хорошо отвечают вашим требованиям.

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

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

Квадрат 4. Зона большой неопределенности. Зона инноваций. Вы сами пока не знаете точно, чего хотите, и, похоже, что на рынке это только начало появляться. То есть решение, по сути, неизвестно.

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

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

Классификация подходов к выбору

Классификация зон поиска и выбора решения дает возможность понять, как провести поиск и выбор решения наиболее эффективно (рис 4).

Квадрат 1. Область стандартов и стабильности. Неопределенность требований и предложений низка, поэтому наиболее эффективно — быстро собрать большой список возможных кандидатов, открыто объявить требования и выбрать минимальную стоимость покупки. Здесь критерий «купить подешевле» вполне себя оправдывает.

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

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

Квадрат 4. Зона инноваций. Здесь неопределенность максимальна, и вам придется пройти итерационный процесс. Неопределенность является свойством инновационного проекта, а не проблемой. С этим бессмысленно бороться. Вы понимаете, чего хотите, по ходу разработки требований, и это нормально. Гарантированно по ходу будут меняться не только требования, но и состав вовлеченных участников и условия взаимоотношений с ними. Итерации в понимании требований порождают как итерации в разработке решения, так и итерации в отношениях с возможными поставщиками. Этим надо учиться управлять. Если не двигаться итерациями, можно легко получить несоответствие результата первоначальным ожиданиям или отсутствие баланса интересов участников. Все уже хорошо усвоили, что проекты в стиле «водопада» в ИТ-индустрии не работают. Так почему же должен работать линейный поиск и выбор ИТ-решения и его поставщика?

В качестве примера, насколько важно определить степень неопределенности вашего выбора, мы бы хотели привести ситуацию, с которой столкнулись на практике. Мы были участниками рабочей группы по выбору интегратора для уже действующей системы поиска причин технических проблем на сети 2G. То есть стартовая ситуация выбора была очень определенной и требовала лишь улучшения ценовых параметров. Мы находились в квадрате 1.

Однако очень быстро участники рабочей группы поняли, что гораздо выгоднее иметь одну систему на всю сеть, а не только на 2G. Это требование автоматически стало позиционировать конкурс не как выбор интегратора, а как поиск вендорского решения. В терминах предлагаемого нами подхода, мы сместились из квадрата 1 в сторону квадрата 2.

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

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

Принятие ИТ-архитектуры, ревизия требований и повторная итерация с поиском ИТ-решений позволили выйти на нормальный режим поиска с понятным алгоритмом. Заметим, что цикл правильного позиционирования отнял несколько месяцев. Если бы мы изначально использовали предлагаемый подход, этот срок значительно сократился бы.

Сколько стоит ценность?

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

Существенные отличия товара от сервиса показаны в таблице. Анализ характеристик сервиса показывает, что качество сервиса — это более значимый параметр, чем стоимость, поскольку некачественный сервис может приводить к прямым убыткам вашего основного бизнеса, которые не покроют никакие штрафные санкции. Существует, пожалуй, единственный способ обезопасить себя — SLA (Service Level Agreement). Однако на практике штрафные санкции всегда невелики и никогда не компенсируют вам ошибочного выбора. А сменить поставщика, когда вы уже купили сервис, крайне тяжело и затратно.

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

За получение ценности мы готовы платить. Извечный вопрос для человека: «Чем я готов заплатить за ценность»? или для бизнеса: «Сколько я готов заплатить за качество продукта, включающего товар (Capex) и сервис (Opex)»? Зоны оправданности затрат на решение можно показать, если отложить на одной оси стоимость, а на другой предполагаемую ценность, которую несет решение (рис.5).

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

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

Если выбор неизбежен, определитесь для себя заранее, сколько вы готовы платить за качество. Но определяясь, помните народную мудрость: «Скупой платит дважды».

Выводы. Как уменьшить риски при выборе?

Сделаем ряд практических выводов и рекомендаций из проведенного нами анализа.

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

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

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

4. Выбирая, не спешите, особенно в ситуации с высокой неопределенность. Желание уложиться любой ценой в проектный срок может сыграть злую шутку.

5. Выбирая, делайте итерации. Итерации особенно важны при поиске с большими степенями неопределенности.

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

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

8. Заранее думайте об SLA:
   • Если покупаемая система должна работать непрерывно 24x7, то покупка сервиса неизбежна. Телевизор, например, можно несколько дней не смотреть, а вот без работающего лифта на 24 этаже вам не обойтись. Кстати, позаботьтесь о резервировании: лучше, если лифтов будет два.
   • Если система обеспечивает важные для вас функции развития, то вам необходим SLA, включающий штрафные санкции за некачественный сервис. SLA должен мотивировать поставщика обеспечивать качество. Если сломался интернет, то желательно не только заставить провайдера починить, но и вычесть дни и часы простоя из оплаты. Здесь надо четко понимать отличие недополученной прибыли от понесенного убытка: недополученную прибыль вы не сможете заложить в штрафные санкции. Штрафные санкции в этом случае — это скорее мотивирующий фактор, чем бизнес-решение.
   • Если система обеспечивает жизненно важные для вас операционные функции, то вам необходим не просто SLA, включающий штрафные санкции за некачественный сервис. Главным становится размер этих штрафов. Здесь включается настоящий риск-менеджмент. Очевидно, что поставщик сервиса не станет включать в контракт полную стоимость ваших убытков. Кроме того, плата за такой сервис будет намного выше простого SLA.

Об авторах:

Антон Саввин, руководитель департамента развития систем поддержки операций компании «Вымпелком». Практик внедрения и автоматизации процессов ITSM и OSS Telecom. В качестве процессного менеджера построил в компании ИТ-процессы управления изменениями ИТ-инфраструктуры. Внедрил единую корпоративную систему управления инцидентами, проблемами и конфигурациями ИТ. Выполнил интеграцию OSS-систем Trouble Ticketing, Inventory и Umbrella Monitoring для мобильной сети.

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