Есть отдельный жанр запроса, с которым к нам приходят чаще, чем с «хотим внедрить». Звучит он примерно так: «У нас уже есть Битрикс24. Настраивали год назад. Никто им не пользуется. Что делать?»
Дальше выясняется одно и то же. Портал куплен, кто-то что-то настроил, менеджеры ведут клиентов в блокноте и в мессенджере, руководитель раз в месяц заходит в отчёты, вздыхает и закрывает. Формально система есть. Фактически компания работает так же, как до неё, только теперь ещё и платит за лицензию.
Разберём, почему так выходит, как устроен аудит существующего портала и что обычно оказывается настоящей причиной. С прицелом на бизнес в Минске и по всей Беларуси.
Почему «настроили, но не работает» - это норма, а не исключение
Первое, что стоит сказать: если у вас так - вы не уникальны и никто не виноват персонально. Это самый частый исход внедрения, и причины у него системные.
Настраивали не под процесс, а под возможности системы. Взяли типовую воронку из демо, слегка переименовали стадии - и получили схему, которая описывает какой-то абстрактный бизнес, но не ваш. Менеджеры это чувствуют сразу: система требует действий, которые не совпадают с тем, что они реально делают.
Внедрение закончилось на запуске. Настроили, показали, ушли. А приживание системы - это не день запуска, а следующие два-три месяца, когда всплывают неудобства и их нужно править.
Никто не отвечал за результат внутри компании. Подрядчик отвечал за настройку, а за то, чтобы люди начали работать по-новому, не отвечал никто. Это не техническая задача, и снаружи её не решить.
Автоматизировали хаос. Если процесс не был описан до внедрения, система просто зафиксировала беспорядок в цифровом виде. Стало не лучше, а хуже: раньше беспорядок был гибким, теперь он требует заполнять поля.
Симптомы: как понять, что аудит нужен
Не по ощущениям, а по конкретным признакам. Если узнаёте три и больше - систему нужно разбирать.
- Менеджеры ведут параллельный учёт. Таблица, блокнот, заметки в телефоне. Верный признак: система не даёт им того, что нужно для работы.
- Данные вносятся задним числом. Раз в неделю, пачкой, «чтобы было». Такие данные не годятся ни для управления, ни для аналитики.
- Много полей, которые никто не заполняет. Классика: тридцать полей в карточке, из них живых - шесть.
- Отчётам не верят. Руководитель проверяет цифры вручную или спрашивает у менеджеров. Значит, отчёт не отражает реальность.
- Сделки висят месяцами без движения. И никто этого не замечает, потому что нет ни напоминаний, ни контроля.
- Роботы отключены. Их когда-то настроили, они мешали, их выключили. Никто не помнит, что именно они делали.
- Один клиент в базе несколько раз. Дубли - признак того, что за качеством данных никто не следит.
- Новый сотрудник учится у соседа, а не по регламенту. Значит, реальный процесс отличается от того, что заложено в систему.
Что смотрят в аудите
Аудит - это не «посмотреть настройки». Настройки как раз обычно в порядке. Проблема почти всегда в разрыве между тем, как настроено, и тем, как работают. Поэтому смотреть нужно с трёх сторон.
Сторона первая: данные
Данные врут меньше всех - они показывают, как система используется на самом деле, а не как об этом рассказывают.
Что считается:
- доля сделок с заполненными ключевыми полями (сумма, источник, ответственный);
- доля сделок без единого движения за последние 30 дней;
- сколько дублей контактов и компаний;
- сколько сделок закрыто с причиной отказа, а сколько - молча;
- как распределяются сделки по стадиям (если 70% висит на одной - стадия описана неправильно);
- разрыв между датой события и датой внесения в систему.
Последний пункт особенно показателен. Если сделки заводятся по пятницам пачками, значит, в течение недели работа идёт мимо системы.
Сторона вторая: настройки
Здесь смотрят, соответствует ли конструкция задаче:
- воронки и стадии: отражают ли они реальный процесс, нет ли лишних и мёртвых стадий;
- поля: какие используются, какие можно убрать, каких не хватает;
- права доступа: кто что видит, есть ли риск утечки базы;
- автоматизация: что настроено, что работает, что выключено и почему;
- интеграции: телефония, почта, сайт, 1С - живы ли, нет ли ошибок обмена;
- отчёты: есть ли те, которыми реально пользуются.
Сторона третья: люди
Самая важная и чаще всего пропускаемая. Полчаса разговора с каждым - и картина становится ясной.
Вопросы, которые дают больше всего:
- Что в системе неудобно настолько, что вы обходите это стороной?
- Что вы ведёте вне системы и почему?
- Какое действие занимает больше всего лишнего времени?
- Что вы делаете каждый день руками, хотя это выглядит однотипным?
Ответы почти всегда конкретные и почти всегда чинятся быстро. Типичное: «чтобы выставить счёт, надо переписать реквизиты из другого места» или «после звонка нужно заполнить пять полей, а у меня следующий звонок».
Что обычно оказывается настоящей причиной
По опыту разборов картина повторяется. Технических причин меньше, чем кажется.
Система требует больше, чем даёт. Менеджер вносит данные, а взамен не получает ничего - ни удобства, ни скорости. Это главная причина саботажа, и она не про лень. Как только система начинает экономить время (счёт формируется сам, реквизиты подтягиваются, задача ставится автоматически), сопротивление исчезает само.
Стадии не совпадают с реальностью. Менеджер не знает, куда двигать сделку, потому что его реальный шаг в схеме не предусмотрен. В итоге двигает как попало или не двигает вовсе.
Нет обязательности. Если можно закрыть сделку без причины отказа и заполнить половину полей, так и будет. Причём это не вопрос дисциплины - это вопрос настройки: обязательные поля на стадии решают проблему за день.
Руководитель не пользуется системой. Если планёрка идёт по устным докладам, а не по отчёту, менеджеры быстро понимают: данные в системе никому не нужны. Это самая дорогая причина и самая трудноисправимая, потому что чинится не настройками.
Никого не научили. Показали один раз при запуске, через месяц половина сотрудников сменилась. Про это отдельно - в статье «Как обучить команду работать в Bitrix24».