научное издание МГТУ им. Н.Э. Баумана

НАУКА и ОБРАЗОВАНИЕ

Издатель ФГБОУ ВПО "МГТУ им. Н.Э. Баумана". Эл № ФС 77 - 48211. ISSN 1994-0408

Модель алгоритмического представления бизнес-процесса.

Файл статьи:

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

Бизнес-процесс можно описать как определенную последовательность действий, приводящих к заранее известному результату, имеющую точку начала и точку конца.

С каждым годом идея представления любых направлений деятельности предприятия в виде бизнес-процессов становится все более и более популярной, что не могло не привести к появлению программных продуктов, специализированных как просто для моделирования бизнес-процессов, так и для построения полноценных приложений и систем на их основе. Такие продукты получили название BPM – систем (от англ. ”Business Process Management” - “Управление бизнес-процессами”). Наиболее популярные в этой области продукты — это решения от Oracle, IBM, SAP, а также системы с открытым исходным кодом, такие как JBPM от RedHat, Bonita BPM от Talend и т.д.

Создание приложений на основе BPM – систем имеет ряд неоспоримых преимуществ перед аналогичными по функциональности приложений, созданных, например, с применением объектно-ориентированных языков программирования. Среди них: относительная простота определения выполняемой приложением последовательности действий, реализуемая путем моделирования бизнес-процесса, увеличение скорости разработки, возможность быстро внести изменения в приложение. Кроме того, такие компании как Oracle обеспечили разработчиков BPM – систем возможностью быстрой интеграции бизнес-процессов с другими продуктами из линейки вендора, например, с базами данных, с помощью уже готовых адаптеров.

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

Связь между бизнес-процессом и алгоритмом

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

Для того, чтобы это понять, рассмотрим еще одно понятие — алгоритм.

Алгоритм— это конечный набор правил, который обладает пятью важными чертами: конечность, определённость, ввод, вывод, эффективность[1] (Д. Э. Кнут).

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

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

В качестве доказательства близкого сходства, почти тождественности, понятий «бизнес-процесс» и «алгоритм» на рисунке 1 приведено графическое представление реального бизнес-процесса. Рассматриваемый в данной статье бизнес-процесс представляет собой упрощенный процесс согласования кредитной заявки в банке, цель заключается в проведении заявки на получение кредита, созданной пользователем путем заполнения форм, через все этапы согласования. На основе диаграммы этого бизнес-процесса создается полноценное автоматизирующее его приложение, которое разворачивается на сервере приложений. Все пользовательские действия выполняются в рабочем пространстве, также развернутом на сервере приложений и доступном для пользователей через браузер. Взаимодействие пользователя с приложением осуществляется с помощью экранных форм. На практике данный процесс автоматизирован с помощью продукта Oracle BPM 11g.

Первый этап: клиент вводит данные по кредиту путем заполнения форм. Перечень данных стандартен для процедуры получения кредита: паспортные данные, данные о работодателе, размере заработной платы, наличии иждивенцев и т. д., а также прикрепляет к заявке документы в электронном виде и оставляет комментарий.
Второй этап: сотрудник Фронт-офиса банка получает заявку от клиента и, на основании введенных данных, делает вывод о полноте и правильности предоставленной информации. В зависимости от этого вывода сотрудник фронт-офиса направляет заявку на следующий этап процесса или возвращает ее клиенту для редактирования, оставив при этом соответствующий комментарий.
Третий этап (содержит внутренний параллелизм): заявка попадает одновременно в Кредитный и Юридический отделы банка. Сотрудники каждого из этих департаментов принимают решение о редактировании заявки клиентом или о переходе ее на следующий шаг. Переход на следующий шаг возможен только в том случае, если сотрудники обоих департаментов одобрили заявку; если же хотя бы один из них этого не сделает, заявка вернется к клиенту на этап редактирования.
Четвертый этап: заявка попадает к участнику в роли Кредитного эксперта, который аналогичным образом делает вывод о необходимости возвращения заявки клиенту, либо о возможности передачи заявки на следующий этап.
Пятый этап: заявка остается у Кредитного эксперта, который создает документ в любом из форматов на основе данных из заявки и отправляет ее в архив.

Примечание 1: в процесс также входят такие автоматические действия как запись в базу данных информации о клиенте, запись в базу данных информации о кредите, а также несколько бизнес-правил.
Примечание 2: каждый из этапов процесса может представлять собой другой подпроцесс. Количество вложенных процессов не ограничено.

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

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

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

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

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

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

BEGIN
AP
if (!Действие1 подтверждено) {
                        Редактировать1
                        Подтверждение действия
            } else if (!Действие2 подтверждено) {
                        Редактировать2
                        Подтверждение действия
            } else END

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

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

Следующий шаг после успешного выделения рекурсивной модели — оценка сложности алгоритма. Именно на этом шаге дают о себе знать все отличительные особенности бизнес-процесса с человеческим участием: мы не можем определить точное количество рекурсивных вызовов, то есть, в нашем случае, количество раз, когда один из участников процесса отправляет заявку на кредит на шаг редактирования. Поскольку количество рекурсивных вызовов напрямую влияет на сложность алгоритма, данная особенность не позволяет точно ее вычислить. Тем не менее, представляется вполне возможной приближенная оценка: так как на приведенном мной в качестве примера бизнес-процессе основывается работоспособное приложение, можно собрать статистические данные по его работе, выделить среднее количество рекурсивных вызовов в каждом конкретном случае и оценить сложность алгоритма. Полученная таким способом информация послужит основой для поиска так называемых «узких мест» бизнес-процесса и его последующей оптимизации. Например, если деятельность одного из участников бизнес-процесса порождает большое количество рекурсивных вызовов, следует задуматься о квалификации участников процесса, которым назначена эта роль. Следует отметить, что описанная таким образом методика применима не только к оценке бизнес-процесса, состоящего исключительно из пользовательских действий, как описано в данной статье, но и к процессу, содержащему автоматические действия: включение автоматических действий в рассматриваемый процесс даст возможность сделать выводы об эффективности работы аппаратно-программных средств, выступающих в качестве платформы для BPM-приложения.

Возможность выделения рекурсивной модели уже неоднократно упоминалась в различных статьях, посвященных, в частности, проблемам декомпозиции[2] и исследованию управленческих процессов[3], а также в трудах, описывающих доступные на сегодняшний день технологии построения бизнес-бизнес процессов[4].

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