Xor rule в aris что значит

Моделирование бизнес процессов с помощью ARIS (express and cloud)

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

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

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

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 рассматривается с пяти точек зрения: организационной, функциональной, обрабатываемых данных, структуры бизнес-процессов, продуктов и услуг. При этом каждая из этих точек зрения разделяется ещё на три подуровня: описание требований, описание спецификации, описание внедрения. Для описания бизнес-процессов предлагается использовать около 80 типов моделей, каждая из которых принадлежит тому или иному аспекту.

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

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

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

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

Доступные типы моделей в 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 не поддерживает связи между создаваемыми объектами в отличие от полноценной платной версии, то есть отсутствует контроль целостности и непротиворечивости модели. Это означает, что при редактировании одной модели программа не будет вносить соответствующие изменения в другую модель, а также не будет проверять существуют ли должности, указываемые в качестве ответственных в процессе и т.д.

Источник

· Каждый путь должен начинаться и заканчиваться событием (Eachpathmustbeginandendwithanevent);

· Все функции/события должны иметь только одну входящую/исходящую связь(All functions/events must have only one incoming/outgoing connection);

· Нельзя использовать операторы XOR/OR после события(NoXOR/ORaftereventpossible);

· Должен быть сохранен порядок операторов(Order at the operator must be preserved);

Если необходимо удалить выбранное правило, можно воспользоваться кнопками RemoveSelection (Удалить выбранное правило) и RemoveAll (Удалить все выбранные правила). На рис. 18.10. представлена ДО с результатами нашего выбора. Флажок у опции OutputStatistic (Выводить статистику) позволит в окне выхода (OutputWindow) представлять информацию о процедуре семантической проверки. Далее нажмем OK.

Рис. 18.10. ДО ARIS Semantic Check

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

Рис. 18.11. Сообщение ARIS

Если выбрать кнопку Да, то на модели появятся предупреждения в местах нахождения семантических ошибок (рис. 18.12.).

Рис. 18.12. Фрагмент eEPC-модели с выведенными сообщениями об ошибках

Далее откроется окно, сообщающее об успешном выполнении программы проверки (рис. 18.13.) и предложении просмотреть полученный отчет.

Рис. 18.13. Сообщение ARIS об окончании процедуры проверки

Так как в качестве выходного формата была выбрана Excel-таблица, но на листах MS Excel будут поочередно выведены отчеты по каждому проверяемому правилу (рис. 18.14.).

Рис. 18.14. Вид отчета в MS Excel

Если бы в окне на рис. 18.7. был выбран другой выходной формат, например, WordDocument, отчет был бы выведен в форме, как показано ниже на рис. 18.15.

Рис. 18.15. Вид отчета в MS Word

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

· Функция 6 заканчивает процесс, тем самым нарушается правило: Каждый путь должен начинаться и заканчиваться событием (Eachpathmustbeginandendwithanevent) об обязательном присутствии события в начале и в конце процесса.

· Функция 1, Функция 4 и Функция : имеют более, чем одну входящую или исходящую связи, тем самым нарушается правило: Все функции/события должны иметь только одну входящую/исходящую связь (Allfunctions/eventshaveonlyoneincoming/outgoingconnection).

· После События 4 следует логический оператор «исключающее или» (XOR), тем самым нарушается правило: Нельзя использовать операторы XOR и OR после события (NoXOR/ORaftereventpossible).

· Функция 3 и Функция 4 предшествуют оператору «или» (OR), Функция 5 следует за оператором «и», Событие 4 предшествует оператору «исключающее или» (XOR), Событие 5 и Событие 6 следуют за этим оператором, тем самым нарушается правило: Должен быть сохранен порядок операторов (Orderattheoperatormustbepreserved). Это правило говорит о том, что различные типы объектов должны предшествовать и следовать за оператором (т.е., если оператору предшествовал объект типа Функция, то следовать за ним должны объекты типа Событие и наоборот).

Итоговая таблица в отчете отражает количество ошибок при проверке каждого правила (таблица 1):

1. Каждый путь должен начинаться и заканчиваться событием

2. Все функции/события должны иметь только одну входящую/исходящую связь

3. Нельзя использовать операторы XOR и OR после события

4. Должен быть сохранен порядок операторов

После исправления ошибок и дополнения модели необходимыми объектами и связями модель будет выглядеть как показана на рис. 18.16. Было три логических оператора, стало – шесть; было шесть функций, стало – восемь; было шесть событий, стало – десять событий (показаны без цвета с жирными границами). Также к функциям добавлены дополнительные экземпляры должностей (Должность 1 и Должность 3).

После семантической проверки отчет показывает отсутствие ошибок в модели по всем четырем примененным правилам (таблица 2):

1. Каждый путь должен начинаться и заканчиваться событием

2. Все функции/события должны иметь только одну входящую/исходящую связь

3. Нельзя использовать операторы XOR и OR после события

4. Должен быть сохранен порядок операторов

Рис. 18.16. eEPC-модель после исправления ошибок

Чтобы распечатать файл, скачайте его (в формате Word).

Источник

Xor rule в aris что значит

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

Как и в случае с DFD, методология EPC «разрослась» интерпретациями, поддерживающими различные нотации (синтаксис и семантику элементов). К этому «приложили руку» как сам автор методологии, так и производители ПО, в котором реализована возможность моделирования бизнес-процессов посредством EPC (ARIS, Microsoft Visio, Business Studio, Bflow). По аналогии с блок-схемами, символы (элементы) графической нотации можно сгруппировать по назначению. В следующей таблице приведены символы EPC и их альтернативные изображения, наиболее часто встречающиеся в литературе и ПО.

Таблица 8.2. Условные обозначения на EPC-диаграммах

№ п/п	Символ	Наименование	Назначение
1. СИМВОЛЫ ПРОЦЕССА
1.1	Событие (Event)	Факт (ситуация, набор условий или обстоятельств), который активирует или оказывает влияние на дальнейшее развитие одного или более процессов. Событие инициируют действия или являются их результатами. В отличие от функции, выполнение которой занимает определенный промежуток времени, событие относится к конкретной точке во времени.
1.2	Функция, деятельность (Activity)	Действие или набор действий, выполняемых над объектом (документом, ТМЦ и т.п.) с целью получения заданного результата.
1.3	Интерфейс процесса (Process Interface)	Внешний (по отношению к текущей диаграмме) процесс или функция. Используется для указания взаимосвязи процессов: — обозначает предыдущий или следующий процесс по отношению к текущему процессу (диаграмме); — обозначает процесс, откуда поступил или куда передается объект.
2. СИМВОЛЫ ОБЪЕКТОВ
2.1	ТМЦ, информация (Information, Entity)	Товарно-материальные ценности (ТМЦ) или информация, используемые или получаемые в результате действий. Может использоваться вместо элемента «Вход / Выход».
2.2	Документ (Document)	Информация, представляемая не в компьютерном виде (на бумаге, пленках, слайдах).
2.3		Файл, база данных (File, Database)	Информация, представляемая в компьютерном виде (файл, таблица, БД, электронный документ).
2.4	Контекстные данные, кластер (Cluster)	Набор данных, необходимых для выполнения функции (модель, диаграмма, заказ).
2.5		Набор объектов, картотека (CardFile)	Набор ТМЦ или документов.
2.6	Сообщение (Message)	Требование отправителя к получателю на создание ТМЦ, предоставление информации или оказание услуги.
2.7	Вход / Выход, продукт (Input / Output, Product)	Объект, необходимый для выполнения процесса (план работ, заказ, материалы) или являющийся результатом процесса (документация, изделие, выполненная услуга).
3. СИМВОЛЫ ИСПОЛНИТЕЛЕЙ
3.1	Организационная единица (Organizational unit)	Структурное подразделение, которому поручено выполнение действия (фирма, организация, отдел, служба).
3.2	Должность, тип исполнителя (Position, Role, Person type)	Должность исполнителя или роль субъекта, которому поручено выполнение действия. Составная часть организационной единицы.
3.3	Исполнитель (Person)	Конкретный исполнитель, которому поручено выполнение действия (имя исполнителя). Экземпляр должности.
3.4	Местоположение (Location)	Местоположение объекта, выполнения действия или возникновения события (фирма, организация, отдел, служба, завод, здание, комната, адрес).
4. СИМВОЛЫ ПО
4.1		Приложение, прикладная система (Application)	Информационная система (программный продукт), с помощью которой выполняется функция.
4.2	Модуль (Module)	Составная часть информационной системы.
5. СИМВОЛЫ ЛИНИЙ
5.1		Поток управления (Control Flow Arrow)	Задает последовательность (до-после) возникновения событий и выполнения действий.
5.2	Организационный поток (Organizational Flow Arrow)	Иерархическая связь между однотипными элементами (организационная единица – должность – персона).
5.3	Поток ресурсов (Resources Flow Arrow)	Связь между действием и ресурсами, необходимыми для его выполнения (организационными единицами, персонами, приложениями, модулями и т.п.).
5.4	Информационный поток (Information Flow Arrow)	Связывает действие и элемент, являющийся источником и/или приемником информации (приложение, кластер).
5.5	Поток информационных услуг (Information output Flow Arrow)	Связь между действием и информационным входом/выходом.
5.6	Поток ТМЦ (Material output Flow Arrow)	Связь между действием и материальным входом/выходом.
6. ЛОГИЧЕСКИЕ СИМВОЛЫ
6.1

Логическое «И»
(AND)Используется для обозначения слияния и/или ветвления параллельно выполняемых действий и событий. При слиянии выполнение (наступление) следующего действия (события) возможно только при завершении выполнения (наступления) всех предыдущих действий (событий). При ветвлении должны выполняться (наступать) все последующие действия (события).6.2Логическое «ИЛИ»
(OR)Используется для обозначения слияния и/или ветвления параллельно выполняемых действий и событий. При слиянии выполнение (наступление) следующего действия (события) возможно при завершении выполнения (наступления) хотя бы одного из предыдущих действий (событий). При ветвлении должно выполняться (наступить) хотя бы одно из последующих действий (событий).6.3

Исключающее «ИЛИ»
(XOR)Используется для обозначения слияния и/или ветвления действий и событий. При слиянии выполнение (наступление) следующего действия (события) возможно при завершении выполнения (наступления) только одного из предыдущих действий (событий). При ветвлении должно быть выполнено (наступить) только одно из последующих действий (событий).7. СПЕЦИАЛЬНЫЕ (ДОПОЛНИТЕЛЬНЫЕ) СИМВОЛЫ7.1Цель
(Objective)Цель выполнения процесса (высокое качество, низкая себестоимость, сокращение издержек, увеличение прибыли).7.2Термин
(Term)Используется:
— для обозначения данных, передаваемых между процессами или обрабатываемых при выполнении процессов (Техническое задание, Форма № 1, Ведомость ЦДЛ №3, пин-код);
— для обозначения статусов бумажных или электронных документов (подписанный, утвержденный).

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

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

Рис. 8.6. Условные обозначения элементов графической нотации EPC в ARIS

8.6. Правила и рекомендации построения EPC-диаграмм

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

Ниже приводятся другие правила и рекомендации [40].

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

2. События и функции по ходу выполнения процесса должны чередоваться.

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

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

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

8. Логические операторы могут объединять или разветвлять только функции или только события. Одновременное объединение/ветвление функции и события невозможно.

9. Логический оператор, разветвляющий ветви, и оператор, объединяющий эти ветви, должны совпадать. Допускается также ситуация, когда оператор ветвления «И», оператор объединения – «ИЛИ».

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

а) допустимые ситуации

б) недопустимые ситуации

Рис. 8.7. Примеры допустимого и недопустимого использования логических операторов

10. Количество пересечений линий следует минимизировать. При этом считается, что пересекающиеся линии не имеют логической связи друг с другом. Другими словами, потоки в местах пересечений не меняют своего направления.

8.7. Пример построения EPC-диаграммы

На следующем рисунке приведен пример диаграммы EPC процесса «Предпроектное обследование» из обучающих материалов к программному продукту Business Studio [40].

Рис. 8.8. Диаграмма EPC для процесса «Предпроектное обследование»

Одной из отличительных особенностей нотации, применяемой в Business Studio, является использование обобщенного символа исполнителя («Субъект»). Несмотря на отображение его в виде организационной единицы, под ним может пониматься также должность или персона.

Источник