У оптимизации процессов непростая судьба. В середине двухтысячных даже запрещалось упоминать это слово, как скомпрометированное подразумеванием бесполезной деятельности. До сих пор люди стараются использовать синонимы типа реинжиниринг, improvement, performance и т.п. Тем не менее повышение эффективности является одной из целей деятельности по управлению бизнес-процессами. Основой для оптимизации является результат анализа данных об окружении и содержании процесса. В случае отсутствия возможности сбора статистических данных (например при дизайне нового процесса), они генерируются симуляторами БП.
В одном из предыдущих постов на Хабре я рассказал об онлайн-сервисе имитационного моделирования бизнес-процессов bpsimulator.com. Сегодня мы постараемся с его помощью решить конкретную задачу по повышению эффективности работы, например процесса розничного кредитования банка.

Цель оптимизации

Одна из ошибок — это начинать оптимизацию ради оптимизации, но мы нее такие, у нас есть вводная: рядом с отделением банка открылась точка продаж конкурирующего банка, предлагающего аналогичный продукт. Технологию и продукт менять нельзя, необходимо уменьшить время с момента подачи заявки до выдачи кредита для образования конкурентного преимущества.

Сбор данных о бизнес-процессе

Для начала необходимо собрать данные о необходимых функциях, их последовательности и исполнителях:
Список функций
1. «Оформление кредитной заявки» выполняет «Операционист» за 15-30 минут
2. «Верификация данных» выполняет «Верификатор» за 5-15 минут
3. «Определение рисков» выполняет «Скоринг (автоматически)» за 1 минуту
4. «Проверка СБ» выполняет «Сотрудник СБ» за 10-15 минут
5 «Принятие решения» выполняет «Кредитный менеджер» за 5-10 минут, процент одобрения (Approval Rate) AR=0.1
6. «Информирование клиента» выполняет «Оператор колл-центра» за 5 минут
7. «Уведомление об отказе» выполняет «SMS-шлюз (автоматически)» за 30 секунд
8. «Оформление кредита» выполняет «Операционист» за 10-20 минут
9. «Зачисление средств» выполняет «АБС (автоматически)» за 1 минуту
Состав организационных структур
1. Операционист: 2 сотрудника в 10 дополнительных офисах
2. Верификатор: 6 сотрудников в филиале
3. Сотрудник СБ: 10 сотрудников в филиале
4. Кредитный менеджер: 5 сотрудников в филиале
5. Оператор КЦ: 2 сотрудника КЦ
Внешние факторы
1.В отделение в день обращаются в среднем по 32 посетителя, равномерно в течении всего рабочего дня

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

Визуальное моделирование бизнес-процесса

Заходим на сервис, запускаем приложение и выбираем русский язык и создание новой модели. Щелкнув правой кнопкой мыши на названии, меняем его на «1.0.0 Розничное кредитование в банке ОАО АКБ „XXX“.

Это покажется разумным в дальнейшем, когда коллеги увидят экран вашего монитора.

Единственное, что пока находится в рабочей области — это панель управления с разделами: Модель, Дизайн, Симуляция и Вид. В разделе Дизайн нажимаем „Добавить генератор“ — это генератор задач, в нашем случае это генератор посетителей банка, желающих оформить кредит. Рядом расположена так же кнопка „Добавить функцию“, нам понадобится их 9. Разместим мышью эти объекты на модели последовательно сверху вниз.
У каждого объекта есть „вход“ — верхняя часть и „выход“ — нижняя. Для соединения объектов кликнем на „+“ в районе „выхода“ вышестоящего объекта и затем на „+“ нижестоящего (или любого другого). Так появится связь со стрелкой от выхода одного объекта ко входу другого.

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

Для изменения должности исполнителя необходимо дважды кликнуть на строку с ресурсом (помечено цифрой 3 на рисунке). Откроется окно менеджера ресурсов. Название должности надо поменять и нажать там же на галочку „Сохранить ресурс“, тогда название поменяется во всех функциях, где задействован данный специалист. Для функции „Оформление кредита“ в выпадающем списке надо выбрать уже созданного нами „Операционист“, а лишнюю строчку удалить. По окончанию моделирования окно „Управление ресурсами“ выглядит следующим образом (одну неиспользуемую автоматически созданную должность я удалил):

У функции „Принятие решения“ надо сделать два выхода, один на функцию „Информирование“, а второй на „Уведомление об отказе“. Таким образом на выходе этой функции образуется правило распределения хода процесса, логическое „ИЛИ“ (или будет принято положительное решение по кредиту и надо приглашать клиента в офис -10%, или достаточно будет проинформировать клиента об отрицательном решении -90%). Свойства функции должны выглядеть следующим образом:

Генератор назовем „Обращение клиента“, в разделе „Время работы“ дважды кликнув на строке „09:00-18:00“ можно редактировать количество клиентов в течение рабочего дня.
На этом этап моделирования обычно заканчивается, наша модель выглядит следующим образом:

Модель пройдет проверку на корректность, но не проходит проверку на адекватность. У нас сотрудники мидл-офиса филиала обслуживают заявки ещё 9 отделений и это обязательно надо смоделировать для получения адекватных результатов.

Можно конечно слить всех операционистов в одно абстрактное отделение, но тогда если пришло три посетителя в офис с двумя операционистами, то последний встанет в очередь на обслуживание, а в абстрактном допофисе его „примет“ свободный специалист из другого города. А если разделить кол-во сотрудников филиала на количество отделений, то будет смешно и не адекватно.
Возможно ещё продублировать генераторы и функции операциониста на модели ещё 9 раз, получится наглядно, но громоздко.

Добавим ещё один генератор задач с названием „Оформление заявки в другом ДО“ и количеством задач 32*9 = 288 в течение рабочего дня. Выход генератора подадим на вход функции „Верификация данных“. Между информированием клиента и оформлением кредита надо поставить фильтр, что бы заявки второго генератора не уходили в одно отделение. Поставим между ними объект „Точка контроля“ из раздела „Дизайн“ и в его свойствах надо нажать „Разрешить“ генератору с названием „Обращение клиента“ — дальше пройдут только те заявки, который этот операционист оформлял. Окончательная модель имеет вид:

Теперь можно запускать.

Имитационное моделирование бизнес-процесса

На панели инструментов в разделе „Симуляция“ нажимаем „Пуск“ — начнется симуляция, цифры на объектах модели будут отражать состояние процесса в масштабе времени 1 секунда реального времени равна 1 минуте времени процесса. Симуляция прекратиться через сутки процессного времени, т.е. через 24 минуты реального. Это долго, поэтому можно нажать следующую кнопку „Ускорить“ — тогда на расчет суток уйдет всего 24 секунды. По окончании симуляции у нас будут собраны все данные о состоянии процесса, задач, функций и загруженности сотрудников в течение всего периода симуляции.

Анализ бизнес-процесса

В разделе „Вид“ панели инструментов находится кнопка открытия окна „Статистика“, в нем во вкладках расположены графики состояния процесса. Так как у нас цель — уменьшить время выполнения задач, смотрим на вкладку „Задачи“:

среднее операционное время составляет около часа. Это значение нам надо будет как-то уменьшать. Первое, что приходит в голову — увеличить количество сотрудников на самых нагруженных участках. На вкладке „Чел. ресурсы“ видно, что на пределе своих сил работают верификаторы.

В разделе „Вид“ панели инструментов находится кнопка „Ресурсы“ открытия окна „Менеджер ресурсов“, увеличим количество верификаторов с 6 до 8 человек (не забываем нажимать галочку сохранения ресурса)

Операционное время работы над задачами практически не изменилось, но у верификаторов появилось слишком много свободного времени. Значит копать надо в другом направлении, например на времени выполнения критичной функции. У функции „Верификация данных“ максимальное время выполнения 15 минут в три раза больше минимального 5 минут. А что если удастся снизить максимальное время верификации до 10 минут? Для проверки гипотезы вернем количество верификаторов -6, а время выполнения функции „Верификация данных“ установим 6-10 минут. Запустим симуляцию.

Операционное время уменьшилось минут на 15, т.е. на 25%, а на некоторых прогонах этот результат доходит и до 50%, что является фактом того, что дальнейшую оптимизацию имеет смысл проводить на уровне конкретной функции.

Заключение

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

Оптимизируем бизнес-процесс с помощью симулятора