MA Enterprise Analytic layering v1

АНАЛИТИЧЕСКОЕ РАССЛОЕНИЕ ПРЕДПРИЯТИЯ

MARCUS AURELIUS LTD

Г. МОСКВА2016 ГОД, ИЮНЬ

Ватикан. Королевская лестница.

Лоренцо Бернини

СОДЕРЖАНИЕ

MARCUS AURELIUS LTD.

1. ОСНОВЫ РАССЛОЕНИЯ

2. ПРИМЕРЫ ДИАГРАММ

3. ВОЗМОЖНОСТИ QPR

РАЗДЕЛ 1. ОСНОВЫ РАССЛОЕНИЯ БИЗНЕС-СИСТЕМ

MARCUS AURELIUS LTD

ПРЕДПОСЫЛКИ

Анализ деятельности предприятия, поиск причин его не эффективной работы или поиск новых

драйверов роста заставляет рассматривать предприятие с различных точек зрения:

Предприятие, как процесс или совокупность процессов

Предприятие, как система

Предприятие, как совокупность индивидов

Предприятие, как иерархия структур и функций

Предприятие, как совокупность информации и данных

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

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

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

ограничений

Предприятие, как часть более широкого социального или культурного контекста

Ни одна точка зрения не даёт универсального представления о предприятии и только совокупность

представлений даёт полную картину, хотя, зачастую, субъективную ввиду ограниченных познавательных

способностей аналитика или ошибочной интерпретации в коллективе моделей и модельных элементов

MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор

СТРУКТУРА И СИНТАКСИС АНАЛИТИЧЕСКОГО МЫШЛЕНИЯ

Для всестороннего или наоборот сфокусированного описания предприятия требуется: A. язык моделирования: набор понятий и четкое определение этих понятий/стереотипов, B. умение выделять/находить понятия (структурные элементы, стереотипы) в

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

точно прояснять те или иные аспекты бизнеса.

ARCHIMATE – удобный выразительный язык, который : А) разработан сообществом известных передовых компаний и отдельными профессионалами

Б) имеет широкий спектр применения, снабжен примерами и методичками

В) хорошо структурирован, обладает встроенными правилами комбинирования элементов

Г) позволяет расширение, уточнение, конструирование

Д) увязан с такими известными и распространенными нотациями, как BPMN и UML

E) Заранее проработаны различные диаграммы под различные точки зрения

История ArchiMate – более 10 лет разработки


ARCHIMATE 3.0

ArchiMate® 3.0 - это нотация (и методика) моделирования, разработанные консорциумом The Open Group в качестве языка архитектурного моделирования.

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

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

В основе синтаксиса и семантики нотации лежит методология TOGAF®

ARCHIMATE – ЭТО ЯЗЫК, НА КОТОРОМ РЕШАЮТСЯ ЗАДАЧИ МАСШТАБА ПРЕДПРИЯТИЯ


ТИПЫ МОДЕЛЬНЫХ ЭЛЕМЕНТОВ В ARCHIMATE

Нотация содержит более 40 модельных элементов. Удобно разделить их для понимания на 7 типов.

Бизнес-деятельность

Программы и обработка данных

Инфраструктура (оборудование и связь)

Целеполагание

Активные элементы (люди, системы …)

Пассивные (продукты, информация)

Поведенческие (процессы, функции)


ТИПЫ И ПРИМЕРЫ ЭЛЕМЕНТОВ

Пассивные элементы Поведенческие Активные элементы


ПРИМЕРЫ ЭЛЕМЕНТОВ И СВЯЗЕЙ МЕЖДУ НИМИ

системы

Мотивы

Цели

ДрайверыДрайверыДрайверыМотивыМотивы

Цели Цели Цели

проекты проекты программы программы функции функции

процессы процессы подразделения подразделенияinfo info info

системы системыданные данные данныеданные

УзлыЦОДыСУБД ШИНЫ Каналы

Ф Ф Ф Ф Ф Ф Ф Ф Ф

Application Component – автоматизированная

информационная системы.

Функция системы – элемент поведения системы,

отражающий определенный паттерн обработки данных

или контроля за ходом бизнес-процесса.

Интерфейс системы – «механизм» предоставления

определенного поведения (функции) системы наружу.

Application Interaction – взаимодействие систем,

выраженное передачей данных между системами

или вызовом из одной системы функции в другой

системе.

Процесс’ный элемент – действие, являющееся частью

взаимоувязанной цепочки действий.

Функция подразделения – предписанный

подразделению вид деятельности.

Node – центры обработки данных.

Data Object – минимальная информационная единица.

Location – место установки или использования

системы.

ПРИМЕРЫ ОТДЕЛЬНЫХ МОДЕЛЬНЫХ ЭЛЕМЕНТОВ

СТАНДАРТНЫЕ ЭЛЕМЕНТЫ

Actor – активный действующий элемент -

сотрудник или подразделение.

Role – роль, в которой выступает активный

действующий элемент.

Значение – значимость информационного

элемента для той или иной роли.

Цель – будущее состояние или результат, к

которому стремится система или активный

элемент.

Stakeholder – лицо, заинтересованное в

результатах деятельности.

Эти и более 20 других элементов тщательно описаны в стандарте с примерами применения.

Каталог системApplication Component –

автоматизированная информационная

системы.

Функция системы

– элемент поведения системы.

Интерфейс системы – «механизм»

предоставления определенного поведения

(функции) системы наружу.

Процесс’ный элемент – действие,

являющееся частью взаимоувязанной

цепочки действий.

КАЖДЫЙ ЭЛЕМЕНТ ОБРАЗУЕТ/ПОРОЖДАЕТ ОДИН АНАЛИТИЧЕСКИЙ СЛОЙ

Каждый элемент (стереотип) лежит в основе соответствующего каталога элементов.

Каждый каталог элементов – это аналитический слой.

Каталог элементов образует аналитический слой или определенную точку зрения на предприятие.

Каталог функций

Каталог процессов

Каталог интерфейсов

СВЯЗИ МЕЖДУ СЛОЯМИ – ЭТО КОМПОЗИТНЫЙ ВЗГЛЯД НА СИСТЕМУ

Между любыми слоями/каталогами строятся связи,

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

Каждая модель имеет графическое представление в виде наглядных диаграмм

Каталог систем



Каталог интерфейсов

Каталог ролей

Каталог целей

Каталог информации/данных

Каталог стейкхолдеровМодель

интеграций

Мод

ель

отв

етст

вен

но

сти

Каталог систем



Каталог ролей

Каталог целей

Каталог данных

Каталог стейкхолдеров

МЕТОДОЛОГИЯ ПРОЕКТА

Выделяем/определяем ЦЕЛЬ, как элемент

Выделяем/определяем СИСТЕМУ, как элемент

Выделяем/определяем ПРОЦЕСС, как элемент

Выделяем/определяем ФУНКЦИЮ, как элемент

Выделяем/определяем РОЛЬ, как элемент

Выделяем/определяем СТЕЙКХОЛДЕРА, как элемент

Выделяем/определяем ДАННЫЕ, как элемент

СОЗДАЕМ СЛОЙ







Строим связи между слоями

Application Х

Application Function

Business Process

SubProcess SubProcess SubProcess



Business Process

Business Process

Application Х


Business Process




Business Process

Business Process

Создаем комплексные диаграммы

Композитные точки зрения

Расслоение предприятия – это выделение и раздробление определенного аспекта деятельности на составляющие элементы.

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

аналитический слой.

Каждый каталог – это база данных однородных элементов. Каждый элемент в каталоге атрибутирован.

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

На базе каталогов строятся различные диаграммы-представления или иерархические зависимости. Совокупность элементов,

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

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

сложности. Стандарт Archimate подсказывает, какие точки зрения наиболее востребованы.

ИТОГ


Таким образом мы получаем: Базу данных всех структурных, поведенческих, ролевых, мотивационных и инфраструктурных элементов предприятия

Возможность неограниченного переиспользования всех элементов с целью построения нужных представлений

(диаграмм, точек зрения) для любых заинтересованных лиц

Представление исходных данных в любой нотации, причем одни и те же данные могут быть представлены сразу в

нескольких нотациях одновременно

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

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

Повышение выразительности и полноты процессных диаграмм в 5-10 раз

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

АРХИТЕКТУРА (СМ ОТДЕЛЬНУЮ ПРЕЗЕНТАЦИЮ)

Архитектура - это набор ключевых компонент («строительных» блоков) сложной системы, а также

множество ключевых взаимосвязей между ними.

Так как мы рассматриваем архитектуру бизнес-систем (Enterprise Architecture), то компоненты будут

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


Архитектура всех предприятий – одинакова, как одинаково устроены все люди: скелет, кровеносная система,

пищеварительная система, тренированный мозг и мышцы и т.п. Чем детальнее исследование

предприятия/человека, тем больше схожести в деталях мы обнаруживаем. Тем не менее и люди и компании

весьма отличаются друг от друга по своей результативности и устойчивости. Задача архитектора – выявить эти

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

предложить варианты трансформации отдельных компонент или связей предприятия. Понимание сущности и

назначения архитектурных исследований заставляет нас разделить архитекторов на 2 класса:

Текущие задачи, которые берёт на себя методология:

помочь архитекторам-исследователям сделать свою работу и подготовить почву для принятия решений руководителями (консультантами).

спланировать и контролировать трансформационный переход от AsIs-архитектуры к ToBe-архитектуре.

информационные компоненты

технологические компоненты

процессные компоненты, финансовые

потоки

инфраструктурные компоненты

цели и целевые установки

драйверы бизнеса

стейкхолдеры, мотивы стейкхолдеров

продукты компании

и другие.

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

такого сложного, как предприятие.

- Архитекторы-трансформаторы (руководители): интуитивно или на основе опыта они выделяют ключевые компоненты/связи бизнеса и

предлагают методы их трансформации к нужному им целевому состоянию, то есть в сущности предлагают ToBe-модель ключевых компонент.

КАКОВА ЦЕННОСТЬ АРХИТЕКТУРНОГО МОДЕЛИРОВАНИЯ?


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

себя практика АРХИТЕКТУРНОГО МОДЕЛИРОВАНИЯ, в основе которой лежит принцип расслоения анализируемой сложной

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

между компонентами различных слоёв.

Все эти компоненты (организованные в виде слоёв) и ранее подвергались анализу дизайнерами изменений и практиками

моделирования: уже давно существует множество нотаций и методологий в моделировании данных, целей, процессов, систем,

инфраструктур и т.п. Тогда в чем же новизна архитектурных методов? Новизна заключается в возможности строить более сложные

модели из нескольких слоёв одновременно, анализировать связи, поддерживать неограниченное количество связей, как между

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

не одной, а несколькими видами связей в зависимости от той роли или контекста, в котором их видит аналитик.

Нынешние экономические реалии всё чаще требуют трансформации предприятий, то есть изменений сразу в нескольких слоях, что

заставляет проводить когерентные (согласованные) проекты/изменения одновременно в целях, продуктах, процессах, системах,

инфраструктуре и т.п. Именно это и стало причиной появления и развития новых методических инструментов, позволяющих

координировать столь сложные трансформации. Примечание: построение новых сложных систем/комплексов/отраслей или

долгосрочное отраслевое планирование имеет в своей основе именно трансформационную природу, так как приводит к

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

Могут ли нынешние руководители всегда быть лидерами изменений? – не всегда это просто, так как изменения затрагивают многие

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

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

конструкцию, способную противостоять новым вызовам рынка и времени.

РАЗДЕЛ 2. ПРИМЕРЫ ДИАГРАММ

MARCUS AURELIUS LTD

Каждая диаграмма содержит элементы одного или более слоев, что соответствует типу

диаграммы или стоящей за этим типом точке зрения.

VIEWPOINTS – ТОЧКИ ЗРЕНИЯ

МЫ ГОТОВЫ СМОДЕЛИРОВАТЬ ЛЮБУЮ ТОЧКУ ЗРЕНИЯ!

До

мен

1Д

ом

ен 2

ПРИМЕР СЛОЯ ИНФОРМАЦИОННЫХ СИСТЕМ

ПРИМЕНЯЕТСЯ В ЦЕЛЯХ ИНВЕНТАРИЗАЦИИ СИСТЕМ ПРЕДПРИЯТИЯ

Автоматизированная система

расчетов

Личный кабинет

пользователя

Финансовая система

Логистическая система

Система контроля датчиков

Система приема

платежей

HR

Система сопряжения с

оборудованием

Система учета инцидентов

Система расчета

мощности

Система мониторинга

сети

Система CRM Система поддержки

оператора ЦОО

Учет основных средств

Учет производственных мощностей

Единая база знаний

Маркетинговый портал

Система автоматизации

проектирования

Регион 2Регион 1

Домен 2

Домен 1

СИСТЕМНЫЙ ЛАНДШАФТ: РЕГИОНАЛЬНАЯ ДИВЕРСИФИКАЦИЯ

С ПОМОЩЬЮ РЕГИОНАЛЬНЫХ СИСТЕМНЫХ КАРТ МЫ ПОКАЗЫВАЕМ РАЗЛИЧИЯ СИСТЕМНОГО ЛАНДШАФТА В

РАЗЛИЧНЫХ ФУНКЦИОНАЛЬНЫХ ДОМЕНАХ МЕЖДУ РАЗЛИЧНЫМИ РЕГИОНАМИ ИЛИ ОТДЕЛЕНИЯМИ КОМПАНИИ.


расчетов






платежей



Система расчета мощности

Система CRM





(вендор X)




расчетов






платежей



Система расчета мощности

ГИС

Система CRM





(вендор Y)



Система мониторинга

сети


ПРИМЕР СЛОЯ ДАННЫХ

СЛОЙ ДАННЫХ (ЛОГИЧЕСКАЯ МОДЕЛЬ ИЛИ МОДЕЛЬ ВЗАИМОСВЯЗИ ОСНОВНЫХ БИЗНЕС-СУЩНОСТЕЙ)

СОЗДАЁТСЯ ПО КАЖДОЙ (!) СИСТЕМЕ.

ПРИМЕР ДИАГРАММЫ СЛОЯ ФУНКЦИЙ

Application Y

(информационная система)











Application Х

(информационная система)







ПО КАЖДОЙ (!) СИСТЕМЕ СОЗДАЁТСЯ ЕЁ ФУНКЦИОНАЛЬНАЯ МОДЕЛЬ

НА 2-3-4 УРОВНЯХ МОДЕЛИРОВАНИЯ В ЗАВИСИМОСТИ ОТ

ПРЕДСТОЯЩИХ ЗАДАЧ ПО ФУНКЦИОНАЛЬНОМУ СРАВНЕНИЮ СИСТЕМ

ИЛИ РАЗВИТИЮ/ТРАНСФОРМАЦИИ СИСТЕМНОГО ЛАНДШАФТА

Сравнение функций,

поиск дублирования функционала

ПОСТРОЕНИЕ СВЯЗЕЙ МЕЖДУ СЛОЯМИ

СВЯЗИ ВНУТРИ СЛОЯ ПРИЛОЖЕНИЙ: СИСТЕМЫ И ПОТОКИ ДАННЫХ

СВЯЗИ МЕЖДУ СЛОЯМИ ПРИЛОЖЕНИЙ И БИЗНЕС-ПРОЦЕССОВ

ИНТЕГРАЦИИ СИСТЕМЫ

ДЛЯ КАЖДОЙ СИСТЕМЫ МЫ ПОКАЗЫВАЕМ,

КАКОЕ ОКРУЖЕНИЕ ЕЙ ТРЕБУЕТСЯ ДЛЯ

ИСПОЛНЕНИЯ ЕЕ ФУНКЦИЙ.


Application Х

Application Component












Application Interface









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

Но это не требуется отображать на нашей диаграмме

ФУНКЦИИ СИСТЕМЫ

СИСТЕМА, ЕЕ МОДУЛИ, А ТАКЖЕ ИХ ФУНКЦИИ 1-ГО, 2-ГО И 3-ГО ПОРЯДКА.

ВЗАИМОСВЯЗЬ ГРУППЫ СИСТЕМ В КОНТЕКСТЕ ОДНОГО ПРОЦЕССА

ДАННЫЕ ДИАГРАММЫ ИЛЛЮСТРИРУЮТ, КАКИЕ БИЗНЕС-ПРОЦЕССЫ ЗАВИСЯТ ОТ СИСТЕМЫ ИЛИ В КАКИХ БИЗНЕС-

ПРОЦЕССАХ И КАКИМИ СВОИМИ ФУНКЦИЯМИ СИСТЕМА УЧАСТВУЕТ.


Application Х


Business Process




Business Process

Business Process

Application Х


Business Process




Business Process

Business Process

ЗАВИСИМОСТЬ ПРОЦЕССА ОТ СИСТЕМ




Business Process Х






НА КАКИЕ СИСТЕМЫ ОПИРАЕТСЯ БИЗНЕС-ПРОЦЕСС? ОТ КАКИХ СИСТЕМ ОН ЗАВИСИТ?

НЕ ПРОСТО ЭЛЕМЕНТЫ – БАЗА ДАННЫХ ЭЛЕМЕНТОВ!


КАЖДЫЙ ЭЛЕМЕНТ В КАТАЛОГЕ АТРИБУТИРУЕТСЯ ДЛЯ ПОЛНОЦЕННОГО ОПИСАНИЯ ЭЛЕМЕНТА.

В ИТОГЕ КАТАЛОГ ЭЛЕМЕНТОВ – ЭТО В СУЩНОСТИ ИНВЕНТАРНАЯ БАЗА ЭТИХ ЭЛЕМЕНТОВ.

ПОЭТОМУ МОЖНО ГОВОРИТЬ О ПОЛНОЦЕННОЙ:

ИНВЕНТАРИЗАЦИИ ЦЕЛЕЙ ПРЕДПРИЯТИЯ

ИНВЕНТАРИЗАЦИИ ПРОЦЕССОВ ПРЕДПРИЯТИЯ

ИНВЕНТАРИЗАЦИИ СИСТЕМ ПРЕДПРИЯТИЯ

ИНВЕНТАРИЗАЦИИ ДАННЫХ ПРЕДПРИЯТИЯ

ИНВЕНТАРИЗАЦИИ ФУНКЦИЙ ПРЕДПРИЯТИЯ

ИНВЕНТАРИЗАЦИИ ЦЕНТРОВ ОБРАБОТКИ ДАННЫХ ПРЕДПРИЯТИЯ

ИНВЕНТАРИЗАЦИИ КАНАЛОВ ПРЕДПРИЯТИЯ

ИНВЕНТАРИЗАЦИИ ПРОДУКТОВ ПРЕДПРИЯТИЯ

ИНВЕНТАРИЗАЦИИ ДРАЙВЕРОВ ПРЕДПРИЯТИЯ

ИНВЕНТАРИЗАЦИИ ТРЕБОВАНИЙ ПРЕДПРИЯТИЯ

ПРИМЕРЫ АТРИБУТОВ ФОРМУЛЯРА ИНФОРМАЦИОННОЙ СИСТЕМЫ


Название поля

1 ID системы

2 Полное наименование системы

3 Краткое имя для схем

4 Краткое описание системы

5 Место текущей физической установки ИС

6 Уровень унификации решения

7 Количество установок

8 Аналитик

9 Класс ИС

10 Целевая архитектура (признак)

11 Ответственный департамент в УК

12 Локальный разработчик ИС

13 Вендор ИС

14 Интегратор ИС

Название поля

15 Язык разработки ИС или СУБД

16 Оценка имеющейся документации

17 Штат специалистов по ИС

18 Статус реализации ИС:• промышленная экслплуатация• архивная система• система на стадии внедрения• выведена из эксплуатации

19 Куда выгружается отчетность?

20 Ответственное лицо по ИС• ФИО• Телефон/Email• Подразделение ответственного лица

21 Контактное лицо по ИС• ФИО• Телефон/Email

22 Заказчик ИС• ФИО• Телефон/Email• Подразделение ответственного лица

ФОРМУЛЯР ИНФОПОТОКА (ПРИМЕР): ОПИСАНИЕ ИНТЕГРАЦИОННОГО ВЗАИМОДЕЙСТВИЯ ДВУХ СИСТЕМ


Название поля Тип поля

1 Номер инфопотока Текст

2 Краткое наименование инфопотока Текст

3 Полное наименование инфопотока Текст

4 Описание инфопотока или комментарии по реализации Текст

5 Активный? (используется или нет) Boolean

6 Статус описания (в работе; описание завершено; заблокировано от изменений) Список выбора

7 Ответственный аналитик Список выбора

8 Вызывающая система Ссылка

9 Вызываемая система Ссылка

10 Состав передаваемых данных или название запрошенной функции Текст

11 Релевантные информационные объекты Ссылка

12 Наименование API и метода, предоставляемого вызываемой системой Текст

13 Метод интеграции Список выбора

14 Протокол интеграции Список выбора

КАРТОЧКА ИНФОПОТОКА (ПРОДОЛЖЕНИЕ)



14 Инициирующее событие в системе №1 Текст

15 Функция системы №1 (вызывающей системы), в контексте которой происходит вызов системы 2

Ссылка

16 Функция системы №2 (вызываемая система), в контексте которой происходит «прием» инфопотока или собственно вызываемая функция

Текст

17 Интегратор Текст

18 Контакты интегратора Текст

19 ИТ-специалист, ответственный за интеграцию Текст

20 Документация, описывающая интеграцию Текст

КАРТОЧКА ФУНКЦИИ. ПРИМЕР



1 Полное наименование функции Текст

2 Краткое наименование функции Текст

3 Описание функции или комментарии по функции Текст

4 Активна? (используется или нет) Boolean

5 Статус описания:- в работе- описание завершено- заблокировано от изменений

Список выбора

6 Ответственный аналитик Список

7 Связь с модулем системы Ссылка

8 Связь(и) с дочерними функциями Ссылка

РАЗДЕЛ 3. ВОЗМОЖНОСТИ ИНСТРУМЕНТА

Возможности программного инструмента Enterprise Architect финской компании QPR

Software PLC. Отличительной особенностью продукта является интуитивная простота

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

неограниченная свобода в использовании на схемах любых элементов, не предусмотренных

нотацией моделирования. Это делает схемы на столько выразительными, на сколько вы

умеете управлять визуальным восприятием сложных картинок высокой степени детализации.

Все элементы диаграмм образую базу данных элементов. Каждый элемент обладает

собственных набором атрибутов.

MARCUS AURELIUS LTD

ИНСТРУМЕНТАЛЬНАЯ СРЕДА МОДЕЛИРОВАНИЯ


ENTERPRISE ARCHITECT. QPR SOFTWARE PLC

ВОЗМОЖНОСТИ ENTERPRISE ARCHITECT

Поддержка стандарта Archimate 2.0 +

Поддержка стандарта BPMN и UML

Возможность разработки любой (!) нотации

Возможность доработки встроенных нотаций

Конструирование любой метамодели

Управляемые панели инструментов

Возможность устанавливать связи между моделями

Связывание объектов атрибутивно или графически

Коллективная работа на общем сервере

Локальная работа на ноутбуке с копией сервера в

режиме редактирования и без связи с сервером

Vbasic-образный язык разработки скриптов для

автоматизации рутинный операций

Поддержка TOGAF


ПРИМЕР ФОРМУЛЯРА ИНФОРМАЦИОННОЙ СИСТЕМЫ В QPR


Общее описание системы

Общее описание системы

Связи системыВхождения системы в

различные диаграммы

Атрибуты системы: СУБД, Вендор, Статус

и т.п.

ТАБЛИЧНЫЕ ПРЕДСТАВЛЕНИЯ СЛОЕВ НА ПРИМЕРЕ СИСТЕМ, ФУНКЦИЙ И ИНФОПОТОКОВ


ИНФОПОТОКИ

ФУНКЦИИ СИСТЕМЫ

СВЯЗИ МОЖНО УСТАНАВЛИВАТЬ КАК ГРАФИЧЕСКИ, ТАК И ТАБЛИЧНО

QPR ENTERPRISE ARCHITECT

QPR Enterprise Architect - среда коллективной работы с моделями:

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

Содержит все справочники, нужные для стандартизации ввода данных

Содержит все представления (отчеты)

Содержит различные подложки для отображения данных

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

систем, функций, интеграций, ролей, процессов, целей и т.д.

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

между формулярами объектов и схемами

Предоставляет единый механизм поиска артефактов моделирования: как на схемам, так

и в каталогах


Enterprise Architect – единая интегрированная среда, в которой интегрированы: системы, функции,

интерфейсы, инфопотоки, процессы, цели, задачи и т.п. зафиксированные в виде артефактов системы и

иллюстрированные интерактивными диаграммами.


КОНТАКТЫ ДЛЯ СВЯЗИ

Рудь Виктор Директор по консалтингу

ООО «МАРК АВРЕЛИЙ»

http://www.consulo.ru

E-mail: v.rud @consulo.ru

Телефон: +7 (495) 922-12-40

Не отказывайся от помощи, особенно когда это связано с исполнением долга.

Многое из того, что не удаётся сделать в одиночку, может быть легко достигнуто, если действовать сообща…

Марк Аврелий


http://www.consulo.ru/

WWW.MARCUS-AURELIUS.RU

Рудь Виктор Геннадиевич

Директор по консалтингу

ООО «МАРК АВРЕЛИЙ»

e-mail: v.rud @consulo.ru

Телефон: +7 (495) 922-12-40

Marcus Aurelius ltd.

Управление архитектурой систем и предприятия

Концептуальное проектирование

Реинжиниринг процессов

Дизайн информационных систем

Бизнес-анализ

Дизайн и поддержание автоматизированных

каталогов услуг

Проведение тендеров на выбор программного

обеспечения

Обучение по архитектурным методологиям

Управление требованиями

Разработка Требований, Тех.Заданий,

Архитектурных решений и концепций

Организационный дизайн

Процессное управление

Проработка KPI процессов и подразделений

Управление проектом

Планирование проекта и ресурсов

Создание и контроль процессной архитектуры

Создание и контроль функциональной архитектуры

Создание и контроль информационной архитектуры

Разработка учебных материалов

Обучение ключевых пользователей

Нормирование численности подразделений и

оптимизация орг.штатной структуры

Реинжиниринг процессов

Подготовка процессов и функций к передаче в

аутсорсинг

Виды услуг компании: Виды помощи в больших проектах:

ЭКСПЕРТИЗА И УСЛУГИ КОМПАНИИ «МАРК АВРЕЛИЙ»


КЛИЕНТЫ КОМПАНИИ «МАРК АВРЕЛИЙ»


СЕВЕРНЫЕ

ПРИИСКИ

ПРИЛОЖЕНИЕ №1.

НЕСКОЛЬКО ПОЛЕЗНЫХ СЛАЙДОВ ДЛЯ БОЛЕЕ ГЛУБОКОГО ПОНИМАНИЯ ТЕМЫ

МНОГОУРОВНЕВЫЙ СТРУКТУРНЫЙ ПОРЯДОК В ЭЛЕМЕНТАХ И СВЯЗЯХ МЕЖДУ НИМИ

Motivation & Delivery domain:

Структурирует цели, мотивы и факторы влияния

Расширение: проекты, программы, плато-gap

Business domain :

Структура процессов, функций, подразделений.

Структурирует бизнес-объекты

Структура создаваемого продукта

Application domain : обработка данных

Структурирует данные

Структурирует поведение систем

Структура интеграций

Infrastructure domain :

Структурирует сети.

Структурирует центры и узлы обработки

Структурирует системное программное

обеспечение

Цели-задачи-мотивы-проекты

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

Бизнес-функции

Бизнес-объекты

Архитектура систем и данных

Инфраструктура

→ → →

В каждом домене может быть выделено до 15 аналитических слоёв (срезов)

ЧЕМ ПРИХОДИТСЯ УПРАВЛЯТЬ?


ДВЕ ГЛАВНЫХ ЧЕРТЫ СОВРЕМЕННОГО УПРАВЛЕНИЯ:

Нахождение релевантной информации в безумном потоке данных.

Выделение базовых элементов и их взаимосвязей.

Если раньше приходилось управлять непосредственно людьми, то

сейчас управление свелось к умению понимать и интерпретировать

многочисленную информацию, поступающую регулярно и

спорадически из различных источников. Ключевым фактором

успеха управления становится способность реагировать на

информационный поток, продолжая видеть в нем отдельные

объекты управления, субъектов управления, возможности и риски,

многочисленные роли и взаимосвязи между ними.

ЭЛЕМЕНТЫ УПРАВЛЕНИЯ СТАЛИ АТОМАРНЫМИ, ПРЕДСКАЗУЕМЫМИ, ГИБКИМИ:

ТИПЫ СВЯЗЕЙ МЕЖДУ ЭЛЕМЕНТАМИ УПРАВЛЕНИЯ И ИХ КОЛИЧЕСТВО

ВОЗРОСЛИ МНОГОКРАТНО !!!

СВЯЗИ, КАК ОБЪЕКТ СТАНДАРТИЗАЦИИ И МОДЕЛИРОВАНИЯ

ВИДЫ СВЯЗЕЙ МЕЖДУ ОБЪЕКТАМИ

PassiveStructureElement

Service

BehaviorElement

Interface

ActiveStructureElement

accesses

accessed by

accesses

accessed by

used by

uses

realized by

realizes

assigned from assigned to

assigned from

assigned to

used by

uses

composes

composed of

used by

uses

triggered by / flow from triggers / flow to

МОДЕЛИРОВАНИЕ СВЯЗЕЙ И ОТНОШЕНИЙ ТАКЖЕ ВАЖНО, КАК И МОДЕЛИРОВАНИЕ САМОЙ СТРУКТУРЫ

АРХИТЕКТУРА: ПРИМЕР ВЗАИМОСВЯЗИ МЕЖДУ СЛОЯМИ МОДЕЛИ


Цели-задачи-мотивы-проекты

Бизнес-процессыБизнес-функцииБизнес-объекты

→ → →

Архитектура систем и данных

Stakeholder Driver

Goal

Constraint

Driver

Business Requiremen

t

System Requiremen

t

PrincipleConstraint

Business Service

Application Service

Value

Product

Work Package

БАЗОВЫЙ ПАТТЕРН

Meaning

Representation

Product

Contract

Business Object

Value

Data Object

Artifact

Business Service

Businessprocess /function /interaction

Event

Application Service

Infrastructure Service

System Software

Applicationfunction /interaction

Business Interface

Business Role



Infrastructure Interface

Node

Device

Business Collaboration

Business Actor

Application Collaboration

Communication Path

Network

BusinessApplication

ApplicationTechnology

РАЗБОР БАЗОВОГО ПАТТЕРНА, ПЕРЕХОД К СЕРВИСАМ

ФУНКЦИИ ПРИЛОЖЕНИЯ

ОБЕСПЕЧИВАЮЩЕЕ ПРИЛОЖЕНИЕ

СЕРВИС

ДОСТУПНОСТЬ СЕРВИСА для

ИСПОЛЬЗОВАНИЯ

СЕРВИС ИНКАПСУЛИРУЕТ ФУНКЦИИ (ПОВЕДЕНИЕ) И РЯД РАЗРОЗНЕННЫХ ИНТЕГРАЦИЙ

В ОДИН УНИФИЦИРОВАННЫЙ И ДОСТУПНЫЙ ДЛЯ ОБЩЕГО ИСПОЛЬЗОВАНИЯ КОМПОНЕНТ

С ОТКРЫТЫМ ИНТЕРФЕЙСОМ ДОСТУПА К НЕМУ

ДАННЫЕ ПРИЛОЖЕНИЯ

MA Enterprise Analytic layering v1

Documents

Transcript of MA Enterprise Analytic layering v1