Бизнес-моделирование

Содержание

Слайд 2

Жизненный цикл программного обеспечения (ЖЦ ПО) ЖЦ ПО определяется как период

Жизненный цикл программного обеспечения (ЖЦ ПО)
ЖЦ ПО определяется как период времени,

который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия их эксплуатации.
Слайд 3

Обычно в состав ЖЦ включаются следующие стадии: 1. Формирование требований к

Обычно в состав ЖЦ включаются следующие стадии:

1. Формирование требований к ПО;
2.

Проектирование;
3. Реализация;
4. Тестирование
5. Ввод в действие;
6. Эксплуатация и сопровождения.
7. Снятие к эксплуатации
Слайд 4

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

Бизнес-процесс

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

позволяет получить конечный результат (товар или услугу).
Классифицировать бизнес-процессы можно следующим образом:
основные;
вспомогательные
Слайд 5

Основные бизнес-процессы - это процессы, которые создают то главное, ради которого

Основные бизнес-процессы - это процессы, которые создают то главное, ради которого

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

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

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

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

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

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

проектированию новых процессов.
Слайд 8

Цели описания и формализации бизнес-процессов предприятия: Определение перечня функций, подфункций, работ

Цели описания и формализации бизнес-процессов предприятия:

Определение  перечня функций, подфункций, работ  в

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

Наиболее распространенные типы диаграмм SADT (Structured Analysis and Design Technique) -

Наиболее распространенные типы диаграмм

SADT (Structured Analysis and Design Technique) - модели

и соответствующие функциональные диаграммы;
DFD (Data Flow Diagrams) - диаграммы потоков данных;
WFD (Work Flow Diagram) - диаграммы потока событий;
ERD (Entity-Relationship Diagrams) - диаграммы «сущность-связь».
Слайд 10

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

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

такие как:

DFD (Data Flow Diagrams) – диаграммы потоков данных;
SADT (Structured Analysis and Design Tecnique – метод структурного анализа и проектирования) – модели и соответствующие функциональные диаграммы;
ERD (Entity-Relationship Diagrams) – диаграммы "сущность-связь";
STD (State Transition Diagrams) – диаграммы перехода состояний;
Семейство IDEF (Integration Definition for Functin Modeling) - методология функционального моделирования.

Слайд 11

Методология функционального моделирования SADT

Методология функционального моделирования SADT

Слайд 12

Методология функционального моделирования SADT Разработана Дугласом Т. Россом Исходная работа над

Методология функционального моделирования SADT

Разработана Дугласом Т. Россом
Исходная работа над

SADT началась в 1969 г.
Первое ее крупное приложение было реализовано в 1973 г. при разработке большого аэрокосмического проекта, когда она была несколько пересмотрена сотрудниками SofTech, Inc.
В 1974 г. SADT была еще улучшена и передана одной из крупнейших европейских телефонных компаний.
Слайд 13

Появление SADT на рынке произошло в 1975 г. после годичного оформления

Появление SADT на рынке произошло в 1975 г. после годичного оформления

в виде продукта.
1981 г. - программа автоматизации промышленных предприятий ICAM (Integrated Computer Aided Manufacturing), предложенной департаментом Военно-Воздушных Сил США.
Семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF - ICAM DEFinition).
1993 г. - SADT было принято в качестве федерального стандарта США под наименованием IDEF0 .
Слайд 14

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

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

построения функциональной модели объекта какой-либо предметной области.
Слайд 15

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

Основные элементы этой методологии основываются на следующих принципах:
Графическое представление блочного

моделирования
Строгость и точность.
Слайд 16

Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов

Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов

текстов и глоссария, имеющих ссылки друг на друга.
Слайд 17

IDEF0 (Integration Definition for Function Modeling) - методология функционального моделирования, в

IDEF0 (Integration Definition for Function Modeling) - методология функционального моделирования, в

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

В основе методологии лежат четыре основных понятия: Понятие функционального блока (Activity

В основе методологии лежат четыре основных понятия:

Понятие функционального блока (Activity Box).


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

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

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

Слайд 20

Слайд 21

Функциональный блок «Обработать заготовку»

Функциональный блок «Обработать заготовку»

Слайд 22

Внесение изменений в технологические указания

Внесение изменений в технологические указания

Слайд 23

www.microafrica.co.za/tass/idef0.htm

www.microafrica.co.za/tass/idef0.htm

Слайд 24

Блоки размещаются по степени важности, это называется доминированием.Наиболее доминирующий блок (с

Блоки размещаются по степени важности, это называется доминированием.Наиболее доминирующий блок (с

номером 1) размещается в левом верхнем углу диаграммы, наименее (2,3..– в правом нижнем).
Слайд 25

2. Интерфейсная дуга Arrow Каждая интерфейсная дуга должна иметь свое уникальное

2. Интерфейсная дуга Arrow

Каждая интерфейсная дуга должна иметь свое уникальное наименование

(Arrow Label), должно быть выражено существительным.
Графическим отображением интерфейсной дуги является однонаправленная стрелка.
В зависимости от того, к какой из сторон подходит данная интерфейсная дуга, она носит название «входящей», «исходящей» или «управляющей».
Слайд 26

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

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

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

Любой функциональный блок по требованиям стандарта должен иметь по крайней мере


Любой функциональный блок по требованиям стандарта должен иметь по крайней мере

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

Типы диаграмм Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет

Типы диаграмм

Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой

функциональный блок с интерфейсными дугами, простирающимися за пределы рассматриваемой области.
Диаграмма обозначается идентификатором “А0”.
Слайд 29

Слайд 30

Типы диаграмм Диаграмма декомпозиции - после описания системы в целом проводится

Типы диаграмм

Диаграмма декомпозиции - после описания системы в целом проводится на

другой диаграмме разбиение ее на крупные фрагменты (2-8, по умолчанию 4).
Слайд 31

Слайд 32

Слайд 33

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

Понятие глоссарий

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

существующий стандарт, который подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом.
Слайд 34

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

Принципы ограничения сложности IDEF0-диаграмм


Ограничение количества функциональных блоков на диаграмме

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

В IDEF0 различают пять типов стрелок: Вход (Input) - материал или

В IDEF0 различают пять типов стрелок:

Вход (Input) - материал или информация,

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

В IDEF0 различают пять типов стрелок: Управление (Control) - правила, стратегии,

В IDEF0 различают пять типов стрелок:

Управление (Control) - правила, стратегии, процедуры

или стандарты, которыми руководствуется работа.
каждая работа должна иметь хотя бы одну стрелку управления
стрелка управления рисуется как входящая в верхнюю грань работы.
Слайд 37

В IDEF0 различают пять типов стрелок: Выход (Output) - материал или

В IDEF0 различают пять типов стрелок:

Выход (Output) - материал или информация,

которые производятся работой.
каждая работа должна иметь хотя бы одну стрелку выхода
работа без результата не имеет смысла и не должна моделироваться
стрелка выхода рисуется как исходящая из правой грани работы.
Слайд 38

Механизм (Mechanism) - ресурсы, которые выполняют работу, например персонал предприятия, станки,

Механизм (Mechanism) - ресурсы, которые выполняют работу, например персонал предприятия, станки,

устройства и т. д.
Стрелка механизма рисуется как входящая в нижнюю грань работы.
Слайд 39

В IDEF0 различают пять типов стрелок: Вызов (Call) - специальная стрелка,

В IDEF0 различают пять типов стрелок:

Вызов (Call) - специальная стрелка, указывающая

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

Слайд 41

Граничные стрелки Стрелки на контекстной диаграмме служат для описания взаимодействия системы

Граничные стрелки

Стрелки на контекстной диаграмме служат для описания взаимодействия системы с

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

В IDEF0 различают пять типов взаимодействия между блоками для описания их

В IDEF0 различают пять типов взаимодействия между блоками для описания их

отношений:

Связь по входу (output-input), когда стрелка выхода вышестоящей работы (далее - просто выход) направляется на вход нижестоящей

Слайд 43

Связь по управлению (output-control), когда выход вышестоящей работы направляется на управление

Связь по управлению (output-control), когда выход вышестоящей работы направляется на управление

нижестоящей.
Связь по управлению показывает доминирование вышестоящей работы.
Данные или объекты выхода вышестоящей работы не меняются в нижестоящей.
Слайд 44

Обратная связь по входу (output-input feedback), когда выход нижестоящей работы направляется на вход вышестоящей.

Обратная связь по входу (output-input feedback), когда выход нижестоящей работы направляется

на вход вышестоящей.
Слайд 45

Обратная связь по управлению (output-control feedback), когда выход нижестоящей работы направляется

Обратная связь по управлению (output-control feedback), когда выход нижестоящей работы направляется

на управление вышестоящей. Обратная связь по управлению часто свидетельствует об эффективности бизнес - процесса.
Слайд 46

Связь выход-механизм (output-mechanism), когда выход одной работы направляется на механизм другой.

Связь выход-механизм (output-mechanism), когда выход одной работы направляется на механизм другой.

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

Разветвляющиеся и сливающиеся стрелки Если стрелка именована до разветвления, а после

Разветвляющиеся и сливающиеся стрелки

Если стрелка именована до разветвления, а

после разветвления ни одна из ветвей не именована, то подразумевается, что каждая ветвь моделирует те же данные или объекты, что и ветвь до разветвления
Слайд 48

Разветвляющиеся и сливающиеся стрелки Если какая-либо ветвь после разветвления осталась неименованной,

Разветвляющиеся и сливающиеся стрелки

Если какая-либо ветвь после разветвления осталась неименованной,

то подразумевается, что она моделирует те же данные или объекты, что и ветвь до разветвления
Слайд 49

Недопустима ситуация, когда стрелка до разветвления не именована, а после разветвления

Недопустима ситуация, когда стрелка до разветвления не именована, а после разветвления

не именована какая-либо из ветвей.
Ошибкой будет считаться стрелка, которая после слияния не именована, а до слияния не именована какая-либо из ее ветвей.

Неверно!

Слайд 50

Количественный анализ диаграмм Количество блоков на диаграммах нижних уровней должно быть

Количественный анализ диаграмм

Количество блоков на диаграммах нижних уровней должно быть ниже

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

Ошибка!

Слайд 51

Слайд 52

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

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

анализировать их структуру и взаимосвязи;
Слайд 53

IDEF2 –динамическое моделирование развития систем. В связи с весьма серьезными сложностями

IDEF2 –динамическое моделирование развития систем.
В связи с весьма серьезными сложностями

анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе.
Слайд 54

IDEF3 – методология документирования процессов, происходящих в системе, которая используется при исследовании технологических процессов на предприятиях.

IDEF3 – методология документирования процессов, происходящих в системе, которая используется при

исследовании технологических процессов на предприятиях.
Слайд 55

IDEF4 – методология построения объектно-ориентированных систем (методология описания различных объектов в компании и действий над ними).

IDEF4 – методология построения объектно-ориентированных систем (методология описания различных объектов в

компании и действий над ними).
Слайд 56

IDEF5 – методология онтологического исследования сложных систем. Онтология – раздел философии, который изучает устройство реального мира.

IDEF5 – методология онтологического исследования сложных систем.
Онтология – раздел философии,

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

Диаграммы потоков данных DFD (Data Flow Diagrams) Диаграммы потоков данных (DFD)

Диаграммы потоков данных DFD (Data Flow Diagrams)

Диаграммы потоков данных (DFD)

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

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

Основные компоненты диаграмм потоков данных:

Внешняя сущность. Материальный объект или физическое лицо,

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

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

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

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

IDEF6 —— Обоснование проектных действий. Назначение IDEF6 состоит в облегчении получения

IDEF6 —— Обоснование проектных действий.

Назначение IDEF6 состоит в облегчении получения «знаний о

способе» моделирования, их представления и использования при разработке систем управления предприятиями. Под «знаниями о способе» понимаются причины, обстоятельства, скрытые мотивы, которые обуславливают выбранные методы моделирования.
Проще говоря, «знания о способе» интерпретируются как ответ на вопрос: «почему модель получилась такой, какой получилась?»
Метод IDEF6 акцентирует внимание именно на процессе создания модели;
Слайд 61

Слайд 62

Диаграммы потоков работ WFD (Work Flow Diagram) При описании бизнес-процессов нижнего

Диаграммы потоков работ WFD (Work Flow Diagram)  

При описании бизнес-процессов нижнего уровня

используются другие процессные схемы, под названием WFD – Work Flow Diagram, что переводится как диаграмма потоков работ.
На этой схеме появляются дополнительные объекты, с помощью которых описывается процесс: логические операторы, события начала и окончания процесса, а также элементы, показывающие временные задержки.
Слайд 63

Слайд 64

. Диаграммы "сущность ̶ связь" ERD (Entity ̶ Relationchip diagram) Диаграммы

. Диаграммы "сущность ̶ связь" ERD (Entity ̶ Relationchip diagram)  

Диаграммы "сущность-связь" (ERD),

впервые были введены Питером Ченом в 1976 г.
Базовыми понятиями ERD являются сущности, атрибуты, связи
Слайд 65

Сущностью (Entity) называют совокупность реальных или абстрактных объектов предметной области, обладающих

Сущностью (Entity) называют совокупность реальных или абстрактных объектов предметной области, обладающих

одинаковым набором свойств (атрибутами).
Сущность – это, как правило, существительное.
Отдельный элемент совокупности – экземпляр сущности.
Слайд 66

Класс сущностей и экземпляр сущности Класс сущностей Экземпляр сущности

Класс сущностей и экземпляр сущности

Класс сущностей

Экземпляр сущности

Слайд 67

Для сущностей имеют место следующие соглашения (правила): – каждая сущность должна

Для сущностей имеют место следующие соглашения (правила):

– каждая сущность должна иметь

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

История Нотация BPMN (The Business Process Modeling Notation) - это новый

История

Нотация BPMN (The Business Process Modeling Notation) - это новый стандарт

для моделирования бизнес процессов и сетевых услуг, который впервые был выпущен BPMI Notation Working Group в мае 2004 года.
Последняя версия нотации BPMN 2.0 вышла в 2010 году. Оригинальная спецификация (на английском языке) изготовлена группой компаний «Object Management Group».
Причины создания
необходимость построения ПРОСТОГО механизма для проектирования и чтения как простых, так и СЛОЖНЫХ моделей бизнес-процессов.
С точки зрения легкости чтения и понимания процессов нотация BPMN 2.0 вне конкуренции.
Моделирование в BPMN осуществляется посредством диаграмм с небольшим числом графических элементов. Это помогает пользователям быстро понимать логику процесса.
Слайд 69

Назначение нотации BPMN BPMN ориентирована : на технических специалистов (разработчиков, ответственных

Назначение нотации BPMN

BPMN ориентирована :
на технических специалистов (разработчиков, ответственных за реализацию

процессов),
на бизнес-пользователей (бизнес-аналитиков, создающих и улучшающих процессы)
на менеджеров, следящих за процессами и управляющих ими.
BPMN служит связующим звеном между фазой дизайна бизнес-процесса и фазой его реализации, так как
модели процессов, описанных в нотации BPMN, являются ИСПОЛНЯЕМЫМИ (т.е. реализуются в любой BPM-системе), а не только документируются.
специальные программные решения позволяют преобразовать диаграммы в исполняемые процессы, затем они могут быть запущенны и работать в реальном времени.
Слайд 70

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

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

Слайд 71

Слайд 72

Пример

Пример

Слайд 73

CASE - ТЕХНОЛОГИИ Расшифровка аббревиатуры CASE: Computer Aided Software Engineering. Можно

CASE - ТЕХНОЛОГИИ

Расшифровка аббревиатуры CASE: Computer Aided Software Engineering.
Можно перевести на

русский примерно как «разработка программного обеспечения с помощью компьютера».
Слайд 74

Применение CASE-средств оправдано при разработке сложного ПО, когда в одной и

Применение CASE-средств оправдано при разработке сложного ПО, когда в одной и

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

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

Современные крупные проекты ИС характеризуются, как правило, следующими особенностями:

сложность описания,

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

анализ и формулировку требований, проектирование прикладного ПО и баз данных, генерацию

анализ и формулировку требований,
проектирование прикладного ПО и баз данных,
генерацию

кода,
тестирование,
документирование,
обеспечение качества,
конфигурационное управление
управление проектом
CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.

Теперь под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая:

Слайд 77

Слайд 78

Инструменты ARIS BpWin Fox Manager Business Studio Бизнес Инжиниринг Групп. Программы

Инструменты

ARIS
BpWin
Fox Manager
Business Studio
Бизнес Инжиниринг Групп. Программы бизнес-моделирования: ОРГ-МАСТЕР®, ОРГ-МАСТЕР®Графикс
Microsoft Office Visio

2003
Слайд 79

Инструментальная система ARIS 101 модель для описания практически всех сторон деятельности

Инструментальная система ARIS

101 модель для описания практически всех сторон деятельности современного

предприятия
Более 250 объектов, описывающих различные аспекты предметных областей
Более 600 различных типов связей, позволяющих описать разнообразные отношения между объектами
Встроенные механизмы для управления, проверки, анализа, экспорта/импорта, архивирования моделей

Разработчик ARIS – компания IDS Scheer AG, г. Саарбрюкен, Германия

Слайд 80

Уровни описания ARIS Схема создания и использования моделей объекта, отражающая уровни

Уровни описания ARIS

Схема создания и использования моделей объекта, отражающая уровни детализации,

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

Альтернатива – выдергивание отдельных процессов из клубка «спагетти диаграмм»!

Слайд 81

Диаграмма взаимодействия в бизнес-процессе «обработка заказа»

Диаграмма взаимодействия в бизнес-процессе «обработка заказа»

Слайд 82

Примеры использования ARIS Фирма Мерседес-Бенц применяет ARIS с 1995 года для

Примеры использования ARIS

Фирма Мерседес-Бенц применяет ARIS с 1995 года для анализа

и совершенствования деятельности в области производства легковых автомобилей. Поводом для её приобретения послужила возраствющая конкуренция на рынке легковых автомобилей и острая необходимость в повышении конкурентоспособности предприятия.
Автомобилестроительная компания Фольксваген успешно использовала систему ARIS для реализации эффективной программы лизинга в двух дочерних подразделениях Фольксваген Лизинг и Фольксваген Банк. Весь процесс разработки данной программы был полностью осуществлен в системе ARIS и продолжался почти 5 месяцев при участии от 6 до 20 специалистов на разных этапах составления проекта.
Окончательным этапом разработки стали расчет экономических показателей реализации проекта и обучение будущих участников данной программы, что также было организовано с применением инструментария ARIS.
Слайд 83

История использования процессной платформы ARIS для совершенствования бизнеса и повышения его

История использования процессной платформы ARIS для совершенствования бизнеса и повышения его

эффективности в РФ насчитывает уже 25 лет. За эти годы процессные методы управления с помощью инструментов ARIS внедрили у себя:

«Роснефть»,
Международный московский банк,
«ВымпелКом»,
«ДаймлерКрайслер Автомобили Рус»,
ЛУКОЙЛ,
AVON Россия,
Siemens Россия
«Норильский никель»