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

«Эффективный ИТ-отдел»

Часть 1 (IE № 18 2004): Симптомы неэффективности ИТ.
Часть 2 (IE № 19 2004): Категоризация проблем ИТ-службы. Основные направления улучшения работы ИТ-отдела.
Часть 3 (IE № 20 2004): Как просчитать затраты на ИТ?
Часть 4 (IE № 21 2004): Как распределить время ИТ-директора?
Часть 5 (IE №22 2004): Как правильно выбрать вендора. Шаг 1.

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

Предварительный анализ затрат и прибылей

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

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

Таблица 1. Предварительная оценка прибылей и затрат по проекту

Категория Стоимость, тыс. долл.
Однократные выплаты по проекту
Аппаратное обеспечение 50
Программное обеспечение 150
Внешние ресурсы 225
Внутренние ресурсы 75
Общие затраты по проекту 500
Однократные преимущества по проекту
Снижение стоимости на поддержание оборудования 450
Итого: стоимость затрат на проект с учетом преимуществ 50
Регулярные затраты по проекту
Дополнительные затраты на обслуживание нового решения 60
Необходимое дополнительное использование процессорных мощностей н/д
Текущая поддержка 15
Итого: общие регулярные затраты 75
Регулярные прибыли по проекту
Снижение затрат, связанное с прекращением обслуживания нескольких старых систем 120 в год
Улучшенный уровень поставки информации н/д
Уменьшение потерь 25
Итого: регулярные прибыли от реализации проекта 145
   
Итого: регулярные преимущества от реализации проекта 70
Общий вывод: приблизительно девять месяцев после успешной реализации проекта требуется для того, чтобы текущие преимущества покрыли стоимость проекта.

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

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

Шаг 2. Предварительный анализ и оценка возможных вендоров

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

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

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

3. Интернет. Последний список изданий, рекомендованных университетом Гарварда для ИТ-директоров, откуда можно почерпнуть необходимую информацию:
CIO magazine: www.cio.com
CMP Media: www.techweb.com
Computer Business Review: www.cbronline.com
E-Week: www.eweek.com
Tech Republic: www.techrepublic.com
Darwin Magazine: www.darwinmag.com
Analyst Views: www.analystviews.com

4. TRF-аналитики. Существует целая индустрия помощи компаниям в выборе технологий, а также технологического стандарта, в который лучше всего инвестировать капиталы. Это TRF-компании (Technology Research Firms). Стоимость услуг таких компаний, как правило, значительна, но в любом случае можно попробовать обратиться к ним и посмотреть, как этот дорогой источник информации может поработать на вас. Наиболее крупные компании с представительствами по всему миру:

  • Aberdeen Group
  • AMR Research
  • Forrester Research
  • Gartner Group
  • Giga information Group
  • International Data Corp (IDC)
  • META Group

5. Финансовые аналитики. Банки и инвестиционные компании, с которыми работает ваша компания, представляет собой великолепный часто недооцениваемый источник информации. Дело в том, что, как правило, банки и инвестиционные компании держат на ставках финансовых аналитиков, в работу которых входит анализ различных рынков. Можете быть уверены, что рынок, который вам нужен, уже был проанализирован. Эти анализы могут быть источником бесценной информации. Если банки отказываются помочь в данном вопросе, тогда помните, что эти же самые финансовые аналитики проводят много времени на форумах и в новостных группах, посвященных определенным продуктам, просматривая или участвуя в обсуждениях.

Грамотно будет построить сбор информации и составление списка в следующем порядке: публикации в прессе, Интернет, отчеты исследовательских компаний, более деликатная информация от консультантов и родственных компаний.

Информация о вендорах должна классифицироваться согласно следующим категориям.

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

  • годовой оборот;
  • прибыльность;
  • история покупок;
  • количество работников, разработчиков ПО, специалистов по продуктам;
  • клиентская база;
  • общее количество конечных пользователей продукта.

2. Технологии. Как выбор данного вендора и его продуктов скажется на состоянии технологической платформы данного предприятия? Как это скажется на состоянии бизнеса и ИТ? Совместим ли продукт с данной или планируемой технической архитектурой? Позиции к рассмотрению следующие:

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

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

  • где расположен головной офис;
  • ближайший офис вендора;
  • общее количество офисов вендора;
  • близость офисов вендора к офисам данной компании;
  • местоположение команды разработчиков.

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

  • какие специфичные для интересующего сектора индустрии изменения были внесены в продукты рассматриваемого вендора;
  • общее количество клиентов данного вендора в интересующем секторе индустрии;
  • являются ли лидеры конкретной индустрии клиентами данного вендора.

5. Функциональный анализ. Этот анализ позволяет первично выяснить, дает ли данный пакет или продукт необходимую функциональность. Позиции к рассмотрению следующие:

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

Результаты первичной селекции

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

После того как информация собрана, команда должна отсеять вендоров недостаточно сфокусированных на данном секторе или не устраивающих в каком-либо другом отношении. Команда должна постоянно задавать себе один и тот же вопрос: "Можем ли мы представить себе ход событий, если будет выбран и внедрен продукт данного конкретного вендора? Сможем ли мы доверить ему наш бизнес?" Результатом этой работы станет небольшой список потенциальных вендоров, составленный на основе четкой методологии, и присутствие или отсутствие некоего вендора в этом документе будет иметь под собой четкое вполне понятное основание. Данный документ может выглядеть так, как показано в таблице 2.

Таблица 2. Структура первичной информации по вендорам

Вендор Вендор А
Название продукта Система А
Годовой оборот 325 млн
Головной офис UK
Ближайший офис Москва
Общее число сотруднков 599
Количество разработчиков 150
Время присутствия на рынке 72 мес
Секторы индустрии Дистрибуция
Общее количество клиентов 250
Крупные клиенты Cannon, Bic
Общее количество конечных пользователей продукта Более 25 тыс.
Серверные платформы Windows XP
Поддерживаемые базы данных Oracle, Informix
Функциональность А Да
Функциональность Б Нет
Замечания --

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

1. Полное соответствие. Один вендор способен полностью удовлетворить запросы компании.

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

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

Документ, который должен быть подписан на этом этапе, будет содержать приведенный список категорий и списки вендоров, подпадающих под одну из этих категорий. Надо помнить, что в идеале в каждой категории должно находиться не более одного-двух вендоров. В идеале после этой стадии список потенциальных вендоров будет содержать три-четыре компании. Пять и более компаний, прошедших первичную селекцию, превратят следующий шаг - Request for Proposal (RFP) - в головную боль. Такое обилие документации потребует больших усилий для анализа. Если количество компаний, прошедших первичную селекцию, менее трех, это снижает возможность договариваться по цене на заключительных этапах работы с потенциальным вендором. Документ может выглядеть так, как представлено в таблице 3 (на примере выбора вендора и решения для автоматизации бизнес-процессов предприятия).

Таблица 3. Категоризация отобранных вендоров по степени соответствия на примере проекта по автоматизации бизнес-процессов предприятия

Полное соответствие
Вендор А Поставка почти полного ERP-пакета без HR-модуля
Вендор B Поставка полного ERP-пакета, все необходимые модули
Оптимальное соответствие
Вендор С Поставка большей части ERP-пакета, но потребуется модуль прогнозирования от вендора X и модуль управления складскими операциями от вендора Y.
Вендор D Поставка большей части ERP-пакета, но потребуется пакет управления финансами от вендора Z.
На заказ
Вендор F Поставка некоторой части ERP-пакета, но модуль прогнозирования и модуль управления складскими операциями потребуется делать на заказ, плюс пакет управления финансами от вендора Z.

Специальный случай

Что делать, если на данной стадии предварительного выбора вендора получается, что ни один из вендоров не способен поставить требуемого решения? Или решение как будто бы есть, но количество требуемой доводки кажется чрезмерным?

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

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

***

Итак, мы подробно обсудили мероприятия на втором шаге выбора вендора, составили список потенциальных вендоров, собрали информацию, просеяли ее и сделали первичную селекцию возможных вендоров. Далее необходимо переходить к третьему шагу - запросу RFP (Request for Proposal). Об этом будет подробно рассказано в следующем выпуске.