Миграция из PipeDrive в amoCRM. Плавали, знаем
О процессе рассказал Константин Кузнецов из RocketSales.
Качественная миграция CRM-системы — это когда пользователь пришёл утром, открыл новую программу, а работать продолжил, как и раньше. Естественно, с учётом новых возможностей, иначе зачем тогда делать миграцию. У пользователя не должно возникать вопросов о функциях новой системы, и он не должен постоянно заглядывать в предыдущую CRM-систему, чтобы проверить историю клиента.
Простым экспортом или импортом здесь не обойтись.Таким способом получится загрузить только контактные данные и некоторые значения полей. А работа прекращаться не должна.
Необходимо повторить все бизнес-процессы, скопировать сущности, воспроизвести схемы соподчинённости. Для этого должен быть чёткий алгоритм действий.
Ниже мы расскажем, как сделали миграцию для компании RetailRocket, — они занимаются автоматизацией ecommerce-маркетинга по всему миру.
RetailRocket долго работали на Pipedrive, долго искали замену, пробовали Freshoffice, возвращались в Pipe, чтобы в итоге решиться на amoCRM.
Сразу укажу, что миграция проводилась нами в рамках комплексной перенастройки всей учётной системы. Например, компания переходила на корпоративный G Suite, а, соответственно, менялась и «экосистема» — новые электронные ящики, учёт документов и так далее.
Почему мигрировали с Pipedrive на amoCRM
Несмотря на то, что Pipedrive появилась раньше, по сравнению с amoCRM её функциональность беднее и содержит ряд ограничений, которые оказались критичны для заказчика.
- Функция обязательных полей. Вероятно, каждая компания сталкивается с проблемой некачественного учёта данных. В amoCRM это решается настройкой обязательных полей, которые не дают двигать сделку по воронке, если менеджер забыл их заполнить. Pipedrive таким похвастаться не может.
- Интеграция с телефонией. К сожалению, это ещё одна слабая сторона Pipedrive. Даже если нажать на контактный телефон в карточке контакта, он сработает как обычная ссылка и отправит на софтфон. Не говоря уже о записи разговоров и их учёте в истории сделок.
- Кастомные доработки. В этом с amoCRM мало кто посоревнуется вообще. Если хотите адаптировать CRM под свой бизнес-процесс, добавить модуль, интегрировать со сторонним сервисом, то вам сюда.
- Цена. По соотношению цена-функциональность PipeDrive тоже проигрывает. Элементарная синхронизация электронной почты доступна только с тарифа 25 $ за пользователя в месяц. Это почти в полтора раза дороже amoCRM со всеми возможностями для интеграций. Кстати, синхронизация почты была одной из болей заказчика. Письма приходилось вручную прикреплять к каждой сделке.
Процесс миграции облегчал тот факт, что, несмотря на ряд существенных отличий, Pipedrive и amoCRM очень похожи. Та же логика работы, очень близкие интерфейсы, линейные бизнес-процессы. Сущности Pipedrive фактически аналогичны сущностям amoCRM и в большинстве случаев повторяют схему взаимосвязи. Это хорошо, потому что копирование сущностей — основной процесс в миграции.
|
Сущности Pipedrive | Сущности amoCRM |
|
---|---|---|---|
|
User (Пользователь) | Пользователь |
|
|
Pipeline (Воронка) | Воронка |
|
|
Deal (Сделка) | Сделка |
|
|
Company (Организация) | Компания |
|
|
People (Люди) | Контакты |
|
|
Participant (Участник) | Нет |
|
|
Follower (Подписчик) | Нет |
|
|
Activity (Задача) | Задача |
|
|
Note (Заметка) | Примечание |
|
|
Email (Письмо) | Письмо |
|
Но возникает три несовпадения.
- Participant (Участник) в Pipedrive выполняет роль дополнительного контакта, который не связан с основной компанией сделки (например, контакт субподрядчика, то есть не основного контакта по сделке). В amoCRM отдельной сущности с такой функцией нет. В принципе, не проблема. Создаём как обычные контакты и линкуем к сделкам.
- Follower, он же подписчик — довольно важная функция. Особенно для управления отделом продаж. Например, руководство может видеть все обновления по сделкам, просто подписавшись на них (как в Facebook — даже панель уведомлений такая же). Такой возможности в Amo, опять же, нет. С её отсутствием заказчику придется смириться и искать другие варианты контроля.
- Наконец, самое проблемное — письма. Из-за того что у пользователей изменились электронные ящики, подтянуть всю историю переписок в новые сделки возможности нет, а значит, нет и возможности прикрепить письма как сущности в новую CRM. Поэтому мы решили сделать так: вытянем содержание писем из Pipedrive, с атрибутами взаимосвязи и времени, и просто прикрепим к сущностям amoCRM в виде заметок. В результате вся история переписки сохраняется, что и является целевым результатом. (По идее, если не менять электронные адреса, старые письма должны автоматически подтянуться в новую CRM. В нашем кейсе возможности проверить не было, так как адреса менялись на новые, поэтому если у вас есть опыт — напишите в комментариях).
Приступаем к миграции
Для начала создаём в новой CRM копии воронок продаж и всех пользователей. Их не так много, поэтому можно сделать это вручную. Нам сразу понадобятся их ID, чтобы сделать линковку по аналогии со старой системой.
Права пользователей также повторяем вручную. В Pipedrive права настраиваются через общую панель, а в amoCRM — для каждого пользователя отдельно.
Здесь только разница интерфейсов: можно добиться тех же самых настроек.
Теперь переходим к самой миграции. Есть два варианта. Условно назовем их «параллельный» и «последовательный».
Параллельный будет заключается в том, что мы сначала создаём копии всех массивов сущностей, а потом проверяем каждую на связь с другими и повторяем эту связь.
Суть последовательного в том, что мы создаём одну сущность из старой базы, а потом сразу за ней, как за нитку, вытягиваем все связанные сущности и создаём их следом. Тогда каждый следующий элемент должен при создании проверять, нет ли уже связанной другой сущности, которая вытянулась за предыдущими.
Здесь главным фактором стало ограничение на частоту запросов по API к amoCRM — только 1 запрос в секунду.
Если работать по параллельной схеме, то придётся по каждой сущности отправлять запрос дважды: первый раз, когда создаём его, а второй — когда обновляем линковку. Поэтому весь процесс занял бы намного больше времени.
Вторая причина — последовательная схема позволяет делать паузы в процессе и продолжать с этого же места.
Ещё причина — естественное «очищение» системы. При параллельном мы бездумно копируем все сущности без разбора, даже если они мёртвые. Последовательная схема вытягивает только те данные, которые задействованы в работе с другими сущностями, а, следовательно, более релевантные.
Также для ускорения процесса и подстраховки мы делаем бэкап выгружаемой базы на своей стороне. Зачем? Сущности из разных массивов могут быть связаны с несколькими элементами. Например, к разным сделкам может относиться один и тот же контакт. Поэтому важно проверять при выгрузке очередной сделки, не выгружался ли уже слинкованный с ней контакт. Чтобы не отправлять запрос проверки на сторону amoCRM, мы проверяем это в нашем бэкапе и уже тогда решаем, нужно ли создавать элемент.
По сути, всё готово, и остаётся выбрать схему, по которой будут вытягиваться из Pipedrive и создаваться в amoCRM сущности. Очень важно, чтобы сохранялась логика соподчинённости сущностей, и процесс шёл от меньших массивов к большим. В этом случае мы всегда передаём элемент с его «наполнением» и не переживаем, что пропустили какую-то взаимосвязь.
Схема подчинённости следующая:
Воронка → Сделка → Компания → Контакт → Задача/Заметка
Воронки мы уже создали, поэтому будем начинать со сделок. Создаётся сделка и сразу цепляется к воронке по ID, проставляется связанный сотрудник (ответственный менеджер). Сюда же проставляются статус воронки (его берём из простого сопоставленного массива), даты создания и последних изменений.
С полем бюджета вышла небольшая проблема. Она не техническая: на согласования потратили много. Дело в том, что Pipedrive поддерживает несколько валют в одном аккаунте, то есть разные сделки могут быть в разных валютах. В amo с этим грустнее — можно задать только одну валюту для аккаунта.
Ок, все бюджеты переведём в доллары и создадим кастомные поля, в которых будет автоматически пересчитываться в рубли и евро. Вот пока решали, по какому курсу будет пересчитываться, время и потеряли. Мы предложили сложную схему, когда ежедневно официальный курс будет автоматически парситься и подставляться в функцию, а пересчёт будет актуален. Но заказчик сказал, что будем пересчитывать по округлённому курсу на момент миграции. Что ж, это даже проще. В общем, бюджет сделок пересчитывается в единую валюту и тоже записывается в поле.
С остальными полями тоже всё просто — система у CRM-ок одинаковая, поэтому они просто заполняются по аналогии.
Когда создали сделку, переходим к её наполнению. Вытягиваем компанию и точно так же создаём полностью в amoCRM, так же проставляем значения полей и настраиваем связь со сделкой.
С контактами то же самое. Их может быть несколько, и пока не создадим все контакты, связанные с этой сделкой, не переходим дальше.
С задачами и заметками поступаем немного по-другому. Опять же, из-за ограничений по частоте запросов к amoCRM надо как-то ускорить процесс. Ведь к каждой сделке может быть несколько сотен заметок. Если создавать каждую, на это уйдёт уйма времени. Поэтому будет заливать их массивами. Ограничиваем количество цифрой 450, чтобы не получить бан, и заливаем сразу всё к сделке, компании или контакту. Понятное дело, если в сделке меньше заметок, то создадутся только они: чужие записи не выгрузятся. Соответственно, и с линковкой проблем нет.
Как только мы закончили с одной сделкой — создали все связанные с ней компании, контакты, заметки, задачи, а также их наполнение, переходим к следующей и по аналогии выгружаем всё по порядку — пока сделки не закончатся в исходной CRM.
Дополнительно нам ещё нужно выгрузить и прикрепить Participants (Участников), но так как это просто связанные со сделками контакты, нам не нужно беспокоиться о компаниях, задачах и заметках — если они были в сделке, то уже выгрузились с ней. Поэтому мы просто забираем их из Pipedrive и загружаем в amoCRM с указанием привязки к сделкам. Ну а если они уже есть, то просто указываем линковку.
В итоге мы получаем копию CRM-системы, но на базе новой функциональности от amoCRM. С ним теперь предстоит ещё большая работа по доработке под задачи компании.
Итоги миграции из PipeDrive в amoCRM
По времени подготовка заняла около двух рабочих недель. Но это с учётом того, что пришлось полностью разбираться в незнакомом Pipedrive, а также тестировать возможности баз обеих систем — выводить правильную логику выгрузки и выяснять ограничения на загрузку.
Сам процесс миграции занял около 12 часов — возможно, могло быть и меньше, но сыграло ограничение на частоту запросов по API в amoCRM.
За это время выгрузили 2300 сделок, 5706 организаций, 11 621 контактов и бесчисленное множество задач и заметок всех сортов и расцветок. Ну и письма, как мы помним, тоже подгрузились заметками в фид сделок.
Те, кто сталкивался с внедрением CRM-системы, вероятно, знает, как сложно отделу продаж перейти на новый режим работы. Особенно если в компании уже была собственная система учёта. Исходя из нашего опыта, такой процесс занимает до 2 месяцев. Поэтому представьте, как удобно, если все базы клиентов, вся история работы с ними просто была клонирована в новую CRM. По сути, так и получилось. Мы запустили миграцию вечером, а к утру уже всё было готово.
Советы
Если вы планируете делать миграцию самостоятельно, то вот вам несколько полезных советов, чтобы не тратить время на свои же ошибки.
- Изучите досконально обе системы. Вы должны быть экспертами в обеих программах, чтобы повторить все функции начальной системы и воспользоваться возможностями новой.
- Согласуйте результат с заказчиком (если делаете не себе). Вы и ваш клиент должны чётко понимать, что он получит, а чего придётся лишиться. Если вы неправильно поймёте или не узнаете у клиента какие-то мелкие подробности, скорее всего, всю работу придётся переделывать с нуля.
- Проведите аналогию сущностей. Все записи в новой CRM-системе должны правильно и, главное, полноценно повторять изначальный вариант. Соотнесите возможности и ограничения сущностей, если хотите получить от миграции максимум.
- Учитывайте различия архитектур и взаимосвязей. В зависимости от схемы взаимодействия сущностей придётся выбирать схему выгрузки и копирования записей.
- Продумайте алгоритм. Возьмите и нарисуйте его в ментальной карте или на флипчарте. Потому что при загрузке вам придётся строить новую систему взаимодействия массивов. Если хотите сделать это быстро и правильно, продумайте все мелочи.
- Продумайте варианты багов. Это обычно решается с помощью штурма. Если вы придумаете ошибку и её решение раньше, чем она всплывёт в работе, вы будете только рады.
- Попробуйте тестовый запуск. Лучше с какой-то частью базы, но стоит попробовать миграцию на начальных этапах. В таком случае вы сразу увидите недостатки своей схемы, либо отследите мелкие баги, о которых не задумывались раньше.
- Делайте бэкап. Это совет для всех. Неважно, что вы собираетесь делать, хотя при миграции это очень пригодится. Просто делайте бэкап.
- Подумайте, что можно сделать вручную. Автоматизация — это, конечно, то, ради чего мы здесь собрались, но не забывайте, что лишний код принесёт вам только проблемы с отладкой. Если каких-то сущностей немного — подумайте, может быть проще перенести их вручную.
Главное, что стоит запомнить, миграция — это вполне реализуемо. Если CRM-система не адаптирована под специфику бизнеса — ищите другие варианты и не бойтесь её сменить. Да, это будет сложно для всей команды, вы обязательно потеряете часть информации или клиентов, но зато конечный результат окупит всё с избытком. Если менеджерам неудобно или не нравится работать с софтом, они будут использовать его по минимуму. Не стоит бояться менять CRM уже с учётом всех бизнес-процессов и присущей им специфики, ведь эффективность менеджеров — это всегда деньги компании.
Читайте также: Эти ошибки в фидах Яндекс.Маркета мешают продажам
Мнение редакции может не совпадать с мнением автора. Ваши статьи присылайте нам на 42@cossa.ru. А наши требования к ним — вот тут.