Краткий вывод

Предложения от различных интеграторов Salesforce практически всегда выглядят одинаково: те же слова, такие как Discovery (выявление требований), Agile (гибкая методология), Best Practice (лучшие практики), и то же обещание «тесного сопровождения». Истинная разница выявляется только при сравнении каждого предложения с конкретными вопросами, которые раскрывают подход поставщика, а не только то, что он предлагает поставить. Цель этих 15 вопросов — выявить расхождения до подписания договора, а не после того, как проект уже застрял.

Вопросы разделены на шесть тем: команда, методология, архитектура, данные, коммерческие условия и непрерывность. К каждому вопросу прилагается краткое объяснение его важности и описание того, как звучит слабый ответ — чтобы его было легко распознать в реальном времени, на встрече или в документе предложения.

Практические последствия выбора для всего процесса внедрения мы подробно описали отдельно в разделе Компания по внедрению Salesforce.

Почему 15 вопросов, а не список технических требований

Список технических требований — количество песочниц (Sandbox), какие лицензии, сроки SLA — важен, но недостаточен. Он проверяет, что поставщик обещает сделать, а не как он будет справляться с ситуацией, когда первоначальный план окажется неточным. Вопросы здесь выбраны потому, что они раскрывают рабочие паттерны: как команда документирует решения, как она справляется с "грязными" данными и что происходит, когда что-то идет не по плану.

Сводная таблица: сильный ответ против слабого ответа

ТемаСильный ответ звучит такСлабый ответ звучит так
Команда"Консультант X руководит архитектурой, разработчик Y выполняет, предоставим резюме и возможность короткого собеседования""У нас опытная команда, назначим подходящих во время Kickoff"
Методология"Двухнедельные спринты, реальное демо в конце каждого спринта, общий бэклог в Jira""Мы работаем по Agile, это гибко и подходит для любого проекта"
Архитектура"Будем формировать ADR для каждого ключевого решения, включая отвергнутые альтернативы и причины отказа""Выберем лучшее решение, исходя из нашего опыта"
Данные"Проведем профилирование данных перед окончательным предложением, оценим качество источников""Будем заниматься очисткой данных в процессе разработки"
Коммерческий"Фиксированная цена за определенный объем работ, дополнительные часы по документированному запросу на изменение""Гибкий T&M, чтобы вас не ограничивать"
Непрерывность"Документ о передаче, обучение внутреннего администратора, две недели Hypercare после Go Live""Мы всегда рядом с вами, протокол прощания не нужен"

Команда: кто фактически будет работать над проектом

1. Кто будет фактически сопровождать проект, а не только на этапе предложения

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

2. Сколько параллельных проектов ведет каждый консультант в то же время

Консультант, ведущий пять проектов одновременно, не может уделять внимание деталям. Сильный ответ признает это ограничение и представит разумное число (обычно два-три проекта). Слабый ответ уклоняется или отвечает "зависит от нагрузки", без конкретного числа.

3. Что произойдет, если ведущий консультант уйдет посреди проекта

Сильный ответ описывает документированный процесс передачи, две недели на совместную работу (Overlap) и постоянное документирование, которое позволяет замещать без потери знаний. Слабый ответ утверждает, что "у нас это почти не происходит" без плана на случай непредвиденных обстоятельств. Подробнее о правильной структуре работы с консультантом Salesforce.

Методология: как фактически организуется работа

4. Как выглядит типичный спринт — что происходит, если что-то не готово вовремя

Сильный ответ описывает Sprint Planning (планирование спринта), короткие Daily (ежедневные встречи), Demo (демонстрации) и ретроспективу, а также что происходит, если задача застревает — откладывается ли она на следующий спринт прозрачно. Слабый ответ ограничивается "мы работаем по Agile" без упоминания конкретных практик.

5. Как выглядит регулярное общение — канал, частота и ответственный

Сильный ответ детализирует канал (Slack, Teams), еженедельную фиксированную встречу по статусу и единое контактное лицо для эскалации. Слабый ответ гласит "мы всегда будем доступны по электронной почте", что на практике означает отсутствие SLA на ответ.

6. Как проверяется работа, прежде чем она представляется клиенту как готовая

Сильный ответ описывает внутреннее тестирование качества (QA), контрольный список приемки и проверку доступности и разрешений перед демонстрацией. Слабый ответ косвенно признает, что первая демонстрация клиенту является также и первой проверкой.

Архитектура: как принимаются решения

7. Как документируются архитектурные решения и кто их утверждает

Сильный ответ представляет краткий шаблон решения — проблема, альтернативы, выбор и причина — который сохраняется и доступен клиенту. Слабый ответ гласит "мы выбираем правильное решение" без документирования причин отказа от других альтернатив.

8. Как решение будет справляться с нагрузкой и ростом через два-три года

Сильный ответ учитывает ограничения Governor Limits, ожидаемый объем данных и планирование расширения. Слабый ответ гласит "Salesforce масштабируема по своей природе" без связи этого с конкретным случаем.

9. Что происходит, когда новое требование конфликтует с предыдущим решением

Сильный ответ описывает процесс Change Request (запроса на изменение), который оценивает влияние на уже построенное. Слабый ответ просто обещает "мы адаптируемся к любым изменениям", что чаще всего заканчивается накоплением скрытого технического долга.

Данные: место, где большинство проектов застревают

10. Как проверяется качество данных до начала построения

Сильный ответ включает ранний этап профилирования — дубликаты, пустые поля, несовместимые форматы — и график исправления. Слабый ответ откладывает это на "мы разберемся с этим во время миграции", что почти всегда удлиняет проект.

11. Что является источником истины для каждого типа данных и как обрабатываются дубликаты между системами

Сильный ответ заранее определяет, какие системы "побеждают" при противоречиях (например, ERP против Salesforce для существующего клиента) и документирует правило. Слабый ответ гласит "Salesforce будет источником истины" в общем виде, не проверяя, верно ли это для каждого объекта.

12. Каков план резервного копирования и восстановления, и кто отвечает за него после внедрения

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

Коммерческие условия и непрерывность: что происходит после подписания

13. Как формируется цена — фиксированная, T&M или комбинированная, и что фактически включено

Сильный ответ разбивает цену на этапы работ с примерными часами для каждого, и определяет, что считается запросом на изменение (Change Request) за дополнительную плату. Слабый ответ дает одно общее число без разбивки, что затрудняет сравнение предложений.

14. Что произойдет, если проект выходит за рамки сроков — кто несет затраты

Сильный ответ различает превышение сроков, вызванное поставщиком (за его счет), и превышение сроков, вызванное изменением требований клиента (за плату). Слабый ответ формулируется неопределенно, что позволяет поставщику переложить любую задержку на клиента.

15. Что происходит по завершении проекта — какая поддержка, на какой срок и по какому тарифу

Сильный ответ включает определенный период Hypercare (обычно две-четыре недели), документ о передаче и обучение внутреннего администратора. Слабый ответ обещает "постоянную поддержку" без четкого тарифа, объема или даты окончания. Подробнее о правильной формулировке таких пунктов договора в SOW проекта Salesforce.

Пример организационного сценария

Финансовая компания получила три предложения по объединению двух старых CRM-систем в одну Salesforce. Два из предложений были на 20-25% дешевле третьего. Когда CIO задал вопрос 10 (ранняя проверка качества данных), два более дешевых поставщика ответили: "мы разберемся с этим в рамках миграции" – тогда как более дорогой поставщик представил недельный план профилирования до подписания окончательной суммы.

Организация выбрала более дорогого поставщика. Неделя профилирования выявила около 12 000 дубликатов записей и поле даты с несовместимым форматом в 3 источниках данных. Это раннее исправление было включено в первоначальную стоимость; у двух других поставщиков это обнаружилось бы во время миграции, как изменение объема работ с дополнительной оплатой.

Урок здесь не в том, что "дешевое всегда плохо" — а в том, что разница между подробным и общим ответом стоит реальных денег, и ее можно выявить только с помощью целенаправленных вопросов до подписания, а не после.

Контрольный список для сравнения предложений

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

Завершающее замечание: вопросы — это инструмент, а не ритуал

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

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

Профессиональные источники