Импортозамещение CRM и ERP: что проверить до миграции

TL;DR: Замена западной CRM или ERP на российскую не чинит процессы. Если между отделами были разрывы, миграция аккуратно перенесёт их в новую платформу, и бюджет на лицензии уйдёт впустую второй раз. До выбора замены зафиксируйте, где сейчас рвётся информация между подразделениями. Это дешевле, чем переплатить за внедрение и через год обнаружить те же потери.

SAP перестаёт продлевать поддержку, Salesforce и Oracle отключают облака. Компании на 200–700 человек оказались в очереди на замену системы, которую внедряли 5–7 лет и под которую перестроили половину работы. Бюджет на миграцию уже выделен, интегратор выбран, дедлайн стоит.

И почти везде проект идёт по одной схеме. Берут текущую конфигурацию, переносят справочники и бизнес-логику «как есть» на 1С, Bitrix24 или отраслевую российскую платформу. Логика понятная: работало же раньше, значит надо повторить.

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

Почему миграция не лечит процессы

Система автоматизирует то, что вы ей описали. Если отдел продаж и склад обменивались данными через выгрузку в Excel раз в день, то после миграции на 1С они продолжат обмениваться через выгрузку в Excel раз в день. Платформа сменилась, разрыв остался.

Я видел это много раз. Компания меняет SAP на 1С:ERP, тратит 14 месяцев и десятки миллионов, а на старте эксплуатации получает ровно те же жалобы: «склад не видит заказ вовремя», «финансы сводят данные руками», «менеджер не знает остаток». Чинили систему, а болело на стыке между системами и людьми.

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

Что зафиксировать до выбора замены

До того как сравнивать 1С:CRM с Bitrix24 или выбирать отраслевую WMS, опишите текущее состояние. Не функциональность системы, а то, как реально движутся данные и решения между отделами.

Три вещи, которые надо положить на бумагу.

Кто кому что передаёт. Возьмите два-три основных процесса (например, путь заказа от приёма до отгрузки и оплаты) и пройдите его по людям. На каждом переходе между отделами зафиксируйте, что передаётся, в каком виде, через какой канал, с какой задержкой.

Где данные дублируются вручную. Каждая ручная перебивка из системы в Excel и обратно — это будущий разрыв в новой платформе, если его не спроектировать иначе. Считайте такие точки. Их обычно больше, чем кажется руководству.

Кто за что отвечает на переходах. Самое дорогое молчит в зонах «это не моё». Заказ завис между продажами и складом, и непонятно, чья это зона ответственности. Такие провалы не видны в ТЗ на миграцию, но именно они съедают деньги.

Если этого описания нет, интегратор будет переносить вашу систему вслепую, опираясь на то, что увидит в конфигурации. А в конфигурации не записано, что менеджер каждое утро звонит на склад, потому что выгрузка врёт.

4 типа стыков как чек-лист миграции

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

Информационный стык. Один отдел не видит данные другого вовремя или видит их в искажённом виде. Склад не знает о новом заказе до утренней выгрузки. Финансы получают отгрузочные документы с задержкой в два дня. Перед миграцией проверьте, где данные приходят с опозданием или приходят неполными.

Форматный стык. Данные есть, но в несовместимом виде. Продажи ведут номенклатуру по своим артикулам, склад по своим, бухгалтерия по третьим. Перенос «как есть» закрепит три параллельных справочника в новой платформе. Перед миграцией проверьте, где одна и та же сущность называется по-разному в разных отделах.

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

Управленческий стык (RACI). Не определено, кто принимает решение и кто отвечает за результат на переходе. Просрочка по заказу есть, ответственного нет. Перед миграцией проверьте, где на границе отделов нет явного владельца результата.

Если по каждому из четырёх типов вы можете назвать конкретные точки в своём процессе, у вас есть карта того, что чинить до миграции, а что можно переносить спокойно.

Кейс: производитель упаковки, 420 человек

Компания меняла связку из западной CRM и самописной складской системы на 1С:ERP. Бюджет миграции 22 млн руб, срок 11 месяцев. До старта проекта мы провели диагностику процесса «приём заказа, отгрузка, оплата».

Нашли разрыв на стыке продаж и склада. Менеджер фиксировал заказ в CRM, а склад узнавал о нём из ручной выгрузки, которую формировали раз в день в 9 утра. Заказы после 9 утра ждали до следующего дня. Часть из них клиенты успевали отменить или подвинуть, часть собирали в авральном режиме с переработками.

Потери считали по трём строчкам: срочные перевозки вместо плановых, переработки склада, отменённые из-за задержки заказы. Вышло 1,9 млн руб/мес. За год это 22,8 млн, ровно стоимость всей миграции.

Дальше важное. В исходном ТЗ на 1С:ERP этот разрыв воспроизводился: в новой системе тоже предполагалась пакетная передача заказов на склад раз в смену, потому что «так привыкли». Мы поправили проектное решение на онлайн-передачу заказа в момент подтверждения. Настройка такой передачи стоила несколько сотен тысяч рублей против 22,8 млн потерь в год, которые иначе переехали бы в новую систему вместе со справочниками.

Диагностика стоила меньше 1% бюджета миграции и окупилась на одном найденном стыке.

Как не привязать новую систему к старым разрывам

Главная ловушка миграции — техзадание, написанное от текущей конфигурации. Когда интегратор спрашивает «а как у вас сейчас работает», ответ «вот так» автоматически закрепляет все костыли.

Три правила, чтобы этого избежать.

Описывайте целевой процесс, а не текущий. ТЗ должно отвечать на вопрос «как должно быть». Текущее состояние нужно как карта проблем, не как образец для копирования.

Каждый ручной обходной путь — это требование, а не привычка. Если менеджер звонит на склад, потому что выгрузка врёт, в ТЗ должно попасть требование «склад видит заказ в момент подтверждения», а не строчка «сохранить утреннюю выгрузку».

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

Порог: мигрировать как есть или сначала чинить процесс

Не каждый стык надо чинить до миграции. Иногда дешевле перенести как есть и поправить потом. Простой порог для решения.

Чинить процесс до миграции, если разрыв стоит больше 300–500 тыс руб/мес, затрагивает основной денежный поток (путь заказа до оплаты, закупки, расчёты с клиентами) и воспроизводится в проектном решении новой системы. Такой стык переедет и продолжит съедать деньги, а переделывать его после запуска дороже, чем спроектировать сразу.

Мигрировать как есть и отложить, если разрыв во вспомогательном процессе, потери на нём небольшие, и его исправление не требует менять архитектуру переноса. Чинить всё сразу нельзя, приоритет за денежным потоком.

Грубо: считайте деньги на каждом найденном стыке и сравнивайте с тем, во сколько обойдётся правка в проекте миграции. Если стык дороже правки, чините до переноса. Эту арифметику удобно прикинуть в калькуляторе потерь на стыках ещё до разговора с интегратором.

FAQ

Сколько занимает диагностика стыков до миграции? Обычно 2–4 недели на два-три основных процесса. Это меньше срока выбора интегратора, так что диагностика не сдвигает проект, а ложится в подготовительный этап.

Не проще ли довериться интегратору, он же знает 1С? Интегратор знает платформу, но не знает, где у вас рвётся между отделами. Он перенесёт то, что увидит в конфигурации и услышит на интервью. Карта стыков, собранная заранее, превращает его работу из «повторить как было» в «собрать как должно быть».

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

Российские системы вообще тянут наши процессы? 1С:ERP, Bitrix24 и отраслевые WMS закрывают подавляющее большинство задач компаний на 200–700 человек. Вопрос почти никогда не в платформе, а в том, спроектированы ли переходы между отделами или скопированы старые костыли.

Чем диагностика стыков отличается от обследования у интегратора? Обследование интегратора отвечает на вопрос «как настроить систему». Диагностика стыков отвечает на вопрос «где и на сколько рублей в месяц теряет процесс». Это разные оптики: одна про софт, другая про деньги на границах между отделами.

Что дальше

Если вы готовите замену CRM или ERP, начните не с выбора платформы, а с карты того, где сейчас рвётся между отделами.

• Разберитесь в логике подхода: «Стыки дороже систем»
• Прикиньте стоимость своих разрывов: калькулятор потерь на стыках
• Посмотрите, как устроена диагностика до закупки системы: E2E-диагностика процессов
• Поймите, как читается путь заказа между отделами: карта бизнес-процессов