Автоматизация бизнес-процесса принятия решения по заявке на лизинг

Далее в системе создается схема процесса - последовательность выполнения операций, позволяющих достигать запланированный результат в рамках процесса. Как уже было подчеркнуто ранее, настройка схем процессов осуществляется в нотации BPMN 2.0, и соответственно система имеет готовый набор инструментов для создания схемы. Это включает в себя блоки для выполнения операций, логические операторы (шлюзы), начальные, промежуточные и конечные события, пулы, артефакты, переходы между блоками и так далее. Важной особенностью системы GreenData является возможность внутренней настройки поведения каждого отдельного элемента схемы. Например, для блока операции может быть задано не только тип задачи (например, пользовательская, сервисная), но и исполнитель/группа исполнителей, визуальное отображение задачи, работа с документами в рамках задачи, алгоритмы расчета необходимых показателей, условия завершения задачи. Важно подчеркнуть, что при выполнении процесса для каждой задачи создается экземпляр системного типа объекта «ДО. Задача на процессе».

Настройка ответственных

Следующий раздел настройки - настройка ответственных по процессам. Для того, чтобы осуществить это в системе GreenData создаются экземпляры системного типа объекта «Группа доступа». Другими словами, определяются группы пользователей, которые будут работать в системе.

Далее в системе осуществляется сама настройка ответственных. В системном типе объекта «Настройка курируемости» создается экземпляр, в котором содержится наименование настройки, связь с ранее созданной сущностью, с которой будет вестись работа, и таблица с матрицами.

Сами матрицы определения ответственных располагаются в системном типе объекта «Матрица курируемости».

На карточку заносятся наименование процесса, поведение матрицы по отношению к сущности и конкретному бизнес-процессу, курируемая и курирующая роль. В качестве ролей используются ранее созданные группы доступа (группы пользователей) и их поведение при выполнении задач в конкретном процессе. Также в системе GreenData реализуется следующий принцип работы матрицы в процессе: при запуске бизнес-процесса определяется сотрудник «Инициатор»- сотрудник, запустивший процесс. Далее по матрице курируемости определяется круг потенциальных ответственных сотрудников. Если сотрудники являются участниками обособленного подразделения, поиск осуществляется следующим образом:

Поиск обособленного подразделения.

Если указано значение вида позразделения, то поиск сотрудников обособленного подразделения осуществляется с текущего подразделения (зависит от подразделения сотрудника-инициатора) и вверх по иерархии подразделений.

Если вид подразделения отсутствует, то поиск ответственных осуществляется в рамках подразделения сотрудника-инициатора.

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

Если сотрудники не являются участниками обособленного подразделения, поиск ответственных сотрудников осуществляется так:

Определяется подразделение по матрице курируемости.

Производится поиск сотрудников с необходимой ролью в найденных подразделениях.

Ответственным сотрудникам присваиваются права на просмотр/редактирование/сохранение объекта. Также, сотрудник, выполнивший задачу по объекту, автоматически становится ответственным на роль.

После выбора курируемой и курирующей роли в системе формируется курируемость подразделений. Курируемые подразделения располагаются по вертикали, курирующие по горизонтали. В матрице выбирается пересечение необходимых подразделений. Система выделит их цветом.

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

Настройка нормативных сроков

К следующему разделу построения бизнес-процессов относят установление нормативных сроков- временных границ для выполнения задач на этапах процесса и всего процесса в целом. Карточка нормативного срока выглядит следующим образом.

На карточке указывается наименование срока, его связь с ранее созданными сущностями (типами объектов), продолжительность срока, связь с процессами/конкретными этапами/задачами и статусами. Таким образом, нормативный срок будет выполняться только в конкретном промежутке процесса, указанном при настройке.

В системе GreenData предусмотрена возможность приостановки выполнения нормативным сроков при выполнении пользовательских задач на процессе. Приостановка отсчета времени нормативного срока может быть выполнена автоматически или вручную. Для приостановки нормативного срока предусмотрена функция «Приостановить нормативный срок». После приостановки завершить задачу становится невозможным. Для возобновления нормативного срока так же предусмотрено восстановление нормативного срока.

Работа с задачами/реестрами задач, схемами маршрутов процессов

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

Для каждого пользовательского действия необходима настройка задачи. Типичная задача обладает следующим набором параметров:

Объект, по которому был запущен процесс.

Экземпляр процесса.

Описание задачи.

Входящие данные.

Входящие документы.

Комментарий с прошлого этапа.

Результат.

Исходящие документы.

Исполнитель.

Сотрудник-инициатор.

Дата назначения.

Комментарий к задаче.

Возможна индивидуальная настройка представления задачи под требования конечного пользователя. За это в системе отвечает системный тип объекта «Визуальная группировка».

Также в системе предусмотрена возможность контроля выполнения бизнес-процесса посредством просмотра схемы маршрута (см.рис.3.2.3). Это означает, что в режиме реального времени возможен контроль над выполнением процесса. Зеленым цветом на схеме маршрута отображаются выполненные этапы, красным- активные элементы. Также имеется информация об исполнителе задачи, времени выполнения задачи, длительности, дополнительной информации. Схема маршрута возможна из карточки объекта, по которому был выполнен запуск бизнес-процесса.

Рисунок 3.2.3- Схема маршрута выполнения процесса

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

3.3 Автоматизация бизнес-процесса принятия решения по заявке на лизинг на платформе GreenData

Исходя из выполненного описания технологии работы встроенного модуля платформы GreenData по работе с бизнес-процессами, работа по автоматизации бизнес-процесса принятия решения по заявке на лизинг была следующей.

Создание объектной модели

В системе GreenData были созданы основные сущности, с которыми будет вестись работа (пример карточки типа объекта представлен ниже (рис.3.3.1):

Заявка на лизинг.

Анкета по лизингу.

Документ, удостоверяющий личность.

Адреса.

Рисунок 3.3.1- Тип объекта для реализации автоматизации процесса по принятию решения

Типы объектов для выгрузки результатов интеграций при проведении проверок (банкротство по ЕФРСБ, исполнительные производства по ФССП и так далее).

Обеспечение.

Расчет скоринга.

Важно отметить, что вышеперечисленные типы объектов не являются окончательным перечнем необходимых сущностей. Объектная модель может быть дополнена различного рода справочниками, таблицами, несущими информацию, прямым образом не участвующую в процессе принятия решения. В ходе создания типы объектов также создались в базе данных, и на данный момент объектная модель выглядит следующим образом (см.рис.3.3.2).

Рисунок 3.3.2- Объектная модель для работы процесса по принятию решения по заявке на лизинг

Определение групп пользователей для работы

Далее были определены группы пользователей системы, которые будут принимать участие в процессе принятия решения. Они были выделены ранее при выполнении моделирования процесса.

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

Сотрудники центра обработки заявок в рамках процесса выполняют контроль введенных в дилерском центре данных, верифицируют их. При нахождении несоответствий отправляют данные на доработку в дилерский центр.

Кредитные специалисты в рамках процесса осуществляют одну из основных операций процесса- принятие решения по заявке на лизинг

Ниже представлена диаграмма прецедентов для всех выделенных ролей, участвующих в процессе (рис.3.3.3).

Рисунок 3.3.3- Диаграмма прецедентов для ролей, участвующих в процессе

Таким образом, в системе были созданы три группы пользователей:

Сотрудник дилерского центра.

Сотрудник центра обработки заявок.

Кредитный специалист.

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

Затем были созданы бизнес-процессы - карточки и схемы, исходя из ранее выполненного моделирования процесса. Хочется подчеркнуть, что процесс был разделен на отдельные процессы во избежание появления ошибок, быстрого отслеживания работы процессов и более высокой скорости запуска. В связи с тем, что сотрудники дилерского центра заполняют данные по заявкам по мере их поступления, первые этапы процесса - «Заполнить анкеты лизингополучателя и поручителей» и «Заполнить форму заявки на лизинг» осуществляются вне процесса.

Следующий этап - «Проверить контрагентов заявки» выполняется автоматически. Он был разбит на более мелкие процессы. В каждом содержится запуск интеграции c внешним сервисом (СПАРК, Credit Registry), обработка ошибок, если они были найдены (некорректный запрос, отсутствие необходимых данных для запроса), пользовательская задача для устранения ошибки и смена статуса заявки. Пример карточки процесса «Проверить контрагентов заявки» представлен ниже (рис.3.3.4).

Рисунок 3.3.4- Карточка процесса «Проверка статуса компании (СПАРК)»

Требуется обратить внимание на ряд моментов:

Заполнено наименование процесса.

Создана связь с основной сущностью - Заявкой на лизинг.

Признак «Разрешен параллельный запуск - нет, поскольку данный процесс по одному объекту должен быть запущен в момент времени только один раз.

Признак «Запрещен ручной запуск» - да, поскольку запуск процессов осуществляется автоматически.

Признак «Отложенное выполнение задач» - да, поскольку необходимо взять задачу в работу сотрудником, прежде чем начинать ее выполнение.

Аналогичные настройки будут иметь все карточки бизнес-процессов, созданные в рамках процесса принятия решения по заявке на лизинг. Пример одной из схем процесса «Проверить контрагентов заявки» представлен ниже (рис.3.3.5).

Рисунок 3.3.5- Схема процесса ««Проверка статуса компании (СПАРК)»

Как ранее было описано, по результатам проверок автоматически принимается решение, может ли заявка быть отклонена. Для этого в рамках системы был создан алгоритм, который проверяет наличие критериев автоматического отказа по заявке на лизинг (рис.3.3.6). Критерии в виде логических атрибутов в свою очередь заполняются при получении результата выполнения интеграции этапами ранее.

Рисунок 3.3.6- Алгоритм по нахождению критерий автоматического отказа по заявке на лизинг



Следующий этап - «Верифицировать данные клиента». Процесс состоит из пользовательской задачи и нескольких вариантов решений - отправить на доработку в дилерский центр, отправить заявку дальше. Настройка пользовательской задачи для группы сотрудников выглядит следующим образом (рис.3.3.7).

Рисунок 3.3.7- Настройка пользовательской задачи «Верифицировать данные по заявке на лизинг»

Были выполнены следующие настройки:

Заполнено наименование.

Тип этапа - Пользовательская задача.

Тип назначения сроков задачи - Фиксированный срок в часах (расчет нормативных сроков осуществляется в часах).

Вид задачи этапа - Выбор вариантов, поскольку сотруднику предложено два способа завершения задачи.

Заполнен шаблон описания задачи для сотрудника.

Роль исполнителя задачи - Сотрудник центра обработки заявок.

Признак «Исполнитель задачи - курируемый» - да.

Далее были настроены два процесса- «Внести изменений по заявке на лизинг» и «Скоринг клиента». Их запуск зависит от выбранного решения сотрудником центра обработки заявок этапом ранее. Процесс «Внести изменений по заявке на лизинг» предусматривает пользовательскую задачу, тип настройки которой был описан ранее («Верифицировать данные клиента»). Более нестандартным бизнес-процессом является процесс «Скоринг клиента», поскольку задействует встроенный расчетный модуль платформы GreenData. Изначально был создан алгоритм, рассчитывающий вычислимые показатели для скоринга, основываясь на данных из заявки на лизинг (рис.3.3.8).

Рисунок 3.3.8- Фрагмент алгоритма по расчету вычислимых показателей скоринга

Далее был создан алгоритм, рассчитывающий скоринговый балл, класс и PD (вероятность банкротства) (рис.3.3.9).

Рисунок 3.3.9- Фрагмент алгоритма по расчету скорингового класса на основании полученного балла

Рисунок 3.3.10- Схема процесса «Скоринг клиента»



Процесс «Скоринг клиента выглядит следующим образом (рис.3.3.10).

Как уже ранее было отмечено, что для выполнения некоторых этапов процесса осуществляется создание алгоритмов на платформе GreenData. За это отвечает расчетный модуль системы. В бизнес-процессе выполнение алгоритмов осуществляется в рамках сервисной задачи (см.рис.3.3.11). Во внутренних настройках задачи указывается алгоритм для определения объекта и сам алгоритм расчета.

Рисунок 3.3.11- Пример настройки сервисной задачи, в рамках которой запускается алгоритм расчета

Далее был создан процесс «Создать лимит на заявку». Для этого был также задействован расчетный модуль платформы. Схема процесса создания лимита выглядит следующим образом (рис.3.3.12). В основном процесс состоит из сервисных задач, которые вызывают выполнение необходимых алгоритмов для расчета соответствующего лимита.

Следующим этапом является процесс «Анализировать критерии по результатам проверок». Процесс предусматривает выполнение сервисной задачи, в рамках которой выполняется алгоритм по проверке необходимых критериев (рис.3.3.13).



Рисунок 3.3.12- Схема процесса «Создать лимит на заявку»

Также алгоритм предусматривает маршрутизацию заявки. При отсутствии каких-либо критериев заявке автоматически присваивается статус «Автоматически одобрена», процесс принятия решения завершается. Если же был обнаружен хотя бы один критерий, заявке переходит в статус «Одобрение».

Рисунок 3.3.13- Фрагмент алгоритма по проверке критериев

Далее был построен финальный процесс- «Принять решение по заявке на лизинг» и «Утвердить решение по заявке на лизинг». Было принято решение объединить эти пользовательские задачи в один процесс, поскольку выполняются сотрудниками одной группы пользователей. Процесс выглядит следующим образом (рис.3.3.14).

Рисунок 3.3.14- Схема процесса «Принять и утвердить решение по заявке на лизинг»

Отличительной чертой этого процесса от других является наличие сервисной задачи, целью которой является очистка ответственного. Цель этой операции связана с тем, что при выполнении задач, где ответственными является одна и та же группа пользователей по заявке устанавливается ответственным конкретный сотрудник, выполнивший первую задачу, в данном случае «Принять решение о возможности предоставления лизинга». Исходя из логики системы, вторая задача - «Утвердить решение и возможности предоставления лизинга» будет назначена на этого же сотрудника, что не соответствует логике процесса - задача должна быть назначена на всех участников группы пользователей.

На этом создание карточек и схем бизнес-процессов окончено.

Создание матриц ответственных



Рисунок 3.3.15- Пример настройки матрицы курируемости

Ранее было отмечено, что в системе были созданы три группы пользователей- Сотрудники дилерского центра, Сотрудники центра обработки заявок и Кредитные специалисты. Принцип настройки матрицы курируемости будет описан на примере матрицы для сотрудников группы «Кредитные специалисты. Пример приведен ниже (рис.3.3.15).

Следует обратить внимание на ряд моментов:

Указано наименование матрицы.

Признак «Обособленное подразделение»- да, поскольку курируемая и курирующая роль относятся к одной группе пользователей - Кредитный специалист.

Указаны курируемая и курирующая роль- ранее созданные группы пользователей.

Признак «Применять для назначения ответственных» - да, поскольку это необходимо при выполнении пользовательских задач.

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

Таким же образом были настроены матрицы курируемости для других групп пользователей.

Создание нормативных сроков

Для каждой пользовательской задачи был определен нормативный срок выполнения и, соответственно, сделана соответствующая настройка. Принцип настройки будет описан на примере нормативного срока для задачи «Верифицировать данные клиента (рис.3.3.16).

Рисунок 3.3.16- Пример настройки нормативного срока

Основные моменты настройки нормативного срока:

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

Настройка задач и реестра задач, просмотр схем маршрута запусков

При настройке карточек задач была оставлена стандартная структура, предложенная системой. Реестр задач выглядит следующим образом (рис.3.3.17). В реестре прописан номер задачи (устанавливается автоматически), наименование задачи, статус выполнения, контрагент, наименование заявки и сотрудник, который выступил в качестве исполнителя.

Рисунок 3.3.17- Реестр задач для сотрудника



Также в ходе тестирования настроенного процесса был выполнен просмотр схемы маршрута процесса. На примере присутствует схема маршрута процесса «Анализировать критерии по результатам проверок», все шаги процесса были выполнены успешно (рис.3.3.18).

Рисунок 3.3.18- Пример схемы маршрута настроенного процесса

В первой части главы была описана структура и деятельность одноименной компании-разработчика платформы GreenData. Также были рассмотрены функциональные возможности платформы и ее основные модули.

Во второй части главы была изучена технология и работа встроенного модуля платформы GreenData, которая отвечает за построение и настройку бизнес-процессов. Она предусматривает осуществление ряда настроек:

Настройка объектной модели с бизнес-процессами.

Настройка карточек и схем бизнес-процессов.

Настройка ответственных по процессам.

Настройка нормативных.

Работа с карточками и реестрами задач для пользователей, просмотр схемы маршрутов выполнения процессов.

В третьей части главы описана реализация автоматизации процесса принятия решения по заявке на лизинг на базе платформы GreenData, а именно выполнены следующие задачи:

Определены сущности для работы и составлена объектная модель.

Определены группы пользователей, принимающие участие в процессе, созданы в системе.

Созданы и настроены карточки и схемы процессов.

Созданы и настроены матрицы определения ответственных.

Созданы и настроены нормативные сроки для выполнения задач.

Определены карточки задачи пользователей.

Осуществлен просмотр схем маршрутов процессов в ходе выполнения тестирования.



Заключение

В рамках выпускной квалификационной работы был автоматизирован бизнес-процесс принятия решения по заявке на лизинг. Были получены следующие результаты:

Выполнен обзор рынка банковских услуг.

Изучена банковская услуга лизинг; ее характеристики и основные участники. Выполнено детальное описание процесса принятия решения по заявке на лизинг:

Описание каждого этапа процесса.

Определены участники процесса.

Построена матрица связности этапов и участников процесса.

Произведен расчет стоимости процесса.

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

Построена модель бизнес-процесса AS IS.

Построена модель бизнес-процесса TO BE, которая учитывает указанные при описании риски, что позволит минимизировать число ошибок, а также снизить стоимость самого процесса больше чем на треть.

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

Осуществлена автоматизация процесса принятия решения по заявке на лизинг с использованием возможностей платформы GreenData.

Платформа GreenData с настроенным автоматизированным процессом принятия решения по заявке на лизинг уже внедрена в работу банковской организации, занимающейся лизингом автомобилей по всей России.

Библиографический список

1. ISO 9000:2000 Системы менеджмента качества. Основные положения и словарь

2. Исаев Р. А. «Бизнес-архитектура и системы управления банком», Москва: ИНФРА-М, 2010 г

3. Флерова А.Н. «Что такое лизинг», Российский внешнеэкономический вестник. 2007. №1(2007) стр.132-141.

4. Исаев Р. А. «Секреты успешных банков: бизнес-процессы и технологии» (2-е издание). - Москва: ИНФРА-М, 2015.- 260 с.

5. Елиферов В.Г., Репин В. В. «Бизнес-процессы: Регламентация и управление»: учебное пособие; Москва: НИЦ ИНФРА-М, 2013. - 319 c.

6. Глухих Л. В., Родин Д. Я. «Развитие банковских инноваций, основанных на оптимизации бизнес-процессов коммерческого банка», Банковский сектоР, 9 (225), г. Краснодар, 2013, стр.46-54

7. Смолякова Н.В. «Место реинжиниринга бизнес-процессов в инновационном менеджменте банка»// Креативная экономика. -- 2015. -- № 1 (97). -- с. 137-148.

8. Гаджигишиев Х.Г., Дохолян С.В. «Использование информационных технологий в управлении лизинговыми процессами»// Региональные проблемы преобразования экономики. -- 2011. -- № 5 (31).

9. Грекул В. И., Коровкина Н. Л., Левочкина Г. А. «Проектирование информационных систем: учебник и практикум для академического бакалавриата.» - М.: Издательство Юрайт, 2017, с.67-81, с.107-110

10. Remco Dijkman, Irene Vanderfeesten, Hajo A. Reijers “Business process architectures: overview, comparison and framework”, Eindhoven University of Technology, Eindhoven, Netherlands, 2014

11. Sabah Al-Fedaghi, Mahmoud BehBehani “Modeling Banking Processes”, International conference on Information and Computer Technoogies, 2018

12. Robin Teigland, Shahryar Siri, Anthony Larsson, Alejandro Moreno Puertas, Claire Ingram Bogusz “The Rise and Development of FinTech”, London, 2018-p.327-349

13. Michael Bjцrn “The adoption of online banking in Sweden”, 2018

14. Чайкина Е. В., Козинкин А.А., Чайкин В. Ю. «Инновационные технологии как фактор конкуренции на банковском рынке России», Научный вестник: Финансы, банки, инвестиции - 2018 - №4, с.114-121

15. Башкирова В. Е., Волошина О. Б., Гордеева О. А. «Кредитование как автоматизированный бизнес-процесс», Модели, системы, сети в экономике, технике, природе и обществе. - 2015. - № 4 (16). - с. 24-30.

16. Кочеихин А.Л. «Бизнес-процессы как основной фактор инновационной деятельности коммерческого банка. реинжиниринг бизнес-процессов», Транспортное дело России. - 2011. с. 36-38.

Размещено на Allbest.ru

...