Краткий обзор
Перевод CRM-системы на Salesforce — это не просто технический проект по «переносу данных». Это организационное решение о том, что следует сохранить, от чего отказаться и как организовать операционную деятельность компании во время перехода. Самая распространенная ошибка заключается не в некорректной настройке Salesforce, а в негласном предположении, что все содержимое старой системы должно быть перенесено в неизменном виде.
Правильный подход начинается с картирования процессов, а не с экспорта таблиц. Затем создается новая модель данных, соответствующая текущей работе организации, а не структуре, установленной десять лет назад в другой системе. Контролируемый период параллельной работы и, наконец, упорядоченное отключение старой системы с документацией для соблюдения нормативных требований завершают процесс.
Организации, сталкивающиеся с этими вопросами, могут найти дополнительную информацию в статье Внедрение Salesforce в организации, где подробно описан комплексный процесс принятия решений в проекте Salesforce.
Картирование существующих процессов: не экспорт, а понимание
Первый шаг при переходе между CRM-системами — не экспорт данных, а взаимодействие с владельцами процессов для понимания того, что на самом деле происходит от момента генерации лида до закрытия сделки, или от получения запроса до закрытия сервисного инцидента. Старый документ с описанием процессов, если он вообще существует, почти всегда устарел по отношению к реальной деятельности.
В процессе картирования следует документировать не только формальные шаги, но и «теневые процессы» — параллельные таблицы Excel, незаполняемые поля, утверждения, передаваемые через мессенджеры вместо системы. Именно в этих областях новая система, даже если она построена правильно, терпит неудачу во внедрении, если эти аспекты не учтены.
Результат картирования должен включать таблицу основных процессов, их владельца, частоту использования и степень зависимости от старой системы. Процесс, выполняемый раз в квартал и генерирующий критически важный отчет для регулятора, требует иного подхода, чем высокочастотный ежедневный процесс. Такое разделение также определяет порядок миграции и необходимый уровень тестирования для каждого процесса.
Что не переносить: решение, экономящее половину работы
Одно из наиболее значимых решений в проекте миграции CRM — это не что переносить, а что не переносить. Большинство устаревших систем, накапливавшихся годами, содержат слои дублирующихся полей, устаревших статусов и процессов, которые были определены для одноразового проекта, который уже завершен.
Практическое правило: любой объект или поле, к которым никто не обращался в течение последних двух лет, по умолчанию переходит в список «не переносить», если только конкретный владелец процесса не запросит обоснованное исключение. Этот список формируется на основе журналов фактического использования в старой системе, а не по воспоминаниям пользователей, поскольку человеческая память часто описывает систему такой, какой она должна была работать, а не такой, какой она работает на самом деле.
Важно различать три категории информации:
- Актуальная информация — должна быть перенесена в новую систему как активная запись со всеми ее связями.
- Актуальная историческая информация — переносится как архив для просмотра, как правило, без необходимости редактирования или автоматизации.
- Устаревшая информация — не переносится совсем, сохраняется только во внешней резервной копии на случай аудита.
Расширенное описание управления границами между этапами планирования и построения представлено в статье Расползание объема работ в Salesforce, поскольку тенденция добавлять «еще немного старых данных» является одним из самых распространенных источников расползания объема работ в подобных проектах.
Новая модель данных против старой: не перевод, а проектирование
Распространенная ошибка — подходить к модели данных как к переводу 1:1: каждая таблица в старой системе становится объектом в Salesforce, каждый столбец — полем. Такой подход сохраняет все недостатки старой системы на новой платформе и упускает ключевое преимущество Salesforce: возможность строить гибкие отношения между объектами, встроенную автоматизацию и богатый слой разрешений.
Сравнение двух основных подходов к миграции помогает принять осознанное решение:
| Аспект | Метод «Lift-and-Shift» (перенос как есть) | Метод «Redesign» (перепроектирование) |
|---|---|---|
| Время проекта | Относительно короткое, обычно 6-10 недель | Более длительное, обычно 3-5 месяцев |
| Соответствие бизнес-процессам | Низкое — сохраняет старые ограничения | Высокое — строится вокруг текущего процесса |
| Риск технического долга | Высокий, проявляется через год-два | Ниже, поскольку структура спроектирована заранее |
| Будущие затраты на поддержку | Со временем увеличиваются | Относительно стабильны |
| Подходит для | Организаций с экстремально сжатыми сроками или очень ограниченным объемом работ | Большинства организаций, переходящих со системы старше трех лет |
| Основной риск | «Новая система, старые проблемы» | Отклонение от графика, если объем работ не ограничен |
На практике большинство организаций выбирают промежуточный подход: перепроектирование для основной модели (учетные записи, контакты, возможности или сервисные инциденты) и контролируемый перенос как есть для второстепенных сущностей, которые не оказывают существенного влияния на процессы. Это решение должно быть явно принято на этапе планирования, а не возникать случайно в процессе построения.
Период параллельной работы: как обеспечить непрерывность бизнеса
Период параллельной работы — это временной интервал, в течение которого обе системы функционируют одновременно — обычно от четырех до восьми недель. Его цель — выявить расхождения в реальном времени, прежде чем они станут необратимой проблемой. Заключенная сделка, открытый сервисный запрос или сформированный отчет о комиссионных — все это должно проверяться параллельно в обеих системах и показывать одинаковый или объяснимый результат.
Вопрос, который возникает почти в каждом проекте: какая система считается «источником истины» в этот период? Ответ должен быть единственный и заранее определенный, как правило, Salesforce с первого дня, когда старая система используется только для проверки, а не для текущей работы. Двойная работа пользователей в двух системах — это путь к усталости и фактическому отказу от новой системы.
Практические инструменты для управления этим периодом:
- Ежедневный или еженедельный сравнительный отчет по ключевым данным в обеих системах (количество лидов, сумма сделок, открытые запросы).
- Актуальный список исключений, который обновляется при выявлении расхождений, с ответственным лицом (Owner), которое обязуется устранить его в течение определенного срока.
- Группа «ключевых пользователей» из каждого отдела, которая ежедневно сообщает об ошибках использования, а не только о технических сбоях.
Большая часть полученных в этот период данных актуальна и для формализованного процесса тестирования, подробно описанного в Руководстве по UAT для Salesforce, а также для периода после запуска, описанного в Плане Hypercare для Salesforce.
Отключение старой системы: не одноразовое событие, а последовательность решений
Отключение старой системы происходит поэтапно, а не нажатием одной кнопки в день перехода (Cutover). Основное правило: система отключается от текущей работы сразу после Go Live, но остается доступной только для чтения на короткий льготный период, обычно 30-60 дней, на случай обнаружения недостающих данных или вопросов от финансового отдела.
Контрольный список для решения о переходе (Cutover)
Прежде чем официально объявить об отключении старой системы, убедитесь, что:
- ☐ Все отчеты, регулярно генерируемые старой системой, успешно воспроизведены из Salesforce или из архива.
- ☐ Завершен один полный бизнес-цикл (например, полный месяц закрытия), полностью в новой системе.
- ☐ Разница в данных между системами опустилась ниже заранее определенного порога (например, менее 1% записей).
- ☐ Имеется письменное подтверждение от юридического или финансового отдела, что архив соответствует требованиям по хранению.
- ☐ Определен ответственный за доступ только для чтения в течение льготного периода и дата его окончательного закрытия.
- ☐ Выполнено полное и проверенное резервное копирование всех данных старой системы перед отменой лицензии.
- ☐ Отправлено уведомление всем владельцам процессов о дате окончательного отключения и способе доступа к архиву.
Пропуск любого из этих пунктов является наиболее частой причиной того, что через несколько месяцев после проекта обнаруживается отсутствие доступа к информации, которая внезапно понадобилась для налоговой проверки или судебного разбирательства.
Архив и регулирование: что необходимо хранить и как долго
Требования к хранению информации варьируются в зависимости от отрасли, но почти всегда существует обязанность хранить финансовые, договорные данные или данные, связанные с жалобами клиентов, в течение семи лет, а иногда и дольше. Распространенная ошибка — пытаться «загрузить» всю эту историю в Salesforce как активные записи, что замедляет производительность и сбивает с толку пользователей, которые видят сделки десятилетней давности в своих ежедневных списках.
Принятым решением является разделение на два уровня:
| Уровень | Содержание | Место хранения | Доступность |
|---|---|---|---|
| Актуальная операционная информация | Последние 24-36 месяцев | Salesforce | Полный, включая редактирование и автоматизацию |
| Регуляторный архив | Полная история в соответствии с законодательством | Внешнее хранилище данных или Salesforce Archive | Только для чтения, с возможностью поиска |
Важно задокументировать политику архивирования в письменной форме и получить одобрение от юридического лица перед отменой доступа к старой системе, так как после отмены лицензии пути назад нет, если обнаружится, что данные отсутствуют.
Пример организационного сценария
Финансовая компания перешла с 12-летней локальной CRM-системы на Salesforce. На этапе картирования команда определила, что около 40% существующих полей не использовались более двух лет, и решила не переносить их. Это сэкономило около месяца работы по построению и тестированию.
В период параллельной работы, который длился шесть недель, было обнаружено расхождение в расчете комиссионных, вызванное разницей в округлении чисел между системами — ошибка, которая не была бы выявлена без ежедневного сравнительного отчета. Команда исправила формулу до того, как она повлияла на реальные платежные ведомости. Старая система была отключена от текущей работы в день Go Live, но доступ только для чтения сохранялся еще 45 дней для проверки квартального отчета, который уже находился в процессе.
Результат: в течение трех месяцев после окончательного отключения дополнительный доступ к старой системе не понадобился, а экономия на затратах на лицензирование покрыла значительную часть стоимости самого проекта миграции.
Распространенные риски и превентивные меры
| Риск | Как это проявляется на практике | Превентивные меры |
|---|---|---|
| Перенос «всего» без фильтрации | Новая система перегружена мертвыми данными и замедляет внедрение | Определить критерий фильтрации по фактическому использованию за последние два года |
| Скопированная модель данных | Те же ограничения старой системы повторяются в Salesforce | Разработать новую модель, основанную на актуальном процессе, а не на старых таблицах |
| Параллельная работа без ответственного | Расхождения между системами выявляются с опозданием или не выявляются вовсе | Регулярный сравнительный отчет с назначенным ответственным за каждое отклонение |
| Слишком поспешное отключение | Обнаружение отсутствующих данных после отмены лицензии | Льготный период доступа только для чтения перед окончательной отменой |
| Игнорирование требований к архиву | Регуляторная проверка выявляет, что требуемая информация не была сохранена должным образом | Получить письменное одобрение от юридического отдела на политику архивирования перед переходом (Cutover) |
Как измерить успех миграции
| Область | Что измерять | Частота проверки |
|---|---|---|
| Полнота данных | Доля записей, успешно перенесенных без ошибок | До и после каждого запуска миграции |
| Соответствие между системами | Расхождения в ключевых отчетах между старой и новой | Ежедневно в период параллельной работы |
| Адаптация пользователей | Уровень работы в новой системе по сравнению с возвратом к старой | Еженедельно в первый месяц |
| Операционные затраты | Экономия на лицензиях и поддержке после отключения | Ежемесячно, начиная через три месяца после Go Live |
Для замены CRM-системы на Salesforce следует заранее выбрать от трех до пяти ключевых показателей и измерять их как до, так и после проекта — в противном случае сложно доказать, что переход действительно улучшил процесс, а не просто перенес его на другую платформу. Фактическое выполнение такого процесса может быть осуществлено при поддержке службы внедрения Salesforce, которая сопровождает организации от этапа картирования до отключения старой системы.
Профессиональные ресурсы
- Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
- HPI Pro – Внедрение Salesforce — https://hpi.pro/salesforce-implementation
- HPI Pro – Методология работы — https://hpi.pro/methodology