Для работы в среде ARIS необходимо сначала тщательно изучить соответствующий объект, что, в свою очередь, приводит к созданию простейшей модели бизнес-процесса, опирающейся в основном, на знание деятельности предприятия. Затем эта модель расширяется за счет дополнительных деталей. В итоге получается базовая модель бизнес-процесса в ARIS.
Б.1. Исходная модель бизнес-процесса
Поясним ключевые моменты описания бизнес-процессов на простом примере обработки заказов. Для начала изложим общий сценарий.
Допустим, потребитель хочет заказать изготовителю несколько изделий. На основе информации о клиенте и изделиях изучается вопрос о технической возможности и экономической целесообразности изготовления данных изделий. После поступления заказа у поставщика приобретаются необходимые материалы. После получения материалов и последующего планирования заказа предприятие изготавливает изделия в соответствии с графиком работ и отправляет их клиенту вместе с надлежащей документацией.
4 Бизнес процессы в Aris
Теперь рассмотрим этот сценарий с различных точек зрения.
В теории систем мы можем разграничить структуру системы и ее поведение. Начнем с описания субъектов (сущностей) ответственности и отношений, участвующих в бизнес-процессе, а затем опишем динамическое поведение при помощи последовательности функций. Выходные потоки описывают результаты выполнения процесса, а информационные потоки — обмен документами, участвующими в процессе.
Функции, производители выхода (организационные единицы), выходные и информационные объекты представлены различными символами. Потоки обозначены стрелками.
Б. 1.1. Субъекты ответственности и их отношения
На рис. 2а представлены субъекты ответственности (организационные единицы), участвующие в бизнес-процессе, причем для каждого из них показан выход, а также взаимосвязи (отношения) в виде контекстных диаграмм или диаграмм взаимодействия. Последовательность выполнения процессов здесь не отражена, тем не менее можно получить исходное представление о структуре бизнес-процесса.
В сложных процессах несметное множество обменов между различными деловыми партнерами подчас может привести в замешательство. Помимо различных взаимодействий, сюда можно ввести функции субъектов ответственности. На диаграмме это сделано лишь в нескольких местах.
Диаграммы взаимодействия широко применяются в теории бизнеса. Рис. 2б отражает довольно типичную картину взаимоотношений между клиентом, производителем и поставщиком и результаты (выходы) их взаимодействия.
Б. 1.2. Поток функций
На рис. 3 тот же бизнес-процесс описывается при помощи подлежащих выполнению функций с указанием их последовательности. Главная роль здесь отводится не субъектам ответственности, как это было на статичной диаграмме взаимодействия, а динамичной последовательности функций. Для наглядности на рис. 3 представлены и операционные единицы.
Из-за обилия элементов их взаимосвязь с диаграммой, приведенной на рис. 2б, здесь не столь очевидна.
Моделирование бизнес-процессов с помощью методологии ARIS (версия 10.0) для начинающих
Функциональные потоки представляют собой последовательности выполнения функций для создания выхода и, таким образом, они могут характеризовать бизнес-процесс. Сами выходные потоки будут показаны отдельно.
Рис. 2а. Диаграмма взаимодействия в бизнес-процессе «обработка заказа»
Рис. 2б. Общая диаграмма взаимодействия на предприятиях
Б. 1.3. Поток выходов
Цель бизнес-процесса состоит в создании выхода для получения вознаграждения в виде другого выхода. В нашем примере выходом производителя является выполнение заказа клиента, а вознаграждением — получение денежных средств, хотя в процессе производства создается также промежуточный выход, возникающий в результате выполнения функций.
Понятие «выход» весьма неоднозначно. В наиболее общем смысле выход в бизнесе есть результат производственного процесса. Выход может быть физическим (материальный выход) и нефизическим (услуги). В то время как материальный выход легко поддается определению (например, доставка материала, изготовленные детали или даже готовый продукт), с понятием «услуги» дело обстоит сложнее, поскольку оно охватывает услуги самого разнообразного характера. Вот лишь некоторые примеры:
театральные представления (драматические спектакли, концерты), где выходом является исполнение на сцене; потребление этого выхода происходит одновременно с его созданием;
банковские услуги в виде займов или кредитов; в этом случае услуга состоит в предоставлении необходимых денежных средств и сама по себе является результатом других банковских услуг (проверка кредитоспособности, услуги по депозиту и т. д.);
услуги по страхованию;
услуги государственного сектора (выдача водительских удостоверений, удостоверений личности и т. д.).
Немаловажная характеристика выхода — его востребованность стороной, не являющейся его производителем. Иными словами, на данный выход должен быть спрос. Необходимыми предпосылками служат поступление заявки от клиента и наличие договоренности о цене.
На каком уровне существует здесь отношение клиент-поставщик — между внешними деловыми партнерами или между внутренними организационными единицами, — значения не имеет. Цена может быть рыночной, либо речь может идти лишь о внутрифирменных расчетах. Кроме того, несущественно, имеем ли мы дело с запрашиваемой ценой или фактически уплачиваемой. Если сторона, приобретающая услугу, осознает ее денежную стоимость — этого достаточно. Внутрифирменные услуги, так же, как и некоторые внешние услуги государственного сектора, иногда предоставляются бесплатно.
Для повышения прозрачности выхода существует тенденция к описанию внутрифирменного выхода и начислению соответствующей стоимости. Так же обстоит дело и в государственном секторе. На рис. 4 под символом каждого выхода указана создающая его функция.
В данном случае выходом являются информационные услуги, например, «проверенный заказ», «производственный план», «заказ», «документация на заказ», «заказ на отправку». Изделия же, представляющие собой непосредственный результат процесса производства, рассматриваются как материальный выход. Доставленные изделия — результат услуги «транспортировка».
На рис. 4 показан результат процесса «изготовление изделия», т. е. материальный выход в виде изготовленного изделия. Аналогичным образом в процессе изготовления выполняется и документируется проверка качества. Все данные, относящиеся к заказчику, фиксируются в «документации на заказ», которая сама по себе является услугой по предоставлению информации.
После каждой внутрифирменной функции описывается поставляемый ею выход, который в свою очередь поступает в следующий процесс уже в качестве входа. Чтобы не перегружать диаграмму, организационные единицы на рисунке опущены. Приведенная иллюстрация выходного потока не позволяет однозначно описать последовательность выполнения функций.
Б.1.4. Информационный поток
Помимо информационных услуг, компонентами процесса являются и другие данные, используемые для описания инфраструктуры бизнес-процессов.
Рис. 3. Поток функций в бизнес-процессе «обработка заказа»
Рис. 4. Поток выходов в бизнес-процессе «обработка заказа»
На рис. 5 представлены информационные объекты бизнес-процесса и данные, которыми они обмениваются. Объекты, отнесенные к разряду информационных услуг, обведены двойной рамкой. Показаны также информационные объекты, описывающие контекстную среду бизнес-процесса, например, данные, касающиеся поставщиков, изделий или графиков работы.
Эти данные необходимы для создания информационных услуг. Например, при проверке заказов проверяется кредитоспособность заказчика и наличие материально-производственных запасов.
Каждый информационный объект имеет свое имя. Ему можно присвоить и другие атрибуты, но для экономии места они здесь опущены. Функции процесса, работающие с информационными объектами, являются частью объектов, предоставляющих информационные услуги.
Можно соотнести функции и с другими информационными объектами, однако это будут уже подфункции по отношению к функциям процесса, рассматривавшимся до сих пор, поэтому на рис. 5 они не показаны. Например, детальную функцию «проверка кредитоспособности» можно соотнести с информационным объектом КЛИЕНТ в рамках функции процесса «проверка заказа».
Поскольку поток данных активизируется функциями, связанными с информационными объектами, функциональный поток на рис. 5 более или менее просматривается. Однако если один информационный объект обрабатывается несколькими функциями или если одна функция требует нескольких потоков данных, то однозначно проследить функциональный процесс невозможно.
Источник: infopedia.su
Построение моделей бизнес процессов в ARIS
Лекция: Построение моделей бизнес-процессов в ARIS Лекция по курсу «Реинжиниринг бизнес-процессами» Описание потока работ бизнес-процесса описания (модели) процесса должны содержать: последовательность выполняемых операций, ответственность за выполнение операций, информационные и материальные потоки процесса, Модели потоков работ в ARIS Цепочка добавленной стоимости/ценности (Value-Added Chain), Цепочка процесса, управляемая событиями (Event-driven Chain, EPC), Офисный процесс (Office process), Процессная цепочка (Process Chain Diagram, PCD), Диаграмма BPMN Цепочка добавленной стоимости Процесс 1 Процесс 2 Процесс 3 определяет логическую последовательность процессов, выполняемых при создании продукта или услуги (добавленной ценности, стоимости) для клиента цель: выявить максимальное количество производительных процессов, т.е. таких процессов, которые добавляют ценность к конечному продукту (услуге) для клиента Типовые процессы, добавляющие ценность Цепочка добавленной ценности может формироваться на основе процессов жизненного цикла продукта/услуги: процессы исследования рынка процессы разработки продукта/услуги процессы планирования ресурсов процессы привлечения клиентов процессы закупки материалов (комплектующих) процессы производства процессы продажи (сбыта) продукта/услуги процессы послепродажного обслуживания Пример цепочки доб. ценности (длинной) Полная цепочка доб. ценности Основная (длинная) цепочка обычно дополняется декомпозицией главного процесса цепочки – процесса обслуживания клиента в объеме идентификации процесса (процесс продажи): Цепочка процесса, управляемая событиями (EPC) Event-driven Process Chain (EPC) – нотация моделирования, созданная проф. А.-В.
Шеером в рамках методологии ARIS, как средство более точной идентификации бизнес-логики процесса отличительная особенность – определение потока работ на основе событий, возникающих во время выполнения процесса основная логика цепочки: происходящие события вызывают выполнение определенных действий (функций) процесса, что в свою очередь приводит к возникновению новых событий Пример EPC Правила построения EPC (1) Цепочка EPC формируется путем чередования событий и функций – происходящие события вызывают выполнение функций, что приводит к возникновению новых событий например, событие «Клиент обратился в фирму» приводит к выполнению сотрудниками фирмы функции «Консультирование клиента», результатом чего является возникновение события «Клиент сформировал требования к компьютеру» Цепочка EPC всегда начинается и заканчивается событиями Правила построения EPC (2) Каждое событие может иметь не более одного, а функция – обязательно по одному входному/выходному потоку управления. Поэтому для обозначения альтернативных и/или параллельных потоков на развилках и слияниях потока работ должны использоваться знаки бизнес-логики (правила): — логическое «И» для обозначения параллельных потоков, — логческое «исключающее ИЛИ» для обозначения альтернативных потоков другие логические операции Правила построения EPC (3) На альтернативных развилках перед значком «искл.
ИЛИ» всегда должна стоять функция, а после – альтернативные события. При слиянии наоборот – до «искл. ИЛИ» стоят альтернативные события, после стоит функция.
Окружение функции определяет исполнителя функции и входные/выходные информационные сущности (носители): Заказ клиента Менеджер по продажам Начальник отдела продаж Оформление плана-графика accepts План-график Правила построения EPC (4) За каждой функцией должен быть закреплен ответственный исполнитель (тип связи – «выполняет»), и такой исполнитель должен быть только один для функции. Остальные типы связей между функцией и оргединицей могут быть использованы нелимитированно. Заказ клиента Менеджер по продажам Начальник отдела продаж Оформление плана-графика accepts План-график Полная модель EPC Обратился клиент Прайс-лист Выбор конфигурац ии клиентом Менеджер по продажам Заявка клиента Клиент выбрал конфигур. Проверка выполнимости заявки клиента Поступили комплектующ ие по отложенной. Заявка невыполни ма Заявка выполнима Менеджер по продажам Заявка клиента Менеджер по продажам Оформление заказа Заказ оформлен Клиент изменил заявку под имеющиеся. Заказ клиента Согласовани е заявки с клиентом Клиент согласился ожидать комплектую. Рабочий день окончен Менеджер по продажам принимает Начальник отдела продаж Менеджер по продажам Начальник отдела продаж Оформление планаграфика План-график оформлен Заявка клиента Оформление заявки на докупку комплектующих Заявка оформлена Заказ клиента принимает Клиент отказался от заказа Планграфик Заявка на закупку
В закладки
Разместил пособие
Эксперт по предмету «Бизнес-планирование»
Поделись лекцией и получи скидку 30% на платформе Автор24
Заполни поля и прикрепи лекцию. Мы вышлем промокод со скидкой тебе на почту
Твоя лекция отправлена! Жди скидку на почте. Есть еще материалы? Загрузи прямо сейчас
Загрузить еще лекции
Поделись лекцией и получи промокод на скидку 30% на платформе Автор24
Заполни поля и прикрепи лекцию. Мы вышлем промокод со скидкой тебе на почту
Твоя лекция отправлена! Жди скидку на почте. Есть еще материалы? Загрузи прямо сейчас
Источник: spravochnick.ru
Методология ARIS. Моделирование бизнес-процесса
Методология ARIS фокусируется на этапах анализа и определения требований при проектировании информационных систем управления. Это многоуровневый подход с несколькими представлениями, в котором основное внимание уделяется вопросам, связанным с бизнесом. Каждое представление дополнительно детализировано со ссылкой на этапы жизненного цикла программного обеспечения в определении требований к уровням, спецификации проекта и описанию реализации. Диаграммы цепочек процессов поддерживают интегральное описание бизнес-процессов на сравнительно агрегированном уровне.
Модель АРИС Framework
Вам будет интересно: Как установить Realtek HD на Windows 7 или в аналогичных модификациях и выполнить некоторые основные настройки?
Концепция АРИС (Архитектура интегрированных информационных систем) Августа-Вильгельма Шеера направлена на то, чтобы создать информационную систему предприятия, полностью соответствующую ее бизнес-интересам и современным экономическим требованиям.
Структура основывается на создании модели представления и уровней описания, что позволяет описывать отдельные элементы с помощью специально разработанных способов. Методология ARIS является перспективным направлением разработки систем для оптимизации бизнеса. Они отображаются для каждого представления описания на уровне обработки данных, начиная с вопроса управления бизнесом и заканчивая реализацией товаров и услуг.
Вам будет интересно: В диспетчере задач диск на 100% загружен: что делать, решение
ARIS опирается главным образом на собственную архитектуру с пятью видами — «АРИС дом». Эти пять представлений являются:
- организационной моделью;
- управленческой моделью;
- моделью данных;
- функциональной моделью;
- выходной(сервисной) моделью.
Классификация выполнена таким образом, чтобы разбить сложность модели на пять аспектов и тем самым упростить моделирование. Каждое представление концепции ARIS (architecture of integrated information) systems демонстрирует модель бизнес-процесса в определенном аспекте:
Реинжиниринг бизнес-процессов
Реорганизация бизнес-процессов является ключевым вопросом для компаний по восстановлению конкурентоспособности и прибыльности на все более нестабильных рынках. Ориентированные на клиента предприятия должны быть структурированы в соответствии с их основными процессами и строго ориентированы на ценность.
Вам будет интересно: Как изменить размер диска в Windows 10: порядок действий, программы
Управление рабочими процессами все в большей степени основывается на совместных, распределенных приложениях, которые, с одной стороны, нуждаются в реинжиниринге, чтобы быть эффективными, а с другой стороны, используют модели в качестве спецификации для контроля за его выполнением.
Отсутствие мощных инструментов, а также методологические недостатки, особенно в том, что касается захвата логики и динамики сложных процессов, являются основными препятствиями для успешной реорганизации бизнес-процессов.
Подход ARIS обеспечивает не только общую и хорошо документированную методологическую основу, но и мощный инструмент моделирования, который поддерживает процесс реинжиниринга на этапах жизненного цикла. В исследовательском проекте он интегрирован с прототипом системы управления рабочими процессами, чтобы улучшить повторное использование моделей для реализации приложений.
Концепция жизненного цикла
Структуры методологии моделирования бизнес-процессов и концепции жизненного цикла появились в различных прикладных областях, таких как Computer Integrated Manufacturing (CIM), автоматизация делопроизводства и проектирование информационных систем.
Методологии и структуры часто основаны на неявных предположениях относительно их объема, цели и уровня детализации. Но есть и другой аспект, который приводит к большому разнообразию подходов. Им является тот факт, что способность методологии ARIS очень сильно зависит от цели.
Некоторые усилия по нему могут быть по своей природе описательными, в то время как в других случаях требуется оптимизированное решение для реализации. В последнем случае анализ процесса должен поддерживаться инструментами формальной оценки, такими как моделирование. Это требует однозначного описания процесса и сбора сведений о бизнес-процессе.
Динамическое поведение
В настоящее время ощущается необходимость согласования различных подходов, выявления общих черт и объединения различных методологий и структур.
Динамическое моделирование бизнес-процессов будет становиться все более важным в будущем. Переход от массового производства к массовой настройке IS-дизайна и растущий интерес к низкоуровневым системным спецификациям требуют четко определенных моделей.
Для этого необходимо иметь представление о природе процессов, чтобы модифицировать и реконфигурировать их. Они помогают выявлять и устранять недостатки в логике и также могут служить в качестве спецификации процесса программного обеспечения для проектирования информационных систем.
Динамическое поведение бизнес-процессов ясно показывает «организационный уклон». Модели накладываются на поведение человека. Это поведенческое искажение может только частично быть представлено формальными подходами моделирования, происходящими из области IS. Методология ARIS должна включать такие аспекты, как человеческие роли, обязанности и неформальное общение.
Эталонная модель
Другим аспектом моделирования бизнес-процессов, требующим дальнейших исследований, является тема эталонных моделей — блока частичного моделирования. Это неполное представление системы с данной точкой зрения, служащей определенной цели для конкретных пользователей. Эталонные модели являются информационным ресурсом организации и образуют базу ноу-хау. Преимущества моделей: ускоренные процессы моделирования, экономия затрат и времени, улучшение качества — подчеркивают необходимость в применении.
Вам будет интересно: В Windows 10 тормозит интернет: типичные ситуации и методы устранения возможных проблем
Модели процессов являются основой для разработки корпоративных приложений. В то время как они описывают структуру и логику на уровне типа, приложение потока операций поддерживает выполнение отдельных процессов на уровне экземпляра. Определение структуры в системах управления базами данных (СУБД) приводит к конкретной БД, а модели — к приложению рабочего процесса. В отличие от генерации программного кода из моделей, как это предусмотрено в классических подходах CASE, разработка приложений основана на конфигурации существующих строительных блоков ПО и, следовательно, поддерживает повторное его использование.
Разработка рабочих процессов
Аппаратная платформа ARIS поддерживает разработку приложений рабочих процессов. Определение требований следует основным бизнес-ориентированным, а не техническим целям. Во время определения требований рассматриваются такие аспекты, как время, затраты, частота, избыточность и другие.
После анализа текущего состояния разрабатываются различные альтернативы, описывающие, как можно выполнить улучшения. В зависимости от того, какие решения рассматриваются для достижения выбранной альтернативы, можно различать организационные, личные или технические подходы либо их композицию.
С технической точки зрения можно исследовать модели в отношении того, какая информационная система необходима. На основе моделей можно указать тип, необходимый для поддержки процесса: управление документами, интеграция приложений баз данных и другие. Поэтому все представления должны быть интегрированы в модель процесса: данные, организация и функции.
Поскольку обработка исключений является центральной проблемой в приложениях на уровне определения требований, исключения могут рассматриваться через определение специальной диаграммы. Если модели процессов определены и утверждены в качестве исходных данных для разработки приложений рабочих процессов, их можно уточнить на следующем уровне.
Спецификация проекта
Функции, которые будут автоматизированы приложением, должны быть указаны на детальном уровне. Если функции выполняются программой, нет необходимости указывать их очень подробно. Выполняемые вручную функции должны быть указаны в виде списков задач. Поэтому используют деревья функций, которые должны быть показаны в качестве справочной информации в приложении.
Поток данных описывается на уровне определения требований, главным образом, в виде кластеров и функций. Во время разработки проекта эти кластеры должны быть определены более подробно относительно сущностей. Для подробного описания потока данных необходимо определить диаграмму потока данных.
В организационных единицах описанные в модели процессы часто находятся на абстрактном уровне. Приложения рабочего процесса используют концепцию роли. Роли описывают возможности, которые человек должен иметь для выполнения определенной должностной функции. В соответствии с такими ролями во время выполнения приложения люди могут выполнять определенные шаги. Эта концепция должна быть рассмотрена.
Помимо описанных аспектов, важно точно определить события и узлы принятия решений, а также указать параметры для интеграции программ.
Описание реализации
На уровне описания реализации необходимо адаптировать данную информационную инфраструктуру к распределенной интегрированной концепции приложения рабочего процесса на основе модели, являющейся результатом спецификации проекта.
Модели используются для настройки приложения. Их можно понимать как графическую программу. Благодаря такому повторному использованию ручное программирование программного кода уменьшается.
Не любая модель поддерживает графическое определение приложений. Выходящие из описания реализации могут использоваться в качестве основы для «нормальной» работы, выполняемой программистами. Инструментальная поддержка моделирования требует компьютерных средств для представления и обработки эталонных моделей. Основными функциями модельной системы управления являются:
Основные правила методологии ARIS
Как правило, разработчик начинает с события, если выстраивает EPC. Ряд мероприятий может следовать за событием. В прошлом говорили, что события и мероприятия должны чередоваться. Это приводит к очень длинным моделям процессов с большим количеством мелочей, поэтому сегодня предлагается добавлять событие только в том случае, если необходимо документировать важные изменения состояния.
Рекомендации по использованию событий:
Правила могут быть использованы следующим образом:
В EPC можно использовать следующие правила:
АРИС: набор инструментов
Набор ARIS-Tool обеспечивает комплексную компьютерную поддержку моделирования. Четыре модуля предоставляют средства для автоматизированного анализа, планирования и внедрения управленческих информационных систем. Такой подход охватывает весь жизненный цикл моделирования. Рассмотрим подробнее:
Express. Официальное ПО
Вам будет интересно: Как скачивать приложения на «Самсунг Смарт ТВ»: установка и настройка
«АРИС Экспресс 2», er модель — программа, выпущенная для операционных систем на базе Microsoft Windows. Также она работает в других ОС, таких как Mac OS X или Linux.
Для загрузки программы:
Программа имеет очень продвинутую бесплатную функцию ARIS Cloud. Это полномасштабный продукт для анализа бизнес-процессов, который как услуга предоставляется совершенно бесплатно для исследовательских и образовательных целей. Он поддерживает совместные проекты по улучшению процессов и доступен для 1000 пользователей одновременно по всему миру. С бесплатной пробной версией software ag ARIS Cloud бесплатная подписка длится 30 дней. С AERIS Cloud для студентов бесплатная подписка длится 3 месяца.
EPC предлагает множество способов для моделирования процессов, их анализа и определения потенциалов улучшения. Модель EPC непосредственно встроена в интерактивный просмотрщик моделей. Можно скачать его и редактировать бесплатно модели в ARIS Express 2 er. Также можно использовать предоставленные видеоуроки, чтобы найти легкий путь в мир АРИС.
Процессы преобразования в XPDL
Для моделирования процессов, которые должны быть преобразованы в XPDL, используют ARIS версии 6.2.
При установке и настройке ARIS запускают программу ARIS Toolset:
На пути к по-настоящему интегрированным предприятиям нет простых путей или кратчайших путей. Неоправданные упрощения на этапе анализа бизнес-процессов и интеграции являются существенным риском для внедрения интегрированных систем.
Инструменты ARIS консолидируют методологические структуры, что является важной предпосылкой для полной интеграции от реорганизации коммерции до внедрения информационных систем. Особенно подробно описаны эти процессы в книге Августа Вильгельма Шеера «Моделирование бизнес-процессов». Изучение основ помогает создать информационную модель, которая является краеугольным камнем систематического и интеллектуального метода разработки прикладных систем.
Источник: ruud.ru