Геннадий Гребеник, «Фора-Банк»: «Не используйте low-code системы для сложных и уникальных процессов»

Справка о компании: «Фора-Банк» – российский универсальный коммерческий банк, который существует на рынке 31 год. У компании 164 офиса в 7 регионах страны. Банк занимает 70 место по активам среди кредитно-финансовых организаций РФ.

Составляющие внутренней банковской системы

В целом все внутренние банковские системы можно разбить на несколько слоев. Первый слой систем – фронтальный, который обеспечивает процессы самообслуживания клиента, процессы, с которыми клиент взаимодействует через операциониста в отделении банка, а также элементы, связанные с управлением и взаимодействием с клиентом (операционный CRM, Customer Relationship Management). Второй слой – мидл. К нему относятся процессы, связанные с дальнейшим проведением операций клиента с учетом политики риск-менеджмента и нормативов Центрального банка. Гибкость, скорость – основные показатели, которые определяют эффективность данных процессов и систем их автоматизации. Третий слой – учетные системы, обеспечивающие отражение клиентских контрактов, счетов и документов клиента. Банковский бизнес зарегулирован Центробанком, в нем очень сложная с точки зрения построения и понимания отчетность. Если говорить про бэк, то, с одной стороны, процессы достаточно регламентированные в связи с требованиями ЦБ, а с другой – постоянно сталкиваемся со спецификой, связанной с внутренней политикой самого банка. Четвертый слой – блок аналитики, к которому относится инструментарий для комплексного анализа бизнеса. Управлять можно тем, что можно измерить. Чем глубже мы измеряем бизнес, тем лучше наш подход к его управлению.

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

В данной статье я расскажу про три стратегии автоматизации бизнес-процессов в зависимости от слоя и назначения систем: коробочное решение, своя разработка и low-code платформа.

Коробочное решение

Данный кейс не относится к «Фора-Банку». Стояла задача внедрить банковскую систему. Классически банковская система АБС относится к учетным системам, хотя в большинстве случаев на нее возлагают и задачи мидл-слоя, обеспечивая функции ручными процессами. Перед нами стояла задача перейти с одной системы на другую за 5 месяцев, и мы выбрали коробочное решение – готовую платформу с готовыми процессами, широкой экспертизой на рынке. Однако было понятно, что переделать коробку под свои процессы иногда сложнее, чем создавать с нуля. Классическое внедрение банковской системы затягивается на годы в связи с задачей «натянуть» процессы банка на возможности новой системы, поэтому мы пошли по другому пути.

В процессе внедрения новой банковской системы участвовала команда из 50 человек. Процесс занял чуть больше пяти месяцев. Месяц – постановка процессов, три месяца – на настройку и обучение, и два месяца – на миграцию и тестирование. Мы решили «сломать» существующую процессную модель банка и построить все заново.

Первый месяц занял описание существующих и построение оптимальных процессов. Вместе с методологами и главным аудитором банка мы перерисовали процессы, максимально их сократив, нарисовали идеальную модель TO BE1. Дальше пришли к нашему поставщику-вендору и вместе стали думать, как оптимизированные процессы подстроить под систему TO BE2. Здесь стоит отметить, что мы не переделывали сильно систему. Мы переделывали процессы. Фактически мы построили новые процессы для нашего банка, максимально использующие возможности новой автоматизированной банковской системы.

Второй этап по настройке системы и обучению сотрудников занял три месяца. Стояла задача обучения 2000 сотрудников не только новой системе, но и новым процессам. Для обучения мы пошли по пути сетевого маркетинга, выбрали лидеров изменений, которые прошли обучение в головном офисе, и задача которых была обучить сотрудников во всех филиалах сети банка.

Самый интересный этап – тестирование, которое проходило одновременно с обучением. С понедельника по пятницу банк работал в обычном режиме. В субботу все выходили на работу и проводили тестовый день – повторяли всю работу, которую делали в пятницу, но с применением новой системы и новых процессов. В конце дня смотрели ошибки в процессах, обучении и настройках. Далее в будни банк работал в привычном режиме, и за эту неделю команда разработки исправляла возникшие ошибки. Мы провели семь тестовых дней. Это действительно была большая нагрузка на весь банк.

Результат – запуск в срок новой системы, плюс оптимизация бизнес-процессов банка. 

Собственная разработка

Поделюсь опытом создания собственной системы дистанционного банковского обслуживания (ДБО) «Фора-Банка». Важно, что это фронтальный слой, а значит UX/UI является одним из основных критериев конкурентной борьбы. Выбор коробки или low-code системы исключает возможность конкурировать с лучшими банковскими приложениями на рынке. Стратегия – собственная разработка. В процессе разработки мы обращали внимание на две вещи. Первая – процессы обслуживания самого клиента. Так называемый клиентский путь, который является с точки зрения фронтальных решений одним из самых важных критериев. Один из показателей эффективности клиентского пути – его длина (сколько шагов необходимо сделать клиенту для выполнения целевого действия). Фактически мы вычищали клиентские пути, чтобы клиент мог максимально быстро и удобно работать с нашим решением. Вторая важная вещь – идти от клиентских потребностей. Классические коробочные решения строятся вокруг сервисов банка и предлагают клиенту найти необходимый для его целевого действия сервис. Это неудобно клиенту, но проще банку. Идти от клиентских потребностей – это формировать решение, логически структурированное вокруг них, зашивая банковские сервисы «под капот». Например, переводы:

Прежде чем решаться на собственную разработку, необходимо понять, обладаете ли вы всеми необходимыми составляющими для этого. Прежде всего, необходимо иметь собственную команду разработки или быть готовым к ее формированию. Второе – время, поскольку разработка чего-либо под себя всегда занимает больше времени, чем коробочное решение. Третье – готовность менять текущие процессы, и четвертое – готовность делать лучшее решение. Если вам достаточно 80% результата, то выбирайте коробку. Если нужен 100% результат, тогда стоит идти в собственную разработку.

Мы начинали проект как стартап. Команда на старте –16 человек. Быстро проводили бизнес-оценку, реализовывали бег глубокой архитектурной проработки, каждый разработчик делал свой кусок фактически автономно. Высокая скорость разработки, быстрый прирост функционала, но увеличивающееся количество ошибок и регресса. Через 9 месяцев разработки запустили в прод MVP (Minimum Viable Product – минимально жизнеспособный продукт, который все же выполняет основную функцию и уже представлен пользователям). Красивое клиентское решение, но с нестабильной работой. Основная задача MVP была достигнута, гипотеза показала увеличение вовлеченности нашей клиентской базы в дистанционные каналы, и заказчик одобрил решение, увеличил затраты на разработку.

Следующим этапом стало выстраивание из этого стартапа полноценного промышленного решения. Мы разбили процесс на шаги, добавили детальную аналитику и разработку архитектурного решения. В разработку добавили шаги по подготовке и презентации плана разработки, написание юнит-тестов, перекрестное ревью кода, автотестирование. В итоге получили платформу, которая может делать реально хорошие промышленные решения. Сейчас в команде 28 человек, которые параллельно ведут до 8 проектов (фичей). Плановые релизы каждый месяц.   

Low-code платформа

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

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

Конвейер банковских карт. Это достаточно большой и сложный процесс, который состоит из более чем двухсот компонентов. Процесс долгий во времени, часть веток может быть активна в течении нескольких месяцев, поэтому мы декомпозировали его и разбили процесс на логически законченные бизнес-функции. Процесс не «живет» в течении своего срока жизни, а поднимается в виде бизнес-функций в соответствии с установленными правилами процесса и «гасится» после исполнения бизнес-функции до следующего этапа. Команда состояла из 6 вендорских и 4 разработчиков со стороны команды банка. Разработка заняла 6 месяцев, отладка более 5.

Первое внедрение проекта было соизмеримо с разработкой с нуля. Перед нами встала задача адаптировать конструктор. Решение мы взяли с другого рынка, не банковского, что исключило возможность переиспользования ранее реализованных функций. Также необходимо было создать большое количество базовых компонентов для конвейера, так как наш бизнес-заказчик предъявил высокие требования к дизайну интерфейсов и эргономике приложения. Большой неожиданностью для нас стала непредсказуемость платформы. Платформа, как интеллектуальный инструмент преобразования настроек в код, стала дополнительной точкой отказа. Вторая неожиданная вещь – недооценка объема задачи. Мы предполагали, что при использовании low-code платформы у нас будет 70% экономия в разработке. Однако это на практике не так, текущая оценка «экономии» на разработке не превышает 20%. Третья неожиданность – слабая внутренняя команда. Тяжело привлечь сильных специалистов к low-code разработке, поскольку хороший разработчик хочет все делать самостоятельно, а не донастраивать то, что уже создал кто-то другой. Поэтому в команде работают специалисты уровня мидл или джуниоры, а это увеличивает время на обучение, дает ограничения в проектных решениях и приводит к постоянному делегированию сложной разработки партнеру. Такой подход не развивает собственную команду, увеличивает расходы на партнера и увеличивает нашу зависимость от него. Неприемлемая для нас ситуация.

Как же мы с этим боролись и что поменяли? Во-первых, была закрыта возможность привлечения партнера проектной командой. Каждая задача на партнера проходила строгий контроль на возможность реализации собственными силами и в большинстве случаев возвращалась в собственную команду. Обучение по «бразильской системе». Во-вторых, итерационное вычищение костылей и заплаток собственной командой. Фактически был запущен процесс рефакторинга реализованного партнером функционала. В-третьих, минимизация переходов с версии на версию. Каждая версия для нас – это большой проект. Поэтому желательно раз в полгода, не чаще, переходить с одной версии платформы на другую. В-четвертых, постоянное давление на нашего поставщика.

Конвейер открытия счетов. Объем процесса – более трехсот компонентов. Для реализации второго проекта команда состояла из 4 разработчиков со стороны вендора и 6 наших. Разработка и отладка системы заняли по 8 месяцев каждая.

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

Второй этап разработки конвейера банковских карт. Команда состоит из 6 человек нашей команды. Разработка заняла четыре месяца.

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

Как итог сформулирую несколько простых правил:

Если вы пренебрегаете данными правилами, внедрение будет соизмеримо внедрению с нуля.

Геннадий Гребеник, директор по трансформации, «Фора-Банк»

Комментарии