Библиографический список - LMS
advertisement
ПРАВИТЕЛЬСТВО РОССИЙСКОЙ ФЕДЕРАЦИИ Федеральное государственное автономное образовательное учреждение высшего профессионального образования "Национальный исследовательский университет "Высшая школа экономики" Пермский филиал Факультет бизнес-информатики Кафедра информационных технологий в бизнесе УДК 004.4'2 + 338.3 Моделирование и анализ бизнес-процессов нефтеперерабатывающего холдинга с использованием языкового инструментария Выпускная квалификационная работа бакалавра Работу выполнил студент группы БИ-11-1 4 курса факультета бизнес-информатики Р.Р. Айзатуллова Научный руководитель: к. ф.-м. н., доцент, доцент кафедры информационных технологий в бизнесе Л.Н. Лядова “_____” Пермь 2015 20__ г. Оглавление Введение .................................................................................................................. 4 Глава 1. Анализ деятельности холдинга ............................................................ 8 Глава 2. Обзор подходов к моделированию и анализу бизнес-процессов ... 20 2.1 Функционально-ориентированный подход ............................................... 23 2.1.1 Методология ARIS ............................................................................ 24 2.1.2 Методология IDEF ............................................................................ 31 2.2 Объектно-ориентированный подход ......................................................... 36 2.3 Выводы.......................................................... Error! Bookmark not defined. 2.4 Имитационное моделирование бизнес-процессов ................................... 42 2.4.1 Система GPSS World......................................................................... 44 2.4.2 Модуль ARIS Business Simulator ..................................................... 48 2.4.3 Система AnyLogic ............................................................................. 51 2.4.4 Выводы ............................................... Error! Bookmark not defined. Глава 3. Разработка метамоделей языков описания бизнес-процессов ........ 59 3.1 Метамодель языка ARIS VAD .................................................................... 61 3.2 Метамодель языка ARIS eEPC ................................................................... 63 3.3 Метамодель IDEF0....................................................................................... 67 3.4 Метамодель UML Activity Diagram ........................................................... 68 3.5 Метамодель AnyLogic ................................................................................. 70 Глава 4. Трансформация моделей..................................................................... 71 4.1 Трансформация ARIS-ARIS ........................................................................ 74 4.2 Трансформация ARIS-AnyLogic ................................................................. 78 4.3 Трансформация UML-ARIS ........................................................................ 81 4.4 Трансформация ARIS-IDEF0 ...................................................................... 83 4.5 Выводы.......................................................................................................... 88 Заключение ............................................................................................................ 92 Библиографический список ................................................................................. 94 Приложение A. Моделирование бизнес-процессов холдинга «Как есть» ... 98 Приложение B. Обзор средств моделирования и анализа БП ..................... 100 Приложение C. Описание языков имитационного моделирования ............ 104 2 Приложение D. Правила трансформации моделей ....................................... 106 Приложение E. Исходные модели бизнес-процессов................................... 111 3 Введение Такому крупному предприятию как нефтеперерабатывающий холдинг необходимо постоянно результативности, заниматься эффективности реализацией и решений адаптивности по процессов. повышению Для этого руководство должно обладать информацией о работе своего предприятия. В связи с этим разрабатываются модели бизнес-процессов «Как есть», которые в дальнейшем позволяют провести всесторонний анализ деятельности предприятия. Моделированием бизнес-процессов могут заниматься бизнес-аналитики рассматриваемого холдинга, используя специализированную платформу ARIS Design Platform, разрабатывая модели в нотациях ARIS VAD и ARIS eEPC. Однако часть бизнес-процессов для построения моделей передается подрядным организациям, которые работают в практически тех же нотациях, используя графический редактор Microsoft Visio. Фактически приходится заново разрабатывать полученные модели, но в нотации, которая используется именно в ARIS Design Platform. Данный процесс является достаточно трудоемким, поэтому встает задача его оптимизации. Следующая стадия связана с анализом бизнес-процессов с помощью имитационного моделирования. Несмотря на то, что ARIS Platform содержит модуль ARIS Business Simulator, для некоторых задач бизнес-аналитику не достаточно использовать только его, а требуется задействовать более мощный инструмент. Сравнительный анализ систем имитационного моделирования (см. таблицу 2.4) показал, что система AnyLogic является самым функциональным инструментом в данной области. Для этого бизнес-аналитику приходится на основе моделей ARIS eEPC разрабатывать имитационную модель AnyLogic. На её разработку бизнес-аналитик может потратить большое количество времени, поэтому задача экономии времени моделирования является достаточно актуальной. Меры, направленные на совершенствование бизнес-процессов, также включают автоматизацию некоторых процессов за счет внедрения информационной системы (ИС). На начальных этапах жизненного цикла ИС необходимо тесное взаимодействие разработчиков и основных участников бизнеспроцесса. Разработчики предпочитают работать с объектно-ориентированными 4 моделями, описанными с помощью UML диаграмм в Microsoft Visio, сотрудники холдинга лучше понимают, модели в нотациях ARIS VAD и ARIS eEPC, поэтому бизнес-аналитик вынужден на основе UML моделей разрабатывать модели в привычных для сотрудников нотациях. Как и в предыдущем случае, возникает проблема снижения трудоемкости данного процесса. Следующая задача связана с сертификацией по стандартам, описывающим требования к системе управления качеством. По рекомендациям [28] для моделирования бизнес-процессов может быть использована нотация IDEF0. В этом случае бизнес-аналитику необходимо разработать модели бизнес-процессов в нотации IDEF0 на основе моделей в нотации ARIS VAD и ARIS eEPC. Так как такие процессы могут быть достаточно сложными, бизнес-аналитик может потратить очень много времени на их разработку. Вышеперечисленные проблемы связаны с большой трудоемкостью работы бизнес-аналитика, и могут быть решены посредством автоматической трансформации моделей одной нотации в другую. Трансформация моделей позволит бизнес-аналитику существенно сэкономить время моделирования за счет переиспользования уже имеющихся моделей. Подходящим средством для реализации такого подхода является инструментарий для создания предметноориентированных языков – DSM-платформа. Однако появляется проблема экспорта созданных бизнес-аналитиком моделей во внешние системы, такие как ARIS Design Platform и AnyLogic, которые используют язык моделирования, отличающийся от разработанного предметноориентированного языка. В этом случае необходимо предварительно выполнить преобразование моделей. Сразу отметим, что в данной работе не рассматривается решение такой задачи, исследование направлено на изучение нотаций для последующей разработки правил трансформации моделей одной нотации в другую. Трансформация моделей – одна из основных идей концепции MDA, основанной на модельно-ориентированного подходе к разработке программного обеспечения. Его суть состоит в построении абстрактной метамодели управления и обмена метаданными (моделями) и задании способов ее трансформации в поддерживаемые технологии программирования (Java, CORBA, XML и др.) [29]. 5 В работе [7] рассматриваются подходы к описанию трансформаций моделей с использованием DSM-платформы. Вопросы, связанные с методами трансформации визуальных моделей подробно освещены в работе [6]. Автор работы замечает, что графовые грамматики могут использоваться для трансформации моделей с одного языка моделирования в другой. Развивая данную тему, авторы работы [8] подробно рассматривают метод трансформации моделей на основе графовых грамматик и предлагают подход к реализации инструментального средства для создания языков описания трансформаций визуальных моделей. Однако данные работы не затрагивают типовых задач моделирования, которые могут решаться с помощью трансформаций моделей. В работе [9] рассматривается моделирование бизнес-процессов с использованием ARIS eEPC, а также агентные имитационные модели AnyLogic, предлагая метод трансляции модели в нотации eEPC в агентную имитационную модель AnyLogic, при этом пользователь не может использовать любые другие нотации. Фактически в распоряжении бизнес-аналитика имеется фиксированный набор нотаций без возможности его расширения. DSM-платформа MetaLanguage помогает решить вышеперечисленные проблемы, предоставляя возможность создания моделей бизнес-процессов в различных нотациях, необходимых бизнес-аналитику холдинга, что позволит ему расширить их набор, а также осуществлять трансформации из одной нотации в другую. Объектом исследования является процесс моделирования бизнес-процессов холдинга, а предметом – методы и средства моделирования и анализа бизнеспроцессов. Целью работы является разработать подход к снижению трудоемкости работы бизнес-аналитика холдинга при построении моделей в разных нотациях для решения определенных задач за счет переиспользования моделей с помощью DSMплатформы. Для достижения данной цели следует решить ряд задач: 1) проанализировать деятельность холдинга для того чтобы: a) определить задачи, при решении моделирование бизнес-процессов; 6 которых применяется b) оценить трудоемкость данного процесса; c) разработать подход, позволяющий снизить трудоемкость разработки моделей; 2) рассмотреть подходы и языки моделирования и анализа бизнеспроцессов, с помощью которых решаются определенные задачи холдинга; 3) разработать метамодели языков описания бизнес-процессов с помощью DSM-платформы в соответствии с обозначенными задачами; 4) разработать, реализовать правила трансформации моделей из одной нотации в другую с точки зрения задач холдинга, а также проанализировать полученные результаты. Рассмотрим методы и инструменты, применяемые в исследовании. Трудоемкость процесса разработки моделей бизнес-процессов оценивается с помощью экспертного метода. При изучении предметной области используются методы структурного анализа. Функционально-ориентированный и объектноориентированный подходы изучаются в части моделирования бизнес-процессов. Модели бизнес-процессов разрабатываются с помощью предметно- ориентированных языков при использовании DSM-платформы MetaLanguage. Данная платформа позволяет реализовывать трансформации моделей из одной нотации в другую на основе методов теории графов, а именно графовых грамматик. Научной новизной обладают следующие результаты исследования: 1) подход, позволяющий снизить трудоемкость работы бизнес-аналитика при моделировании бизнес-процессов, основанный на переиспользовании уже разработанных моделей с помощью DSM-платформы; 2) правила трансформации моделей из нотаций, которые используются подрядчиками холдинга, в ARIS VAD и ARIS eEPC, из UML Activity Diagram в ARIS eEPC, а также из нотации ARIS eEPC в нотацию IDEF0 и имитационную модель AnyLogic. 7 Глава 1. Анализ деятельности холдинга Задачами данной главы являются: 1) определить, для каких задач холдинга применяется моделирование бизнес-процессов; 2) описать процесс работы сотрудников холдинга и подрядных организаций при моделировании бизнес-процессов, для того чтобы оценить трудоемкость данного процесса; 3) описать подход к моделированию и анализу бизнес-процессов, позволяющий снизить трудоемкость работы бизнес-аналитика; 4) проанализировать и выбрать бизнес-процессы холдинга, на примере которых предлагается рассмотреть описанный подход. 1.1 Организация процесса моделирования бизнес-процессов «Как есть» Моделирование бизнес-процессов может быть применено для некоторых задач, стоящих перед холдингом. Для решения той или иной задачи могут быть использованы определенные нотации и инструментальные средства. Рассмотрим подробнее эти задачи. 1.1.1 Формализация бизнес-процессов холдинга В настоящее время центр организационного развития холдинга занимается формализацией бизнес-процессов, которые впоследствии должны быть подвержены изменениям. Рассмотрим подробнее организационную структуру центра (см. рис.1.1). Департамент управления персоналом и организационного развития Вице-президент по управлению персоналом и организационному развитию Центр организационного развития Бизнес-архитектор Архитектор системы оперативного управления Консультант по организационному развитию Бизнес-аналитик Рисунок 1.1 Организационная структура центра организационного развития холдинга 8 Рассмотрим матрицу ответственности за моделирование бизнес-процессов (см. таблицу 1.1). Функция Таблица 1.1 Матрица ответственности сотрудников центра организационного развития Архитектор системы Должность Бизнес-аналитик оперативного Бизнес-архитектор управления (СОУ) Самостоятельная разработка моделей бизнес-процессов Предварительная Итоговая проверка и проверка проекта утверждение проекта Отрисовка моделей, моделей моделей разработанных подрядчиком в ARIS Design Platform Проверка проекта Разработка замечаний и Разработка замечаний и моделей, разработанных рекомендаций по проекту рекомендаций по подрядчиком моделей проекту моделей Бизнес-аналитик холдинга может сам разрабатывать модели бизнеспроцессов, основываясь на нормативно-методологической документации, с помощью системы ARIS Design Platform. Бизнес-процессы верхнего уровня должны описываться в нотации ARIS VAD, нотация ARIS eEPC row display служит для более детального моделирования бизнес-процессов. Часть бизнес-процессов передается подрядной организации, которая на основании регламентов разрабатывает модели бизнес-процессов с помощью графического редактора Microsoft Visio, фактически используя те же нотации ARIS VAD и ARIS eEPC. Однако разница между нотацией, в которой работает бизнес-аналитик холдинга и нотацией, которую использует консультант подрядной организации, все же есть. После того как консультант подрядной организации разработал модели бизнес-процессов, они передаются бизнес-аналитикам на проверку. В результате проверки бизнес-аналитик формирует перечень замечаний по моделям, который передается обратно консультанту. В этом случае консультант дорабатывает модели. После того как бизнес-аналитик согласовал модели, они передаются архитектору системы оперативного управления на проверку. После проверки могут быть сформированы замечания, которые должны быть также исправлены консультантами подрядной организации. Когда архитектор системы оперативного управления согласовывает модели, они передаются бизнес-архитектору для итоговой верификации. Бизнес-архитектор может не утвердить модели и отправить их обратно консультанту на доработку. В случае утверждения моделей бизнес9 архитектором, бизнес-аналитик должен разработать на основе утвержденных моделей в Visio модели в ARIS Design Platform. Экспертным методом оценим временные затраты на ручную перерисовку моделей бизнес-процессов одним бизнес-аналитиком в ARIS Design Platform (см. таблицу 1.2). Элемент ARIS Таблица 1.2 Экспертная оценка времени моделирования Время на БизнесБизнесБизнесразработку 1-го процесс A процесс B процесс C элемента (мин.) 1,5 68 80 15 1 22 14 3 1 18 46 9 Функция/Интерфейс Роль/Группа Оператор 1,5 Событие 1 ИС Информационный 1,5 объект Общее количество элементов Общее время на моделирование всего бизнес-процесса 25 5 57 5 21 0 41 50 2 179 252 50 4:06:00 5:45:00 1:09:00 Из таблицы видно, что в среднем на разработку большого процесса может уходить от 4 до 6 часов, и больше, если процесс еще сложнее. Поэтому задача снижения трудоемкости работы бизнес-аналитика становится очень актуальной. 1.1.2 Анализ моделей бизнес-процессов Далее на основе моделей «Как есть» разрабатываются имитационные модели для анализа. ARIS Platform содержит модуль имитационного моделирования ARIS Business Simulator, но для некоторых задач бизнеса бизнес-аналитику требуется задействовать более мощный инструмент. По результатам сравнительного анализа систем имитационного моделирования (см. таблицу 2.4) выяснилось, что система AnyLogic является более функциональным инструментом и обеспечивает высокий уровень поддержки принятий решений по сравнению с ARIS Business Simulator. Для этого бизнес-аналитику приходится заново разрабатывать имитационную модель AnyLogic. Рассмотрим основные фазы моделирования и анализа бизнес-процессов холдинга, а также детальное описание первой фазы процесса (см. Приложение A). Описание процесса отрисовки моделей подрядчиков в ARIS Design Platform «Как есть» представлено на рисунке 1.2. 10 11 Рисунок 1.2 Процесс отрисовки моделей в ARIS Design Platform «Как есть» 1.1.3 Автоматизация бизнес-процессов Другая задача связана с автоматизацией некоторых бизнес-процессов за счет внедрения информационной системы. Холдинг сотрудничает с подрядной организацией, которая занимается разработкой и внедрением информационных систем. Модели бизнес-процессов строятся на основе нормативной документации, результатах интервью непосредственных исполнителей процессов, а также уже разработанных в прошлом моделей. Бизнес-аналитикам холдинга и разработчикам необходимо совместно обсуждать проектируемую систему для описания её функциональности и поведения. Разработчики для описания бизнес-процессов применяют UML ориентированные диаграммы, разрабатывая модели с помощью графического редактора Microsoft Visio. С целью проверки корректности моделей бизнесаналитики холдинга обсуждают их с менеджером проекта и основными участниками бизнес-процесса, которые привыкли работать только с моделями в нотации ARIS eEPC, поэтому бизнес-аналитику холдинга приходится заново разрабатывать модели в привычной для сотрудников нотации. 1.1.4 Сертификация по стандартам качества Для получения холдингом статуса организации, удовлетворяющей ISO 9000 и ISO 9001 (стандарты, описывающие требования к системе управления качеством) холдингу необходимо следовать рекомендациям по методике менеджмента процессов в системе качества. Согласно таким рекомендациям [28] в качестве метода схематического изображения процесса может быть выбрана нотация IDEF0. В этом случае бизнес-аналитики должны разработать на основе моделей ARIS VAD и ARIS eEPC модели в нотации IDEF0. 1.2 Организация процесса моделирования бизнес-процессов «Как будет» Проблема заключается в том, что бизнес-аналитикам холдинга приходится вручную разрабатывать модели ARIS VAD и ARIS eEPC на основе полученных моделей от подрядчиков, а также модели в нотации IDEF0 и AnyLogic на основе моделей ARIS eEPC. В данной работе предлагается рассмотреть следующий подход, позволяющий снизить трудоемкость работы бизнес-аналитика при моделировании (см. рис. 1.3). 12 13 Рисунок 1.3 Часть 1 Процесс отрисовки моделей в ARIS Design Platform «Как будет» 14 Рисунок 1.3 Часть 2 Процесс отрисовки моделей в ARIS Design Platform «Как будет» Согласно вышеописанной диаграмме, рассмотрим следующие этапы предложенного подхода: 1. После того как подрядчики разработали модели и они были утверждены бизнес-архитектором, бизнес-аналитик холдинга импортирует их из Microsoft Visio в DSM-платформу, при этом сохраняет модель и вводит метаданные о ней. 2. Далее бизнес-аналитик осуществляет трансформацию полученных моделей в модели нотаций ARIS VAD и ARIS eEPC, соответствующие нотациям, которые используются в ARIS Design Platform. Трансформация должны осуществляться по определенным правилам, которые разрабатываются один раз, а затем могут применяться многократно. 3. Так как формальные модели должны находиться в системе ARIS Design Platform, то соответствующие модели экспортируются в систему ARIS Design Platform, при этом осуществляется преобразование модели к формату, используемому системой ARIS Design Platform. 4. На основе некоторых моделей, полученных на шаге 2, необходимо построить имитационные модели для построения моделей «Как будет». С этой целью используется система AnyLogic, однако сначала необходимо реализовать трансформацию модели ARIS eEPC в модель AnyLogic с помощью DSM-платформы по определенным правилам. 5. После того экспортировать как в модель AnyLogic определенном получена, формате во её необходимо внешнюю систему имитационного моделирования AnyLogic для осуществления анализа. 6. Основываясь на результатах проведения имитационного анализа, бизнесаналитик может исправить модель, тем самым получить модель «Как будет». Такая модель должна быть помещена в систему ARIS Design Platform. Теперь рассмотрим ситуацию, связанную с сертификацией по стандартам ISO 9000 и ISO 9001. Определим основные этапы: 1. Модели некоторых бизнес-процессов в нотации ARIS eEPC должны быть импортированы из Microsoft Visio в DSM-платформу MetaLanguage. 15 2. Необходимо осуществить трансформацию моделей в нотации ARIS eEPC в модели IDEF0. Сразу хочется отметить, что на этапах, когда осуществляется трансформация моделей, возможны потери, связанные с тем, что нотации отличаются друг от друга назначением, выразительной мощностью, а также семантикой и синтаксисом. В этом случае модель должна быть доопределена бизнес-аналитиком вручную. В данной работе не рассматривается решение задач, связанных с импортом моделей из внешних систем, а также их экспортом во внешние системы. Исследование фокусируется на изучении нотаций для последующей разработки правил трансформации моделей одной нотации в другую. Следующий вопрос связан с выбором инструментария, позволяющего разрабатывать модели и реализовывать их трансформацию из одной нотации в другую. Ключевыми требованиями для принятия решения в пользу того или иного инструментария являются: 1) возможность создания моделей в нотациях ARIS VAD, ARIS eEPC, IDEF0, UML Activity Diagram; 2) возможность создания моделей AnyLogic; 3) возможность трансформации моделей из одной нотации в другую. На основании обзора (см. приложение B, таблицы B.1) выяснилось, что современные средства моделирования и анализа бизнес-процессов становятся все более универсальными и многоцелевыми, например, нет четкой границы между CASE средствами и специальными программами моделирования и анализа бизнеспроцессов. Также во многие средства разработки моделей бизнес-процессов. Однако изученные системы не отвечают все поставленным требованиям. Как показал обзор (см. приложение B, таблицы B.1-B.2), DSM платформа MetaLanguage позволяет разрабатывать предметно-ориентированные языки, а также поддерживает визуальную трансформацию моделей из одной графической нотации в другую. Поэтому именно эта платформа выбрана в качестве инструмента для дальнейшей работы. 16 1.3 Выбор бизнес-процессов для исследования Для дальнейшего исследования необходимо выбрать бизнес-процессы, на которых бы хорошо демонстрировались обозначенные проблемы. С этой целью определим следующие требования к бизнес-процессам: 1) бизнес-процесс должен относиться к таким бизнес-процесса холдинга, который передается подрядным организациям для его формализации; 2) в бизнес-процессе должны выделяться его основные стадии (фазы); 3) бизнес-процесс должен представлять собой логически выстроенную событийно-функциональную цепочку; 4) функции бизнес-процесса должны иметь исходные данные и результаты, которые передаются в последующие функции, образуя тем самым информационный поток; 5) среди выбранных бизнес-процессов должен быть такой, который планируется автоматизировать с помощью информационной системы; 6) среди выбранных бизнес-процессов должен быть процесс системы массового обслуживания. В настоящий момент в холдинге выделено 13 основных процессов, которые можно отнести к четырем функциональным областям: недроиспользование, управление эксплуатацией объектов, управление промышленной и экологической безопасностью и управление коммерческими и деловыми услугами. В основном, бизнес-процессы холдинга представлены в виде четырехуровневой иерархии. На самом нижнем уровне находятся бизнес-процессы, которые задокументированы в положениях. В таких положениях процесс формализован вербально, описаны основные стадии, функции и роли. В положении может быть указана цель бизнеспроцесса, а также его привязка к бизнес-процессам верхнего уровня. В результате проведения анализа регламентов были выбраны следующие бизнес-процессы: управление интегрированное моделирование изменениями Активов по холдинга, проектам а также холдинга, техническая поддержка сотрудников холдинга. Управление изменениями по проекту является типичным процессом, представляющимся событийно-функциональной 17 цепочкой с разбивкой на основные фазы процесса. В данном процессе хорошо прослеживаются логика процесса, основные функции, их исполнители, а также информационные и материальные потоки. В рамках данного процесса изучим регламент «Методика управления изменениями по проекту». Управление изменениями производится в течение всего срока работы над проектом и связано с тем, что проект очень редко идет в полном соответствии с намеченным планом. Заказчики хотят внести изменения в содержание, возникают и исчезают риски, изменяется законодательство, по ходу выполнения проекта изменяется общее представление о проекте у его участников, обнаруживаются ошибки планирования, которые необходимо исправить, одни люди уходят из проекта и другие приходят на их место. Все это приводит к изменениям в проекте. Управление изменениями - это совокупность заранее оговоренных процедур и правил, в соответствии с которыми изменения вносятся в проект. Важно отметить, что любое изменение, прежде чем оно будет внесено в план проекта, вначале рассматривается лицами, имеющими соответствующие полномочия, которые ответственны за внесение изменений. После рассмотрения изменение либо принимается, либо отвергается (или откладывается до выяснения обстоятельств). На примере процесса интегрированного моделирования хорошо демонстрируется разработка функциональных требований к информационной системе. В настоящее время сотрудники холдинга работают в данном направлении, так как информационная система, задействованная в этом процессе, требует совершенствования или полной замены. В рамках данного процесса изучим регламент «Интегрированное моделирование активов холдинга». Сам процесс направлен на моделирование производственной деятельности нефтегазового актива. Интегрированная модель состоит из моделей компонентов объектов разработки месторождений, инфраструктуры, а также ограничений производства. Все компоненты связаны между собой единым программным средством. Интегрированное моделирование нацелено на достижение максимального понимания производственных процессов, выявление проблемных областей, ведущих к снижению эффективности производства. Технологическая поддержка, а именно обработка заявок пользователей холдинга, является процессом системы массового обслуживания, который хорошо 18 поддается имитационному анализу. Регламент «Обработка заявок сотрудников холдинга» описывает процесс предоставления помощи пользователям информационных продуктов. 1.4 Выводы по главе На основании вышеизложенной информации можно заключить: 1) перед холдингом ставятся следующие задачи, для решения которых может быть применено моделирование бизнес-процессов: a) построение моделей бизнес-процессов «Как есть» для их последующего анализа, с целью разработки моделей «Как должно быть»; b) построение моделей бизнес-процессов для разработки функциональных требований к автоматизирующей системе; c) построение моделей бизнес-процессов для сертификации по стандартам ISO 9000 и ISO 9001; 2) с задачей моделирования связана проблема большой трудоемкости работы бизнес-аналитика, который заново разрабатывает модели в необходимых нотациях; 3) предлагается рассмотреть подход, основанный на трансформации моделей с помощью DSM-платформы MetaLanguage, который позволит решить соответствующую проблему; 4) исследуются такие бизнес-процессы как управление изменениями по проектам холдинга, интегрированное моделирование Активов холдинга, а также техническая поддержка сотрудников холдинга. 19 Глава 2. Обзор подходов к моделированию и анализу бизнес-процессов Для реализации ряда мероприятий, направленных на совершенствование бизнес-процессов, необходимо обладать знаниями о том, как работает холдинг. Поэтому начальная стадия моделирования бизнес-процессов связана с построением его формальной модели. Построение такой модели может основываться на функционально-ориентированном или объектно-ориентированном подходах, которые рассматриваются в параграфах 2.2-2.4. После того как формальная модель разработана, переходят ко второму этапу – анализу бизнес-процессов. Для анализа бизнес-процессов может применяться имитационное моделирование, которое рассматривается в параграфе 2.5. Таким образом, цель данной главы – исследовать подходы к построению формальной модели организации и анализу её бизнес-процессов. В данной главе: 1) объясняются основные понятия, которые используются в процессе исследования; 2) рассматриваются функционально-ориентированный ориентированный подходы к разработке и объектно- формальной модели организации; 3) рассматривается применение имитационного моделирования для проведения анализа бизнес-процессов; 4) выделены и изучены методологии и языки моделирования и анализа бизнес-процессов в рамках каждого из перечисленных подходов. 2.1 Понятийный аппарат Прежде чем перейти к исследованию подходов и методологий моделирования бизнес-процессов, необходимо дать определения основным понятиям, которыми будем оперировать в ходе исследования. Под моделированием будем понимать следующее. Во-первых, это построение модели как некоего представления (образа) оригинала, отражающего наиболее важные его черты и свойства. Если же модель уже построена, то моделирование – процесс исследования (анализа) функционирования системы, вернее, её модели. 20 Моделью бизнес-процесса называется его формализованное (графическое, табличное, текстовое, символьное) описание, отражающее реально существующую или предполагаемую деятельность предприятия [1]. Наиболее удобно для восприятия и анализа, естественно, графическое представление, которое и будет рассматриваться в данной работе. Под подходом к моделированию понимается совокупность теоретических и практических инструментов и методов, направленных на моделирование бизнеспроцессов. Следующее понятие – это методология моделирования, включающая в себя последовательность действий, которые необходимо выполнить для построения модели (процедуру моделирования), и применяемую нотацию (язык) [1]. Язык моделирования бизнес процессов – нотация для описания моделей. Нотация представляет собой совокупность графических объектов, используемых в модели. Нотация определяет синтаксис языка моделирования [2]. Наконец, дадим определения следующим понятиям, которые понадобятся при исследовании данного вопроса [2]: 1) операция – элементарное действие, выполняемое на одном рабочем месте; 2) функция – совокупность операций, сгруппированных по одному признаку; 3) бизнес-процесс – связанная совокупность функций, в ходе выполнения которой потребляются определенные ресурсы, и создается продукт (предмет, услуга, научное открытие, идея), представляющий ценность для потребителя. Для полного описания деятельности холдинга, необходимо построить различные модели предметной области с точки зрения следующих аспектов моделирования: 1) модель организационной структуры; 2) функциональная модель; 3) модель бизнес-процессов; 4) модель данных. Данные аспекты моделирования всегда представлены в большинстве методологий в том или ином виде [3]. Рассмотрим выделенные аспекты подробнее (см. таблицу 2.1). 21 Таблица 2.1 Характеристика аспектов моделирования Описание Аспект моделирования Совокупность организационных единиц, связанных иерархическими и процессными отношениями. Организационная единица - это подразделение, представляющее собой объединение людей (персонала) для выполнения совокупности общих функций или бизнес-процессов Последовательность взаимосвязанных по входам и выходам функций составляет бизнес-процесс. Функция бизнес-процесса может порождать объекты любой природы (материальные, денежные, информационные) В совокупности функций бизнес-процесса возможны альтернативные или циклические последовательности в зависимости от различных условий протекания процесса. События, вызываемые взаимодействием предприятия с внешней средой, инициируют выполнение функций, которые, формируют новые события, пока не будет завершен некоторый бизнес-процесс Совокупность материальных объектов и основных видов информационных объектов или документов, которые используется при выполнении некоторой функции или операции Модель организационной структуры Функциональная модель Модель бизнес-процессов Модель данных На начальном этапе моделирования необходимо ответить на следующий вопрос: «Кто что делает и в какой последовательности?». Построение вышеперечисленных моделей помогает ответить на данный вопрос [3]. Однако, исходя из задач холдинга, данное исследование фокусируется на построении и анализе функциональных моделей и моделей бизнес-процессов. С точки зрения задач холдинга важно рассмотреть еще одну классификацию моделей в зависимости от временного фактора: 1) статистические модели, которые не учитывают фактор времени, с их помощью бизнес-аналитики холдинга выделяют основные фазы процессы; 2) поведенческие модели помогают бизнес-аналитикам определить, когда и/или при каких условиях выполняются бизнес-функции, с помощью таких категорий, как состояние системы, событие, переход из одного состояния в другое, условия перехода, последовательность событий [1]. Далее необходимо определить уровни детализации бизнес-процессов, так как от этого зависит выбор нотации для их моделирования: 1) процессы первого уровня: бизнес-процессы, которые реализуют услуги и продукты организации; 22 2) процессы второго уровня: подпроцессы, являющиеся основными составляющими процесса первого уровня; 3) процессы третьего уровня: последовательность функций с промежуточным результатом; 4) процессы четвертого уровня: функции, детализированные на операции. Сейчас существует 13 бизнес-процессов верхнего уровня, которые направлены на достижение главных целей холдинга в соответствие с его миссией. В соответствие с текущими задачами холдинга данные бизнес-процессы должны быть исследованы, именно поэтому необходимо декомпозировать и рассматривать процессы второго и третьего уровня. Существуют различные подходы к моделированию предметной области, выделим функционально-ориентированный и объектно-ориентированный подходы, которые рассмотрим в параграфах 2.1-2.2. 2.2 Функционально-ориентированный подход Функционально-ориентированный подход применяется бизнес-аналитиками холдинга преимущественно для построения моделей бизнес-процессов «Как есть». Для этого необходимо представить организацию в виде иерархии функций, преобразующих поступающий поток информации в выходной поток. При этом процесс преобразования потребляет определенные ресурсы. Такой подход четко разграничивает данные и функции, которые их обрабатывают [2]. Согласно принципам функционально-ориентированного подхода холдинг представляется иерархической древовидной структурой с добавлением новых деталей на каждом уровне. Далее предполагается разбиение сложной задачи холдинга на подзадачи, которые просты в понимании и решении. Таким образом, получается множество бизнес-процессов, направленных на достижение определенных целей холдинга, которые в свою очередь могут быть также декомпозированы. Функционально-ориентированный подход рассмотрим их подробнее: 23 имеет свои достоинства, 1. Модели «Как есть» должны быть тщательно изучены, с этой точки зрения функционально-ориентированные модели более наглядны для бизнесаналитиков холдинга, нежели чем объектно-ориентированные модели. 2. В процессе разработке моделей бизнес-аналитику необходимо проводить интервью сотрудников, задействованных в процессе. Подход от выполняемых функций интуитивно лучше понимается исполнителями при получении от них информации об их текущей работе. 3. С помощью функционального подхода точнее разрабатываются должностные инструкции сотрудников холдинга на основе моделей бизнес-процессов. 4. В настоящее время в холдинге ожидаются некоторые изменения в организационной структуре, функциональные модели хорошо показывают себя в таких случаях. Главный недостаток функциональных моделей заключается в том, что процессы и данные существуют отдельно друг от друга – помимо функциональной декомпозиции существует структура данных, находящаяся на втором плане [2]. Кроме того, бизнес-аналитикам холдинга сложно представить процессы обработки информации, которые динамически могут изменяться, так как не ясны условия их выполнения. В рамках функционально-ориентированного подхода рассмотрим такие методологии как ARIS и IDEF. 2.2.1 Методология ARIS В данной работе нотации ARIS VAD и ARIS eEPC являются центральными для построения бизнес-процессов рассматриваемого холдинга. Бизнес-аналитики холдинга строят модели бизнес-процессов с помощью данной методологии, так как это обусловлено требованиями в части моделирования бизнес-процессов. Консультанты подрядной организации также используют эти нотации, однако разницу между ними представляет лишь графическое описание. Рассмотрим методологию подробнее. ARIS – это методология построения интегрированных информационных систем (Architecture of Integrated Information Systems, ARIS) предполагает 24 определённый подход к формализации информации о деятельности организации и представление её в виде графических моделей, удобном для понимания и анализа. Модели ARIS могут быть использованы для анализа и выработки различного рода решений по реорганизации деятельности предприятия, в том числе по внедрению информационной системы управления, разработке систем менеджмента качества [3]. Методология включает различные типы моделей в зависимости от поставленных задач, однако в данном исследовании остановимся на методе описания взаимосвязи бизнес-процессов первого и второго уровня Value Added Chain diagram (VAD) и методе описания процессов третьего и четвертого уровня Extended Event–Driven Process Chain (eEPC), которые позволяют детально описать бизнес-процессы холдинга. Приступим к исследованию нотации ARIS VAD. 1. Элементы, типа «Функция»: a) Business Process Level 1 служит для отображения процессов самого верхнего уровня; b) Business Process представляет бизнес-процессы, являющиеся составляющими процесса верхнего уровня; c) Subprocess является декомпозицией процесса, представляющегося элементом Business Process. 2. В моделях такого типа отображаются два вида связей между процессами: a) связь «предшественник-последователь» горизонтальными линиями. Данная связь изображается используется для описания последовательности процессов; b) связь «состоит из» изображается вертикальными линиями, отображающими детализацию процесса другими подпроцессами. 3. Objective – цель процесса. Элемент необходим для получения информации о том, для каких стратегических целей выполняется данный процесс и что даст результат выполнения процесса для организации. 4. Product/Service – продукт или услуга, которые являются результатами выполнения какой-либо стадии процесса. 25 5. KPI – ключевой показатель деятельности, влияющий на количественное или качественное изменение результатов по отношению к поставленным целям процесса. Проиллюстрируем применение VAD модели на процессе управления изменениями по проектам холдинга (см. рис. 2.1). Рисунок 2.1 Фрагмент VAD модели процесса управления изменениями по проектам холдинга VAD модель позволяет бизнес-аналитикам холдинга получить наглядную информацию о логической взаимосвязи рассматриваемого процесса с процессами верхнего уровня, а также о его составе. Такую модель можно считать картой процесса, иллюстрирующей основные результаты каждой фазы, в какой последовательности и куда эти результаты передаются. С помощью КПД бизнесаналитик может оценить эффективность выполнения процесса по отношению к целям, которые также должны быть отражены на VAD модели. Выделим следующие особенности VAD: 1) основная нотация моделирования бизнес-процессов холдинга, бизнесаналитики используют данную нотацию для описания и регламентации бизнес-процессов первого и второго уровня; 2) нотация используется для описания логической взаимосвязи рассматриваемого процесса с его составляющими фазами и процессами верхнего уровня; 3) по аспекту моделирования VAD модели можно отнести к функциональным моделям; 4) VAD модели являются статическими моделями, так как при их разработке главное показать структуру рассматриваемого процесса; 26 5) нотация VAD предназначена для моделирования процессов верхнего уровня; 6) структурообразующие элементы нотации – бизнес-процесс и связи, указывающие на последовательность бизнес-процессов и отношение «часть/целое» между процессами; 7) нельзя показать элементы организационной структуры; 8) наличие элементов, указывающих на цель процесса и показателей, по которым эффективность процесса и степень реализации цели будет оцениваться; 9) направление связей относительно остальных элементов нотации не регламентируется. Теперь рассмотрим нотацию ARIS eEPC для процессов, требующих более детального описания. В [4] дается следующее определение: «eEPC – это направленный граф событий и функций, содержащий различные логические коннекторы, которые позволяют моделировать альтернативный и параллельный ход процессов. Опишем элементы нотации. 1. Элементы типа «Функция». В данную группу входят следующие элементы: a) Function–бизнес-функция, выполняемая в рамках определенной системы; b) часто рассматриваемый бизнес-процесс связан с какими-то внешними бизнес-процессами, для этого используется элемент типа Process Interface. i. Process Interface Start указывает на бизнес-процесс, являющийся начальным для текущего бизнес процесса. ii. Process Interface Middle указывает смежный бизнес процесс, являющийся выходным во время выполнения текущего бизнес-процесса, и/или ссылка на смежный бизнес-процесс, являющийся входным, во время выполнения текущего бизнес-процесса. iii. Process Interface End указывает смежный бизнес-процесс, являющийся конечным для текущего бизнес процесса. 27 2. Элементы типа «Событие»: a) стартовое событие; b) событие внутри бизнес-процесса; c) конечное. 3. Элементы типа «Информационный носитель»: a) E-mail – сообщение электронной почты; b) File – любая внешняя база данных; c) Document – документ. 4. Логические операторы, отражающие альтернативные варианты выполнения бизнес-процесса: a) AND Operator – логическое «И»; b) OR Operator – логическое «ИЛИ»; c) XOR Operator – логическое исключающее «ИЛИ». 5. Элементы, отражающие исполнителей бизнес-функций: a) Group – элемент соответствует временной группе сотрудников, не имеющей статуса постоянного подразделения Компании; b) Person Type – бизнес-роль. 6. Application System Class – информационная система корпоративного масштаба, участвующая при выполнении бизнес-функции, если таковая является автоматизированной. 7. Application System Type – элемент обозначает модуль/подсистему большой информационной системы. 8. Cluster – элемент обозначает шаблон для бизнес-функции, который берется (или создан, подготовлен) в информационной системе/программном продукте. 9. Screen – элемент соответствует транзакции или экранной форме АСУ. Рассмотрим часть модели в нотации eEPC, на примере первой фазы процесса управления изменениями «Инициирование предложения по внесению изменений» (см. рис. 2.2). 28 29 Рисунок 2.2 Фрагмент eEPC модели «Инициирование предложения по внесению изменений» Центральный элемент нотации – бизнес-функция, которая может инициироваться и заканчиваться определенным событием, таким образом, бизнесаналитик получает информацию о состоянии внешней или внутренней среды, факте свершившегося действия или необходимости совершения какого-либо действия. События могут «переключать» бизнес-функции, т.е. передавать управление от одной функции к другой [1]. Каждая функция выполняется определенной ролью в бизнес-процессе, что говорит о распределении ответственности в рамках рассматриваемого процесса. Нотация содержит элементы, указывающие на материальные и информационные объекты, которые поступают на вход и преобразовываются функцией. Следует отметить, что такие объекты не классифицируются по различным типам, например заявки, внутренняя документация, документы, регламентирующие выполнение функции и т.д. [5].Дополнительную информацию представляет объект, указывающий на автоматизацию функции некоторой информационной системой. Одним из главных элементов нотации являются операторы, описывающие логику выполнения бизнес-процесса. Для того чтобы показать границы фаз в рамках одного бизнес-процесса используются внешние интерфейсы (см. рис. 2.3-2.4). Рисунок 2.3 Внешний начальный интерфейс eEPC модели «Оценка воздействия предложения по внесению изменений» Рисунок 2.4 Внешний конечный интерфейс eEPC модели «Оценка воздействия предложения по внесению изменений» Вследствие такого окружения функции, модели в нотации ARIS eEPC получаются громоздкими и трудночитаемыми, с этим растет сложность при выполнении анализа моделей бизнес-процесса [5]. 30 На основе вышеизложенного исследования можно выделить следующие особенности языка ARIS eEPC: 1) данный язык используется в качестве основного языка моделирования бизнес-процессов холдинга, бизнес-аналитики используют данную нотацию для описания и регламентации бизнес-процессов третьего и четвертого уровня; 2) нотацию ARIS eEPC используют для более детального описания бизнеспроцессов: отражаются последовательность и логика выполнения функций бизнес-процесса, исполнители, входные и выходные объекты и другая информация [1]; 3) по аспекту моделирования модели в нотации ARIS eEPC относятся к моделям бизнес-процессов; 4) модели, разработанные с помощью нотации ARIS eEPC, являются поведенческими, так как нотация учитывает логику выполнения процесса, альтернативные переходы с помощью логических операторов; 5) нотация используется для моделирования процессов третьего и четвертого уровня; 6) структурообразующими элементами являются функция, событие и правила выполнения функций (логические операторы); 7) исполнители функций представлены двумя типами: группа и роль; 8) границы системы могут обозначаться внешними интерфейсами; 9) возможность использования элементов, указывающих на автоматизацию функции; 10) возможность задания атрибутов функции; 11) направление связей относительно остальных элементов нотации не регламентируется. 2.2.2 Методология IDEF Нотация IDEF0 предполагает описание функциональной модели организации, представляющего систему в виде набора взаимосвязанных функций [5]. Данная нотация может применяться для получения холдингом статуса организации, удовлетворяющей стандартам ISO 9000 и ISO 9001. 31 Рассмотрим данную нотацию подробнее. Моделирование следует начинать с описания контекста, при этом обязательно учитывать точку зрения на модель и цель моделирования, так как точка зрения определяет основное направление развития модели и уровень необходимой детализации. Цель и точка зрения существенно влияют на субъект моделирования. Под субъектом моделирования подразумевается сама система, но при этом необходимо точно установить, что входит в систему, а что находится за ее пределами [2]. В дальнейшем процесс может быть декомпозирован, уровень декомпозиции выбирается разработчиком модели исходя из его целей и точки зрения. Опишем основные элементы нотации: 1. Функциональный блок представляет собой определенную функцию в рамках рассматриваемой системы. Функциональный блок изображается в виде прямоугольника, каждая из его сторон имеет определенное назначение: a) верхняя сторона отражает «Управление», нижняя «Механизм»; b) левая сторона имеет значение «Вход», а правая «Выход». 2. Интерфейсная дуга отображает элемент системы, обрабатываемый функциональным блоком или оказывающий на него иное влияние. С помощью интерфейсной дуги отображается: a. Вход - входной поток, в роли которого может выступать информация, предметы материального мира. b. Выход - выходной поток – результат преобразования функциональным блоком входного потока. c. Механизм, который представляет собой ресурсы, с помощью которых выполняется функциональный блок. В роли механизмов часто выступают исполнители функции, либо материалы, оборудование, с помощью которых она реализуется. d. Управление – данные, предназначенные для регулирования выполнения функционального блока. Управление никак не преобразуется в ходе выполнения функционального блока, оно лишь выступает регулятором, предоставляя правила, инструкции. Связи можно классифицировать следующим образом: 32 1) связь «Выход - Вход» подразумевает, о том, что выход одной функции является входом для другой; 2) «Выход - Управление» говорит, о том, что выход одного функционального блока подается на управление другого; 3) «Выход - Механизм» подразумевает, что выход одного функционального блока используется как механизм при реализации другого; 4) «Выход - Обратная связь на управление» используется в тех случаях, когда зависимый блок корректирует исполнение управляющего; 5) «Выход – Обратная связь на вход» обычно применяется для описания цикла. Как было обозначено, с помощью данной нотации моделируются процессы верхнего уровня, применим IDEF0 для этой задачи (см. рис.2.5). Рисунок 2.5 Фрагмент IDEF0 модели процесса управления изменениями по проектам холдинга Моделирование с помощью IDEF0 предполагает обязательное наличие управления и выходного потока. Логично, что каждый процесс должен обязательно порождать некоторый результат, при этом его выполнение должно каким-то образом регламентироваться, в противном случае нет смысла моделировать. Можно отметить, что модели IDEF0 абстрагированы от времени, в нотации нет элементов, которые бы передавали ветвления, разделения и слияния параллельных функций и их длительность. Хотя на интуитивном уровне должно 33 быть понятно о порядке их следования. Также IDEF0 не предусматривает наличие элементов, отражающих события начала и завершений функций. Проиллюстрируем вышеизложенную характеристику на примере фрагмента процесса «Инициирование предложения по внесению изменений» (см. рис. 2.6). Рисунок 2.6 Фрагмент IDEF0 модели «Инициирование предложения по внесению изменений» Как видно из фрагмента с помощью IDEF0 неудобно представлять точку разделения процессов, так как нет соответствующих элементов. Таким образом, язык IDEF0 используют для описания процессов верхнего уровня с акцентом на их управление. IDEF0 применяют на начальных этапах разработки ИС, когда необходимо понять, как работает организация, которую собираются автоматизировать. Руководитель хорошо понимает работу в целом, но не может точно знать о деталях её исполнения, в свою очередь его подчиненный понимает работу на своем рабочем месте, при этом, не углубляясь в детали работы других рабочих. Поэтому для описания холдинга необходимо построить модель, которая будет адекватно отражать ситуацию и при этом учитывать знания всех участников бизнес-процессов. Моделирование с помощью IDEF0 помогает ответить на следующие вопросы: 1. Какие функции, и в какой последовательности выполняются в рамках рассматриваемой системы? 2. Кто является исполнителем каждой функции? 3. Чем руководствуется исполнитель при выполнении функции? 4. Что является результатом выполнения функции? 34 На основании представленной характеристики можно выделить следующие особенности IDEF0: 1) нотацию IDEF0 используют при сертификации по стандартам ISO 9000 и ISO 9001; 2) IDEF0 используется для описания бизнес-процессов верхнего уровня, для понимания в целом как это работает, принимая во внимание знания всех участников бизнес-процессов; 3) по аспекту моделирования модели в IDEF0 относятся к функциональным моделям; 4) IDEF0 – нотация для построения статистических моделей, для которых характерно абстрагирование от времени: a) отсутствие элементов, отвечающих за ветвления, т.е. за условный переход от функции к функциям; b) нет элементов разделения и слияния параллельных функций; c) также никак не отражена длительность функции; d) нет событий начала, конца; 5) по уровню детализации модели в нотации IDEF0 могут относиться к первому, второму уровню, иногда с помощью IDEF0 моделируются процессы третьего уровня; 6) структурообразующим элементом является функция; 7) исполнителя функции можно задать с помощью механизма; 8) границы системы определяются точкой зрения и целью моделирования, IDEF0 не подразумевает наличие специальных элементов для представления внешних воздействий; 9) 10) четкая типизация потоков данных: вход, выход, управление, механизм; различные виды связей: «Выход-Вход», «Выход-Управление», «ВыходМеханизм», «Выход-Обратная связь на управление», «Выход-Обратная связь на вход»; 11) обязательное наличие выхода (результата) и регламентирующего исполнение функции; 12) направление связей строго регламентируется методологией. 35 управления, 2.3 Объектно-ориентированный подход Объектно-ориентированный подход рассматривает моделируемый холдинг как набор взаимодействующих объектов – производственных единиц. В объектноориентированном подходе выделяют два ключевых понятия: объект и класс. Объект определяется как осязаемая реальность – предмет или явление, имеющее четко определяемое поведение. Данный подход применяется холдингом на этапах проектирования информационных систем, автоматизирующих тот или иной бизнес-процесс. Такие процессы являются более адаптивными, поэтому данный подход позволяет описывать условия выполнения процессов [2]. В частности для этой задачи в холдинге используется язык UML, который основан на принципах объектноориентированного подхода. UML (Unified Modeling Language) – унифицированный язык моделирования, который применяется для многих целей, в том числе и для моделирования бизнеспроцессов. В рамках языка UML все представления о модели сложной системы фиксируются в виде диаграмм. Как уже было обозначено, использование UML диаграмм актуально при проектировании разработкой информационных программного систем, кода. Сейчас начиная с анализа, бизнес-аналитики заканчивая занимаются подготовкой некоторых бизнес-процессов холдинга к автоматизации с целью повышения их эффективности. На начальных стадиях проектирования ИС, необходимо постоянное взаимодействие разработчика и заказчика ИС (холдинга) для построения концептуальной и логической модели бизнес-процессов, а также описания функциональных требований. В результате обзора (см. приложение B, таблица B.1) выяснилось, что большинство CASE средств являются UML ориентированными, программисты также часто используют язык UML для построения моделей. С другой стороны бизнес-аналитики холдинга, непрофессиональные программисты, лучше понимают функционально-ориентированные модели, таким образом, встает проблема трансформации объектно-ориентированных в функционально-ориентированные модели. 36 При построении логической модели процессов холдинга, которые необходимо автоматизировать, используется нотация UML Activity Diagram, диаграмма активности. Рассмотрим элементы нотации: 1) активность – то, что необходимо выполнить (деятельность или действие); 2) объект, который либо инициирует выполнение действий, либо определяет их результат. При моделировании БП чаще в роли объекта выступают данные. Объект может содержать характеристику состояния; 3) поток управления отражает порядок выполнения активностей; 4) траектория объектов показывает, что результатом активности является переход указанного объекта в иное состояние или создание нового объекта в указанном состоянии. Траектория объектов отражает поток данных. Когда траектория объектов по направлению совпадает с потоком управления, можно использовать в качестве перехода только траекторию объектов; 5) точка ветвления описывает различные пути выполнения в зависимости от значения некоторого условного выражения; 6) для параллельных управляющих потоков используются: a) точка разделения, которая обеспечивает разделение одного потока на несколько параллельных потоков; b) точка слияния, которая обеспечивает синхронизацию нескольких параллельных потоков; 7) начальный узел деятельности – узел, в котором начинается поток (или потоки) при вызове данной деятельности извне; 8) конечный узел деятельности – узел, который останавливает все потоки данной диаграммы деятельности; 9) дорожка – графическая область диаграммы, содержащая элементы, ответственность за выполнение которых принадлежит отдельным подсистемам. Диаграмма разбивается на дорожки с исполнителем активности. Такие дорожки хорошо демонстрируют распределение зон выполнение функций между участниками бизнес-процесса. 37 ответственности за Потоком управления определяется порядок выполнения активностей, а объектный поток передает информационные ресурсы от активности к активности. Фрагмент иллюстрирует ветвление процесса в зависимости от результата проверки модели. Для большей информативности стрелки от синхронизационной черты подписываются в соответствие с результатом выполнения функции. Некоторые объекты имеют состояния, которые могут меняться после выполнения активности. Состояние объекта лучше отражает, каким именно образом объект преобразовывается функцией. Эта возможность является очень важной для разработки функциональных требований к системе. Рассмотрим применение диаграммы активности для процесса интегрированного моделирования Активов холдинга, а именно конфигурации интегрированной модели. Практически предполагают задействование поддерживать все все информационной необходимые этапы функции данного системы, интегрированного которая процесса должна моделирования. Фактически каждая функция процесса представляет собой функциональное требование для разрабатываемой системы. Рассмотрим фрагмент процесса (см. рис. 2.7). Следует заметить, что приведенный ниже пример показывает ситуацию, когда объектный поток и поток управления не совпадает. Это случается когда результат выполнения активности передается не в следующую активность, а далее. 38 Рисунок 2.7 Фрагмент диаграммы активности «Конфигурация На основании представленной характеристики можно выделить следующие особенности нотации: 1) нотация используется разработчиками ИС для проектируемой системы с бизнес-аналитиками холдинга; 39 обсуждения 2) данная нотация используется для моделирования динамических аспектов поведения системы; 3) модели, разработанные в нотации UML Activity Diagram, являются моделями бизнес-процессов; 4) нотация UML Activity Diagram реализует поведенческое моделирование, так как с помощью диаграммы активности можно передать: a) слияние и разделение для параллельных активностей; b) событие, инициирующее и завершающее активность; 5) по уровню детализации бизнес-процессов модели принадлежат 3-4 уровню; 6) управление порядком выполнения активностей происходит в зависимости от их временной последовательности (поток управления). Траектория объектов (поток данных) и поток управления могут совпадать; 7) нет понятия потока управления, в смысле регулятора выполнения активности (правила, инструкции); 8) дорожки отражают исполнителей; 9) направление связей не регламентируется методологией. 2.4 Сопоставление подходов к моделированию бизнес-процессов Оба рассмотренных подхода имеют отличительные особенности с точки зрения решения некоторых задач холдинга (см. таблицу 2.2). Функционально-ориентированный подход Ключевой элемент – функция Большая наглядность моделей для бизнесаналитиков холдинга, а также сотрудников, участвующих в бизнес-процессах холдинга Модели хорошо использовать при изменении организационной структуры холдинга или в случае, когда она слабо оформлена Модели больше подходят для регламентированных процессов. Такой бизнеспроцесс был рассмотрен и описан в соответствующих нотациях (см. параграф 2.1, рис. 2.1-2.6) Таблица 2.2 Особенности подходов Объектно-ориентированный подход Ключевой элемент – объект Хуже понимаются бизнес-аналитиками холдинга и сотрудниками, участвующими в бизнес-процессах холдинга Подход позволяет построить более стабильную систему, лучше соответствует структурам х Объектно-ориентированные модели целесообразнее применять на начальных этапах разработки информационной системы, автоматизирующей некоторые бизнес-процессы холдинга. Соответствующий процесс был рассмотрен в параграфе 2.2, рис.2.7 На основании второй главы получим сводную характеристику нотаций соответствующих подходов (см. таблицу 2.3). 40 41 Показывает логику выполнения процессов Показывает состав взаимосвязь процесса с процессами верхнего уровня Функциональная модель Статическая 1, 2-й Не строго + - Применение Аспект моделирования Тип модели Уровень детализации БП Соблюдение последовательности Событие Ветвление Слияние Информационный поток Средство выполнения процесса Управление процессом Исполнитель + - - + + + + + 3,4-й Поведенческая Модель БП Основная модель для Сертификация по описания процессов стандартам ISO 9000 и холдинга 9001 Основная модель для описания процессов холдинга Область использования в холдинге + + + + - - - - 1, 2-й Статическая Функциональная модель Показывает, как в целом как работает система Функциональноориентированный Функциональноориентированный Функциональноориентированный Подход IDEF0 ARIS eEPC ARIS VAD Критерий сравнения + - + + + + + + 3,4-й Поведенческая Модель БП Показывает логику выполнения процессов Используется программистами при проектировании ИС Объектно-ориентированный UML Activity Diagram Таблица 2.3 Характеристика нотаций моделирования бизнес-процессов Основываясь на результатах исследования, представленного в параграфах 2.1-2.2, можно заключить следующее: 1. VAD Диаграмма показывает верхний бизнес-процессы верхнего и фактически представляет собой карту процесса, на которой хорошо отражается его структура и взаимосвязи с другими процессами. Цели и КПД позволяют бизнес-аналитику судить об эффективности бизнеспроцесса. На диаграмме отражаются основные элементы, являющиеся результатами выполнения каждой фазы. В нотации нет элементов организационной структуры, то есть бизнес-аналитик не получит информации об ответственности за основные фазы бизнес-процесса. 2. IDEF0 используется для моделирования бизнес-процессов верхнего уровня. С помощью модели можно получить представление о распределении ответственности за подпроцессы, а также с помощью чего выполняется и регулируется процесс. 3. Нотация ARIS eEPC является самой полной из всех рассмотренных, которая направление на более детальное моделирование бизнеспроцессов. С помощью нотации можно отразить границы процесса, его информационное обеспечение, документный поток, а также ответственность за выполняемые функции. 4. Диаграмма активности используется для разработки функциональных требований к системе для автоматизации. С этой точки зрения очень важно понимать, как именно функция обрабатывает исходные данные, чтобы получить результат. Для этого используется состояние объекта, которое может меняться в зависимости от выполнения той или иной активности. 2.5 Имитационное моделирование бизнес-процессов После того как построены достоверные модели бизнес-процессов «Как есть», переходят к их анализу. Под анализом бизнес-процессов будем понимать деятельность, направленную на изучение и оценку бизнес-процессов с целью их организации и улучшения. 42 Выделяют два основных вида анализа бизнес-процессов: количественный и качественный. Количественный анализ позволяет получить численные оценки параметров процесса, проверить их на соответствие эталонным значениям, качественный проводится с целью понимания поведения и структуры процесса. Сначала вычисляют текущие численные значения параметров процесса с помощью методов количественного анализа, затем выясняют причины высоких или низких показателей, их зависимость от определенных факторов, используя методы качественного анализа [13]. В данной работе речь пойдет о количественном анализе, поэтому выделим ключевые показатели бизнес-процессов холдинга, в первую очередь подвергающиеся оптимизации: 1) затраты бизнес-процесса; 2) продолжительность бизнес-процесса; 3) количество обслуженных единиц или количество произведенного продукта, услуги. Исходя из определенных выше показателей, холдинг может ставить перед собой следующие цели [14]: 1) повышение уровня обслуживания; 2) сокращение общей длительности цикла процесса; 3) повышение производительности; 4) сокращение времени ожидания; 5) снижение затрат на осуществление данной деятельности; 6) снижение затрат на хранение товарно-материальных запасов. Для достижения данных целей необходимо добиться [14]: 1) объединение дублирующих функций; 2) устранение множественных уровней проверки и получения подтверждения; 3) регулирование производства на основе спроса; 4) передача сотрудникам, работающим на смежном производстве, неэффективно выполняемых функций; 5) устранение перемещений в процессе выполнения данной работы. 43 Некоторые бизнес-процессы холдинга сложны и динамичны, поэтому потоковые модели не обеспечивают полноты анализа. В настоящее время применение имитационного моделирования является эффективным инструментом для реализации вышеперечисленных целей и задач. Имитационное моделирование позволяет строить модели, описывающие процессы так, как они проходили бы в действительности. Такую модель можно «проиграть» во времени как для одного испытания, так и заданного их множества. При этом результаты будут определяться случайным характером процессов. По этим данным можно получить достаточно устойчивую статистику [15]. Проведение имитационного моделирования предполагает осуществление четырех основных этапов [16]: 1) построение модели одного или нескольких процессов, выполнение которых необходимо оптимизировать; 2) запуск имитации выполнения процессов модели; 3) анализ полученных показателей; 4) повторение п.1-3 для альтернативных сценариев выполнения процесса и выбор наиболее оптимального. В рамках имитационного моделирования изучим три системы GPSS World, модуль ARIS Simulation и AnyLogic. 2.5.1 Система GPSS World GPSS (General Purpose Simulation System) – система и язык моделирования, используемый для имитационного моделирования различных систем, в основном систем массового обслуживания. Основой имитационных алгоритмов в GPSS является, дискретно-событийный подход [26]. Краткое описание системы представлено в приложении A, таблица A.1. Среди огромного множества разработок для персональных ЭВМ можно выделить несколько основных. Это следующие системы: GPSS/H, SLX, Proof Animation (Wolverine Software); GPSS/PC и GPSS World (Minuteman Software); Micro-GPSS и WebGPSS (Стокгольмская школа высшей экономики). К наиболее используемым в России зарубежным системам относятся Arena и GPSS World [23], 44 поэтому в данной работе рассматривается система GPSS World (Minuteman Software). Тот факт, что система ориентирована в основном на процессы систем массового обслуживания, накладывает ограничение в области ее применения для задач холдинга. Язык является достаточно простым, с помощью такой модели можно описать процесс работы небольшого цеха, ремонтной службы, автозаправочной станции. Однако для моделирования систем с большим числом разнообразных точек обслуживания и сложной логикой обработки событий GPSS уже не подходит, потому что модель очень быстро разрастается и становится сложной для восприятия и контроля. Приходится расставлять специальные контрольные точки для сбора промежуточных значений показателей, что еще больше усложняет модель и затрудняет анализ ее работы [22]. Также на языке GPSS достаточно сложно представить непосредственно процессы обработки данных. Изначально GPSS World возможны такие эксперименты как: 1) анализ чувствительности, который используется для определения наиболее важных факторов, влияющих на моделируемую систему; 2) оптимизирующие эксперименты, которые позволяют определить оптимальные уровни факторов; 3) эксперименты пользователя – эксперименты над моделью, программируемые пользователем. Завершающий шаг любого эксперимента – это анализ результатов. Процедура дисперсионного анализа ANOVA позволяет осуществлять многофакторный дисперсионный анализ. Однако данная процедура имеет ограничение на количество исследуемых факторов – максимум 6. Данный недостаток может быть критичным при исследовании сложной модели с большим количеством воздействий [24]. Система GPSS World ориентирована на текстовое создание моделей. Однако автора работы [23] предлагает расширенный редактор GPSS World, который позволяет разрабатывать визуальные модели процесса, а также поддерживает 2D анимацию и обеспечивает создание анимационных форм. Важной доработкой системы является генератор отчётов, который строит отчёт в формате RTF, 45 совместимого с Microsoft Word. Исключительно важной новой функцией расширенного редактора является возможность проведения экспериментов и серий экспериментов непосредственно самим Заказчиком модели, с помощью специально созданного EXE модуля. Данные усовершенствования повышают уровень поддержки принятия решений на базе имитационной модели с помощью GPSS World «Расширенный редактор» по сравнению с версией GPSS World. Рассмотрим принципы моделирования на языке GPSS. Моделируемый объект (система) представляется в виде блок-схемы, построенной из заданного набора блоков, представляющих операции над элементами модели (устройствами, очередями и т.п.), выполняемые при продвижении в ней обслуживаемых заявок. Модель может включать несколько сегментов [18]. Рассмотрим данный язык подробнее. Статические элементы модели (устройства, очереди и т.д.) и операции над ними представляются в виде блоков. Обслуживаемые заявки являются динамическими элементами языка, представляющиеся также блоками. Логика использования блоков зависит от структуры моделируемой системы. Разберемся в некоторых понятиях языка GPSS [18]: 1) процесс – созданная на GPSS модель, каждый сегмент модели представляет собой отдельный процесс; 2) с помощью перемещения, динамических элементов, транзактов моделируются процессы; 3) транзакты представляют в общем случае заявки на обслуживание, а блоксхема – процесс их обслуживания; 4) блоки – операции, выполняемые в системе в процессе обслуживания в ней заявок; 5) дуги, соединяющие блоки, показывают порядок выполнения этих операций, определяют путь, по которому заявка должна пройти от момента ее входа в систему до окончания обслуживания и вывода из системы. GPSS содержит большое количество блоков [19], однако для построения простой модели бизнес-процесса достаточно рассмотреть несколько из них (см. Приложение B, таблица B.1). 46 Рассмотрим методы сбора статистики в имитационной модели [17]. Блоки QUENE и DEPART обеспечивают автоматический сбор статистических данных, описывающих вынужденное ожидание, которое может происходить время от времени в различных точках модели. При использовании регистратора очереди в тех точках модели, где ресурсы ограничены, интерпретатор автоматически собирает информацию об ожидании: 1) сколько раз требования приходили в очередь; 2) сколько пришедших требований фактически присоединилось к очереди и сколько сразу заняли прибор; 3) каково было максимальное значение длины очереди; 4) каково было среднее число ожидающих требований; 5) каково было среднее время ожидания тех требований, которым пришлось ждать. Основные выводы по системе и языку GPSS. 1. Система GPSS World в большей степени ориентирована на системы массового обслуживания, то есть она больше подходит для моделирования случайных процессов. 2. GPSS World не является подходящим инструментом для моделирования больших систем, как например, процесс работы всего нефтедобывающего цеха, язык отлично подходит для моделирования небольших систем, а также для «чернового» моделирования при решении масштабных и сложных задач. 3. В настоящее время существует ряд разработок, направленных на совершенствование системы GPSS World, с помощью которых можно моделировать более сложные системы. Главное направление таких разработок – облегчения взаимодействия пользователя и системы посредством графической оболочки. 4. На основании результатов проведения экспериментов могут быть сформированы отчеты в формате, совместимом с Microsoft Word. 5. GPSS модель содержит как динамические элементы – транзакты, которые создаются и уничтожаются в процессе имитации, а также постоянные элементы – устройства и очереди. 47 6. Язык GPSS содержит достаточное количество блоков для имитационного моделирования процесса и сбора необходимой статистики для простых случайных процессов. 2.5.2 Модуль ARIS Business Simulator Модуль имитационного моделирования ARIS Business Simulator используется в тех случаях, когда есть необходимость промоделировать во времени разработанные моделирования – модели определение бизнес-процессов. узких мест в Цель динамического реализации процессов: несогласованность параллельно выполняемых процессов, нехватка ресурсов для эффективного выполнения процессов и т.д. [26]. Можно выделить следующие этапы имитационного моделирования с помощью ARIS Business Simulation: 1) создание моделей процессов, используя стандартную нотацию ARIS eEPC; 2) подготовка и занесение параметров для динамического моделирования; 3) проведение эксперимента – прогон процессов во времени на основе занесенных параметров; 4) анализ результатов моделирования. Следует отметить, что аналитику не требуется заново разрабатывать модель для анализа, так как модуль ARIS Business Simulator интегрирован с платформой ARIS, таким образом, аналитику требуется ввести лишь исходные параметры и запустить процесс имитационного моделирования. Проиллюстрируем данные шаги на упрощенном фрагменте бизнес-процесса «Обработка заявок» (см. рис. 2.8). 48 49 Рисунок 2.8 ARIS eEPC модель фрагмента бизнес-процесса «Обработка заявок» Рассмотрим, какие параметры необходимо задать, чтобы получить статистику [27]: 1) для функций задается: a) время статического ожидания, т.е. время подготовки к выполнению функции; b) время ориентации, т.е. время перед выполнением функции; c) продолжительность выполнения функции; d) сколько раз должна выполниться данная функция перед переходом на следующее событие; e) необходимость задействования всего персонала, назначенного для выполнения данной функции или первого свободного; 2) для организационной единицы задается количество служащих, находящихся на рабочем месте; 3) для событий задается вероятность ветвления, которая может быть основана на наблюдениях и опыте участников процесса; 4) для операторов задается время синхронизации, что определяет, как долго система должна ждать поступление события на один из входов после поступления события на другой вход; 5) для связи, которая определяет, какая организационная единица какую функцию выполняет, задается количество служащих, требующихся для выполнения данной функции. Основные результаты динамического моделирования отражаются в характеристиках объектов, участвующих в моделировании: 1) для функций – затраты денег и времени на реализацию, время ожидания освобождения ресурсов; 2) для точек разветвления – время ожидания завершения параллельных процессов; 3) для организационных единиц – коэффициенты использования. В процессе динамического моделирования реальное поведение объектов отражается при помощи анимационных эффектов. Для ускорения процесса подобные эффекты могут быть отключены [37]. Таким образом, система позволяет оценить: 50 1) прерывание выполнения функции из-за отсутствия трудовых или материальных ресурсов; 2) число завершенных процессов; 3) узкие места, т.е. функции, которые не могут быть выполнены из-за нехватки ресурсов; 4) временную разницу между началом и концом процесса выполнения какой-либо функции. Собранная статистика может быть проанализирована как средствами ARIS (в табличной и графической форме), так и экспортирована в другие средства (Microsoft Excel) для более детального анализа, построения дополнительных диаграмм и графиков. Подведем итоги по модулю имитационного моделирования ARIS Business Simulator: 1) система реализует динамическое моделирование процессов посредством проведения динамического эксперимента, т.е. прогона процессов во времени при заданных характеристиках; 2) на основе динамического моделирования генерируется детальная статистика для поиска узких мест процесса, сравнения различных сценариев; 3) анимация позволяет бизнес-аналитику рассматривать процессы с различных точек зрения и выделять «узкие» места процессов; 4) результаты эксперимента могут сохраняться в atf или xls формате. 2.5.3 Система AnyLogic AnyLogic – программное обеспечение для имитационного моделирования, разработанное российской компанией The AnyLogic. Инструмент обладает современным графическим интерфейсом и позволяет использовать язык Java для разработки моделей [20]. Отличительной особенностью AnyLogic является использование не только одной парадигмой моделирования. Среда позволяет использовать различные уровни абстрагирования, стили и концепции, строить модели в рамках той или иной парадигмы и смешивать их при создании одной и 51 той же модели [21]. Краткое описание системы представлено в приложении A, таблица A.1. Система AnyLogic направлено на огромное количество прикладных задач. Однако в данном исследовании рассмотрим для, каких задач холдинга может быть применена данная система. 1. Нефтепромысел. Система обеспечивает принятие решений, касающихся развития, оптимизации или реорганизации производства, заранее оценить потенциальную прибыль или убыток от реализации такого рода решений. 2. Логистика и цепочки поставок. Рассматриваемый холдинг имеет большую дилерскую сеть, поэтому задача управления потоками товаров и информации в цепочке поставок очень актуальна. AnyLogic предоставляет инструмент для принятия решений в управлении цепями поставок. 3. Склад и перевозки. Управление перевозками включает в себя множество различных аспектов, таких как: планирование и организация перевозок и технического обслуживания автопарка, управление человеческими ресурсами, а также управления рисками. При помощи AnyLogic можно решить эти вопросы, а значит решить и главную задачу управления перевозками. Использование имитационное моделирования позволяет определить максимальную загрузку транспортных средств, минимизировать расходы на перевозки, а также вычислить вероятность превышения расходов. При помощи моделирования можно разыграть различные схемы транспортировки и управления автопарком, чтобы выявить и предотвратить возможные проблемы. 4. Рынок и конкуренция. Система позволяет помочь бизнес-аналитикам холдинга решить типичные задачи из области анализа и прогноза рынков: a) поведение потребителей; b) лояльность к бренду, возможность перехода с одного продукта на другой; c) реакция на продвижение продукта; d) поведение компаний-конкурентов; 52 e) имитационные модели рынка в сочетании с цепочками поставок, логистикой и моделью производства; f) внедрение нового продукта, о котором нет сопоставимых статистических данных. 5. Бизнес-процессы. Менеджеры холдинга могут решать проблемы организации бизнес-процессов и экспериментировать с различными решениями в пределах одного отдела. AnyLogic позволяет анализировать и оценивать эффективность бизнес-процессов компании, улучшать их, а также разрабатывать совершенно новые бизнес-процессы, основываясь на имитационных экспериментах. Модели AnyLogic могут быть основаны на любой из основных парадигм имитационного моделирования: дискретно-событийное моделирование, системная динамика, и агентное моделирование. Система обеспечивает достаточно высокий уровень поддержки принятия решений, так как AnyLogic обеспечивает выполнения нескольких типов экспериментов, а также развитую компьютерную оболочку, позволяющую запускать вычислительные эксперименты и просматривать их результаты. Рассмотрим виды экспериментов, реализованных в AnyLogic [25]. 1. Простой эксперимент запускает модель с заданными значениями параметров, поддерживает режимы виртуального и реального времени, анимацию, отладку модели. 2. Варьирование параметров позволяет сравнить поведение модели при разных значениях параметров и оценить степень влияния отдельных параметров на поведение модели. 3. Оптимизация позволяет найти значения параметров, при которых достигается наилучший результат моделирования системы, а также изучить поведение модели при заданных условиях. 4. Сравнение «прогонов» Позволяет интерактивно задавать различные значения параметров и запускать модель с этими значениями. 5. Анализ чувствительности выполняет несколько "прогонов" модели, варьируя значения одного из параметров и показывая, как результаты моделирования зависят от этих изменений. 53 6. Монте-Карло получает и отображает набор результатов моделирования для стохастической модели или для модели со стохастически меняющимися параметрами. 7. Калибровка находит значения параметров модели, при которых результаты моделирования наиболее точно соответствуют заданным данным. 8. Нестандартный эксперимент запускает нестандартный сценарий, полностью написанный пользователем. 9. Рассмотрим основные этапы построения модели AnyLogic [21]. На первом этапе решения задачи создается модель, которая соответствует структуре рассматриваемого бизнес-процесса. В ходе разработки модели учитываются только те детали, которые оказывают существенное влияние на изучаемые аспекты работы системы. Разработку модели следует начинать с элемента «Source», который задает интенсивность поступления заявок. Данный элемент можно связать с наступлением какого-либо события, это придаст модели большую информативность для бизнес-аналитика. 10. Далее генерируемые заявки поступают на обслуживание, которое представляется на модели с помощью элемента «Service». С данным элементом связано количество ресурсов, задействованных при выполнении некоторой функции. Ресурсы могут быть как трудовые, так и материальные, они также имеют определенную скорость обслуживания, которая задается бизнес-аналитиком. 11. Стоит отметить, что при моделировании неважно, какие документы обрабатываются функцией, а также что является ее результатом, поэтому нет смысла отражать информационный поток. Также нет смысла отражать промежуточные события, но если в этом есть острая необходимость можно подписать связь, соединяющую два элемента «Service». Для построения простой модели достаточно рассмотреть следующие элементы модели AnyLogic (см. Приложение B, таблица B.2). Теперь рассмотрим упрощенную модель AnyLogic бизнес-процесса «Обработка заявок» (см. рис. 2.9). 54 55 Рисунок 2.9 AnyLogic модель фрагмента бизнес-процесса «Обработка заявок» Следующий этап заключается в анализе статистики, собранной и представленной моделью. В результате проведения серии экспериментов над простой имитационной моделью бизнес-аналитик может определить следующую информацию о бизнес-процессе: 1) количество обслуженных заявок в каждой функции бизнес-процесса; 2) количество заявок, которые задерживаются в очереди; 3) сколько ресурсов простаивает; 4) доля занятых ресурсов. Собранные статистические данные можно сохранить и затем загрузить их обратно. Данные сохраняются в формате.csv и могут быть просмотрены в любом редакторе текста или в программе Excel. Подведем итоги по системе и языку AnyLogic: 1) современный и мощный язык имитационного моделирования среды AnyLogic, которую можно применять в следующих областях холдинга: a) нефтепромысел; b) логистика и цепочки поставок; c) склад и перевозки; d) рынок и конкуренция; e) бизнес-процессы холдинга; 2) система AnyLogic обеспечивает достаточно высокий уровень поддержки принятия решения за счет проведения сложных вычислительных экспериментов и анализа результатов моделирования, а также развитой графической оболочки, которая облегчает взаимодействие пользователя и системы за счет 2D и 3D анимации; 3) собранную по результатам экспериментов статистику можно сохранить и просмотреть в удобном формате Excel; 4) язык содержит достаточное количество элементов, с помощью которых можно разрабатывать модели процессов разных предметных областей; 5) с помощью элементов модели AnyLogic можно исполнителей, функции, события, альтернативные переходы. 56 представлять 2.5.4 Сопоставление систем имитационного моделирования бизнес-процессов Система GPSS появилась достаточно давно, однако на протяжении всего времени специалисты в этой области продолжают её совершенствовать. В параграфе 2.4 была рассмотрена система GPSS World «Расширенный редактор», которая включает доработки в области визуализации, а именно анимация и графический редактор моделей. Такие разработки направлены на улучшение взаимодействие пользователя с системой благодаря большей наглядности, как моделей, так и результатов экспериментов. Однако стандартная версия системы не подходит для моделирования очень сложных процессов, таких как деятельность нефтегазового цеха. Система больше направлена на проведение простых экспериментов для небольших отделов. Для решения задач холдинга она может быть применена, например, при моделировании деятельности автозаправочной станции. Главным достоинством ARIS Business Simulator является его полная интеграция с самой платформой ARIS. Таким образом, бизнес-аналитику не требуется разрабатывать модели для анализа заново, нужно просто задать исходные параметры и запустить эксперимент. Однако данная система обеспечивает лишь проведения одного динамического эксперимента, что является недостаточным для полного анализа. Поэтому, несмотря на возможность анимации, визуализации результатов с помощью графиков, система не предоставляет бизнес-аналитику должный уровень поддержки принятия решений. AnyLogic – самая мощная система имитационного моделирования среди изученных. Система обеспечивает проведение 8 различных экспериментов, развитую визуализацию, как самого процесса моделирования, так и его результатов. Помимо прочего систему может применяться для практически все области деятельности холдинга: от производства до реализации продукции. Система предоставляет бизнес-аналитику высокий уровень поддержки принятия решений за счет развитой графической оболочки и мощного функционала. Таким образом, на основании проведенного исследования, представленного в параграфе 2.2, а также сравнительной таблицы (см. таблицу 2.4), в качестве инструмента имитационного анализа предлагается рассмотреть систему AnyLogic. 57 Критерий Применение для решения задач холдинга Парадигма моделирования Вид эксперимента Графическая оболочка Построение моделей Уровень поддержки принятия решений Формат импорта моделей Формат экспорта моделей Генерация отчетов по результатам экспериментов Таблица 2.4 Сравнение систем имитационного моделирования ARIS Business GPSS World AnyLogic Simulator Нефтепромысел Для моделирования Логистика и цепочки Для моделирования простых случайных поставок простых динамических процессов небольших Склад и перевозки процессов подразделений Рынок и конкуренция Бизнес-процессы Дискретно-событийное ДискретноДинамическое моделирование, событийное моделирование системная динамика, и моделирование агентное моделирование Простой эксперимент Варьирование параметров Оптимизация Анализ чувствительности Сравнение «прогонов» Простой динамический Анализ чувствительности эксперимент Монте-Карло Оптимизирующие Калибровка эксперименты Эксперименты Нестандартный пользователя эксперимент В некоторых версиях 2D, 3D анимация, возможно применение Анимация, графики графики графиков и анимации Можно Текстовый редактор запрограммировать нестандартную логику Графический редактор доступен в Доступен графический Доступен графический версии GPSS World редактор моделей редактор моделей «Расширенный редактор» Средний уровень в Высокий уровень за счет усовершенствованных Не обеспечивает возможности проведения версиях должного уровня из-за различных типов поддержки только Низкий уровень в экспериментов и одного эксперимента стандартной версии развитой графики GPSS World в т.ч xml Модели Vensim (.mdl) .gps,.txt в т.ч xml В Java апплет отдельное приложение Java Отчетность в формате RTF, совместимым с Microsoft Word Отчетность может быть представлена средствами ARIS таблицей и графиками, а также экспортирована в другие средства, например, Microsoft Excel Отчетность может быть представлена средствами AnyLogic, а также в формате.csv и может быть просмотрена в любом редакторе текста или в программе Excel .gps,.sim,.gpr,.txt,.htm 58 2.6 Выводы по главе В данной главе были изучены такие нотации как ARIS VAD, ARIS eEPC, IDEF0, UML Activity Diagram и AnyLogic с точки зрения применения для решения задач холдинга, выразительной мощности, а также семантики и синтаксиса. На основании вышеизложенного исследования можно заключить, что нотация ARIS eEPC является наиболее выразительной по сравнению с другими нотациями. Следует отметить, что с помощью элементов изученных нотаций можно описать функциональную структуру бизнес-процесса. То есть все рассмотренные нотации содержат элементы, представляющие собой функции бизнес-процесса. Нотации также содержат в том или ином виде организационные элементы, участвующие в бизнес-процессе. Информационные объекты в явном виде присутствуют во всех нотациях, за исключением нотации AnyLogic, так как с точки зрения имитационного анализа такие данные использовать необязательно. Однако не все нотации используются для создания поведенческих моделей. Так, например, модели в нотациях ARIS VAD и IDEF0, главным образом, используются для моделирования бизнес-процессов верхнего уровня, и являются статическими, поэтому не содержат логических операторов. Вышеизложенное исследование нотаций с точки зрения назначения, выразительной мощности, а также семантики и синтаксиса является основой для разработки их метамоделей, а также правил трансформации моделей одной графической нотации в другие. 59 Глава 3. Разработка метамоделей языков описания бизнес-процессов Исходя из задач холдинга, обозначенных в п. 1.1, в данной главе необходимо решить следующие вопросы: 1) представить общую схему процесса трансформации моделей с помощью DSM-платформы; 2) разработать метамодели таких нотаций как ARIS VAD, ARIS eEPC (используемые бизнес-аналитиком), ARIS VAD, ARIS eEPC (используемые подрядчиком), IDEF0, UML Activity Diagram и AnyLogic на основе исследования, проведенного в главе 2. 3.1 Общая схема процесса трансформации моделей Прежде чем перейти к трансформации моделей бизнес-процессов, необходимо разработать метамодели языков их описания. Метамодель – модель, которая описывает структуру нотации, то есть все сущности, связи между ними и их атрибуты. посредством Правила трансформации сопоставления элементов задаются на уровне метамоделей исходной и целевой метамодели. Трансформация реализуется на моделях бизнес-процессов, основанных на соответствующих метамоделях. По аналогии с объектно-ориентированным программированием модель это – экземпляр класса «Метамодель». Как было отмечено, DSM-платформа MetaLanguage применяется для моделирования бизнеспроцессов холдинга. Рассмотрим характеристику системы подробнее. Система MetaLanguage представляет собой языковой инструментарий для разработки предметно-ориентированных языков. Основные конструкции системы [19]: 1) сущности языка моделирования, т.е. классы объектов предметной области, существенные с точки зрения решаемой задачи; 2) связи между сущностями языка: отношение наследования, ассоциации и агрегации; 3) ограничения, позволяющие описать правила построения моделей. Одним из центральных компонентов системы MetaLanguage является трансформатор, который основан на графовых грамматиках. Компонент трансформации позволяет производить преобразование созданных пользователями 60 моделей в текст или визуальную модель, описанную в другой графической нотации [19]. В данной работе рассматривается трансформация типа «Модель – Модель». Основные преимущества системы MetaLanguage: 1) многоуровневое моделирование; 2) динамическое изменение описаний метамоделей и моделей без повторной генерации кода DSL-редакторов; 3) трансформация моделей, предоставляющая возможность в нотациях исходного и целевого языков моделирования описывать и выполнять преобразования моделей, как между различными уровнями иерархии, так и внутри одного уровня. Подробнее с описанием системы MetaLanguage можно ознакомиться [19]. В главе 2 были рассмотрены основные элементы языков ARIS VAD, ARIS eEPC, IDEF0, UML Activity Diagram и AnyLogic. На этом основании разработаем метамодели языков с помощью системы MetaLanguage. Для разработки метамоделей языков будем использовать сущности, а также связи ассоциации, агрегации и наследования, где метамодель – модель языка, используемого для создания моделей [19]. Важно при разработке метамодели указать обязательный атрибут «Имя» для сущностей и связей. 3.2 Метамодель языка ARIS VAD Рассмотрим основные сущности метамодели языка ARIS VAD, который используется бизнес-аналитиками холдинга (см. таблицу 3.1). Таблица 3.1 Сущности метамодели языка ARIS VAD (Бизнес-аналитик) Сущность Атрибут Тип данных атрибута БизнесПроцессУровень1 Имя Строковый БизнесПроцесс Имя Строковый Подпроцесс Имя Строковый Цель Имя Строковый Результат Имя Строковый КПД Имя Строковый Теперь рассмотрим связи между сущностями (см. таблицу 3.2). Таблица 3.2 Связи между сущностями метамодели языка ARIS VAD (Бизнес-аналитик) Связь Тип связи Направление Состоит_Из_1 Агрегация Однонаправленная Состоит_Из_2 Агрегация Однонаправленная Предшественник_Последователь_1 Ассоциация Двунаправленная 61 Связь Предшественник_Последователь_2 Цель_БП БП_Результат КПД_БП Тип связи Ассоциация Ассоциация Ассоциация Ассоциация Направление Двунаправленная Однонаправленная Однонаправленная Однонаправленная Теперь представим в виде матрицы, какие именно сущности соединяют данные связи (см. таблицу 3.3). Сначала следует читать элемент строки, а затем элемент столбца. Таблица 3.3 Матрица связей между сущностями метамодели языка ARIS VAD (Бизнес-аналитик) БизнесПроце Сущность БизнесПроцесс Подпроцесс Цель Результат КПД ссУровень1 БизнесПроц + есУровень1 БизнесПроц + + + есс + Подпроцесс + Цель Результат + КПД - Связь агрегации используется для того, чтобы отразить иерархическую структуру бизнес-процессов, так как данный тип связи определяется как «частьцелое». Ассоциативные связи используются для соединения равноправных сущностей, которые некоторым образом связаны друг с другом. В результате получилась следующая метамодель языка ARIS VAD (Бизнесаналитик) (см. рис. 3.1). Рисунок 3.1 Результат разработки метамодели языка ARIS VAD (Бизнес-аналитик) в MetaLanguage 62 Теперь рассмотрим нотацию ARIS VAD, которую используют консультанты подрядной организации. В целом нотации очень похожи, разницу представляет лишь графическое описание элементов. Также подрядчики не используют элементы, представляющие иерархию бизнес-процесса с бизнес-процессом верхнего уровня, так как зачастую такая информация не содержится в регламентах, ею располагают сами бизнес-аналитики холдинга. Поэтому им проще самим доработать модели подрядчиков. Представим метамодель языка ARIS VAD (Подрядчик) (см. рис. 3.2). Рисунок 3.2 Результат разработки метамодели языка ARIS VAD (Подрядчик) в MetaLanguage 3.3 Метамодель языка ARIS eEPC Представим информацию о сущностях метамодели ARIS eEPC (Бизнесаналитик) в виде таблицы (см. таблицу 3.4). Таблица 3.4 Сущности метамодели языка ARIS eEPC (Бизнес-аналитик) Сущность Атрибут Тип данных атрибута Имя Строковый Функция Длительность Строковый Автоматизация Логический НачальныйИнтерфейс Имя Строковый СмежныйИнтерфейс Имя Строковый КонечныйИнтерфейс НачальноеСобытие СмежноеСобытие КонечноеСобытие ИС ИСКорпоративногоМасштаба МодульИС Имя Строковый Имя Строковый Имя Строковый Имя Строковый Сущность необходима для наследования Имя Строковый Имя Строковый 63 Сущность Объект Документ Файл ЭлектронноеПисьмо Транзакция/ЭкраннаяФормаАСУ Шаблон Оператор Группа Роль Атрибут Тип данных атрибута Сущность необходима для наследования Имя Строковый Имя Строковый Имя Строковый Имя Строковый Имя Строковый Имя Строковый Имя Строковый Имя Строковый Рассмотрим связи, используемые на метамодели языка ARIS eEPC (Бизнесаналитик) (см. таблицу 3.5). Таблица 3.5 Связи между сущностями метамодели языка ARIS eEPC (Бизнес-аналитик) Связь Тип связи Направление Функция_Функция Ассоциация Однонаправленная Функция_Интерфейс Ассоциация Двунаправленная Функция_СмежноеСобытие Ассоциация Однонаправленная Функция_КонечноеСобытие Ассоциация Однонаправленная Функция_Объект Ассоциация Двунаправленная Функция_Оператор Ассоциация Двунаправленная Интерфейс_Оператор Ассоциация Двунаправленная НачальноеСобытие_Функция Ассоциация Однонаправленная НачальноеСобытие_Оператор Ассоциация Однонаправленная СмежноеСобытие_Функция Ассоциация Однонаправленная СмежноеСобытие_Интерфейс Ассоциация Двунаправленная Оператор_СмежноеСобытие Ассоциация Двунаправленная Оператор_КонечноеСобытие Ассоциация Однонаправленная НачальныйИнтерфейс_Интерфейс Наследование Однонаправленная СмежныйИнтерфейс_Интерфейс Наследование Однонаправленная КонечныйИнтерфейс_Интерфейс Наследование Однонаправленная ИСКорпоративногоМасштаба_ИС Наследование Однонаправленная МодульИС_ИС Наследование Однонаправленная Документ_Объект Наследование Однонаправленная Файл_Объект Наследование Однонаправленная ЭлектронноеПисьмо_Объект Наследование Однонаправленная Транзакция/ЭкраннаяФормаАСУ_Объект Наследование Однонаправленная Шаблон_Объект Наследование Однонаправленная Рассмотрим подробнее связь наследования (см. таблицу 3.6). Таблица 3.6 Наследование сущностей метамодели языка ARIS eEPC (Бизнес-аналитик) Сущность-родитель Сущность-потомок НачальныйИнтерфейс Интерфейс СмежныйИнтерфейс КонечныйИнтерфейс ИСКорпоративногоМасштаба ИС МодульИС Документ Файл Объект ЭлектронноеПисьмо Транзакция/ЭкраннаяФормаАСУ Шаблон 64 Связь наследования используется для того, чтобы сущности-потомки унаследовали связи, соединяющие их родительскую сущность с другими сущностями. Заметим, что такой прием позволяет минимизировать ассоциативные связи между сущностями. Например, необходимо соединить связью сущность «Функция» с сущностями «Документ», «Файл», «ЭлектронноеПисьмо», «Транзакция/ЭкраннаяФормаАСУ» и «Шаблон». В данном случае получается 5 разных связей. При создании сущности родителя «Объект», необходимо провести лишь одну единственную связь «Объект_Функция», указав, что сущность-родитель не должна иметь экземпляров класса. Однако стоит заметить, что такой прием нарушает правила построения моделей, поэтому бизнес-аналитику надо быть очень внимательным. Например, нельзя проводить связь между такими сущностями как «КонечныйИнтерфейс» и «Функция», так как конечный интерфейс свидетельствует о том, что в данной точке процесс заканчивается и управление передается в другой процесс. Теперь представим в виде матрицы, какие именно сущности соединяются ассоциативными связями (см. таблицу 3.7). Сначала следует читать элемент строки, а затем элемент столбца. Таблица 3.7 Матрица связей между сущностями метамодели языка ARIS eEPC (Бизнес-аналитик) Функ Интер Начально Смежное Конечное Опера Сущность Объект ИС ция фейс еСобытие Событие Событие тор + + + + + + + Функция + + + Интерфейс Начальное + + Событие СмежноеСо + + + бытие КонечноеС обытие + Объект + ИС + + + + + Оператор Заметим, что такие сущности как «Группа» и «Роль» не связаны с другими сущностями, так как в нотации ARIS eEPC данные элементы также визуально не связаны с функциями. В результате получилась (см. рис. 3.3). 65 следующая метамодель 66 Рисунок 3.3 Результат разработки метамодели языка ARIS eEPC (Бизнес-аналитик) в MetaLanguage Нотация ARIS eEPC, используемая подрядчиком имеет некоторые особенности. Во-первых, подрядчик использует только один элемент для представления смежных бизнес-процессов. Также подрядчиком используется только одно событие, оно может являться как начальным, смежным так и конечным. Во-вторых, в нотации есть только один элемент «Организационная единица», который связан непосредственно с функцией, так как подрядчик не делит пространство модели на дорожки с исполнителями. В-третьих, подрядчик использует 2 типа информационных объектов: бумажный документ и документ, сгенерированный системой. Рассмотрим полученную метамодель языка ARIS eEPC (Подрядчик) (см. рис.3.4). Рисунок 3.4 Результат разработки метамодели языка ARIS eEPC (Подрядчик) в MetaLanguage 3.4 Метамодель IDEF0 Рассмотрим сущности языка IDEF0 (см. таблицу 3.8). Сущность ФункциональныйБлок Управление Механизм Таблица 3.8 Сущности метамодели языка IDEF0 Атрибут Тип данных атрибута Имя Строковый 67 Теперь рассмотрим связи между данными сущностями (см. таблицу 3.9). Таблица 3.9 Связи между сущностями метамодели языка IDEF0 Тип данных Тип связи Направление Атрибут атрибута Связь ФункциональныйБлок_Функцион альныйБлок Управление_ФункциональныйБл ок Механизм_ФункциональныйБлок Ассоциация Двунаправленная Имя Строковый Ассоциация Однонаправленная Имя Строковый Ассоциация Однонаправленная Имя Строковый Теперь представим в виде матрицы, какие именно сущности соединяют данные связи (см. таблицу 3.10). Таблица 3.10 Матрица связей между сущностями метамодели языка IDEF0 Сущность ФункцБлок Механизм Управление + ФункцБлок + Механизм + Управление В результате получим следующую метамодель языка IDEF0 (см. рис. 3.5). Рисунок 3.5 Результат разработки метамодели языка IDEF0 в MetaLanguage 3.5 Метамодель UML Activity Diagram Рассмотрим основные сущности метамодели языка UML Activity Diagram (см. таблицу 3.11). Таблица 3.11 Сущности метамодели языка UML Activity Diagram Сущность Атрибут Тип данных атрибута Название дорожки Имя Строковый Активность Имя Строковый Ветвление Имя Строковый Начальный_Узел Имя Строковый Конечный_Узел Имя Строковый Синхронизатор Имя Строковый Имя Строковый Объект Состояние Строковый Теперь рассмотрим связи между сущностями (см. таблицу 3.12). 68 Таблица 3.12 Связи между сущностями метамодели языка UML Activity Diagram Тип данных Связь Тип связи Направление Атрибут атрибута Строковый Активность_Активность Ассоциация Однонаправленная Имя Строковый Активность_Ветвление Ассоциация Однонаправленная Имя Строковый Акивность_КонечныйУзел Ассоциация Однонаправленная Имя Строковый Активность_Синхронизатор Ассоциация Однонаправленная Имя Строковый Активность_Объект Ассоциация Двунаправленная Имя Строковый Ветвление_Активность Ассоциация Однонаправленная Имя Строковый Ветвление_КонечныйУзел Ассоциация Однонаправленная Имя Строковый Ветвление_Синхронизатор Ассоциация Однонаправленная Имя Строковый НачальныйУзел_Активность Ассоциация Однонаправленная Имя НачальныйУзел_Синхронизато Строковый Ассоциация Однонаправленная Имя р Строковый Синхронизатор_Активность Ассоциация Однонаправленная Имя Строковый Синхронизатор_КонечныйУзел Ассоциация Однонаправленная Имя Синхронизатор_Синхронизато Строковый Ассоциация Однонаправленная Имя р Теперь представим в виде матрицы, какие именно сущности соединяют данные связи (см. таблицу 3.13). Сначала следует читать элемент строки, а затем элемент столбца. Таблица 3.13 Матрица связей между сущностями метамодели языка UML Activity Diagram Начальный Конечный Синхрон Сущность Активность Ветвление Объект узел узел изатор + + + + + Активность + + + Ветвление Начальный + + узел Конечный узел Синхрониза + + + тор + Объект В результате получим следующую метамодель языка UML Activity Diagram (см. рис. 3.6). 69 Рисунок 3.6 Результат разработки метамодели языка UML Activity Diagram в MetaLanguage 3.6 Метамодель AnyLogic В соответствие с таблицей C.2 (см. приложение C) рассмотрим основные сущности метамодели языка AnyLogic (см. таблицу 3.14). Сущность Source Sink Service SelectOutputIn SelectOutputOut ResourcePool Таблица 3.14 Сущности метамодели языка AnyLogic Атрибут Тип данных атрибута Имя Строковый Интенсивность поступления заявок Строковый Имя Строковый Имя Строковый Тип ресурсов Строковый Количество ресурсов Целый Вместимость очереди Целый Время задержки Строковый Имя Строковый Имя Строковый Вероятность Вещественный Имя Строковый Тип Строковый Количество Целый Скорость Строковый Теперь рассмотрим связи между сущностями (см. таблицу 3.15). 70 Таблица 3.15 Связи между сущностями метамодели языка AnyLogic Связь Тип связи Направление Source_Service Ассоциация Однонаправленная Source_SelectOutputIn Ассоциация Однонаправленная ResourcePool_Service Ассоциация Однонаправленная Service_Sink Ассоциация Однонаправленная Service_Service Ассоциация Однонаправленная Service_SelectOutputIn Ассоциация Однонаправленная SelectOutputOut_Sink Ассоциация Однонаправленная SelectOutputOut_Service Ассоциация Однонаправленная SelectOutputOut_SelectOutputIn Ассоциация Однонаправленная Теперь представим в виде матрицы, какие именно сущности соединяют данные связи (см. таблицу 3.16). Таблица 3.16 Матрица связей между сущностями метамодели языка AnyLogic Resource Сущность Source Sink Service SelectOutputIn SelectOutputOut Pool + + Source Sink + ResourcePool + + + Service SelectOutputIn + + + SelectOutputOut - В результате получилась следующая метамодель языка AnyLogic (см. рис. 3.7). Рисунок 3.7 Результат разработки метамодели языка AnyLogic 3.7 Выводы по главе Результатами данной главы являются разработанные метамодели таких языков как ARIS VAD, ARIS eEPC, IDEF0, UML Activity и AnyLogic. Полученные метамодели используются для разработки и реализации правил трансформации, которые рассматриваются в следующей главе. 71 Глава 4. Трансформация моделей В соответствие с задачами холдинга в области моделирования в данной главе необходимо: 1) разработать правила трансформации для вышеописанных метамоделей; 2) осуществить трансформацию моделей; 3) оценить результаты выполнения трансформаций. Определим, какие именно трансформации необходимо осуществить в соответствии с определенными задачами холдинга (см. рис. 4.1). Рисунок 4.1 Трансформация моделей бизнес-процессов в соответствие с задачами холдинга Теперь рассмотрим каждую нотацию с точки зрения содержания в ней основных элементов или их аналогов, необходимых для описания бизнес-процесса: 1) функция; 2) организационный элемент; 3) событие; 4) информационный объект; 5) внешний бизнес-процесс; 6) средство выполнения функции; 7) ветвление; 8) слияние. 72 ARIS VAD (Бизнесаналитик) + + Не требуется + Не требуется Не требуется Не требуется Не требуется ARIS VAD (Подрядчик) + + Не требуется + Не требуется 73 Не требуется Не требуется Не требуется + + + + + + + + ARIS eEPC (Подрядчик) + + + + + + + + ARIS eEPC (Бизнесаналитик) - + + Не требуется - + + + AnyLogic + + - - + + + + UML Activity Diagram - - + - + - + + IDEF0 Таблица 4.1 Характеристика нотаций для трансформации Для наглядности представим характеристику нотаций в виде таблицы (см. таблицу 4.1). Слияние Ветвление Средство выполнения функции Внешний бизнеспроцесс Информационный объект Событие Организационный элемент Функция Нотация 4.1 Трансформация ARIS-ARIS Определим правила трансформации моделей нотации ARIS VAD (Подрядчик) в модели нотации ARIS VAD (Бизнес-аналитик), а также моделей нотации ARIS eEPC (Подрядчик) в модели нотации ARIS eEPC (Бизнес-аналитик) (см. приложение D, таблицы D.1-D.2). Нотации, которые используются бизнес-аналитиком и подрядчиком очень похожи. Разницу между нотациями составляет лишь то, что подрядчики не используют элементы для описания взаимосвязи рассматриваемого бизнеспроцесса с процессами верхнего уровня. Это объясняется тем, что регламенты, которые передаются подрядчикам для разработки моделей бизнес-процессов, зачастую не содержат такую информацию. Не все консультанты подрядной организации являются опытными экспертами, которые хорошо разбираются в бизнес-процессах и могут без труда построить иерархическую структуру бизнеспроцессов для рассматриваемого. Поэтому после того как модели передаются обратно бизнес-аналитику, он сам может доопределить модель, отобразив дополнительные бизнес-процессы и связи между ними. В качестве примера рассмотрим исходную модель бизнес-процесса «Управление изменениями по проекту» в нотации ARIS VAD (Подрядчик) (см. рис. Приложение E, рис. E.1) и результат трансформации в соответствующую нотацию, которую использует бизнес-аналитик (см. рис. 4.2). Ввиду того что нотации имеют одинаковые элементы и соответственно связи между ними будут также идентичны, после выполнения трансформация модель не требуется доопределять. 74 75 Рисунок 4.2 Результат трансформации модели бизнес-процесса «Управление изменениями по проекту» в нотацию ARIS VAD (Бизнес-аналитик) Правила трансформации для моделей нотации ARIS eEPC (Подрядчик) в модели нотации ARIS eEPC (Бизнес-аналитик) представлены в приложении D (таблица D.2). Можно заметить, что рассматриваемые нотации практически идентичны, однако некоторая разница все-таки есть. Во-первых, нотация подрядчика не предполагает разделение области диаграммы на дорожки с исполнителями. Здесь с каждой бизнес-функций связана организационная единица. Кстати подрядчики используют всего один элемент, представляющий организационный элемент. В нотации бизнес-аналитика используются роли и группы. В данном случае можно трансформировать сущность «ОрганизационнаяЕдиница» только в «Роль» или только в «Группа». Следующее различие заключается в том, что подрядчики используют только один элемент «Событие» для представления начального, смежного и конечного события. Поэтому в данном случае придется задавать следующее правило трансформации сущности «Событие» в «СмежноеСобытие». Бизнес-аналитику самому придется отслеживать такие ситуации и заменять элементы, где необходимо использовать начальное или конечное событие. Подрядчики используют только один элемент «Интерфейс», для отражения бизнес-процессов, смежных с данным. На диаграмме понятно, в каком случае интерфейс является начальным, в каком смежном или конечным. Однако, для трансформации следует определять правило из определенной сущности только в одну конкретную сущность. В данном случае пусть используется правило трансформации элемента «Интерфейс» в элемент «СмежныйИнтерфейс». Как и в предыдущей ситуации, бизнес-аналитику придется самому заменять смежные интерфейсы на начальные или конечные. Последнее различие заключается в том, что подрядчик использует только два элемента для описания информационного потока: системный документ и бумажный документ. Таким образом, если результатом выполнения функции является электронное письмо, то бизнес-аналитику самому необходимо исправить элемент на соответствующий. Рассмотрим трансформацию исходной модели бизнес-процесса, которая представлена в приложении E (рис. E.2). Результат трансформации представим на рис 4.3. 76 77 Рисунок 4.3 Результат трансформации модели бизнес-процесса «Оценка воздействия предложения по внесению изменений» в нотацию ARIS eEPC (Бизнес-аналитик) Как видно из рис. 4.3 интерфейс в начале процесса должен быть начальным, а в конце – конечным, поэтому бизнес-аналитик сам должен поменять соответствующие элементы (см. рис. 4.4-4.5). Рисунок 4.4 Доопределение начального интерфейса модели бизнес-процесса «Оценка воздействия предложения по внесению изменений» после трансформации Рисунок 4.5 Доопределение конечного интерфейса модели бизнес-процесса «Оценка воздействия предложения по внесению изменений» после трансформации 4.2 Трансформация ARIS-AnyLogic Определим правила трансформации моделей нотации ARIS eEPC (Бизнесаналитик) в модели нотации AnyLogic (см. приложение D, таблица D.6). Главное различие нотаций заключается в том, что в нотации ARIS eEPC для слияния двух функций обязательно должен использоваться оператор, в нотации AnyLogic для этого нет специального элемента, поэтому слияние отображается напрямую к следующей функции. Трансформация таких подграфов является проблематичной, поэтому после её выполнения бизнес-аналитику необходимо проверить модель и скорректировать ее в случае необходимости. Для имитационного моделирования не важно, какие документы поступают на вход функции, какие являются ее результатом, поэтому отражать информационный поток на модели AnyLogic не имеет смысла. Рассмотрим исходную модель бизнес-процесса «Обработка заявок» в нотации ARIS eEPC (Бизнес-аналитик) (см. приложение E, рис. E.3). Результат трансформации в нотацию AnyLogic представлен на рис. 4.6. Модель требуется доопределить вручную, результат доопределения представлен на рис. 4.7. 78 79 Рисунок 4.6 Результат трансформации модели бизнес-процесса «Обработка заявок» в нотацию AnyLogic 80 Рисунок 4.7 Доопределение модели бизнес-процесса «Обработка заявок» 4.3 Трансформация UML-ARIS Определим правила трансформации моделей нотации UML Activity Diagram в модели нотации ARIS eEPC (Бизнес-аналитик) (см. приложение D, таблица D.3). Вообще нотация ARIS eEPC является расширенной версией UML Activity Diagram, поэтому трансформация должна быть удачной. Область диаграммы активности также делится на дорожки для разделения зоны ответственности за выполнение функций. Разница заключается в том, что дорожки на диаграмме активности располагаются вертикально, а в нотации ARIS eEPC горизонтально. Поэтому бизнес-аналитику после трансформации необходимо переместить элементы модели горизонтально. Так как обе нотации применяются для моделирования динамического аспекта системы, то есть содержат логические операторы, то в результате трансформации целевая модель должна содержать логическую структуру процесса. Еще одно отличие заключается в том, что в диаграмме активности нет такого понятия как событие между функциями, это означает, что после трансформации необходимые смежные события должны быть созданы вручную бизнесаналитиком. В качестве примера для выполнения правил трансформации рассмотрим фрагмент бизнес-процесса «Интегрированное моделирование», а именно первую его фазу «Конфигурация интегрированной модели» (см. приложение E, рис. E.4). Результат трансформации модели представлен на рис. 4.8. Можно заметить, что модель после трансформации полностью сохранила все элементы и связи между ними. Таким образом, модель после трансформации доопределять не надо, это значит, что трансформацию можно считать успешной. 81 82 Рисунок 4.8 Результат трансформации модели бизнес-процесса «Конфигурация интегрированной модели» в нотацию ARIS eEPC 4.4 Трансформация ARIS-IDEF0 Определим правила трансформации моделей нотации ARIS VAD (Бизнесаналитик) в модели нотации IDEF0 (см. приложение D, таблица D.4). Для нотации IDEF0 центральное место занимает функциональная цепочка. По сути ARIS VAD как раз описывает последовательность бизнес-процессов. Поэтому трансформацию можно считать удачной, если IDEF0 модель будет содержать цепочку бизнеспроцессов. Так как в нотации ARIS VAD результаты выполнения бизнес-процесса отражаются отдельными элементами, связанными только с одним бизнеспроцессом, а в нотации IDFE0 информационный поток представляется связями между функциональными блоками, то соответствующие данные не удастся передать при трансформации. Такую информацию аналитику придется доопределять вручную. Исходную модель бизнес-процесса «Управление изменениями по проекту» в нотации ARIS VAD (Бизнес-аналитик) можно посмотреть на рис. 4.2. Результат трансформации в нотацию IDEF0 представлен на рис. 4.9. Рисунок 4.9 Результат трансформации модели бизнес-процесса «Управление изменениями по проекту» в нотацию IDEF0 Теперь отразим информационный поток между функциональными блоками, основываясь на исходной модели (см. рис. 4.10). 83 84 Рисунок 4.10 Доопределение модели бизнес-процесса «Управление изменениями по проекту» Определим правила трансформации моделей нотации ARIS eEPC (Бизнесаналитик) в модели нотации IDEF0 (см. приложение D, таблица D.5). Рассматриваемые нотации ARIS eEPC и IDEF0 очень отличаются друг от друга. Главное отличие заключается в том, что цель использования нотации ARIS eEPC показать событийно-функциональную цепочку процесса, его поведение, нотация IDEF0 описывает функциональную модель процесса. Это означает, что в нотации нет логических операторов, поэтому если процесс имеет ветвление и слияние, то их трудно отразить на модели IDEF0. Следующее различие заключается в том, что в исходной нотации информационные объекты являются сущностями, а в целевой – связями. Такие правила трансформации часто заканчиваются ошибкой при разветвлении функций. В нотации сущностями, в ARIS IDEF0 eEPC это организационные связь, идущая к элементы нижней представляются стороне элемента «Функциональный блок», поэтому информацию об исполнителе функции бизнесаналитику необходимо определить вручную. Аналогично этому информационные системы, с помощью которых выполняются некоторые функции, придется определять вручную связью «Механизм» на модели IDEF0. Некоторые документы никак не обрабатываются функцией, а регулируют её выполнение. Однако такие документы являются входными для функции, но в нотации IDEF0 такие регулирующие документы относятся к специальному виду связи «Управление». Поэтому после трансформации бизнес-аналитику необходимо проверить информационные потоки на модели IDEF0 и скорректировать некоторые связи как «Управление». Исходную модель бизнес-процесса «Управление изменениями по проекту», а именно одну из его фаз «Оценка воздействия предложения по внесению изменений» в нотации ARIS eEPC (Бизнес-аналитик) можно посмотреть на рис. 4.3. Результат трансформации в нотацию IDEF0 представлен на рис. 4.11. Из рисунка видно, что модель необходимо доопределить вручную, чтобы получить полноценную модель рассматриваемого бизнес-процесса (см. рис.4.12). 85 86 Рисунок 4.11 Результат трансформации модели бизнес-процесса «Оценка воздействия предложения по внесению изменений» в нотацию IDEF0 87 Рисунок 4.12 Доопределение модели бизнес-процесса «Оценка воздействия предложения по внесению изменений» 4.5 Выводы по главе В 4 главе были разработаны следующие правила трансформации (см. приложение D): 1) ARIS VAD (нотация Подрядчика) – ARIS VAD (нотация бизнесаналитика); 2) ARIS eEPC (нотация Подрядчика) – ARIS eEPC (нотация бизнесаналитика); 3) ARIS eEPC (нотация бизнес-аналитика) – AnyLogic; 4) UML Activity Diagram – ARIS eEPC (нотация бизнес-аналитика); 5) ARIS VAD (нотация бизнес-аналитика) – IDEF0; 6) ARIS eEPC (нотация бизнес-аналитика) – IDEF0. После реализации данных правил необходимо оценить результат трансформации с точки зрения потерь некоторых сущностей и связей моделей (см. таблица 4.2). Определим главные критерии для оценки: 1. Функциональная структура процесса. Необходимо чтобы целевая модель сохранила все функции исходной модели. 2. Логическая структура. После трансформации модель должна сохранить логику выполнения функций. 3. Организационная структура. Ответственность за выполнения функций лежит на организационных элементах, участвующих в бизнес-процессе, поэтому такая информация должна передаваться на целевую модель. 4. Информационный поток. После трансформации должен отслеживаться поток входных данные и результатов выполнения функций. Трансформация ARIS VAD (нотация Подрядчика) – ARIS VAD (нотация бизнесаналитика) ARIS eEPC (нотация Подрядчика) – ARIS eEPC (нотация Функциональная структура Таблица 2.2 Оценка реализации трансформации моделей Логическая Организационная Информационный структура структура поток Полностью сохранена на целевой модели Полностью сохранена на целевой модели Не требуется Полностью сохранен на целевой модели Полностью сохранена на целевой модели Полностью сохранена на целевой модели Полностью сохранена на целевой модели Полностью сохранен на целевой модели 88 Трансформация Функциональная структура Логическая структура Полностью сохранена на целевой модели Частично сохранен на целевой модели Полностью сохранена на целевой модели Не требуется Полностью сохранена на целевой модели Полностью сохранена на целевой модели Полностью сохранена на целевой модели Полностью сохранен на целевой модели Полностью сохранена на целевой модели Полностью сохранена на целевой модели Необходимо полностью доопределить на целевой модели Не сохранен на целевой модели Полностью сохранена на целевой модели Не сохранена на целевой модели Не сохранена на целевой модели Частично сохранен на целевой модели бизнесаналитика) ARIS eEPC (нотация бизнесаналитика) – AnyLogic UML Activity Diagram – ARIS eEPC (нотация бизнесаналитика) ARIS VAD (нотация бизнесаналитика) – IDEF0 ARIS eEPC (нотация бизнесаналитика) – IDEF0 Организационная Информационный структура поток Из таблицы видно, что после реализации всех правил трансформации целевые модели сохранили функциональную структуру. Большинство целевых моделей содержат после трансформации элементы организационной структуры, такие элементы необходимо доопределить только на моделях в нотации IDEF0. Это связано с тем, что в исходной нотации организационные единицы являются сущностями, а в целевой – связями. После трансформации модели в нотации IDEF0 практически не содержат элементов информационного потока между функциями по той же причине что и в предыдущем случае. Наиболее проблематично на целевой модели передается логическая последовательность бизнес-процесса, это объясняется тем, что целевая и исходная нотации относятся к разным аспектам моделирования, который может учитывать временной фактор, а может, и нет. В целом реализацию правил трансформации на рассмотренных примерах можно считать удачной, так как целевая модель содержит необходимую основу для корректировки бизнес-аналитиком. Рассмотрим временные затраты на разработку правил трансформаций (см. таблицу 4.3). 89 Правило трансформации ARIS VAD (нотация Подрядчика) – ARIS VAD (нотация бизнесаналитика) ARIS eEPC (нотация Подрядчика) – ARIS eEPC (нотация бизнесаналитика) ARIS eEPC (нотация бизнес-аналитика) – AnyLogic; UML Activity Diagram – ARIS eEPC (нотация бизнес-аналитика); ARIS VAD (нотация бизнес-аналитика) – IDEF0 ARIS eEPC (нотация бизнес-аналитика) – IDEF0 Таблица 4.3 Временные затраты на разработку правил трансформаций Общее время на Время на разработку Время на отладку разработку правила правила правила трансформации трансформации трансформации 00:30:00 00:10:00 00:40:00 00:45:00 00:15:00 01:00:00 04:30:00 01:20:00 05:50:00 02:30:00 00:30:00 03:00:00 00:15:00 00:15:00 00:30:00 00:15:00 00:15:00 00:30:00 Несмотря на то, что процесс разработки правил трансформации достаточно трудоемкий и требует времени, все правила разрабатываются только один раз, а затем используются бизнес-аналитиком многократно. Следует отметить, что при необходимости в процессе работы бизнес-аналитик сам может дополнить правило, включив в него другую конструкцию. Также если аналитику требуется использовать другие нотации для моделирования, он может создать необходимые метамодели и разработать для них правила трансформации. Рассмотрим временные затраты на ручную разработку и трансформацию фрагментов рассмотренных бизнес-процессов (см. таблицу 4.4). Из таблицы видно, что автоматическая трансформация моделей из одной нотации в другую позволяет существенно снизить временные затраты при моделировании бизнес-процессов, что было доказано на примерах рассмотренных бизнес-процессов. Данные временные характеристики были получены в процессе моделирования ранее выбранных бизнес-процессов, точнее их фрагментов. Таким образом, можно сделать вывод о том, что трансформация позволит сократить временные затраты на моделирование полноразмерных бизнес-процессов. 90 91 0:17:00 0:10:00 0:18:00 Оценка воздействия предложения по внесению изменений Обработка заявок Конфигурация интегрированной модели Управление изменениями по проекту Оценка воздействия предложения по внесению изменений Управление изменениями по проектам холдинга Управление изменениями по проектам холдинга Техническая поддержка сотрудников холдинга Интегрированное моделирование Активов холдинга Управление изменениями по проектам холдинга Управление изменениями по проектам холдинга 0:23:00 0:21:00 0:10:00 Управление изменениями по проекту Бизнес-процесс Время на ручную разработку модели Модель бизнеспроцесса ARIS eEPC (нотация бизнес-аналитика) – IDEF0 ARIS VAD (нотация бизнес-аналитика) – IDEF0 UML Activity Diagram – ARIS eEPC (нотация бизнес-аналитика) ARIS eEPC (нотация бизнес-аналитика) – AnyLogic ARIS eEPC (нотация Подрядчика) – ARIS eEPC (нотация бизнесаналитика) ARIS VAD (нотация Подрядчика) – ARIS VAD (нотация бизнесаналитика) Правило трансформации 0:00:02 0:00:01 0:00:02 0:00:02 0:00:02 0:00:01 0:05:00 0:02:00 0:02:00 0:03:00 0:02:00 0:05:02 0:02:01 0:02:02 0:03:02 0:02:02 Не требуется 0:00:01 0:12:58 0:07:59 0:20:58 0:17:58 0:14:58 0:09:59 Экономия Время на Время на времени за счет Общее реализацию доопределение трансформации время трансформации модели Трансформация Таблица 4.4 Временные затраты на разработку моделей бизнес-процессов Заключение Основные результаты, полученные в данном исследовании: 1. Проанализирована деятельность холдинга в области моделирования бизнес-процессов. В этой части выделены основные задачи холдинга: a. построение моделей бизнес-процессов «Как есть» для их последующего анализа, с целью разработки моделей «Как должно быть»; b. построение моделей бизнес-процессов для разработки функциональных требований к автоматизирующей системе; c. построение моделей бизнес-процессов для сертификации по стандартам ISO 9000 и ISO 9001. Для решения обозначенных задач аналитику требуется использовать разные нотации моделирования бизнес-процессов и задействовать внешнюю систему для их анализа. С этим связана проблема большой трудоемкости работы бизнес-аналитика, который заново разрабатывает модели в необходимых нотациях. 2. Для решения данной проблемы разработан и описан подход, основанный на переиспользовании уже разработанных моделей, для которых один раз разрабатываются правила трансформации, используемые многократно. В качестве инструментального средства выбрана языковая платформа MetaLanguage, которая не ограничивает аналитика в наборе нотаций, а также предоставляет возможность трансформации моделей одной нотации в другую посредством визуального редактора. 3. Разработаны метамодели языков описания и анализа бизнес-процессов: ARIS VAD, ARIS eEPC, UML Activity Diagram, IDEF0 и AnyLogic. На основании данных метамоделей разработаны исходные модели бизнеспроцессов для последующей трансформации. 4. Для решения обозначенных задач холдинга разработаны правила трансформации моделей одной графической нотации в другую. Разработанные правила были реализованы удачно, так как целевые 92 модели сохранили необходимую основу для их доработки бизнесаналитиком. 5. Трансформация осуществлялась на примере моделей следующих бизнеспроцессов «Управление «Интегрированное изменениями моделирование по проектам Активов холдинга», холдинга», а также на основе «Техническая поддержка сотрудников холдинга». Дальнейшее развитие работы может онтологического подхода. 93 быть направлено Библиографический список 1. Самуйлов К.Е. Основы формальных методов описания бизнес-процессов: учеб. пособие для студентов бакалавриата, обучающихся по направлениям 010300 «Математика. Компьютерные науки», 010400 «Информационные технологии» или 010500 «Прикладная математика и информатика» / К.Е. Самуйлов, Н.В. Серебренникова, А.В. Чукарин, Н.В. Яркина – М.: РУДН, 2008. – 130 с. 2. Грекул В.И. Проектирование информационных систем: учеб. пособие для студентов, обучающихся по специальностям в области ИТ / В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина; под ред. И. Черкесова – М.: Открытые системы, 2005. – 303 с. 3. Кулябов Д.С. Введение в формальные методы описания бизнеспроцессов: учеб. пособие для студентов эконом. вузов / Д.С. Кулябов., А. В Королькова – М.: РУДН, 2008. – 173 с. 4. Маклаков С., Репин В. ARIS Toolset/BPwin: выбор за аналитиком / КомпьютерПресс. М: 2002.-№1. 5. Бабкин Э.А., Князькин В.П., Шиткова М.С. Сравнительный анализ языковых средств, применяемых в методологиях бизнес-моделирования / Бизнес-Информатика №3(13). М: 2010 г с.31-41. 6. Сухов А.О. Методы трансформации визуальных моделей / Материалы III международной научно-технической конференции «Технологии разработки информационных систем ТРИС–2012». Таганрог: Изд-во Технол. инст. ЮФУ, 2012. – Т. 1. – с. 120-124. 7. Лядова Л.Н., Серый А.П., Сухов А.О. Подходы к описанию вертикальных и горизонтальных трансформаций метамоделей / Математика программных систем: межвуз. сб. науч. ст. Пермь: Изд-во Перм. гос. нац. исслед. ун-та, 2012. – Вып. 9. – с. 33-49. 8. Серый А.П., Сухов А.О. Использование графовых грамматик для трансформации моделей / Материалы конференции «CSEDays 2012». Екатеринбург: Изд-во Урал. ун-та, 2012. – с. 48-55. 94 9. Доррер М.Г., Ланцев Е.А. Агентное имитационное моделирование бизнес-процессов в нотации EPC / Научно-технический вестник информационных технологий, механики и оптики. М: 2013. № 3. с. 86-92. 10. Сухов А.О. Разработка инструментальных средств создания визуальных предметно-ориентированных языков: дис. канд. физ. мат. наук: 05.13.11/ Перм. гос. нац. исслед. ун-т. – Пермь, 2013. – 256 с. 11. Одинцов И.О. Профессиональное программирование. Системный подход / СПб.: Изд-во БХВ-Петербург, 2002. – 514 с. 12. Калянов Г. Н. Консалтинг: от бизнес-стратегии к корпоративной информационно-управляющей системе / издание 2-е. М.: Горячая линия – Телеком, 2011. – 210 с. 13. Репин В. В. Процессный подход к управлению. Моделирование бизнеспроцессов / Репин В.В, Елиферов В.Г. – М.: Манн, Иванов и Фербер, 2013. – 544 с. 14. Тумай К. Имитационное КОНСАЛТИНГ. РУ моделирование [Электронный ресурс] бизнес-процессов [Режим / доступа: http://consulting.ru/econs_art_997892185] [Проверено: 17.05.2015]. 15. Строгалев В.П., Толкачева И.О. Имитационное моделирование / Учеб. пособие. – М.: Изд-во МГТУ им. Н.Э. Баумана, 2008. – 280 с. 16. Пинаева А. Имитационное моделирование: оптимизируем бизнеспроцессы / Система бизнес-моделирования [Электронный ресурс]. [Режим доступа: http://www.businessstudio.ru/procedures/business/immodel] [Проверено: 17.05.2015]. 17. Томашевский В.Н. Имитационное моделирование в среде GPSS / В.Н. Томашевский, Е.Г. Жданова – М.: Бестселлер, 2003. – 416 с. 18. Лядова Л.Н. Имитационное моделирование: Методические указания по курсу «Системное и прикладное программное обеспечение» / Перм. ун-т; Сост. Л.Н. Лядова. – Пермь, 2003. – 60 с. 19. Алтаев А.А. Имитационное моделирование: Методическое пособие по дисциплине «Компьютерное моделирование» / Изд-во ВСГТУ; Сост. А.А Алтаев. – Улан Удэ, 2001. – 122 с. 95 20. Карпов Ю. Г. Имитационное моделирование систем. Введение в моделирование с AnyLogic 5 / Ю.Г. Карпов – СПб: БХВ-Петербург, 2006. – 400 с. 21. Монахов А.Д. К вопросу об использовании имитационной среды Anylogic для оценки эффективности вычислительных систем / Науковедение. Интернет-журнал [Электронный ресурс]. [Режим доступа: http://naukovedenie.ru/?id=168/] [Проверено: 17.05.2015]. 22. Худорожков Р. Модели бывают разные / Liberty Grant [Электронный ресурс]. [Режим доступа: www.libertygrant.co.uk/portal/?p=1083] [Проверено: 17.05.2015]. 23. Девятков В.В. Развитие методологии имитационных исследований сложных экономических система: Дис. докт. экон. наук: 08.00.13 / Финансовый университет при Правительстве Российской Федерации. М., 2014. – 344 с. 24. Орлова А.А. Дисперсионный анализ факторов при имитационном моделировании сложных систем / Молодежный научно-технический вестник. М: Изд-во ФГБОУ ВПО МГТУ им. Н.Э. Баумана, 2013. – Вып. 11. – с. 35-45. 25. Серый А.П., Сухов А.О. Использование графовых грамматик для трансформации моделей / Материалы конференции «CSEDays 2012». Екатеринбург: Изд-во Урал. ун-та, 2012. – с. 48-55. 26. Хайдаров К.А. Теория и практика обработки информации / Частное Боровское исследовательское учреждение [Электронный ресурс]. технологий по внедрению [Режим новых доступа: http://bourabai.ru/tpoi/index.htm] [Проверено: 17.05.2015]. 27. Клебанов Б.И. Методические указания к лабораторным работам по CASE пакету ARIS Toolset для направления 654600 – Информатика и вычислительная техника специальности 220200 – автоматизированные системы обработки информации и управления / Урал. Тех. Ун-т; Сост. Б.И. Клебанов. – Екатеринбург, 2002. – 29 с. 28. Business Studio Документация. Разработка системы менеджмента качества / Business Studio [Электронный ресурс] [Режим доступа: http://bu 96 sinessstudio.ru/wiki/docs/current/doku.php/ru/qms/qms] [Проверено: 17.05.2015]. 29. Kleppe A., Warmer J., Bast W. MDA Explained. The Model Driven Architecture: Practice and Promise. Reading: Addison-Wesley, 2003. – 170 p. 97 Рисунок A.1 Основные фазы процесса моделирования и анализа бизнес-процессов холдинга Приложение A. Моделирование бизнес-процессов холдинга «Как есть» 98 99 Рисунок A.2 Процесс разработки проекта моделей подрядчиком Приложение B. Обзор средств моделирования и анализа бизнес-процессов Для построения моделей бизнес-процессов представлен широкий набор программных средств, среди которых можно выделить особый класс программ – CASE средства. Под CASE средством будем понимать набор инструментов и методов программной инженерии для проектирования программного обеспечения, который помогает обеспечить высокое качество программ, отсутствие ошибок и простоту в обслуживании программных продуктов [11]. CASE средства первого поколения ориентированы непосредственно на системных бизнес-аналитиков и проектировщиков и поддерживали графические модели, проектирование спецификаций, экранные редакторы и словари данных. Они не были предназначены для поддержки полного жизненного цикла [12]. Второе поколение CASE-средств характеризуется созданием интегрированной среды комплексной автоматизации процесса проектирование ИС. Они имеют уже программное, лингвистическое, математическое, информационное и организационное обеспечение, предоставляя инструменты для разработки архитектуры системы. Современные CASE средства обеспечивают интегрированную среду автоматизированного проектирования ИС и поддерживают весь жизненный цикл. При этом они используются не только для производства программных систем, но и как инструмент решения исследовательских и проектных задач на начальных этапах разработки. Хочется отметить, что среди современных средств моделирования бизнеспроцессов нет четкой границы между CASE средствами и специальными программными продуктами, направленными на моделирование бизнес-процессов. Сейчас некоторые программные продукты называют CASE инструментариями, что может быть объяснено универсальностью программных продуктов и стремлением сделать их многоцелевыми. Несмотря на размытость границ между понятиями, выделим программные продукты, являющиеся инструментами непосредственно программной инженерии – CASE средства и программные моделирования и анализа бизнес-процессов (см. таблица B.1). 100 продукты Формирование документации, отчетов Система моделирование общего назначения Имитационное моделирование - Нотации ARIS, UML, BPMN, BPEL и др. в т.ч. xml, JPEG Image File xml, bpmn, xpdl, vsd, png, jpg, bmp, svg в т.ч. xml, JPEG xml, bpmn, xpdl, Image File vsd - - BPMN В Java апплет отдельное приложение Java Модели Vensim (.mdl) - - Нотация AnyLogic. Диаграмма активности gps, sim, gpr, txt, htm gps - - - Встроенный Можно генератор отчетов, Можно выгрузить в Отчетность в документация Можно выгрузить в выгрузить в формате Word, формате RTF, может быть текстовом формате формате Word и PDF, как web совместимым с выгружена в или формате Excel Excel файл, в формате Microsoft Word формате Word b SharePoint.и wiki Excel bp1, idl, xml Формат импорта моделей - - IDEF0, IDEF3, DFD bp1, idl, xml Для документировани я проектов интегрируется со средством SoDA GPSS World AnyLogic Функционально- Имитационный Системная динамика, Имитационный Имитационное стоимостной, анализ, агентное, дискретноанализ, анализ моделирование имитационный стоимостной событийное «Что если» СМО анализ анализ и др. моделирование AllFusion Process Bizagi BPM ARIS Platform Modeler Suite Моделирование, Моделирование, оптимизация, Автоматизация анализ, и публикация БП БП оптимизация БП и управление IТархитектурой Формат экспорта моделей - UML диаграммы - UML диаграммы Поддержка нотаций - - - Анализ БП CASE Caseberry - CASE Применение Создание пользовательских диаграмм Трансформация моделей IBM Rational Rose Enterprise Критерий сравнения Таблица B.1Характеристика средств моделирования и анализа бизнес-процессов + 101 На основании представленной таблицы можно судить о достаточно широких возможностях, которые предоставляют современные программные продукты. Однако описанные инструменты не обеспечивают возможность создания пользовательских нотаций, фактически каждый программный продукт имеет ограниченный набор нотаций, но иногда бизнес-аналитику могут потребоваться строить модели и в других нотациях. Стоит отметить, что ни одна система не содержит полный набор необходимых нотаций для проведения исследовательской работы, таких как ARIS VAD, ARIS eEPC, IDEF0, IDEF3 и AnyLogic. Также существенным недостатком выделенных инструментов является отсутствие возможности трансформации моделей из одной нотации в другую. Предметно-ориентированные языки и языковые инструментарии (DSM платформы) снимают указанные ограничения, позволяя разрабатывать языки широкого спектра областей. Рассмотрим характеристику DSM платформ. Таблица B.2 Обзор DSM платформ Критерий сравнения Создание DSL для широкого спектра областей Средство описания абстрактного синтаксиса Возможность модификации метаязыка Возможность многоуровневого моделирования Изменение описания метамодели без перегенерации кода Наличие «ручной» доработки DSL Возможность горизонтальной трансформации MetaEdit+ DSL Tools, State Machine Designer Eclipse GMF QReal MetaLangua ge + + + + + GORP MOF Encore MOF + + - - - + + - - - + + - - - + - + + + + - - С помощью плагинов - + Данный обзор полностью основан на результатах диссертационного исследования [10]. Стоит отметить, что такие платформы как DSL Tools и Eclipse 102 GMF сложны в понимании, их интерфейс затрудняет изучение инструментариев непрофессиональными программистами. Следующим важным ограничением является возможность изменения описания метамодели без перегенерации кода. Такие платформы как DSL Tools, Eclipse GMF и QReal не позволяют пользователю производить изменение описания языка во время создания моделей, приходится перезапускать системы, что усложняет работу специалиста. Осуществление горизонтальных трансформаций – одно из главных требований к функциональности DSM платформ в данной работе. Ряд средств вообще не позволяет их реализовывать, Eclipse GMF предоставляет возможность трансформации моделей, однако с помощью плагинов. Такие трансформации не являются визуальными, а требуют от специалиста навыков программирования. Как видно из таблицы B.2 платформа MetaLanguage удовлетворяет всем представленным требованиям. Платформа понятна для разных категорий пользователей, поддерживает в согласованном состоянии описаний метамоделей и моделей предметной области при внесении изменений в метаязык и/или метамодель. Очень важно, что платформа MetaLanguage позволяет трансформации моделей, как между различными уровнями иерархии, так и внутри одного уровня, между различными языками моделирования [19]. 103 Приложение C. Блок Описание языков имитационного моделирования Описание блока Параметр A GENERATE B Вводит транзакты в модель, посылая их в следующий по порядку блок C D E QUENE SEIZE RELEASE A Помещает транзакт в конец очереди B Предназначен для занятия одноканального устройства Предназначен для освобождения одноканального устройства A Таблица C.1 Язык GPSS Описание параметра Среднее значение интервала времени; Разброс или модификатор среднего значения Время появления первого транзакта Общее число генерируемых транзактов Уровень приоритета каждого транзакта Номер очереди (числовое или символьное имя очереди) Число добавляемых к очереди элементов Обозначает имя устройства, занимаемого транзактом Обозначает имя устройства, освобождаемого транзактом A Номер, имя очереди Число удаляемых из очереди элементов Среднее время задержки Разброс относительно среднего значения A DEPART Удаляет транзакт из очереди ADVANCE Задерживает транзакт TERMINATE Удаляет транзакт, вычитая величину A из содержимого счетчика завершений B A B Величина, вычитаемая из счетчика завершений A Блок Описание блока Параметр Source Задает интенсивность поступления заявок Интенсивность поступления заявок Sink Уничтожает поступившие заявки - ResourcePool Задает набор ресурсов, участвующих в процессе Тип Количество Скорость Service Service Захватывает заданное количество ресурсов, задерживает их, а затем освобождает Захватывает заданное количество ресурсов, задерживает их, а затем освобождает Тип ресурсов Количество ресурсов Вместимость очереди Время задержки 104 Таблица C.2 Язык AnyLogic Описание параметра Количество заявок, поступающих в единицу времени Может быть движущимся, статическим или переносным Задает количество доступных ресурсов Задает скорость ресурса Название ресурса, участвующего при выполнении Задает количество задействованных ресурсов Задает вместимость очереди Задает время выполнения функции в соответствие с некоторым распределением Блок Описание блока SelectOutputIn С помощью элементов можно задать разветвление процесса в соответствие с заданной вероятностью SelectOutputOut Параметр Заданная вероятность в соответствие с блоком SelectOutputOut Блок SelectOutputIn Вероятность 105 Описание параметра Вероятность, которая задается бизнес-аналитиком Название блока SelectOutputIn, к которому относится блок SelectOutputOut Вероятность, которая задается бизнес-аналитиком Приложение D. Правила трансформации моделей Таблица D.1 Правила трансформации ARIS VAD (Подрядчик) – ARIS VAD (Бизнес-аналитик) Название правила Левая часть правила Правая часть правила Сущность БизнесПроцесс_Биз несПроцесс БизнесПроцесс БизнесПроцесс Цель_Цель Цель Цель КПД_КПД КПД КПД Результат_Результа т Результат Результат Подпроцесс_Подпр оцесс Подпроцесс Подпроцесс Связь БизнесПроцессБиз несПроцесс_ БизнесПроцесс_Биз несПроцесс ЦельБизнесПроцес с_ ЦельБизнесПроцес с КПДБизнесПроцес с_ КПДБизнесПроцес с БизнесПроцессРезу льтат_ БизнесПроцессРезу льтат ПодпроцессПодпро цесс_ ПодпроцессПодпро цесс СостоитИз_Состои тИз2 БизнесПроцессБизнесПроцесс ПредшественникПоследователь1 ЦельБизнесПроцесс ЦельБизнесПроцесс КПДБизнесПроцесс КПДБизнесПроцесс БизнесПроцессРезультат БизнесПроцессРезультат ПодпроцессПодпроцесс ПредшественникПоследователь2 СостоитИз СостоитИз2 106 Таблица D.2 Правила трансформации ARIS eEPC (Подрядчик) – ARIS eEPC (Бизнес-аналитик) Название правила Левая часть правила Правая часть правила Сущность Функция_Функция Интерфейс_СмежныйИнтерф ейс Оператор_Оператор ОрганизационнаяЕдиница_Ро ль Функция Интерфейс Оператор Организационная Единица Функция СмежныйИнтерфе йс Оператор Роль СмежноеСобыти е Событие_СмежноеСобытие Событие Документ_Документ Документ СистемныйДокумент_Шабло н СистемныйДокум ент Шаблон ИСКорпоративногоМасштаба _ИСКорпоративногоМасштаб а ИСКорпорати вногоМасшта ба ИСКорпоративного Масштаба МодульИС_МодульИС МодульИС МодульИС Документ Связь ФункцияФункция_ФункцияФ ункция ИнтерфейсФункция_Интерфе ФункцияФункция ИнтерфейсФункция 107 ФункцияФункция ИнтерфейсФункция Название правила йсФункция ИнтерфейсОператор_Интерфе йсОператор ИнтерфейсСобытие_Смежное СобытиеИнтерфейс ОператорФункция_ФункцияО ператор ОбъектФункция_ОбъектФунк ция Левая часть правила ИСФункция_ИСФункция ИСФункция СобытиеФункция_ФункцияС межноеСобытие ОператорОператор_Оператор Оператор ИнтерфейсОператор ИнтерфейсСобытие ОператорФункция ОбъектФункция СобытиеФункция ОператорОператор Правая часть правила ИнтерфейсОператор СмежноеСобытиеИнтерфейс ФункцияОператор ОбъектФункция ИСФункция ФункцияСмежноеСобытие ОператорОператор Таблица D.3 Правила трансформации UML Activity Diagram – ARIS eEPC (Бизнес-аналитик) Название правила Левая часть правила Правая часть правила Сущность Роль НазваниеДорожки_Роль НачальныйУзел_НачальноеС обытие НачальныйУзел НачальноеСобытие КонечныйУзел КонечноеСобытие Активность_Функция Активность Функция Ветвление_Оператор Ветвление Оператор Объект_Шаблон Объект Шаблон Синхронизатор_Оператор Синхронизатор КонечныйУзел_КонечноеСоб ытие Связь 108 Оператор Название правила НачальныйУзелАктивность_ НачальноеСобытиеФункция АктивностьКонечныйУзел_Ф ункцияКонечноеСобытие АктивностьАктивность_Функ цияФункция АктивностьВетвление_Функц ияОператор ВетвлениеАктивность_Смежн оеСобытие Левая часть правила НачальныйУзелАктивность АктивностьКонечныйУзел Правая часть правила НачальноеСобытиеФункция ФункцияКонечноеСобытие АктивностьАктивность ФункцияФункция АктивностьВетвление ФункцияОператор ВетвлениеАктивность СмежноеСобыти е ОбъектАктивность_Функция Объект НачальныйУзелСинхронмзато р_НачальноеСобытиеОперато р СинхронизаторСинхронизато р_ОператорОператор ОбъектАктивность ФункцияОбъект НачальныйУзелСинхронмзатор НачальноеСобытиеОператор СинхронизаторСинхронизатор ОператорОператор ВетвлениеСинхронизатор_См ежноеСобытие ВетвлениеСинхронизатор СмежноеСобыти е СинхронизаторАктивность_С межноеСобытие СинхронизаторАктивность СмежноеСобыти е АктивностьСинхронизатор_Ф ункцияОператор АктивностьСинхронизатор ВетвлениеКонечныйУзел_Ко нечныйУзел ВетвлениеКонечныйУзел ФункцияОператор КонечноеСобытие Таблица D.4 Правила трансформации ARIS VAD (Бизнес-аналитик) – IDEF0 Название правила Левая часть правила Правая часть правила Сущность БизнесПроцесс_Функциональ ныйБлок БизнесПроцесс Связь ПредшественникПоследовате ль1_ФункциональныйБлокФу нкциональныйБлок ПредшественникПоследователь1 109 ФункциональныйБлокФункциона льныйБлок Таблица D.5 Правила трансформации ARIS eEPC (Бизнес-аналитик) – IDEF0 Название правила Левая часть правила Правая часть правила Сущность Функция_ФункциональныйБл ок Функция Связь Объект_ФункциональныйБло к ФункциональныйБлок Объект ФункциональныйБлокФункциона льныйБлок ФункцияФункция_ФункцияФ ункция ФункцияФункция ФункциональныйБлокФункциона льныйБлок Таблица D.6 Правила трансформации ARIS eEPC (Бизнес-аналитик) – AnyLogic Название правила Левая часть правила Правая часть правила Сущность НачальноеСобытие_Source НачальноеСобытие КонечноеСобытие_Sink КонечноеСобытие Функция_Service Функция Роль_ResourcePool Роль Оператор_SelectOutputIn Оператор СмежноеСобытие_SelectOutp utOut СмежноеСобыти е Связь ФункцияФункция_ServiceServ ice НачальноеСобытиеФункция_ SourceService ФункцияКонечноеСобытие_S erviceSink НачальноеСобытиеОператор_ SourceSelectOutputIn ФункцияФункция НачальноеСобытиеФункция ФункцияКонечноеСобытие НачальноеСобытиеОператор 110 ServiceService SourceService ServiceSink SourceSelectOutputIn Рисунок E.1 Модель бизнес-процесса «Управление изменениями по проекту» в нотации ARIS VAD (Подрядчик) Приложение E. Исходные модели бизнес-процессов 111 112 Рисунок E.2 Часть 1 Модель бизнес-процесса «Оценка воздействия предложения по внесению изменений» в нотации ARIS eEPC (Подрядчик) 113 Рисунок E.2.Часть 2 Модель бизнес-процесса «Оценка воздействия предложения по внесению изменений» в нотации ARIS eEPC (Подрядчик) 114 Рисунок E.3 Модель бизнес-процесса «Обработка заявок» в нотации ARIS eEPC (Бизнес-аналитик) 115 Рисунок E.4 Модель бизнес-процесса «Конфигурация интегрированной модели» в нотации UML Activity Diagram
