CRM зарастает полями годами. Одно завели под акцию, другое под отчёт, третье под интеграцию, которую давно отключили. Поля остаются. В карточке сделки их набралось 128 - менеджер открывает сделку и не находит нужное среди мёртвых.
Мы сделали робота, который наводит порядок. Он проверяет, что поле действительно пустое по всей базе, и удаляет только подтверждённый мусор. Полей в сделке стало 54. Робот ставится на отдел продаж в Битрикс24 или другой CRM.
Что было до
Карточка зарастает мёртвыми полями. Менеджер открывает сделку и видит длинный список, где половина значений пустые или дублируют друг друга. Нужное поле приходится искать глазами. Справочники врут: одно и то же название продублировано в двух полях, и непонятно, какое заполнять.
Удалять руками страшно. А вдруг это поле где-то используется - в роботе, в отчёте, в печати договора? Поэтому поля копятся: проще оставить, чем рискнуть. Так карточка и растёт до 128 полей.
Как это работает
Робот не удаляет поле сразу. Сначала он собирает по нему факты: сколько раз оно заполнено за всю историю базы, упоминается ли в коде, торчит ли в бизнес-процессах. Поле уходит под нож, только если оно пустое по всей базе и нигде не используется.
Само удаление идёт по безопасному протоколу: сухой прогон без записи, потом ограниченный на нескольких полях, потом боевой, потом проверка результата. Перед каждым удалением робот сохраняет полный бэкап - если что-то пошло не так, откат на месте.
Полей в сделке стало 54, в контакте - 65 вместо 102, в компании - 95 вместо 126. Поля для печати документов и подписей робот оставил осознанно: они пустые, но нужны бизнес-процессам, которые формируют договоры и акты. Пустота поля - повод проверить, зачем оно стоит, а не приговор.
Техническая сторона
- →Стек. Python на стандартной библиотеке, без внешних зависимостей. Робот ходит в CRM через REST Битрикс24: читает метаданные полей, считает заполненность, удаляет подтверждённый мусор.
- →Подтверждение пустоты по всей базе. Робот не верит выборке. Он проходит все записи полным обходом списка и считает, сколько раз поле реально заполнено за всю историю. Поле с нулём заполнений по всей базе - кандидат на удаление, а не поле, которое выглядело пустым в первых строках.
- →Три проверки до удаления. Пустота по базе - только первая. Дальше поиск упоминаний в коде роботов и отчётов и ручной обход бизнес-процессов. Поле уходит, только когда все три проверки чистые. Так из-под ножа выводятся поля, которые пусты сейчас, но завязаны на печать или автоматизацию.
- →Бэкап и откат. Перед удалением метаданные поля сохраняются в файл. Если поле понадобилось - восстановить можно из этого бэкапа, не собирая поле заново вручную.
- →Поля-двойники. Самая частая ловушка - два поля с почти одинаковыми названиями под один смысл. Разбор карточек показал: такие дубли плодят путаницу в справочниках. Робот сводит их к одному канону и удаляет лишний, а не оставляет оба.
- →Приватность. Робот работает с метаданными полей и счётчиками заполненности. Содержимое карточек - имена, телефоны, названия клиентов - наружу не уходит и остаётся в контуре сервера компании. По закону о персональных данных это снимает вопрос ещё на входе.
Что это даёт
Менеджер открывает сделку и видит поля, которые нужны для работы, а не свалку из 128 строк, где половина мёртвая. Справочники перестают врать - на один смысл одно поле. Ни одно живое поле не потеряно: удаляется только то, что пусто по всей базе, не торчит в коде и не завязано на печать документов.
