Миграция процессов автоматизации без боли

Компания решила сменить CRM. Или ERP. Или платформу автоматизации. На бумаге всё понятно: переносим данные, настраиваем новую систему, запускаем. На практике — кошмар. Потому что за годы работы в старой системе выросла экосистема автоматизаций: триггеры, интеграции, боты, RPA-роботы. Всё это завязано на конкретные поля, статусы, API. И всё это нужно как-то перенести.

Миграция данных — это половина проблемы. Вторая половина — миграция процессов. Бот, который создавал заявки в старой CRM, должен создавать их в новой. Триггер, который слал уведомления, должен работать в новой системе. Интеграция с 1С должна продолжать синхронизировать данные. И всё это — желательно без остановки бизнеса.

В этой статье разберём, как планировать и выполнять миграцию автоматизированных процессов. Не просто «скопировать и вставить», а системно: с инвентаризацией, тестированием, откатом и минимальным риском.

Почему это сложнее, чем кажется

На первый взгляд, автоматизация — это просто логика: «если X, то Y». Логику можно переписать в новой системе. Но дьявол в деталях.

Разные модели данных. В старой CRM поле называлось «Статус», в новой — «Этап воронки». Значения другие. Связи между сущностями устроены иначе. Автоматизацию нельзя просто скопировать — её нужно адаптировать.

Разные возможности платформ. Старая система позволяла делать X, новая — не позволяет. Или позволяет, но по-другому. Часть автоматизаций придётся переосмыслить, а не просто перенести.

Зависимости между автоматизациями. Один триггер создаёт запись, другой — реагирует на её создание. Перенесли первый, забыли про второй — цепочка сломалась. Нужно видеть всю картину.

Внешние интеграции. Бот интегрирован со старой CRM через API. Новая CRM имеет другой API. Бота нужно переписывать, а не просто переключать.

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

Шаг 1: Инвентаризация автоматизаций

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

Где искать? Встроенные триггеры и автоматизации в CRM/ERP. Отдельные workflow-системы. Интеграционные платформы (Zapier, Make, n8n). RPA-роботы. Чат-боты и голосовые помощники. Скрипты и cron-задачи на серверах. Плагины и расширения.

Что фиксировать для каждой автоматизации? Название и назначение (что делает). Триггер (что её запускает). Действия (что происходит). Системы, с которыми взаимодействует. Зависимости от других автоматизаций. Владелец (кто отвечает). Критичность (что будет, если не работает).

Результат — таблица или карта всех автоматизаций. Это ваша «инвентаризационная опись», по которой будете работать дальше. Без неё — гадание и пропущенные автоматизации, которые всплывут после миграции.

Шаг 2: Приоритизация и классификация

Не все автоматизации одинаково важны. Некоторые критичны для бизнеса, другие — «приятно иметь». Это влияет на порядок и подход к миграции.

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

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

Необязательные автоматизации — legacy, которое никто не использует, или эксперименты, которые не прижились. Возможно, их не нужно переносить вообще. Это хороший момент для очистки.

Для каждой автоматизации также определите подход: прямой перенос (логика сохраняется, только адаптация под новую систему), переосмысление (пересмотр логики — возможно, в новой системе можно сделать лучше), отказ (не переносим, автоматизация устарела).

Шаг 3: Маппинг данных и логики

Перед тем как переносить автоматизации, нужно понять, как сущности и поля старой системы соответствуют новой.

Маппинг сущностей. «Сделка» в старой CRM = «Заявка» в новой? Или «Сделка» + «Заказ»? Как связаны клиенты, контакты, компании?

Маппинг полей. Поле «Источник» со значениями «Сайт, Звонок, Реклама» в старой системе = поле «Канал привлечения» со значениями «Веб, Телефония, Маркетинг» в новой. Нужна таблица соответствий.

Маппинг статусов. Это особенно важно для автоматизаций, которые реагируют на смену статуса. «Новая» → «В работе» → «Закрыто» в старой системе может соответствовать «Создана» → «Взята в работу» → «Выполнена» в новой.

Маппинг API. Если автоматизация вызывает API, нужно понять: какой метод в новом API соответствует старому? Какие параметры изменились?

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

Шаг 4: Реализация и адаптация

Теперь — собственно перенос. Подходы различаются в зависимости от типа автоматизации.

Встроенные триггеры CRM. Обычно приходится создавать заново в новой системе. Используйте маппинг: вместо старого поля — новое, вместо старого статуса — новый. Логика сохраняется, но «обёртка» другая.

Интеграционные сценарии (Zapier, Make). Можно скопировать сценарий и заменить коннектор. Вместо «amoCRM» — новый коннектор. Поля переназначить согласно маппингу. Часто быстрее, чем переписывать с нуля.

Чат-боты и внешние системы. Нужно менять интеграционный слой — как бот общается с CRM. API-вызовы переписываются на новый API. Модель данных адаптируется. Это может быть значительная работа.

RPA-роботы. Если робот работал через интерфейс старой CRM — его нужно переобучить на интерфейс новой. Это почти полная переделка сценария.

Скрипты и кастомный код. Анализируем, что делает скрипт, адаптируем под новые API и структуру данных. Тестируем особенно тщательно.

Шаг 5: Тестирование

Перенесённые автоматизации нужно тестировать. И не «посмотрели — вроде работает», а системно.

Тестирование на тестовом окружении. Если есть sandbox или тестовая среда новой системы — сначала проверяйте там. Не на боевых данных.

Функциональное тестирование. Каждая автоматизация проверяется: триггер срабатывает? Действия выполняются? Результат корректный?

Тестирование граничных случаев. Что если поле пустое? Что если статус неожиданный? Что если связанная запись не найдена? Автоматизация должна корректно обрабатывать исключения.

Интеграционное тестирование. Если автоматизации связаны — тестируйте цепочку целиком. Одна создаёт запись, другая реагирует — проверьте, что цепочка работает.

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

Шаг 6: Переход и параллельная работа

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

Параллельная работа двух систем. Новая система запущена, но старая ещё работает. Данные синхронизируются между ними. Пользователи постепенно переходят. Автоматизации работают в обеих системах.

Поэтапное переключение. Сначала переводите некритичные процессы. Смотрите, как работает. Потом — более важные. В конце — критичные. Это снижает риск «всё упало одновременно».

Мониторинг после переключения. Первые дни после миграции — усиленный мониторинг. Алерты на ошибки. Ручная проверка ключевых процессов. Быстрая реакция на проблемы.

План отката. Что если что-то пошло сильно не так? Как вернуться на старую систему? Это должно быть продумано заранее, а не в момент паники.

Типичные ошибки миграции

Несколько вещей, которые регулярно идут не так.

Недооценка объёма. «У нас всего несколько автоматизаций» — а потом выясняется, что их 50, и половина — критичные. Инвентаризация должна быть полной.

Копирование без адаптации. Попытка перенести автоматизацию «один в один», не учитывая различия систем. Результат — работает криво или не работает вообще.

Пропуск тестирования. «Логика та же, должно работать». А потом в продакшене — сюрпризы. Тестирование обязательно, даже для «простых» автоматизаций.

Big bang вместо поэтапного перехода. Желание «переключить всё за выходные» вместо постепенной миграции. Риск — всё сломается одновременно, и нет времени чинить.

Отсутствие отката. Нет плана B. Если миграция провалилась — паника, ручное восстановление, потеря данных.