Всё для Учёбы — студенческий файлообменник
1 монета
ppt

Студенческий документ № 050928 из МЭСИ

Архитектурный подход к управлению бизнесом

Калянов Георгий Николаевич

профессор, доктор технических наук

Kalyanov@mail.ru

http://www.kalyanov.by.ru

Лекция №2

Понятие архитектуры современного предприятия

Архитектура предприятия

• Под архитектурой предприятия (ЕА - Enterprise Architecture) понимается всестороннее и исчерпывающее описание (модель) всех его ключевых элементов и межэлементных отношений

• Согласно ISO 15704 ("Industrial Automation Systems - Requirements for Enterprise-Reference Architectures and Methodologies. 1999") архитектура предприятия должна включать роль людей, описание процессов (функции и поведение), и представление всех вспомогательных технологий на протяжении всего жизненного цикла предприятия.

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

• "обращен к социально-экономическим компьютезированным системам любого размера и сложности"

• "включает взгляд на предприятие и его системы как на целое, в котором все компоненты гармонично соответствуют друг другу, обеспечивает комплексный и целостный взгляд на потребности субъектов и планы их удовлетворения, на существующие системы, действующие ограничения и перспективные возможности применения ИТ"

Зиндер Е.З.

Архитектура предприятия

Архитектура (в соответствии с документом "Federal Enterprise Architecture Framework. Dev. by: The Chief Information Officers Council (USA)") является стратегической информационной основой, определяющей:

• структуру бизнеса;

• информацию, необходимую для ведения бизнеса;

• технологии, применяемые для поддержания бизнес-операций;

• процессы преобразования, развития и перехода, необходимые для реализации новых технологий в ответ на изменение/появление новых бизнес-потребностей.

Архитектурные слои

• Бизнес-архитектура

• Системная архитектура

* архитектура приложений

* архитектура данных

* техническая архитектура (сетевая архитектура, архитектура платформ)

Архитектурные слои

Архитектура приложений

• собственно прикладные системы, поддерживающие исполнение бизнес-процессов;

• интерфейсы взаимодействия прикладных систем между собой и с внешними системами и источниками или потребителями данных;

• средства и методы разработки и сопровождения приложений.

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

• базы данных и хранилища данных;

• системы управления базами данных или хранилищами данных;

• правила и средства санкционирования доступа к данным.

Сетевая архитектура

• локальные и территориальные вычислительные сети;

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

• аварийные планы по обеспечению бесперебойной работы сетей в условиях чрезвычайных обстоятельств.

Архитектура платформ

• аппаратные средства вычислительной техники - серверы, рабочие станции, накопители и другое компьютерное оборудование;

• операционные и управляющие системы, утилиты и офисные программные системы;

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

Цикл выстраивания архитектуры

Цели применения подхода

• повышение интегрированности предприятия (обеспечение решения ряда интеграционных задач - интеграции рынков, интеграции проектантов, разработчиков и производителей, интеграции поставщиков и производителей, интеграции аппаратного и программного обеспечения от разных вендоров и т.п.)

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

Задачи моделирования архитектуры

• определение бизнес-целей и требований

• моделирование бизнеса с позиции менеджера

• моделирование бизнес-процессов

• моделирование бизнес-функций

• моделирование оргструктуры, включая логические схемы принятия решений

• моделирование ресурсов

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

Этапы моделирования архитектуры

Этапы моделирования архитектуры

Классификация существующих сред

• универсальные интегрирующие среды (например, Zachman Framework, GERAM)

• языки моделирования предприятий (например, IDEF, ARIS, BPML)

• программные среды моделирования (например, ARIS 6 Collaborative Suite, Popkin System Architect, METIS)

• мета-модели и языки мета-моделирования (например, UML Profile for Business Process Definition, UEML)

Лидеры по объему продаж

Недостатки существующих сред

• фрагментарность

• отсутствие унификации

Фрагментарность

• поддерживают лишь отдельные компоненты среды моделирования

• поддерживают лишь отдельные фазы и этапы процесса моделирования

• не являются универсальными в части применимости к предприятиям любого вида

• поддерживают лишь отдельные виды моделирования

Унификация - цель проекта UEML

• общий, визуальный, базированный на шаблонах язык для коммерческих инструментальных средств моделирования предприятий

• стандартизованные, независимые от инструментов механизмы передачи знаний (моделей) между проектами

• репозиторий моделей предприятий

Данные о проекте

Проект UEML (Unified Enterprise Modeling Language)

• Рабочая группа - компании - производители EML (Enterprise Modeling Language)

• Дата начала проекта - 01.03.2002

• Объявленная продолжительность -15 месяцев (т.е. до 01.06.2003)

• Сайт проекта - www.ueml.org

Основные направления работ

• разработка и исследование методологического и методического обеспечения создания ЕА (методологии, базирующиеся на схеме Захмана, GERAM - Generalised Enterprise Reference Architecture and Methodology, GRAI Integrated Methodology, методика планирования ЕА Спивака и др.);

• разработка языков класса EML - Enterprise Modeling Language (CIMOSA, GRAI, BPML - Business Process Modeling Language, UEML - Unified Enterprise Modeling Language и др.);

• разработка инструментария создания ЕА;

• собственно, разработка архитектур - корпоративных, муниципальных, федеральных.

Зарубежный опыт

• Федеральная архитектура США (проект FEA) - представляет собой комплект

* концептуальных материалов

* архитектурных моделей различных типов

* правил применения концепций и моделей на практике

* правил оценки качества достигнутых результатов

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

• Работы начаты в 1996 г.

* первые результаты - 1999 г.

* последний релиз архитектуры - 2003 г.

Разработка федеральных архитектур

• Проекты ведутся в 22 странах

* 5 уровень - Канада

* 4 уровень - США (FEA - начало в 1996г.), Дания, Германия, Сингапур, Великобритания

* 3 уровень - Испания, Нидерланды

* 2 уровень - ЮАР, Бразилия, Португалия

• Проект InfoCitizen

* шифр ЕС IST-2000-28759 - анализ архитектуры для программы "Электронная Европа"

Исследовательские работы в области ЕА

• Результаты НИОКР по заказу Министерства экономического развития и торговли в рамках ФЦП "Электронная Россия", выполненные Фондом поддержки системного проектирования, стандартизации и управления проектами (ФОСТАС)

- Электронное правительство: рекомендации по внедрению в Российской Федерации (под ред. Дрожжинова В.И. и Зиндера Е.З.), ЭКО-ТРЕНДЗ, Москва, 2004.;

• Работы в рамках плановой тематики Института проблем управления РАН "Разработка и исследование методов анализа, построения и реинжиниринга архитектуры организационных систем на основе современных технологий управления знаниями".

Реализация в учебных планах

• Программа спецдисциплины "Системная диагностика организации" для направления 523100 "Бизнес-информатика" подготовки магистра, разработанная на кафедре "Стратегическое управление информационными системами" факультета Бизнес-информатики ГУ-ВШЭ и целиком базирующаяся на архитектурном подходе;

• Бакалаврские программы дисциплин "Технологии ИТ-консалтинга" и "Практика ИТ-консалтинга", включающие основы архитектурного подхода и ряд разделов дисциплины.

- учебник "Моделирование, анализ, реорганизация и автоматизация бизнес-процессов" - Финансы и статистика, 2005г.

Проекты

• банк Москвы,

• ЮКОС, • Метасистема "Электронная Москва",

• департамент экономики г. Москвы,

• Системная модель управления компании "Вестимпекс"

• и др. Линейка продуктов CASEWISE

Видение архитектуры

Ориентация на архитектурный подход

• методология Casewise Framework базируется на модифицированной схеме Захмана

• ориентация на языки класса EML (в частности, поддержка нотации BPMN - Business Process Modeling Notation)

• широкое использование референсных архитектурных моделей

• интеграция всех слоев архитектуры

BPMN • события перед запуском процесса;

• активности (бизнес-процессы, бизнес-функции, бизнес-операции);

• конечные результаты выполнения процесса;

• потоки для демонстрации последовательности выполнения активностей;

• информационные объекты, привязанные к потокам;

• специальные узлы (шлюзы) для моделирования ветвлений;

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

• BPMN - аналог IDEF3 + наличие веб-сервисов, обеспечивающих моделирование сообщений между объектами

BPMN Extension

Референсные модели

• Модель федеральной архитектуры США - FEA (Federal Enterprise Architecture)

* Perfomance Reference Model

* Business Reference Model

* Service Component Reference Model

* Data&Information Reference Model

* Technical Reference Model

• Модель процессов ITIL (IT Infrastructure Library)

* поддержка всех элементов ITIL Framework

* более 8 000 объектов

• Модель деятельности телекоммуникационных компаний - eTOM (The Enchanced Telecom Operation Map)

ITIL Framework

ITIL Service Support

eTOM Framework IT Architecture Accelerator

• управление проектом реализации ИТ-стратегии

• оценка проектов

• расстановка приоритетов по степени срочности, важности и стратегической значимости

• планирование сроков и контроль за их реализацией.

CASE № 2 Технические требования к модели информационных потоков нефтяной компании

Цель разработки

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

• формализации информационной инфраструктуры компании в виде модели информационных потоков;

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

Модель информационных потоков должна обеспечить:

1) Информационную поддержку работ по сопровождению и развитию информационной инфраструктуры, включая:

• выявление бизнес-процессов, требующих первоочередной автоматизации

• выявление первоочередных направлений совершенствования каналов связи

• анализ информационных систем (ИС) и их взаимодействия, оценка степени покрытия бизнес-процессов и информационных потоков существующими ИС;

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

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

• анализ альтернативных вариантов совершенствования информационной инфраструктуры

Модель информационных потоков должна обеспечить:

2) Информационную поддержку работ по совершенствованию бизнес-процессов компании, включая:

• выявление бизнес-процессов, требующих совершенствования

• избавление от дублирующих действий в различных сценариях (ввод одних и тех же сведений в различные системы)

• анализ альтернативных вариантов совершенствования бизнес-процессов

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

Использование модели позволит:

• Оптимизировать функциональность и порядок внедрения новых ИС, а также проведение доработок используемых ИС;

• Уменьшить затраты на внедрение перспективных ИС;

• Оценить внедрение по времени и результатам;

• Обеспечить большее взаимопонимание между всеми участниками проектов по внедрению ИС (заказчиками, пользователями, разработчиками, консультантами и т.д.);

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

Требования к составу и структуре модели

• Модель информационных потоков должна строиться с охватом следующих структурных подразделений компании: НПО, НПЗ, ГПЗ, АЗК, терминалы (нефтебазы), филиалы торговых домов.

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

• Идентификация объектов модели должна осуществляться по функциональному признаку, а не в соответствии с имеющимися названиями элементов организационно-штатной структуры.

Требования к составу и структуре модели

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

• необходимой степенью детализации входящих и исходящих информационных потоков;

• типом бизнес-процесса - основное внимание должно быть сконцентрировано на основных бизнес-процессах (переработке и сбыте нефтепродуктов).

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

6) Модель должна включать как внутренние (прямые и обратные), так и внешние информационные потоки, обеспечивающие информационные связи с внешними по отношению к компании объектами

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

• Инструмент должен предоставлять пользователям web-доступ. При этом сайт модели информационных потоков должен генерироваться автоматически по модели (моделям), созданной в инструментальном средстве.

• Инструмент должен обеспечить качественную визуализацию модели, включая возможность навигации "кликом" по нужному объекту на любом объекте диаграммы.

• Инструмент должен обеспечить возможность сбора информации "с мест". Предполагается предоставление разработчикам на местах ограниченной функциональности, позволяющей собрать спецификации для разработанной централизованно модели. Переданная с мест информация должна автоматически (но с возможностью ручного контроля) загружаться в модель в инструментальном средстве.

• Инструмент должен обеспечивать возможность хранения и получения пользователями текстовых и табличных файлов (MS Word, MS Excel) с описаниями регламентов и шаблонами документов.

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

Информационные системы на различных НПЗ

Заключение

Архитектура - одно из средств управления изменениями

• оказание помощи менеджерам при анализе потенциальных изменений и их реализации;

• предоставление основы для совместной работы бизнес-менеджеров и ИТ-менеджеров над целями, бизнес-процессами и выстраиванием предприятия в целом;

• предоставление единого хранилища всей информации о предприятии;

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

Наличие архитектуры обеспечивает

• поддержку принятия решений и управление в условиях сложных бизнес-процессов и информационных технологий;

• план развития и изменений;

• основу для назначения приоритетов при формировании ИТ-бюджетов;

• основу для управления портфелем ИТ- проектов;

• соответствие принятым корпоративным стандартам;

• поддержку разработки новых систем.

+ более эффективное использование ИТ-систем за счет

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

• упрощения процессов управления системами;

• повторного и многократного использования технологий;

• оптимизации функциональности и процессов внедрения новых ИТ-систем, а также проведение доработок используемых ИТ-систем;

• оценки внедрения по времени и результатам;

• обеспечения взаимопонимания между всеми участниками ИТ-деятельности предприятия.

Показать полностью… https://vk.com/doc-128381368_438865557
2 Мб, 11 ноября 2016 в 14:29 - Россия, Москва, МЭСИ, 2016 г., ppt
Рекомендуемые документы в приложении