.png?&quality=65&format=webp)
Внедряем СЭД без потерь: программа автоматизации документооборота в организации
О преимуществах СЭД, кейсах использования и о функциональности топовых систем для автоматизации документооборота читайте в этой статье.
Расскажу историю внедрения 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 версий.
