Похожие презентации:
Архитектура предприятия-5
1. Архитектура предприятия. лекция 5
АРХИТЕКТУРА ПРЕДПРИЯТИЯ. ЛЕКЦИЯ 5ПРЕПОДАВАТЕЛЬ: САВЧЕНКО ТАТЬЯНА АНАТОЛЬЕВНА
2. Элементы Архитектуры предприятия. Бизнес-архитектура и архитектура информации
ЭЛЕМЕНТЫ АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ. БИЗНЕС-АРХИТЕКТУРАИ АРХИТЕКТУРА ИНФОРМАЦИИ
основные домены,
принципы,
модели и стандарты архитектуры,
модели описания архитектуры"
3. Домены (предметные области) архитектуры
ДОМЕНЫ (ПРЕДМЕТНЫЕ ОБЛАСТИ) АРХИТЕКТУРЫ* Бизнес-архитектура.
* Архитектура информации (данных).
• Описывает деятельность организации с точки зрения ее ключевых бизнес-процессов.
• Определяет, какие данные необходимы для поддержания бизнес-процессов (например, модель
данных), а также для обеспечения стабильности и возможности долговременного
использования этих данных в прикладных системах.
* Архитектура приложений.
• Определяет, какие приложения используются и должны использоваться для управления
данными и поддержки бизнес-функций (например, модели приложений).
* Технологическая архитектура
(инфраструктура).
• Определяет, какие обеспечивающие технологии (аппаратное и системное программное
обеспечение, сети и коммуникации) необходимы для создания среды работы приложений,
которые, в свою очередь, управляют данными и обеспечивают бизнес-функции
* Архитектура интеграции.
• Определяет инфраструктуру для интеграции различных приложений и данных.
* Архитектура общих сервисов.
• Примерами их являются такие сервисы, как электронная почта, каталоги, общие механизмы
безопасности (идентификации, аутентификации, авторизации). То есть, это достаточно большое
количество прикладных систем, которые носят "горизонтальный характер".
* Сетевая архитектура.
• Определяет описания, правила, стандарты, которые связаны с сетевыми и коммуникационными
технологиями, используемыми в организации.
* Архитектура безопасности
4. Области, входящие в понятие Архитектуры предприятия
ОБЛАСТИ, ВХОДЯЩИЕ В ПОНЯТИЕ АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ5. Модель, используемая для описания стратегии и архитектуры информационных технологий
МОДЕЛЬ, ИСПОЛЬЗУЕМАЯ ДЛЯ ОПИСАНИЯ СТРАТЕГИИ ИАРХИТЕКТУРЫ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ
Ключевыми
элементами,
с точки зрения
архитектуры,
являются:
- принципы,
- стандарты и
- модели
6. Элементы описания архитектуры ИТ
ЭЛЕМЕНТЫ ОПИСАНИЯ АРХИТЕКТУРЫ ИТ* Миссия и видение.
* Руководящие принципы. Утверждения, описывающие принципы и ключевые элементы философии
использования информационных технологий.
* Цели, задачи и стратегии.
* Архитектура информационных технологий.
* Политики (правила).
* ИТ-стандарты. Стандарты – это обязательные к использованию утверждения, касающиеся используемых
технологий, продуктов и/или услуг.
* Процедуры. Процедуры – это инструкции, описывающие, как выполняются политики и стандарты. Процедуры
устанавливают и описывают процессы, которые выполняются на регулярной основе.
* Руководства или рекомендации (guidelines).
7. Связь: Политики, стандарты и процедуры
СВЯЗЬ: ПОЛИТИКИ, СТАНДАРТЫ И ПРОЦЕДУРЫСтандарты всегда должны быть связаны с
некоторыми сформулированными
политиками, хотя сами политики могут и не
иметь определенных стандартов "под собой".
Точно так же процедуры всегда должны быть
связаны с определенными стандартами, хотя
сами стандарты могут существовать без
связанных с ними каких-либо процедур.
8. примеры общих принципов, связанных с архитектурой в целом
ПРИМЕРЫ ОБЩИХ ПРИНЦИПОВ, СВЯЗАННЫХ С АРХИТЕКТУРОЙ ВЦЕЛОМ
* Все подразделения (ведомства) должны использовать в своей работе архитектуру, разработанную для
организации (правительства) в целом.
* Функциональное руководство и руководство в области ИТ должно основываться на общем видении.
* Архитектура должна обеспечивать решение вопросов бесперебойного выполнения организациями своих
функций, безопасности и восстановления в случае катастрофических событий.
* Функциональные (бизнес-) требования должны формировать архитектуру.
* Архитектура должна обеспечивать совместимость и взаимодействие.
* Архитектура должна быть расширяемой, масштабируемой и адаптивной.
* Архитектура должна быть инструментом реализации изменений.
* Архитектура должна уменьшать сложность интеграции и способствовать улучшению качества бизнеспроцессов.
* Тенденции рынка должны учитываться при проектировании технологической архитектуры.
9. Примеры декларируемых принципов в области ИТ-инфраструктуры
ПРИМЕРЫ ДЕКЛАРИРУЕМЫХ ПРИНЦИПОВ В ОБЛАСТИ ИТИНФРАСТРУКТУРЫ* Инфраструктура должна быть основана на использовании технологий,
поддерживающих открытые стандарты.
* Инфраструктура (совместно с принципами управления данными и
разработки приложений) должна обеспечивать взаимодействие систем.
10. Примеры принципов в области управления данными
ПРИМЕРЫ ПРИНЦИПОВ В ОБЛАСТИ УПРАВЛЕНИЯ ДАННЫМИ* Бизнес-структуры (отделы, департаменты, ведомства), являющиеся владельцами данных, отвечают
за целостность и распространение данных.
* Данные уровня отдельных бизнес-структур (департамента, региона, города) должны быть явно
описаны и доступны всем остальным бизнес-структурам (департаментам, ведомствам).
* Ведомства собирают только самый необходимый минимум данных и стремятся уменьшить нагрузку
на тех, кто должен предоставлять данные.
* Данные вводятся в информационные системы один раз, и тут же выполняется проверка их
корректности.
* Информация является ценным ресурсом, который передан в управление менеджерам
(государственным служащим), и этим ресурсом необходимо соответствующим образом управлять.
11. Примеры принципов, связанных с прикладными системами
ПРИМЕРЫ ПРИНЦИПОВ, СВЯЗАННЫХ С ПРИКЛАДНЫМИСИСТЕМАМИ
* Прикладные системы разрабатываются на основе стандартной, единой методологии.
* Все структурные подразделения (ведомства) используют общие методы представления информации
пользователям в своих приложениях и координируют работы по созданию пользовательского интерфейса
межфункциональных (межведомственных) систем.
* Создание межфункциональных прикладных систем приветствуется.
* Руководство заранее планирует процесс замены устаревших прикладных систем.
12. Примеры принципов, связанных с управлением и контролем
ПРИМЕРЫ ПРИНЦИПОВ, СВЯЗАННЫХ С УПРАВЛЕНИЕМ ИКОНТРОЛЕМ
* Единая архитектура, соответствующие стандарты и руководства используются всеми структурными
подразделениями (ведомствами) в процессе принятия решений о своих информационных системах.
* Стандарты пересматриваются регулярно не реже одного раза в два года с участием представителей
структурных подразделений (ведомств).
* Руководство структурных подразделений (ведомств) стремится к кооперации и партнерству с
другими структурными подразделениями (ведомствами) в области информационных технологий.
* организация должна иметь интегрированный процесс управления архитектурой.
13. Классификация моделей
КЛАССИФИКАЦИЯ МОДЕЛЕЙПо
оформлению
Формальные
(использующие общепринятые правила, нотации и
средства)
Неформальные
По
содержанию
По
алгоритму
Количественные
позволяющие производить численные оценки и проверки
Качественные
предназначенные для понимания поведения и структуры
системы
Описательные
предназначенные только для восприятия человеком
Исполняемые
позволяющие исследовать их поведение и использовать
полученные результаты для выводов об исходной системе
14. Цели разработки архитектуры предприятия
ЦЕЛИ РАЗРАБОТКИ АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ1. Обеспечить понимание структур,
объектов и связей между ними в
неоднородном и обширном наборе
информационных систем предприятия;
моделирование с
целью
2. Предоставить сведения, необходимые
для обеспечения интеграции процессов,
систем и информации.
моделирование
обеспечить понимание
для интеграции
15. Разработка моделей для различных перспектив
РАЗРАБОТКА МОДЕЛЕЙ ДЛЯ РАЗЛИЧНЫХ ПЕРСПЕКТИВУровень абстракции
Необходимая информация
для описания моделей
данного уровня
Пример
Контекст архитектуры
Список Бизнес-сущностей
«Счет», «Клиент»…
Архитектура прикладных систем
Список основных бизнеспроцессов
«Продажа», «Производство …»
Технологическая архитектура
Информация о местах
расположения бизнеса
План размещения оборудования и
т.п.
Динамические модели
Статические модели
• описывают процессы информационного обмена,
пересылку сообщений между объектами
• рассматривают структуры и взаимосвязи между
объектами
16.
ПерспективыБизнес-архитектура
Архитектура
информации
Архитектура
приложений
Технологическая
архитектура
* Классы бизнес-процессов
(группа процессов, имеющих
много общих активностей)
* Список бизнес-процессов
* Список бизнес-сущностей –
объектов, важных для
бизнеса ("клиент", счет")
* Связи между сущностями
(бизнес-объектами)
* Список бизнеспроцессов
* Список мест расположения
бизнеса
* Сценарии использования (Use
case)
* Модели бизнес-процессов
* Семантические модели
* Модели связей
* Модели "сущность-связи"
* Разбиение
процессов на
сервисы
* Модели бизнес-логистики
* Операционные
(нефункциональные) требования
* Архитектура расположения
элементов центра обработки
данных
* Модели процессов (потоков
работ)
* Модели бизнес-событий
* Модель расположения
процессов
* Определения ролей
* Логические модели данных
* Схемы данных
* Спецификации документов
* Определения
сервисов
* Взаимосвязи
между сервисами
* Модели классов
* Логические типы серверов: БД,
почтовые, транзакционные, …
* Географическое распределение
серверов
* Хостируемое ПО
* Спецификации процессов
* Модели интеграции процессов
* Описание ручных процедур
* Стандарты качества
* Физические модели данных
* Схемы БД
* Код доступа к данным
* Справочники данных
* Код программ
* Описания
интерфейсов
* Расписания
процессов
* Физические серверы
* Топология фрагментов сети
* Мапирование продуктов на
сервисы и приложения
(уровни
абстракции)
Домены
Контекст
("планировщик")
Концептуальный уровень
("владелец"
предприятия)
Логический
("проектировщик")
Физический
("разработчик")
17. Динамическая концептуальная модель процесса закупки товара
ДИНАМИЧЕСКАЯ КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ ПРОЦЕССАЗАКУПКИ ТОВАРА
18. Статическая модель процесса закупки товара в магазине
СТАТИЧЕСКАЯ МОДЕЛЬ ПРОЦЕССА ЗАКУПКИ ТОВАРА В МАГАЗИНЕ19.
20. Составные части бизнес-архитектуры
СОСТАВНЫЕ ЧАСТИ БИЗНЕС-АРХИТЕКТУРЫСтруктуры
и процессы
Описание
функций
Миссия
Цели
организации
Критическ
Бизнесие факторы
стратегии
успеха
21. Контекст Бизнес-архитектуры
КОНТЕКСТ БИЗНЕС-АРХИТЕКТУРЫ22. построение высокоуровневых моделей бизнес-процессов предприятия
ПОСТРОЕНИЕ ВЫСОКОУРОВНЕВЫХ МОДЕЛЕЙ БИЗНЕСПРОЦЕССОВ ПРЕДПРИЯТИЯШаг 1.
Идентификация критически важных для
предприятия процессов (обычно не
более восьми).
ключевые процессы, которые максимально влияют на
способности организации реализовывать свою миссию,
достигать цели, выполнять основные функции.
Шаг 2.
Отследить связи между этими
процессами и бизнес-стратегиями,
движущими силами и критически
важными факторами успеха.
Построить модели высокого уровня для
ключевых бизнес-процессов (см.
следующий раздел).
Это можно сделать с помощью матрицы взаимных связей. Для
каждого элемента этой матрицы определяется качественная
оценка по принципу "важно" – "неважно" или по некоторой
условной шкале.
Шаг 3.
Шаг 4.
Шаг 5.
Это включает последовательность основных шагов
(желательно, не более восьми на процесс).
Для каждого шага процессов,
Это может быть функциональное подразделение внутри
идентифицированных на этапе 3,
организации, партнер, клиент, внешний регулирующий
определить ответственных за
орган.
выполнение шага.
Идентифицировать и документировать основные
категории информационных объектов (опять же
рекомендуется не более восьми).
23. Типы моделей
ТИПЫ МОДЕЛЕЙмодели процессов/потоков работ,
функциональные модели,
организационные модели,
модели данных/ресурсов,
временные модели типа диаграмм Ганта,
модели причинно-следственных связей
24. Инструменты Детализации бизнес-процессов
ИНСТРУМЕНТЫ ДЕТАЛИЗАЦИИ БИЗНЕС-ПРОЦЕССОВ* декомпозиция функций/процессов;
* анализ бизнес-событий;
* моделирование местоположений выполнения функций/процессов;
* модель интеграции функций/процессов.
25. Декомпозиция бизнес-процессов
ДЕКОМПОЗИЦИЯ БИЗНЕС-ПРОЦЕССОВЦели декомпозиции:
Задачи декомпозиции:
идентификация
* задать границы анализа рассмотрением наиболее
критически важных функций бизнеса;
подпроцессов, которые
составляют основу
выполнения бизнесфункций,
определение границ
основных
организационных единиц и
определение вклада
каждой функции в цепочку
создания добавочной
стоимости
* идентифицировать основные процессы, обеспечивающие
выполнение функций организации;
* идентифицировать межфункциональные процессы,
которые являются первоочередными кандидатами на
инновации, связанные с применением информационных
технологий;
* идентифицировать пересечения и излишние
функции/процессы.
26. Модель интеграции
МОДЕЛЬ ИНТЕГРАЦИИОсновная
область
анализа
* Обеспечить понимание ключевых внутренних и внешних точек интеграции
* Информационные потоки между участниками бизнес-событий
* Понимание основных интерфейсов прикладных систем
* Понимание требований к технологической архитектуре с точки зрения интеграции
Результаты
(артефакты)
анализа
* Потоки информации, которые требуются для реализации различных шаблонов бизнес-процессов
* Связи между функциями бизнеса
* Требования к архитектуре информации, приложениям и технологической архитектуре
* Возможности для организационных изменений
Основные
вопросы
* Какая информация является критической для новых шаблонов реализации бизнес-процессов?
* Какие потоки информации существуют между различными точками соединения моделей бизнессобытий?
* Каковы требования с точки зрения времени?
27. Методы анализа моделей
МЕТОДЫ АНАЛИЗА МОДЕЛЕЙАнализ цепочек создания
добавочной стоимости
Динамическое моделирование
• (А нужно ли вообще выполнять этот шаг?)
• (Как эта модель выполнения бизнес-функций будет себя вести при
различных значениях на входе и доступных ресурсах, и как со временем
будет меняться поведение процесса?)
Анализ пересечений и непокрытых
областей (Gap-overlap analysis)
• (Будет ли наша бизнес-архитектура иметь избыточные
элементы, и есть ли в ней "пробелы"?)
Соотнесение затрат с активностями
(Activity-based costing)
• (На каких процессах, каналах продаж и заказчиках мы реально
зарабатываем или теряем деньги?)
Обучение
• (Как эти бизнес-процессы соотносятся с другими?)
Общая стоимость владения
• (Сколько стоит этот процесс?)
Возврат инвестиций (ROI)
• (Будет ли достигнут возврат инвестиций в данный бизнеспроцесс и когда?)
28. Показатели эффективности бизнеса и процессов
ПОКАЗАТЕЛИ ЭФФЕКТИВНОСТИ БИЗНЕСА И ПРОЦЕССОВМетрики уровня
процессов
Метрики оценки прямых
результатов
Метрики оценки
конечных результатов
• оценивают
эффективность самого
процесса:
• время цикла
выполнения
операций,
• стоимость на
транзакцию или
единицу выхода
процесса.
• оценивают
возможности
процессов производить
на выходе продукт или
услугу в соответствии
со спецификациями:
• процент ошибок
• количество
обслуженных заявок в
единицу времени.
• оценивают процесс с
точки зрения
конечного потребителя
(клиента) и выполнения
функций организации:
• уровень
удовлетворенности
клиента
• эффективность
продукта.