Проблема начинается с запроса, а не с реализации.
Когда организация обращается к поставщику Salesforce, первый запрос почти всегда звучит как «коммерческое предложение на внедрение». Во многих случаях это неверный запрос. Некоторые организации уже используют систему и нуждаются в диагностике; другие еще не определились с желаемым процессом; третьи имеют удовлетворительно работающую систему, но испытывают недостаток в постоянном сопровождении.
Заказ неверного типа услуги приводит к проекту, результатом которого становится нерелевантный продукт, и зачастую это выясняется только после нескольких месяцев работы. Данное руководство соотносит четыре типа услуг с симптомами, побуждающими организацию искать помощи.
Быстрое сопоставление по симптомам
| Что вы говорите | Что, вероятно, требуется | Основной результат |
|---|---|---|
| «Мы работаем в Excel и хотим навести порядок» | Анализ требований, затем поэтапное внедрение | Карта процессов, модель данных, первый этап в производстве |
| «У нас есть Salesforce, но никто не пользуется» | Проверка состояния (Health Check) и план внедрения | Приоритизированный отчет с выводами и план исправлений |
| «Система медленная и неисправная после многих лет» | Техническая диагностика и план по устранению технического долга | Картирование долга, рекомендация по рефакторингу или перестройке |
| «Проект застопорился на полгода» | Спасение проекта | Оценка состояния, решение о дальнейших действиях, план стабилизации |
| «Нужен кто-то для текущего обслуживания» | Сопровождение или управляемые услуги (Managed Services) | SLA, частота релизов, точка приема запросов |
| «Генеральный директор хочет знать, подходит ли Salesforce» | Краткая консультация, не проект | Экспертное заключение и рекомендация по применимости |
Этой таблицы достаточно для большинства случаев. Остальная часть статьи подробно описывает, что именно следует требовать от каждой услуги.
Услуга 1: Консалтинг и анализ требований
Когда запрашивать: Когда процесс, источник достоверных данных и границы проекта еще не ясны; или когда существуют внутренние разногласия между отделами.
Что обязательно должно быть в результате: Карта процессов на уровне принятия решений, базовая модель данных, модель разрешений, карта систем, критерии приемки и базовые показатели. Результат, который не включает первые пять пунктов, является не анализом требований, а резюме встреч.
Типичный объем: От двух до восьми недель, в зависимости от количества кросс-функциональных процессов. Подробно о том, что именно должно быть получено и как отличить хорошего консультанта, изложено в руководстве по консалтингу Salesforce.
Услуга 2: Разработка и внедрение
Когда запрашивать: Когда анализ требований завершен, владельцы процессов определены и принято решение о содержании первого этапа.
Что обязательно должно быть в соглашении: Определение этапов, критерии приемки для каждого этапа, ответственность за миграцию данных, механизм запросов на изменения, гарантийный период и план передачи знаний. Отсутствие последних двух пунктов является частой причиной долгосрочной зависимости от поставщика.
Предупреждающий знак: Предложение, детально описывающее количество часов разработки, но не уточняющее, что считается «завершенным».
Услуга 3: Проверка состояния (Health Check) и диагностика
Когда запрашивать: Когда система функционирует, но что-то не работает — низкий уровень внедрения, ненадежные данные, проблемы с производительностью или невозможность внесения изменений без нарушений.
Что обязательно должно быть в результате: Список выявленных проблем с указанием серьезности, влияния на бизнес, усилий по исправлению и рекомендуемой последовательности. Отчет, перечисляющий пятьдесят проблем без их приоритизации, бесполезен; отчет, который гласит «сначала исправьте эти три, а остальные пока не трогайте», является ценным продуктом.
Важное отличие: Проверка состояния (Health Check) не является проектом по исправлению. Она предназначена для принятия решения о том, что и в какой последовательности исправлять.
Услуга 4: Сопровождение, поддержка и управляемые услуги (Managed Services)
Когда запрашивать: Когда система введена в эксплуатацию и отсутствует внутренняя команда, способная обеспечить текущее обслуживание.
Что обязательно должно быть определено: Что включено, а что нет. Критическое различие проводится между устранением ошибки, небольшим изменением конфигурации и разработкой новой функциональности. Договор, объединяющий все три в «банк часов», как правило, исчерпывается в течение квартала, поскольку разработка новой функциональности поглощает часы, предназначенные для поддержки.
Дополнительно: Время реакции в зависимости от серьезности, регулярные циклы выпусков и принадлежность документации.
Правильное сочетание услуг
Большинство организаций потребляют не одну услугу, а цепочку. Здоровая последовательность выглядит так:
- Краткая консультация для принятия решения о применимости — дни, а не недели.
- Целенаправленный анализ требований для первого этапа.
- Поэтапное внедрение.
- Определенный период стабилизации после запуска.
- Текущее сопровождение.
- Периодическая проверка состояния (Health Check), предпочтительно не тем, кто строил.
Шестой пункт чаще всего пропускают, хотя он является наименее затратным.
Пример для иллюстрации: Сеть бутик-отелей
Этот сценарий является гипотетическим и предназначен для иллюстрации. Сеть из четырех отелей обратилась к трем поставщикам с запросом на коммерческое предложение по внедрению Salesforce для управления мероприятиями и запросами гостей. Первые два предложения представляли собой полномасштабное внедрение на многие месяцы.
Третий поставщик задал один вопрос: кто определяет, что такое «событие» — менеджер по мероприятиям в каждом отеле или штаб-квартира. Ответ был, что общего определения нет. В такой ситуации полномасштабное внедрение привело бы к созданию четырех различных систем под одним названием. Вместо этого сеть заказала краткий анализ требований, получила одно согласованное определение и модель данных, и только затем приступила к внедрению — с меньшим объемом, чем было предложено изначально.
Признаки, предупреждающие при заказе услуги
- Предложение оценивает часы, но не определяет результат.
- То же предложение включает анализ требований и внедрение одной суммой без контрольной точки, позволяющей остановиться.
- Отсутствует определенный гарантийный период после сдачи.
- Отсутствует пункт о передаче знаний и документации в собственность организации.
- Поставщик отказывается предоставить архитектурное заключение до подписания.
Инструменты для проверки самого поставщика — а не только услуги — собраны в руководстве по выбору компании-интегратора Salesforce.
От запроса к документу
После определения необходимой услуги следующим шагом является ее формулирование таким образом, чтобы полученные предложения были сопоставимы. Структура документа запроса и список вопросов, которые стоит включить, подробно изложены в руководстве по RFP для внедрения Salesforce, а пункты, которые должны войти в само соглашение, детализированы в руководстве по контракту и SOW.
Следующий шаг
Прежде чем запрашивать коммерческое предложение, сформулируйте одним предложением симптом — а не решение. «У нас нет единой картины клиента между продажами и обслуживанием» приводит к иному запросу, чем «мы хотим Salesforce». Это предложение ценнее любого документа с требованиями, который будет написан после него.