Почему CRM перестала работать через два месяца после запуска — и кто должен был это заметить

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

Почему «не работает» через два месяца — это расхождение, а не поломка?

Исследователи process mining называют это concept drift и считают базовым свойством процессов, а не аварией. Формулировка из работы Бозе, ван дер Аалста, Жлиобайте и Печенизкого (IEEE Transactions on Neural Networks and Learning Systems, 2014): большинство бизнес-процессов меняются со временем, а методы анализа рассматривают их так, будто они находятся в устойчивом состоянии. Дрейф бывает внезапным и постепенным, разовым и сезонным.

Статья написана об алгоритмах, но диагноз тот же, что и в CRM: модель процесса застыла, процесс — нет. Разница только в том, что в process mining дрейф ищут специально, а в компании после внедрения его не ищет никто, потому что эта работа никому не досталась.

Контур процесса: через какие стадии за год не прошла ни одна сделка?

Самый заметный след дрейфа — пустые стадии. В апреле 2026 года Auspex прогнал собственный аудит по своему же порталу. Во всех воронках через 33 стадии из 60 за год не прошла ни одна сделка. В главной воронке три стадии из девяти — «Отправили КП», «Согласовали условия сотрудничества», «Подписание договора» — стояли пустыми: сделки года шли сокращённым путём, от заявки сразу к счёту и оплате.

Воронка, нарисованная на внедрении, и воронка, которой команда реально пользуется, оказались разными воронками. Никто ничего не саботировал. Согласование условий никуда не делось, оно просто перестало быть отдельным шагом в системе и переехало в переписку.

В апрельском аудите CRM одной сервисной компании та же картина в другом масштабе: 37% стадий без единой сделки за год, а из тринадцати настроенных воронок реально живых восемь. Оба числа — замер по конкретному порталу, а не отраслевая статистика; мы не знаем, как выглядит эта доля в среднем по рынку, и не видели исследования, которое её считает.

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

Контур данных: почему первыми ломаются автоматизации, а не отчёты?

Второй контур расходится тише. Поля, которые на внедрении кто-то заказал и отстаивал, постепенно перестают заполняться, и решения об этом никто не принимал. На собственном портале Auspex в апреле 2026 года насчитывалось 112 пользовательских полей, из которых реально заполнялись два-три. В аудите сервисной компании в карточке сделки оказалось 121 пользовательское поле с заполненностью 0%, а выборочная проверка контактов дала около 19% дублей и почти половину контактов без привязки к компании.

Главное здесь — порядок, в котором пустота проявляется. Отчёты деградируют мягко: среднее считается по тому, что заполнено, число выходит меньше реального, но число выходит. Автоматизации деградируют резко. Условие, которое сверяется с пустым полем, не срабатывает никак: не ошибается, не уведомляет, просто молчит. Поэтому первый симптом распада данных звучит как «робот больше не напоминает», а не как «отчёт показывает ерунду».

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

Контур поведения: почему обход дешевле системы?

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

Точнее всего этот механизм задокументирован в больницах. Коппель, Веттернек, Теллес и Карш (Journal of the American Medical Informatics Association, 2008) разобрали, как медсёстры обходят систему подтверждения лекарств по штрихкоду, и описали 15 типов обходов и 31 тип причин — от смятых и затёртых штрихкодов до разряженных батарей и нестабильного Wi-Fi. Предупреждения системы персонал отменял для 4,2% пациентов и 10,3% препаратов. Вывод авторов: обход порождают недостатки в конструкции системы, в её внедрении и в том, как она встроена в реальный рабочий процесс.

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

В CRM у обхода есть измеримый след — задачи. На портале Auspex в апреле 2026 года ни одна открытая задача не была привязана к сделке или контакту: ноль процентов. В аудите сервисной компании таких было 8%. «Перезвонить клиенту» живёт в модуле задач, сделка живёт в воронке, связи между ними нет. С точки зрения воронки этого звонка не существует.

Второй след — распределение нагрузки. На собственном портале из активных аккаунтов реально работала с CRM чуть больше трети, а около 79% открытой воронки держалось на двух людях. В сервисной компании почти половина открытой воронки лежала на одном менеджере. Когда на человеке сотни открытых сделок, он физически не ведёт их в системе. Он держит в голове те, которые помнит, и система узнаёт о них последней.

Почему три контура не складываются в один сигнал?

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

Скорости тоже разные. Поведение меняется за недели: обход находят сразу, как только он оказывается дешевле. Данные сыплются месяцами. Процесс расходится кварталами, ровно с той скоростью, с какой у бизнеса появляются новые продукты и каналы. Поэтому не бывает момента, когда три проблемы звучат вместе и кто-то говорит «у нас распад». Бывает момент, когда руководитель открывает отчёт, не верит ему и формулирует это как «CRM не работает».

Что на самом деле показывают ваши отчёты?

Самая неприятная часть распада в том, что приборы, которыми его ловят, дрейфуют вместе со всем остальным. Пример из собственного аудита Auspex за апрель 2026 года. Стандартный показатель «время до первой активности по лиду» показывал почти мгновенную реакцию, и по нему с обработкой лидов всё было в порядке.

Дальше выяснилось, что 44,6% лидов получали первую «активность» в первые пять минут, и это не люди. Это бизнес-процессы обновляли поле последней активности. Когда автоматические активности до пяти минут исключили из расчёта, медиана человеческой реакции составила 11,2 часа, а средняя — 55,7 часа.

Одно поле, два автора. Робот и человек пишут в него одинаково, а отчёт их не различает. Автоматизацию ставили, чтобы реагировать быстрее, а она сделала саму реакцию неизмеримой и формально улучшила показатель ровно тем, что его испортила.

Bitrix24 тут ни при чём — свойство общее: любая метрика, в которую пишут и люди, и роботы, перестаёт быть метрикой людей в тот момент, когда роботов становится много. Поэтому после каждой новой автоматизации стоит спрашивать не только «что она делает», но и «какие показатели она теперь подрисовывает».

Почему владелец процесса — это не администратор CRM?

Обнаружить все три контура можно при одном общем условии: кто-то должен регулярно смотреть и иметь право менять. Майкл Хаммер описал эту роль в статье «The Process Audit» (Harvard Business Review, апрель 2007) как один из пяти обязательных enabler'ов процесса, наряду с дизайном, исполнителями, инфраструктурой и метриками. Владелец в его определении — руководитель, который отвечает за процесс и за его результат.

Процесс, которому не хватает одного из enabler'ов, может давать результат в краткосрочной перспективе — за счёт сверхчеловеческих усилий или вмешательства руководства, — но такие результаты не держатся.

— Michael Hammer, The Process Audit, HBR, 2007

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

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

Как провести ревизию трёх контуров за 90 минут?

Это можно сделать самим, без интегратора. Условие одно: в комнате должен сидеть человек, который реально работает в этой воронке, а не только тот, кто её когда-то настраивал.

• Процесс, 30 минут. Откройте отчёт по стадиям за 12 месяцев, выпишите стадии с нулём сделок и воронки, в которые за год не зашло ничего. По каждой — письменное решение: убрать или восстановить. Отдельно спросите менеджера, какой шаг он делает в переписке вместо системы. Этот шаг и будет стадией, которой у вас нет.
• Данные, 30 минут. Возьмите три автоматизации, которые запускали на внедрении, и для каждой выпишите поля, от которых зависит условие. Посмотрите заполненность именно этих полей за последний месяц. Параллельно посчитайте, сколько пользовательских полей в карточке сделки заполнены меньше чем в 10% случаев — это список кандидатов в архив.
• Поведение, 30 минут. Посмотрите долю открытых задач, привязанных к сделкам и контактам, и распределение открытых сделок по менеджерам. Потом задайте команде один вопрос: что вы делаете мимо CRM, потому что так быстрее. Ответ никогда не бывает пустым, и именно он полезнее всего в этой ревизии.

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

Что с этим делает Auspex?

Auspex — компания по внедрению CRM и автоматизации бизнес-процессов. Аудит, из которого взяты числа в этой статье, в апреле 2026 года Auspex прогнал прежде всего по собственному порталу. 33 пустые стадии из 60, 112 пользовательских полей с двумя-тремя рабочими, ноль задач, привязанных к сделкам, — это наши числа, а не клиентские. Портал работает много лет, через него прошли сотни настроек и десятки людей, которые давно не в компании.

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

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

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