Эффективный ИТ-отдел. Как выбирать вендора. Проверка примеров и анализ несоответствий

Как правильно выбрать вендора. Шаг 1. (IE № 22 2004): Этапы выбора вендора. Создание команды выбора. Шаг 2. (IE № 23 2004): Оценка затрат и прибылей и предварительный анализ вендоров. Шаг 3. (IE № 24 2004): Анализ RFP. Шаг 4. (IE № 1 2005): Детальная проработка вендоров.

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

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

Источники информации

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

Основные пути вычисления клиентов, не упомянутых вендором в RFP, следующие.

1. Сообщения на сайтах поиска/предложения работы. Логика данного хода проста: компании, которые нанимают людей и указывают в списке необходимых навыков технологию данного вендора, скорее всего имеют эту технологию в производстве. Опрос специалиста, указавшего данную технологию в списке навыков, которыми он владеет, тоже может привести к очень продуктивным результатам. Есть только одно неудобство — не все технические специалисты работали с данными продуктами на производстве, многие лишь ознакомились с ними в лабораторных условиях.
2. Любая компания, занимающаяся трудоустройством в секторе ИТ, за определенную плату сможет выдать достаточно полную информацию о компаниях, использующих данную технологию, на базе резюме и предложений проходивших через них.

Таким образом, у команды выбора вендора появляется мастер-список клиентов вендора. В зависимости от размера проекта количество компаний из обоих списков, которым необходимо звонить, колеблется от двух до восьми из каждого списка. Необходимо помнить, что компании из вендорского списка отличаются тем, что скорее всего подготовлены вендором и готовы ответить на вопросы.

Вопросы клиентам вендора

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

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

1. Какой продукт вы подвергали оценке?
2. Каковы были ключевые критерии выбора при принятии решения?
3. Какие функции считались критически важными, и как проходил функциональный анализ продукта? Какова была логика распределения приоритетов? Что было более важным, что менее важным?
4. Когда было принято решение по поводу данного продукта? Сколько времени было потрачено на оценку вендора?
5. Какие модули или продукты были в конце концов приобретены или внедрены?
6. Работала ли техническая архитектура так, как было запланировано?
7. Каковы именно были ключевые эффекты внедрения вендорской технологии: снижение стоимости, увеличение оборота? Каким образом были получены эти преимущества?
8. Какой период потребуется или потребовался, чтобы получить прибыль от внедрения данной технологии?
9. Были ли какие-либо технические проблемы или проблемы поддержки пользователей? Как вендор справился с этими проблемами? Вмешательство какого уровня руководства потребовалось для разрешения данной проблемы?
10. Прибегали ли к помощи поставщиков ИТ-услуг при внедрении данного продукта или технологии?
11. Каково качество услуг вендора после продажи?
12. Как архитектура системы вела себя по мере изменения объема транзакций и количества пользователей?
13. Какие были сюрпризы — хорошие и плохие?
14. Какие уроки вы извлекли в результате процесса выбора и последующего внедрения продукта вендора? Пошли бы вы на внедрение этого продукта еще раз?

Анализ несоответствий

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

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

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

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

Таблица. Детальный анализ наиболее критичных несоответствий.

Шаг 5. Выбор сопутствующих вендоров

Если решение вендора требует дополнительного аппаратного обеспечения для успешного внедрения, команда выбора вендора может столкнуться с еще одним процессом выделения поставщика сопутствующих решений. В целом этот процесс должен управляться согласно модели, предложенной в данном цикле. Чаще всего, однако, не приходится проходить весь процесс отбора с нуля. Чаще всего выбор сопутствующих вендоров сильно зависит от выбора вендора по основному решению. Отправной точкой для выбора сопутствующего поставщика могут быть рекомендации самого вендора (в RFP есть соответствующий пункт) и звонки по клиентам вендора. Как правило, другие клиенты этого вендора без проблем говорят, какие компании они используют в качестве поставщка аппаратного и дополнительного программного обеспечения, а также ИТ-услуг.

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

1. Качество юстировки решений. Как правило, серьезные бизнес-приложения подвергаются тестированию на оборудовании ведущих вендоров. Более того, оборудование определенным образом «затачивается» под приложения, равно как и приложения под оборудование. Отклики клиентов помогают оценить качество связки «вендор—вендор», а также понять, какие проблемы возникают в связи с интеграцией систем.
2. Надежность и поддержка. Для критически важных приложений аппаратное обеспечение должно поставлять достаточную степень надежности, необходимую степень избыточности ресурсов и качественные и быстрые услуги по поддержке.
3. Апгрейд. Если требования масштабируемости системы предполагают ее расширение в будущем, поставщики аппаратного обеспечения должны объяснить принципы минимизации полной стоимости решения и нейтрализации сложностей апгрейда.
4. Цена. Вендоры должны представить цену для различных уровней. Часто поставщики приложений имеют контракты с поставщиками аппаратного обеспечения и таким образом получают скидки, недоступные для несвязанных сделок.

***

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

ИТ-услуги от вендора Одновременно с выбором вендора команда выбора вендора должна исследовать возможность использования услуг ИТ-консультантов вендора или необходимость увеличения штата. Оба подхода в настоящее время используются компаниями. Это вопрос большой и сложный, требующий отдельной статьи. Здесь мы остановимся только на моментах, которые тесно связаны с выбором самого вендора, поскольку эти процессы могут взаимно влиять друг на друга. Опыт консультантов вендора. Готов ли вендор предоставить информацию по проекту с аналогичными параметрами (размер компании, внедренные модули, бюджет проекта, бизнес-модель) и запрашиваемыми услугами? Участвовали ли консультанты вендора в других подобных проектах? Предоставит ли вендор потенциальный рабочий план, который демонстрирует детальное понимание ключевых проблем для проекта? Штат. Готов ли вендор предоставить информацию по каждому члену команды, которая будет участвовать в проекте? Готов ли вендор предоставить резюме на каждого участника команды? Имеет ли заказчик право наложить вето на участие в проекте тех или иных членов команды? Фиксированная цена. Готовы ли консультанты вендора заключить контракт с фиксированной ценой? Ведь если команда выбора вендора завершила работу над детальным рассмотрением вендоров на достаточном уровне, большинство сложностей и недочетов уже задокументированы и понятны. В этой ситуации объем работ известен, и вендор должен пойти на контракт с фиксированной ценой. Скидки. Готов ли вендор предоставить скидки на услуги ИТ-консультантов, основанные на общем объеме оплат по проекту?

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