Андрей Бегунов, СТО, банк ПУМБ: "Corezoid стал мощным катализатором цифровой трансформации ПУМБа"

img
Андрей Бегунов, ИТ Директор банка ПУМБ

Андрей, расскажи, пожалуйста, как для тебя началась “цифровая трансформация” в банке ПУМБ?

Я присоединился к команде ПУМБ в ноябре 2016 года. К марту 2017 года мы разработали и утвердили на Правлении Стратегию развития ИТ на 3 года.

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

В 2017 году ИТ-ландшафт банка на 99% представлял из себя стек технологий Microsoft. Наследие у банка было немалое, а объем бизнеса рост и продолжает расти очень быстро. Модель ИТ-архитектуры 2017 года вызывала у меня вопросы. Что делать с таким большим количеством поставщиков и таким объемом лицензионных контрактов, масштабируемостью и стабильностью ядра?

Нужны простые тонкие “фронты” без бизнес логики, а сами процессы должны быть гибкими, переиспользуемыми, управляемыми без глубокого понимания языков программирования.

Мы провели анализ и решили, что ресурсы нашей внутренней разработки в банке мы сосредоточим там, где есть наши ноу-хау, где мы непосредственно соприкасаемся с нашим клиентом во всех каналах - как он-лайн так и офф-лайн.

Например, в целевой архитектуре все фронт-енды с того момента делаем сами своими силами, постепенно вытесняя унаследованные монолитные системы. Очевидно, что в нашем бизнесе нужна большая скорость изменений в отношениях с клиентами. Нужны простые тонкие “фронты” без бизнес логики, а сами процессы должны быть гибкими, переиспользуемыми, управляемыми без глубокого понимания языков программирования. Поэтому в стратегии на 3 года года мы заложили “процессный двигатель” (process engine) как стратегически необходимый компонент для развития бизнеса.

Компания Middleware очень вовремя вышла на нас с предложением процессного слоя на базе технологии Corezoid. У нас была большая степень доверия к опыту и компетенции Middleware.

Если бы мы тогда предложили использовать в банке известный процессный движок, например, от кого-то из топовых мировых игроков, то к нему тоже, конечно, было бы доверие. Но появился бы вопрос стоимости владения и вопрос того, смогли бы бизнес линии работать с процессным движком самостоятельно? Ответ, скорее, отрицательный. Почему? Круто, много возможностей, но из опыта и в наших реалиях – движок все равно был бы для инженеров. В итоге, бизнес-ценность свелась бы к минимуму. И таких примеров много, когда ИТ привносит понятную ИТ мощную технологию, но ее адаптация сталкивается с непреодолимыми препятствиями. В контексте принятия решения о сотрудничестве с Middleware мы с бизнесом были взаимно заинтересованы.

Мало иметь простые фронты и процессный движок. Cледующий необходимый слой - интеграционная платформа. В первые 90 дней работы в 2017 году я заметил, что у нас в терминологии происходила подмена понятий. То, что называли “интеграционным слоем”, на самом деле, таковым не являлось. Почему? Потому что был продукт класса ESB (Enterprise Service Bus) и это была платформа хостинга приложений, хотя и с некоторыми интеграционными возможностями. Как только возникал вопрос переиспользуемости ранее наработанных API в новых разработках, мы тратили ресурсы на то, чтобы сделать рефакторинг API.

Слово “API” в словаре бизнеса начало активно звучать с началом работы с командой Middleware.

Слой API – это отдельная история. Слово “API” в словаре бизнеса начало активно звучать с началом работы с командой Middleware. До этого, ИТ-шники с API, конечно, работали. Но слово “API” не было на слуху в бизнесе. API – это был ИТ-шный термин. Какой business value дает API никто не понимал. Здесь Middleware сыграла ключевую роль фасилитатора. Компания понятным языком смогла донести важность этих строительных блоков в общем фундаменте бизнеса и процессов. Благодаря партнерам, мы расставили точки над и в вопросе, зачем бизнесу нужна экосистема API.

Как родилась пирамидка, о которой ПУМБ сейчас часто говорит на конференциях?

img

Corezoid компании Middleware идеально лег в middleware часть :)

Пирамидка родилась в феврале 2017 года. Она вошла в ИТ-стратегию, как визуализация целевой архитектуры, понятная всем и объясняющая бизнес ценность технологий и самые ключевые слои архитектуры и изменения которые нужно было сделать, чтобы прибавить в гибкости. Corezoid компании Middleware идеально лег в middleware часть :)

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

“Интеллект не аутсорсится”

На рынке многие по прежнему продолжают думать, что придет человек с готовой коробкой и все решит. Мне импонирует фраза основателя Middleware Александра Витязя: “Интеллект не аутсорсится.” Ты не можешь предложить клиенту ничего нового, если постоянно будешь покупать готовые решения у внешних вендоров.

Как происходила “цифровая трансформация” на управленческом уровне, на уровне людей?

В нашей ИТ-стратегии важное внимание мы выделили изменениям в подходах к работе с людьми. Мы решили, что нужно попробовать “scrum”, точнее говоря, привести процессы, мотивацию, взаимодействие и наполнение команд к классической модели “scrum”. Возможно, не все знают, что скрам – это фигура из игры в регби. А регби – это игра, когда мощно впрягаются все, и это про общую цель, командную работу, большие усилия.

img
Scrum – это все про командную игру.

Многие организации продолжают работать в парадигме, что во главе всего – процесс. Давайте сделаем процесс еще лучше, и все наладится.

Иногда уже и вспомнить было сложно, кто вообще заказывал разработку год назад.

Мы пишем требования, куда-то их передаем, кто-то с ними что-то делает. Главное, чтобы все двигалось. А мы будем оптимизировать. У такой модели есть ограничение. В такой конфигурации сотрудник зачастую сидел как на производственном конвейере. Человек получал кусочек задачи, что-то делал, но мало понимал/знал как выглядит тот продукт, который в итоге собрали. И вообще где он, и поехал ли он? Более того, пользуюсь ли я тем, что создавалось? А ведь есть еще фактор текучки кадров на рынке. Иногда уже и вспомнить было сложно, кто вообще заказывал разработку год назад. Задачи “прокисали”.

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

Знаете, есть на мостах гайки такие здоровые. И вот представьте себе, что гайка – это важная задача. Соответственно, мы предполагали, что нужно взять ключ побольше, крупнее и в нужных местах просто докрутить. А если нужного ключа нет, то возможно купить новое ПО у внешнего вендора, чтобы уже наверняка. Перепробовали много инструментов/ключей из классического управления изменениями: показатели, дашборды, таймшиты, комитеты по управлению изменениями. Что-то продолжаем использовать, но от многих старых вещей отказались.

Мы решили, что нам нужна внешняя помощь: компетенция с рынка. Нашли партнера и выбрали одно, но конкретное место приложения сил для scrum-подхода. Очень важна принципиальна вовлеченность, лидерство и поддержка ТОП-менеджмента. Глава правления Сергей Черненко постоянно в этом потоке принятия решений. И это не только вопрос финансирования. Это постоянная кропотливая работа над роад-мэпами, приоритетами команд, погружение в детали, посещение демо.

Начали с тренинга по scrum. Пригласили сотрудников банка уровня “борд -1”. Пришли около 60 человек. На старте нам было непонятно, насколько банк готов к scrum-подходам, сам тренинг стал лакмусовой бумажкой. В первый день мы говорили в целом о том, как и почему мир меняется и почему нужно меняться. Очень полезная картинка, которая показывает, сколько времени каким технологиям понадобилось на принятие и адаптацию, чтобы достичь например 50 млн. пользователей.

img
Сколько времени понадобилось технологиям, чтобы достичь 50 млн. пользователей: от 68 лет для авиатранспорта до 19 дней для Pokemon Go

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

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

img
Новый офис банка ПУМБ, ул. Спасская, 5. Источник

Я считаю, что для нас, как для команды, были созданы все условия: были инвестиции, понимание, готовность к эксперименту. Важно, что бизнес подразделения не только поддержали, но и возглавили многие направления трансформации.

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

Важную роль сыграли ритуалы scrum. В этих ритуалах есть цикл вещей, которые нужно делать обязательно. Есть backlog (список задач, которые ожидают взятия в работу), есть понятия ретро, демо. Ключевое, где руководитель розницы Себастьян Рубай нас очень поддержал, – что в командах нужен сильный Product owner.

img
Источник

Еще до формирования команд мы показали на нескольких примерах, что такое взять людей: бизнес-заказчика, разработчика, системного аналитика, проектного менеджера, и закрыть на полдня в одной комнате. Это был реальный факт. Они вышли и говорят: “Wow! Я увидел разработчика, который сразу же сказал, почему нельзя сделать так, как я хочу, и предложил свой альтернативный вариант. Тут же.”

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

Мы создали команду по разработке фронт-енда для отделений, команду мобильного приложения, команду для работы с потребительскими кредитами, команду в контакт-центре для работы с фронт-ендами контакт-центра. Везде появились сильные Product owners: Юрий Белоцкий, Михаил Сергиенко, Дмитрий Дудник, Анна Кондратова, Сергей Караулов. На конец 2018 года у нас уже работали 7 кросс-функциональный команд.

В трансформации важны внутренние евангелисты.

В трансформации важны внутренние евангелисты. Внешний партнер, консультант, привносит знания и компетенции, помогает масштабировать, но этого мало. Нужно чтобы были свои сильные игроки в поле, которые несут опыт и знания внутрь. Мой коллега Александр Ващук, как внутренний коуч провел десятки внутренних тренингов по scrum и devops, несколько игр по бизнес-симуляции. Интерес в компании большой и список участников наполняется быстро. Коллеги видят, что кипит работа, есть эффект. Сотрудники из совершенно разных подразделений приходят к нам в коворкинг, иногда в рабочее время, чаще – в нерабочее. Всех это драйвит, мы изменяемся.

"Коллеги, перестаньте думать вдолгую. Вы пролетите. Делайте MVP, делайте прототипы, проверяйте гипотезы, главное быстро".

Все чаще на совещаниях я начал говорить: “Коллеги, перестаньте думать вдолгую. Вы пролетите. Делайте MVP, делайте прототипы, проверяйте гипотезы, главное быстро”. Мы показываем известную картинку с самокатом и машиной.

Что такое MVP?

Лидеры команд, Product owners глубоко поддержали эту идею. В банке прижилась концепция “делаем прототип, проверяем, учимся, дальше или выбрасываем, или масштабируем”. Можно сказать, что появился “MVP” как понятие в словаре банка. Это было супер-важно.

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

Corezoid стал огромным катализатором и ускорителем цифровой трансформации в ПУМБе. Corezoid позволил сильно расширить узкое горлышко ИТ-ресурсов.

Corezoid стал огромным катализатором и ускорителем цифровой трансформации в ПУМБе. Corezoid позволил сильно расширить узкое горлышко ИТ-ресурсов. Когда есть “цифровое ядро” в виде процессной системы которой управляет сам бизнес, изменения в организации происходят на порядки быстрее. Бизнес начинает самостоятельно собирать процессы, мыслить категориями MVP, строить и улучшать прототипы.

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

Касательно альтернатив, таких как Camunda, например, и других open source. В моем опыте мне пришлось столкнуться, как минимум, с 2-мя крупными платформами для управления процессами. Обе истории – fail. Сама идеология процессности появилась ведь давно. Она правильная. Но идею часто покупали люди из ИТ или близкие к ИТ технологиям, и приносили в компанию.

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

Очень важный фактор - уровень знаний и компетенций в бизнесовых командах. Дефицит компетенции в бизнесе в комбинации со сложными системами приводят к инертности, ошибкам и неудачам проекта. Если бизнес не понимает, что такое API, как его использовать, что такое процессный “слой”, то все умирает. Не важно open source это или нет.

Порог входа для начала работы с Corezoid очень невысокий. Это большой плюс.

Порог входа для начала работы с Corezoid очень невысокий. Это большой плюс. Если бы в Corezoid было сложно, бизнес-аналитики в бизнесах построением процессов не занимались бы. Один из ярких примеров - событийный маркетинг, команда CRM во главе с Сергем Карауловым успешно разрабатывает процессы на Corezoid, прототипируя идеи, проверяя их, предлагая клиентам продукты в контексте профиля клиента, его поведения и интересов.

За последний год мы в ПУМБе сделали большой скачок вперед. И это требует определенного осмысления. Стало очевидным, что нужен отдельный Центр компетенций по Corezoid, и компания Middleware это поддержала.

Corezoid сейчас, как кровеносная система банка, наполнилась событиями.

Центр компетенций у нас теперь развивает культуру работы с платформой, разрабатывает общие стандарты, выступают в виде узла знаний на стыке различных компетенций. Corezoid сейчас, как кровеносная система банка, наполнилась событиями. Естественно, у бизнесов возникают вопросы: как было вчера? Как будет завтра? Какое подразделение сколько создало процессов? Кто сколько потребляет ИТ-ресурсов? Кто собственник созданных на Corezoid процессов?

Для ИТ важно уметь дать ответ на вопрос “а во сколько мне это обходится, насколько эффективно работает инвестиция”? Со временем мы научились аллоцировать потребление мощностей на бизнес подразделения. Но это все, конечно, не сразу. Мы пришли к этим вопросам через 1-1,5 года.

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

Резюмируя, можно сказать, что мы перешли на качественно иной уровень ведения бизнеса за последние полтора года. И это очень быстро. Крупные игроки рынка, наверное, двигаются, как правило, эволюционно. Но на нашем примере можно утверждать: банк может и готов работать в новой цифровой парадигме. Для этого нужно не так много, как кажется вначале, правильная мотивированная команда, готовность меняться, нужные акценты на технологическом уровне, понимание того что ИТ = бизнес, а бизнес = ИТ.

Рекомендуем прочитать:
CTO Mambu Ben Goldin: “Corezoid – это облачная машина состояний, а не очередной BPM”.
CTO Mambu Ben Goldin: “Corezoid – это облачная машина состояний, а не очередной BPM”.
Что привлекло мое внимание в Corezoid – это фундаментальный подход к самой технологии. Corezoid – это не еще один BPM.
ПОКАЗАТЬ ВСЕMore
Создайте свое цифровое ядро прямо сейчас!
Начать
Запросить демо