Привет, Хабр! На связи Настя Трехбратская, Product Owner в Garage Eight. Мы развиваем инвестиционную платформу для клиента, и бо́льшая часть ее функционала связана с отслеживанием рисков. Это сложная задача, так как клиенту нужно соблюдать баланс между опытом пользователей, стабильностью сервиса и финансовыми рисками.
До недавнего времени мониторинг был полностью ручным. Сотрудники операционного департамента клиента ежедневно проверяли 4–6 разрозненных систем, а конечный результат во многом зависел от уровня знаний и опыта конкретного специалиста.
В таких условиях сложно масштабироваться, поэтому к нам обратились с задачей построить автоматическую риск-операционную систему с нуля. В статье рассказываю, как мы создали продукт, который оказался полезен и команде клиента, и конечным пользователям.
Как операционный департамент работал раньше
Главная задача департамента — отслеживать аномалии: например, сбои в системе или случаи читерства. Команда должна увидеть риск, проверить его и быстро принять решение, потому что даже минимальное время простоя платформы приводит к большим финансовым потерям.
В привычной для сотрудников схеме было несколько ограничений:
-
Множество разрозненных инструментов. Для проведения одного цикла проверки сотруднику приходилось собирать данные из нескольких источников и сопоставлять их вручную.
-
Высокие временные затраты. Один цикл мониторинга занимал 30–40 минут, а таких подходов могло быть до трех в день.
-
Задержка в обнаружении рисков. Из-за человеческого фактора часть сигналов проходила незамеченной — о них могли узнать спустя две недели. К этому моменту компания уже успевала понести убытки.
-
Длительный онбординг. Чтобы разобраться во всех системах и научиться писать запросы, новичкам требовалось от двух до трех месяцев. Именно поэтому эйчарам клиента приходилось нанимать только высококвалифицированных технических специалистов.
В итоге ручной мониторинг не выдерживал нагрузки, а бизнес часто терял ресурсы.
Почему не рассматривали готовое решение
На рынке есть много систем для риск-менеджмента, однако решили сфокусироваться на идее собственного продукта. И вот почему:
Независимость от обновлений
Когда берете готовый B2B-продукт, вы привязываетесь к его дорожной карте. Разработчик стороннего софта ориентируется на рыночные запросы. В отличие от такого решения, собственный продукт обеспечивает полную автономность.
Возможность масштабироваться
Внешние платформы финансово привлекательны только на начальных этапах. Когда вы растете, стоимость лицензий также увеличивается, возникают трудности с кастомизацией. В долгосрочной перспективе свое решение оказывается гибче и дешевле.
Учет специфики бизнеса
У каждого продукта своя архитектура данных и логика рисков. Мы знаем нюансы клиентской платформы и можем максимально точно учесть их в разрабатываемом инструменте.
С какими трудностями мы столкнулись при разработке
Есть две проблемы, с которыми мы работаем:
Сопротивление команды клиента
Несмотря на то что новый инструмент объективно удобнее, быстрее и точнее, люди всё равно тянутся к привычному формату. Это стало заметно благодаря глубинным интервью: при разборе сложных кейсов специалисты рефлекторно возвращаются к старым интерфейсам.
Решение. Здесь важно действовать постепенно: например, клиент не стал сразу отменять старые дашборды, но отключил часть функционала. Некоторые процессы команда может проводить как в старом флоу, так и в новом — это дает время на адаптацию. Однако скоро рабочие процессы полностью перейдут на новый продукт. Кроме того, мы проводим обучение для сотрудников клиента: показываем, почему новые флоу лучше и как они сокращают время на мониторинг.
Попытки сотрудников автоматизировать часть процессов самостоятельно
В операционном департаменте работают опытные ребята, и они тоже пытаются автоматизировать свою рутину. Проблема в том, что это делается подручными средствами, а команда разработки даже не в курсе. Такие инструменты немасштабируемые и часто недостаточно точные: они могут подтягивать данные из старых источников.
Решение. Мы действуем через операционных лидов и учим их мыслить с точки зрения продукта. Проводим границы: если речь о простой задаче вроде сбора несложного отчета, то мы не возражаем, что сотрудник помог себе сам. В задачах, где важны полнота и точность данных, самописный костыль создает ловушку. В этом случае мы просим приходить к разработке с проблемой, а не со своим готовым решением.
Как процессы устроены сейчас
Мы решили не создавать сразу идеальную систему мониторинга, а подготовить минимально жизнеспособный продукт (MVP). Изначально точность алертинга достигала всего 15%, но этого было достаточно, чтобы протестировать проект. После мы собрали оценки операционного департамента и проанализировали, где улучшить процессы, каких функций не хватает и какие пороговые значения для рисков выставить. Через несколько месяцев продукт доработали, а точность довели до 99%. Кстати, за эту разработку мы получили награду Client First на годовом таунхолле внутри компании.
Что получилось в итоге:
-
Мы сократили время между моментом, когда риск появился, и реакцией компании в четыре раза. Кроме того, данные в новой системе более точные.
-
Продукт показывает аномалии в клиентском поведении, которые могут привести к фродовой активности, а значит, к затратам на исправление ошибок. Так мы косвенно влияем на операционные расходы клиента.
-
Чтобы проверить риски сейчас, достаточно открыть только одну платформу. Так мы снизили требования к позиции сотрудника операционного департамента и сократили косты клиента на наём. При этом мы продолжаем оптимизировать функционал: например, улучшаем работу с овервью.
Сейчас платформа закрывает потребности операционного департамента внутри компании клиента, но мы видим потенциал инструмента и продолжаем его развивать. У нас есть амбиция — сделать софт настолько хорошим, чтобы другие компании захотели его купить.
А как вы справляетесь с рисками бизнеса? Пишите в комментариях, какие решения применяете.
ссылка на оригинал статьи https://habr.com/ru/articles/1065208/