Журнал отвечает на вопрос «кто и когда изменил». Вопрос «а нужно ли это поле вообще» он не закрывает — и не должен. Но задаёт его именно он.

Почему полей становится много

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

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

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

Что показывает журнал и чего он не показывает

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

Дальше начинается граница инструмента.

Отсутствие в журнале двусмысленно. Поле не появляется в истории либо потому, что его не трогают, либо потому, что оно не отмечено для отслеживания. По журналу эти два случая не различаются.

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

Дубликаты не видны тем более. «Источник», «Источник заявки» и «Откуда пришёл» живут в разных сущностях, заполняются разными людьми и в журнале выглядят тремя независимыми полями.

И отдельно: выбирая поля для отслеживания, вы выбираете из общего списка. Когда в нём накопилось всё, что заводилось за годы, выбор превращается в перебор.

Что делает аудит полей

Приложение «Аудит полей в CRM» отвечает на вторую половину вопроса. Оно сканирует пользовательские поля в сделках, лидах, контактах, компаниях, счетах и смарт-процессах и показывает их состояние.

Что находит:

  • Мёртвые поля — с нулевой или близкой к нулю заполняемостью.
  • Дубликаты по смыслу — поля, которые называются по-разному, а собирают одно и то же. Сравнение делает ИИ, потому что по названию совпадение не ловится.
  • Неиспользуемые опции списков — варианты, которые не выбрал ни один сотрудник ни разу.
  • Недостающие поля — то, что сотрудники пишут текстом в комментариях, хотя это просится в отдельное поле.

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

Порядок, в котором они работают вместе

Связка получается в обе стороны, и вторая важнее.

Аудит перед настройкой логирования. Сначала чистка, потом контроль. Отмечать поля для отслеживания имеет смысл в списке, где не осталось мусора: и выбирать проще, и журнал не зашумлён правками полей, которые никому не нужны.

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

Пользователь логирования здесь в выигрышном положении. У него уже есть то, чего у остальных нет: подтверждение или опровержение по журналу, а не догадка.

Про бизнес-процессы

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

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

Рекомендации применяются вручную — приложение ничего не удаляет само. Есть массовое применение одной кнопкой, но нажимает её администратор, посмотрев список. В Pro-тарифе изменения можно откатить в течение тридцати дней.

Границы

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

Заполняемость — статистика, а не приговор. На молодом портале с сотней сделок мёртвым выглядит почти всё, и чистить там нечего: сначала данные, потом выводы.

Функции на ИИ — поиск дубликатов по смыслу и предложение недостающих полей — работают на подписке «Маркетплейс + GPT» и отдельно не тарифицируются. Без подписки остальные проверки работают.

Бесплатный план ограничивает число сканирований в месяц; удаление полей и все рекомендации, включая ИИ, в него входят. Объединение полей, создание, откат изменений и автосканирование по расписанию — в Pro.

Значения из карточек приложение у себя не хранит: результаты проверки остаются на портале.

Установить приложения из Маркета Битрикс24: Аудит полей в CRM · Логирование изменения пользовательских полей

Подробнее о продукте — на странице Аудита полей.