О компании Услуги Портфолио. Выполненные проекты Поддержка Отзывы клиентов Контактная информация ООО Брутка: разработка программного обеспечения и продвижение Вашего бизнеса в Internet

Как правильно выбирать вендора


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

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

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

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

Этапы выбора вендора
Многоступенчатый и сложный процесс выбора вендора в целом достаточно понятен. Этапы его представлены во врезке. Начинается он с того что определяется необходимый масштаб проекта и объем функциональных требований к ПО (или оборудованию вендора, в случае не программно-центричного выбора), а также к сопутствующим услугам, после чего создается команда по выборам вендора, происходит идентификация понятия "правильный" вендор, работа с RFP, выборы финалистов и отсев неправильных вендоров, окончательный выбор победителя, подбор сопутствующих вендоров, планирование и переговоры по цене с финалистом. Каждый из данных шагов мы обсудим более подробно в необходимых деталях.

Шаг 1. Определение масштаба данного проекта и функциональных требований
четко сформулировать основную причину необходимости выбора вендора;
определить объем и масштабы бизнес-функций, требующие работы с вендором;
создать команду оценки вендоров;
описать и расставить приоритеты запросов бизнеса к системе;
общий предварительный анализ затрат и прибылей от проекта.
Шаг 2. Предварительный анализ всех возможных вендоров:

определить источники информации, на основании которых создать список потенциальных вендоров;
создать первичные и вторичные критерии отсева вендоров;
создать структуру отсева;
собрать данные на вендоров;
осуществить предварительный отсев, выбрав 2-8 финалистов.
Шаг 3. RFP (Request For Proposal)

Шаг 4. Детальная проработка ответов

Шаг 5. Дополнительные (сопутствующие) поставщики

Шаг 6. Окончательный план и его утверждение

Шаг 7. Окончательный договор с выбранным вендором

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

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

Ситуация № 1. Необходимость замены или обновления систем, находящихся в конце цикла жизни или устаревающих до срока.

Ситуация № 2. Серьезные изменения в бизнес-модели (новые направления бизнеса, новые приобретения, влияющие на бизнес, вывод капиталов из определенных рынков или резкое увеличение объемов бизнеса).

Ситуация № 3. Необходимость снижения себестоимости продукции или увеличения производительности и т. п.

Ситуация № 4. Небольшой прогресс в бизнесе, увеличение прибылей, увеличение продаж, увеличение присутствия на рынке.

Ситуация № 5. Принципиальные изменения у поставщиков компании или возникновение новых требований у заказчиков.

Ситуация № 6. Поддержание конкурентного паритета - необходимость ответа на бизнес или технологические инициативы со стороны конкурентов.

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

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

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

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

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

Состав команды оценки вендоров
Полная занятость: ИТ-директор, менеджер ИТ-приложений, разработчик ИТ-приложений, бизнес-аналитик по закупкам, производству, дистрибуции или другой функциональной области.
Частичная занятость: DBA, разработчик ПО, специалист по EDI, системный инженер, бизнес-аналитик по финансам, контролер, бизнес-аналитик по основным средствам производства, директор по HR.
Управление: СОО, СFO, вице-президент по производству, вице-президент по продажам и маркетингу, вице-президент по развитию.


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

Работа по описанию бизнес-процессов и документированию требований чрезвычайно трудна и дотошна, однако является АБСОЛЮТНЫМ УСЛОВИЕМ успешного выбора вендора и формирует основной принцип внедрения. Без этого команда не сможет оценить, насколько соответствует решение вендоров требованиям бизнеса, и найти возможные варианты обойти это несоответствие, не сможет определить, какие перемены требуются от бизнеса, какие затраты необходимы для правильной конфигурации и настройки типовой системы. Поверхностное, слабое понимание бизнес-требований и неизбежно слабый анализ на этой основе - основная причина неудач внедрений больших систем.

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

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

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

Типичный набор документов, который создается на уровне сбора требований к новой системе, состоит из следующих описаний:

диаграмм бизнес-процессов;
описаний процессов, показывающих требуемые входные/выходные данные, процедуры, вычисления, интерфейсы и учитывающих человеческий фактор;
триггеров бизнес-событий (синхронных, асинхронных);
смысла данных (объектов, поисков, транзакций) и требований к их формату;
календаря обработки данных - дневные, недельные и месячные транзакции, мощности, события и отчеты;
оценки объема обработки данных;
требований к отчетам;
требований к пользовательскому интерфейсу;
требований к безопасности.
Как только бизнес-требования к решению определены, каждому из них должен быть назначен коэффициент критичности, чтобы, по мере того как будут прорабатываться решения от разных поставщиков, команда могла предварительно уяснять значимость разных процессов и соответственно анализировать недостатки проработки данных процессов в решениях вендоров. Важно заметить, что на предварительном этапе не надо слишком сильно усложнять систему оценки. Можно остановиться на трех категориях оценки критичности: высокая, средняя и низкая. Пример формулировок с категориями может быть такой: "Заказ потребителей категории А должен быть выполнен как минимум на 98,5% в связи со спецификой обязательств по контракту; система должна автоматически предупреждать о потенциально возможных недостачах определенных продуктов на складе - приоритет высокий".

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

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

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

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

 

Другие статьи

   

CRM

Преимущества CRM для Вашей компании Функции CRM системы Введение в Customer Relationship Management 
   

HTML (XHTML)

Развитие веб-технологий Юзабилити: наука или идеология? ICQ значек на Web странице 
Графические фильтры в HTML Справочник по мета тегам  

IT Новости

Стив Баллмер не считает, что Google опережает Microsoft во всех областях   

Законодательная база

Про електронний цифровий підпис   

Информация для заказчика

Не торопитесь с эскизами Целесообразность аутсорсинга Динамика развития IT - аутсорсинга в странах бывшего СНГ 
Безопасность при аутсорсинге Аутсорсинг IT- служб предприятия IT аутсорсинг 
Советы по построению отношений с аутсорсером Способы эффективного улучшения Вашего бизнеса с использованием Web сайта Данные о существующих доменных зонах 
   

Правила регистрации доменов

Правила домена .UA   

Разработка

Совместный выпуск Windows Server 2008 с Visual Studio и SQL Server Как написать хорошее тех. задание на сайт  

Технические советы и рекомендации

Firefox VS IE. Сравнение безопасности Microsoft поможет узаконить пиратские Windows XP Professional Sun готовит универсальную замену для платформы Java 2 ME 
Безопасность Wi-Fi-сетей: технологии защиты   

Электронная коммерция

Владелец сайта VS промоутер Маркетинг в электронной коммерции