История одного проекта внедрения или как Low-code ломает языковой барьер
Сегодня поговорим с евангелистом компании ELMA Александрой Лощеновой об истории внедрения BPMS в компанию, где около 1500 сотрудников, в основной массе, говорят только на родном языке, и это не русский или английский, с которыми мы привыкли работать. Обычно в проектах внедрения мы уточняем требования и самостоятельно настраивали интерфейсы, но в этом случае такой подход сильно бы увеличил срок внедрения, потребовался бы перевод всех пользовательских интерфейсов. Обсудим, как команда Александры справилась с языковым барьером, масштабировалась на всю филиальную сеть и сократила время оказания услуг в несколько раз.
Как начинался проект?
- В банке с разветвленной филиальной сетью в дружественной нам стране работали консультанты с целью оптимизации бизнес-процессов. В этот же период шло масштабное обновление АБС — ключевой системы банка — на несколько мажорных версий, которое сильно меняло интерфейсную часть и API системы. Обновление АБС и оптимизация процессов, которая сильно их изменяла и затрагивала другие системы компании, навела руководство на мысль об обучении сотрудников. Как обучить всех сотрудников в филиалах работать по-новому, к тому же в незнакомом интерфейсе АБС?
В поиске ответа на этот вопрос было принято решение о внедрении BPM-системы, как единого пространства для сотрудников, "под капотом" которой будут все банковские системы. Интерфейс дружелюбнее, цепочкой задач в процессе и вызовом интеграционных функций управляет BPM-система, сотрудникам филиалов больше не нужно задумываться о сложной последовательности операций для открытия тех или иных продуктов.
Как выбирали платформу?
- Совместно с консультантами были сформированы критерии выбора платформы, изучены вендоры BPM-систем. Обращали внимание на опыт, отзывы и обзоры. В итоге выбор пал на несколько вендоров. Их пригласили на территорию компании на 2 недели для реализации процесса, демонстрирующего основные требования к функционалу. Некоторые вендоры отказались от участия в такие короткие сроки, а несколько приехали на место для плотного взаимодействия с бизнесом и ИТ для настройки бизнес-процесса. Спустя 2 недели, после проведения демонстраций итоговых решений, было принято решение с каким вендором идти в пилотный проект.
Что представлял из себя пилотный проект?
- Пилотный проект имел четкие ограничения по объему и сроку — автоматизация одного бизнес-процесса за 2 месяца. Для тестирования запускаемых процессов и получения оперативной обратной связи был выбран один из филиалов банка, прямо в нем и работала команда внедрения, которая состояла из:
- нескольких аналитиков со стороны банка. В текущей терминологии я бы использовала понятие “citizen developer”, в вольном переводе определения из словаря Gartner — это сотрудник не ИТ-отдела, а бизнес-подразделения, который создает новую функциональность для себя или других людей с помощью инструментов, не запрещенных в организации. До этого проекта они не занимались аналитикой, они работали в бизнес-подразделениях банка и понимали, как устроены бизнес-процессы, имели возможность уточнить требования, так как знали язык.
нескольких разработчиков со стороны банка — они писали веб-сервисы для работы с АБС, процессинговой системой и другими банковскими системами.
И нескольких Low-code разработчиков со стороны вендора, среди них была и я.
Как велась разработка процесса:
Аналитик банка моделировал бизнес-процесс в системе, создавал контекстные переменные и формы задач на родном языке. Системные названия процессов и контекста формировались на английском, чтобы мы могли понять, о чем речь.
Аналитик банка формировал задачу для разработчиков, сообщая, что необходимо выполнить в ходе процесса в другой системе банка, например, чтобы создать проводку, открыть счет или выпустить пластиковую карту.
Аналитик банка создавал шаблоны документов, чтобы они формировались автоматически на основании введенных данных в систему или данных, полученных от других систем.
Разработчик банка создавал веб-сервис, который принимал на вход данные, передавал их в одну или несколько систем банка и возвращал информацию об успешности операции или ошибке. Веб-сервисы писались преимущественно на английском, хотя иногда и на родном языке разработчиков — так мы расширяли свой словарный запас.
Low-code разработчик создавал плагины — проверял данные на входе, вызывал веб-сервисы и возвращал "читаемый" результат. Преимущество таких "плагинов" было в том, что это "собиралось" в отдельный "кубик" в графическом редакторе бизнес-процессов, который аналитик банка может сам настраивать мышкой и использовать в других бизнес-процессах. Такие плагины писались на английском, так как пользовательского интерфейса они не предполагали.
Дальше шел этап тестирования. Он проходил в два этапа:
- Тестирование командой разработки процессов — аналитик банка и Low-code разработчик проходили весь бизнес-процесс и сверялись, что данные корректно переходят между BPM-системой, АБС и другими системами.
- Тестирование операционистами банка — операционист при обслуживании клиента банка дублировал информацию в BPM-системе, которая была интегрирована с тестовыми средами банковских систем, после чего аналитик сверялся с корректностью данных.
Присутствие в филиале, в котором проводилось тестирование, предоставило нам возможность получать оперативную обратную связь от операционистов и быстро вносить изменения в процесс.
Изначально в тестирование передавалась AS IS модель процесса, чтобы проверить корректность интеграционных точек, собрать обратную связь от операционистов на привычном для них процессе и измерить время выполнения процесса. Параллельно велась разработка TO BE модели, которую готовили консультанты.
После устранения всех замечаний мы запустили BPM-систему в промышленную эксплуатацию в рамках нашего тестового филиала.
О результатах пилотного проекта:
- За время пилотного проекта мы автоматизировали вместо планируемого одного бизнес-процесса целых пять.
То, что мы сможем сделать больше от первоначального плана, стало понятно после первых трех недель разработки. Руководство увидело результат — автоматизированный бизнес-процесс, готовый к запуску в промышленную эксплуатацию. Такой результат достигался за счет слаженной работы аналитиков, разработчиков банка и Low-code разработчиков, а также за счет выбранного банком гибкого подхода к управлению проектом. Мы не тратили время на формирование большого технического задания на всю систему, а быстро получали модель процесса от аналитика, интегрировали с другими системами, тестировали и запускали в эксплуатацию. Разработка одного бизнес-процесса, в зависимости от его сложности, занимала от 1 до 3 недель.
Масштабирование на филиальную сеть:
- Следующим шагом был запуск системы на все филиалы. Кроме масштабирования, необходимо было обеспечить поддержку новой версии АБС. Изначально в промышленную эксплуатацию на одном филиале мы запустились на старой версии АБС, так как к запуску BPM-системы миграция еще не была отлажена.
Новая версия АБС отличалась от предыдущей не только интерфейсом, что стало предпосылкой к внедрению BPMS. Она отличалась и API, из-за чего мы на старте заложили в архитектуру системы поддержку разных версий АБС на уровне системы и на уровне конкретных плагинов — в зависимости от версии выполнялся тот или иной код.
Вернемся к масштабированию — мы развернули веб-ферму серверов для поддержки больших нагрузок, провели несколько нагрузочных тестов и убедились в стабильности системы. Было решено подключать филиалы постепенно — по несколько штук в день, смотреть за нагрузкой и при необходимости корректировать план по запуску или конфигурацию серверов.
Оптимизация процессов:
- Далее мы занимались разработкой следующих процессов и оптимизацией существующих — переходом от AS IS к TO BE. Я уже писала выше, что параллельно с тестированием AS IS модели мы разрабатывали TO BE, на основании моделей полученных от консультантов. Переход на TO BE модель в промышленной эксплуатации происходил постепенно, по аналогии с масштабированием. В начале мы перевели на TO BE модель один филиал — обучили сотрудников работать по-новому, записав обучение на видео, собрали обратную связь, внесли изменения и измерили результаты оптимизации в цифрах. После отладки внутри одного филиала — начали постепенно подключать к TO BE модели остальные.
За полгода нам удалось сократить скорость предоставления услуг в 2-3 раза, а по некоторым продуктам — в 6 раз. Например, процесс оформления пластиковой карты, который сначала занимал 30 минут, после автоматизации и оптимизации занял 5 минут.
Какой эффект получен от внедрения системы?
- За время проекта банк сформировал свой центр компетенций по Low-code BPMS. Была создана структура, которая занимается поддержкой и развитием бизнес-процессов компании. Структура состоит из четырех групп:
- аналитики для сбора требований и формирования моделей процессов;
- Low-code разработчики для настройки скриптов и интеграций;
- тестировщики для обеспечения качества внедряемого продукта;
- сотрудники поддержки для консультации пользователей по возникающим вопросам.
По результатам проекта нам удалось:
- стандартизировать работу филиалов — до внедрения BPMS каждый филиал работал по-своему;
- сформировать единое пространство для сотрудников филиалов — им теперь не приходится переключаться между всеми системами банка и тратить время на изучение последовательности действий для создания счета, карты, перевода и т.п.;
- сократить количество ошибок при вводе информации, так как BPMS валидирует вводимые данные на форме на основании бизнес-правил, принятых в организации;
- увеличить скорость ввода оптимизированных бизнес-процессов и новых банковских продуктов;
- устранить нестыковки данных между системами по одному клиенту;
- получить большой объем аналитической информации, которая агрегирована в рамках одной системы.
Внедрение BPMS помогло за полгода автоматизировать ключевые бизнес-процессы и оптимизировать их. Low-code подход за счет своей простоты в использовании дал возможность “citizen developer” освоиться в системе и с первых недель проекта включиться в разработку бизнес-процессов. Также Low-code BPMS позволила быстро вносить изменения в бизнес-процессы в моменты как отладки, так и оптимизации, поэтому к моменту масштабирования на всю филиальную сеть у процессов было уже порядка 20 версий.
Прочитать больше об экспертном опыте Александры вы можете в ее канале: