«А что если … ?» — пожалуй, самый частый вопрос на уме у риск-аналитика. Его хлеб — строить и проверять гипотезы, например:
А что если мы добавим в модель частоту смены адреса? Станет ли точнее наш прогноз по риску дефолта у стартапов?
А что если учитывать текучку кадров у клиента? Сможем ли мы точнее предсказывать кассовые разрывы?
А что если мы поднимем лимит по овердрафту у клиентов с идеальной платежной дисциплиной? Как это скажется на их лояльности вдолгую?
Привет, Хабр. Меня зовут Алексей Арустамов, я — разработчик и CEO компании Loginom, и в этой статье я хочу рассказать, как аналитики нашего клиента, одной автолизинговой компании, наладили себе (почти без нашей помощи) конвейер проверки гипотез и перестали дергать своих разработчиков на мелкие изменения логики и правил.
Про гипотезы
Для начала договоримся о терминах — что такое «гипотезы» в таком бизнесе как лизинг автомобилей? Да что угодно. Ими могут быть совершенно разные по своим масштабам вещи, например:
А что если увеличить допустимую сумму мелких налоговых штрафов с 10 до 50 тысяч рублей? Те, кто не заплатил за парковку, всё равно платят лизинг исправно.
А что если учитывать не только возраст компании, но и смену директора за последние два года? Если сменили трижды — возможно, стоит попросить поручителя.
А что если полностью отказаться от жёстких стоп-факторов и перейти к взвешенной системе риска, где каждая просрочка лишь увеличивает ставку? Тогда рынок расширится, а потери останутся теми же.
Каждая гипотеза — это новый набор правил или изменение существующего. В кейсе, о котором я тут рассказываю, на данный момент таких бизнес-правил уже стало больше 250. На первых этапах их было около сотни, потом перевалило за 250, а на третьем этапе ожидается под 500 (хотя, думаю, и это не предел). И все эти правила нужно не только придумать, но и сформулировать, объяснить исполнителям, потом проверить на реальных данных, а потом внедрить в боевой контур. И вот тут подходим к главному.
Почему проверять гипотезы по-старинке — страшнее переезда?
Возьмем простую ситуацию. Сидит аналитик, перебирает цифры, и вдруг его осеняет: клиенты, у которых за плечами просрочка по кредитам больше девяноста дней, потом и лизинговые платежи пропускают заметно чаще.
Логично? Вполне.
Тогда рождается гипотеза, сформулируем её примерно так: «А что если добавить проверку на просрочку 90+ дней? Если такая есть — сделка автоматически уходит к экспертам на ручной разбор. Снизится ли тогда доля неплатежей?».
Хорошая мысль. Её бы проверить. Для этого нужно:
Взять историю сделок — кто платил, кто нет.
Сходить во внешний сервис (например, бюро кредитных историй или Контур.Фокус, в случае нашего клиента) и вытащить оттуда данные по просрочкам.
Посчитать новый признак — «есть длинная просрочка или нет» (has_overdue_90_plus).
Прогнать старые заявки через эту новую логику и посмотреть: изменилось бы решение? Стало бы лучше?
Если да — внедрить правило в боевой конвейер.
Всё звучит как обычная инженерная задача. Но тут появляется одно «но», которое портит всю идиллию.
В той компании, о которой я рассказываю, вся эта механика была зашита в CRM. А CRM, как известно, штука для ведения клиентов: заноси контакты, веди сделки, не забывай звонить. Это не движок для бизнес-логики. И уж точно не полигон для экспериментов.
Что это означало на практике?
Чтобы добавить одно-единственное новое правило, аналитик писал задачу разработчикам. Те брали её в работу, и через неделю-другую (а то и третью) выдавали результат. Потом аналитик тестировал, находил ошибку — разработчики исправляли. Ещё неделя. Круг замыкался. Простая правка «сделай порог не 10 тысяч, а 50» растягивалась на полмесяца. А если требовалось запустить новый процесс — скажем, для грузовиков отдельную линейку правил — там и вовсе уходило до трёх месяцев.
Спрашивается: кому охота экспериментировать при таких темпах? Никто не будет ради сомнительной гипотезы «а вдруг точность вырастет на полпроцента» дёргать целый отдел разработки, ждать неделями и молиться, чтобы ничего не сломалось. Вот и крутили то, что уже есть. А новые идеи — они же как ростки: без полива засыхают. В итоге риск-аналитик занимался не проверкой гипотез, а … как бы помягче сказать … документооборотом. И это при том, что настоящая его работа — именно искать, пробовать, ошибаться и находить лучшее. Ну, вы помните в самом начале — “А что если …?”
Подытожу. Изменение одного бизнес-правила занимало 2–3 недели. Запуск нового процесса — до 3 месяцев (см. рис. 1). При таких темпах любая гипотеза становится роскошью. И это — главная боль, от которой наш клиент решил избавляться — нужно было делать другую систему.
А какой она должна быть эта другая система?
Когда вся эта акробатика с бесконечными согласованиями, ожиданием разработчиков и страхом что-то сломать окончательно утомила (а утомила она, судя по срокам, основательно и всех), участники процесса пришли к простой, но очень ёмкой формулировке: «Нам нужна система, где правит бизнес-логика, а не код».
Тут я поясню, а то звучит, как лозунг.
Если аналитик хочет поменять порог просрочки с 10 тысяч на 50 тысяч рублей (об этом кейсе ниже) — он должен иметь возможность сделать это сам. САМ! Зайти и поменять. Без Jira, без разработчиков, без двухнедельных ожиданий.
В итоге они выделили три ключевых фактора, «трех китов» (рис. 2), на которых держится любая приличная среда экспериментов.
Cкорость. Возможность сократить время от идеи до проверки с недель до часов. Если ты можешь проверить гипотезу за обед, ты будешь их проверять. Если на это уходит месяц — ты будешь делать вид, что у тебя нет идей.
Гибкость. Возможность тестировать новые сценарии, менять настройки и добавлять источники данных без оглядки на legacy-код с табличкой «не трожь, а то всё сломается». Бизнес-правила должны стать как сменные картриджи в принтере: старый вынул, новый вставил. И неважно, что внутри — простая формула или нейросеть.
Контроль. Все риск-правила — вещь конфиденциальная — должны быть собраны в одном месте. С понятным логированием, кто, что и когда менял. Чтобы в любой момент можно было ткнуть в любую заявку и получить внятный ответ, почему решение было именно таким.
И вот когда они эти три желания сформулировали, то начали смотреть по сторонам — что на рынке есть, чтобы их закрыть. CRM отпала сразу. Писать свою систему с нуля — долго и дорого. Покупать тяжеловесную BRMS (Business Rule Management System) — значит снова отдать ключи от системы программистам и вернуться к исходной точке.
Так они и пришли к low-code платформам. И, не буду скромничать, наш Loginom подошел им по нескольким причинам, включая те, которые они сами для себя выписали. Это, помимо скорости, гибкости и контроля:
Визуальный конструктор. Для аналитика, привыкшего к Excel, разница как между ездой на механике и на автомате. Все интуитивно понятно.
Гибкие возможности интеграции. Возможность подключать любые источники данных, от API «Контур.Фокус» до корпоративной базы, просто перетаскивая кубики на экране. В большинстве случаев аналитики могут самостоятельно собирать нужные интеграции. Иногда, для особо сложных или нестандартных задач, действительно приходится привлекать разработчика. Но в этом и заключается прелесть подхода: разработчик, единожды создав такую интеграцию, «упаковывает» её в переиспользуемый компонент, эдакий «кубик» в нашей экосистеме. После этого аналитики могут использовать эти «кубики» в своих сценариях десятки раз, уже не дёргая разработчиков.
Модульность. Всю логику можно разбить на независимые подмодели. Работает, как конструктор LEGO: можно изменять один «кубик», не опасаясь, что вся конструкция рассыпется.
О том, как она работает изнутри — ниже.
Как они это построили: устройство конвейера для гипотез
Схема получилась простая и рабочая (рис. 3):
Расшифрую по шагам.
Шаг 1.
CRM‑система, которая принимает заявку от консультанта, собирает все данные (кто берёт, что берёт, на каких условиях) и упаковывает их в JSON — он старый, добрый, простой и предсказуемый. В JSON-объект складывается всё: и контрагенты, и автомобили, и история платежей — всё, что нужно для принятия решения.
Шаг 2.
CRM не стучится напрямую в Loginom, то есть не работает синхронно — сервис может в тот момент перезагружаться, обновляться или, не дай бог, лежать. Вместо этого CRM отправляет JSON в очередь RabbitMQ. Просто кладёт сообщение и идёт дальше заниматься своими делами. Очередь — место надёжное, она не забывает, что в нее что-то положили.
Шаг 3.
Loginom в свободное время забирает сообщение из очереди, разбирает JSON и прогоняет его через 250+ бизнес-правил — и на выходе собирает новый JSON. На выходе формируется JSON-ответ с решением («одобрить», «отказать», «отправить на ручную проверку»), плюс список задач или рекомендаций для консультанта («проверить документы», «запросить поручительство», «уточнить сумму залога»).
Шаг 4.
Loginom формирует JSON-ответ с решением и передает его специальной утилите. Уже эта утилита отправляет его в очередь ответов в RabbitMQ.
Шаг 5.
CRM забирает ответ, показывает его консультанту, консультант действует по инструкции: говорит клиенту «да», «нет» или «подождите, мы проверим».
Теперь пара слов о том, почему этот способ оказался удобным для проверки гипотез. Тут три простых соображения.
Асинхронность. Как я написал выше, если в момент, когда пришла заявка, Loginom временно недоступен (потому что аналитик залил новую версию правил, или сервер перезагружают, или случился мелкий сбой), сообщение не теряется. Оно терпеливо лежит в очереди. Как только Loginom снова в строю — он берёт сообщение и обрабатывает. Ни одна заявка не пропадает. Для экспериментирующего аналитика это важно: можно спокойно обновлять логику в рабочее (!) время, не выключая систему и не боясь, что боевые данные где-то потеряются.
Стандартизация. Все запросы и ответы имеют строгую JSON‑схему. Это значит, что если аналитик захочет добавить в заявку новое поле — например, «средний возраст автопарка» — ему не придется переписывать всю интеграцию. Достаточно расширить схему, и Loginom сам разберёт обновлённый JSON.
Скорость. Среднее время обработки одного сообщения — меньше пяти секунд. То есть консультанту, когда он работает с клиентом, почти не надо ждать. Он загружает тестовую заявку, и через пять секунд видит результат. Можно покрутить параметры, прогнать десяток сценариев за минуту, понять, сработало или нет. Если бы каждая заявка обрабатывалась даже минуту, желание экспериментировать было бы явно скромнее. Да и у клиентов терпение небесконечно.
В общем, схема получилась простая, как угол дома, и надёжная, как швейцарские часы. Клиент её спроектировал сам, поэтому она решает ровно ту задачу, которая у него болела: сделать проверку гипотез рутиной, а не одиссеей.
О том, что происходит внутри Loginom после того, как он забрал JSON из очереди — рассказываю ниже.
4. Что у Loginom «под капотом»?
Итак, запрос попадает в очередь, и Loginom его забирает. Дальше — внутренняя кухня (рис. 4). Для риск-аналитика в ней нет ничего пугающего. JSON, древовидные структуры данных и логические блоки — всё это знакомые и понятные инструменты (иначе, что это за риск-аналитик?).
Значит, сначала платформа парсит JSON и превращает его в древовидную структуру данных. Для тех, кто привык к базам данных, процесс похож на денормализацию вложенной структуры в плоские таблицы. Клиент делился, что на версии платформы 7.2, с которой они начинали, это была довольно кропотливая задача. Ребята ждали нашу следующую версию 7.3, где мы добавили готовый компонент «JSON в дерево», но и на 7.2 справились, самостоятельно собрав сценарий парсинга.
Дальше эта древовидная структура попадает в большой «блок обработки данных». Этот блок — не монолитный скрипт на 5000 строк, а скорее, комод с множеством ящичков. В каждом ящичке — своя независимая подмодель, например:
ящичек «Правила проверки контрагентов по внешним сервисам» (например, «Контур.Фокус»),
ящичек «Расчёт финансовых метрик» (долговая нагрузка, налоги, выручка),
ящичек «Проверка по чёрным спискам»,
ящичек «Внутренний скоринг».
Зачем такая модульность? Всё просто: «Если нужно изменить правило про возраст автопарка, нет необходимости трогать всё остальное. Открыли нужную подмодель, поправили формулу — и поехали. Никто никому не мешает, ничего не ломается». К — конструктор.
После того как все подмодели-ящички отработали, их результаты собираются воедино и переходят в «блок решения». Здесь, собственно, и выносится вердикт. Когда срабатывают правила, то какие-то из них «зажигают» красную лампочку, какие-то — зелёную, какие-то — жёлтую. Система смотрит на всю эту гирлянду и определяет маршрут сделки:
Если всё зелено и сумма небольшая — авторешение «одобрить».
Если есть красный стоп-фактор (например, компания в реестре недобросовестных поставщиков) — авторешение «отказать».
Если что-то жёлтое (порог превышен, но не критично) — сделка уходит в «серую зону».
Про «серую» зону скажу отдельно. Для нее предусмотрен отдельный блок — выставление задач. Тут Loginom, согласно заложенным правилам, формирует список отделов, которые должны пересмотреть заявку. Например, «Служба безопасности» или «Отдел залогов». Эти задачи упаковываются в JSON и уходят обратно в CRM, где консультант уже распределяет их по соответствующим подразделениям.
Но верну вас в Loginom — путь его обработки запроса заканчивается итоговым решением во внутреннем формате. В нем, как я писал выше, собрано всё: результат одобрения/отказа, список задач, дополнительные рекомендации. Потом этот внутренний формат преобразуется обратно в JSON, и ответ уходит в очередь.
Вживую это работает примерно так. Открываем какой-нибудь узел в середине конвейера — там, скажем, имеется таблица с промежуточными данными. Щёлкнул по правилу — увидел, сколько входных параметров зашло в него, на скольких сработало true, на скольких — false. То есть это именно «белый ящик»: любой аналитик может взять любую заявку, пройти по шагам и понять, почему система решила именно так. В этом, кстати, одно из ключевых отличий от ИИ — пойди, попробуй понять, как ИИ пришел к решению; а тут — всё по полочкам и как на ладони.
И всю эту логику, заметьте, аналитики клиента собрали сами, — без нас и почти без своих разработчиков. Это значит, что не мы за них писали правила, не мы разбивали на модули. Они сами пришли на платформу, покрутили одно, другое — и методом проб, ошибок и вот этих самых дешёвых экспериментов — довольно быстро разобрались как правильно спроектировать подмодели для тестирования гипотез (ради которых все и затеивалось, как вы помните).
Сейчас же, когда приходит новый запрос, его прогон по всем этим ящичкам с правилами занимает пять секунд. Каким образом? Об этом далее.
5. Почему эксперименты вдруг стали такими дешевыми?
Благодаря модульности. Вернемся к нашему примеру. Аналитик заметил, что клиенты с мелкими налоговыми штрафами платят исправно, и решил проверить гипотезу: поднять порог для отказа с 10 до 50 тысяч рублей.
В старой системе это была бы эпопея на месяц. В новой — это 15 минут работы самого аналитика (рис. 5). Он открывает нужный «ящичек» — подмодель «Проверка финансовой дисциплины», — находит узел с условием:
задолженность_по_налогам > 10000
Меняет 10000 на 50000. Всё.
Почему это безопасно? Потому что он меняет логику только внутри одного «ящичка». Все остальные части системы этого даже не замечают. По сути, вы с таким же успехом меняете лампочку в комнате — вам не нужно для этого отключать электричество во всем доме.
Возможно, внимательный читатель из разработчиков возразит: «Стоп! А что там с тестированием? Вдруг новое правило даст сбой на каких-то пограничных случаях?». А я отвечу так — в Loginom мы сделали режим отладки. В нем можно взять любую заявку (или десяток таковых) и прогнать их через изменённую подмодель, в обход «боевого» контура. Опять же, это может делать и сам аналитик — прямо из визуального интерфейса — и там он может увидеть промежуточные данные на каждом узле — сколько заявок попало в одну ветку, сколько в другую, какие значения приняли флаги.
Если все работает как надо, аналитик публикует обновлённую подмодель. Сервер Loginom с заданной периодичностью (например, раз в несколько секунд) проверяет наличие изменений в сценариях. Обнаружив новую версию, он загружает ее в память. При этом веб-сервис, принимающий заявки, не останавливается. Запросы, которые уже в работе, завершаются по старой логике, а новые обрабатываются уже с учётом обновлений. Процесс проходит гладко, без остановки конвейера.
Известно, что аппетит приходит во время еды. Здесь мы наблюдали что-то похожее. Когда они только начинали, у них было около сотни правил, и аналитики довольно робко меняли что-то раз в неделю, боясь, что система «ляжет». Сейчас они меняют правила по нескольку раз в день — рутина. И теперь уже совершенно не страшно, что 90% гипотез не взлетают — оставшиеся 10% взлетевших покрывают всё с хорошим запасом.
6. Обстановка сегодня. Напутствия
Таким образом, на стороне клиента сформировалась полноценная команда экспертов по системе поддержки принятия решений (СППР). В ней в основном работают риск- и бизнес-аналитики. Разработчиков привлекают очень редко, только для решения действительно нетривиальных задач. В этом и заключается вся прелесть low-code подхода.
Полный отказ от кода (no-code) мог бы показаться проще для пользователей. Однако в мире enterprise-проектов всегда находятся специфические задачи, не укладывающиеся в готовые сценарии. Поэтому более жизнеспособной оказывается модель, где 95% работы выполняется в визуальном редакторе, а для оставшихся 5% можно точечно привлечь программиста. Так сохраняются гибкость и возможность решать любые, даже самые заковыристые задачи «кровавого энтерпрайза».
Таким образом, наша роль, как разработчиков платформы, свелась к редким консультациям, типа: «Вот здесь, если хотите сделать сложное ветвление, лучше использовать такой-то узел». И всё.
Что у них сейчас в планах? Потихоньку перешагивают уровень простой маршрутизации заявок и двигаются в сторону пересмотра уже одобренных сделок — знаете, бывает, клиент через полгода просит пересмотреть условия, добавить технику, увеличить сумму. Изначально это был отдельный и ручной процесс, но в реальности он вполне поддается автоматизации. Делают.
Еще двигаются в сторону сегментации контрагентов: малый бизнес, средний, крупный — для каждого свой скоринг, свои пороги. Плюс скоринговые карты — числовая оценка риска. Плюс рейтинговые модели, чтобы можно было сказать клиенту: «У вас рейтинг AA, ставка будет вот такая». И мне льстит, что это все делается на нашей платформе.
В целом, мне, как человеку, который продаёт платформу, положено говорить: «Приходите к нам, мы всё сделаем». Не отказываясь от этих слов, я всё же скажу иначе. Вот несколько вещей, которые наш клиент сделал правильно, и которые могут пригодиться вам, если вы решите строить похожий конвейер.
Начинайте с малого. Не пытайтесь автоматизировать всё и сразу. Выберите один самый больной процесс — например, маршрутизацию заявок по экспертам — и сделайте его хорошо. Посмотрите, как оно пойдёт. Освоитесь — добавляйте следующий.
Инвестируйте в аналитиков. Один толковый аналитик, освоивший low-code инструмент, принесет больше пользы, чем целый штат разработчиков, которым нужно объяснять азы предметной области (опять же — им и не надо, им других задач хватает). Отдайте инструмент в руки тех, кто знает бизнес.
Не бойтесь, что 90% гипотез не взлетят. Когда цена ошибки — 15 минут времени аналитика, вы не боитесь ошибаться. И тогда из десяти гипотез одна обязательно «выстрелит» и окупит все затраты.
Используйте «Чемпион/Челленджер». Для проверки гипотез на живом трафике нет ничего лучше (рис. 6). Здесь 95% заявок идут по старой, проверенной модели («Чемпион»), а 5% — по новой («Челленджер»). Сравниваете результаты и, если «Челленджер» оказался круче, делаете его новым «Чемпионом». Безопасно и эффективно.
7. Вместо заключения
Если вы дочитали до этого места — значит, вы либо разработчик, уставший от мелких правок, либо аналитик, который устал ждать, когда эти правки внесут. (Но это неточно). Надеюсь, наш опыт был вам полезен.
Если у вас возникнут вопросы по этому кейсу, пишите в комментарии или личные сообщения — я постараюсь ответить, не разглашая конфиденциальных деталей. И, конечно, вы можете попробовать всё сами: у нас есть общий тестовый стенд (ссылка) и мы подготовили упрощенный экземпляр этого кейса (см. описание ниже).
Всего хорошего, и пусть ваши гипотезы взлетают чаще, чем в среднем по больнице.
P.S. Как потрогать кейс руками
Мы разместили на нашем демостенде упрощённый, обезличенный сценарий конвейера принятия решений. Вы можете зайти и вживую посмотреть, как всё работает.
Что делать:
Зайдя в сценарий, вы увидите несколько узлов с названиями «Заявка...» — это тестовые примеры.
В центре находится узел «Стратегия» — это и есть наш блок принятия решений.
Чтобы запустить проверку, просто перетащите связь от любого узла-заявки ко входу узла «Стратегия» и нажмите кнопку запуска.
На конвейере видно, как:
заходит JSON с несколькими полями (условная заявка);
внутри сценария правила проверяют эти поля;
можно поменять порог в правиле и сразу увидеть, как меняется выход;
можно посмотреть промежуточные данные на любом узле;
в конце формируется JSON-ответ с решением.
Вы увидите, как узлы «зеленеют» — так система показывает путь прохождения заявки. Можете «провалиться» внутрь узла «Стратегия» и пройти весь процесс по шагам, изучая данные на каждом этапе. Это и есть та самая «прозрачность», о которой я говорил.
Этот демо-сценарий показывает упрощенную, но похожую на правду систему поддержки принятия решений. Он включает в себя выбор одной из двух стратегий обработки, проверку по базовым требованиям (возраст, регион), сверку с чёрными списками, расчёт скорингового балла, обращение к эмуляторам внешних сервисов и автоматическое формирование итогового решения — «одобрить» или «отказать». В результате также формируется структурированный ответ с решением и информацией о выполненных проверках.
Спасибо вам за потраченное время, за внимание. Буду рад новым подписчикам.
