Как мы разрабатываем Элизу
Привет, Хабр! Команда ВТБ Лизинга хотела бы поделиться историей о том, как мы начали выстраивать новый IT-ландшафт для системы электронного лизинга автомобилей. Эта система не имеет отношения к знаменитой программе-собеседнику, просто название “e-Leasing” как-то естественно превратилось в Элизу, да так и прижилось.
Старая система перестала успевать за нашими быстро меняющимися потребностями, продиктованными рынком. То и дело сделки не доходили до реализации из-за неповоротливости процессов, бумажной бюрократии и технических проблем с перегруженной информационной системы. Мириться с этим дальше было нельзя.
[Что же мы сделали?]
Чего хотят клиенты
Клиенты хотят быстро согласовать договор и получить машину или сразу партию машин чуть ли не в этот же день. Они не любят ждать, и это понятно, потому что простой бизнеса равно потеря денег. И уменьшить время ожидания в наших силах. На старте проекта мы посчитали, что если всё получится, число совершаемых сделок увеличится более чем на 20%.
Мы поняли, что чтобы выиграть в конкурентной борьбе, нам надо сократить сроки проведения лизинговой сделки на всех этапах: от подачи заявки до выдачи автомобиля. Параллельно с этим необходимо упростить и упорядочить бизнес-процессы, избавиться от бумажных документов и дать клиентам возможность заключать сделки удалённо, в электронном формате. Эти изменения охватывают все стороны процесса: маркетинг, продажи, экспертизы, верификацию, принятие решений — в общем, нужна полная автоматизация.
Мы можем вполне амбициозно заявить, что на данный момент ведём крупнейший проект в сфере российского автолизинга. В результате мы кардинально увеличим скорость продаж и создадим полностью безбумажную систему, где клиент встречается с менеджером лишь на заключительном этапе сделки во время передачи автомобиля. С технической точки зрения это значит выстроить новый IT-ландшафт, подготовить и реструктурировать стек технологий и, как бы пафосно это ни звучало, произвести глобальную цифровую трансформацию.
Ну, а начать надо было с замены действующей CRM.
Зачем менять CRM
Проще всего, конечно, ничего не менять. Разработчики хорошо знакомы со старой платформой, можно использовать наработанный код, и вообще внедрение нового всегда требует периода адаптации. Но иногда изменения неизбежны.
Сколько ни занимайся рефакторингом, сложный софт в итоге утрачивает изначальную стройность. Накапливается технический долг, структура данных становится неоптимальной, реализация бизнес-процессов и фич — чересчур сложной. Как результат — баги и нестабильность. Количество жёстко запрограммированной логики увеличивается; соответственно, повышаются и трудозатраты на разработку новых возможностей. И всё это напрямую влияет на отказоустойчивость и стабильность работы самой системы.
Кроме того, со скоростью света устаревают сами технологии, а некоторые вендорные продукты уходят в прошлое. Чего только стоит отказ Microsoft от дальнейшего развития технологии Silverlight, на которой у нас было разработано большое количество приложений и модальных окон. Сложность ещё и в необходимости установки данного компонента на рабочие станции пользователей. Да и технология работает теперь только в устаревших браузерах Internet Explorer, от которых в ближайшей перспективе Microsoft также планирует избавиться. Всё написанное на Silverlight вполне успешно мигрировало на JavaScript в виде Angular и React.
Немало проблем у нас было с сильно кастомизированным MS Unified Service Desk. Сам продукт, может быть, и классный, если бы не идея с толстым клиентом, который доставляет немало хлопот при установке обновлений. Да и ведёт он себя иногда непредсказуемо, как и MS E-mail Router. На эту тему можно писать отдельные трактаты, но зачем, ведь всё это мы оставляем в прошлом. И переносим функционал в отдельные компоненты нашей будущей сервис-ориентированной архитектуры.
Microsoft BizTalk... Тут надо выдержать минутную паузу… Почему? Потому что сам вендор однажды чуть не поставил данный продукт на грань выживания и как будто вывел его из эксплуатации. Правда, потом одумался и вернул. Наверное, не стоит объяснять, что любая ESB (в простонародье шина), отслужившая верой и правдой более 10 лет, рано или поздно попадает в разряд Mission Critical System. Чем больше потоков проходит через огромные графы оркестровок, тем медленнее работает интеграция. И сколько ни наращивай мощность железа, ничего не помогает. Всё это ещё усугубляется дефицитом кадров, знакомых с платформой, готовых развивать и сопровождать написанное (зачастую захардкоженное разными специалистами за многие годы).
В общем, любая крупная компания со множеством информационных систем (более 40) рано или поздно упирается в вопрос о дальнейшей эксплуатации шины или же начинает задумываться о том, чтобы различные типы интеграций реализовывать разными способами. Мы не исключение. Но об этом чуть позже.
Ну и главная причина замены CRM была продиктована самой компанией Microsoft, когда она сняла с сопровождения используемую нами платформу MS Dynamics CRM 2016, тем самым дав нам стимул развиваться и идти вперёд.
Выбор
Составив план действий, мы приступили к выбору будущей платформы. Первым делом проанализировали отчёты Forrester и Gartner. Учли и опыт использования CRM в финансовом секторе РФ. Если интересно, можете взглянуть на обзор CRM в банковской отрасли, обзор CRM в лизинговой отрасли и обзор CRM в российских компаниях на момент нашего выбора. В результате анализа в лонг-лист попали 14 CRM.
Далее мы ужесточили требования отбора и сформировали шорт-лист финалистов, отсеяв облачные платформы. Ведь нам нужен только On-Premise (то бишь локальный) софт:
Дальше путь известен. Определяем критерии выбора. Формируем сравнительные таблицы (таблица 1, таблица 2, таблица 3). Устанавливаем весовые коэффициенты для критериальной модели. Отбираем платформы с максимальным набором возможностей и минимальными бизнес-рисками. И в финал проходят… *барабанная дробь*... Microsoft Dynamics 365 и Terrasoft Creatio.
Далее пошли тесты-кейсы с различными потенциальными подрядчиками, референс-визиты в Microsoft и «Террасофт», переговоры по минимизации стоимости лицензий и премиальной поддержке. По итогу победила MS Dynamics 365: она в ВТБ уже была, а кроме того Microsoft дал нам неплохую скидку и обещал индивидуальную поддержку. Кстати, выбрав знакомую платформу, мы минимизировали риск демотивации нашей команды CRM, а также смогли привлечь в проект крупных подрядчиков, специализирующихся на этом продукте (на текущий момент их уже пять), и приобрели статус VIP-клиента Microsoft.
Как менять CRM
Возможны два сценария: Big-Bang и Step-by-Step.
В первом случае нужно разработать и протестировать полностью готовое решение, затем подготовить и протестировать миграцию данных, провести генеральную репетицию переключения и работы всех участников на новой платформе, и, наконец, в назначенный день «выключить» старую платформу и «включить» новую.
С точки зрения разработки это наилучший вариант. Мы сразу получаем готовое решение по окончании глобального проекта. Но и минусов достаточно:
долгий, дорогой проект;
отложенная ценность для бизнеса;
высокий риск ухода реальной потребности от того, что будет в итоге сделано.
Кроме того, придётся продолжать доработки действующей платформы. Наконец, опыт, сын ошибок трудных, говорит нам, что ожидание «дня X» может растянуться ох как надолго. Скорее всего, с первого раза не всё получится, и в последний момент вдруг выяснится, что чего-то разработчики не учли, а систему придётся откатывать назад. Так вот, каждый такой «день X» стоит недёшево. Немного рискованно, не правда ли?
В сценарии Step-by-Step мы, что называется, отрубаем хвост по частям и переходим на новую платформу постепенно. Выбираем наиболее критичные участки — либо проблемные с технологической точки зрения, либо дающие наибольшую ценность для бизнеса, — затем разрабатываем перспективное решение с ограниченным (пилотным) функционалом. После этого запускаем пилотный процесс/продукт на ограниченном объёме бизнеса.
Таким образом, мы пошагово переходим на новую платформу, параллельно настраивая и дорабатывая её, а также связанные с ней микросервисы, обслуживающие сразу несколько систем. Плюсов здесь много:
ценность для бизнеса появляется раньше (на этапе пилотного запуска);
риски становятся более управляемыми (по ходу реализации пилота можно корректировать приоритеты проекта);
меньшие вложения в старт.
Из минусов можно упомянуть более трудоёмкий процесс разработки и необходимость поддерживать обе платформы во время переходного периода. Впрочем, такая необходимость есть и в сценарии Big-Bang.
Поэтому, проанализировав риски, сроки и влияние на текущий бизнес, мы остановились на сценарии постепенной замены CRM (Step-by-Step).
Как мы работаем
Сейчас в проекте «Элиза» задействовано около 150 аналитиков и разработчиков. Команда свежая; многие, в том числе и руководство, пришли совсем недавно. Мы двигаемся по двенадцати направлениям. Самое главное — это CRM, где задействовано наибольшее количество ресурсов на стеке .NET (C# и T-SQL) и JavaScript.
Но не надо думать, что всё делается только в MS Dynamics 365. Это лишь часть общей цепочки омниканального решения, его фронт-офисная составляющая. Выбор CRM был иллюстрацией того, насколько тщательно мы подходим к отбору используемых в проекте технологий. Аналогичный анализ проводится при выборе других модулей и компонентов.
Например, в качестве брокеров сообщений у нас используется небезызвестные RabbitMQ и Apache Kafka с технологическим стеком на Java. Понятно, что эти решения приходят для замены ESB MS BizTalk во благо прогнозируемой отказоустойчивости, которая достигается благодаря настраиваемой контейнеризации и горизонтальному масштабированию, зеркалированию и другим модным словечкам, а также гарантированной доставке передаваемых интеграционных потоков. Теперь у нас появились простые правила выбора интеграционных решений для бизнес-задач. Их краткое описание можно увидеть на следующей картинке:
Наверное, у вас возник вопрос: зачем нам сразу два брокера сообщений? Об этом, а также о внедрении новой парадигмы в интеграционном слое мы обязательно расскажем в отдельных статьях, которые, надеемся, вызовут интересные дискуссии с читателями.
В нашем решении работает система распознавания документов. Технология Optical Character Recognition должна преобразовывать различные форматы доков (PDF-файлы, сканы, фото), необходимых для одобрения лизинговой сделки, в редактируемые формы с возможностью поиска. Документы клиентов распознаются и вводятся в систему, что в разы ускоряет проведение сделки и исключает личный контакт. Важный аспект внедрения OCR заключается и в том, что мы не используем продукты Adobe. Здесь задействован ИИ: обучаемые и самообучаемые модели с использованием C++, JS, Python и др. Понятно, что без нейронных сетей уже никак не обойтись.
Интересная тема — работа с рисками. Движок принятия решений (Risk Engine) нужен для оценки потенциального клиента. Технология позволяет строить аналитические модели, используя большое количество источников информации. Это и внутренняя информация по нашему клиенту, если он постоянный, и его кредитная история, ну и другие критерии для оценки лизингополучателя с точки зрения его платёжеспособности. В RE у нас синергия с банком ВТБ благодаря продукту Experian Power Curve.
Мы интегрируемся с партнёрами и госорганами, используя API. С госорганами это происходит в рамках государственных программ, таких как введение электронного ПТС (подробнее здесь). С партнёрами же мы извлекаем общедоступную информацию по клиентам из внешних источников: например, ЕГРЮЛ, ЕГРИП, ФНС, Росстат, ФССП, ЕФРСБ, МВД, ЦБ РФ, БКИ и др. Интегрируемся с сервисами, которые дают информацию для идентификации клиента (скажем, сервис «Госуслуги»). Далее через API получаем информацию от телематического оборудования.
С клиентами мы взаимодействуем в личном кабинете (Angular) на сайте компании. Там в удобных форматах доступна информация о договоре, транспортном средстве, страховом полисе и взаиморасчётах. Клиент также может задать вопрос персональному менеджеру в чате (Jivo) и оперативно получить ответ. В этом году планируем запустить мобильное приложение, которое ещё больше упростит и ускорит наше взаимодействие с клиентами. При этом мы не планируем писать приложение на кросс-платформе вроде React Native или подобных. Разработка будет вестись на нативных языках. Пока выбор пал на Kotlin, Java и Swift. Об этом обязательно напишем после успешного внедрения.
Вот он какой, личный кабинет клиента ВТБ Лизинга
Наши планы
В будущем хотим использовать технологии RPA (Robotic Process Automation). Программные роботы и искусственный интеллект позволят автоматизировать бизнес-процессы с целью достижения операционной эффективности (да здравствует автоматизация!).
На финальной стадии у нас находятся внедрение сервисов конструктора печатных форм (.NET), способного формировать документы в различных вариациях, версиях и форматах из любой системы, а также калькулятора лизинговых платежей (.NET) с собственным корпоративным интерфейсом. Кроме того, скоро появится API для вызова из «Личного кабинета», мобильного приложения или «Справочника транспортных средств» (.NET Core). Через этот API менеджер и клиент получат возможность конфигурировать желаемый предмет лизинга, сравнивать его с одноклассниками, получать выгодные предложения от поставщиков и даже бронировать машину.
В общем, планов у нас много. Стратегия цифровой трансформации в целом готова и потихоньку реализуется. Проект рассчитан на три года. В середине октября планируем запустить пилот. Что мы должны получить в результате:
мгновенная скорость принятия решений для 70% клиентов;
возможность проведения безбумажной сделки;
перевод 100% сделок на новую CRM;
перевод 30% сделок на дистанционный формат.
Уже сейчас наблюдается существенное ускорение времени сделки: оно сократилось от недели и более до нескольких дней. А в перспективе планируем сократить его до нескольких часов.
Поскольку процесс продолжается, история на этом не заканчивается, так что следите за постами блога, где мы будем рассказывать о нашем прогрессе. Кстати, наша команда ещё растёт, мы открыты для обратной связи и новых лиц. Будем рады вашим мыслям и соображениям в комментариях!