Номер части:
Журнал
ISSN: 2411-6467 (Print)
ISSN: 2413-9335 (Online)
Статьи, опубликованные в журнале, представляется читателям на условиях свободной лицензии CC BY-ND

ОБЗОР МЕТРИК ОЦЕНКИ СЛОЖНОСТИ БИЗНЕС-ПРОЦЕССОВ



Науки и перечень статей вошедших в журнал:
DOI:
Дата публикации статьи в журнале:
Название журнала: Евразийский Союз Ученых — публикация научных статей в ежемесячном научном журнале, Выпуск: , Том: , Страницы в выпуске: -
Данные для цитирования: . ОБЗОР МЕТРИК ОЦЕНКИ СЛОЖНОСТИ БИЗНЕС-ПРОЦЕССОВ // Евразийский Союз Ученых — публикация научных статей в ежемесячном научном журнале. Технические науки. ; ():-.

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

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

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

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

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

Также общие черты наблюдаются при моделировании обоих типов процесса.

Преимущества моделирования программного процесса:

— простота понимания алгоритма работы ПО,

— поддержка управления процессами разработки ПО,

— автоматизация процесса разработки ПО,

— поддержка усовершенствования процесса разработки ПО.

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

Цели моделирования бизнес-процессов:

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

— применение при разработке информационных систем, реализующих бизнес-процесс,

— улучшить текущую деловую структуру и работу,

— показать структуру обновленного бизнес-процесса,

— идентифицировать возможности аутсорсинга,

— упрощение деловых спецификаций с технической платформой.

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

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

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

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

При применении спецификации SPEM используется универсальная метамодель для описания процесса разработки программного обеспечения или семейства связанных процессов разработки программного обеспечения. Метамодель включает: Основные элементы, Зависимости, Структуру Процесса, Компоненты Процесса и Жизненный цикл Процесса. SPEM основывается на метамодели UML. При моделировании, как процесса программного обеспечения, так и модели бизнес-процесса необходимо применение графической нотации. В настоящее время применяются следующие инструменты моделирования бизнес-процессов: IDEF 0, IDEF 3, UML, UML и BPMN.

BPMN — новый стандарт для моделирования бизнес-процессов, предложенный Business Process Management Initiative (BPMI). BPMI объединяет в себе все разнообразие терминологии, связанных с моделированием бизнес-процессов посредством стандартной нотации BPMN, таким же образом как спецификация SPEM в области моделирования программного процесса.

BPMN обеспечивает графическую нотацию для построения бизнес-процессов в формате диаграмм Business Process Diagram (BPD), на основе составления блок-схем возможно создание графических моделей бизнес-процессов, что в свою очередь позволяет создать модели даже очень сложных бизнес-процессов. Другое важное преимущество BPMN — это то, что языки XML, разработанные для бизнес-процессов, такие как BPEL и BPML, могут быть выражены визуально в общей нотации [3].

Первая цель BPMN состоит в том, чтобы обеспечить нотацию, которая может быть понятна всем бизнес-пользователям от бизнес-аналитиков до технических разработчиков. Чтобы достигнуть это BPMN упрощает моделирование высокоуровневого бизнес-процесса через BPD, который включает две основные категории: первая содержит базовые элементы, с помощью которых возможно разработать простые модели процессов; вторая содержит полный список элементов, которые позволяют создавать сложные модели бизнес-процессов [2].

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

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

Для оценки программного процесса FMESP включает ряд метрик. Метрики измеряют структурную сложность моделей программного процесса. Цель состоит в том, чтобы оценить влияние структурной сложности моделей программного процесса на их пригодности для обслуживания. Метрики FMESP были определены в двух различных объемах: в первую очередь, образцовом объеме, чтобы оценить полную структурную сложность модели; во-вторых, базовый объем элемента, чтобы оценить определенную сложность фундаментальных элементов модели, а именно, Действия, Роли и Продукты работы. Метрики объема приведены в Таблице 1.

Таблица 1.

Метрики процесса

Метрики

Значение

Формула

NA Количество действий модели БП
NWP Количество рабочих процессов
NPR Количество ролей, использованных в процессе
NDWPIn Количество входных зависимостей в рабочих процессах с действиями
NDWPOut Количество выходных зависимостей в рабочих процессах с действиями
NDWP Количество зависимостей, между рабочим процессом и действием NDWPIn+NDWPOut
NDA Количество прецедентов между действиями
NCA Связь действий в модели NA/NDA
RDQPIn Соотношение между входными зависимостями в рабочих процессах к общему количеству действий NDWPIn/NDWP
RDWPOut Соотношение между выходными зависимостями в рабочих процессах к общему количеству действий NWP/NA
RWPA Среднее между рабочими процессами и действиями NWP/NA
RRPA Соотношение рабочих ролей и действий. NPR/NA

Метрики FMESP были определены, на основании анализа метамодели SPEM и сгруппированы в основные метрики, которые были получены, после подсчета числа значительных конструкторов метамодели SPEM и их отношений, и полученные метрики, которые получены в результате расчетов. Пример модели программного процесса, представленной с использованием  SPEM с вычислением метрик объема приведен на рисунке 1.

Рисунок 1.  Модель программного процесса с расчетом основных метрик

При оценке сложности бизнес-процессов стоит рассмотреть также метрику CFC (Control-flow complexity of processes) – отражающую количество состояний процесса. Данная метрика отражает число возможных решений при управлении процессом. При моделировании процессов каждое новое решение добавляется с помощью соединителей:

— И — разделение: данный соединитель в модели добавляет 1 к метрике CFC этой модели.

— XOR — разделение с n переходами: один от n возможных решений должен быть отработан. Поэтому каждое XOR-разделение с n коммуникабельными переходами добавляет n к метрике CFC этой модели.

— ИЛИ — разделение с n коммуникабельными переходами: есть 2n-1 возможности обработать по крайней мере одно решение и в большей части n коммуникабельных переходов ИЛИ — разделении, т.е. каждый ИЛИ — разделение с n коммуникабельными переходами добавляет 2n — 1 к метрике CFC.

На рисунках 2-4 приведены разные реализации процессов с CFC=8.

Как видно из схем, в обоих случаях значение метрики CFC = 8, но при этом первый вариант более прост для восприятия и структурирован. В связи с этим в дополнение к метрике CFC используют другие метрики, отражающие меру структурированности модели процесса.

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

Применительно к примерам на рисунках 2-4, в первом случае глубина вложенности равна 1, во втором случае 3. Данная метрика является дополнением к метрике CFC. Ряд факторов ограничивает применение метрик оценки сложности программного обеспечения для оценки сложности бизнес-процессов, но привязка данных метрик к оценке сложности бизнес-процессов возможна. Данные метрики позволяют оценить эффективность моделирования процесса, выявить ошибки моделирования, а также оценить эффективность декомпозиции модели.

Список литературы:

  1. Cardoso J., «How to measure the control-flow complexity of web processes and workflows» in The Workflow Handbook, pp. 199–212, 2005.
  2. Cardoso J., Mendling J., Neumann G., and Reijers H., «A discourse on complexity of process models» in Proceedings of the BPM 2006 Workshops, Workshop on Business Process Design BPI 2006, Vienna, Austria, 2006.
  3. Rol´on E., Ruiz F., Garc´ıa F., and Piattini M., «Towards a suite of metrics for business process models in BPMN» in 8th International Conference on Enterprise Information Systems, Paphos, Cyprus, 2006.[schema type=»book» name=»ОБЗОР МЕТРИК ОЦЕНКИ СЛОЖНОСТИ БИЗНЕС-ПРОЦЕССОВ» author=»Петрова Марина Александровна» publisher=»басаранович екатерина» pubdate=»2017-06-17″ edition=»ЕВРАЗИЙСКИЙ СОЮЗ УЧЕНЫХ_ 30.12.2014_12(09)» ebook=»yes» ]
Список литературы:


Записи созданы 9819

Похожие записи

Начните вводить, то что вы ищите выше и нажмите кнопку Enter для поиска. Нажмите кнопку ESC для отмены.

Вернуться наверх
404: Not Found404: Not Found