Методика преобразования модели бизнес-процесса с целью повышения ее прозрачности для пользователей Текст научной статьи по специальности «Экономика и бизнес»

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

The methodology of business process model improvement for the ease of understanding for users.

Визгунов Александр Николаевич,

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

Нижегородского филиала ГУ - ВШЭ, Визгунов Николай Павлович, кандидат экономических наук, доцент кафедры информационных технологий и инструментальных методов в экономике Института экономики и предпринимательства

ННГУ им. Н.И.Лобачевского, vizgunovhse @ yandex. ru

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

Annotation. The paper deals with problem of evaluation of complexity of business-process models for users. The opportunities of using of the cross-connectivity metric are analyzed. The methodology of business process model improvement for the ease of understanding for users, using this metric, is considered.

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

Key words: business process management, business process modeling, quality metrics, cross-connectivity metric.

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

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

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

3. Автоматизация бизнес-процессов.

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

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

- регистрация заявки, поступившей на бумажном носителе, и выполнение оценки лимита с помощью скоринговой системы,

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

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

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

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

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

- если уровень сложности модели высок, каким образом можно повысить прозрачность модели?

Проблеме оценки сложности понимания моделей бизнес-процессов уделяется в последние годы повышенное внимание. Так, в работах [1], [2], [3] высказывается идея о применимости метрик качества из области программной инженерии для оценки качества моделей бизнес-процессов. В работе [1] рассматриваются возможности применения для оценки качества модели бизнес-процессов следующих метрик качества ПО: связности или сцепления (cohesion), связанности с другими модулями (coupling), объема (size) и др. В работе [2] предлагается метрика взвешенной связности (weighted coupling metric), используемая для оценки силы связи между различными задачами, описанными в рамках модели бизнес-процесса.

Применительно к оценке сложности понимания модели бизнес-процесса наибольший интерес представляет показатель взаимной связности (ctoss-сonnectivity metric; далее - CCM), предложенный в работе [3]. Рассмотрим его подробнее.

При расчете показателя модель бизнес-процесса представляется в виде ориентированного графа, состоящего из множества вершин (n1, n2; .. е N) и множества дуг (a1, a2; .. е A). Вершина может быть одного из двух типов: процедура бизнес-процесса (t1, t2; .. е T) или логический оператор AND (И), OR (ИЛИ) или XOR (исключающее ИЛИ) (с1, с2; .. е C). Представление бизнес-процесса в виде графа позволяет проводить анализ процессов, изначально описанных в различных нотациях бизнес-моделирования -BPMN, ARIS (EPC-диаграммы) и др.

Рассмотрим основные показатели, используемые при расчете ССМ. Первый показатель - вес вершины w(n), рассчитываемый следующий образом:

w(n) = 1, если ne C и n - логический оператор AND,

w(n) = —, если ne C и n - логический оператор XOR,

d

1 2d - 2 1

w(n) = —— + —— * —, если ne C и n - логический оператор OR (ИЛИ), 2 1 2 1 d

w(n) = 1, если ne T,

где d - степень вершины (количество входящих и исходящих дуг).

Вес вершины связан с количеством вариантов, анализируемых при рассмотрении элемента модели бизнес-процесса. Наибольший вес имеет вершина, сопоставленная оператору AND, поскольку этот оператор предусматривает единственный вариант исполнения бизнес-процесса - тот, при котором задействованы все дуги. Меньший вес имеет вершина, сопоставленная оператору XOR - вес вершины тем меньше, чем большее количество дуг ей инцидентно (поскольку увеличение количества дуг увеличивает число возможных вариантов исполнения). Наконец, вес вершины, сопоставленной оператору OR, определяется следующим образом.

Количество возможных вариантов использования d дуг составляет 2d-1. Только один из этих вариантов (то есть 1 из 2d-1 вариантов) соответствует оператору AND - вариант, при котором задействованы все дуги. Этот вариант отражает первая часть формулы, используемой для определения веса

вершины, сопоставленной оператору OR: * *1, то есть доля вариантов,

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

2d - 2 1

оператору XOR, что определяет вторую часть формулы: ——- * —

(аналогично, доля вариантов, при которых задействованы не все дуги, умножается на вес вершины, сопоставленной оператору XOR.)

Следующий показатель - вес дуги - определяется по формуле: W(a) = w (source^^w (destination(a)), где w (source^)) - вес начальной вершины дуги a, w (destination(a)) - вес конечной вершины дуги a.

Следующий показатель - вес маршрута, рассчитываемый для последовательности направленных дуг p=<a1, a2, ... ax> от вершины n1 до вершины n2 следующим образом:

v(p) = W(ai) *W(a2) * ::: *W(ax).

Наконец, последний показатель - сила связи между вершинами, которая для вершин n1, n2 рассчитывается как максимальный из весов маршрутов, соединяющих эти вершины: V(n1, n2) = max v(p)

pe P (ni,n2)

, где P (n1,n2) - множество возможных маршрутов от вершины n1 до вершины П2.

Исходя из вышеприведенных определений, показатель CCM для модели бизнес-процесса рассчитывается следующим образом:

ZV (n1, n2)

n1 n2eN 4 1 2 /

CCM =

|N|*(|N|-1)

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

В то же время алгоритм расчета показателя CCM вызывает ряд вопросов. Во-первых, не все логические операторы, используемые в рамках различных нотаций, учтены при расчете данного показателя. Так, например, в рамках нотации BPMN используется сложный оператор (complex gateway), который имеет несколько условий, в зависимости от выполнения которых активируются исходящие дуги. Вопрос, каким образом рассчитывается CCM для моделей, построенных с учетом сложных операторов, остается открытым. Во-вторых, неочевидным представляется расчет веса вершины, сопоставленной оператору OR. Как уже было сказано, доля вариантов, при

( 2d - 2 Л

которых задействованы не все дуги (——-), умножается на вес вершины,

сопоставленной оператору XOR (—). Таким образом, при расчете

d

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

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

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

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

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

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

Проблему наличия принципиально различных сценариев в рамках одной модели бизнес-процесса можно решить путем разбиения модели бизнес-процесса на несколько, соответствующих отдельным основным сценариям. Эффективность такого подхода обоснована еще в работе М.Хаммера и Д. Чампи [4]. По мнению этих авторов, переход от единой универсальной модели бизнес-процесса к нескольким моделям, «приспособленным к требованиям разных рынков, ситуаций или исходных данных», является одним из ключевых элементов реинжиниринга бизнес-процессов.

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

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

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

Рассмотрим эти этапы подробнее.

1. Анализ наличия в рамках модели бизнес-процесса сценариев -

исключений.

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

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

-К- Хтах — хтт ,

где - - размах вариации; хтах - доля сценария бизнес-процесса, который выполнялся наиболее часто; хт1п - доля сценария бизнес-процесса, который выполнялся минимальное количество раз. Например, если из 100 вариантов выполнения бизнес-процесса сценарий Sl выполнялся 90 раз, сценарий S2 выполнялся 9 раз, а сценарий S3 выполнялся 1 раз, величина размаха вариации будет равна 0,89 (0,9 - 0,01). Таким образом, значение размаха вариации, близкое к единице, свидетельствует о том, что в рамках модели описан основной сценарий и, по меньшей мере, один сценарий - исключение.

Размах вариации отражает только крайние значения изучаемой совокупности; для более точного анализа наличия в рамках модели сценариев - исключений может использоваться коэффициент вариации:

V = - * 100%, где

а =

1

П г=1

1Е (X, - X)2

xi - доля 1-ого сценария бизнес-процесса в общем объеме вариантов выполнения,

т - количество сценариев,

х - среднее арифметическое долей сценариев.

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

- если частота выполнения различных сценариев в рамках модели процесса различается незначительно (низкое значение коэффициента вариации; совокупность показателей является однородной), то все сценарии в рамках модели можно рассматривать в качестве основных -все они выполняются с достаточно близкой частотой,

- если частота выполнения различных сценариев в рамках модели процесса различается существенно (высокое значение коэффициента вариации; совокупность показателей является неоднородной), то в рамках модели представлены как основные сценарии, так и сценарии-исключения.

В статистике совокупности, имеющие коэффициент вариации больше 30-35 %, принято считать неоднородными [5]. Это значение можно использовать в качестве порогового при определении того, к какому из двух перечисленных видов принадлежит модель бизнес-процесса.

В качестве примера рассмотрим две модели бизнес-процессов, в рамках каждой из которых описано 5 различных сценариев выполнения. Для анализа характера каждой модели используются данные о 50 наблюдениях. Данные о количестве (и доле в общем объеме) бизнес-процессов, выполненных по каждому сценарию, представлены в табл. 1:

Количество (доля в общем объеме) бизнес- Коэффициент

процессов, выполненных по каждому вариации

сценарию, описанному в рамках отдельной

модели

1 2 3 4 5

Модель процесса 1 14(0,28) 10 (0,2) 10 (0,2) 10 (0,2) 6 (0,12) 0,25

Модель процесса 2 25 (0,5) 2 (0,04) 15 (0,3) 3 (0,06) 5 (0,1) 0,83

Все сценарии в рамках модели бизнес-процесса 1 выполняются с достаточно близкой частотой, в ней отсутствуют сценарии - исключения. Этой ситуации соответствует низкое значение коэффициента вариации (0,25). Напротив, в рамках модели бизнес-процесса 2 присутствуют сценарии-исключения (сценарий 2 и сценарий 4). Этой ситуации соответствует высокое значение коэффициента вариации (0,83). Для подобной модели должны быть проведены работы по переносу сценариев процессов-исключений из общей модели в отдельные документы.

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

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

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

Определяются сценарии выполнения бизнес-процесса, реализуемые на практике. Каждый сценарий Si представляется в виде набора значений (у1, у2, ..., уп), где п - множество процедур, описанных в рамках модели; у -показатель выполнения процедуры ] в рамках сценария (у = 1, если процедура ] выполняется; у = 0, если процедура ] не выполняется). Например, в рамках модели описано 10 различных процедур. Тогда сценарий, в рамках которого выполняются только процедуры №2 и №3 описывается набором значений (0,1,1,0,0,0,0,0,0,0).

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

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

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

А ССМ = ССМ 1 - ССМо , где

ССМ 1 - среднее арифметическое ССМ моделей, полученных в результате преобразований, ССМ0 - ССМ исходной модели. Чем выше значение показателя, тем более эффективным было преобразование модели.

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

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

1. Vanderfeesten I., Cardoso J., Mendling J., Reijers H.A., Aalst W.M.P. van der. Quality Metrics for Business Process Models // L. Fischer, ed.: Workflow Handbook 2007, Workflow Management Coalition, Lighthouse Point, Florida, USA, 2007.

2. Vanderfeesten I., Cardoso J., Reijers H.A.. A Weighted Coupling Metric for Business Process Models // Johann Eder, Stein L. Tomassen, Andreas Opdahl, Guttorm Sindre, editor, Proceedings of the CAiSE 2007 Forum, volume 247 of CEUR Workshop Proceedings, Trondheim, Norway, June 2007.

3. Vanderfeesten, I.T.P., Reijers, H.A., Mendling, J., van der Aalst,W.M.P., Cardoso, J.: On a quest for good process models: The cross-connectivity metric // Bellahsene, Z., L'eonard, M., eds.: CAiSE. Volume 5074 of Lecture Notes in Computer Science, Springer, 2008.

4. Хаммер М., Чампи Д. Реинжиниринг корпорации. Манифест революции в бизнесе. М.: Манн, Иванов и Фербер, 2007.

5. Чернова Т.В. Экономическая статистика. Таганрог: Изд-во ТРТУ, 1999.