Как стать автором
Обновить

Ремонтные работы или IT-трансформация? Как мы разработали архитектуру с нуля и создали платформу для малого и среднего бизнеса

Время на прочтение 8 мин
Количество просмотров 18K
Привет, Хабр! Мы в МКБ разработали новый диджитал-подход к обслуживанию малого и среднего бизнеса. Хотим поделиться, как нам удалось создать IT-платформу с нуля, какие технологии и решения нам помогли, с какими трудностями сталкивалась команда и как менялись наши задачи. Подробности под катом.

Ранее мы уже рассказывали о том, как внедряли Agile и как благодаря ему пересмотрели все, начиная от иерархии и заканчивая подходом к разработке продуктов. Аналогичная трансформация произошла с проектом МСБ (продукты для малого и среднего бизнеса). По заветам Agile мы решили подать материал не безлико от абстрактного корпоративного «мы», а группой соавторов-представителей ключевых направлений и команд в проекте.

В начале была идея

Виктор Жидков
директор департамента малого и среднего бизнеса
Прежде чем выстраивать сервисы, необходимо разработать фундамент. В нашем случае это непосредственно платформа для улучшения продаж. Логика ее структуры предопределяет принцип работы внедряемых сервисов. Логику мы сформулировали так: в продуктах для МСБ всегда было много проблем, связанных с историческим паттерном в общении с клиентом и организации продаж. Именно эта невозможность контролировать все точки соприкосновения и, собственно, сам контакт менеджера с клиентом должна стать отправной точкой для разработки новой системы.
Разумеется, на рынке есть готовые CRM-решения, но их универсальность не позволяет подстраиваться под уникальные клиентские сценарии и сценарии продаж. И тогда мы решили сделать платформу, которая бы объединила в себе CRM- и BPM-компоненту. В этом случае мы представили кастомизируемый процессный модуль, чтобы можно было создавать статусную модель и автоматически развивать воронку. Изначально проектировать её монолитной неправильно — микросервисная архитектура сегодня показала свой потенциал, так что мы решили развивать нашу платформу именно в этом ключе. Мы рассмотрели основные точки контроля контактов менеджеров и клиентов: продолжительность самого разговора, количество встреч, их результативность, какие каналы приносят больше конверсий и так далее. Постепенно решения этих вопросов объединялись в новую архитектуру платформы МСБ.
Алексей Карпунин
руководитель ИТ-дирекции
Перед фактическим началом работ мы должны были понять, чем малый и средний бизнес отличается от классического корпоративного бизнеса, почему их нужно разделять, почему нужен особый IT-подход и особая архитектура.
Отличия мы сформулировали следующим образом. МСБ — это бизнес, который находится в постоянном поиске, а корпоративный бизнес — это стабильные клиенты и высокая маржа, что означает очень серьезную цену ошибки и индивидуальный подход к клиенту. МСБ — это низкая маржа и доходность только за счет объема, конвейерные процессы и необходимость поиска оптимальных подходов. Мы должны были дать бизнес-заказчику возможность пробовать, изучать гипотезы, быстро реализовывать их, проверять, отсеивать неправильные и очень быстро запускать те, которые понравились. В этом вся суть отличий. Подходы, которые мы применяли к корпоративному бизнесу, не ложились на МСБ, из-за чего процессы МСБ по факту не работали.
Так мы приняли решение о необходимости новой платформы и запустили разработку. Нам предстояло очень много задач: автоматизировать существующие процессы, рассмотреть сценарии, которые могут возникнуть в будущем, спроектировать все это в виде микросервисной архитектуры и отладить на существующих кейсах.

Стек — всему голова

Артём Забава
ИТ-бизнес-партнер
Для разработки архитектуры платформы МСБ мы в первую очередь хотели выстроить единый стек технологий, чтобы вся команда разработчиков была «на одной волне». Это сильно упростило бы разработку конкретных продуктов: при создании приоритетного продукта можно перебросить на него ребят из других команд. Также это бы очень упростило процесс онбординга и подготовки разработчиков. Фокусируемся на одном процессе обучения-становления, и нет необходимости искать разработчиков конкретного стека для каждого продукта. За основу взяли Javascript и Spring Boot.
Также нам было важно сделать прозрачный процесс деплоя CI/CD, сделать так, чтобы все сервисы разворачивались по общим правилам через TeamCity, и сделать путь универсальным. Кроме того, сформировать правильный процесс оркестрации. Решили, что выстраивать общий процесс, общаться с различными системами и отвечать за их взаимодействие должна Camunda BPM.
В процессе разработки каждое решение проходит в команде два звена. Первое — наши разработчики со своим взглядом на реализацию задач бизнеса и встраивания решений в IT-архитектуру. Другим звеном выступает отдел IT-архитектуры банка, и уже последние полтора года все действия мы согласуем вместе. Если вопрос оказывается довольно сложным и так сразу его не решить, собирается архитектурный комитет, на котором мы выходим с презентацией и обоснованием каждого решения.
На данный момент в направлении МСБ разрабатываются сервисы для автоматизации выдачи экспресс-гарантий и регулярно улучшаются существующие инструменты. Так, например, ровно год назад мы начали разрабатывать новое решение АРМ МСБ — автоматизированное рабочее место малого и среднего бизнеса, центральная система этого направления. В ней осуществляется продажа продуктов, присутствует инструмент для совершения звонков, а также есть возможность автоматизировать процесс, собирать метрики для формирования отчетов и воронки продаж. Тем самым АРМ позволяет увеличивать продажи на основе обработанной информации.
Кроме того, мы создали личный кабинет для агентов, который помогает открывать счета клиентов МСБ. Планов у нас очень много. Например, завести телеграм-ботов, которые помогут отправлять предложения, собирать статистику и общаться с клиентами.
Конечно же, в рабочем процессе мы опираемся на методологию Agile. Но это лишь небольшой процент от общего успеха. Как карбоновый велосипед — помогает выиграть 5–6 секунд, но не определяет победу во всей гонке. Многое решают кадры.
Вадим Тухватуллин
ведущий разработчик центра компетенций общебанковских бэк-офисных систем
В выборе технологий для разработки сервисов платформы МСБ мы ориентируемся на популярные open-source решения:
  • Spring Framework — фреймворк для создания веб-приложений;
  • RabbitMQ — для межсистемного взаимодействия;
  • Camunda BPM — платформа для автоматизации бизнес-процессов.
Нам важно, чтобы архитектура решения позволяла максимально быстро получать качественный результат в условиях сильных ограничений по срокам и бюджету. Стек технологий определяется из целевой архитектуры банка, учитываются количество необходимых кадров на рынке и горизонты окупаемости решения.
Мы используем концепцию цифровой трансформации: создаем для банка новые продуктовые решения со своими компонентами и сервисами согласно концепциям микросервисной архитектуры. Таким образом мы можем осуществлять доработки, не боясь нарушения общей целостности.
Сам процесс разработки похож на scrum-методологию: первым делом берем задачи из бэклога и даем оценки по инициативам заказчика. Разработчики участвуют в проработке требований. Далее устанавливаем реализованные задачи на тестовый стенд, разработчики проводят демо-показ и, если все хорошо, ставим на бой. Потом проводим ретроспективу, разбираем проблемы и сложности, с которыми столкнулась команда.

Пробы пера и первые штрихи


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

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

Артём Забава
На мой взгляд, глобальные выводы делать еще рано, ведь бывает, что всё идет бодро на новой архитектуре и новых продуктах, потому что минимум легаси и минимум тормозящих факторов. Основная сложность — найти компромисс между скоростью разработки новых продуктов, автоматизацией бизнес-процессов с одной стороны и качеством всего этого — с другой. Если делать ставку на быстрый рост компании, скорость масштабирования должна быть высокой. Задач много, но очень важно придерживать коней, а не скакать галопом, чтобы не потерять в качестве.

Что сделано и что дальше


Виктор Жидков
Мы показали, что бизнес может сотрудничать с IT на другом уровне, а также что в непростое время «ресурсного голода» можно не только сберечь, но и привлечь еще большие ресурсы для развития. Разработка архитектуры платформы МСБ с нуля дает толчок повторить опыт с другими направлениями банка к переводу бизнес-процессов на микросервисную архитектуру. Помимо этого, удалось отказаться от легаси, сформировать единый технологический стек и внедрить процессы разработки согласно Agile.
У нас очень много планов на будущее. Это и речевая аналитика, и многоканальность: будут доступны видео-каналы общения со всеми контрольными точками. Достаточно сложно сформулировать ближайшие пару лет, но на полгода бэклог у нас есть и по продажам можно понять, что нас ждет, спланировать бизнес-процессы. Мы включим туда все возможное, что хотим внедрить: финансовые подсказки, динамические лендинги, подсказки для наиболее эффективных клиентов, направление активности продаж на определенную когорту клиентов. Разделение платформы по элементам, каждый из которых можно будет улучшать и вместе с тем увеличивать продажи до космических размеров.

Итак, нам удалось:
  • создать рабочую платформу, которая автоматизирует процессы МСБ и помогает увеличивать продажи, используя agile-подход;
  • на основе микросервисной архитектуры объединить CRM- и BPM-компоненту;
  • ориентируясь на динамику малого и среднего бизнеса, выработать адаптивное решение на едином стеке технологии Java Script и Spring Boot;
  • подготовить АРМ-систему для МСБ;
  • оптимизировать рабочий процесс за счет open source-решений RabbitMQ и Camunda BPM;
  • провести диджитал-трансформацию бизнес-процессов, регулярно отслеживая прогресс и интеграцию в создаваемую архитектуру на этапе демо.
Однако говорить, что это конец диджитал-трансформации, очень рано. Это скорее один из тысячи шагов по улучшению сервисов МКБ в целом.
Всем спасибо, что прочли. Мы развиваемся как IT-компания и находимся в постоянном поиске свежих идей. Пишите с вопросами, советами и мнениями в комментариях, мы открыты для общения и сотрудничества.
Теги:
Хабы:
+13
Комментарии 19
Комментарии Комментарии 19