В универсальном банке среднего размера более 200 различных бизнес-процессов, которые пересекаются, дополняют друг друга, дублируются. Менять процессы можно точечно, вскрывая самые наболевшие проблемы, но кардинальное изменение операционной эффективности и прозрачности бизнеса требует и серьезных изменений в организации. А изменения в организации — это прежде всего изменение людей, нелегкая и очень смелая задача. Данная проблема анализируется в статье.
Основными предпосылками и сигналами к оптимизации и перестройке бизнес-процессов в кредитной организации являются:
- возросшее количество конфликтов среди подразделений банка;
- возрастающие затраты, не пропорциональные росту бизнеса;
- возросшее количество проблем, связанных с обслуживанием клиентов, таких как срыв установленных сроков, ошибки, снижение качества работы персонала;
- ухудшение позиций кредитной организации в конкурентной борьбе, снижение качества обслуживания, снижение скорости вывода новых банковских продуктов на рынок и т. д.
Первый шаг в оптимизации процессов — понимание необходимости кардинальных изменений топ-менеджментом и собственниками бизнеса. Процесс можно растянуть на
Второй вариант — ставить задачу на
Глобальная оптимизация процессов — первые шаги
Глобальная оптимизация процессов начинается с идентификации того, как организация работает сейчас. Описание процессов AS IS («как есть») — второй шаг. Выбор способа аннотации описания бизнес-процессов не влияет на конечный результат, и могут быть использованы технологические карты BPMN, IDEF0, IDEF3 (рис. 1 и 2), хотя технологические карты не самый лучший способ, так как теряется наглядность процесса, а это очень важно для его перестройки.
На данном этапе не нужна скрупулезная детализация процесса. Главная задача — описать все существующие процессы, роли, верхнеуровневые задачи. В этом описании степень детализации может быть ограничена набором функций, исполняемых одной ролевой единицей в рамках каждой задачи процесса. Для такой модели подойдет четырехмерная структура (рис. 3):
- продукты и сервисы банка;
- бизнес-процессы — цепочка действий;
- ролевая структура;
- ИТ-инфраструктура.
Рекомендуем использовать объектно-ориентированные модели с поддержкой связей между слоями. Очень важно отслеживать взаимосвязь между слоями модели, так как это помогает определить основные точки последующих изменений и причинно-следственные связи. Не всегда «грязные» процессы являются следствием несистемного управления компанией, очень часто накладываются ограничения в виде возможностей ИТ-систем или структурной организации компании.
Задача описания существующих процессов решается изучением текущих нормативных документов подразделений и проведением интервью с ключевыми участниками или владельцами процесса (руководителями бизнес-подразделений, директорами и главными бухгалтерами филиалов банка). Если структура кредитной организации включает филиалы с относительно самостоятельным управлением, возможна ситуация, когда один и тот же процесс в разных филиалах идет по-разному. В наших проектах был самый яркий случай, когда в банке из тринадцати филиалов было восемь разных схем прохождения одного и того же процесса. Иногда в процессе возникает большое количество нелогичных, излишних действий. Например, продажа бланка простого векселя в одном филиале крупного банка проходила по процессу, в котором принимали участие и главный бухгалтер, и директор филиала.
По времени второй этап может занять от одного до трех месяцев, в зависимости от масштаба банка и выделенной команды. Критерии успеха — профессионализм сотрудников и высокий статус проекта, позволяющий привлекать ресурсы других бизнес-подразделений по первому требованию.
Основной состав команды:
- главный архитектор;
- банковские методологи (могут быть из компании-партнера);
- модератор (методолог с широким профессиональным опытом, владеющий методологией построения процессов).
Основной принцип описания цепочки событий — соответствие входных и выходных потоков. Прорисовка процесса позволяет выявить потерянные звенья (входные потоки «ниоткуда» и выходные потоки «в никуда»). Такие факты детально изучаются, отыскиваются недостающие связи, звенья и подпроцессы. Карта процессов не должна содержать разрывов — это главное условие, благодаря которому ни один процесс не будет потерян при его последующей перестройке.
Третий шаг — определение целевой карты процессов. Из существующей карты удаляются дубли, удаляются лишние разветвления, ненужные подпроцессы, выделяются зоны ручного труда, которые требуют новых ИТ — решений, автоматизирующих эти блоки. Если существующая ИТ-инфраструктура позволяет выполнить оптимизацию, большая часть задач уже решена; если системы устарели, то это еще одна задача, без которого эффект перестройки процессов банка будет не столь эффективен.
Замена ИТ-систем должна быть следствием задачи изменения бизнес-процессов, хотя в некоторых банках технологическая задача идет впереди, что приводит к неэффективному использованию внедренных изменений, или дело вообще не доходит до промышленной эксплуатации. Учитывая гипотетические, максимально возможные функции автоматизации потенциальными системами, рисуем процессы TO BE 1 («как бы мы хотели») — рис. 4.
Основные участники этого процесса — методологи, архитекторы. Очень важно подключить службу внутреннего аудита, поскольку это позволит оптимизировать процессы с учетом требований регулятора и внутренней политики кредитной организации. Если внутренняя политика банка препятствует достижению оптимальной картины процесса, она может быть тоже изменена, для этого опять же необходимо активное участие главного аудитора. Срок проработки процессов TO BE 1 займет около одного месяца при условии максимальной вовлеченности команды.
Основной состав команды:
- аудитор банка;
- представитель корпоративного бизнеса;
- представитель малого бизнеса;
- представитель розничного бизнеса;
- представитель инвестиционного бизнеса;
- риск-менеджеры;
- главный архитектор;
- банковские методологи (могут быть из компании-партнера);
- модератор (методолог с широким профессиональным опытом, владеющий методологией построения процессов).
На этом этапе команда расширяется представителями, отвечающими за продажу продуктов и обслуживание клиентов. Процессы должны быть не только адаптированы к учетным и бэк-офисным функциям, но, в первую очередь, нацелены на повышение эффективности и качества работы с клиентами.
Требования к выбору систем рождаются из заданных процессов TO BE 1 и текущей инфраструктуры банка и могут быть оформлены как функциональное требование с внутренней скоринговой картой (рис. 5). Не всегда лучшая система на рынке оказывается лучшей для конкретного банка. Функциональные требования должны быть акцентированы на тех особенностях системы, которые позволят организации максимально следовать процессам TO BE 1.
Целевая карта процессов
Процесс выбора системы оставим за рамками статьи, так как она не является специфической задачей для оптимизации процессов. Когда система выбрана, начинается процесс подготовки к внедрению и формирование уже конечных процессов TO BE 2 — создается целевая карта процессов. Она строится более подробно, чем в процессах AS IS и TO BE 1.
Допустимо использовать ту же аннотацию, что и раньше, но возможно ее расширение для более детального описания потоков и действий. На этом уровне могут появиться пятимерная или шестимерная модели организации. Пример шестимерной модели:
- продукты и сервисы банка;
- бизнес-процессы — цепочка действий (с добавлением описания входящих, поддерживающих и исходящих артефактов, элементарных действий, которые должны быть выполнены в данной задаче, а также KPI процессов);
- ролевая структура (из которой строится будущая организационная структура банка);
- ИТ-инфраструктура;
- модель потоков данных;
- нормативная база банка (инструкции, руководства пользователей, форматы и шаблоны внутренних и внешних документов).
Параллельно с построением процессов проводится формализация требований к доработкам и настройкам ИТ-систем банка (как старых, так и новых). Настройки осуществляются в соответствии с описаниями продуктов и сервисов, функций и задач цепочки процесса, а также с ролевой моделью, из которой формируется карта доступа к системам. На практике в этот процесс эффективно включать представителей вендоров систем. Настройка — процесс довольно сложный, который может занять от двух до четырех месяцев.
Команда:
- аудитор банка;
- главный архитектор банка;
- главные архитекторы партнеров, внедряемых и перестраиваемых систем (представители вендора);
- банковские методологи (могут быть из компании-партнера);
- модератор (методолог с широким профессиональным опытом, владеющий методологией построения процессов).
При сильном расхождении процессов TO BE 2 и ТО BE 1 в команду вводятся участники от бизнеса и риск-менеджмента для оперативной корректировки процессов и поиска наилучшего варианта:
- представитель корпоративного бизнеса;
- представитель малого бизнеса;
- представитель розничного бизнеса;
- представитель инвестиционного бизнеса;
- риск-менеджеры.
Внедрение новых процессов — 11 этапов
До этого шла речь в некотором смысле о подготовительной стадии проекта. Стадия внедрения новых процессов намного сложнее. На практике до финального, запланированного результата доходят не все проекты. Сложность в том, что в процесс вовлечена вся организация, и кроме своих ежедневных задач сотрудникам приходится тратить время на изучение, тестирование, пилотную эксплуатацию новой схемы процессов. В среднем нагрузка на сотрудников возрастает на
Внедрение новых процессов разбивается на несколько этапов.
Первый этап, который может стартовать параллельно описанию процессов TO BE 2, — настройка новых систем, интеграция, перенос продуктового каталога. Перенос может быть организован как конвейер: каждый описанный и согласованный процесс сразу отдается на реализацию, не дожидаясь окончания полной прорисовки карты процессов. Интеграционные потоки между системами могут стартовать еще раньше. В этом процессе основная нагрузка ложится на ИТ-службы и методологов. Параллельно с настройкой процессов устанавливаются права доступа пользователей к системам. На этом этапе рекомендуется применять подход расширенного распределения прав (избыточное распределение).
Второй этап — выделение фокусных групп и тестовых отделений. Схема фокусных групп утверждается правлением, заполнение схемы сотрудниками отдается на усмотрение руководителей соответствующих подразделений. Группа утверждается приказом с четкой фиксацией обязанностей и ключевых показателей эффективности (KPI). В состав фокусных групп должны войти наиболее профессиональные сотрудники.
Третий этап — обучение фокусных групп, построение программы тестирования. Построение программы целесообразно объединить с обучением. В задачи фокусной группы входит подготовка тестовых сценариев, которые будут использоваться в последующем тестировании и обучении банковского персонала.
Следующие три этапа могут идти параллельно.
Четвертый этап — тестирование, доработка и расширение тестовых сценариев. На этом этапе основной акцент делается на проверку работоспособности процессов и доработки, связанные с ошибками, неполной формализацией требований, некорректными настройками. Результатом этого этапа является оттестированная инфраструктура, готовая к опытной эксплуатации.
Пятый этап — формирование лидеров изменений: из каждого подразделения по несколько специалистов. Схема лидеров изменения готовится и утверждается правлением банка. Заполнение схемы, как и в случае фокусных групп, отдается на уровень руководителей подразделений, но, в отличие от выбора сотрудников для фокусных групп, здесь добавляется критерий лидерских качеств (специалисты должны быть неформальными лидерами в своих подразделениях).
Шестой этап — обучение лидеров изменений. Оно может быть очным в центре обучения или в тренинг-центре кредитной организации.
Седьмой этап — передача знаний и обучение сотрудников кредитной организации. Этот этап проходит на тестовых сценариях с использованием дистанционных систем обучения и наставничества лидеров изменений. Начиная с этого этапа в проекте принимает участие весь персонал банка. Задача руководителей подразделений — организация нормальной ежедневной работы служб с выделением от 30 до 50% времени сотрудников на обучение и прохождение тестовых заданий.
После обучения проводится аттестация — восьмой этап. Это тестирование, аттестация сотрудников. Тестовые задания проверяются централизованно, контроль за соблюдением правил тестирования возлагается на руководителей подразделений. Именно они являются заказчиками качественной подготовки персонала. По полученным результатам оцениваются лидеры изменений. Основа KPI лидеров — уровень подготовки вверенного им персонала.
Девятый этап — перенос в новые системы портфеля договоров.Этот этап выполняется параллельно этапам 5 — 8, но после завершения четвертого этапа. Здесь основная нагрузка снова ложится на ИТ и методологов.
Десятый этап — тестовые дни. В выходные повторяются все операции пятницы в новых процессах и новых системах. Данный этап — самый сложный для кредитной организации. Сотрудники банка выходят в выходные, как правило, субботы не хватает для повторения операций пятницы, и персоналу приходится работать без отдыха. В промежутках между тестовыми днями производится проверка процессов, настроек, анализ ошибок персонала. Работа над ошибками ведется как бизнес-персоналом банка, так и службами ИТ по корректировкам систем. Данный процесс может занять один—два месяца (три—четыре раза). Можно рекомендовать увеличенный срок (два месяца). Режим тестовых дней — один раз в две недели. В период тестовых дней нагрузка на персонал банка возрастает в
Одиннадцатый этап — запуск новых процессов. Последний тестовый день при достижении критерия успешности переводит процессы в новый формат. Банк с понедельника перестает работать в старой структуре. Желательно данный процесс планировать на расширенные выходные (с праздничными днями), так как подобное переключение гладко не проходит, и надо иметь запас для экстренной корректировки инфраструктуры. Если по окончании выходных критерий успешности не достигнут, переключение переносится на следующий цикл.
Неправильно считать, что на этом процесс завершен. Первый месяц работы банка в новых процессах так же сложен, как и тестовые дни. Необходима усиленная поддержка бизнес-подразделений и особенно ИТ-служб и методологов.
Выводы
Все вышеописанное — это не теория, а инсайды одного успешного проекта, который был реализован за шесть месяцев для средней многофилиальной кредитной организации с полной заменой основных банковских систем. Оценивая масштабы изменений, приходим к выводу, что комплексный проект реинжиниринга процессов не может жить в одном-двух выделенных подразделениях банка, а является грандиозным вызовом для всей кредитной организации.
Автор статьи — Product&Marketing Director, компания RBtechnologies.
