Эффективный ИТ-отдел. Как правильно выбирать вендора. Часть 3. Анализ RFP.

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

RFP (Request For Proposal) представляет собой устоявшийся подход, в рамках которого компания позволяет вендорам продемонстрировать их возможности. RFP, как правило, покрывает достаточно большое поле информации о вендоре: описание продукции, техническая архитектура, структура и финансы компании, квалификация, тренинги, техническая поддержка и так далее.

Причины использования RFP

Как показало время, наиболее важные причины, которые вновь и вновь приводят предприятие к использованию RFP, таковы:

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

Если команда затрудняется создать качественный RFP, это означает, что масштабы проекта и критерии выбора не были заданы четко. Качественный RFP не только снижает усилия команды, но и вовлекает вендоров в процесс.

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

Обзорная часть RFP

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

Как правило, обзорная часть проекта состоит из трех частей: информации о компании, процессе и критериях отбора вендоров. В типичном случае эта часть отражает информацию, приведенную во врезке "Обзорная часть RFP".

Обзорная часть RFP должна быть создана так, чтобы помочь вендорам ответить на базовые вопросы, обычно интересующие вендоров. Вот список этих вопросов:

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

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

Обзорная часть RFP 1. Информация о компании: история компании; размер бизнеса - трех-пятилетняя история доходов компании, число работников; географическое представительство компании: местонахождение головного офиса, офисов компании и расположение промышленных мощностей; обзор продукции или услуг; ключевые клиенты или рынки; ИТ-архитектура компании; ключевые особенности компании (большое количество географически разделенных клиентов, высокотехнологическая продукция, труднопредсказуемый рынок и так далее); контактная информация. 2. Информация о проекте: обоснование проекта и ожидаемые результаты; предполагаемое время начала и окончания проекта; масштаб проекта; выделенные бюджеты (если бюджеты не были выделены, то сроки, в которые намечено выделение бюджетов). 3. Информация о RFP-процессе: способ распространения RFP; требования к формату ответа и количеству копий; кто в команде выбора вендора является лицом, принимающим решение; список вендоров - участников RFP-опроса; сроки проведения RFP-опроса; критерии отбора и соответствующие приоритеты (размер вендора, соответствие функциональным запросам, ценообразование, рекомендации).

Вопросы к вендору в RFP

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

Вендор: информация о компании вендора - размер, стабильность, ресурсы.

Функциональное покрытие: насколько требуемое функциональное поле покрывается возможностями вендорских продуктов или услуг.

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

Подходы к внедрению: предварительная информация от вендора по поводу их подходов к внедрению продуктов и временные рамки.

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

Экономика: порядок выплат, кредиты и другие экономические вопросы.

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

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

Вопросы к вендорам в RFP 1. Информация о вендоре: обзор деятельности вендора, включая историю, услуги, основные возможности, местонахождение офисов компании, команду и организационную структуру; финансовая информация: отчет за три-пять лет по оборотам и прибылям вендора; финансовая информация: отчет за три-пять лет по оборотам и прибылям на данном продукте или услуге; обзор линейки продуктов вендора и распределение доходов по продуктам; общее число работников компании; количество разработчиков или инженеров, работающих над созданием продукта; каковы критерии, с помощью которых вендор измеряет качество своей услуги или оборудования: оценка степени удовлетворенности клиента, количество звонков в службу поддержки или другие критерии; как часто данная информация публикуется внутри компании и как часто открывается для клиентов; результаты предыдущего анализа удовлетворенности клиентов, проведенного самим вендором или независимой компанией, насколько часто проводятся данные исследования; доступные для клиентов уровни услуги (как правило, вендоры имеют золотой, серебряный, платиновый и другие уровни); как вендор оценивает свои конкурентные преимущества; контактная информация. 2. Функциональное покрытие: карта соответствия модулей системы или ее возможностей каждому функциональному требованию, идентифицированному ранее и описанному в RFP; при этом необходимо особенно выделить высокоприоритетные функциональные области; соответствие каждому функциональному требованию должно быть отмечено одной из трех характеристик: "не требует настроек", "требует настройки", "отсутствует в системе"; для каждого утверждения, что данная функциональность присутствует в продукте, вендор должен обеспечить краткое описание того, где именно она присутствует, и предоставить образцы экранных интерфейсов; краткое описание того, как конфигурируется система; краткое описание того, как проводится глубокая подстройка системы, обычно с указанием используемых языков программирования. 3. Техническая сторона: описание технической архитектуры продукта; как требуемая или рекомендуемая технология работает с настоящей или планируемой технологической платформой в компании, пославшей RFP; технологии, поддерживаемые продуктом (операционные системы, аппаратное обеспечение, базы данных); история релизов и патчей для данного продукта (даты, информация о добавленной функциональности и исправленных ошибках); масштабируемость проекта в особенности для ключевых функциональных позиций (результаты лабораторных исследований и данные реальных клиентов компании); требуются ли для нормальной работы продукты третьих компаний, список этих продуктов и их роли; описание интерфейсов с другими продуктами; безопасность: на уровне пользователя, на уровне управления, интеграция с другим ПО, для обеспечения информационной безопасности. 4. Подходы к внедрению: как вендор подходит к внедрению своих продуктов, используемые методики и проектные схемы, есть ли какие-то нестандартные требования к внедрению, диктуемые географией, количеством пользователей, объемами информации и другими факторами; как вендор определяет временные рамки реализации проекта, приблизительные оценки усилий по внедрению - часы, количество сотрудников и т. д.; как вендор подходит к вопросу независимого аудита проекта. 5. Примеры и мнения клиентов: Здесь вендоры должны показать клиентов с законченным проектом, максимально близким к запрашиваемому. Если трудно подобрать точное соответствие существующему запросу, вендор должен привести подходящие примеры различных частей проектов, выполненных для других заказчиков. Обычно называются следующие клиенты вендора: работающие на том же самом рынке или с той же самой бизнес-моделью; использующие этот же самый продукт или услугу; с такой же технической платформой (существующие или планируемые); аналогичного размера (измеряемого размером годового оборота, числом пользователей, общим числом работников компании и т. д.); с соответствующими географическими данными - число офисов, аналогичная область, страна, язык; с аналогичными объемами продаж или бизнес-партнерами; с аналогичным по масштабу и задачам внедрением продукта; имеющие мнения по вопросам внедрения и дальнейшей работы с продуктом. Хороший способ получить конкретный ответ от вендора по этому пункту - требование заполнить специальную таблицу "Клиенты вендора, имеющие близкие характеристики". 6. Экономика: основные принципы ценообразования продукта (количество пользовательских мест, серверов, модулей и т. д.); стоимость продуктов вендора, которые необходимо закупить для проекта, и приблизительная общая стоимость внедрения; стоимость поддержки и ее опции; стоимость лицензий на продукты, ассоциированные с основным продуктом или необходимые ему, если таковые имеются; расценки на обучение технического персонала и бизнес-пользователей работе в системе; другие профессиональные услуги и консультации, почасовая оплата или другие виды оплат.

RFP-встреча

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

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

Распорядок встречи будет простым. Менеджер команды выбора вендора должен представить членов своей команды и дать короткое описание и пояснение к RFP, уделяя особое внимание ожидаемым преимуществам и критериям отбора. Короткое пояснение, как создавался список вендоров, приглашенных на встречу, тоже может быть уместен.

Затем идет сессия вопросов и ответов. Список заданных вопросов и ответов на них должен быть задокументирован. Если команде задается вопрос, на который пока нет ответа, вопрос документально фиксируется, и ответ на него высылается позже. В некоторых случаях допускается не давать ответа на вопрос. Вся встреча не должна длиться более 90 минут независимо от сложности RFP и числа приглашенных. В течение нескольких дней полный список вопросов и ответов на встрече, а также ответы и дискуссионные вопросы должны быть высланы по электронной почте всем представителям вендоров.

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

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

Оценка ответов на RFP

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

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

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

Таблица. Клиенты вендора, имеющие близкие характеристики.