Aris описание бизнес процессов

При изучении бизнес-процессов предприятия как правило требуется зафиксировать в документальном виде описание бизнес-процесса. Как это сделать?

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

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

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

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

• eEPC: extended Event Driven Process Chain – расширенная нотация описания цепочки процесса, управляемого событиями.
• ARIS: Architecture of Integrated Information Systems.

Нотация ARIS разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Августом-Вильгельмом Шеером.

Первоисточник – фундаментальный труд: Шеер. “Бизнес-процессы. Основные понятия. Теории. Методы”.

Элементарным кирпичиком нотации ARIS является функция бизнес-процесса и все сопряженные с ней элементы:

В этой статье рассмотрим “урезанное” подмножество eEPC ARIS, которое наиболее часто применяется для документирования бизнес-процессов (потоков работ work flow) на проектах автоматизации.

В основе описания eEPC процесса – описание последовательности функций (действий), которые выполняют пользователи в системе. Каждой функции предшествует событие. Часто событие интерпретируют как некое “происшествие”, например, звонок клиента, получение письма и так далее. Но более точное определение – это состояние процесса, при котором должно выполниться действие. Событие – это необходимое и достаточное условие выполнения некоторого действия:

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

Например, “от начала выполнения техоперации прошло 10 мин” – это тоже событие.

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

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

Далее, у каждой функции надо указать исполнителя:

Получаем последовательность состояний системы (результатов) и соответствующих действий пользователей. Но для описания процесса этого недостаточно.

Нужно добавить данные, которые перемещаются между функциями:

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

В вышеприведенной схеме исходящими данными из функции “Действие 1” является “Заказ клиента”, а результатом выполнения функции (завершающим событием) может быть “Заказ обработан отделом продаж”…

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

Некоторые нотации (например, нотация, принятая в 1С СППР) рассматривают только потоки работ, а на связях указываются наименования документов и результатов. Такая упрощенная модель с использованием элементов ARIS выглядела бы так:

Заметим, что всей полноты картины такая модель не дает.

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

Далее, использование логических операторов “И”, “ИЛИ”, “ИСКЛЮЧАЮЩЕ ИЛИ” позволяет указать ветвление потоков работ.

Оператор “И”

“И” – позволяет указать что после события запускаются сразу несколько функций:

либо указать, что событие (состояние) возникает только если выполнено несколько функций:

либо указать что только несколько событий (состояний) разрешают выполнение функции:

также, “И” позволяет указать что выполнение функции приводит одновременно к нескольким состоянием (событиям):

Оператор “ИЛИ”

“ИЛИ” – позволяет указать что возникновение одного из нескольких событий (состояний) – достаточно чтобы начать выполнение функции:

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

Оператор “Исключающее ИЛИ”

И наконец, “Исключающее или” отличается от просто “ИЛИ” тем, что возможен только один из альтернативных вариантов – либо Событие 1 либо Событие 2, но не оба одновременно. Это взаимоисключающие альтернативы: два взаимоисключающих события приводят к выполнению одной функции

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

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

Типичные ошибки

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

Перечислим наиболее распространенные ошибки моделирования в нотации eEPC ARIS.

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

• Два (или больше) входа в одну функцию. Например, при кольцевом выполнении функций:

Источник: itrp.ru

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

Источник: businessarchitecture.ru

Почему в 2022 году многие всё ещё используют ARIS

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

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

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

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

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

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

• JavaScript
• ERP-системы
• Бизнес-модели

Источник: habr.com