Организация
Кто выполняет работу?
Организационная структура компании: организационные единицы, должности, лица и связи между ними.
В нашем примере
Менеджер подтверждает условия, кладовщик собирает товар, координатор организует доставку.
Инструментальная методология целостного моделирования и оптимизации бизнес-процессов и информационных систем. Устроена «домом ARIS»: пять видов — Data, Function, Organization, Product/Service и Control — на трёх уровнях описания; именно Control view, собирающий связи между остальными, руководство называет тем, что отличает ARIS от прочих подходов.
Заказ идёт через продажи, склад и доставку. Схема шагов есть, но на ней не видно, кто отвечает за каждый шаг, какие данные ему нужны и что в итоге получает клиент. Попытка дорисовать всё это на одном листе даёт полотно, которое никто не читает.
У одного процесса четыре стороны, и у каждой свои хозяева. Оргструктуру знает кадровая служба, данные — те, кто ведёт учётную систему, порядок шагов — исполнители, результат для клиента — продажи. Если рисовать всё вместе, схема перегружается; если по отдельности — через полгода четыре схемы расходятся, и вопрос «кого затронет смена роли кладовщика» решается опросом коллег. ARIS предлагает третий путь: описывать каждую сторону отдельно, на своём виде, а связи между ними держать в пятом, управляющем виде. Руководство по методу прямо называет этот вид тем, что отличает ARIS от других подходов.
В раздатке — устройство дома ARIS: пять видов, три уровня описания и то, как процесс собирается из них. Дальше 48 карточек типов моделей из 55, что есть на странице реестра, — от дерева функций и организационной схемы до EPC и клиентских путей, — 12 понятий с бытовыми аналогиями, учебный разбор обработки заказа и план первой недели. Метод существует рядом с одноимённым программным продуктом; здесь речь о методе в том виде, как он изложен в руководстве ARIS 10 Method Manual редакции апреля 2026 года.
Центральная нотация метода — событийная цепочка процессов (event-driven process chain, EPC). В ней события и функции чередуются: событие «заказ получен» запускает функцию «проверить заказ», а её результат снова становится событием — «заказ проверен» или «заказ отклонён». Именно к функциям EPC потом привязывают исполнителей, данные, системы и результаты. Так один и тот же процесс читается и как порядок шагов, и как ответ на вопрос, что изменится, если заменить роль или систему.
Дом ARIS нужен, чтобы каждую сторону процесса обсуждать с теми, кто в ней разбирается, а потом собрать эти разговоры в одну картину, где видно, что от чего зависит.
Исследуйте основные части: у каждой свой вопрос, смысл и место в примере.
Выберите элемент схемы — откроются объяснение и пример.
Организационная структура компании: организационные единицы, должности, лица и связи между ними.
Менеджер подтверждает условия, кладовщик собирает товар, координатор организует доставку.
Учебная раскладка пяти представлений ARIS. Выберите часть дома. Подробности EPC и других моделей открываются в связанных карточках.
Авторский учебный пример. Организация и решения придуманы для объяснения подхода; это не обязательный порядок работ из стандарта.
Согласуем роли, основные функции и смысл заказа как информационного объекта.
Названия одинаково понимаются продажами и складом.
Связываем события и функции, показываем альтернативы успешной проверки и отказа.
Видно, почему процесс идёт по каждой ветви.
Привязываем исполнителей, данные, приложения и результаты к нужным функциям.
Можно оценить влияние изменения роли или системы на процесс.
Онтология предприятия и метод инженерии предприятия. Существенная модель предприятия складывается из четырёх аспект-моделей: кооперации (CM), действий (AM), процессов (PM) и фактов (FM). Фирменное разведение — координационный мир и производственный мир: PM задаёт пространство состояний и переходов координационного мира, FM — производственного, а CM и AM покрывают оба. Кооперация описывается через транзакторные роли акторов и координационные структуры между ними.
Единый язык моделирования корпоративной архитектуры от The Open Group. В редакции 4 язык разложен не по слоям, а по доменам: четыре домена ядра — Common, Business, Application и Technology — плюс Motivation, Strategy и Implementation and Migration. Для каждого домена задан свой набор элементов, а все разрешённые отношения сведены в нормативное приложение B. Отдельного домена для информации и данных язык не заводит намеренно: информация моделируется сквозь домены элементами пассивной структуры. Реестр держит редакцию 4 и рядом 70 строк редакции 3.2 — из сводной матрицы школ старая редакция исключена.
Событие описывает состояние, функция — выполняемую работу. Формулировки «заказ проверен» и «проверить заказ» выполняют разные роли в EPC.
Перед проработкой согласуйте вопрос: Кто выполняет работу? Ответ должен быть понятен участникам рассматриваемой работы.
Пройдите весь пример от исходной ситуации до результата: Можно оценить влияние изменения роли или системы на процесс.
Общие оси — нейтральные названия частей предприятия: деятельность, данные, приложения, инфраструктура и другие. Здесь показано, какие элементы подхода сопоставлены с этими осями и насколько совпадает их охват.
Есть сопоставление с 5 осями из 17
| Ось реестра | В ARIS | Сопоставление | Пояснение |
|---|---|---|---|
| Информация и данные | Data Viewточка зрения | Охват тот же, что у оси. | Представление данных. |
| Деятельность: функции и процессы | Function Viewточка зрения | Охват тот же, что у оси. | Функциональное представление. |
| Организация и ответственность | Organization Viewточка зрения | Охват тот же, что у оси. | Организационное представление. |
| Продукты, услуги и ценность | Product/Service Viewточка зрения | Охват тот же, что у оси. | Представление продуктов и услуг. |
| Интеграция и взаимодействие | Control Viewточка зрения | Охват тот же, что у оси. | Управляющее (интеграционное) представление: его предмет — связи между остальными четырьмя представлениями. Это и есть домен интеграции и взаимодействия. |
| Делит по другому признаку | Requirements Definition · Design Specification · Implementationизмерение | Вне общих осей | Уровень описания, а не фаза жизненного цикла: ARIS 10 Method Manual §2.3 говорит прямо — «the ARIS lifecycle model is not to be understood as a procedure model for developing an information system. It rather serves to define the various descriptions that differ in their proximity to information technology», и там же: у уровней разная частота обновления, то есть они существуют одновременно, а не сменяют друг друга. Переведено 2026-09-07. |
Полное описание предприятия — работа на месяцы. Первый полезный результат получается за пять рабочих дней, если не пытаться описать всё сразу.
Выпишите функции верхнего уровня одного сквозного процесса — для заказа это приём, проверка, резервирование, сборка, доставка — и расставьте их в порядке создания ценности. Это диаграмма цепочки добавленной стоимости (value-added chain diagram), функциональный вид. Получится каркас, к которому дальше привязываются все остальные модели.
Нарисуйте участников процесса: организационные единицы, должности, при необходимости роли. Только тех, кто участвует в выбранном процессе, а не всю компанию. Это организационный вид; из него на третий день возьмутся исполнители функций.
Раскройте одну функцию цепочки — например, проверку заказа — в событийную цепочку процессов. Чередуйте события и функции, развилки помечайте логическими операторами: «заказ проверен» ведёт к резервированию, «заказ отклонён» — к уведомлению клиента. К функциям привяжите должности из организационной схемы.
Согласуйте информационные объекты процесса — заказ, клиент, товар, отгрузка — в расширенной модели «сущность — связь» (eERM); если в подразделениях один объект зовут по-разному, начните с модели профессиональных терминов (technical terms model). Затем на диаграмме распределения функции (function allocation diagram) укажите, что каждая функция EPC берёт на входе и отдаёт на выходе.
Добавьте типы прикладных систем, в которых выполняются функции, и продукт или услугу, которые получает клиент, — дерево продуктов и услуг (product/service tree). Теперь у каждой функции есть исполнитель, данные, система и результат. Проверьте модель вопросом из примера: что изменится, если заменить роль или систему.
Первая же EPC на сорок функций делает модель нечитаемой, а соседние процессы — островами. Сначала диаграмма цепочки добавленной стоимости (value-added chain diagram): десяток функций верхнего уровня в порядке создания ценности. Каждая из них потом раскрывается в свою EPC, и границы между процессами определены заранее.
В EPC уровня требований появляются таблицы базы данных и имена серверов — и модель устаревает с первым релизом. Держите уровни раздельно: на уровне требований — сущности и типы прикладных систем, на уровне реализации — таблицы и конкретные системы. Связь между уровнями метод задаёт явно, и её лучше провести, чем перемешать.
Обе нотации есть среди типов моделей ARIS. EPC через чередование событий и функций показывает, почему процесс пошёл по той или иной ветви. BPMN привычнее для тех, кто передаёт схему в исполнение или в другой инструмент. На практике команды выбирают одну нотацию как основную и не смешивают их в одном процессе.
Нет. Метод описан в официальном руководстве, и первую неделю можно пройти в любом редакторе моделей, где типы объектов задаются явно. Инструмент становится нужен, когда моделей десятки и связи между видами — исполнитель, данные, система — надо проверять автоматически, а не глазами.
ArchiMate — язык для архитектуры предприятия: связывает услуги, процессы, приложения и оборудование крупными элементами, без шагов внутри процесса. ARIS — метод, в центре которого сам процесс с его событиями, функциями и окружением. Если нужна карта систем и их связей с бизнесом, ближе ArchiMate; если нужно подробно описать, как идёт работа и кто с какими данными её делает, — ARIS.
15 страниц: что это и чем не является, устройство подхода, 5 карточек словаря, 12 понятий с аналогиями, учебный пример и план первой недели.
Пришлём ссылку сразу после отправки формы
Дословные выписки из стандарта с переводом. Строки с пояснением простыми словами отмечены.
Понятия этого подхода с объяснениями, примерами и типичными ошибками.
Связь, которая показывает, какой исполнитель (ресурс) отвечает за выполнение конкретной деятельности.
Способ описания модели, при котором связи между элементами фиксируются в виде таблицы, а не на графической схеме.
Это модель, описывающая последовательность шагов обработки в программе.
Справочник терминов, который связывает технические названия объектов данных с общепринятыми словами компании.
Статическая иерархическая структура, описывающая состав продукта или услуги.
Иерархическая структура, в которой функции предприятия разложены по уровням детализации.
Подходы, которые описывают предприятие целиком — от стратегии и процессов до данных и ИТ-инфраструктуры: язык, рамка или метод со своей моделью.
Руководство прямо называет исходную концепцию: архитектура интегрированных информационных систем, разработанная А.-В. Шеером, с отсылкой к его работе 1992 года; полное изложение — там же и в «ARIS — Business Process Frameworks» 1998 года. Обе оси дома взяты оттуда же: деление на виды — по книге 1992 года, с. 13 и далее, три уровня описания — с. 16 и далее.
Перечень логических операторов событийной цепочки процессов (EPC) руководство возводит к работе Хоффмана, Кирша и Шеера 1993 года. Модель данных вида Data строится на модели «сущность — связь» Чена, которую руководство называет самым распространённым методом проектирования семантических моделей данных (Chen, 1976).
Руководство редакции 10 датировано апрелем 2026 года, копирайт — SAG ARIS GmbH, Саарбрюккен, 2010–2026. Истории версий самого руководства в нём нет.
Реестр процессов, архитектурное рабочее пространство, связи между системами и процессами — те самые артефакты, только про вашу организацию.
Это же в StormСравнение с другими системамиАрхитектура систем и интеграцийРеестр процессов