«5 ловушек автоматизации продаж: почему проекты заходят в тупик — и как этого избежать»

Продолжаем наш большой цикл статей о проблемах, с которыми вы можете столкнуться при:

• Автоматизации продаж
• Внедрении Битрикс24
• Разработке интернет-магазинов

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

1. Переход с «своей», но неподдерживаемой системы

Ситуация:
Компания годами использовала собственную, «сделанную под себя» информационную систему. У каждого сотрудника — своя «зелёная кнопочка», код не документирован, сопровождение возможно только при участии автора. Всё удобно, но хрупко. Решено перейти на типовое решение: для поддержки, обновлений и снижения рисков. Однако, по мере внедрения растут сомнения: «А как без этого АРМа?», «У нас теперь столько документов…», «Мы так работать не сможем!». В итоге — либо проект саботируют до финала, либо получают «старую систему на новой платформе».

Решение:
Чётко определить истинную цель проекта на старте:

• Если цель — воспроизвести существующую функциональность, но уже на современной, поддерживаемой платформе — декларировать это явно и дать подрядчику время на анализ старой системы.
• Если же цель — действительно модернизировать процессы — нужно готовиться к сопротивлению, активно участвовать в обучении, защищать новое решение как перед собой, так и перед командой. Через год новая система станет такой же «родной», как когда-то старая — но без её технического долга.

2. Потеря интереса к проекту (смена приоритетов)

Ситуация:
Внедрение идёт, но вдруг:

• статус-встречи отменяют или переносят;
• ответственные «всегда в командировке»;
• обратная связь — формальная и запоздалая.

Причины? Может быть:

• неожиданный рост и необходимость срочно реагировать на рынок;
• подготовка к крупной выставке;
• другие стратегические инициативы.

Решение:
Не игнорировать тревожные сигналы. Лучше честно признать, что сейчас проект — не в фокусе, и официально поставить его на паузу. Это сохранит ресурсы, репутацию и шанс на успешный запуск позже — без спешки и компромиссов.

3. Смена управленческой команды

Ситуация:
Ключевой инициатор внедрения  уходит — либо из компании, либо на другое направление. Новые руководители не в курсе целей, решений, контекста. Проект «зависает». Особенно тяжело, если уходит не один человек, а целый блок управления — тогда компания может «трястись» полгода.

Решение:
Если проект по-прежнему важен:

• провести передачу знаний: передать документы, презентации, записи встреч;
• организовать вводную встречу новой команды с подрядчиком;
• переоценить текущую точку и скорректировать планы.

Если же проект утратил актуальность — закрыть его формально и честно: принять готовые артефакты, зафиксировать уроки, не оставлять «висяков».

4. Неправильный выбор архитектуры или продукта

Ситуация:

• Небольшая команда (5–10 человек) выбирает корпоративную ERP «на вырост» — но уже на старте пользователи страдают от сложности;
• Автоматизируют только производство, а потом вспоминают про сервис — но архитектура не поддерживает интеграцию;
• Не решают: единая база или несколько систем с обменами?

Решение:
Этап обследования бизнес-процессов — священный. Его нельзя пропускать или сокращать.

• Поделиться с подрядчиком не только текущей структурой, но и планами развития — даже если они неформализованы;
• Требовать обоснований архитектурных решений;
• Задавать вопросы, пока не появится внутренняя уверенность в выборе.

5. Проблемы с данными при миграции

Ситуация:
В старой системе справочники велись хаотично:

• «Болт синий», «Болт красный», «Болт обыкновенный» — три позиции, которые на деле — одна;
• доступ ко справочникам был у всех, прайсы поставщиков добавляли новые дубли;
• в новой системе это невозможно — нужна классификация, единые правила, чистота.

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

Решение:

• Разработать и утвердить единую структуру НСИ (номенклатур, цен, характеристик) до начала миграции;
• Назначить ответственных за подготовку данных — и дать им ресурсы и поддержку;
• Закрыть неограниченный доступ к справочникам в старой системе;
• Получить от подрядчика шаблон загрузки, проверить пробные выгрузки — заранее, а не в ночь перед запуском.

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

В следующей статье цикла —  погружение в тонкости внедрения. Оставайтесь на связи.