Что должен содержать качественный запрос предложений (RFP)
Цель RFP – не просто получить цену. Его задача — получить сравнимые коммерческие предложения и выявить, какой поставщик лучше всего понял проблему. Документ, перечисляющий сто требований и запрашивающий отметки «поддерживается / не поддерживается», достигает обратного эффекта: все поставщики отмечают «поддерживается», и в итоге решение сводится к цене.
Практическое отличие: вместо того чтобы писать «Система должна поддерживать управление возможностями», опишите, что компания обрабатывает около четырехсот сделок в месяц, что каждая сделка проходит утверждение по ценообразованию, и что утверждение в настоящее время осуществляется по электронной почте. Поставщики предоставят совершенно разные ответы — и именно в этом суть.
Девять разделов RFP для Salesforce
1. Контекст и бизнес-цель. Чем занимается организация, в чем заключается проблема, и что будет считаться успехом через год. От абзаца до одной страницы.
2. Текущее состояние. Используемые системы, количество пользователей, что работает, а что нет. Если существует среда Salesforce, укажите редакцию, срок использования и уровень кастомизации.
3. Ключевые процессы. От трех до семи процессов, каждый в отдельном абзаце: кто выполняет, каковы точки принятия решений, что происходит в случае отклонений.
4. Объемы и данные. Количество записей в каждой основной сущности, ежемесячная скорость создания, годы истории, которые необходимо сохранить, и известное состояние качества данных. Это наиболее важный раздел для точного ценообразования, который зачастую упускают из виду.
5. Интеграции. Для каждой системы: название, тип интерфейса (если известен), направление, требуемая частота и ответственный в организации.
6. Ограничения. Регулирование, информационная безопасность, место хранения данных, языки, доступность, неизменяемые сроки.
7. Требования к поставщику. Предлагаемый подход, план этапов, состав команды с именами и ролями, допущения, риски и ценообразование согласно фиксированной структуре.
8. Метод оценки. Критерии и их веса, опубликованные заранее. Это обеспечивает целенаправленные предложения и снижает количество споров после выбора победителя.
9. График тендера. Срок для вопросов, срок для ответов, срок подачи предложений, срок демонстраций, срок принятия решения.
Данные, которые необходимо раскрыть для получения реальной оценки
| Данные | Почему это критично | Что происходит без них |
|---|---|---|
| Количество пользователей по типу | Определяет лицензирование, обучение и разрешения | Предложения слишком широкого диапазона |
| Объем записей и история | Определяет усилия по миграции | Миграция оценивается грубо |
| Количество систем-источников | Определяет сложность и интеграцию | Неприятные сюрпризы после подписания |
| Уровень существующей документации | Определяет объем требуемого анализа | Поставщики предполагают наличие документации |
| Доступность владельцев процессов | Определяет скорость принятия решений | Нереалистичный график, согласованный обеими сторонами |
| Бюджет или диапазон | Уточняет решение | Несравнимые предложения |
Вопросы, которые позволяют отличить поставщиков
Следующие вопросы вызывают совершенно разные ответы от разных поставщиков, поэтому они полезны. Вопрос, на который все отвечают одинаково, не стоит включать в документ.
- Каковы три ключевых допущения, на которых основано предложение, и каковы последствия, если одно из них ошибочно?
- В каких случаях вы бы порекомендовали конфигурацию, даже если разработка кажется более эффективной, и наоборот?
- Опишите проект, в котором вы вышли за рамки графика. Что послужило причиной, и что вы изменили с тех пор?
- Кто будут непосредственными членами команды, и какую долю времени каждый из них посвятит конкретно этому проекту?
- Что вам нужно от нас для успеха, и что вы будете делать, если не получите это?
- Как вы обеспечите нашу способность самостоятельно поддерживать систему?
Последний вопрос является хорошей проверкой характера взаимодействия. Поставщик, который уклоняется от ответа, планирует создать зависимость.
Что необходимо запросить в качестве результатов в предложении
- Предварительная архитектурная схема на уровне блоков, включая источники истинности.
- План этапов с описанием содержания каждого этапа, а не только дат.
- Детализированное ценообразование в единой структуре, которую вы диктуете, по этапам и ролям.
- Явный список допущений.
- Карта рисков со способами их устранения.
- Пример реального результата из предыдущего проекта, с анонимизированными именами — например, документ с решениями или план тестирования.
Последний пункт, пожалуй, самый показательный, поскольку он демонстрирует стандарт работы, а не обещание.
Единая структура ценообразования — инструмент, предотвращающий сравнение несравнимого
Определите таблицу, которую должен заполнить каждый участник:
| Этап | Часы старшего специалиста | Часы младшего специалиста | Стоимость | Что считается завершенным |
|---|---|---|---|---|
| Анализ требований | ||||
| Конфигурация и разработка для этапа 1 | ||||
| Интеграции | ||||
| Миграция данных | ||||
| Тестирование и UAT | ||||
| Обучение и внедрение | ||||
| Стабилизация после запуска | ||||
| Управление проектом |
Поставщик, отказывающийся разбить цену в соответствии с этой структурой, не обязательно дороже — но его невозможно сравнивать, и это достаточная причина, чтобы повторно запросить у него информацию.
Пример для иллюстрации: средний пенсионный фонд
Гипотетический сценарий предназначен для иллюстрации. Финансовая организация выпустила RFP, который включал восемьдесят функциональных требований в табличной форме. Четыре участника отметили «поддерживается» почти в каждой строке, и предложения различались только ценой и количеством часов.
Во втором раунде документ был изменен: вместо таблицы требований были включены три полностью описанных процесса, реальные объемы данных и запрос на решение одного сценария в ходе демонстрации. Полученные предложения существенно отличались друг от друга — одно предлагало абсолютно иную модель данных, другое выявило зависимость от регуляторного одобрения, о котором никто не думал.
Комиссия не выбрала самое дешевое предложение и не ошиблась. Она выбрала то, которое смогло объяснить, почему седьмое требование в исходном документе совершенно не нужно.
Распространенные ошибки при составлении RFP
- Копирование документа из другого проекта без адаптации объемов и процессов.
- Требование списка клиентов вместо примеров результатов.
- Критерии оценки, сформулированные после получения предложений.
- График, не оставляющий времени для вопросов и ответов.
- Скрытое предпочтение существующему поставщику, что вынуждает других тратить ресурсы впустую и негативно влияет на качество будущих предложений.
Что происходит после подачи
Хороший документ — это только половина работы. Следующий шаг — нормализация предложений и их сравнение на единой основе, как описано в руководстве по сравнению предложений Salesforce, а затем структурированная оценка по заранее определенным весам, как изложено в руководстве по оценочной карте для выбора поставщика.
Информационная база для составления самого документа часто формируется в процессе краткосрочного консультирования, как описано в руководстве по консалтингу Salesforce, а критерии для проверки компании собраны в руководстве по выбору компании-интегратора.
Следующий шаг
Прежде чем отправить документ, проведите одну проверку: дайте его прочитать кому-то в вашей организации, кто не участвует в проекте, и попросите его одним предложением объяснить, какую проблему вы пытаетесь решить. Если он не сможет, то и поставщики не смогут — а они просто вернут то, что они привыкли продавать.