Детальный анализ вендоров

В большинстве несложных проектов создания ИС задействованы три стороны: заказчик, производитель оборудования или программного обеспечения, а также посредник между ними в лице интегратора. Заказчик общается с интегратором, интегратор — с производителем, и эти два круга общения оказываются изолированы друг от друга. Когда речь идет о сложных проектах, цена которых начинается с десятков тысяч долларов, заказчик может вступить в непосредственное взаимодействие с производителем Михаил Попов, Как использовать вендора, http://www.ibusiness.ru/marcet/manager/31 702/, Опубликовано 22 января 2004 года.

Для прямой работы с вендором (производителем и поставщиком) есть две основные причины: во-первых, общение заказчика с поставщиком является способом воздействия на посредника — дистрибьютора или интегратора, а во-вторых, это способ воздействия на самого поставщика.

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

Взаимодействие с вендором имеет смысл в том случае, если в компании существует продуманная ИТ-стратегия, в которую органично включены вопросы централизованного финансирования ИТ. Однако последнее условие в 90% случаев не выполняется. Либо у руководства компании существуют смутные представления об ИТ-стратегии, либо у разных управляющих отсутствует согласие по поводу целей развития. Если ресурс, выделяемый на развитие ИТ, недостаточно специфицирован и за него отвечают различные подразделения, то могут возникать самые разные сценарии, в т. ч. и сценарий «дикого рынка», когда заказчик становится ареной конкурентной борьбы нескольких поставщиков.

Детальный анализ вендоров представляет собой важный этап работы Глеб Галкин, Эффективный ИТ-отдел. Как выбирать вендора. Часть 4. Детальный анализ вендоров // Корпоративные системы, № 1(111), 2005. Главная задача этого шага — тщательнейшая проработка соответствия вендорского продукта функциональным запросам компании, проработка технических моментов вендорского решения, а также планомерная работа с бывшими заказчиками данного вендора с целью понять, насколько качественно вендор решил проблемы других компаний.

Детальный анализ состоит из двух основных частей:

функциональность продукта, в ходе которого выясняют, насколько точно продукт вендора, соответствует функциональным запросам компании;

анализ технических решений.

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

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

предпочтительная техническая архитектура решения;

способность поддерживать пиковые объемы нагрузки;

подход к разработке.

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

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

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

Наконец, последнее — оценка методологии разработки и технологий, использованных вендором для создания данной системы или продукта. Эти два фактора влияют на стоимость и качество системы. Вендоры, которые сделали инвестиции в специальные технологии и методики создания приложений, такие как SDLC, CMM, или вендоры с сертификатами качества ISO имеют важные преимущества. Чем более распространена технология создания, тем выше доступность рабочей силы и тем, как правило, ниже стоимость продукта.