{"id":14277,"url":"\/distributions\/14277\/click?bit=1&hash=17ce698c744183890278e5e72fb5473eaa8dd0a28fac1d357bd91d8537b18c22","title":"\u041e\u0446\u0438\u0444\u0440\u043e\u0432\u0430\u0442\u044c \u043b\u0438\u0442\u0440\u044b \u0431\u0435\u043d\u0437\u0438\u043d\u0430 \u0438\u043b\u0438 \u0437\u043e\u043b\u043e\u0442\u044b\u0435 \u0443\u043a\u0440\u0430\u0448\u0435\u043d\u0438\u044f","buttonText":"\u041a\u0430\u043a?","imageUuid":"771ad34a-9f50-5b0b-bc84-204d36a20025"}

История одного проекта внедрения или как 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 версий.

Прочитать больше об экспертном опыте Александры вы можете в ее канале:

0
Комментарии
-3 комментариев
Раскрывать всегда