Aris методология моделирования бизнес процессов

Время на прочтение
7 мин

Количество просмотров 10K

Пост о возможностях разработки в ARIS, а не о заправках, как многие подумали

Disclaimer

Эта статья не претендует на то, чтобы быть учебным пособием или каким-то кратким введением в методологию или линейку продуктов ARIS. Она написана мной на основании опыта внедрения и использования линейки этих продуктов в крупных российских компаниях, поэтому является субъективным взглядом и частным мнением. На данный момент я никак не связан с Software AG (вендор ARIS), за исключением того, что начинал свою карьеру в московском офисе этой компании (а точнее в IDS Scheer, которую она поглотила) более 10 лет назад. Сразу хочу сказать, что статья — взгляд с точки зрения технического специалиста, а не методолога / процессного консультанта / дизайнера бизнес-процессов. Аудитория статьи — люди, которые хотят понять что такое ARIS и как, где и зачем его можно использовать. Очевидно, что есть куча маркетинговых материалов, но возможно для кого-то будет интересна практическая сторона вопроса.

Введение (BPM и другой BPM)

Когда речь заходит о бизнес-процессах, либо об управлении бизнес-процессами, то в голове сразу возникает аббревиатура BPM (Business Process Management). И вот здесь начинается путаница, которая многих сбивает с толку с самого начала. Дело в том, что BPM также можно расшифровать как Business Process Modeling (или Modelling, кому как больше нравится). И в этом контексте ARIS — это, конечно же, система моделирования бизнес-процессов.

То есть нужно изначально понимать, что назначение этой платформы — моделирование, хранения и обработка статичных моделей бизнес-процессов. Да, с ними можно осуществлять различные действия: рассчитывать стоимость процессов, проводить реинжиниринг, генерировать на основании этих моделей должностные инструкции и регламенты процессов, проводить симуляции работы этих процессов (математико-статистическими методами, некоторый упрощенный аналог известной GPSS c понятным GUI). Но нельзя делать самое главное — исполнять эти процессы, то есть делать то, что многие изначально хотят от этой системы, видя аббревиатуру BPM и ассоциируя ее с BPM-системами, такими как Pega BPM, IBM BPM, Camunda, Activiti и т.д.

Почему возникает такая путаница именно с ARIS? Дело сразу в нескольких вещах. Во-первых, стоимость системы достаточно высока, поэтому она “по умолчанию” должна “всё уметь” (так думают те, кто принимает решение о ее покупке). Во-вторых, эта платформа представлена очень большим набором систем “на все случаи жизни”. От системы моделирования, состоящей из серверной и клиентской частей, симуляции процессов (ARIS Business Simulator), до систем управления процессом изменения и согласования моделей (ARIS Process Governance), системы контроллинга (ARIS Process Performance Manager), системы управления рисками (ARIS Risk & Compliance Manager).

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

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

Почему все до сих пор используют ARIS

Если сравнить ARIS и другие системы подобного класса, то это сравнение далеко не всегда будет в его пользу, поскольку он имеет достаточно высокие системные требования, цену, порог входа для пользователей (обучение и т.д.).

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

1. Исторически это была первая система подобного рода (первая версия появилась в 1992 году), да еще имеющая под собой основание в виде одноименной методологии, созданной А-В. Шеером.

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

3. Широкий набор нотаций моделирования

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

5. Интеграция с SAP “из коробки”.

6. Большие возможности кастомизации, причем не только силами вендора, но и на месте штатными сотрудниками.

Я бы хотел подробнее остановиться на последнем пункте: разработке отчетов, макросов, интеграционных решениях и объектной модели ARIS. Поскольку, на мой взгляд, это то конкурентное преимущество, которое и позволило системе ARIS просуществовать почти 30 лет.

Интеграция, кастомизация, скрипты

Вообще идея иметь внутреннюю объектную модель, среду разработки и язык программирования — не новая. Тот же MS Office поддерживает макросы с незапамятных времен, что упрощает автоматизацию многих рутинных операций.

В случае с ARIS наличие такого инструмента — неоспоримое конкурентное преимущество. Стоит отметить, что он присутствует не “для галочки”, а действительно эффективно функционирует, позволяя работать с данными и интегрировать ARIS с чем угодно. В статье не стоит цель сравнения с другими средствами моделирования, поэтому этим заниматься не будем, а сосредоточимся на возможностях системы.

Среда разработки

Итак в ARIS встроена среда разработки, позволяющая писать скрипты на JavaScript (стандарт ECMAScript 5), а также использовать подключаемые библиотеки на Java (в т.ч. и свои собственные), что открывает безграничные возможности для кастомизации системы и автоматизации операций.

Как видно на скриншоте, среда разработки немного устарела. По сравнению с новыми IDE здесь сложно найти все те современные удобства, к которым мы уже так привыкли. Нет даже возможностей версионирования, хотя накрутить их поверх с помощью “костылей и велосипедов” вполне возможно. В общем для конца 90-х — начала 2000-х — вполне приемлемо. Даже есть возможность real-time дебага с точками останова. Тем не менее все не так ужасно, как кажется на первый взгляд: есть автодополнение, есть подсветка кода (не совсем уж блокнот) и есть возможность откладки, как я уже упомянул. Этого вполне достаточно, чтобы разрабатывать и автоматизировать, если присутствует потребность и желание.

Объектная модель

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

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

Для работы с объектными моделями в системе ARIS существуют несколько типов скриптов, с помощью которых можно обрабатывать данные, в частности, макросы (Macros) и отчеты (Reports). О них и пойдет речь далее.

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

Макросы

Макросы в контексте ARIS — это вид скриптов, позволяющий работать с клиентской частью приложения. Основной фичей макросов является возможность запускать их по триггерам клиента, таким как сохранение, изменение моделей, создание объектов, связей и т.д. Но при этом макросы работают со своей объектной моделью, привязанной к клиенту, и не имеют прямого доступа к данным, хранящимся на серверной части. Для решения этой проблемы используется workaround в виде вызова отчета (Report) из макроса, что значительно расширяет возможности последнего.

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

Отчеты

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

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

Проблемы и интеграционные решения

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

• автоматизация рутинных задач;

• вовлечение сотрудников в использование ARIS;

• понимание и ощущение практической пользы от ARIS.

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

Если планируется использовать ARIS для описания процессов, ролевой структуры, то логично интегрировать ARIS с кадровой системой SAP HR / 1С, для того, чтобы иметь актуальную оргструктуру, а не рисовать ее руками (а это может быть непросто в каком-нибудь холдинге). Это в свою очередь позволит на основании процессов, отрисованных в ARIS, генерировать должностные инструкции, регламенты процессов и выгружать их обратно в кадровые системы, уже в привязке к должностям (через ролевую модель).

Другим примером может быть разработка какой-либо сложной системы с множественными интеграционными точками, когда задействовано большое число аналитиков. В этом случае при моделировании можно воспользоваться механизмом семантических проверок (стандартных либо кастомизированных) для верификации входов-выходов процессов “на стыках”. Если же в дополнение на более низком уровне моделируется интеграция до передаваемых между системами полей, то возможно, к примеру, использовать скрипты для генерации WSDL (если используется SOAP).

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

В заключение хотелось бы добавить, что разработка под ARIS — это крайне узкая область: есть всего один профильный форум ariscommunity.com, куда можно обратиться, если Вы столкнулись с какими-то ограничениями или сложностями. Но тем и интереснее решение задач, когда заранее знаешь, что никто не поможет

Методология ARIS (Architecture of Integrated Information System) необходима для формирования представлений о деятельности предприятия и визуализации процессов в виде графических моделей, удобных для понимания и комплексного анализа.

Основные определения и термины

Нотация ARIS разработана в Германии компанией IDS Scheer AG. Программное обеспечение высоко ценится на рынке инструментальных средств моделирования бизнес-процессов и включает в себя несколько модулей.

Разработка методологии ARIS предусматривает такие цели, как:

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

Основные элементы, используемые в методологии

Среди ключевых элементов выделяют следующие:

• Organizational chart: organizational unit, person, location, role.
• Process landscape: process.
• Business process: event (событие фиксирующее состояние конкретных параметров в определенный временной промежуток), activities (работа, задание или конкретное действие, которое выполняется в течение определенного промежутка времени), role (должность в организации).
• IT system: risks, input and output data, process control via rules («и», «или»), proccess interface (средство связи с рассматриваемым процессом).
• Data model: entity (таблица), attributes (поле таблицы); primary key (первичный ключ таблицы), foreign key (исходный ключ таблицы), relationship (связь между таблицами).
• IT infrastructure: IT system, hardware, network.
• System landscape: IT system, domain.

Документирования процесса

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

• Отсутствие специальных средств моделирования. Как результат — замедление развития организации, спровоцированное неспешною обработкой полученной информации и еще более неторопливым процессом согласования итоговых решений;
• Ручные правки и задержка в подготовке документов. Методология описания в ARIS позволяет создавать готовые текстовые файлы, опираясь на скрипты и специальный встроенный язык SAX Basic. Итоговый документ не будет содержать логических ошибок, в частности при распределении обязанностей между сотрудниками структурных подразделений;
• Генерация отчетности проводится не вручную, а с помощью скриптов. ARIS осуществляет анализ различных моделей и объектов, обрабатывает статистику и выполняет любые иные действия, необходимые для документирования и анализа созданных моделей.

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

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

Концепция архитектуры

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

Нотация на предприятии необходима для:

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

Визуально основная особенность модели заключается в том, что она представлена в виде схемы «сверху вниз», где низшие элементы являются преобладающими. Соединяющий элемент — это стрелка либо разделитель «или»/«и», представляющий альтернативный способ решения проблемы.

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

Графические отметки при передаче нотации базируются в основном не на фигурах, а на цветах:

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

Для чего используется концепция интеграции в нотация ARIS:

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

Подход к описанию изучаемых процессов и его документирование предполагает рассмотрение организации с точки зрения 4 разных моделей:

1. Организационная — подразумевает структуру организации, а именно иерархию подразделений и соответствующих должностей. Модель базируется по принципу «сверху-вниз», при условии, что верхние позиции являются доминирующими. На нижних уровнях графической схемы указывают штатных работников с наименьшей ответственностью или задачи, не требующие установки четких временных промежутков.
2. Функциональная — анализ функций и целей, выполняемых в организации. Работа, задача, начальное или финальное действие — это основа модели: верхние уровни — сам бизнес-процесс, нижние — базовые функции, разделенные на составные элементы.
3. Информационная — распределение информации и задач, необходимых для воплощения системных функций;
4. Модель управления — второстепенный взгляд на реализацию конкретных задач в рамках указанной системы.

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

• Value-added Chain Diagram (диаграмма цепочки процесса);
• extended Event-driven Process Chain — еЕРС (расширенная нотация цепочки процесса; управляемого событиями) и PCD (диаграмма це­почки процесса);
• Organizational Chart (организационная диаграмма);
• Function Tree (дерево функций);
• Product Tree (дерево выпускаемой продукции).

Плюсы и минусы

Преимущества:

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

Недостатки:

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

Пример практического применения

Рассмотрим несколько примеров применения нотации ARIS на практике:

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

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

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

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

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

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

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

ARIS (акроним от англ. Architecture of Integrated Information Systems) — методология и тиражируемый программный продукт для моделирования бизнес-процессов организаций. Продукт и методология принадлежат немецкой компании Software AG как результат поглощения компании IDS Scheer автора методологии Августа-Вильгельма Шеера.

Реализация методологии предполагается с задействованием специализированного программного продукта, обеспечивающего совместную работу над описаниями и диаграммами. Первая версия продукта выпущена в 1994 году. К концу 2000 года продукт был продан в 24 тыс. организаций. С 2009 года поставляется бесплатная версия инструмента — ARIS Express.

Продукт предусматривает серверную часть (ARIS Server) с централизованным репозиторием, хранимым в реляционной СУБД и серию пользовательских инструментов для ведения объектов и подготовки графических представлений (ARIS Toolset в ранних версиях, в версиях 2000-х годов — ARIS Business Architect, ARIS Designer).
К середине 2010-х годов также появилась публично-облачная версия продукта. Доступная по адресу http://www.ariscloud.com/

Продукт ARIS используется в различных проектах по реинжинирингу и оптимизации бизнес-процессов, ИТ-проектах типа внедрения и эксплуатации ERP-систем, в частности, есть проработанное интеграционное решение для SAP R/3.

Одна из иллюстраций структурированного подхода ARIS к проекту реинжиниринга

Программное обеспечение ARIS составляет основу пакета Business Process Analysis Suite корпорации Oracle. Технически инструментарий ARIS достаточно простой для изучения, имеет интуитивно понятный интерфейс. Модели копируются и вставляются в файлы документов (например, формата Microsoft Word) в виде рисунков.

В продуктах ARIS предусмотрена возможность создания сценариев автоматизации составления различных аналитических отчётов, нормативных документов, новых моделей. Каждый сценарий представляет собой подпрограмму, запускаемую в ARIS Business Architect (либо Toolset — более ранней версии) или непосредственно на сервере ARIS. Сценарии пишутся на специальном языке программирования — SAX Basic. Для автоматизированного формирования того или иного отчёта в ARIS сценарии оперируют данными из базы моделей, вычленяя из неё конкретные объекты и модели.

Технология ARIS Script позволяет в автоматическом режиме производить:
формирование нормативных документов на основании моделей ARIS (например, паспорт процесса, регламент процесса);
формирование аналитических отчётов на основании моделей ARIS;
интеграцию ARIS Toolset с другими приложениями и базами данных;
Формирование базы моделей ARIS на основании готовых спецификаций.

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

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

Общий принцип в инструментарии — возможность интеграции моделей разных типов в рамках одного репозитория посредством декомпозиции (детализации) объектов. Таким образом, любую организацию можно описать с помощью иерархии моделей — от обобщения: например, VACD (англ. value added chain diagram) до уровня процедур и ресурсного окружения функций.

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

• eEPC (англ. extended event-driven process chain) — событийная цепочка процессов
• ERM (англ. entity-relationship model) — модель «сущность-связь» для описания структуры данных;
• UML (англ. unified modeling language) — унифицированный объектно-ориентированный язык моделирования

Основные элементы, используемые в нотации ARIS:

1. Organizational chart:
2. Organizational unit;
3. Символ «Person»;
4. Символ «Location»;
5. Группа персон, роль: «Role».
6. Process landscape:
7. Process.
8. Business process:
9. Event — событие фиксирует состояние определенных параметров на определенный момент времени;
10. Activities — работа, определённое действие, выполняемое в течение некоторого промежутка времени;
11. Role — должность в организации;
12. IT system — информационная система, частный случай «хранилища данных»
13. Risks — риски;
14. Input and Output data — отправитель или получатель данных.
15. Process control via rules (and, or, xor) — перекрёсток («и», «или», «исключающее или»);
16. Proccess interface — средство связи с рассматриваемым процессом.
17. Data model:
18. Entity — сущность (таблица);
19. Attributes — атрибут сущности (поле таблицы);
20. Primary Key — уникальный атрибут сущности (первичный ключ таблицы);
21. Foreign Key — внешний ключ таблицы;
22. Relationship — отношения между сущностями (связь между таблицами);
23. IT infrastructure:
24. IT system;
25. Hardware;
26. Network;
27. Network components.
28. System landscape:
29. IT system;
30. Domain.
31. Deneral diagramm (англ.)

Доступные типы моделей в Aris express: organization chart, process landscape, business process, data model, IT infrastructure, system landscape, BPMN diagram, whiteboard, general diagram.

Пример диаграмм:

Organizational chart

Process landscape (VAD)

Business process (EPC (event-driven process chain)

BPMN (business process modeling notation (BPMN 2.0))

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

Облачная версия aris cloud включает в себя 4 типа диграмм: EPC, OC, VAD, application system type diagram

Бесплатная версия программы т.е ARIS EXPRESS поддерживает только базовые типы диаграмм, не имеет многопользовательской поддержки (ARIS CLOUD поддерживает), не использует базу данных, не содержит инструментов для формирования отчётов и средств анализа модели. ARIS Express не поддерживает связи между создаваемыми объектами в отличие от полноценной платной версии, то есть отсутствует контроль целостности и непротиворечивости модели. Это означает, что при редактировании одной модели программа не будет вносить соответствующие изменения в другую модель, а также не будет проверять существуют ли должности, указываемые в качестве ответственных в процессе и т.д.

Метки: arisbpmnбизнесбизнес архитектурамодель

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

Модель АРИС Framework

Концепция АРИС (Архитектура интегрированных информационных систем) Августа-Вильгельма Шеера направлена на то, чтобы создать информационную систему предприятия, полностью соответствующую ее бизнес-интересам и современным экономическим требованиям.

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

ARIS опирается главным образом на собственную архитектуру с пятью видами — «АРИС дом». Эти пять представлений являются:

• организационной моделью;
• управленческой моделью;
• моделью данных;
• функциональной моделью;
• выходной(сервисной) моделью.

Классификация выполнена таким образом, чтобы разбить сложность модели на пять аспектов и тем самым упростить моделирование. Каждое представление концепции ARIS (architecture of integrated information) systems демонстрирует модель бизнес-процесса в определенном аспекте:

1. Функциональном — действия, группировки и иерархические отношения, которые существуют между ними, описаны в представлении функции, например, в дереве функций.
2. Организационном — предоставляет обзор организационной структуры компании, включая человеческие ресурсы, машины, оборудование и их взаимосвязи.
3. Информационном (модели данных) — все события, которые генерируют данные об окружающей среде, такие как корреспонденция, документы и другие.
4. Сервисном — предоставляет обзор всего портфеля продуктов и услуг, включая услуги, продукты, финансы.
5. Управленческом — вид процесса, который соединяет все другие представления во временно-логический график, например, в управляемых событиях технологической цепочки или BPMN.

Реинжиниринг бизнес-процессов

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

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

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

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

Концепция жизненного цикла

Структуры методологии моделирования бизнес-процессов и концепции жизненного цикла появились в различных прикладных областях, таких как Computer Integrated Manufacturing (CIM), автоматизация делопроизводства и проектирование информационных систем.

Методологии и структуры часто основаны на неявных предположениях относительно их объема, цели и уровня детализации. Но есть и другой аспект, который приводит к большому разнообразию подходов. Им является тот факт, что способность методологии ARIS очень сильно зависит от цели.

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

Динамическое поведение

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

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

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

Динамическое поведение бизнес-процессов ясно показывает «организационный уклон». Модели накладываются на поведение человека. Это поведенческое искажение может только частично быть представлено формальными подходами моделирования, происходящими из области IS. Методология ARIS должна включать такие аспекты, как человеческие роли, обязанности и неформальное общение.

Эталонная модель

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

Модели процессов являются основой для разработки корпоративных приложений. В то время как они описывают структуру и логику на уровне типа, приложение потока операций поддерживает выполнение отдельных процессов на уровне экземпляра. Определение структуры в системах управления базами данных (СУБД) приводит к конкретной БД, а модели — к приложению рабочего процесса. В отличие от генерации программного кода из моделей, как это предусмотрено в классических подходах CASE, разработка приложений основана на конфигурации существующих строительных блоков ПО и, следовательно, поддерживает повторное его использование.

Разработка рабочих процессов

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

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

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

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

Спецификация проекта

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

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

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

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

Описание реализации

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

Модели используются для настройки приложения. Их можно понимать как графическую программу. Благодаря такому повторному использованию ручное программирование программного кода уменьшается.

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

1. Модель строительства и хранения.
2. Выбор/поиск и анализ моделей.
3. Конфигурация модели.
4. Интеграция моделей.
5. Адаптация и модификация модели.
6. Эволюция и изменение модели.
7. Модель исполнения и интерпретации.

Основные правила методологии ARIS

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

Рекомендации по использованию событий:

1. В начале процесса или после интерфейса запуска.
2. В конце процесса или до конца интерфейса.
3. События принятия решений по соединителям XOR или OR.
4. Для важных событий, например, вехи в проекте.
5. Действия или события не должны иметь более одного исходящего или входящего соединения.
6. Поток управления процессом моделируется с использованием Правил (шлюзов).

Правила могут быть использованы следующим образом:

1. Из одного входящего соединения следует несколько исходящих соединений (SPLIT).
2. Из нескольких входящих подключений следует точно одно исходящее подключение (JOIN).
3. Возможна последовательность Правил.
4. Er модель обычно закрывается с тем же оператором, как была открыта, и заканчивается «EPC Событием».
5. Логические операторы.

В EPC можно использовать следующие правила:

1. Разделение — шаги обработки, которые следуют правилу, происходят параллельно и должны быть выполнены.
2. Соединение — все шаги обработки для входящих соединений должны быть выполнены, чтобы можно было выполнить шаги обработки, которые следуют правилу.
3. SPLIT — точно один из следующих шагов обработки правил должен быть выполнен.
4. Разделитель — должен быть выполнен как минимум один из следующих этапов обработки правила, или несколько, или все этапы обработки.
5. Для логических операций между событиями и действиями существуют специальные правила, которые показаны в модели ARIS Express.

АРИС: набор инструментов

Набор ARIS-Tool обеспечивает комплексную компьютерную поддержку моделирования. Четыре модуля предоставляют средства для автоматизированного анализа, планирования и внедрения управленческих информационных систем. Такой подход охватывает весь жизненный цикл моделирования. Рассмотрим подробнее:

1. ARIS-Modeler специализируется на системном моделировании. На основе мета-структуры платформы ARIS для ПК представляют методы для конкретных видов, включая расширенное моделирование отношений сущностей, а также диаграммы цепочек процессов и стимулов-ответов, а также диаграммы функциональной и организационной иерархии.
2. ARIS-Analyzer предоставляет средства для изучения и оценки существующей системы с точки зрения ключевых показателей эффективности. Анализ слабых мест можно проводить для каждого вида моделирования. Кроме того, может быть получена идеализированная концепция интеграции, включающая в себя целевую функцию и модели данных. Эталоны являются неотъемлемой частью ARIS-Analyzer.
3. ARIS-Project Manager используется для управления проектами. Он предназначен для планирования, контроля и мониторинга всего проекта на всех его этапах. ARIS-Project Manager определяет все задачи, которые будут решаться в процессе моделирования бизнес-процессов.
4. Цель ARIS-Navigator — предоставить компьютеризированную документацию для корпоративной модели, разработанной на этапах моделирования.

Express. Официальное ПО

«АРИС Экспресс 2», er модель — программа, выпущенная для операционных систем на базе Microsoft Windows. Также она работает в других ОС, таких как Mac OS X или Linux.

Для загрузки программы:

1. Переходят на профильный сайт.
2. Выбирают метод загрузки для ОС.
3. Входят в сообщество ARIS, принимают Лицензионное соглашение и Правила экспорта Software AG, чтобы иметь возможность загрузить ПО.
4. Знакомятся с инструкцией по установке независимо от того, какая загрузка выбрана.
5. Знакомятся с системными требования, чтобы быть уверенным, что пользовательский ПК будет способен работать с программой.

Программа имеет очень продвинутую бесплатную функцию ARIS Cloud. Это полномасштабный продукт для анализа бизнес-процессов, который как услуга предоставляется совершенно бесплатно для исследовательских и образовательных целей. Он поддерживает совместные проекты по улучшению процессов и доступен для 1000 пользователей одновременно по всему миру. С бесплатной пробной версией software ag ARIS Cloud бесплатная подписка длится 30 дней. С AERIS Cloud для студентов бесплатная подписка длится 3 месяца.

EPC предлагает множество способов для моделирования процессов, их анализа и определения потенциалов улучшения. Модель EPC непосредственно встроена в интерактивный просмотрщик моделей. Можно скачать его и редактировать бесплатно модели в ARIS Express 2 er. Также можно использовать предоставленные видеоуроки, чтобы найти легкий путь в мир АРИС.

Процесс моделирования:

1. Загружают ARIS Express.
2. Просматривают примеры моделей или видеоуроки.
3. Начинают моделирование.
4. Присоединяются к сообществу ARIS.
5. Получают бесплатную копию «шпаргалки». Для этого нажимают на картинку на профильном сайте, чтобы увеличить ее и скачать документ в формате PDF.

Процессы преобразования в XPDL

Для моделирования процессов, которые должны быть преобразованы в XPDL, используют ARIS версии 6.2.

При установке и настройке ARIS запускают программу ARIS Toolset:

1. В строке меню выбирают Файл-> Создать, а затем модель в следующем диалоговом окне.
2. Появится другое диалоговое окно, в котором выбирают место, где будет храниться модель ARIS. Можно выбрать, например, LOCAL-> Demo62-> Основная группа.
3. После нажатия кнопки «Далее» появляется другое диалоговое окно. Необходимо установить флажок «Процессы» и выбрать тип модели eEPC.
4. Появится диалоговое окно, в котором необходимо назначить имя для новой модели ARIS.
5. Вводят имя и нажимают кнопку «Готово». Окно покажет область редактирования для новой модели.
6. При моделировании ARIS используют только элементы панели инструментов, отмеченные красным кружком.
7. Элемент, помещенный в правом верхнем углу в наборе инструментов, называется функцией в АРИС, он будет отображен в Activity/Task в XPDL, поэтому используют его для определения задач в процессе.
8. Элемент называется правилом AND в ARIS и сопоставляется с фиктивным действием (маршрут) в XPDL с помощью AND Split или Join в зависимости от того, как пользователь подключает его к задачам.
9. Кроме того, если нужно определить какой-либо значимый идентификатор для других объектов действий и переходов, следует изменить тот же атрибут в ARIS для соответствующих объектов. Чтобы сделать это, нужно дважды щелкнуть объект, вставить его в график и отредактировать атрибут Identifier.
10. Убеждаются, что данные содержат только буквенно-цифровые символы или символы «_», «-», «.».
11. После создания модели в ARIS можно экспортировать ее в XML.
12. Для этого нужно найти определение процесса в древовидном представлении ARIS, щелкнуть его правой кнопкой мыши и выбрать «Экспорт / Импорт-> Экспорт XML…».
13. После нажатия на «Экспорт XML» пользователя попросят ввести используемый язык, а затем выбрать местоположение и имя файла XML, который будет сгенерирован.
14. Нажимают на соответствующий значок, чтобы преобразовать этот * .aml файл в XPDL.
15. Отправляют XPDL-файл в хранилище, позже можно загрузить его в движок через «Package Mng»- раздел приложения.

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

Инструменты ARIS консолидируют методологические структуры, что является важной предпосылкой для полной интеграции от реорганизации коммерции до внедрения информационных систем. Особенно подробно описаны эти процессы в книге Августа Вильгельма Шеера «Моделирование бизнес-процессов». Изучение основ помогает создать информационную модель, которая является краеугольным камнем систематического и интеллектуального метода разработки прикладных систем.

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

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

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

Моделирование бизнес-процессов в ПО ARIS

К основным целям бизнес-моделирования можно отнести следующие моменты:

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

ARIS, то есть, Architecture of Integrated Information Systems является методологией и тиражируемым программным продуктом, предназначенным для моделирования бизнес-процессов организаций. Продукт и методология стали собственностью немецкой фирмы Software AG в результате поглощения компании IDS Scheer, которую создал автор методологии Август-Вильгельм Шеер.

Реализовать методологию можно путем задействования специализированного программного продукта, который способен обеспечить совместную работу над описаниями и диаграммами. Первая вариант этого программного продукта вышел в свет в 1994-ом году. В 2000-ом году данный продукт уже был поставлен примерно двадцати четырем тысячам организаций. Начиная с 2009-го года стала поставляться бесплатная версия инструмента, именуемая ARIS Express.

Программный продукт ARIS может использоваться в разных проектах по реинжинирингу и оптимизации бизнес-процессов, ИТ-проектах типа внедрения и эксплуатации ERP-систем, в том числе, имеется отработанное интеграционное решение для SAP R/3.

Программное обеспечение ARIS является основой пакета Business Process Analysis Suite компании Oracle. Технически инструментальный набор ARIS считается довольно простым для освоения и обладает интуитивно понятным интерфейсом. Сформированные модели можно копировать и вставлять в файлы документов (к примеру, формата Microsoft Word) в форме рисунков.

В программных продуктах ARIS предусматривается возможность формирования сценариев автоматизации создания разных аналитических отчетов, нормативной документации, новых моделей. Все сценарии являются подпрограммами, которые можно запустить в ARIS Business Architect (либо Toolset для более ранних версий) или прямо на сервере ARIS. Сценарии следует писать на специализированном языке программирования, который называется SAX Basic. Для того чтобы в автоматизированном режиме сформировать какой-либо отчет в ARIS, сценарии могут оперировать данными из базы моделей, выбирая из нее требуемые объекты и модели.

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

1. Создание нормативной документации на базе моделей ARIS, таких, как паспорт процесса, регламент процесса.
2. Создание аналитических отчетов на базе моделей ARIS.
3. Объединение ARIS Toolset с иными приложениями и базами данных.
4. Создание базы моделей ARIS на базе готовых спецификаций.

К примеру, каждая организация в методологии ARIS должна рассматриваться со следующих позиций:

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

Причем каждая из этих точек зрения должна также подразделяться на следующие подуровни:

1. Подуровень описания требований.
2. Подуровень описания спецификации.
3. Подуровень описания внедрения.

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

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

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

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

1. eEPC (extended event-driven process chain), которая является событийной цепочкой процессов.
2. ERM (entity-relationship model), которая является моделью типа «сущность-связь» для описания структуры данных.
3. UML (unified modeling language), которая является унифицированным объектно-ориентированным языком моделирования.

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

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

ARIS
– это сокращенное английское выражение
(Architecture
of
Integrated
Information
Systems),
что в переводе означает: архитектура
интегрированных информационных систем.

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

Методология
ARIS
реализует принципы системного структурного
анализа, основным понятием которого
служит структурный элемент (объект).

Структурный
анализ является методологической
разновидностью системного анализа.

В
структурном анализе предполагается
использование графического представления
для описания структуры и деятельности
организации. При этом реализуются
основные принципы структурного анализа:

• разбиение
  на уровни абстракции с ограничением
  числа элементов на каждом уровне (обычно
  от 3 до 9);

• ограниченный
  контекст включающий только существенный
  на каждом уровне детали;

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

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

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

● Организационная
структура

● Данные
(потоки и структура)

● Функции
(«деревья» функций)

● Контроль
и управление (деловые процессы)

Все
данные подсистемы организации в
реальности и в моделях должны быть
связаны между собой. Методология ARIS
дает возможность описывать достаточно
разнородные подсистемы в виде
взаимоувязанной и взаимосогласованной
совокупности различных моделей, которые
хранятся в едином репозитории (рис.
1.1). Именно взаимосвязанность и
взаимосогласованность моделей являются
отличительными особенностями методологии
ARIS [5].

Рис.
1.1 — Структурная схема формирования
репозитория

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

Естественно,
что эти подсистемы не являются
обособленными. Они взаимно проникают
друг в друга, и поэтому одни и те же
элементарные модули могут использоваться
для описания различных структурных
моделей. Для устранения избыточности
методология ARIS
ограничивает число типов моделей [4].

В
связи с этим в методологии ARIS
выделено пять типов представлений
основных моделей, отражающих основные
аспекты организации (рис. 1.2):

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

2.
Функциональные модели, описывающие
функции (процессы, операции), выполняемые
в организации;

3.
Информационные модели (т.е. модели
данных), отражающие структуру информации,
необходимой для реализации всей
совокупности функций системы;

4.
Модели процессов или управления,
представляющие комплексный взгляд на
реализацию деловых процессов в рамках
системы и объединяющие вместе другие
модели;

5.
Модели входов и выходов, описывающие
потоки материальных и нематериальных
входов и выходов, включая потоки денежных
средств.

Рис.
1.2 — Взаимосвязи моделей деятельности
организации

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

Для
построения моделей и проведения
структурного анализа в ARIS используют
следующие методы и средства визуального
описания:

• DFD
(Data Flow Diagrams) – диаграммы потоков данных
для анализа и функционального
проектирования моделей систем. Описывают
источники и адресаты данных, логические
функции, потоки данных и хранилища
данных к которым осуществляется доступ;

• STD
(State
Transition
Diagrams)
– диаграммы перехода состояний для
проектирования систем реального времени;

• ERD
(Entity-Relationship
Diagrams)
– диаграммы сущность-связь, описывающие
объекты (сущности), свойства этих объектов
(атрибуты) и их отношения объектов
(связи);

• SADT
(Structured
Analysis
and
Design
Technique)
— технология структурного анализа,
проектирования и моделирования
иерархических многоуровневых модульных
систем;

• IDEF0
(Integration
Definitionfor
Function
Modeling)
– подмножество SADT
– стандарт описания бизнес-процессов
в виде иерархически взаимосвязанных
функций;

• IDEF1
– стандарт описания движения информации;
используется для определения структуры
информационных потоков, правил движения,
принципов управления информацией,
связей потоков, выявления проблем
некачественного информационного
менеджмента;

• IDEF1X
– стандарт разработки логических схем
баз данных, основанный на концепции
сущность-связь;

• IDEF3
– стандарт описания процессов, основанная
на сценариях. Сценарий есть описание
последовательности изменения свойств
объекта в рамках некоторого процесса.
Стандарт позволяет описать последовательность
этапов изменения свойств объекта
(Process
Flow
Description
Diagrams
— PFDD)
и состояния объекта на этапах (Object
State
Transition
Network
— OSTN).
Стандарт позволяет решать задачи
документирования и оптимизации процессов;

• IDEF4
– стандарт описания структуры объектов
и заложенных принципов их взаимодействия;
позволяет анализировать и оптимизировать
сложные объектно- ориентированные
системы;

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

• UML
(Unified
Modeling
Language)
– объектно-ориентированный унифицированный
язык визуального моделирования. Позволяет
описывать диаграммы действий, диаграммы
взаимодействия, диаграммы состояний,
диаграммы классов и компонент. Используется
как для анализа, так и для проектирования
моделей информационных систем [7].

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

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

Каждый
уровень соответствует определенной
фазе жизненного цикла информационной
системы:

1.
уровень определения требований (что
система должна делать);

2.
уровень проектной спецификации (основные
пути реализации системы);

3.
уровень описания реализации (физическое
описание конкретных программных и
технических средств.

Каждый
из уровней анализа состоит из своего
комплекта моделей различных типов, в
том числе диаграмм UML,
диаграмм SAP
R/3
и др. Каждый объект моделей ARIS
имеет множество атрибутов, позволяющих
контролировать процесс разработки
моделей, определить условия для выполнения
функционально-стоимостного анализа,
имитационного моделирования, взаимодействия
с work
flow-системами
и т.д. [4].

Подборка по базе: ___ ____ __ ARIS.docx, Циулина М.В. Методологияпсих.-пед. исследований.pdf, Лекции — Основы моделирования.pdf, контрольная работа математического моделирования.doc, реферат Методология.rtf, Творческая работа _Способы моделирования правильных многогранник, ARIS методология.pptx, Лекция 33-36 Теория и методология обучения физической культуре.p, Контрольная работа Методология Шевчук В.А..docx, Крысанова О.А. — Методология психолого-пе дагогических исследован

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

Из истории

• Создателем программной системы ARIS и автором одноименной методоло­гии моделирования бизнес-процессов является профессор Саарского университета (Saarland University) Август-Вильгельм Шеер.
• В середине 1970-х гг. А.-В. Шеер основал Институт информационных систем (один из наиболее известных в Германии исследовательских центров в области информационных систем) при Саарском университете и руководил этим институтом вплоть до 2005 г.
• В этот знаменательный период Шеер создал методологию ARIS, основал компанию «IDS Scheer», специализирующуюся на разработке программного обеспечения для управления бизнес-процессами, и силами «IDS Scheer» разработал программ­ную систему ARIS.
• Большое влияние на ход работы по созданию новой методологии оказал тот факт, что выполнение работ осуществлялось в тесной взаимосвязи с Институтом информационных систем, т.е. в работе были учтены теоретические и практические знания в области информационных технологий того времени.

О создании методологии

• За основу при создании методологии ARIS были взяты, объединены и интегрированы известные на тот момент и хорошо проявившие себя методологии.
• Однако суть в том, что А.-В. Шеер постарался взять все лучшие свойства от известных методологий, при этом попытался устранить имеющиеся в этих свойствах недостатки и противоречия.
• Конкретно, методология IDEF3, относящаяся к семейству IDEF и предназначенная для описания потоков работ (Work Flow Modeling), была взята за основу при создании модели еЕРС — «расширенной цепочки процесса, управляемого событиями»; во многих изданиях имеется и другой перевод — «процессно-событийная модель» .
• Полученная в результате методология ARIS предоставила возможность с разных точек зрения и сторон описывать бизнес-процессы, протекающие в реальной действительности. Понятно, что чем больше точек зрения и сторон описания, тем точнее модель бизнес-процессов.

• ARIS — это и методология, и программный продукт для моделирования бизнес-процессов организаций.
• Под системой ARIS (либо инструментальной средой ARIS) понимается аппаратное и программное обеспечение, реализующее методологию ARIS.

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

• ARIS — это сокращенное английское выражение Architecture of Integrated Information Systems, что в переводе означает: архитектура интегрированных информационных систем.
• Под архитектурой подразумевается совокупность технологий, обеспечивающих проектирование, управление, применение и реализацию бизнеса в виде «деловых» процедур бизнес-процессов предприятий и организаций, а также проектирование и создание интегрированных информационных систем поддержки бизнес- процессов.

• Методология ARIS реализует принципы системного структурного анализа, основным понятием которого служит структурный элемент (объект).

Основные элементы моделей в методологии ARIS

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

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

• организационная структура;
• данные (потоки и структура);
• функции («деревья» функций);
• контроль и управление (деловые процессы).

• организационная структура;
• данные (потоки и структура);
• функции («деревья» функций);
• контроль и управление (деловые процессы).

• требования
• спецификации
• внедрение

Каждый уровень соответствует определенной фазе жизненного цикла информационной системы (в ARIS используется трехфазовая модель жизненного цикла):

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

Это обеспечивает целостность разрабатываемой системы.

• организационная структура;
• данные (потоки и структура);
• функции («деревья» функций);
• контроль и управление (деловые процессы).

• требования
• спецификации
• внедрение

• Каждый из уровней анализа состоит из своего комплекта моделей различных типов, в том числе диаграмм UML, диаграмм SAP R/3 и др.
• Каждый объект моделей ARIS имеет множество атрибутов, позволяющих контролировать процесс разработки моделей, определять условия для выполнения функционально-стоимостного анализа, имитационного моделирования, взаимодействия с workflow-системами и т.д.

• Методология ARIS предусматривает возможность представления информации при помощи более 80 типов моделей, относящихся к тому или иному «взгляду».
• При этом основной «взгляд» в ARIS — это процессы, для моделирования которых предназначено примерно 2/3 моделей из общего числа, т.е. методология ARIS в большей степени ориентирована на процессный подход.

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

• организационная схема (Organizational Chart — ОС);
• функциональная модель (Function Tree — FT);
• процессно-событийная модель (Extended Event-Driven Process Chain — eEPC).

Методология ARIS предназначена специально для визуального описания бизнес-процессов и условий функционирования различного рода организаций и предприятий,

а также для анализа их деятельности по различным показателям

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

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

Методологию ARIS эффективно использовать для анализа и оптимизации бизнес-процессов (реинжиниринг), для внедрения стандартных информационных систем класса ERP (таких, как, SAP) и внедрения систем управления качеством.

• Анализ и оптимизация бизнес-процессов в методологии ARIS осуществляются с помощью процедурной модели ARIS (которая регламентирует фазы оптимизации), позволяющей перестраивать и постоянно совершенствовать бизнес-процессы.

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

• Согласно процедурной модели, на фазе анализа «как есть» выполняется «инвентаризация» бизнес-процессов и разрабатываются модели «как есть» («as is»). Таким образом, выявляются слабые места бизнес-процессов и потенциальные возможности их оптимизации.

• На фазе формирования целевой концепции на основании моделей «как есть» описываются альтернативные варианты целевых процессов «как должно быть» («to be»), которые должны отражать представление о том, как будет функционировать организация после улучшения «неоптимальных» процессов.

Внедрение стандартных информационных систем класса ERP.

• К классу ERP относятся такие российские и западные ERP-системы, как «R/З», «Oracle Applications», «Вааn IV», «iRenaissance», «Axapta», «ПАРУС», «Галактика» и др.

• ERP- системы (Enterprise Resource Planning System) — это системы управления ресурсами предприятия.

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

Внедрение систем управления качеством по стандарту ISO 9000.

• Методология ARIS может обеспечить поддержку всего процесса подготовки и непосредственной сертификации по данному стандарту. Для этого в системе ARIS предусмотрено создание специальных отчетов, соответ­ствующих требованиям ISO 9000, а также существуют модели, отражающие полную методологию процесса сертификации по стандарту ISO 9000 (анализ существующей системы управления на предприятии, реорганизация бизнес-процессов, обучение персонала и непосредственно сама сертификация).

• ГОСТ ISO 9000 — серия международных стандартов, описывающих требования к системе менеджмента качества организаций и предприятий.

• В ходе подготовки к сертификации разрабатываются модели цепочек добавленной стоимости, еЕРС, организационные, ролевые и др.
• В рамках методологии ARIS также имеется возможность определения требований к автоматизированной системе управления и проведения ее проектирования, обеспечения подготовки и внедрения организационных изменений на предприятии.

Задачи методологии ARIS

• С помощью методологии ARIS могут решаться специализированные задачи, например, связанные с имитационным моделированием.
• AR1S поддерживает построение моделей так, как процессы проходят в действительности. Такие модели можно «проиграть» во времени как для одного испытания, так и заданного их множества. Имитационные модели позволяют выявить длительности периодов простоя в процессах (например, динамика времени ожидания и ситуации недостатка ресурсов).
• Другой специализированной задачей, решаемой в рамках методологии ARIS, является стоимостной анализ, который осуществляется на базе моделей процессов с помощью аналитических методов оценки и исследования операций.

Преимущества методологии ARIS

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

Недостатки методологии ARIS.

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

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

Невозможность визуального отражения длительности выполнения процедур.

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

Следует отметить, что реальная длительность выполнения процедур в еЕРС визуально отражена быть не может.

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

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

Отсутствие учета управляющих воздействий

• Одним из важнейших аспектов описания моделей бизнес-процессов является отражение на модели управляющих воздействий, обратных связей по контролю и управлению процедурой. В нотации AR1S еЕРС управление процедурой может быть отражено только с помощью указания входящих документов, которые регламентируют выполнение процедуры, и последовательности выполнения процедур во времени (запускающие события).
• В отличие от ARIS, в нотации IDEF0 каждая процедура должна иметь хотя бы одно управляющее воздействие (вход управления — стрелка сверху). Если при создании модели в еЕРС указывать только последовательность выполнения процедур, не заботясь об отражении управляющих воздействий (например, документов и информации), полученные модели будут иметь низкую ценность с точки зрения анализа и дальнейшего использования. К сожалению, именно эта ошибка наиболее распространена на практике. Создается модель «Work Flow» (поток работы), отражающая простую последовательность выполнения процедур и входящих/исходящих документов, при этом управляющие (контрольные) воздействия на функции в модели не отражаются. Реальные процессы управления могут остаться «за кадром» на 30—90%.

Необходимость разработки соглашений о моделировании.

• Методология ARIS поддерживает большое количество типов моделей, нотаций и объектов, т.е. предоставляется чрезмерное количество возможностей. Поэтому перед началом моделирования необходимо определиться с набором исполь­зуемых типов моделей, а следовательно, объектов, их атрибутов и связей. Для этого формируются так называемые соглашения по моделированию. Разработка этих соглашений сама по себе является сложной, дорогостоящей задачей, требующей значительного времени (1—3 месяца) и квалифицированных специалистов. Если проект с использованием системы ARIS начинается без детальной проработки таких соглашений, то вероятность создания моделей бизнес-процессов, не отвечающих на поставленные вопросы, составляет 80—90%.
• Отсутствие четких соглашений по моделированию управляющих воздействий в рамках еЕРС ARIS может привести к созданию моделей, не отвечающих на поставленные вопросы, в то время как нотация IDEF0 системы BPWin позволяет решить эту задачу.

Основные модели ARIS

Основные модели ARIS

• организационная схема (Organizational Chart — ОС),
• функциональная модель (Function Tree — FT),
• процессно­-событийная модель (extended Event-Driven Process Chain — eEPC).

Организационная схема

• Организационная схема (Organizational Chart — ОС) (далее организационная модель) описывает организационные единицы различного уровня и их взаимосвязи.

• подразделения предприятия;
• наименование должности и фамилии руководителей подразделений;
• физическое местоположение отделов на предприятии.

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

Организационная модель

КАФЕДРА КБ-9:

Заведующий кафедрой

Зам.зав.кафедрой – Канева И.Ю. Преподаватели

Учебно-методический кабинет

Зав.уч.кабинетом – Леонов Д.А.

Техник – Новожилов А.А.

Диспетчер – Ляшкова А.В.

Лаборатория:

Зав.лабораторией – Шубин Н.Ю.

Лаборант – Фокина О.С.

Лаборант – Кириченко О.С.

Функциональная модель (Function Tree — FT)

• Функциональная модель представляет собой «дерево» основных функций, реализуемых на предприятии. Модель строится иерархически — от верхнего уровня функций к нижнему (через декомпозицию). При этом функции не обяза­тельно отражаются в хронологическом порядке.

Процессно-событийная модель (Extended Event-Driven Process Chain — еЕРС)

• Процессно-событийная модель (Extended Event-Driven Process Chain — еЕРС) (кратко — модель или диаграмма еЕРС) предназначена для детального описания процессов, выполняемых в рамках одного подраз­деления, несколькими подразделениями или конкретными сотрудниками.
• Модель еЕРС позволяет выявлять взаимосвязи между организацион­ной и функциональной моделями.
• Модель еЕРС отражает последовательность функциональных шагов (действий) в рамках одного бизнес-процесса, которые выполняются орга­низационными единицами, а также ограничения по времени, налагаемые на отдельные функции.

Нотация ARIS eEPC

• ARIS еЕРС — одна из первых нотаций, получившей широкую известность на российском рынке. Она относится к нотациям Work Flow. Особенности нотации — наличие элементов типа «Событие» и операторов логики «И», неисключающее «ИЛИ», исключающее «ИЛИ».

Нотация ARIS eEPC – методические фильтры

Нотация ARIS еЕРС содержит большое количество графических элементов. Поэтому при выполнении проектов создаются так называемые методические фильтры (в рамках соглашений по моделированию), которые ограничивают количество типов элементов, доступных пользователям при создании схем процес­сов. (В некоторых средствах моделирования нотация ARIS еЕРС сразу реализована с минимально необходимым набором элементов.) Однако даже в этом случае неопытные пользователи создают схемы такой сложности, в которых трудно разобраться. К ним нужен подробный комментарий (либо наличие аналитика, способ­ного объяснить схему).

Нотация ARIS eEPC

Нотация ARIS eEPC

Простейшая модель eEPC, описывающая фрагмент бизнес-процесса предприятия

Нотация ARIS eEPC

Нотация eEPC построена на определенных семантических правилах описания:

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

Нотация ARIS eEPC

• при помощи нотации eEPC ARIS можно описывать бизнес-процесс в виде потока последовательно выполняемых работ (процедур, функций).

Нотация ARIS eEPC

Типичная схема в ARIS еЕРС:

• не годится для автоматизации в системе класса ВРМ (Business Process Managment) (нужно применять дополнительный транслятор, переводящий ее в нотацию BPMN, с последующей ручной доработкой);
• сложна для восприятия рядовыми сотрудниками (их нужно учить правилам использования логических операторов и кор­ректному чтению схем, которые их содержат).

(с) Репин В.