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

 

Лекция 3.

 

Тема лекции: «Моделирование элементов архитектуры предприятия».

1. Эволюция представлений об архитектуре предприятия.
2. Категории моделей архитектуры предприятия.
3. Построение архитектуры предприятия.

 

1. ЭВОЛЮЦИЯ ПРЕДСТАВЛЕНИЙ ОБ АРХИТЕКТУРЕ ПРЕДПРИЯТИЯ.

 

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

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

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

 

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

 

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

Следующей ступенью развития оказалось понятие корпоративной информационно--технологоческой архитектуры масштаба предприятия (EWITA - Enterprise-Wide Information Technology Architecture). Даже название уже указывает на то, что она сочетает в себе как технологические аспекты, так и аспекты, связанные с данными. Основное направление работ при этом состоит в совместном использо-вании общих данных, исключении дублирования бизнес-функций, координации управления пользователями, ресурсами, информационной безопасностью за счет улучшений в управлении портфелем прикладных систем. Архитектура данного этапа эволюции описывает то, как компоненты информационной системы связаны между собой; точно так же бизнес-архитектура описывает то, как элементы биз-неса связаны между собой.

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

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

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

 

Более того существуют уже проработанные готовые модели архитектуры предприятия, описывающие деятельность именно государственных агентств и ведомств (например, Архитектура федеральной организации (Federal Enterprise Architecture, FEA)).

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

 Сама концепция архитектуры предприятия явилась результатом поиска не-которого целостного подхода, который обеспечил бы «взгляд на организацию в целом», с учетом всех возможных измерений, хотя учет большего количества из-мерений предполагает и рост сложности представлений об архитектуре [(J.Schekkerman, 2004)].–

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

Рисунок  2. Развитие представлений об архитектуре предприятия.

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

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

 

Например, The Open Group, компания, которая сама разработала целую методологию по описанию архитектуры предприятия (TOGAF) предлагает толковать ее так: «Архитектура предприятия - это способ пони-мания различных элементов, которые в совокупности составляют предприятие-, и то, как эти элементы взаимосвязаны».

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

 

Таким образом, архитектуру предприятия можно рассматривать как про-цесс трансформации новых бизнес-стратегий в основанные на информацион-ных технологиях и реализуемые в масштабах всей организации решения, кото-рые подкреплены принятыми принципами управления (см., напр., [1]).

 

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

 

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

 

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

 

2. КАТЕГОРИИ МОДЕЛЕЙ АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ.

 

Формальное описание архитектуры предприятия впервые было сформули-ровано в стандарте ИСО 15704, который был предложен рабочей группой IFAC/IFIP (International Federation of Automatic Control/International Federation for Information Processing). Идея состояла в том, чтобы разработать максималь-но общую, так называемую эталонную (reference) модель архитектуры предприя-тия, которая охватывала бы дополнительно процесс развития предприятия во времени как проект, а также учитывала бы роль человеческого фактора. Архитек-туры отдельных подсистем, в том числе ИТ-системы предприятия, могут быть тог-да разработаны как специфические уточнения такой общей модели.

2.1.  Методология FEA.

 

В западных странах (США, Канаде, Великобритании и др.) для управления развитием и функционированием государственных организаций и предприятий с использованием информационных технологий признана и практически используется методология «архитектуры предприятия» (www.enterprise-architecture.info).

Кроме этого, в США используется правительственная методология и практика по управлению информатизацией органов государственной власти и государственных предприятий – Архитектура федеральной организации (Federal Enterprise Architecture, FEA)).

 

Методология FEA базируется на множестве взаимоувязанных референтных моделей, которые охватывают все структурные аспекты предприятия (учреждения), в том числе его информационной системы: структуру и функции деятельности, структуру программных и технических средств, структуру обрабатываемой информации. С описанием FEA на русском языке можно ознакомиться в работах В.И. Дрожжинова и А.А.  Штрика [см.: Дрожжинов В., Штрик А. Стандартизация архитектуры государственных ведомств США//PC Week/RE 2005. № 28, 31].

 

Е.З. Зиндер считает, что мощный толчок развитию архитектур сверхкрупных распределенных человеко-машинных систем дали программы создания «электронного правительства» (ЭП). Концепции, методы и модели архитектур ЭП в них планомерно разрабатывались в течение многих лет — вплоть до обобщенных «архитектур электронного правительства» [Зиндер Е.З. Архитектура предприятия в контексте бизнес-реижиниринга. Часть 2//Intelligent Enterprise. 2008. №7.

 

В результате процесс заимствования идей на определённое время поменял направление: многие методы и модели архитектур, созданные для ЭП, стали заимствоваться коммерческими предприятиями. Существенный вклад в развитие архитектурного подхода сделала разработка FEA — «Федеральной архитектуры предприятия», развиваемой в США и, получившая наибольшую известность.

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

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

 

Состав FEA предусматривает следующие категории компонентов:

− стимулы (деловые и технические) и стратегическое направление развития архитектуры (включая его видение, цели и объекты);

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

− архитектурные референсные модели;

− текущую и целевую архитектуры;

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

− архитектурные сегменты для специфических областей деятельности;

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

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

 

Е.З. Зиндер в своей публикации отмечает, что принципы FEA определены как важнейшие руководящие правила, и поскольку архитектура предприятия не обязательно базируется на моделях, этим (и подобным) принципам нужно уделять большое внимание. FEA включает и другие ценные методические документы, например, по управлению инвестициями, по оценке зрелости архитектуры. [Зиндер Е.З. Архитектура предприятия в контексте бизнес-реижиниринга. Часть 2//Intelligent Enterprise. 2008. №7.

 

Существенным достижением FEA считаются её референсные модели:

− модель результативности (эффективности);

− модель функций и сервисов деятельности;

− модель прикладных ИТ-сервисов/компонентов общего назначения;

− модель базовых технических ИТ-сервисов и стандартов;

− модель информации и данных.

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

 

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

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

 

Вместе с тем FEA вполне можно признать и «архитектурой типа 2» по ISO 15704.

 

2.2. Эталонная модель архитектуры GERAM.

 

Разработан-ная как приложение к данному стандарту (ИСО 15704), такая общая эталонная модель архи-тектуры получила название GERAM (Generalized Enterprise Reference Architecture and Methodology).

Фактически, GERAM представляет собой абстрактное описание архитектуры общего уровня, которая может быть использована для «привязки» и сравнения между собой различных практических моделей архитектур. Она определяет комплекс концепций, методов и моделей, необходимых для проектирования и сопровождения современного предприятия (любого типа) в течение всего времени его существования [(Галактионов, 2002)]. GERAM обеспечивает поддержку всех элементов среды моделирования архитектуры, базируясь при этом на:

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

- процессо-ориентированных концепциях для описания бизнес-процессов;

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

Рассмотрим GERAM более подробно (см.:  [Приложение А, ГОСТ Р ИСО 15704-2008]

 

(А.1.1).  Предыстория.

 

Одной из наиболее важных характеристик современного предприятия является быстро изменяющаяся среда и невозможность прогнозирования на долгосрочную перспективу. Для того, чтобы приспособиться к изменениям, предприятия должны сами развиваться и реагировать на такие изменения. Адаптация должна носить естественный динамический характер, а не являться периодической и принудительной. Это вызывает необходимость интеграции работы предприятия 1) и развитие дисциплин, организующих все знания, которые необходимы для идентификации изменений на предприятии и оперативного профессионального решения проблем, связанных с изменениями. Эта дисциплина называется «инжинирингом предприятия» 2).

 

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

 

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

 

Предыдущее исследование, проведенное консорциумом AMICE в области открытых систем архитектуры для компьютерного интегрированного производства (см. приложение D [ГОСТ Р 17504:2008]) лабораторией GRAI и консорциумом Purdue (как и аналогичные методологии, разработанные другими), позволило получить стандартные архитектуры, предназначенные для организации знаний по интеграции предприятия, которые можно использовать как руководство для программ инжиниринга предприятия. Целевая группа IFIP/IFAC проанализировала эти архитектуры и пришла к выводу, что даже если имеют место случаи частичного дублирования, ни одна из существующих стандартных архитектур не совпадают с другой; каждая из них уникальна по своему характеру. Признание необходимости определения обобщенной архитектуры является результатом работы целевой группы IFIP/IFAC.

 

Начиная с оценки существующих архитектур интеграции предприятия (CIMOSA, GRAI/GIM и PERA), целевая группа IFIP/IFAC по архитектурам интеграции предприятия разработала общее определение обобщенной архитектуры. Предложенная основа была озаглавлена GERAM (обобщенная стандартная архитектура предприятия и методология). Действие GERAM распространяется на методы, модели и инструменты, которые необходимы для построения и поддержания интегрированного предприятия независимо от того, является ли оно частью предприятия, одиночным предприятием или комплексом предприятий (виртуальным или расширенным предприятием).

 

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

 

(А.1.2).  Область деятельности.

 

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

 

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

 

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

 

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

 

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

 

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

 

(А.2).  Среда инжиниринга предприятия и интеграция предприятия.

 

(А.2.1).  Общая информация.

 

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

 

Комплекс составных частей, идентифицированных GERAM, кратко описан в настоящем разделе ниже, а каждая составная его часть более подробно определена в А.3.

 

Среда GERAM идентифицирует наиболее важную составную часть GERA (обобщенная стандартная архитектура предприятия), основные понятия, которыми необходимо руководствоваться при инжиниринге и интеграции предприятия (например, сущности предприятия, жизненные циклы и истории жизни сущностей предприятия). GERAM проводит различие между методологиями инжиниринга предприятия (EEMs) и языками моделирования (EMLs), которые используются методологиями для описания и моделями, структурами, содержанием и поведением рассматриваемых сущностей предприятия. Эти языки моделирования обеспечивают моделирование человеческой составляющей в деятельности предприятия, а также доли бизнес-процессов и их вспомогательных технологий в работе предприятия. В результате процесса моделирования разрабатываются модели предприятия (EMs), которые представляют все или часть операций предприятия, включая его производственные или сервисные задачи, организацию и менеджмент, а также систему управления и информационную систему. Такие модели могут применяться в качестве руководства при внедрении операционной системы предприятия (EOSs), а также для улучшения возможностей предприятия по оценке операционных или организационных альтернатив (например, посредством моделирования), что в результате приводит к улучшению текущих и будущих производственных показателей.

 

Методология и языки, применяемые для моделирования предприятия, подкрепляются инструментами инжиниринга предприятия (EETs). Семантика языков моделирования может определяться онтологиями, мета-моделями и словарями, которые в комбинации именуются «общими концепциями предприятия» (GEMCs).

 

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

 

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

 

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

 

(А.2.2).  Определение компонентов основы GERAM.

 

(А.2.2.1).  GERA - общая стандартная архитектура предприятия.

 

GERA определяет общие смежные понятия предприятия, рекомендованные для применения при инжиниринга предприятия и выполнении интеграционных проектов. Такие понятия можно классифицировать как:

 

a) понятия, ориентированные на человека:

 

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

 

2) для поддержки людских ресурсов в процессе планирования, строительства и изменений на предприятии;

 

b) понятия, ориентированные на описание бизнес-процесса предприятия;

 

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

 

(A.2.2.2).  EEMs - методологии инжиниринга предприятия.

 

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

 

(А.2.2.3).  EMLs - языки моделирования предприятия.

 

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

(A.2.2.4).  GEMCS - общие понятия моделирования предприятия.

 

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

 

- естественное языковое объяснение значения понятий моделирования (словари);

 

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

 

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

 

(А.2.2.5).  PEMs - частные модели предприятия.

 

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

 

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

 

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

 

В литературе частные модели предприятия обозначают терминами «стандартные модели» и «стандартные архитектуры типа 1» (такие архитектуры как GERA относятся к «стандартным архитектурам типа 2»). Эти термины имеют одно и то же значение.

 

(А.2.2.6).  EETs- инструменты инжиниринга предприятия.

 

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

(А.2.2.7).  EMs - модели (конкретного) предприятия.

 

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

 

(А.2.2.8).  EMOs - модули предприятия.

 

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

 

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

 

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

 

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

 

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

 

(A.2.2.9).  EOSs - операционные системы (конкретного) предприятия.

 

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

(А.3).  Описание компонентов среды GERAM.

 

(А.3.1).  GERA - обобщенная стандартная архитектура предприятия.

 

(А.3.1.1). Общая информация.

 

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

 

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

 

1) роли людских ресурсов,

 

2) способы организации ролей, выполняемых людскими ресурсами, для взаимодействия с другими людскими ресурсами и элементами технологии при выполнении работ на предприятии и

 

3) способности и качества людских ресурсов как ресурсных элементов предприятия.

 

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

 

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

 

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

 

Примеры стандартных архитектур предприятия приведены в ARIS (архитектура информационных систем), CIMOSA (архитектура открытых систем), GRAI/GIM (диаграммы с результатами и взаимосвязанными видами деятельности)/Интегрированная методология GRAI, IEM (интегрированное моделирование предприятия), PERA (стандартная архитектура предприятия Purdue). Стандарт ENV 40003 устанавливает общую среду моделирования предприятия. ИСО 14258 устанавливает правила и понятия для моделей предприятия.

 

(А.3.1.2).  Понятия, ориентированные на человека.

 

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

 

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

 

главное исполнительное лицо;

 

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

 

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

 

заместители менеджера;

 

бухгалтеры;

 

кассиры;

 

проектировщики продукции, процесса и информационной системы;

 

инженеры на производстве, техники-электрики и механики;

 

обслуживающий персонал;

 

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

 

инспекторы;

 

мастера;

 

операторы машин;

 

работники склада;

 

аналитики процесса работы;

 

секретари;

 

водители;

 

уборщики;

 

консультанты по вопросам менеджмента и системам;

 

интеграторы систем;

 

создатели систем;

 

поставщики ИТ и продавцы.

 

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

 

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

 

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

 

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

 

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

 

- возможности и качества сотрудников, рассматриваемые как ресурсные элементы.

 

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

 

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

 

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

 

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

 

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

 

- перестраивать свои деловые (и производственные) процессы;

 

- улучшать менеджмент ресурсов и их использование при производстве новой продукции и услуг;

 

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

 

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

 

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

 

Модели, устанавливающие обязанности сотрудников, обеспечивают определение их обязанностей, ответственности и полномочий в процессе работы и организации предприятия. Такие модели обеспечивают сбор необходимой информации и ее осознанное применение при планировании операционной системы. Действие GERA распространяется на человеческий фактор в своем понятии представления (см. А.3.1.5.3). Это понятие обеспечивает представления (виды) моделей с ориентацией на процесс и внедрение с ориентацией на технологию, подтверждая значимость человеческого фактора и сбора необходимой информации. Фактически эти представления подтверждают роль человеческого фактора как рабочего ресурса. Под этим углом и будут описываться профессиональные навыки и умения сотрудников и их возможности. Человеческий аспект в интеграции предприятия должен внимательно рассматриваться при изменении методологии как с точки зрения изменения обязанностей сотрудника, так и его роли как потенциального и фактического ресурса (см. А.3.2).

 

(А.3.1.3). Понятия, ориентированные на процесс.

 

(А.3.1.3.1). Общая информация.

 

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

 

- жизненный цикл производственной сущности и этапы его жизненного цикла;

 

- история жизни;

 

- типы производственной сущности;

 

- моделирование предприятия с представлением интегрированной модели и модельными представлениями.

 

(А.3.1.4). Концепции, ориентированные на технологию.

 

(А.3.1.4.1). Общая информация.

 

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

 

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

 

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

 

(А.3.1.5).  Среда моделирования GERA.

 

(А.3.1.5.1).  Общая информация.

 

GERA обеспечивает проведение анализа и среду моделирования на базе концепции жизненного цикла и идентифицирует три размерности для определения области и концепции моделирования предприятия:

 

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

 

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

 

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

 

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

 

Одним из главных преимуществ GERAM является его мощность в решении задач, связанных с изменениями (реинжиниринг, CPI/TQM). Одним из ее главных недостатков является концептуальный характер, она снабжает методологическими руководствами, но не обеспечивает ни языком моделирования, ни соответствующими инструментальными средствами.

 

2.3. Изменение организационных принципов предприятия.

 

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

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

Если возвращаться к эволюции понятия «архитектура предприятия» то можно отметить, что она, прежде всего, связана с теми изменениями, которые происходили и происходят во взглядах на принципы организации деятельности предприятия как такового. Говоря точнее, прежде всего, имеется в виду использование следующих организационных механизмов, которые условно показаны на рисунке 3. (см., напр., [1]):

 

-      функциональная специализация;

-      реинжиниринг бизнес-процессов;

-      корпоративная архитектура.

 

 

Рисунок 3. Изменение организационных принципов предприятия.

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

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

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

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

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

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

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

 

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

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

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

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

 

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

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

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

 

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

 

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

Рисунок 4. Переход от бизнес-архитектуры к ИТ-архитектуре (приложения, информация, инфраструктура)

Для построения архитектуры данных необходимо выделить основные сущности и агрегировать на них все «кванты» информации, собранные из описания бизнес-процессов. В результате использования стандартной методологии описания данных – модель «сущность-связь» (Entity-Relationship Model – ERM) – можно четко структурировать всю информацию, тем самым определив структуру таблиц базы данных, что однозначным образом формализует структуру данных в компании в привязке к существующим бизнес-процессам и будет понятно для ИТ-специалистов.

 

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

 

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

 

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

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

 

2.4. Категории моделей архитектуры предприятия.

 

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

Бизнес-ракурс.

 

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

 

В типовом случае этот ракурс включает:

 

− цели и задачи верхнего уровня;

 

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

 

− выполняемые бизнес-функции или организационные процедуры;

 

− основные организационные структуры организации (предприятия);

 

− взаимосвязи между всеми перечисленными элементами.

 

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

 

Ракурс приложений.

 

Ракурс приложений определяет  набор  приложений предприятия. Обычно этот ракурс включает:

 

− описание приложений или автоматизированных поддерживающих бизнес-процессы;

 

- описание взаимодействия и взаимозависимостей (интерфейсов) прикладных систем предприятия (организации);

 

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

 

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

 

 

Ракурс информации.

 

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

 

− стандартные модели данных;

 

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

 

− описание шаблонов создания и использования информации в организации.

 

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

 

Технологический ракурс. Технологический ракурс рассматривает аппаратное и программное обеспечение, используемое в организации.

 

Ракурс включает:

 

− аппаратные средства серверов и рабочих станций;

− операционные системы;

- средства сетевого доступа;

− принтеры и МФУ;

- другие устройства.

 

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

 

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

 

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

 

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

 

Не надо питать иллюзий насчет того, что работа архитектора заканчивает-ся строительством видения великолепной архитектуры предприятия. Архитек-тура информационных технологий - это только на 10% видение, а на 90%- кропотливая работа по реализации.  

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

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

Первоочередными задачами такого проекта являются:

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

- понимание стратегии развития бизнеса организации;

- формирование общих для бизнеса и ИТ требований к целевой архитектуре;

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

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

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

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

1)   Определение и обоснование цели - ответы на вопросы:  Почему? и Что?

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

3)   Определение существующего состояния архитектуры ( «as-is») для каждой выбранной области (домена) - отправная точка ответа на вопрос где?

4)   Определение целевой архитектуры - конечная точка ответа на вопрос где?

5)   Анализ расхождений между текущим и желаемым состоянием.

6)   Разработка плана перехода - ответы на вопросы:  Когда? и Как?

7)   Подтверждение (проверка) достижимости: можно ли на самом деле до-стичь конечного состояния из данного начального состояния с учетом су-ществующих ограничений?

8)   Выполнение намеченного плана.

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

 

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

 

- определение «устава» (основных правил) и границ проекта;

 

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

 

- получение поддержки высшего руководства;

- определение состава рабочей группы (организационная структура и уча-стники);

 

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

 

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

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

 

Список этих высокоуровневых документов может включать:

 

- бизнес-факторы, влияющие на деятельность предприятия;

- внутренние и внешние технологические факторы;

- формулировку общего видения Архитектуры предприятия;

- высокоуровневые принципы.

 

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

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

Рисунок 5. Общая схема построения архитектуры предприятия.

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

 

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

 

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

 

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

 

СПИСОК РЕКОМЕНДУЕМОЙ ЛИТЕРАТУРЫ.

 

 

[1] Данилин А., Слюсаренко А. Архитектура и стратегия. «Инь» и «Янь» информационных технологий предприятия.  –   М. Интернет Ун-т Информ. Технологий, 2005. – 504 с.

 

[2] Калянов Г. Н. Консалтинг: от бизнес-стратегии к корпоративной информационно-управляющей системе. Учебник для вузов. 2-е изд., доп. – Горячая линия-Телеком М., 2014. –  210 с. 

[3] Кудрявцев Д.В., Арзуманян М.Ю.,  Григорьев Л.Ю. Технологии бизнес-инжиниринга.  Учебное  пособие / под редакцией Д.В. Кудрявцева. — СПб.:  Изд-во Политехн. ун-та, 2014.

 

[4] Трутнев Д.Р.  Архитектуры информационных систем. Основы проектирования: Учебное пособие. – СПб.: НИУ ИТМО (Санкт-Петербургский национальный исследовательский университет информационных технологий, механики и оптики), 2012. – 66 с.

 

[5] Репин В.В., Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов. – М.: РИА «Стандарты и качество», 2004 – 408 с. (Серия «Практический менеджмент»).