Практикум по дисциплине «Архитектура предприятия»

Модель представляется как атрибутивная и нормализованная модель

«сущность-связь», отражающая все намерения, которые были ранее представлены в семантической модели.

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

Позиция субподрядчиков (детализированные спецификации). Приводятся описания данных (библиотека). Определение всех объектных данных,

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

В качестве примера приведем модель Захмана в применении к государству.

11

Другой пример – модель Захмана для описания корпоративной

архитектуры.

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

1.Изучить основные элементы модели Захмана.

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

3.Представить отчет о работе в виде конспекта теоретического материала,

таблицы схемы Захмана для конкретного примера и ответов на контрольные вопросы.

Варианты заданий

1.Автомобильный завод.

2.Автосервис.

3.Агропромышленный комплекс.

4.Бакалейный магазин.

5.Банк.

12

6.Единый информационный расчетный центр (ЕИРЦ).

7.Магазин «М-Видео».

8.Магазин «Спортмастер».

9.Магазин стройматериалов.

10.Мебельный магазин.

11.Молочный комбинат.

12.Нефтеперерабатывающий завод.

13.Производство средств вычислительной техники.

14.Ресторан.

15.Университет.

16.Фирма для производства рекламной продукции.

17.Поликлиника.

18.Аптека.

19.Фирма по производству программного обеспечения.

20.Склад электротехнической продукции.

КОНТРОЛЬНЫЕ ВОПРОСЫ

1.Что входит в понятие «архитектура предприятия»?

2.Что такое концептуальная модель?

3.Какова иерархия уровней в модели Захмана?

4.По каким признакам осуществляется детализация каждого уровня?

5.В каких случаях целесообразно использовать модель Захмана?

13

ТЕМА № 2 ИСПОЛЬЗОВАНИЕ СХЕМ «3Д-ПРЕДПРИЯТИЕ» И «МУЛЬТИКУБ»

ДЛЯ ОПИСАНИЯ АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ

Схема «3Д-Предприятие»

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

Схема "3D-Предприятие" – это стратегическая модель информационно-

управляющей системы (ИУС), трансформирующейся вместе с предприятием,

целям которого она служит. Модель строится в трех измерениях:

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

"3D-предприятия". Она строится для отражения взаимосвязей ключевых компонентов ИУС предприятия на выбранном историческом участке времени его развития в трех измерениях, предусмотренных 3D-схемой. Первые две оси аналогичны (но не обязательно строго совпадают) тем, что использованы в плоской модели Захмана. Третья ось позволяет явно определить те изменения,

которые происходили или будут происходить с предприятием, его

14

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

1.Горизонтальная ось уровня проектирования и использования ИУС; "горизонтальных" уровней: потребности и планы, бизнес-модель, логическая модель, техническая конструкция, детальная реализация, практика использования.

2.Вертикальная ось раздела обеспечения и аспекта работы ИУС; шесть

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

системы – люди и организационные единицы), как (функции и процессы), что

(объекты, информация), где (размещение, коммуникации), когда (время и

графики функционирования).

3. Ось времени, в котором развивается предприятие и его ИУС. Это шесть возможных (но не единственных) стадий на "верхней грани" модели,

соответствующих (возможным) стадиям жизненного цикла системы: анализ

(стратегический может отделяться от детального), проектирование

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

или проекты разных подсистем ИС.

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

15

времени в виде проектов (в частности, для того, чтобы не вступать в непродуктивный конфликт с обычаями предприятия).

Например, работами по развитию бизнеса предприятия могут быть фазы управления предприятием:

ситуационный и диагностический анализ;

выдвижение целей и выбор стратегий;

разработка плана мероприятий осуществления стратегий;

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

тактический и оперативный мониторинг;

стратегический мониторинг, возобновление анализа и совершенствование стратегий.

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

указанные ранее.

Схема "Мультикуб" и ее применение

Модель "3D-Предприятие" может служить базой для перехода к следующему, более конкретному уровню планирования при управлении проектной программой. Для этого рассматривается сочетание областей работ каждого проекта и нескольких дополнительных осей:

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

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

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

Рассмотрим процесс соединения выделенной в архитектуре 3D-

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

16

ТЕМА № 3

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

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

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

моделей.

Бизнес модель – компактное упрощённое представление о бизнесе,

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

Бизнес модель выражает суть бизнес-системы, поэтому её может разработать только управленческая команда этой организации. Бизнес модель должна отвечать на ключевые вопросы об описываемой бизнес-системе, такие как "что?", "как?", "для кого?", "с кем?", "где?", "когда?" и т.д.

Бизнес модель логически описывает, каким образом организация создаёт,

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

инфраструктуру, организационную структуру, способы продаж, операционные процессы и политики.

Основные этапы построения типовой бизнес модели имеют вид:

Этап 1. Идентификация критически важных для предприятия процессов.

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

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

18

выполняются плохо и являются источниками неудовлетворенности клиентов;

процессы, в которых имеются возможности для экономии.

Желательно, чтобы рекомендуемое число таких процессов, не превышало 8

в соответствии с принципом: "семь плюс-минус два" объекта. При необходимости схожие бизнес-процессы могут быть объединены в группы или классы.

Этап 2. Отследить связи между этими процессами и бизнес-стратегиями,

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

или по некоторой условной шкале, например, 9-3-1, в соответствии с которой 9

обозначает сильную взаимосвязь, 3 – промежуточную, 1 – слабую.

Этап 3. Построить модели высокого уровня для ключевых бизнес-

процессов. Это включает последовательность основных шагов (желательно, не более восьми на процесс).

Этап 4. Для каждого шага процессов, идентифицированных на этапе 3,

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

Этап 5. Идентифицировать и документировать основные информационные объекты (рекомендуется не более 8).

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

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

использованием таких инструментов, как:

декомпозиция функций/процессов;

анализ бизнес-событий;

моделирование местоположений выполнения функций/процессов;

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

19

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

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

идентифицировать основные процессы, обеспечивающие выполнение функций организации;

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

идентифицировать пересечения и излишние функции/процессы.

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

20