Эффективный ИТ-отдел. Как правильно выбрать вендора.Шаг 1. (IE № 22 2004): Этапы выбора вендора. Создание команды выбора.
|
Детальный анализ вендоров, выбранных после анализа RFP, представляет собой следующий шаг работы с вендорами. Главная задача этого шага — тщательнейшая проработка соответствия вендорского продукта функциональным запросам компании, проработка технических моментов вендорского решения, а также планомерная работа с бывшими заказчиками данного вендора с целью понять, насколько качественно вендор решил проблемы других компаний.
Прорабатывая RFP-данные, предоставленные вендорами, команда по выбору вендора должна сосредоточиться на различиях между вендорами, так как именно эти различия и повлияют на окончательный выбор. В конце концов после анализа RFP должно остаться два (иногда три) вендора. Эти два вендора должны быть подвергнуты более детальному анализу. Детальный анализ состоит из двух основных частей. Первая главная часть детального анализа – функциональная. В ходе ее команда выясняет, насколько точно продукт, предлагаемый вендором, соответствует функциональным запросам компании. Вторая часть детального анализа — выяснение технических моментов решения.
Уровень детализации
Функциональная часть детального анализа должна проводиться настолько детально, насколько можно. Как наиболее важная, она требует особенных аналитических усилий. Необходимо упомянуть, что ошибки именно в этой части, как правило, являются основным источником неприятных сюрпризов в фазе внедрения решения. Поэтому понимание бизнес-процессов, которые надо перевести в информационные системы, должно быть очень глубоким. Серьезные требования предъявляются и к уровню детализации системы вендора. Команда по выбору вендора должна задавать вопросы до тех пор, пока не будет получен удовлетворительный ответ. Если в результате этой работы от вендора начнут поступать недовольные замечания по поводу детальности вопросов, можете принять это как комплимент хорошей работе. Жалобы подобного рода можно использовать как индикатор правильности направления движения. Важно понять и обратное: если вендор не жалуется, то до желаемого уровня детализации еще далеко и команда выбора продолжает играть в поле, определенном самим вендором.
Структура вендорских демонстраций
Основа функциональной части детального анализа — демонстрация решения. Эффективнее всего будет организовать для каждого вендора по две разные демонстрации. На первой из них, открытой, вендор демонстрирует продукт так, как считает нужным. Вторая демонстрация четко планируется командой по выбору вендора и дает ответы на вопросы, являющиеся высокоприоритетными функциональными моментами компании-заказчика. Демонстрации надо организовывать именно в порядке, указанном выше: сначала свободная презентация вендоров, потом, спустя некоторое время, — презентация по плану, продуманному командой по выбору вендора.
Все вендоры знают наилучший способ презентовать свою продукцию. Открытая ничем не лимитированная возможность показать продукт так, как вендоры считают нужным, является важным шагом в работе с ними. Зная, что им были даны все шансы, они будут удовлетворены ходом дела. Вы получаете все козыри в руки. Вы дали вендорам сделать то, что они хотели, теперь их черед сделать то, что вам нужно. Вендоры и не будут подозревать, что вторая демонстрация для команды по выбору вендора намного более важна.
Содержание второй демонстрации критично. Команда по выбору вендора должна представить вендору обширный список требуемых функций, а также пробные сценарии и данные для тестовой работы системы. В результате этой демонстрации команда по выбору вендора должна понять не только то, как в данной системе выполняются ключевые функциональные требования, но и как та или иная функция сконфигурирована в системе и какой уровень конфигурации требуется, чтобы заставить ее работать согласно функциональным требованиям. Команда по выбору вендора ни на минуту не должна забывать, что многоступенчатые конфигурации и настройки системы повышают стоимость внедрения. Нужно вести учет примерного уровня настроек, требуемого для функциональности. Вендора надо просить дать столько демонстраций, сколько нужно, чтобы команда по выбору вендора поняла в деталях, как каждая из функций будет выполняться.
В дополнение к демонстрации основных функциональных требований команда по выбору вендора должна запросить демонстрации вспомогательных функций системы, если относительно них остаются какие-либо вопросы после первой демонстрации. В эту часть обычно включаются дополнительная функциональность, инструменты конфигурации, языки настройки, интеграционные средства, API, инструменты извлечения данных, возможности создания отчетов и другие.
Как правило, на каждую демонстрацию отводится целый день. Вторая демонстрация назначается на одну из последующих недель. Одна-две недели после первой демонстрации должны быть посвящены анализу откликов других заказчиков на эту же систему и дополнительные исследования по данному вендору. Команда по выбору вендора должна иметь достаточно времени между демонстрациями, чтобы собрать воедино все, что удалось найти. Но демонстрации надо назначать достаточно близко по времени друг к другу, чтобы быть уверенным, что сравнение вендоров сделано качественно. Хорошим интервалом считается один день между демонстрациями.
Добиться наилучшего порядка работы данного этапа можно, выполняя следующие правила:
- Вендоры должны четко представлять, чего вы ожидаете от первой и второй демонстраций.
- Необходимо обеспечить присутствие на демонстрации каждого члена команды по выбору вендора и отсутствие каких-либо других дел в этот день.
- Членам команды по выбору вендора следует проявлять активность во время сессии вопросов и ответов.
- Демонстрации должны проходить там, где это удобно вендору, чтобы он мог показать товар в его лучшем проявлении и не имел никаких претензий в связи с нехваткой чего бы то ни было или техническими неувязками.
Технический детальный анализ
Вторая часть детального анализа — технический детальный анализ — необходима для выяснения полного набора технических компонентов для всех вендорских приложений и планируемой технической архитектуры. Технический детальный анализ, как правило, проходит при участии технического представителя (одного или более) от вендора, членов команды по выбору вендора и технического специалиста из ИТ-отдела компании. Данная часть работы предполагает, что будут определены все необходимые технические детали будущего решения. Эта часть состоит из трех подчастей: предпочтительная техническая архитектура решения, способность поддерживать пиковые объемы нагрузки и подход к разработке.
Прежде всего команда по выбору вендора должна определить рекомендуемые стандарты и вероятные требования для всех требуемых компонентов планируемой системы. Дело в том, что показать в благоприятном свете свое решение вендорам часто удобнее на конфигурации, минимально соответствующей требованиям. Но реальный интерес представляет не минимальная, а наиболее вероятная конфигурация, и оценивать решения надо относительно нее. Очевидно, что наиболее вероятная конфигурация определяет и цену.
Здесь команда по выбору вендора может углубиться в различные аспекты технического анализа. Результатом работы на этом этапе должно быть четкое понимание вероятной стоимости проекта с технической точки зрения, чтобы команда могла создавать бюджет проекта начиная с конца описываемого здесь этапа выбора вендора. Потенциальные вопросы должны быть распределены таким образом, чтобы было понятно, какие технологические вопросы повлияют на процесс принятия решения в целом и какие — на общую стоимость проекта.
Список рассматриваемых вопросов может быть следующим:
- Предпочтительная техническая архитектура решения: ОС, серверы, клиенты, сеть, базы данных.
- Количество и тип требуемых серверов и систем хранения.
- Инструменты интеграции: middleware, API и т. д.
- Приложения от третьих компаний, необходимые для работы решения (middleware, приложения создания отчетов, базы данных и др.).
- Минимальные требования к клиенту.
- Требования к сети и пропускной способности между сервером и клиентом
- Возможности балансировки нагрузки и кластеризации.
- Подходы к созданию резервных копий данных. Управление восстановлением данных.
- Процедуры старта и завершения работы системы
- Защита и аудит системы. Пользовательские и администраторские настройки.
Пиковые нагрузки
Вторая часть технического анализа состоит в том, чтобы оценить способность системы поддерживать пиковые объемы транзакций и адаптироваться к будущему изменению бизнеса. Здесь важно четко проанализировать возможности масштабируемости системы. Для этого необходимо оценить текущий объем пользователей и пиковую нагрузку на систему. Это трехступенчатый процесс. Сначала надо определить день и время пиковой активности существующей в компании системы. После чего взять реальный объем транзакций и количество пользователей. Должны быть определены пики нагрузки, сезонные и месячные факторы (отчеты конца месяца или финансовые обработки) и недельные влияния. Эти пиковые изменения зависят в значительной степени от индустрии, типа компании, концентрации пользователей, сезонности бизнеса и ряда других показателей.
После того как пики определены, техническая команда должна построить календарь работы системы, описать, какие процессы в какие часы работают. Данная таблица может выглядеть примерно так, как показано на рис. 1. Команда по выбору вендора может оценить количество пользователей и объемы транзакций для пиковых и общих периодов. Затем эта информация должна быть просуммирована, как показано на рис. 2.
После этого команда может сравнить эти данные с данными рассматриваемой системы. Вендоры обычно представляют два различных типа показателей мощностей системы. Один является результатом лабораторного стресс-теста, который показывает максимальные возможности системы при определенных различных технических условиях. Второй — результат практического внедрения системы у реального пользователя.
Во втором случае команда по выбору вендора должна связаться с компанией, у которой уже работает эта система, и проверить данные и способность системы управляться с пиковыми объемами.
В целом все эти сборы данных и оценки должны стремиться ответить на два вопроса.
- Будет ли у онлайнового пользователя нормальная возможность взаимодействовать с системой во время пиковых часов работы системы (будет ли время ответа системы находиться в приемлемых пределах для пользователей, или ответ будет слишком медленным)?
- Будет ли система способна обработать всю требуемую информацию в какое-то разумное время?
Подход к разработке
Наконец, последняя составляющая технического детального анализа — оценка методологии разработки и технологий, использованных вендором для создания данной системы или продукта. Эти два фактора влияют на стоимость системы. Вендоры, которые сделали инвестиции в специальные технологии и методики создания приложений, такие как SDLC, CMM, или вендоры с сертификатами качества ISO имеют важные преимущества. Чем более распространена технология, использованная при создании, тем выше доступность рабочей силы и тем, как правило, ниже стоимость продукта. Можно оценить уровень адаптации сертификации и методологий через контакт с компанией, которая выдала сертификат. Можно также, например, попросить вендора показать руководство по стандартам разработки.
***
В области технического детального анализа один вендор редко отличается от другого. Большинство вендоров поддерживают все технологии, присутствующие на рынке, используют одинаковые среды разработки, обеспечивают похожие интерфейсы и поддерживают объемы передачи данных, превышающие ожидаемые пики. Поэтому технический детальный анализ должен быть сосредоточен на понимании потенциальной стоимости внедрения данной системы с точки зрения аппаратной и инфраструктуры. Следует предусмотреть и страховку от любых сюрпризов, в особенности связанных с поддержкой платформ и масштабируемостью решения анализа.
Тем не менее фаза технического детального анализа необходима. Важно понять: при таком подходе, а также при проведении двух функциональных презентаций команда по выбору вендора держит контроль над ситуацией в своих руках, что и требуется делать явно или скрыто на протяжении всего периода выбора. В следующей части статьи читайте о методике детального анализа компании-вендора.
