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

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

Сразу скажу, что бизнес составляющая процесса в данном случае рассматриваться не будет. То есть плох или хорош, например, уровень Approval Rate 70%, оставим для дискуссий. Сейчас перед нами другая задача - показать что процесс работает стабильно, качественно и без аномалий. В нашем примере это значит, что нам важно что распределение Approval Rate вообще существует и не принимает экстремальных значений 0% и 100% (разумеется, вы можете считать экстремальными и другие цифры). Если же показатель превысил порог, то это повод для ручного анализа проблемы, в результате которого должно появиться как минимум объяснение ситуации, а в худшем случае исправление ошибки.

1. Ключевые показатели

Если цель понятна, определимся с ключевыми показателями, дающими общую характеристику работоспособности процесса принятия кредитного решения. Это можно сделать задав себе вопрос "Что обязательно должно присутствовать или отсутствовать в заявке, по которой вынесено кредитное решение?"

Пример простых показателей:

• Не пустое решение (обязательно значение из списка. Например, одобрить или отклонить. null - не корректное значение)
• Наличие ставки по одобренным заявкам
• Сумма одобренного кредита 
• Одобренный срок кредита
• Соблюдение SLA (тайминга) обработки заявки
• Отсутствие ошибок типа ERROR и WARNING в логе обработки
• прочее

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

Пример показателей распределения/агрегирования:

• Распределение принимаемых решений (доли одобренных/отклоненных заявок)
• Средний срок одобренного кредита
• Распределение одобренных ставок (для того, чтобы сразу понимать что ставки находятся в пределах тарифов банка и не принимают аномальных значений)
• прочее

2. Аналитический разрез

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

Это могут быть:

• кредитные продукты ("0/0/10", "Отличные наличные", "Авто без переплаты" и т.д.)
• даты отчета
• направления кредитования (POS, автокредит, ипотека и т.д.)

3. Выводы

Отчет должен содержать выводы, так как это одна из важнейших частей любой аналитической активности. Без них отчет - это просто цифры, посмотрев на которые сторонний человек почти наверняка задаст вопрос "И что? Это нормально, хорошо или плохо?"

Так как в начале мы договорились, что оцениваем только качество работы процесса, то и выводы у нас должны быть соответствующие. А еще лучше, содержащие бинарную логику "нормально"/"стоит обратить внимание".

Вывод нужно ставить напротив каждого из рассматриваемых показателей. Для этого придётся определить границу до которой мы считаем показатель "нормальным" и "не нормальным" при пересечении этой границы. Делается это экспертно, аналитически или математически. Возможно, для определения "нормальности" придется пообщаться с различными подразделениями внутри банковских рисков. Но на первое время можно ограничиться и собственным экспертным мнением.

4. Построение отчета

С теорией все. Можно переходить к практике. Я покажу как паспорт качества будет выглядеть в Excel, потому что он есть у всех =) Но вообще, выбор инструмента ограничивается вашими знаниями и необходимостью автоматизации.

1. Выбираем показатели. У меня это будут:

• Общее количество обработанных заявок
• Количество заявок с пустыми решениями
• Количество заявок, автоматически обрабатывающихся более 10 минут
• Количество заявок с ошибками типа ERROR и WARNING в логе обработки
• Распределение принятых решений
• Группы одобренных ставок

2. Выбираем разрез. Я хочу посмотреть данные по POS кредиту и Автокредиту за май

3. Прогнозируем выводы. Решаем что будем считать нормальным и не нормальным. В разрезе показателей "нормальным" у меня будет считаться:

• Общее количество обработанных заявок - больше нуля
• Количество заявок с пустыми решениями - отсутствуют
• Количество заявок, автоматически обрабатывающихся более 10 минут - отсутствуют
• Количество заявок с ошибками типа ERROR и WARNING в логе обработки - отсутствуют
• Распределение принятых решений - больше 0% и меньше 100%, отсутствие варианта "пусто" (null)
• Группы одобренных ставок - отсутствует вариант "пусто" (null)

Все остальные варианты будут относиться к категории "стоит обратить внимание" на основании которого будет проводиться детальный ручной разбор

4. Имея все вводные, делаем выборку, отбирая майские заявки по POS кредиту и Автокредиту и строим паспорт качества. Получается так:

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

Как правило, возникшие ошибки относятся либо к типу логических (что-то пропустили при внедрении стратегии проверки), либо к типу технологических (сетевой сбой, зависшая служба, перезагруженный сервер). Однако, бывает и так, что аномалия находится вовне и тогда исправление не зависит от вашего подразделения. Например, недоступность внешних аналитических сервисов БКИ. В таких случаях нужно просто объяснить наличие проблемы и архитектурно закрыть эту часть процесса на своей стороне так, чтобы в будущем такие внешние воздействия влияли на процесс минимально и ожидаемо (например, при отсутствии ответа БКИ, отправлять заявку не в ошибку, а на ручную проверку).

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

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

И помните, что если до текущего момента ваш процесс работал без присмотра, первичное построение паспорта качества может выявить множество "пасхальных яиц" о которых вы не подозревали и которые могут вызвать дискомфорт при демонстрации руководству. Но качество того стоит=) Как говорил один умный человек: "Каждый имеет право на ошибку и обязанность её исправить".