Анализ ресурсного окружения процессов

ВОПРОСЫ К ЭКЗАМЕНУ ПО ДИСЦИПЛИНЕ

«АРХИТЕКТУРА ПРЕДПРИЯТИЯ»

1. Понятие «архитектуры предприятия»

2. Базовые определения по архитектуре

3. Стратегические цели и задачи предприятия

4. Бизнес-архитектуры предприятия

5. ИТ-архитектуры предприятия

6. Информационная архитектура (EIA)

7. Архитектура прикладных решений (ЕSА)

8. Техническая архитектуры предприятия

9. Принципы построения архитектуры предприятия

10. Современные методики описания архитектуры предприятия

11. Структура организационной компоненты. Структура информационной компоненты.

12. Определение моделирования. Типология моделей.

13. Общие принципы моделирования

14. Модель Захмана

15. Модель META Group

16. Модель Gartner

17. Модель TOGAF

18. Объектный анализ

19. Процессный анализ. Понятие процесса

20. Компоненты процесса. Анализ процесса.

21. Анализ топологии процесса. Анализ характеристик процесса

22. Анализ ошибок процесса. Анализ динамики процессов.

23. Анализ ресурсного окружения процессов.

24. Мониторинг процесса. Анализ возможностей стандартизации процесса (создание референтных и эталонных моделей)

25. Основные методики и направления моделирования

26. IDEF-технологии

27. Основы подхода и результаты внедрения ВРМ

 

 

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

Бизнес стратегия – определяет направление развития бизнеса в соответствии со стратегическими целями и задачами, стоящими перед предприятием, и отвечает на вопрос, почему предприятие должно развиваться именно в этом направлении. Бизнес стратегия включает:

· Цели и задачи стоящие перед предприятием;

· Бизнес решения, необходимые для достижения поставленных целей и задач;

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

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

· Проекты, которые можно запустить для выполнения бизнес стратегии;

· Варианты решения текущих задач и проблем;

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

4.Бизнес - архитектура предприятия (EBA - Enterprise Business Architecture) – это целевое построение организационной структуры предприятия, увязанное с его миссией, стратегией, бизнес - целями. В ходе построения бизнес - архитектуры определяются необходимые бизнес-процессы, информационные и материальные потоки, а также организационно-штатная структура.

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

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

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

ИТ - архитектура предприятия, или, другими словами, архитектура информационных технологий, представляет собой совокупность технических и технологических решений для обеспечения эффективного функционирования бизнес - процессов предприятия в соответствии с правилами и концепциями, определяемыми бизнес – архитектурой.

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

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

· Enterprise Information Architecture (EIA) – информационная архитектура;

· Enterprise Solution Architecture (ESA) – архитектура прикладных решений;

· Enterprise Technical Architecture (ETA) – техническая архитектура.

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

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

6.Информационная архитектура (Enterprise Information Architecture, EIA) или, другими словами, архитектура информации – это (с точки зрения аналитиков компании Meta Group) управляемый набор методик, описывающий информационную модель предприятия и включающий:

· Базы данных и хранилища данных.

· Информационные потоки (как внутри организации, так и связи с внешним миром).

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

7.Архитектура прикладных решений (Enterprise Solution Architecture ESA) – или, другими словами, архитектура приложений, включает совокупность программных продуктов и интерфейсов между ними.

Архитектуру прикладных решений разделяют на два направления:

· Область разработки прикладных систем;

· Портфель прикладных систем.

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

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

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

· Взаимодействие с другими системами (интерфейсы) – описывает взаимодействие приложения с внешними объектами (программными продуктами, пользователями).

Архитектура прикладных решений описывает ситуацию, сложившуюся в ИТ - подразделении на текущий момент времени (т.е. это картина, демонстрирующая «технологическое обеспечение» бизнес - процессов, где каждой основной бизнес - функции соответствуют определенные приложения). На основе архитектуры прикладных решений строятся планы последующего развития информационных технологий в компании, разрабатываются планы мероприятий и проектов, необходимых для достижения стратегических целей. На данном уровне лучше всего отслеживается взаимодействие бизнес - архитектуры предприятия и ИТ - архитектуры, так как можно определить взаимосвязи между организационной структурой предприятия и используемыми приложениями. В этом случае для оптимизации управления приложениями их разделяют на определенные группы (домены) в соответствии с функциональными возможностями. Следует отметить, что подобное разделение позволяет проще идентифицировать владельца приложения, определять его соответствие бизнес - требованиям.

8.Техническая архитектура предприятия (Enterprise Technical Architecture, ETA) – это совокупность программно-аппаратных средств, методов и стандартов, обеспечивающих эффективное функционирование приложений. Другими словами, под технической архитектурой мы будем понимать полное описание инфраструктуры предприятия, включающее:

· Информацию об инфраструктуре предприятия;

· Системное программное обеспечение (СУБД, системы интеграции);

· Стандарты на программно-аппаратные средства;

· Средства обеспечения безопасности (программно-аппаратные);

· Системы управления инфраструктурой.

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

9. Аналитики выделяют следующие подходы процессу построения архитектуры предприятия:

· Традиционный подход - требует существенных затрат времени и ресурсов для построения архитектуры предприятии. Первый этап построения архитектуры рассматривается как проект в ходе, которого собирается детализированная информация о состоянии предприятия (текущая архитектура) и на ее основе начинают разрабатываться планы развития (целевая архитектура). Основу данного подхода составляет процесс построения архитектуры предприятия;

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

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

Архитектура предприятия развивается циклично. В ходе разработки стратегии развития предприятия выявляются изменения в бизнес - архитектуре предприятия, позволяющие оптимизировать его бизнес - процессы, а изменение бизнес - процессов предприятия непосредственно влияет на изменение ИТ - архитектуры. Далее разрабатывается план миграции, в ходе выполнения которого происходит переход из текущего состояния в планируемое. При этом процесс миграции является лишь очередным шагом на пути преобразования предприятия и его окончание означает переход предприятия на новый виток развития, вновь начинающийся с разработки стратегии.

Один из самых первых и наиболее удачных процессов разработки архитектуры предприятия был предложен Стивеном Спиваком (Steven Spewak) и назывался EAP (Enterprise Architecture Planning). Модель выделяет в архитектуре предприятия семь шагов, разделенных на четыре уровня, и обеспечивает высокоуровневый взгляд на предприятие с точки зрения бизнеса.

Уровень 1. Это уровень начала работ и активации архитектурного процесса. На этапе инициирования процесса планирования разрабатываются и описываются основные концепции развития архитектуры предприятия. Разрабатываются принципы построения архитектуры.

Уровень 2. Этот уровень описывает состояние предприятия в настоящий момент времени. Другими словами, это уровень разработки текущей архитектуры предприятия. Здесь происходит бизнес моделирование (разработка текущей бизнес архитектуры) и описание текущих систем и технологий (документирование текущей архитектуры информационных систем).

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

Уровень 4. Это уровень, обеспечивающий разработку плана перехода из текущего состояния в будущее. На этом уровне разрабатывается план миграции.

Процесс разработки архитектуры предприятия имеет циклическую структуру.

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

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

Основу управления и контроля архитектурного процесса, как правило, составляет набор руководящих принципов. Многие аналитики выделяют следующий набор принципов:

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

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

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

· Должны быть разработаны и поддерживаться в актуальном состоянии стандарты, правила и политики. Все проекты должны контролироваться на соответствие стандартам.

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

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

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

10. Первые версии многих современных методик были разработаны еще в 90-х г. прошлого века. Многие из них постоянно модернизируются или становятся основой для других, более современных методологий:

1. Zachman framework – методика, опубликованная впервые в 1987 году Zachman Institute for Framework Advancement (ZIFA). Методика постоянно обновляется и поддерживается в актуальном состоянии. Лежит в основе многих программных продуктов для архитектурного моделирования (например, CASE Wise).

2. EAP (Enterprise Architecture Planning) – коммерческая методика, разработанная в 1992 г. Стивеном Спиваком (Steven Spewak) на основе двух верхних уровней Zachman framework: Scope (Planner) и Business Model (Owner). Методика представляет собой архитектурный процесс, обеспечивающий инициализацию и разработку архитектуры в рамках всего предприятия.

3. PERA (Purdue Enterprise Reference Architecture). Методика разрабатывалась в 1989 – 1992 гг. в Purdue Laboratory for Applied Industry Control (PLAIC). В основе методики заложена декомпозиция плана внедрения информационной системы на отдельные шаги и упрощения за счет этого ее внедрения и интеграции. В настоящее время эту методику не поддерживают в актуальном состоянии.

4. TOGAF (The Open Group Architecture Framework) была разработана в 1995 г. Методика позиционируется авторами как средство разработки информационных систем. Методика сфокусирована на эффективном функционировании приложений, критичных для бизнеса.

5. CIMOSA (Computer Integrated Manufacturing Open Sys), известная как CIM Open System Architecture, была разработана компанией AMICE Consortium в 1996 г. Методика являлась одной из инициатив в рамках программы European ESPRIT. В настоящее время можно говорить о том, что CIMOSA является европейским архитектурным стандартом для построения комплексных автоматизированных производств (CIM – Сomputer-Integrated Manufacturing), и поддерживает все этапы их жизненного цикла.

6. IAF (Integrated Architecture Framework) разрабатывалась в 1996 г. В ее основу были заложены: Zachman Framework, EAP (Enterprise Architecture Planning). В настоящий момент эта методика разрабатывается и используется Cap Gemini и Ernst & Young consulting.

7. FEAF (Federal Enterprise Architecture Framework) – была разработана в 1996г. в USA Chief Information Officers Council. Методика обеспечивает построение крупных комплексных систем для государственных организаций. Данная методика легла в основу многих современных концепций построения архитектуры предприятия (например, Treasury Enterprise Architecture Framework, TEAF).

8. JTA (Joint Technical Architecture). Первая версия этой методики разрабатывалась для US Department of Defends и была опубликована 22 августа 1996 г. В настоящее время методика поддерживается в актуальном состоянии National Defiance Industrial Association (NDIA).

9. E2AF (Extended Enterprise Architecture Framework) была разработана в Institute For Enterprise Architecture Development в 2002 г. Методика включает в себя элементы следующих методик: Zachman Framework, EAP (Enterprise Architecture Planning), IAF (Integrated Architecture Framework), Federal Enterprise Architecture Framework.

Наиболее интересные методики построения архитектуры предприятия были предложены такими аналитическими компаниями как Meta Group (2002) и Gartner (2005).

10. META Group выпустила в 2002 г. документ Enterprise Architecture Desk Reference, описывающий подход этой аналитической компании к архитектуре предприятия. В основе методики заложено разделение архитектуры предприятия на четыре основных компонента: бизнес архитектуру, архитектуру приложений, архитектуру информации, архитектуру технологий.

11. Gartner в настоящий момент разработал архитектурную методику под названием Gartner Enterprise Architecture Framework (GEAF). Методика была опубликована в 2005 г. и существенно отличалась от моделей использующихся аналитиками компании ранее. В основу новой методики лег документ Enterprise Architecture Desk Reference компании Meta Group.

Модель Захмана

Основные правила заполнения таблицы следующие:

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

· порядок следования колонок несущественен;

· каждая клетка содержит соответствующее описание аспекта реализации системы в виде определенной модели или, возможно, простого описания (текстового документа);

· базовые модели для каждой из колонок являются уникальными;

· соответствующие модели в клетках каждого ряда в совокупности образуют полное описание системы с выбранной перспективы;

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

Первая строка соответствует уровню планирования бизнеса в целом (бизнес-модель). На этом уровне вводятся достаточно общие основные понятия, определяющие бизнес – например, продукты и услуги, клиенты, расположение объектов бизнеса, а также формулируется бизнес-стратегия (колонка 6 – мотивация). Фактически, данная строка определяет контекст всех последующих строк.

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

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

На четвертом уровне – технологической или физической модели – осуществляется привязка данных и операций над ними к выбранным технологиям реализации. Например, здесь может быть определен выбор реляционной СУБД, или средств работы с неструктурированными данными, или объектно-ориентированной среды.

Пятый уровень соответствует детальной реализации системы, включая конкретные модели оборудования, топологию сети, производителя и версию СУБД, средства разработки и собственно готовый программный код. Многие из работ на данном уровне часто выполняются субподрядчиками.

Последний, шестой уровень описывает работающую систему. На этом уровне могут быть введены, в том числе, такие объекты, как инструкции для работы c системой, фактические базы данных, работа службы HelpDesk. Надо заметить, что в исходной работе Захмана содержание этого уровня не детализируется. При развитии модели, как будет показано ниже, отмечены возможности рассмотрения аспектов функционирования работающей системы с точки зрения, например, конечного пользователя или эксплуатирующих служб.

Методика META Group

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

Исторически архитектурная методика META Group оперировала таким понятием, как Технологическая архитектура масштаба предприятия (EWTA – Enterprisewide Technical Architecture). Однако по мере того, как в индустрии происходило понимание более тесной связи между бизнесом и информационными технологиями, в представления (домены или предметные области) архитектуры предприятия META Group были добавлены такие домены, как Бизнес- архитектура (EBA – Enterprise Business Architecture), Архитектура информации (EAI – Enterprise Information Architecture) и Портфель прикладных систем предприятия (EAP – Enterprise Application Portfolio). Это соответствует эволюции понятия " Архитектура предприятия", которая происходила на рынке в целом (см."Архитектура предприятия: основные определения"), и принятой сегодня практике выделения доменов архитектуры.

Кроме того, расширяя многие другие представления, архитектурная методика META Group рассматривает архитектуру предприятия в интеграции с другими ключевыми процессами, в частности, с процессом управления корпоративными ИТ-программами и проектами (EPM – Enterprise Program Management) и процессом выработки стратегии и планирования. В частности, отмечается, что архитектура, собственно говоря, и реализуется на практике через процесс управления ИТ-программами и проектами.

Объединяющим для всех доменов архитектуры META Group является процесс формулировки бизнес-требований к ИТ-архитектуре, что оформляется в виде двух документов: Видения общих требований (CRV – Common requirements Vision) и Принципах концептуальной архитектуры (CA – Conceptual Architecture).

Рис. 8.5. Аналитическая работа и компоненты Архитектуры предприятия

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

На этапе 1 разрабатывается Видение общих требований. Разработка Видения общих требований включает в себя:

· анализ тенденций развития внешней для предприятия среды, включая технологические тенденции;

· бизнес-стратегии и основные движущие силы с точки зрения бизнеса;

· требования к информационным системам со стороны бизнеса;

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

Этап 2 состоит в разработке Концептуальной архитектуры, которая определяет логически связанный набор принципов, обеспечивающий общее руководство для развития информационных систем предприятия и технологической инфраструктуры. На этом же этапе параллельно ведется разработка наиболее приоритетных доменов архитектуры. Здесь же выполняется анализ на несоответствие (gap- анализ) между текущим и желаемым состоянием архитектуры.

Этап 3 состоит в разработке плана реализации, обеспечивающего миграцию в сторону желаемого состояния архитектуры.

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

. 16.Cтруктура и модель описания ИТ-архитектуры Gartner

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

• Бизнес-потребности, которые определяют ключевые требования к конкретной технологии для данной индустрии и организации. Фактически здесь определяется индивидуальность архитектуры. Другой важный аспект связан с позиционированием ИТ в организации – либо ИТ-архитектура формируется для максимального уменьшения издержек, либо она должна обеспечивать возможности быстрых изменений и высокую гибкость. Другие примеры могут включать быстрое распространение информации, высокую безопасность, простоту использования и требуемую степень надежности.
• Принципы, которые включают в себя те основополагающие подходы, которых придерживается руководство. Например, это может быть принцип максимального использования стандартных приложений вместо заказных разработок, правила относительно того, кто владеет данными и пр. Большинство организаций могут иметь от 20 до 30 таких базовых принципов.
• Процессы и руководства во всех областях жизненного цикла элементов архитектуры. Этот раздел может охватывать такие области как документирование требований пользователей, стили программирования, процессы обеспечения качества или управление конфигурациями устройств и систем. Здесь также могут быть определены "эталонные модели" для организации пользовательского интерфейса, доступа к данным, управления содержанием.
• Раздел Протоколы и Стандарты описывает те промышленные протоколы и стандарты, которые должны поддерживаться используемыми в организации технологиями.
• Раздел Используемые продукты и технологии является, по сути дела, утвержденным для организации списком продуктов или технологий. Они закупаются и используются как для создания приложений, так и для формирования инфраструктуры и обеспечения интеграции с внешними системами. Эта часть содержит взвешенную оценку всех "за" и "против" о конкретных поставщиках.

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

В 2002 году Gartner сформулировала новую концепцию архитектуры предприятия, которая стала определенным обобщением рассмотренной ранее модели ИТ-архитектуры на уровень Бизнес-архитектуры, косвенным отражением растущей важности вопросов взаимодействия предприятий между собой, влияния концепций сервис-ориентированной архитектуры, осознания того факта, что существуют различные стили архитектуры информационных систем, соответствующие различным стилям бизнес-процессов. Мы уже отмечали выше, что типичными стилями бизнес-процессов являются массовая обработка транзакций, операции в реальном времени, аналитические процессы и бизнес- анализ, совместная работа.

Эта модель в какой-то степени расширяет рассмотренные выше представления, а также подчеркивает взаимосвязь между понятиями "Электронной нервной системы" предприятия, которые были сформулированы в свое время Биллом Гейтсом, основателем, а ныне Председателем и Главным архитектором программного обеспечения компании Microsoft, и практической реализации этих идей в рамках современных подходов к проектированию архитектуры ИТ предприятия. Кстати, обратите внимание, как называется должность Билла Гейтса. Не является ли это еще одним подтверждением важности вопросов систематического построения и описания архитектуры?

Билл Гейтс в своей книге "Бизнес со скоростью мысли" [5.12] дал следующее определение: "электронная нервная система есть совокупность электронных процессов, с помощью которых организации воспринимают мир и адекватно реагируют на изменения, происходящие в нем".

Модель Gartner 2002 года сформулирована в виде четырех связанных, взаимозависимых и усложняющихся уровней:

• Среда бизнес-взаимодействия (Business Relationship Grid);
• Бизнес-процессы и стили бизнес-процессов;
• Шаблоны;
• Технологические строительные блоки (кирпичики – bricks).

Рис. 8.3. Уровни модели архитектуры Gartner

При этом уровни ИТ-архитектуры соответствуют различным уровням выполнения операций реального бизнеса так, как показано нарис. 8.4.

 

Рис. 8.4. Архитектура ИТ в бизнес-контексте

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

• верхний уровень Среды бизнес-взаимодействия описывает новую модель "виртуального" бизнеса, а также все, что связано с кооперацией предприятий и бизнесом B2B. Этот уровень соответствует понятию "отраслевой нервной системы" взаимодействующих предприятий. Он получил развитие в связи с распространением Интернет как среды взаимодействия, и связан с понятиями доступа, межорганизационного взаимодействия;
• второй уровень Стили бизнес-процессов описывает, как организация выполняет свои ключевые функции, т.е. включает в себя бизнес-процессы предприятия, такие как обработка заказа, мониторинг производственных процессов, анализ использования критически важных ресурсов, совместная работа с информацией;
• следующий уровень Шаблоны описывает модели и алгоритмы, которые могут широко использоваться для решения различных задач на предприятии. Отметим, что шаблоны охватывают не только область программного обеспечения, но и соответствующие сетевые и вычислительные ресурсы, как мы рассматривали ранее в "Технологическая архитектура, стандарты и шаблоны". Примерами шаблонов является трехуровневая архитектура прикладных систем (интерфейс-логика-данные), использование "толстого" клиента в архитектуре клиент/сервер, хранилища данных. Что касается приложений, то упор сделан на использовании шаблонов сервис-ориентированной архитектуры, т.е. реализации приложений в виде модульного набора различных типов сервисов. Это, в том числе, позволяет в перспективе интегрировать приложения как web-сервисы.
• нижний уровень Строительные блоки (Bricks) соответствует технологической архитектуре и включает в себя операционные системы, серверы, базы данных, сами данные и пр.

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

Полная модель представляет собой "трехмерную" комбинацию бизнес-архитектуры, технической и информационной архитектур. При этом описанные выше слои среды бизнес-взаимодействия, стилей бизнес-процессов, шаблонов и строительных блоков пересекаются со слоями Информационной архитектуры (Домен данных, Домен приложений, Домен интеграции, Домен доступа) и Технической архитектуры (Домен инфраструктуры, Домен системного управления и Домен безопасности. По большому счету, "все пересекается со всем". Например, при построении прикладных систем могут использоваться шаблоны проектирования и строительные технологические блоки. При этом для управления прикладной системы используются технологии системного управления и также должны быть учтены вопросы безопасности.

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

Консультационные услуги Gartner предоставляет конечным заказчикам — организациям и предприятиям, внедряющим информационные технологии (прежде всего, руководителям их информационных служб), а также инвесторам на рынке информационных технологий и поставщикам. Основные направления консультационных услуг: оптимизация бюджета на информационные технологии, выбор поставщиков информационных технологий и налаживание взаимоотношений с ними, стратегическая архитектура информационных технологий в организации, прогнозирование развития технологий.

На ежегодной основе Gartner организует около 50 конференций, специализированных по региону или какой-либо прикладной тематике. Также на регулярной основе организуются симпозиумы, выставки, тематические саммиты. Постоянные партнёры по организации событий: Hewlett Packard, CA Technologies, IBM, Microsoft, Oracle, SAP, British Telecom, Autonomy.

Методика TOGAF

Методика описания архитектуры TOGAF (сокращение от The Open Group Architecture Framework) была предложена некоммерческим объединением The Open Group, в которое входит ряд ведущих производителей информационных технологий, а также компаний из списка Fortune 1000. TOGAF позиционируется ее авторами не как некоторая эталонная модель, а как "средство для разработки архитектур информационных систем". Основное назначение – ускорить и облегчить процесс разработки архитектуры конкретной организации, обеспечивая при этом возможность будущего развития. В декабре 2003 года была опубликована версия 8.1 этой модели.

Основным полем для применения TOGAF является, прежде всего, программная инфраструктура информационной системы (в противоположность таким типам архитектур, как бизнес-архитектура, архитектура данных и приложений). Таким образом, она в наилучшей мере подходит для описания интеграционных компонент, использующихся для поддержки широкого спектра корпоративных приложений, прежде всего, критичных для бизнеса (mission-critical). Поскольку эта интеграционная архитектура сильно зависит от принимаемых решений в остальных областях, то в рамках TOGAF в необходимой степени рассматриваются и эти смежные области. В состав модели TOGAF входят две основные компоненты – методика ADM (Architecture Development Method), определяющая процесс разработки архитектуры, и Базовая Архитектура (Foundation Architecture). Она дополняется соответствующей базой данных ресурсов, включающей описания архитектурных принципов, примеров реализации, а также специализированный язык ADML. Заметим, что в описании TOGAF добавлен специальный документ, поясняющий соответствие между понятиями TOGAF и моделью Захмана.

Рис. 8.9. Структура TOGAF

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

В соответствии с методикой ADM, процесс разработки архитектуры включает следующие фазы:

• Подготовка: уточнение модели под особенности организации, определение принципов реализации проекта.
• Фаза A: определение границ проекта, разработка общего представления (Vision) архитектуры; утверждение плана работ и подхода руководством.
• Фаза B: разработка бизнес-архитектуры предприятия.
• Фаза C: разработка архитектуры данных и архитектуры приложений.
• Фаза D: разработка технологической архитектуры.
• Фаза E: проверка возможности реализации предложенных решений.
• Фаза F: планирование перехода к новой системе.
• Фаза G: формирование системы управления преобразованиями.
• Фаза H: управление изменением архитектуры.

Каждая фаза, в свою очередь разбивается на подпроцессы (этапы), отдельные работы и так далее. Например, фаза D включает следующие основные подпроцессы:

• Описание существующей технологической архитектуры.
• Обзор бизнес-архитектуры, архитектуры данных и приложений для определения начальных данных и необходимой степени детализации.
• Описание существующей системы с необходимой степенью детализации, которая выбирается для того, чтобы можно было выявить необходимые изменения при формировании целевой архитектуры. Формирование реестра используемых платформ программного и аппаратного обеспечения.
• Выявление и описание элементарных архитектурных блоков – кандидатов на использование в новой архитектуре. Фактически, речь идет о возможных архитектурных шаблонах.
• Разработка черновика технического отчета, резюмирующего основные результаты изучения существующего состояния и возможности использования типовых блоков.
• Направление черновика отчета на рецензирование, анализ комментариев и внесение, при необходимости, поправок.
• Формирование целевой технологической архитектуры.
• Описание существующей системы в терминах TOGAF.
• Определение перспектив (представлений) архитектуры.
• Формирование модели целевой архитектуры.
• Определение ИТ-служб (сервисов).
• Подтверждение учета бизнес-требований.
• Определение архитектуры и используемых блоков (шаблонов).
• Проведение анализа расхождений (gap analysis).

Для каждого такого подпроцесса определяются решаемые в его ходе задачи, входные и выходные документы. Важно отметить, что процесс предусматривает не обязательную, но возможную адаптацию самого метода к условиям конкретного предприятия, которая осуществляется на предварительной фазе. Это может быть вызвано как необходимостью учета других существующих стандартов предприятия, так и привлечением аутсорсинговых компаний к разработке архитектуры. Интересным примером может являться проект внедрения корпоративной ERP-системы. В этом случае необходимо определенное изменение порядка разработки – так, бизнес-архитектура в этом случае может определяться возможностями, поддерживаемыми в выбранном продукте, поэтому фазы B и С в данном случае будут выполняться не до, а после фазы D!

Анализ ошибок процесса

Этапы анализа ошибок процесса:

1) классификация возможных ошибок процесса;

2) описание ошибок процесса;

3) выявление ошибок в процессе.

Возможные ошибки, которые могут возникать при моделировании бизнес-процессов:

· незавершенность. Наличие пробелов в описании процесса, например отсутствие подпроцесса, процедуры или информационного ресурса;

· несоответствие. Неадекватное использование информационных ресурсов в различных частях процесса. Это приводит к искаженному восприятию информации или к неясности указаний;

· иерархическая несовместимость. Несовместимость процесса с подпроцессами, его составляющими;

· «наследственная» несовместимость. Наличие конфликта между основными и последующими процессами.

Анализ динамики процессов

Динамика процессов исследуется с помощью динамической (имитационной) модели.

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

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

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

Анализ ресурсного окружения процессов

Основу процесса составляют выполняемые функции. Для выполнения каждой из функций требуются ресурсы:

· людские – участники процесса (кто выполняет);

· производственные – станки, оборудование, компьютеры, транспорт (при помощи чего выполняет);

· материальные – материалы, комплектующие, энергетические ресурсы (с использованием чего выполняет);

· информационные – данные, документы, информация (на основании чего выполняет);

· интеллектуальные – знания и полномочия участников и владельца процесса.

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