Почему дебиторка перестаёт быть управляемой
Дебиторская задолженность почти никогда не появляется одним крупным событием. Она набирается по частям. Один клиент попросил отсрочку на неделю, второй оплатил половину счёта, третий просто забыл, а менеджер не напомнил, потому что был занят новой сделкой. К концу квартала финансовый директор открывает выгрузку из учётной системы и видит сумму, которую никто сознательно не одобрял.
Информация о долге живёт в двух разных мирах. Факт оплаты фиксируется в бухгалтерии, договорённость об отсрочке остаётся в голове менеджера или в переписке. Между этими точками нет связи. Бухгалтерия видит, что деньги не пришли, но не знает, что клиент обещал заплатить после подписания акта. Менеджер знает про обещание, но не следит за банковской выпиской. Финдиректор узнаёт обо всём последним, когда сумма уже накопилась.
Второй источник проблемы: распределение ответственности. Формально за дебиторку отвечает финансовая служба, фактически повлиять на клиента может только тот, кто с ним общается. У менеджера по продажам мотивация построена на закрытых сделках, поступившие деньги в неё обычно не входят. Он честно доводит сделку до подписи и переключается на следующую. Дальше долг переходит в зону, где им никто не занимается всерьёз.
Контроль дебиторки в Битрикс24 закрывает как раз эту стыковку. CRM никого не заставляет платить. Она держит вместе три вещи: кто продал, на каких условиях и что происходит с оплатой сейчас. Когда всё это лежит в одной карточке, разговор с отделом продаж перестаёт быть спором о том, кто виноват.
Что финансовому директору нужно видеть, а что ему обычно показывают
Классический отчёт по дебиторке из учётной системы отвечает на один вопрос: сколько нам должны на дату. Этого мало для решения. Финансовому директору нужны ответы совсем другого уровня.
Первое. Структура долга по срокам. Триста миллионов тенге долга, где всё в пределах согласованной отсрочки, и те же триста миллионов, где половина висит больше девяноста дней, это две принципиально разные ситуации, требующие разных действий.
Второе. Кто именно накопил долг, в смысле менеджера и подразделения, а не клиента. Если у одного продавца доля просрочки втрое выше средней по отделу, вопрос стоит не о клиентах, а об условиях, которые он раздаёт, чтобы закрыть план.
Третье. Что уже сделано по каждому долгу. Звонили ли клиенту, когда, что он ответил, назначена ли следующая попытка. Без этого любое совещание по дебиторке превращается в устный опрос: «Ну, я вроде писал ему на прошлой неделе».
Учётная система на второй и третий вопрос не отвечает, там нет ни менеджера сделки, ни истории коммуникаций. CRM отвечает, потому что изначально построена вокруг клиента и работы с ним. Именно поэтому связка «финансовый директор и CRM» перестала быть экзотикой. Финансовая служба заходит в систему продаж за контекстом, которого больше нигде нет.
Где в Битрикс24 хранятся данные о деньгах
Счёт в Битрикс24 представляет собой отдельный элемент CRM. Он лежит в разделе CRM и содержит данные о клиенте, позициях, сумме, реквизитах и сроке оплаты. Большая часть полей заполняется автоматически из карточки клиента или сделки, поэтому счёт не приходится собирать заново.
Счета бывают обычными и регулярными. Регулярные создаются по расписанию и закрывают повторяющиеся платежи вроде аренды или подписки. Для компаний с абонентской моделью это заметно снижает риск: счёт не забудут выставить, потому что его выставляет система.
Каждый счёт проходит через стадии, которые настраивает администратор портала, и отображается в канбане. Финальная стадия называется «Оплачен». Набор стадий меняется под процесс компании, и это важнее, чем кажется. Стадии нужны не только для наглядности: именно к ним привязывается автоматизация. Робот или триггер срабатывает при переходе счёта на конкретную стадию.
Создать счёт можно из карточки сделки, из карточки контакта или компании, вручную в разделе счетов, автоматически роботом или импортом из файла. Права доступа к счетам настраиваются отдельно, поэтому руководитель может открыть финансовой службе полную картину, а менеджеру оставить только его клиентов.
Есть ещё смарт-процессы. Этот механизм позволяет создать собственный тип элемента CRM со своим набором полей, отдельной воронкой, стадиями в канбане, правами доступа и связью с задачами и календарём. Компании с нестандартным процессом взыскания часто выносят работу с просроченной задолженностью в отдельный смарт-процесс, чтобы она не смешивалась с продажами и имела собственные стадии, от первого напоминания до передачи юристам.
Автоматические напоминания вместо ручного обзвона
Самая утомительная часть работы с дебиторкой состоит в том, чтобы регулярно вспоминать, кому пора звонить. В ручном режиме это делает либо финансовый контролёр со своей таблицей, либо никто.
В Битрикс24 эту рутину берут на себя роботы и триггеры. Робот выполняет действие: создаёт задачу, отправляет письмо, уведомление или документ. Триггер реагирует на событие вроде изменения поля или подписания документа. Оба привязываются к стадии, поэтому логику можно описать простыми правилами. Счёт перешёл на стадию отправки клиенту, через оговорённый срок ответственному ставится задача связаться и уточнить оплату.
У задач есть собственные напоминания: уведомлением внутри портала или письмом на почту. Плюс чек-листы, теги и шаблоны. Для повторяющихся операций подходят регулярные задачи. Настраивается один раз, дальше задача создаётся по расписанию с нужным исполнителем и сроками. Ежемесячная сверка расчётов с ключевыми клиентами укладывается в этот механизм целиком.
Эффект от такой автоматизации редко выглядит впечатляюще на презентации, но именно он даёт основной результат. Напоминание, отправленное на третий день просрочки, стоит компании ноль и решает большую часть случаев, где клиент просто забыл. До юристов доходит только то, что действительно того требует.
Настройка правил под конкретный процесс занимает не один вечер, здесь легко перестараться и завалить отдел лишними задачами. Если хотите пройти этот этап быстрее, имеет смысл сразу заложить его в проект внедрения Битрикс24 для вашего бизнеса: правила взыскания проще спроектировать вместе с воронкой продаж, чем достраивать потом поверх готовой конструкции.
Отчёты: что доступно из коробки и чего в ней нет
Готовой кнопки «отчёт по дебиторке» в Битрикс24 нет, и обещать её было бы нечестно. Есть инструменты, из которых такой отчёт собирается.
Раздел CRM-аналитики содержит блоки по лидам и по продажам: общий анализ движения лидов, отчёты по первичным и повторным обращениям, воронку продаж в двух вариантах, динамику продаж по периодам и сравнение периодов между собой. Главное достоинство раздела в фильтрации по любым полям, включая пользовательские. Если в карточке заведено поле с датой планируемой оплаты, по нему можно отобрать нужный срез. При этом на количество элементов в отчётах действуют ограничения, а часть отчётов ещё в разработке.
Есть деталь, о которую спотыкаются при переходе. CRM-аналитика работает со старой версией счетов. Новые счета в этих отчётах не отображаются. Для их анализа используется BI Конструктор.
BI Конструктор представляет собой инструмент бизнес-аналитики на базе Apache Superset. Отчёты в нём выглядят как дашборды: страницы с диаграммами и таблицами, данные обновляются автоматически. Источником служат сведения о сделках, задачах, звонках, компаниях, товарах и других элементах CRM, можно подключать и внешние источники. Отдельный раздел, рабочее место аналитика, позволяет управлять подключениями и видеть, какие элементы вообще не участвуют в отчётах.
Практически это значит, что дашборд по дебиторке для финансового директора собирается руками аналитика, а не выбирается из списка готовых. Зато собранный один раз, он показывает ровно те разрезы, которые нужны именно этой компании: по срокам просрочки, по менеджерам, по направлениям, по юридическим лицам.
Стык с учётной системой: где заканчивается CRM
CRM не заменяет бухгалтерию и не должна. Факт поступления денег фиксируется в учётной системе, и попытка вести первичный учёт оплат в CRM обычно заканчивается расхождением цифр.
Поэтому связка строится иначе. Коннектор к 1С передаёт из учётной системы в Битрикс24 сумму оплаты, сумму отгрузки, проценты оплаты и отгрузки, признаки полной оплаты и полной отгрузки. Файлы счетов на оплату и УПД попадают в карточку сделки. Отдельно решается вопрос частичных оплат: они становятся видны в сделках Битрикс24, а не только в 1С.
При синхронизации счетов важна передача статуса. Чтобы статусы совпадали корректно, между системами задаётся их сопоставление. Обмен настраивается либо через Push&Pull, либо через http-сервисы.
Для финансового директора это означает следующее. Цифра приходит из 1С, где она достоверна, а видит её человек в CRM, где есть клиент, менеджер и переписка. Никто не сверяет две таблицы вручную и не спорит, какая из них правильная.
Как меняется разговор с отделом продаж
Технические возможности сами по себе дебиторку не сокращают. Её сокращает изменение управленческой практики, которое эти возможности делают реальным.
Первое изменение касается момента отгрузки. Если в карточке клиента видно текущую задолженность и историю платёжной дисциплины, решение об отгрузке в долг перестаёт быть жестом доброй воли менеджера. Оно принимается по правилу, которое устанавливает финансовая служба.
Второе изменение касается прозрачности условий. Когда отсрочка зафиксирована полем в карточке, исчезает целый класс споров. Клиент утверждает, что ему обещали тридцать дней, менеджер помнит про четырнадцать. В системе стоит дата, и обсуждать нечего.
Третье изменение касается мотивации. Как только просрочка по каждому менеджеру видна в отчёте, появляется возможность привязать к ней премию. Многие компании к этому не готовы, и это отдельный управленческий разговор. Но без данных такой разговор невозможен в принципе, а с данными он хотя бы становится предметным.
Побочный эффект тоже стоит упомянуть. Первые недели после запуска отчётов обычно неприятны: выясняется, что реальная просрочка больше, чем считалось, потому что раньше её часть просто не попадала ни в один отчёт. Это нормальная стадия, и к ней стоит подготовить и себя, и собственника.
Не весь долг одинаково полезно взыскивать
Ошибка, которая обесценивает даже хорошо настроенную систему, состоит в одинаковом отношении ко всем должникам. Ресурс отдела продаж ограничен. Если менеджер тратит одинаковые усилия на клиента с недельной просрочкой в двести тысяч тенге и на клиента, который не платит четвёртый месяц и перестал брать трубку, компания проигрывает дважды.
Разделение обычно строится по двум осям: величина долга и глубина просрочки. Мелкая свежая просрочка закрывается автоматическим напоминанием, человека к ней подключать не нужно вовсе. Крупная свежая требует работы менеджера, желательно телефонным звонком в первые дни, пока отношения не испорчены. Мелкую застарелую часто дешевле списать, чем взыскивать, хотя решение здесь всегда за финансовой службой. Крупная застарелая остаётся единственной категорией, ради которой имеет смысл поднимать юристов и приостанавливать отгрузки.
Такое разделение удобно описывать через поля и стадии. Формула расчёта категории задаётся один раз, дальше система сама расставляет приоритеты, а руководитель отдела видит в канбане, где сосредоточены деньги, а не только количество карточек. Отдельно стоит завести признак спорной задолженности. Долги, где клиент не согласен с суммой из-за претензий к качеству или недопоставке, взысканием не решаются вообще, их надо возвращать в операционную службу.
Третий разрез, который часто забывают, это платёжная история конкретного клиента за прошлые периоды. Компания, которая исправно платит два года и один раз задержала на десять дней, и компания, которая опаздывает системно, требуют разного тона общения. Первую достаточно уведомить, второй пора пересматривать условия отсрочки.
Как это выглядит на практике
Возьмём условную оптовую компанию с отсрочкой платежа, примерно двадцатью менеджерами и несколькими сотнями активных клиентов. Пример иллюстративный, но собран из типичных ситуаций, а не из идеального сценария.
Исходная точка: дебиторка отслеживается в отдельном файле, который финансовый контролёр обновляет раз в неделю по выгрузке из 1С. К моменту, когда файл попадает к финансовому директору, данным уже несколько дней. Работа с должниками ведётся по остаточному принципу, потому что напоминать приходится вручную и по памяти.
Что меняется. В карточке сделки появляются поля с условиями оплаты и датой планируемого платежа. Из 1С приходят сумма оплаты и признак полной оплаты, включая частичные платежи. Настраиваются правила: за несколько дней до наступления срока ответственному ставится задача напомнить клиенту, а при переходе счёта в просрочку создаётся задача с более коротким сроком и уведомлением руководителю отдела. Строится дашборд с разбивкой долга по срокам и по менеджерам.
Что даёт результат. Основной эффект в таких проектах обычно приносит превентивное напоминание до срока платежа, а не жёсткое взыскание после. Значительная доля просрочки в оптовой торговле объясняется обычной забывчивостью на стороне клиента, у которого своя очередь платежей. Второй по значимости эффект в сокращении времени финансовой службы на сбор данных: вместо еженедельной ручной сводки открывается дашборд.
Чего ожидать не стоит. Клиенты, которые не платят из-за собственных финансовых проблем, от автоматизации платить не начнут. Их станет видно раньше и точнее, что тоже полезно, но решаются такие ситуации другими инструментами.
С чего начинать финансовому директору
Первый шаг лежит вне системы. Нужно письменно зафиксировать кредитную политику: кому даём отсрочку, на каких условиях, при каком уровне долга отгрузка останавливается, кто имеет право сделать исключение. Без этого автоматизировать нечего, потому что правил, которые можно описать роботами, просто не существует.
Второй шаг. Договориться, где живёт истина по деньгам. Обычно это учётная система, а CRM получает данные оттуда. Обратный вариант тоже возможен, но требует дисциплины, к которой готовы немногие.
Третий. Определить набор полей в карточке, без которых отчёт не соберётся. Как минимум это условия оплаты, дата планируемого платежа и признак фактической оплаты. Добавлять поля позже можно, но исторические сделки останутся без них, и первый год отчёт будет неполным.
Четвёртый. Согласовать правила напоминаний с руководителем отдела продаж. Здесь легче всего испортить дело: если система начнёт ставить менеджеру по двадцать задач в день, он перестанет открывать их все. Начинать разумнее с одного-двух правил и расширять по мере того, как люди привыкают.
Пятый. Только после этого браться за дашборды. Отчёт по пустым полям красив и бесполезен, смысл он приобретает через месяц-два после того, как данные начали накапливаться.
Порядок здесь важнее скорости. Компании, которые начинают с дашбордов и правил взыскания, а политику пишут потом, обычно проходят весь путь дважды. Мы в B2BPRO.KZ видим этот сценарий регулярно и стараемся отговаривать от него ещё на этапе обсуждения задачи, даже когда клиент просит просто настроить отчёт.
Частые вопросы
Можно ли в Битрикс24 получить готовый отчёт по дебиторской задолженности?
Готового отчёта именно с таким названием в системе нет. Есть раздел CRM-аналитики с отчётами по лидам и продажам и фильтрацией по любым полям, включая пользовательские, и есть BI Конструктор, в котором дашборд по задолженности собирается под конкретную компанию. Учтите: CRM-аналитика работает со старой версией счетов, новые счета анализируются через BI Конструктор.
Обязательно ли интегрировать CRM с 1С, чтобы контролировать долги?
Не обязательно, но без интеграции факт оплаты кто-то должен проставлять в CRM руками, и данные быстро расходятся с учётом. Коннектор к 1С передаёт в Битрикс24 сумму оплаты и отгрузки, проценты по ним, признаки полной оплаты и отгрузки, а также делает видимыми частичные оплаты в сделках. При синхронизации счетов настраивается сопоставление статусов между системами.
Кому давать доступ к данным о задолженности?
Права доступа к счетам настраиваются отдельно от остальной CRM. Обычная конфигурация: финансовая служба и руководство видят всю картину, менеджер только своих клиентов. Это снимает вопрос о том, что продавцы будут обсуждать между собой чужие условия оплаты.
Что делать, если процесс взыскания у нас сложный и не укладывается в стадии счёта?
Для этого существуют смарт-процессы. Они позволяют создать отдельный тип элемента CRM с собственными полями, воронкой, стадиями канбана, правами доступа и связью с задачами и календарём. Работа с проблемной задолженностью выносится в такой процесс и живёт отдельно от продаж.
Сколько времени занимает настройка контроля дебиторки?
Зависит в первую очередь от того, есть ли у компании формализованная кредитная политика и настроена ли интеграция с учётной системой. Техническая часть, то есть поля, стадии, роботы и дашборд, обычно не самая долгая. Дольше всего идёт согласование правил между финансовой службой и продажами, и этот срок стоит закладывать в план отдельно.