CRM для факторинга: от управления клиентской базой к операционной платформе

От воронки продаж к операционному контуру

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

Ключевые отличия:

1. Участники процесса: в сделке три стороны: фактор, поставщик и дебитор. Связи между ними многоуровневые: один поставщик может работать с несколькими дебиторами, и наоборот.
2. Объект управления: в факторинге недостаточно управлять карточкой клиента. Нужно контролировать связку поставщик — дебитор — документы — лимиты — риски. Лимит может устанавливаться на дебитора, поставщика, группу компаний или на связку контрагентов.
3. Процессный подход: CRM в факторинге выходит за рамки клиентской базы и воронки. Она становится рабочей системой для продаж, риск-подразделения, операционного блока, юридической и финансовой функций. Через CRM проходят заявки, согласование условий, контроль лимитов, обработка документов и статусы финансирования.
4. Динамика риска: в факторинге риск меняется по ходу сделки. Поступают документы, выбираются лимиты, возникают просрочки, дебитор отклоняет поставку. Система должна мгновенно реагировать на эти события и показывать актуальную картину, а не только общий статус сделки.

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

Когда Excel, 1С и «кастом» тормозят рост

Растущие факторинговые компании могут столкнуться с рядом системных проблем, используя собственные разработки, Excel, а также 1С.

• Excel и почта: контроль документов, лимитов, риск-решений и выплат становится крайне сложным. Версии таблиц расходятся, знания о процессе остаются у отдельных сотрудников, а ключевые решения зависят от «ручного» фактора.
• 1С: система отлично поддерживает бухгалтерский и финансовый учет, но зачастую неудобна для управления продажами, гибкими согласованиями, задачами и обработкой исключений. Эти процессы выносятся в отдельные сервисы или выполняются вручную, провоцируя разрозненность данных.
• Собственные разработки: они учитывают особенности бизнеса на момент создания, но изменения продуктов, риск-политики и интеграций требуют постоянной доработки. Скорость развития теперь зависит от ограниченного числа внутренних специалистов.

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

Требования к платформе: гибкость, интеграции, контроль и масштабирование

Факторинговые компании различаются по продуктовой линейке, структуре согласований и правилам риск-менеджмента, так что подобрать универсальное решение для них крайне сложно. Платформа должна стать, по сути, операционной системой. А при выборе стоит учитывать не только текущие потребности, но и перспективу роста, изменения продуктовой модели и усложнение процессов. Готовые функции важны, но не менее значима способность системы адаптироваться к уникальной логике конкретного бизнеса.

1. Поддержка сложных связей между контрагентами

   Факторинговая сделка не сводится к паре «клиент — договор». В ней участвуют поставщик, дебитор, группа компаний, поручители и другие связанные стороны. Система должна позволять вести такие многоуровневые связи без дублирования карточек, ручных таблиц и неформальных согласований. Все участники сделки должны быть видны в контексте друг друга, а не изолированно.

2. Настройка процессов, форм и маршрутов согласования

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

   Важно, чтобы система поддерживала:

   • гибкую настройку этапов сделки и заявки;
   • изменение маршрутов согласования под внутренние регламенты;
   • кастомизацию форм и полей под конкретные продукты и сценарии;
   • управление исключениями и нестандартными ситуациями без остановки основного процесса.

   Чем проще вносить изменения, тем быстрее компания реагирует на рыночные вызовы и требования бизнеса.

3. Интеграция с ЭДО, учетными системами и внешними сервисами

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

   Система должна:

   • получать документы из СБИС, Диадок или другого оператора;
   • сопоставлять их с контрагентами и договорами автоматически;
   • контролировать подписание и отклонение;
   • передавать подтверждённые данные в расчетный модуль.

   Кроме ЭДО, важна интеграция с учетными системами (1С, SAP и др.), скоринговыми сервисами, внутренними источниками данных и другими ИТ-системами компании. Без этой связки сотрудники вынуждены скачивать и пересылать файлы, вручную переносить статусы и повторно сверять данные — что становится серьезным препятствием для масштабирования.

4. Разграничение прав, аудит и контроль изменений

   В факторинговом процессе участвуют разные подразделения: продажи, риск-подразделение, операционный блок, юридическая и финансовая службы. У каждого свои задачи, зоны ответственности и объем доступа к данным.

   Платформе нужно обеспечивать:

   • гибкое разграничение прав доступа на уровне объектов, полей и действий;
   • полный аудит всех действий пользователей — кто, когда и что изменил;
   • контроль версий и истории изменений по ключевым данным (лимиты, условия сделки, статусы).

5. Возможность поэтапного развития системы

   Факторинговый бизнес развивается — и система должна эволюционировать вместе с ним. На старте достаточно автоматизировать контрагентов, заявки, документы, базовые риск-проверки и управленческую отчетность. Сложные расчеты, продуктовые условия и комитетные процедуры можно внедрять следующими этапами.

   Поэтому архитектура платформы должна позволять:

   • запускать проект с минимально жизнеспособного функционала (MVP);
   • постепенно добавлять новые модули и сценарии;
   • не переписывать систему каждый раз при изменении требований;
   • масштабироваться без потери производительности с ростом портфеля и числа пользователей.

6. Управление исключениями и нестандартными сценариями

   В факторинге всегда есть место исключениям: дебитор отклоняет поставку, просрочка, превышение риск-порога, нестандартные условия договора. Система не просто регистрирует такие случаи, а активно на них реагирует.

   Важно, чтобы CRM могла:

   • настраивать стоп-факторы и автоматические проверки;
   • создавать задачи риск-менеджеру при наступлении критических событий;
   • останавливать движение документа или блокировать финансирование до принятия решения;
   • уведомлять ответственных и вести историю работы с исключениями.

7. Инструменты для управленческой отчетности и аналитики

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

   Ключевые отчеты:

   • контроль портфеля и лимитов;
   • просрочка и риск-профиль;
   • загрузка подразделений и сроки обработки заявок;
   • экономика сделок и маржинальность.

С чего начать: пошаговый план

Макеты, экранные формы и отчеты — плохая точка старта для факторинговой CRM. Проекты, которые начинаются с интерфейсов, часто буксуют: команда рисует экраны, так и не определившись, какие процессы и в какой последовательности она автоматизирует. Стартовать нужно с логики самого бизнеса. Кто участвует в сделке? Какими данными обмениваются стороны? Какие решения принимаются на каждом шаге? Ответы на эти вопросы задают архитектуру будущей системы.

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

Шаг 1. Сначала — карта участников, а не карточки

Классический кредит устроен проще факторинговой сделки. Здесь как минимум три стороны — фактор, поставщик, дебитор, — а на деле связанных сущностей еще больше. Задача шага: собрать единую модель данных, где все участники и объекты связаны друг с другом, а не разложены по изолированным карточкам.

Шаг 2. Пройти процесс целиком — от заявки до погашения

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

Шаг 3. Назначить события, на которые система реагирует сама

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

Шаг 4. Очертить границы: что CRM не делает

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

• какие данные остаются в учетной системе;
• какие поступают из ЭДО;
• где выполняются расчёты (в специализированном модуле);
• какие данные пользователь видит в CRM;
• какие интеграции нужны для синхронизации.

Шаг 5. Автоматизировать первым то, что дает измеримый эффект

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

С чего начать:

• контрагенты и связи — единый реестр поставщиков, дебиторов и групп компаний со всеми связями;
• заявки и сделки — этапы, статусы, задачи, согласования;
• документы и ЭДО — получение, привязка к сделке и контрагентам, контроль статусов;
• базовые риск-проверки — лимиты, стоп-факторы, автоматические уведомления;
• управленческая отчётность — портфель, лимиты, просрочка, загрузка подразделений.

Что можно отложить:

• сложные продуктовые расчеты и кастомизированные формулы;
• комитетные процедуры с многоступенчатыми согласованиями;
• глубокую интеграцию со скоринговыми и внешними сервисами;
• массовый перенос исторических данных и закрытых сделок.

Шаг 6. Оценить данные и спланировать миграцию (если проект не первый)

Если у компании уже есть данные в старых системах — Excel, 1С, самописных решениях, — их предстоит перенести на новую платформу. Этот этап часто недооценивают, хотя миграция «грязных» или неструктурированных данных способна нарушить работу системы и привести к управленческим ошибкам.

Кейс СберФакторинга: построение операционной CRM-системы, которая меняется вместе с бизнесом

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

Вместе с ИТ-интегратором НОРБИТ было принято решение о переходе на low-code платформу BPMSoft. Ключевая задача заключалась не в простой замене CRM, а в пересборке рабочего контура с сохранением полезного пользовательского опыта и устранением накопленных ограничений.

В рамках миграции на новое ПО команда НОРБИТ систематизировала создание и обработку заявок, контрагентов и потенциальных клиентов, автоматизировала генерацию документов. Интегратор упростил работу с факторинговым калькулятором и реестром поставок. В новой CRM созданы рабочие места для всех участников и настроен единый интерфейс сделок. Система позволяет отслеживать исполнение процессов на всех этапах работы с клиентом, анализировать нагрузку и эффективность воронки продаж в режиме реального времени.

Переход на BPMSoft стал для СберФакторинга не заменой одной CRM на другую, а частью более широкой трансформации ИТ‑ландшафта.

Компания получила платформу, которая:

• объединяет работу с заявками и клиентскими данными в едином контуре;
• поддерживает интеграции с внутренними системами экосистемы Сбера;
• позволяет регулярно развивать процессы и адаптировать интерфейсы под потребности пользователей;
• обеспечивает рост нагрузки (+20% заявок) без увеличения штата;
• сокращает время операций (заявка — с 3 до 1 минуты, калькулятор — с 10+ до 4 кликов);
• создает основу для внедрения AI, чат‑ботов и полноценного цифрового клиентского пути.

От функций к инфраструктуре роста

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

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