2) Использование новых технологии в педагогических, научно технических и административных сферах.

В настоящее время происходит активное внедрение ИТ систем в рынок товаров и услуг. И 1 из главных проектов, которые не только внедряют, но и оптимизируют производство является создание архитектуры предприятия. В данном случае рассматривается влияние маркетинга на изменение на Бизнес‐архитектуры, Архитектура информации, Архитектуры прикладных систем и Технологическую архитектуру. Но в этой главе я отражу текущее состояние дел в НГИЭУ с помощью бизнес-ориетированных программ ARIS-express, bp-win. project expert. С помощью них можно оценить возможные области для оптимизации деятельности, расходов.

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

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

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

ARIS-express

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

Управление развитием информационных систем

[+]

Записаться

|

Вам нравится?  Нравится 29 студентам

| Поделиться |

Поддержать курс

| Скачать электронную книгу

Поделиться

Лекция 2:

2.6. Стандартизация архитектуры на уровне организации

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

1. к порядку выполнения работ по описанию архитектуры;

2. к составу и структуре моделей архитектуры;

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

Стандарт должен включать в себя:

1. порядок выполнения работ по описанию архитектуры;

2. методику создания и структурирования единой базы знаний о деятельности организации;

3. методику (тактику) интервьюирования;

4. методику описания (моделирования) архитектуры;

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

Далее в данном разделе рассматривается методика описания (моделирования) архитектуры, ориентированная на поддержку средой моделирования Casewise Corporate Modeler, которая позволяет обеспечить реализацию основных требований к описанию: системность, целостность и однородность описания, простоту, наглядность, открытость к изменениям, возможность автоматизированного анализа.

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

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

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

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

4. ограничение количества функциональных объектов (не более 6-7) на каждом из уровней для обеспечения читабельности и понимаемости модели;

5. последовательное приближение к конечному результату.

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

1. функциональную компоненту (иерархию процессов, функций, операций);

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

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

4. ИТ-компоненту, фиксирующую уровень и степень автоматизации объектов функциональной компоненты.

Описание осуществляется на основе структурного подхода Casewise (Casewise framework) – схемы архитектуры организации, описываемой в виде матрицы (см. рис.2.3), представляющей собой модифицированную схему Захмана, столбцы которой характеризуют разные аспекты моделирования архитектуры ("Процессы", "Организационная структура", "Данные" и "ИТ-инфраструктура"), а строки уровни абстракции моделирования. Аспекты, представленные в столбцах матрицы соответствуют вопросам: Как?, Кто?, Что?, Какими средствами? Создание описания архитектуры фактически является совокупностью процедур, состоящих из ответов на перечисленные вопросы по уровням абстракции моделирования.

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

1. модели бизнес-среды организации (уровень бизнеса, внешняя среда);

2. модели концептуального уровня (уровень организации);

3. логические модели (уровень подразделений);

4. физические модели (уровень технологий).

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

Таблица 2.4.
Область описания	Назначение	Категории диаграмм
Процессы	Функциональные области деятельности Процессы функциональных областей Логические схемы процессов Детальные схемы процессов	Контекстная диаграмма Список функциональных областей, диаграмма уровня процессов Логическая схема процесса Детальная схема процесса
Организационная структура	Организационная структура по функциональным областям Ролевая организационная иерархия Организационная структура подразделений Ролевая организационная структура	Организационная схема верхнего уровня Организационная схема со сферами деятельности Организационная схема уровня подразделений Ролевая организационная структура
Данные	Данные функциональных областей Данные процессов функциональных областей Логические данные процессовФизические данные процессов	Список сущностей (подсхем) предметной области Диаграмма взаимосвязей сущностей (без атрибутов) Диаграмма взаимосвязей сущностей (с атрибутами) Матрица взаимосвязей Сущность\ Функциональный объект
ИT–инфраструктура	Классификация систем Классификация систем по целевому назначению Взаимосвязь систем подразделений Матрица Процессы/Средства автоматизации	Перечень классов систем (ИАС, расчетные и т.п.) Перечень используемых систем Перечень функций системы Матрица Процессы/Системы

Стандарт определяет необходимый набор объектов, с помощью которых осуществляется моделирование:

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

2. шаблоны и категории объектов;

3. типы связей и ассоциаций, необходимых для моделирования;

4. правила именования и нумерации объектов и схем;

5. стили;

6. перечни атрибутов объектов для обеспечения полноты описания деятельности и возможности получения необходимых отчетов из Casewise Corporate Modeler.

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

Таблица 2.5.
Наименование и представление	Описание
Внешняя сущность	Назначение. Моделирует внешние по отношению к организации/подразделению объекты. При этом сущности, внешние по отношению ко всей организации, изображаются овалами красного цвета (см. пример слева сверху), сущности, внешние по отношению к подразделению, изображаются овалами розового цвета (см. пример слева снизу). Имя. Имя представляет собой существительное. Пример: склад, клиент, поставщик и т.д.
Функциональный объект\функция	Назначение. Моделирует функциональный объект любого уровня детализации (от сферы деятельности до функции нижнего уровня), допускает детализацию диаграммой следующего уровня, присутствие которой обозначается символом декомпозиции. Поле "Имя" содержит наименование процесса в виде глагола в неопределенной форме. Пример: "Проверить поступление денег". Детализация. Осуществляется посредством декомпозиции данного процесса диаграммами уровня процессов более низкого уровня, логическими схемами процессов или детальными схемами процессов.
Хранилище данных	Назначение. Моделирует накопитель данных Имя. Идентифицирует его содержимое. Должно быть существительным.
Поток данных	Назначение. Моделирует направленный поток данных Имя. Имя отражает содержание потока
Символ декомпозиции	Назначение. Показывает, что данный процесс детализируется диаграммой следующего уровня

В настоящее время наблюдается тенденция интеграции разнообразных методов моделирования и анализа систем, проявляющаяся в форме создания интегрированных средств моделирования. Одним из таких средств является продукт, носящий название ARIS - Architecture of Integrated Information System, разработанный германской фирмой IDS Scheer. Его методическую основу составляет совокупность различных методов моделирования, отражающих разные взгляды на исследуемую систему. Одна и та же модель может разрабатываться с использованием нескольких методов, что позволяет использовать ARIS специалистам с различными теоретическими знаниями и настраивать его на работу с системами, имеющими свою специфику.

ARIS поддерживает четыре типа моделей, отражающих различные аспекты исследуемой системы:

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

2. функциональные модели, содержащие иерархию целей, стоящих перед аппаратом управления, с совокупностью деревьев функций, необходимых для достижения поставленных целей;

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

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

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

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

Разработка архитектуры будет проходить в 4 этапа:

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

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

3. уровень 3 (планируемая перспектива) - определение технических деталей перспективной архитектуры (данные, приложения и технологии);

4. уровень 4 – формирование плана реализации перспективной архитектуры.

Таблица 2.3. Этапы планирования архитектуры
№	Название этапа	Результаты	Трудозатраты
1	Инициация планирования	цели, видение, методологии, инструментарий, команда, презентации, рабочий план	-
2	Предварительное бизнес-моделирование	организационно-штатная структура, предварительная функциональная бизнес-модель	7%
3	Формирование снимка организации	полная функциональная бизнес-модель	23%
4	Описание текущих систем и технологий	каталог информационных ресурсов, системные схемы	15%
5	Формирование архитектуры данных	определения сущностей, ER-модель, матрица сущности-функции, отчет по архитектуре данных	15%
6	Формирование архитектуры приложений	определения приложений, матрицы приложений, анализ покрытия, отчет по архитектуре приложений	15%
7	Формирование технической архитектуры	распределение данных/приложений, отчет по технологической архитектуре	10%
8	Разработка плана реализации	последовательность, план перехода, цены и преимущества, факторы успеха и рекомендации	15%
9	Заключительное планирование	окончательный отчет, презентация	-
10	Переход к реализации	совершенствование политик, стандартов, процедур, детализация проектных планов	-

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

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

   1. обзор организации и определение ее контекста (системных входов/выходов);

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

   3. формирование перечня и определений целей и их достижимости;

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

2. Целью шага 2 является исследование организации, системных входов/выходов и вариантов на основании встреч с менеджментом. Результатами являются согласованное и утвержденное видение организации, а также политическая поддержка менеджмента. Основными задачами шага являются:

   1. изучение всех исходных материалов по бизнесу (заказчики, продукты, сотрудники, цели и т.д.);

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

   3. анализ организаций, успешно выстроивших свои архитектуры;

   4. формирование видения организации, демонстрирующего ИТ-среду, обеспечивающую достижение целей.

3. Целью шага 3 является адаптация методологии планирования и создание руководства по методологии. Основными задачами шага являются:

   1. формулирование принципов и требований к методологии;

   2. оценка существующих в организации методов и стандартов;

   3. изучение имеющихся на рынке подходов;

   4. принятие решения об исполнителе (внутренние ресурсы или внешний консультант);

   5. создание методологии, отвечающей нуждам данной организации;

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

4. Целью шага 4 является наведение порядка с компьютерными ресурсами и оценка инструментария создания ЕА. Основными задачами шага являются:

   1. определение требований к инструментарию;

   2. определение требований к аппаратуре;

   3. оценка альтернатив для репозитария проекта;

   4. выбор и приобретение подходящего программного инструментария;

   5. разработка регламентов и процедур, обеспечивающих надлежащее использование продуктов;

   6. разработка проектов отчетов, экранных форм и т.п.;

   7. оценка трудозатрат на "канцелярскую" поддержку большого объема документации по ЕА;

   8. доведение решений по инструментарию до всех подразделений – потенциальных пользователей ЕА

5. Цель данного шага – создание проектной команды. Основными задачами шага являются:

   1. определение квалификационных требований по каждой из фаз создания ЕА;

   2. оценка трудозатрат по каждой фазе создания ЕА;

   3. определение необходимого числа участников;

   4. спецификация ролей и областей ответственности каждого члена команды;

   5. подбор персонала;

   6. обучение персонала (методологии и инструментарий);

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

Начнем построение архитектуры с организационного уровня.