«Эффективный ИТ-отдел»Часть 1 (IE № 18 2004): Симптомы неэффективности ИТ.Часть 2 (IE № 19 2004): Категоризация проблем ИТ-службы. Основные направления улучшения работы ИТ-отдела. Часть 3 (IE № 20 2004): Как просчитать затраты на ИТ? Часть 4 (IE № 21 2004): Как распределить время ИТ-директора? |
Даже среднего размера компания имеет достаточно большой лист поставщиков программного, аппаратного обеспечения и сетевого оборудования. И ИТ-директора достаточно часто сталкиваются с необходимостью оценки вендоров. Практика показала, что чаще всего процессы выбора являются "программно-центрированными". Это означает, что в начале подбирается поставщик программного обеспечения покрывающего запросы бизнеса и задачи автоматизации бизнес-процессов, после чего принимаются решения относительно покупки аппаратного обеспечения и всевозможных дополнительно необходимых систем. Это логичный подход и в описании методики мы сконцентрируемся именно на такого рода процессе выбора вендоров.
Конечно, мы попытаемся охватить процесс выбора вендоров во всем его многообразии и сложности. Это не означает что каждая конкретная ситуация выбора вендора будет столь же многоступенчата. ИТ-директор должен будет действовать по ситуации, руководствуясь описанной методологией как моделью, а не догмой. Здравый смысл должен превалировать.
Систематический подход
Статистика по компаниям показывает, что часть ИТ-бюджета, которая уходит на оплату поставок и дополнительных услуг вендоров, колеблется в среднем от 30 до 60% ИТ-бюджета. Это автоматически означает, что ИТ-директор не сможет уйти от необходимости навести порядок в процессах выбора вендоров и процессе управления их активностью после продажи. Хорошо продуманный выбор вендоров и надежные поставщики-партнеры существенно облегчат работу ИТ-директора. Обратное тоже верно.
Понятно, что систематический подход приводит к наиболее четко выверенному результату, но, кроме этого, систематический подход выступает как защита ИТ-директора в общении с вендорами. Очевидно, что интересы вендоров не всегда совпадают с интересами компании, которую представляет ИТ-директор. Конечно, удовлетворенность клиента для вендоров важна, но прибыльность, доходы, расширение клиентской базы и захват новых рынков для них тоже имеют не последнее значение. Вендор и его менеджеры по продажам методично и целенаправленно занимаются анализом рынка и вопросов продаж, делая все, чтобы выбор пал на продукт их компании.
Вендор будет стараться продать - это надо всегда помнить. Вендор делает это каждый день. Эту очевидную мысль можно переформулировать в более продвинутой форме: "При выборе вендора и общении с ним ИТ-директор всегда будет в более проигрышном положении, чем сам вендор в общении с ИТ-директором". Почему? Потому что ИТ-директор занимается выбором вендоров не так часто, тогда как на стороне вендоров стоят "сейлы", люди, которые закрывают по нескольку крупных контрактов в год, а то и в квартал или даже в месяц. Поэтому с точки зрения практики ведения переговоров ИТ-директор находится в гораздо худшем положении.
Проблема еще и в том, что, сделав выбор вендора, достаточно сложно нажать "Undo" и что-то изменить. Даже если через некоторое время ИТ-директор находит вендора получше, обратный ход чаще всего невозможен. Вендоры, как правило, защищают себя весьма чувствительными выплатами в случае разрыва контракта до окончания срока действия. Обычно вендорские внедрения связаны одновременно с поставкой аппаратного, программного обеспечения и сопутствующих услуг, поэтому возможность выбрать другого поставщика может открыться только через несколько лет.
Этапы выбора вендора
Многоступенчатый и сложный процесс выбора вендора в целом достаточно понятен. Этапы его представлены во врезке. Начинается он с того что определяется необходимый масштаб проекта и объем функциональных требований к ПО (или оборудованию вендора, в случае не программно-центричного выбора), а также к сопутствующим услугам, после чего создается команда по выборам вендора, происходит идентификация понятия "правильный" вендор, работа с RFP, выборы финалистов и отсев неправильных вендоров, окончательный выбор победителя, подбор сопутствующих вендоров, планирование и переговоры по цене с финалистом. Каждый из данных шагов мы обсудим более подробно в необходимых деталях.
Этапы процесса выбора вендораШаг 1. Определение масштаба проекта и функциональных требований
Шаг 2. Предварительный анализ возможных вендоров
Шаг 3. RFP Шаг 4. Детальная проработка Шаг 5. Дополнительные (сопутствующие) поставщики Шаг 6. Окончательный план и его утверждение Шаг 7. Окончательный договор с выбранным вендором |
Масштаб проекта и объем функциональных требований
Для начала ИТ-директор должен четко уяснить для себя весь спектр бизнес-процессов, который должен быть поддержан системами и решениями вендоров. Списки вендоров, технические требования - все это уже следует из понимания ИТ-директором спектра бизнес-процессов, подлежащих поддержке со стороны ИТ. И команда по выбору вендоров, которую ИТ-директор создаст в будущем, будет задавать вопросы и отбирать финалистов, основываясь именно на результатах данного этого анализа бизнес-процессов.
Основные причины, которые подталкивают предприятия к началу работы с вендорами, как правило, подпадают под одну из нижеописанных ситуаций.
Ситуация № 1. Необходимость замены или обновления систем, находящихся в конце цикла жизни или устаревающих до срока.
Ситуация № 2. Серьезные изменения в бизнес-модели (новые направления бизнеса, новые приобретения, влияющие на бизнес, вывод капиталов из определенных рынков или резкое увеличение объемов бизнеса).
Ситуация № 3. Необходимость снижения себестоимости продукции или увеличения производительности и т. п.
Ситуация № 4. Небольшой прогресс в бизнесе, увеличение прибылей, увеличение продаж, увеличение присутствия на рынке.
Ситуация № 5. Принципиальные изменения у поставщиков компании или возникновение новых требований у заказчиков.
Ситуация № 6. Поддержание конкурентного паритета - необходимость ответа на бизнес или технологические инициативы со стороны конкурентов.
Понятно, что основным результатом выбора и внедрения того или иного решения должно быть увеличение прибыльности, оборотности, снижение стоимости или увеличение контроля над бизнесом для данной компании. И с самого начала до самого конца процесса ИТ-директор должен не упускать из поля зрения эту главную цель.
Здесь главная задача ИТ-директора - четко определить масштаб будущей работы, сконцентрировав его на определенных бизнес-функциях с четко определенными границами и интерфейсами с другими бизнес-процессами. Примерами таких определенных бизнес-функций с четко определенными границами являются процессы продаж, логистика, планирование потребностей производства, поддержка потребителей, закупки. Чтобы четко определить масштаб работы, необходимо проанализировать и ичключить то, что не входит в него. Хорошим инструментом для понимания масштаба внедрения решений является контекстная диаграмма, показывающая бизнес-процессы в соотношении друг с другом с выделением того, что входит и не входит в данный масштаб. В любом случае детальный документ, который определяет функциональный масштаб внедрения, является первым шагом на пути выбора вендора. Определение масштаба внедрения может быть довольно деликатным процессом и требует не только решений ИТ-директора, но рассмотрения данного вопроса советом директоров и менеджментом компании.
Создание команды оценки
Анализ масштаба проекта, проведенный ИТ-директором, позволяет понять спектр знаний, технических и в сфере бизнеса, необходимый для качественной оценки вендоров. После того как определен масштаб внедрения решения, должна быть выбрана команда специалистов, которая будет осуществлять экспертизу вендоров. Оценка вендоров, в особенности в тех случаях, когда покрывается большой масштаб, требует большой аналитической работы. Усилиями одного специалиста здесь не обойтись.
Команда должна включать в себя специалистов из всех областей производства, которые будут затронуты выбором данного вендорского решения. В этом случае решение по выбору вендора становится более зрелым, включая в себя как техническую, так и бизнес-сторону. Раннее вовлечение бизнес-отделов в процесс выбора вендора существенно облегчает процесс внедрения новой технологии в компанию после окончательного выбора. Кроме того, бизнес способен увидеть аспекты того или иного решения вендора, которым ИТ-отдел может не придать должного значения (например, время, необходимое, чтобы обучить представителя службы поддержки потребителей в условиях большого объема работы).
Размер команды будет различным в зависимости от размера компании, масштаба и размера инвестиций. Небольшая команда может состоять из одного человека от ИТ, одного от бизнес-подразделений и одного управляющего. Как может выглядеть состав команды для оценки вендоров, видно на врезке. В идеальном случае вся команда или хотя бы наиболее активный костяк команды должен обустроиться в специально отведенном помещении.
Состав команды оценки вендоровПолная занятость: ИТ-директор, менеджер ИТ-приложений, разработчик ИТ-приложений, бизнес-аналитик по закупкам, производству, дистрибуции или другой функциональной области.Частичная занятость: DBA, разработчик ПО, специалист по EDI, системный инженер, бизнес-аналитик по финансам, контролер, бизнес-аналитик по основным средствам производства, директор по HR. Управление: СОО, СFO, вице-президент по производству, вице-президент по продажам и маркетингу, вице-президент по развитию. |
Описание бизнес-процессов и задание приоритетов
Одно из самых труднопроходимых мест в деле выбора вендора - понимание того, насколько данный программный пакет или что бы то ни было, предлагаемое вендором, подходит для бизнеса и соответствует требованиям бизнеса. Для этого необходимо полное понимание бизнес-процессов на уровне максимально возможной детализации. Полное понимание бизнес-процессов, сроков, событий, календарей, объемов и правил, управляющих данными процессами, позволит команде быстро и аккуратно оценить систему и определить оптимальный подход к решению.
Работа по описанию бизнес-процессов и документированию требований чрезвычайно трудна и дотошна, однако является АБСОЛЮТНЫМ УСЛОВИЕМ успешного выбора вендора и формирует основной принцип внедрения. Без этого команда не сможет оценить, насколько соответствует решение вендоров требованиям бизнеса, и найти возможные варианты обойти это несоответствие, не сможет определить, какие перемены требуются от бизнеса, какие затраты необходимы для правильной конфигурации и настройки типовой системы. Поверхностное, слабое понимание бизнес-требований и неизбежно слабый анализ на этой основе - основная причина неудач внедрений больших систем.
В целом сбор требований в отношении необходимой ИТ-поддержки бизнес-процессов очень похож на стандартный процесс сбора требований на начальных этапах создания программного обеспечения. Если ИТ-директор имеет опыт управления созданием программного обеспечения (а очень многие ИТ-директора так или иначе были задействованы в процессе написания собственного ПО), дополнительных навыков здесь не понадобится. Вся разница состоит в том, что собранные требования будут потом проецироваться на уже готовые решения, а не запускаться в разработку.
Требования должны покрывать бизнес-события и процессы, которые управляют ими. Созданные в результате анализа документы должны охватывать не только того, что делает система, но и то, за что отвечают люди, управляющие системой, какие бизнес-правила или практики влияют на данный процесс и какая информация создается на каждом этапе. Описания, кроме того, должны показать разницу между текущим бизнес-процессом и планируемой реализацией этого процесса. Наиболее эффективный путь к созданию таких описаний - это интервью с менеджерами и конечными пользователями компании.
При этом старая документация по процессам может служить отправной точкой для создания новых требований. Это особенно работает в отношении нового ПО. Система, работающая в настоящее время, представляет собой отражение старых бизнес-требований. То, что настоящая система делает хорошо, должно быть отправной точкой для нового решения. Если существующая система вообще не имеет документации и процессы никак не описаны, команда проекта должна собрать базовые требования к системе и создать документацию заново.
Типичный набор документов, который создается на уровне сбора требований к новой системе, состоит из следующих описаний:
- диаграмм бизнес-процессов;
- описаний процессов, показывающих требуемые входные/выходные данные, процедуры, вычисления, интерфейсы и учитывающих человеческий фактор;
- триггеров бизнес-событий (синхронных, асинхронных);
- смысла данных (объектов, поисков, транзакций) и требований к их формату;
- календаря обработки данных - дневные, недельные и месячные транзакции, мощности, события и отчеты;
- оценки объема обработки данных;
- требований к отчетам;
- требований к пользовательскому интерфейсу;
- требований к безопасности.
Как только бизнес-требования к решению определены, каждому из них должен быть назначен коэффициент критичности, чтобы, по мере того как будут прорабатываться решения от разных поставщиков, команда могла предварительно уяснять значимость разных процессов и соответственно анализировать недостатки проработки данных процессов в решениях вендоров. Важно заметить, что на предварительном этапе не надо слишком сильно усложнять систему оценки. Можно остановиться на трех категориях оценки критичности: высокая, средняя и низкая. Пример формулировок с категориями может быть такой: "Заказ потребителей категории А должен быть выполнен как минимум на 98,5% в связи со спецификой обязательств по контракту; система должна автоматически предупреждать о потенциально возможных недостачах определенных продуктов на складе - приоритет высокий".
Опыт показывает: ИТ-директору необходимо дополнительно контролировать, что команда детально проработала вопрос приоритетов для разных задач, потому что в противном случае всем требованиям будет выставлен высокий приоритет. ИТ-директор должен четко понимать, что процессы высокого приоритета будут критически важными при выборе решения вендоров, и именно эти требования станут основными критериями отбора систем на стадии детальной проработки решений вендоров. В связи с этим необходимо провести четкую границу между требованиями с высоким приоритетом, которые будут ответственны за выбор, и всеми остальными требованиями. ИТ-директор, кроме того, должен дать понять команде, что на данном этапе оценке и приоритезации подвергается только функциональная часть решений вендоров, а техническая сторона вопроса, также как и требования к вендору, будет подвергаться приоритезации позже.
Услуги аудита решений
В зависимости от размеров проекта команда может воспользоваться услугами третьих компаний в деле схематизирования бизнес-процессов и формулирования требований к новой системе. Однако ИТ-директор должен четко понимать границы вовлечения третьих сторон в такой деликатный процесс, как выбор вендора. У третьих компаний могут быть свои интересы - чаще всего они хотят стать партнерами по внедрению, что может всплыть позже. Кроме того, собственная команда по выбору вендоров никогда не наработает навыков выбора и понимание описания процессов, если вовлечь в этот процесс третьи компании. ИТ-директор должен помнить: идеальная модель привлечения третьих компаний для помощи позволяет третьей стороне помогать самой команде в проведении процесса оценки, а также обучать команду выбора правильно проводить документацию и строить на этом основании выбор вендора. Лучшие компании подобного рода накопили достаточно много опыта в процедурах выбора вендоров и программных пакетов и, как правило, претендуют на роль партнеров по внедрению.
Результатом тщательной проработки бизнес-процессов должно стать полное понимание путей их улучшения. Команда выбора вендора должна задокументировать эту информацию для ее дальнейшей оценки на уровне руководства предприятием. Здесь есть один момент, с которым надо быть очень осторожным. Как только становятся понятны пути возможного улучшения бизнес- процессов, ИТ-директор может сразу же попытаться их улучшить, будучи еще на стадии анализа бизнес процессов. Ничего криминального в этом нет, но важно помнить, что изучение бизнес-процессов было начато для того, чтобы в будущем внедрить новую систему. А если начинать изменения до внедрения, это может внести дополнительный хаос в процессы производства, что всегда так или иначе выливается в определенные дополнительные затраты и прямое или косвенное удорожание процессов внедрения. Глобальные бизнес-процессы на стадии внедрения системы следует изменять с очень большой осторожностью.
| С самого начала ИТ директор должен помнить о главном: результат выбора и работы с вендорами должен привести к увеличению прибыльности, оборотности, снижению стоимости или увеличению контроля над бизнесом для данной компании. |
Продолжение читайте в следующем выпуске цикла "Эффективный ИТ-отдел"
