ГОСТ Р ИСО 15704-2022 Моделирование и архитектура предприятия. Требования к стандартным архитектурам и методологиям предприятия

        ГОСТ Р ИСО 15704-2022

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

МОДЕЛИРОВАНИЕ И АРХИТЕКТУРА ПРЕДПРИЯТИЯ

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

Enterprise modelling and architecture. Requirements for enterprise-referencing architectures and methodologies

ОКС 25.040.01

Дата введения 2023-01-01

Предисловие

1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью "НИИ экономики связи и информатики "Интерэкомс" (ООО "НИИ "Интерэкомс") на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 100 "Стратегический и инновационный менеджмент"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 3 октября 2022 г. N 1045-ст

4 Настоящий стандарт идентичен международному стандарту ИСО 15704:2019* "Моделирование и архитектура предприятия. Требования к стандартным архитектурам и методологиям предприятия" (ISO 15704:2019 "Enterprise modelling and architecture - Requirements for enterprise-referencing architectures and methodologies", IDT)

5 ВЗАМЕН ГОСТ Р ИСО 15704-2008

6 Некоторые положения международного стандарта, указанного в пункте 4, могут являться объектом патентных прав. Международная организация по стандартизации (ИСО) и Международная электротехническая комиссия (МЭК) не несут ответственности за идентификацию подобных патентных прав

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

Введение

0.1 Логическое обоснование архитектур и моделей предприятий

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

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

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

Стандартная справочная база нуждается в дополнительных возможностях, чтобы:

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

- описать подходящие решения, чтобы идентифицировать проблемы в рамках предприятия;

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

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

С точки зрения инжиниринга предприятия вводится следующее отличие:

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

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

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

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

0.2 Обоснование применения настоящего стандарта

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

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

0.3 Преимущества применения настоящего стандарта

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

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

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

Пользователями настоящего стандарта являются:

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

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

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

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

1 Область применения

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

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

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

2 Нормативные ссылки

В настоящем стандарте нормативные ссылки отсутствуют.

3 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями.

Организации ИСО и МЭК поддерживают терминологические базы данных для их использования в стандартизации по следующим адресам:

- платформа просмотра онлайн ИСО доступна по адресу https://www.iso.org/obp;

- IEC Electropedia: доступно по адресу http://www.electropedia.org/.

3.1 архитектура (architecture): Концептуализация форм, функций и соответствия целевому назначению предприятия (3.4) и его среды (3.9), реализованная в элементах и отношениях, взаимосвязях предприятия со средой и принципах, определяющих проектирование и развитие предприятия.

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

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

[ISO/IEC/IEEE 42010:2011, 3.2, с изменениями - содержание первоначального определения адаптировано к контексту настоящего стандарта, добавлены примечания к словарной статье]

3.2 аспект (aspect): Отличительная особенность, выраженная в некоторой проекции контента интегрирующей модели предприятия (3.6).

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

3.3 бизнес-процесс (business process): Частично упорядоченный, часто вложенный, набор видов деятельности предприятия (3.4), которые следует исполнять для получения желаемого результата, стремясь достичь заданной цели предприятия или части предприятия.

3.4 предприятие (enterprise): Предпринимательская деятельность или меры по организации производства, которые точно формулируют и четко определяют миссию (3.13), цели и задачи по предложению товаров или услуг либо достижение желаемого проектируемого конечного результата или бизнес-результата.

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

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

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

3.5 инжиниринг предприятия (enterprise engineering): Дисциплина, предполагающая деятельность по созданию, модификации или реорганизации предприятия (3.4).

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

3.6 модель предприятия (enterprise model): Представление предприятия (3.4), а также сущностей в пределах предприятия, их отношений, декомпозиции на компоненты и детализация в той степени, которая необходима для передачи информации о деятельности предприятия и аспектах ее функционирования.

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

[ИСО 19439:2006, 3.23, с изменениями - слова "выделение главных признаков домена предприятия, представляющего сущности предприятия" заменены словами "представление предприятия, а также сущностей в пределах предприятия", слова "что оно намерено" - словами "о деятельности предприятия" и добавлено примечание 1 к словарной статье]

3.7 относящееся к предприятию (enterprise-referencing): Применимо к сущности (3.8), которая включена, включает или является частью предприятия (3.4).

Примечание 1 - Обобщенная архитектура (3.1) предприятия, архитектура конкретного предприятия и архитектура, которая включает предприятие как один из элементов, являются относящимися к предприятию архитектурами.

3.8 сущность (entity): Любая конкретная или абстрактная вещь в рамках рассматриваемого домена.

[ИСО 19439:2006, 3.29]

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

Примечание 1 - В случае вложенного предприятия его среда может находиться внутри более крупного предприятия.

[ISO/IEC/IEEE 42010:2011, 3.8, с изменениями - содержание оригинального определения адаптировано к контексту настоящего стандарта, включая содержание определения из ИСО 19439:2006, 3.30, и добавлено примечание к словарной статье]

3.10 основа, среда, рамочная структура (framework): Структура, выраженная в диаграммах, тексте и формальных правилах, которая связывает элементы архитектуры (3.1) предприятия (3.4) друг с другом.

Примечание 1 - Рамочная структура направлена на создание одного или нескольких описаний архитектуры предприятия.

[ИСО 19439:2006, 3.31, с изменениями - слова "составные части концептуальной сущности" заменены словами "элементы архитектуры предприятия" и добавлено примечание 1 к словарной статье]

3.11 общность (genericity): Степень, в которой понятие объединяет сущности в категорию или группу.

3.12 жизненный цикл (life cycle): Ряд различимых фаз (стадий) и этапов в рамках фаз, которые проходит сущность (3.8) от ее создания до окончания существования.

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

[ИСО 19439:2006, 3.42, с изменениями - добавлено примечание 1 к словарной статье]

3.13 история жизни (life history): Фактическая, записанная, с управляемой конфигурацией последовательность фаз и этапов в пределах фаз, которые сущность (3.8) проходит в течение своей жизни.

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

3.15 модель (model): Представление определенных сущностей и их характеристик (a) с использованием формального подхода или (b) с использованием устоявшихся парадигмы, подхода или техники специально разработанного моделирования.

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

Примечание 2 - Модель может быть частью более крупной модели.

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

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

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

3.17 размерность моделирования (modelling dimension): Концептуальный набор точек зрения (3.24) сущностей (3.8) предприятия (3.4), связанных по типу архитектурных особенностей и проявляющихся в четко выраженных агрегирующих координатах во временном континууме.

Примечание 1 - Обычными размерностями моделирования являются жизненный цикл, точка зрения и общность (3.11).

3.18 организация (organization): Распределение обязанностей и полномочий на предприятии (3.4).

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

3.19 перспектива (perspective): Ориентация заинтересованной стороны (3.22) или пользователя модели (3.15) относительно идентифицированного домена.

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

3.20 справочная база (reference base): Источник информации, содержащий описания концепций, требования и рекомендации по обобщенной архитектуре (3.1) предприятия (3.4).

3.21 ресурс (resource): Сущность (3.8), обеспечивающая некоторые или все способности, необходимые для обеспечения деятельности предприятия (3.4).

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

Примечание 2 - В настоящем стандарте термин "ресурс" применяется к нечеловеческим сущностям, вовлеченным в работу сущностей предприятия. Вовлечение людей распределено по ролям, которым они соответствуют в работе сущности предприятия.

[ИСО 19439:2006, 3.60, с изменениями - слово "предприятие" удалено в начале определения, удалено также последнее предложение примечания 1 к словарной статье и добавлено примечание 2 к словарной статье]

3.22 заинтересованная сторона (stakeholder): Индивидуум, команда, организация или их группы, заинтересованность которых связана с перспективой (3.19) предприятия (3.4) или его архитектуры (3.1) либо с сущностью (3.8) архитектуры предприятия.

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

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

[ISO/IEC/IEEE 42010:2011, 3.10, с изменениями - содержание оригинального определения адаптировано к контексту настоящего стандарта; добавлены примечания к словарной статье]

3.23 представление (view): Результат работы, выражающий селективное восприятие или отображение модели (3.15) предприятия и выделяющий некоторую особенность или характеристику, игнорируя другие.

[ИСО 19439:2006, 3.25, с изменениями - содержание оригинального определения адаптировано к контексту настоящего стандарта]

3.24 точка зрения (viewpoint): Идентификация одного или более видов модели (3.15), используемой для работы с совокупностью проблем заинтересованной стороны (3.22).

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

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

4 Сокращения

5 Требования к относящимся к предприятию архитектурам и моделям

5.1 Общие требования

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

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

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

b) определить имеющиеся и возможные в будущем цели предприятия;

c) описать важные задачи, которые предстоит выполнить;

d) идентифицировать необходимые виды и количество данных;

e) идентифицировать соответствующие элементы предприятия и их взаимосвязи с целями предприятия;

f) установить взаимосвязи среди людей, процессов и оборудования для рассматриваемого взаимодействия;

g) установить основные функции и обязанности руководства;

h) определить соответствующие экономические, культурные и технологические факторы;

i) описать требуемую степень поддержки автоматизации;

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

k) описать структуры принятия решений и средства для определения несоответствий;

l) поддерживать формы выражения, читаемые человеком и обрабатываемые машиной;

m) измерить достаточность и эффективность методологии архитектуризации предприятия по степени достижения предприятием своих целей.

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

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

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

5.2.1 Типы предприятия

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

5.2.2 Характеризация архитектуры предприятия

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

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

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

Примечание 1 - В настоящем стандарте применение термина "архитектура" обычно означает ее конкретную форму как описание архитектуры.

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

5.2.3 Инжиниринг предприятия и методология архитектуризации

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

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

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

5.2.4 Проектирование предприятия

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

5.2.5 Функционирование предприятия

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

5.3 Базовые понятия для относящейся к предприятию архитектуры

5.3.1 Размах концептуальной ориентации

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

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

5.3.2 Ориентация на человека

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

5.3.3 Ориентация на процесс

Архитектуры и модели предприятия должны идентифицировать и обеспечивать средства представления функционирования предприятия. Такие представления должны охватывать характеристики и виды деятельности, включая функциональность, поток данных между функциями и последовательность контроля. Эти представления должны признавать понятия "жизненный цикл" (5.3.9.1) и "история жизни" (5.3.9.2) и поддерживать операции, ориентированные на процесс.

5.3.4 Ориентация на совместимость

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

5.3.5 Ориентация на решение

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

5.3.6 Ориентация на реализацию

5.3.6.1 Ориентация на выполнение миссии

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

5.3.6.2 Ориентация на контроль выполнения миссии

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

5.3.6.3 Ориентация на экономику

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

5.3.7 Ориентация на технологию

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

5.3.8 Ориентация на окружение

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

5.3.9 Ориентация на время жизни

5.3.9.1 Ориентация на жизненный цикл

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

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

Примечание 1 - Если фазу разбивают, получается, что различные подсистемы могут иметь различные зависимости и, следовательно, регламентируются с большей гибкостью. Это особенно очевидно для программного обеспечения, где разбиение, обеспечивающее модульность, является устоявшейся практикой.

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

Примечание 3 - Другие стандарты, особенно гармонизированные с ISO/IEC/IEEE 15288, используют термин "стадия" вместо "фаза" для одного и того же понятия, связанного с развитием системы. Чтобы различать архитектуру системы и архитектуру предприятия, в настоящем стандарте термин "фаза" применяется для характеристики сегментации деятельности на протяжении срока жизни предприятия.

5.3.9.2 Ориентация на историю жизни

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

5.3.9.3 Сопряженная роль жизненного цикла и истории жизни

Используя концепции, ориентированные на срок жизни, описанные в 5.3.9.1 и 5.3.9.2, архитектор идентифицирует виды деятельности предприятий в пределах фазы жизненного цикла, в то время как история жизни позволяет архитектору или пользователю архитектуры идентифицировать соответствующий временной период, в который встречаются экземпляры этих видов деятельности. Такая двойная ориентация обеспечивает итеративный характер зависимостей деятельности жизненного цикла, при этом поддерживается временная последовательность истории жизни. Фазовые итерации видов деятельности идентифицируют различные процессы изменений, необходимые для рабочих процессов и/или разработки процессов или обслуживания клиентов. Наглядный пример приведен в приложении В на рисунке B.3.

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

Примечание 2 - Другие стандарты, в частности гармонизированные с ISO/IEC/IEEE 15288, используют термин "стадия жизненного цикла" вместо "стадии истории жизни".

5.3.10 Ориентация на заинтересованные стороны

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

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

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

5.3.11 Ориентация на позицию

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

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

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

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

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

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

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

5.3.12 Ориентация на модель

5.3.12.1 Представление архитектуры предприятия

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

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

Соблюдая требования, установленные в ISO/IEC/IEEE 42010, модели архитектуры предприятия должны относиться к одной или нескольким точкам зрения и связанным с ними архитектурным проблемам заинтересованных сторон.

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

5.3.12.2 Инжиниринг на основе модели

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

Примечание - См. [70] в отношении понимания размерностей.

5.3.12.3 Общность

Архитектуры предприятия на основе модели должны обеспечить возможности представления общих элементов предприятий (6.4.1), частичных моделей предприятий (6.4.2) и частных моделей предприятий (6.4.3).

5.3.12.4 Интеграция моделей

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

5.3.13 Ориентация на представление модели

5.3.13.1 Модели и отображения

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

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

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

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

5.3.13.2 Первичный аспект для точек зрения

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

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

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

В настоящем стандарте не рассматривают следующее:

- требования к отражению в модели содержимого представлений;

- какое содержимое должны включать (не включать) представления;

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

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

5.3.14 Ориентация на совместимость предприятия

5.3.14.1 Поддержка интероперабельности модели

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

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

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

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

5.3.14.2 Поддержка интероперабельности процессов

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

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

5.3.15 Ориентация на верификацию и валидацию

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

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

6 Компоненты архитектуры предприятия

6.1 Модели предприятия

6.1.1 Цель моделей предприятия

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

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

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

b) имитации операции предприятия для верификации модели и операции, которую модель представляет;

c) руководства и работы предприятия для достижения поставленных целей;

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

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

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

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

6.1.2 Типы моделей предприятия

6.1.2.1 Формы моделей предприятия

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

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

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

6.1.2.2 Модели предприятия на основе модели

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

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

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

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

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

Martin R. and E.Robertson, "Meta" Matters [46]. Воспроизведено с разрешения авторов.

Рисунок 1 - Абстракции метаотношений

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

6.1.2.3 Представления моделей

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

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

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

b) степень абстракции элементов представления.

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

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

6.2 Языки моделирования

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

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

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

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

6.2.2 Выразительные возможности

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

6.2.3 Семантика и синтаксис модели предприятия

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

6.2.4 Наименования, маркировка и терминология

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

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

- ссылку на другие подходящие словари.

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

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

Таблица 1 - Установление соответствия между фазами жизненного цикла и функционированием системы

Примечание - Особенно полезный набор наименований фаз жизненного цикла: идентификация домена, определение концепции, определение требований, проектное задание, описание исполнения, доменная операция и определение вывода из эксплуатации. См. также приложение B и ИСО 19439.

6.2.5 Элементы совместимости

Для каждого элемента модели, выраженного с помощью языка моделирования, синтаксис и семантика должны идентифицировать:

- форму(ы) представления элемента;

- отношения между данным элементом и другими элементами модели;

- возможности элемента;

- динамику рассматриваемого взаимодействия.

6.3 Модели как представления

6.3.1 Представление характеристик предприятия

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

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

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

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

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

6.3.2 Концепции внутренней структуры

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

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

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

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

6.3.3 Совместимость подходов структурирования

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

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

6.3.4 Концепции поведенческих аспектов предприятия

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

Примечание 1 - Если переменные ограничены до входных и выходных параметров, система рассматривается как "черный ящик".

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

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

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

6.3.5 Краткосрочное и долгосрочное изменение поведения

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

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

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

6.3.6 Представление поведения

6.3.6.1 Моделирование поведения

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

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

6.3.6.2 Представление времени

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

6.3.6.3 Статическое представление

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

6.3.6.4 Динамическое представление

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

6.3.6.5 Последовательность

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

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

6.3.7 Концепции иерархии

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

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

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

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

6.3.8 Рекурсия при декомпозиции

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

Пример 1 - Как часть своей операционной деятельности фирма, занимающаяся проектно-конструкторскими работами, планировкой, строительством (AEC), разработала проект новой фабрики для своего клиента. Предприятие компании AEC (E1) находится в рабочей фазе и будет в этой фазе в течение нескольких лет. Проект (E2), который состоит из нескольких корпоративных образований (объектов) (E1, E3, E4), имеет модель предприятия более крупную по области применения, чем сама компания AEC. Проект является предприятием (E5), и его модель развивается с фазы разработки концепции (запрос на предложение и предварительный проект) до рабочей фазы (после заключения договора). Новое предприятие (E6) и его модель находятся в фазе планирование/создание, и только после этого начнется фаза использование/функционирование.

Заинтересованные стороны можно предварительно разбить на три группы по типу ролей: те, основные интересы которых лежат в области определения возможностей для сущности предприятия (S); те, основные интересы которых лежат в области создания возможностей для сущности предприятия по обеспечению этих возможностей (C), и те, основные интересы которых лежат в области использования возможностей по предоставлению продукции и услуг (U). Конкретная деятельность сущности предприятия S, C и U касается интересов в каждой из описанных ролей. Каждый вид этой деятельности можно далее декомпозировать на другой набор определенных подобных категорий S, C, и U, с соответствующими подвидами деятельности (см. рисунок 2).

Рисунок 2 - Декомпозиция деятельности по проектированию продукта для представления рекурсивной структуры деятельности

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

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

Пример 2 - На объекте производственного предприятия деятельность "Производить" можно, в свою очередь, подразделить на виды деятельности более низкого уровня S, C и U. Деятельность S продвигается за счет потребностей пользователя и включает все виды деятельности, конечным результатом которых будет запрос: что производить? Деятельность C продвигается за счет технологических требований и включает виды деятельности, конечным результатом которых будет вопрос: как производить продукцию/систему с точки зрения имеющихся потребностей? Деятельность U продвигается за счет задания и включает виды деятельности, конечным результатом которых будет отгрузка продукции. Каждый вид деятельности на каждом уровне декомпозиции может обеспечить обратный поток информации на более высокий уровень.

6.3.9 Итерация

На примере рисунка 2 виды деятельности S, C и U являются итеративными, так как выполняются повторно при каждой декомпозиции и по всем декомпозициям. Следовательно, виды деятельности, показанные на рисунке как упорядоченные, на самом деле необязательно следуют в указанной последовательности. Архитектор может вернуть предыдущие виды деятельности, чтобы повторить их при актуализированных входных потоках, если необходимо удовлетворить потребности заинтересованных сторон, т.е. поток обратной информации по производительности, поддержке и способности к сопровождению может возникнуть при каждой декомпозиции, как показано на рисунке 2.

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

6.3.10 Наличие и формат информации о модели

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

6.3.11 Управление составляющими частями

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

6.4 Влияние общности

6.4.1 Общие элементы предприятий

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

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

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

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

6.4.2 Частичные модели предприятия

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

6.4.3 Частные модели предприятий

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

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

6.5 Перспективы и точки зрения предприятия

6.5.1 Перспективы особой важности

6.5.1.1 Идентификация перспектив

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

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

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

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

Примечание - Фраза "архитектурный стиль" подразумевает различение между представительной целью моделирования и целью или миссией моделируемой сущности [37].

6.5.1.2 Типичные точки зрения

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

6.5.1.3 Функциональная точка зрения

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

6.5.1.4 Информационная точка зрения

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

6.5.1.5 Ресурсная точка зрения

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

6.5.1.6 Организационная точка зрения

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

Примечание - См. 6.5.1.8 по альтернативной точке зрения или точке зрения, связанной с ресурсами.

6.5.1.7 Экономическая точка зрения

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

6.5.1.8 Точка зрения, связанная с принятием решений

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

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

Аспекты точки зрения, связанной с принятием решений, являются структурой принятия решений на предприятии, которая обеспечивает идентификацию тем для принятия решений, их категорий, критериев и зависимостей (см. CEN/TS 14818).

6.5.1.9 Точка зрения, связанная с рисками

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

6.5.1.10 Точка зрения, связанная с архитектуризацией

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

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

6.5.2 Дополнительные перспективы, представляющие интерес

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

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

6.6 Концептуальная структура моделирования предприятия

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

Пример - Абстрактное пространство, определенное размерами жизненного цикла, общностью и точками зрения моделирования, образует концептуальную структуру, описанную в ИСО 19439.

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

Поскольку концептуальная структура моделирования является метамоделью по отношению к моделям, которые она включает, эту структуру можно применять рекурсивно к контенту моделей, чтобы обеспечить дальнейшую обработку или декомпозицию компонентов модели [43].

6.7 Инструментарий

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

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

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

6.8 Модули

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

6.9 Операционные системы предприятия

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

6.10 Представление

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

Приложение A

(справочное)

Ключевые принципы интеграции и взаимодействия предприятия

A.1 Общие положения

Некоторые концепции, описывающие характер архитектур и моделей предприятия, возникли из исследований Целевой группы по архитектурам для интеграции предприятий Международной федерации автоматического управления/Международной федерации по обработке информации [International Federation of Automatic Control/International Federation for Information Processing (IFAC/IFIP)], которые могут значительно упростить, интегрировать и расширить работу, связанную с инжинирингом предприятия. Эта работа приводит к разработке Обобщенной стандартной архитектуре предприятия и методологии [Generalized Enterprise Reference Architecture and Methodology (GERAM)], которая может поддержать тех, кто планирует, проектирует и реализует сложные проекты по интеграции предприятия (см. приложение B для актуализированной версии).

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

A.2 Применимость для любого предприятия

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

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

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

A.3 Идентификация предприятия и определение его миссии

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

A.4 Разделение функции выполнения миссии и функции управления миссией

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

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

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

A.5 Идентификация структур процесса

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

A.6 Идентификация содержания процесса

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

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

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

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

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

A.7 Признание жизненного цикла

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

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

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

A.8 Интеграция предприятия

A.8.1 Поэтапный подход к интеграции предприятия

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

A.8.2 Подходы к интеграции

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

A.8.3 Степень интеграции

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

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

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

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

A.8.4 Оценка и измерение результатов деятельности по интеграции

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

A.9 Модульность

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

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

A.10 Проблемы заинтересованных сторон

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

Приложение B

(справочное)

Обобщенная архитектура предприятия и методология (GERAM)

B.1 Введение

B.1.1 Предыстория

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

Предыдущее исследование, проведенное консорциумом AMICE по CIMOSA [36], лабораторией GRAI по GRAI и GIM [34] и консорциумом Purdue по PERA [71] (как и аналогичные методологии, разработанные другими участниками), позволило получить архитектуры, предназначенные для организации существующих знаний по интеграции предприятия, которые можно использовать как руководство для программ интеграции предприятия. Целевая группа IFIP/IFAC по архитектурам интеграции предприятий проанализировала эти архитектуры и пришла к выводу, что даже если и имеют место случаи некоторого дублирования, ни одна из существующих стандартных архитектур не относится к другим и уникальна по своему характеру. Признание необходимости определения обобщенной архитектуры является результатом работы целевой группы.

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

Независимо от этого начинания, под влиянием сектора инжиниринга (преимущественно производственного и управляющего) другие архитектуры [или основы архитектуры предприятия (EA)] были разработаны с первоначальным упором на разработку ИТ-системы. Некоторые из них были расширены по области применения до системного инжиниринга для бизнес-сектора и оборонной промышленности, например Zachman [72], Command, Control, Communications, Computer Intelligence, Surveillance и Reconnaissance/Department of Defense Architecture Framework (Фреймворк архитектуры Министерства обороны) (C4ISR/DoDAF) [33], Federal Enterprise Architecture Framework (Фреймворк федеральной архитектуры предприятия) (FEAF) [38], The Open Group Architecture Framework (Фреймворк архитектуры открытых групп) (TOGAF) [67], StairLike CIM [31], и недавняя разработка NATO Architecture Framework (Фреймворк архитектуры НАТО) [51], а также множество других, включая корпоративные, адаптированные или комбинированные архитектуры.

Большинство из этих структур ретроспективно накладываются на GERAM [28], [55], [60], [61], [44], чтобы идентифицировать их вклады при сопоставлении или потенциальную незавершенность, а также определить, включают ли эти структуры дополнительные детали, считающиеся необходимыми в различных типичных ситуациях на практике.

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

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

B.1.2 Область применения GERAM

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

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

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

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

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

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

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

B.2 Фреймворк архитектуры и интеграция предприятия

B.2.1 Анализ фреймворка

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

Комплекс составных частей, идентифицированных GERAM, представлен на рисунке B.1, а в B.2.2 описан каждый компонент, который более подробно определяется в B.3.

Фреймворк GERAM идентифицирует наиболее важный компонент - GERA (Обобщенную архитектуру предприятия), основные понятия, которыми необходимо руководствоваться при инжиниринге и интеграции предприятия, например объекты (сущности) предприятия, жизненные циклы и истории жизни сущностей предприятия. GERAM проводит различие между методологиями архитектуры предприятия (EAMs) и языками моделирования (EMLs), которые используются методологиями для описания и моделирования структуры, контента и поведения рассматриваемых сущностей предприятия. EMLs обеспечивают моделирование роли человека в работе предприятия, а также производственных процессов и их вспомогательных технологий. В результате процесса моделирования разрабатываются модели предприятия (EM), которые представляют все или часть работ предприятия, включая его производственные или сервисные задачи, организацию и менеджмент, а также систему управления и информационную систему. Такие модели могут применяться для ориентации при внедрении операционной системы предприятия (EOS), а также для улучшения возможностей предприятия по оценке рабочих или организационных альтернатив (например, посредством моделирования), что в результате приводит к улучшению настоящих и будущих производственных показателей.

Рисунок B.1 - Компоненты фреймворка GERAM

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

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

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

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

B.2.2 Определение компонентов GERAM

B.2.2.1 Обобщенная архитектура предприятия GERA

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

- как понятия с ориентацией на человека:

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

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

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

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

B.2.2.2 Методологии архитектуризации и интеграции предприятия (EAMs)

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

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

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

B.2.2.4 Общие концепции моделирования предприятия (GEMCs)

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

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

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

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

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

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

Область применения этих моделей распространяется на все возможные компоненты предприятия, например:

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

- рабочие процессы, например функциональность и поведение;

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

- компоненты инфраструктуры, например информационные технологии, энергоресурсы, услуги.

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

B.2.2.6 Инструменты архитектуры и инжиниринга предприятия (EAETs)

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

B.2.2.7 Модели предприятия (EMs)

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

B.2.2.8 Модули предприятия (EMOs)

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

B.2.2.9 Операционные системы предприятия (EOS)

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

B.3 Спецификация компонентов фреймворка GERAM

B.3.1 Спецификация GERA

B.3.1.1 Основные понятия

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

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

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

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

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

- роли человеческих ресурсов;

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

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

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

Примеры архитектур предприятия, таких как фреймворки архитектуры, приведены в ARIS [62] (Архитектура интегрированных информационных систем), CIMOSA [36] (Архитектура открытых систем), GRAI/GIM [34] (Диаграммы с результатами и взаимосвязанными видами деятельности)/Интегрированная методология GRAI, IEM [49] (Интегрированное моделирование предприятия), PERA [71] (Архитектура предприятия Purdue), а также многие другие, дополняющие указанные или являющиеся их производными. ИСО 19439 устанавливает общую основу моделирования предприятия. Настоящий стандарт устанавливает требования, которым должны соответствовать указанные фреймворки.

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

B.3.1.2.1 Роли сотрудников

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

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

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

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

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

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

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

d) развитие отдельных работников, их мастерства, знаний и карьерного роста.

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

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

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

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

- перестроить свои бизнес- и производственные процессы;

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

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

B.3.1.2.2 Модели ролей человека

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

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

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

B.3.1.3 Концепции, ориентированные на процесс

B.3.1.3.1 Концепции моделирования процесса

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

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

b) история жизни, которая описывает инстанцирование во времени видов деятельности жизненного цикла;

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

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

Более подробно данные концепции будут описаны ниже.

B.3.1.3.2 Концепция жизненного цикла

B.3.1.3.2.1 Фазы жизненного цикла

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

B.3.1.3.2.2 Идентификация сущности

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

B.3.1.3.2.3 Концептуализация сущности

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

Рисунок B.2 - Фазы жизненного цикла GERA

B.3.1.3.2.4 Определение требований к сущности

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

B.3.1.3.2.5 Проектирование сущности

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

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

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

Общие технические требования к предприятию представляют собой деятельность по концептуальному эскизному проектированию, которая является основной по отношению к разработке решения проблемы, представленной набором требований. Для выполнения такой деятельности часто используют системного архитектора. С точки зрения высшего руководства разработка архитектуры является видом деятельности. В то же время с точки зрения архитектора, принимающего решения, детали этой деятельности должны содержать ряд технических, управленческих процессов и процессов менеджмента, см. ISO/IEC/IEEE 42020 и ISO/IEC/IEEE 42030.

B.3.1.3.2.6 Реализация сущности

Реализация сущности включает виды деятельности, которые определяют задачи, подлежащие выполнению для создания или модернизации сущности, включающие реализацию в самом широком смысле, действие которой распространяется:

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

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

c) конструирование, производство или создание сущности;

d) испытания компонентов и верификацию, интеграцию системы, валидацию и проведение испытаний;

e) ввод в эксплуатацию вновь развернутой сущности или ее новой версии;

f) создание или актуализацию документации по сборке или внедрению.

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

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

B.3.1.3.2.7 Работа сущности

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

Примечание - Фактические действия по изменению включают экземпляры жизненного цикла, рассмотренные в B.3.1.3.2.2-B.3.1.3.2.6. Аналогичным образом оперативные потребности часто требуют динамической конфигурации или реконфигурации частей системы либо создания виртуальной организации.

B.3.1.3.2.8 Вывод сущности из эксплуатации

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

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

B.3.1.3.3 История жизни

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

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

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

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

Пример - Связи между жизненным циклом и историей жизни, представляющие собой простой случай с комбинацией семи процессов: тремя инжиниринговыми, тремя операционными и одним процессом вывода из эксплуатации, показаны на рисунке B.3.

Рисунок B.3 - Итеративные процессы в истории жизни сущности

B.3.1.3.4 Взаимодействие сущностей при интеграции предприятия

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

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

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

a) на основе ориентации на операционную деятельность;

b) общего и рекурсивного подхода.

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

Рисунок B.4 - Взаимодействие жизненных циклов сущностей Инжиниринговый проект и Завод

B.3.1.3.5 Проектное предприятие

Проектное предприятие - это предприятие (нередко с короткой историей жизни), созданное для создания другой сущности. В качестве примеров проектного предприятия можно привести инжиниринговый проект предприятия, единственные в своем роде производственные проекты, проект ЕРС (инжиниринг, закупка, строительство), строительные проекты и т.д.

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

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

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

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

B.3.1.3.6 Предприятие, ориентированное на оказание повторных услуг и производство повторяющейся продукции

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

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

B.3.1.3.7 Сущность продукции

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

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

B.3.1.3.8 Рекурсия предприятия

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

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

b) сущность Инжиниринг/Реализация, например, проект или программа, обеспечивающие средства для проведения работ по инжинирингу предприятия. Проект или программа могут пользоваться услугами сущности Методология как консультативной службы, чтобы определить, спроектировать и организовать работу сущности предприятия, которая может быть новой производственной линией или отдельным продуктом, например кораблем;

c) сущность Предприятие, например, фабрика или судоверфь, являющаяся результатом операций сущности Инжиниринг/Внедрение. Сущность Производство использует операционную систему, созданную сущностью Инжиниринг/Внедрение, чтобы спроектировать и построить продукт, например корабль, и/или предоставить потребителю услуги предприятия;

d) сущность Продукция, являющаяся результатом операции сущности Производство. Она представляет всю продукцию (и потребительские услуги) предприятия.

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

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

f) сущность Инженерно-строительные подрядчики для упрощения представляется как одна сущность, вносит вклад в технические работы по проектам или программам Инжиниринг/Строительство.

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

Идентификация роли различных сущностей, их продукции и связей между ними демонстрирует рекурсивную характеристику первых четырех типов сущности: a)-d). На рисунке B.5 показана рекурсивная цепочка развития сущностей предприятия.

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

Рисунок B.5 - Рекурсивная классификация сущности Предприятие

На рисунке B.5 показано, что сущность методология также имеет жизненный цикл. Существует четкое различие между:

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

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

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

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

Рисунок B.6 - Вклад в сущность производства со стороны других типов сущностей

B.3.1.3.9 Моделирование процесса

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

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

B.3.1.4.1 Важность технологий для предприятия

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

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

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

B.3.1.4.2 Поддержка ИТ для архитектуры и интеграции предприятия

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

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

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

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

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

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

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

B.3.1.4.3 Сервисы по исполнению и интеграции модели предприятия (EMEIS)

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

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

B.3.1.5 Фреймворк моделирования GERA

B.3.1.5.1 Параметры структуры

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

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

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

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

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

Рисунок B.7 - Справочная модель EMEIS

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

B.3.1.5.2 Моделирование предприятия

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

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

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

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

Примечание - Два столбца слева представляют эталонные модели; правая сторона представляет частные модели предприятий.

Рисунок B.8 - Структура моделирования GERA

B.3.1.5.3 Концепции представления модели

B.3.1.5.3.1 Концепция точки зрения

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

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

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

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

a) точка зрения контента модели сущности: функция, информация, ресурс, организация;

b) точка зрения цели сущности: потребительская услуга и продукция, менеджмент и контроль;

c) точка зрения реализации сущности: исполняемые людьми задачи, автоматизированные задачи для технологии поддержки миссии и задачи технологии управления и контроля;

d) точка зрения физического проявления сущности: программное и аппаратное обеспечение.

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

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

- выбор проекта;

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

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

- анализ функций принятия решений и обнаружения отсутствующих ролей при принятии решений.

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

Рисунок B.9 - Концепция представления модели

Понятие "представление модели" является обобщением понятий представлений многих архитектур, начиная с самых ранних CIMOSA [36], GRAI [34] и др. и согласуется с извлечением соответствующего контента из информационных систем, имеющихся в существующих продуктах и стандартах моделирования предприятия, например ИСО/МЭК 10746, ISO/IEC/IEEE 42010. Фреймворк моделирования GERA допускает применение языков различной выразительной способности для каждого представления модели. Это означает, что существует выбор языка в любом конкретном представлении в зависимости от требуемых возможностей анализа (и, следовательно, выразительной способности) в соответствии с требованиями методологии инжиниринга предприятия.

B.3.1.5.3.2 Точка зрения контента модели сущности

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

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

Примечание - Система менеджмента и контроля нередко называется "системой принятия решений".

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

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

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

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

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

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

B.3.1.5.3.3 Точка зрения цели сущности

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

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

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

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

B.3.1.5.3.4 Точка зрения реализации сущности

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

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

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

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

B.3.1.5.3.5 Точка зрения физического проявления сущности

Два приведенных ниже представления позволяют отобразить физическое проявление сущности предприятия:

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

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

B.3.1.5.3.6 GERA с аспект-ориентированными представлениями

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

B.3.2 Спецификация EAMs

B.3.2.1 Методологии преобразования предприятия

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

Фундаментальный методологический аспект Интеграция предприятия/Архитектура предприятия (EI/EA) таков, что на самом деле для EI/EA не нужно иметь отдельную методологию в смысле следования процессу, который полностью отделен от существующих процессов менеджмента и инжиниринга. Скорее всего, чтобы обеспечить отсутствие пробелов или не упустить какие-либо решения, в рамках методологии EI/EA необходимо объединить и гармонизировать существующие:

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

- соответствующие процессы и методы инжиниринга.

Для организации принять методологию EI/EA равноценно систематическому совершенствованию процессов менеджмента и инжиниринга, совершенствование которых является видом преобразования или мерами по интеграции предприятия, таким образом призывая к реализации методологии "Бутстрэппинг".

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

Рисунок B.10 - Структура моделирования GERA с точками зрения моделирования и связанными с ними представлениями

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

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

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

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

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

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

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

- от типа сущности, разрабатываемой или преобразуемой;

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

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

- наличия хороших эталонных моделей;

- наличия компонентов или продуктов многократного пользования (модули в терминологии GERAM).

Методология инжиниринга предприятия часто имеет отличающуюся картину видов деятельности жизненного цикла, очевидную в соответствующей истории жизни. Простая каскадная методология имеет линейный внешний вид видов деятельности жизненного цикла в истории жизни, тогда как гибкая методология имеет повторяющиеся серии каскадных сегментов в истории жизнедеятельности по мере возникновения каждого нового витка. Большинство методологий имеют пересекающиеся сегменты деятельности, возникающие как итерации проекта, внедрения и тестовых операций. На рисунке B.11 показан пример истории жизни идеализированного приложения методологии спирального развития в контексте подхода инжиниринга V-моделей систем [63].

a - концепция; b - требования; c - анализ; d - задание требований; e - анализ; f - проектирование программного обеспечения; g - детальный проект; h - кодирование; i - испытание единиц; j - испытание систем; k - приемочные испытания

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

Примечание 2 - Строительство опускают, как для единичных, так и для системных и приемочных испытаний.

Примечание 3 - Для испытаний единиц и систем в работе потребуется испытательный стенд.

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

Рисунок B.11 - Образец истории жизни при развитии по спирали с использованием V-модели инжиниринга системы

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

Типичными современными методологиями интеграции/архитектуризации предприятия являются: TOGAF Architecture Development Method (Метод разработки архитектуры, ADM) [66], Unified Modelling Language (Унифицированный язык моделирования, UML) 2.5 с областью применения - разработки ИТ-архитектуры (см. ИСО/МЭК 19505), Purdue Guide for Master Planning (Составление мастер-плана по руководству Purdue) с областью применения - автоматизация производственного объекта [71], NATO Architecture Framework (Фреймворк архитектуры НАТО) (NAF) 4.0 [51], Control Objectives for Information and Related Technologies (Контрольные задачи по информационным и связанным с ними технологиям), версия 5 (COBIT5) с областью применения - гармонизированная стратегия предприятия и разработка ИТ-архитектуры [41], Networked Enterprise (Сетевое предприятие) [50], [29] и т.д. В будущем такие методологии вероятно будут учитывать или опираться на стандарты по процессам жизненного цикла системной инженерии (ISO/IEC/IEEE 15288), процессам разработки архитектуры (ISO/IEC/IEEE 42020) и оценки архитектуры (ISO/IEC/IEEE 42030).

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

B.3.2.2 Человеческий фактор

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

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

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

B.3.2.3 Распределение задач в соответствии с ролями сотрудников и машин

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

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

Такая мера обеспечит разделение задач "Выполнение миссии предприятия" и "Менеджмент и контроль предприятия", как это определено на этапе анализа требований:

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

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

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

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

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

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

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

- границу между Человеческой и Организационной архитектурой и Архитектурой менеджмента и контроля информационной системы;

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

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

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

Рисунок B.12 - Границы автоматизируемости, гуманизируемости и степени автоматизации для определения трех Архитектур реализации

B.3.2.4 Управление проектами, программами и портфелями проектов

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

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

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

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

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

История жизни проекта или программы включает как минимум три временных этапа:

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

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

c) завершение проекта, предусматривающее общую приемку и окончательную оценку проекта.

Широко используемые современные методологии управления проектами включают, среди прочего: для управления проектами, the Project Management Body Of Knowledge (Свод знаний по управлению проектами) (PMBOK) [58] и Projects In Controlled Environments (Проекты в контролируемой среде, версия 2) version 2 (PRINCE 2) [57]; для управления программами: the Programme Management (Управление программами) [56], [59]; для управления портфелем проектов: [42].

B.3.2.5 Экономические аспекты и аспекты производительности

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

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

a) расчет стоимости решения;

b) показатели результативности для принятого решения;

c) сопоставление затрат на выполнение решения с бюджетом.

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

Примеры подхода к технико-экономической оценке могут быть найдены в ECOGRAI [35]. GEM (методологии эволюции GRAI) и Activity Based Costing (методике расчета затрат) [32].

B.3.2.6 Другие аспекты

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

B.3.3 Спецификация языков моделирования предприятия (EML)

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

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

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

- каждая область, представленная в рамках моделирования (см. рисунки B.8 и B.10), должна распространяться на каждый тип сущности предприятия;

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

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

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

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

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

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

Примеры языков моделирования приводятся в ARIS [62], CIMOSA [68], [69], GRAI/GIM [34], IEM [64], UML (см. ИСО/МЭК 15414 и ИСО/МЭК 19505), Языке моделирования систем (Systems Modelling Language, SysML) (см. ИСО/МЭК 19514) или Интегрированном определении (the Integrated Definition, IDEF) или в семействе языков [48], [68], [54]. Соответствующими стандартами являются ИСО 19440, который определяет исходный комплекс основных конструкций для моделирования предприятия, ISO/PAS 19450, который устанавливает объектно-процессную методологию с адаптируемой семантикой формального языка, ИСО 18629, который устанавливает язык спецификации процесса, и ИСО 10303-11, который устанавливает стандартный справочник по языку EXPRESS.

B.3.4 Спецификация общих концепций моделирования предприятия GEMCs

B.3.4.1 Формы разработки концепций

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

a) глоссарии;

b) метамодели;

c) онтологические теории.

При этом должны быть выполнены следующие требования:

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

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

B.3.4.2 Глоссарий

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

B.3.4.3 Метамодели

В контексте GERAM метамодели являются концептуальными моделями терминологической составляющей языков моделирования. Метамодель описывает понятия, используемые в языках моделирования, их ожидаемые свойства и связи, а также некоторые основные ограничения, например ограничения мощности множества. Мета модели языка моделирования ограничивают применяемость языка моделирования с представлением фактов о моделируемой сущности [65]. Метамодели располагаются между неформальными и формальными выражениями. Нормальным представлением метамодели, как правило, является метасхема связей сущностей, классы абстрактных объектов или нотация на языке с аналогичной выразительной способностью. Терминологию, определенную в интегрированных метасхемах, можно также рассматривать как схему (в любой момент времени) инструментальной базы данных инжиниринга предприятия для моделей предприятия.

B.3.4.4 Онтологические теории

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

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

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

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

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

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

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

B.3.5 Спецификация частичных моделей предприятия (PEM)

B.3.5.1 Представление частичных моделей

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

Частичные модели можно выразить как:

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

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

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

B.3.5.2 Частичные модели роли человека

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

B.3.5.3 Частичные модели процессов

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

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

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

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

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

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

B.3.5.4 Частичные модели технологий

Частичные технологические модели обеспечивают общее описание ресурсов и их совокупностей, например описания цеховых участков, сборочных линий, гибких систем производства, офисных систем, ИТ-систем, систем управления, систем связи, систем разведки, наблюдения и рекогносцировки (Intelligence, Surveillance, Reconnaissance (ISR) systems), систем поддержки управления информацией и принятия решений, системы планирования ресурсов предприятия, системы деловой осведомленности и т.д. Все частичные модели являются специфическими для конкретного сектора промышленности и/или конкретной страны, обеспечивая общие описания компонентов (нередко увязанных с каталогами поставщиков), общих правил эксплуатации и т.д. Эти модели образуют очень большой комплекс моделей, и поэтому предприятию рекомендуется вести собственный каталог частичных моделей, используемых в прошлом и настоящем или планируемым для использования в будущем, включая соответствующее обслуживание метаданных.

B.3.5.5 Частичные модели ИТ-систем

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

Частичная модель для интеграции сервисов, которая обеспечивает портативность в гетерогенной среде, нужна, как правило, для интеграции предприятия и должна включать коммуникационные сервисы, контроль обработки/исполнения, презентационные и информационные сервисы. Определение таких сервисов само должно относиться к улучшению стандартных определений, таких как Электронный обмен данными [Electronic Data Interchange (EDI)], Стандарт по обмену данными моделей изделий [Standard for Exchange of Product (STEP)], Язык гипертекстовой разметки [Hyper-Text Mark-up Language (HTML)]/Протокол передачи гипертекстовых файлов [Hyper-Text Transport Protocol (HTTP)], и все остальные протоколы обмена информацией. Затем такие сервисы могут быть упакованы различным образом, как модульные продукты или строительные блоки.

B.3.6 Спецификация инструментов инжиниринга и архитектуры предприятия EAET

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

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

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

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

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

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

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

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

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

С помощью потенциальной интеграции инжиниринга предприятия и сервисов исполнения модели представляется возможным увязать сервис инжиниринга с сервисами менеджмента предприятия.

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

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

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

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

B.3.7 Спецификация модулей предприятия (ЕМО)

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

B.3.8 Спецификация моделей предприятия EM

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

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

Отдельными важными аспектами применения моделей предприятия являются:

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

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

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

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

B.3.9 Спецификация операционной системы предприятия (EOS)

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

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

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

Приложение C

(справочное)

Связь ИСО 15704 с другими международными стандартами на архитектуры систем предприятия

C.1 Связь с международными стандартами на архитектуры систем предприятия

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

Таблица C.1 - Связь с международными стандартами на архитектуры систем предприятия

C.2 Значимые связи с другими стандартами

C.2.1 Связь с ИСО 19439, ИСО 15531 и ИСО 20140

ИСО 15704 указан в нормативных ссылках ИСО 19439, в котором в приложении B представлен фреймворк GERA.

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

C.2.2 Связь с ИСО/МЭК 10746 [Открытые распределенные системы (ODP)]

Подход на основе точек зрения также используется в ISO/IEC 10746 и устанавливает следующие точки зрения:

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

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

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

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

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

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

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

C.2.3 Связь с ISO/IEC/IEEE 42010, ISO/IEC/IEEE 42020 и ISO/IEC/IEEE 42030

Большая часть подхода, использованного для описания требований для архитектуры предприятия, соответствует ISO/IEC/IEEE 42010. Использование проблем заинтересованных сторон, в рамках точек зрения, которые управляют представлениями из моделей, вытекает из стандарта, описывающего архитектуру. Действительно, ISO/IEC/IEEE 42010 идентифицирует ИСО 15704 как архитектурный фреймворк, согласующийся со спецификацией ISO/IEC/IEEE 42010.

В этом смысле ИСО 15704 является инстанцированием метамодели ISO/IEC/IEEE 42010 для описания архитектуры.

Архитектурные процессы ISO/IEC/IEEE 42020, фокусируясь на разработке процесса архитектуры, идентифицированного в ISO/IEC/IEEE 15288, тем не менее применимы для четкой формулировки архитектур предприятия и их выполнений в соответствии с ИСО 15704 путем задания их использования в фазе концепция жизненного цикла, так что они будут использоваться на более поздних фазах.

Поскольку в ИСО 15704 не представлены ни процессы для создания архитектуры предприятия, ни средства определения соответствия архитектуры ее назначению, ISO/IEC/IEEE 42030 предлагает полезный механизм проведения такой оценки.

C.2.4 Связь с МЭК 62264

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

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

Библиография

[1]	ISO 10303 (all parts)	Industrial automation systems and integration - Product data representation and exchange [Системы автоматизации производства и их интеграция. Представление данных об изделии и обмен этими данными (все части)]
[2]	ISO 10303-11	Industrial automation systems and integration - Product data representation and exchange - Part 11: Description methods: The EXPRESS language reference manual (Системы автоматизации производства и их интеграция. Представление данных об изделии и обмен этими данными. Часть 11. Методы описания. Справочное руководство по языку EXPRESS)
[3]	ISO/IEC 10746 (all parts)	Information technology - Open Distributed Processing [Информационная технология. Открытая распределенная обработка. Базовая модель (все части)]
[4]	ISO 14258	Industrial automation systems - Concepts and rules for enterprise models (Промышленные автоматизированные системы. Концепции и правила для моделей предприятия)
[5]	ISO 15531 (all parts)	Industrial automation systems and integration - Industrial manufacturing management data [Промышленные автоматизированные системы и интеграция. Данные по управлению промышленным производством (все части)]
[6]	ISO 15745 (all parts)	Industrial automation systems and integration - Open systems application integration framework [Системы промышленной автоматизации и интеграция. Прикладная интеграционная среда открытых систем (все части)]
[7]	ISO 16100 (all parts)	Industrial automation systems and integration - Manufacturing software capability profiling for interoperability [Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств (все части)]
[8]	ISO 18435 (all parts)	Industrial automation systems and integration - Diagnostics, capability assessment and maintenance applications integration [Системы промышленной автоматизации и интеграция. Интеграция приложений для диагностики, оценки возможностей и технического обслуживания (все части)]
[9]	ISO 18629 (all parts)	Industrial automation systems and integration - Process specification language [Системы промышленной автоматизации и интеграция. Язык спецификаций процесса (все части)]
[10]	ISO 22400 (all parts)	Automation systems and integration - Key performance indicators (KPIs) for manufacturing operations management [Системы промышленной автоматизации и интеграция. Ключевые технико-экономические показатели (KPIs) для управления производственными операциями (все части)]
[11]	ISO 9000	Quality management systems - Fundamentals and vocabulary (Системы менеджмента качества. Основные положения и словарь)
[12]	ISO 11354 (all parts)	Advanced automation technologies and their applications - Requirements for establishing manufacturing enterprise process interoperability [Усовершенствованные автоматизированные технологии и их применение. Требования к установлению интероперабельности процессов промышленных предприятий (все части)]
[13]	ISO 19439:2006	Enterprise integration - Framework for enterprise modelling (Интеграция предприятия. Основа моделирования предприятия)
[14]	ISO 19440	Enterprise integration - Constructs for enterprise modelling (Интеграция предприятия. Конструкции для моделирования предприятий)
[15]	ISO/IEC 15414	Information technology - Open distributed processing - Reference model - Enterprise language (Информационные технологии. Открытая распределенная обработка. Эталонная модель. Язык описания предприятия)
[16]	ISO/IEC 19500 (all parts)	Information technology - Object Management Group - Common Object Request Broker Architecture (CORBA) (Информационные технологии. Группа управления объектами. Общая архитектура брокера запросов к объекту (CORBA) (все части))
[17]	ISO/IEC 19505 (all parts)	Information technology - Object Management Group Unified Modeling Language (OMG UML) (Информационные технологии. Унифицированный язык моделирования группы по управлению объектами (OMG UML) (все части))
[18]	ISO/IEC 19510	Information technology - Object Management Group Business Process Model and Notation (Информационные технологии. Модель и нотация процесса менеджмента объекта в групповом бизнесе)
[19]	ISO/IEC 19514	Information technology - Object management group systems modeling language (OMG SysML) (Информационная технология. Язык моделирования систем, разработанный группой по управлению объектами (OMG SysML))
[20]	ISO/IEC/IEEE 15288	Systems and software engineering - System life cycle processes (Системная и программная инженерия. Процессы жизненного цикла системы)
[21]	ISO/IEC/IEEE 42010:2011	Systems and software engineering - Architecture description (Разработка систем и программного обеспечения. Описание архитектуры)
[22]	ISO/IEC/IEEE 42020	Software, systems and enterprise - Architecture processes (Программное обеспечение, системы и корпоративная среда. Процессы, связанные с разработкой архитектуры)
[23]	ISO/IEC/IEEE 42030	Software, systems and enterprise - Architecture evaluation framework (Программное обеспечение, системы и корпоративная среда. Схема оценки архитектуры)
[24]	ISO/PAS 19450	Automation systems and integration - Object-Process Methodology (Системы автоматизированные и интеграция. Объектно-процессуальная методология)
[25]	IEC 62264 (all parts)	Enterprise-control system integration (Интеграция систем управления предприятием (все части))
[26]	CEN/TS 14818	Enterprise Integration - Decisional Reference Model (Интеграция предприятий. Эталонная модель принятия решений)
[27]	Bernus P., Mertins K., Schmidt G. Handbook on Architectures of Information Systems. Berlin Heidelberg: Springer-Verlag. 1998. 896 p. ISBN 978-3-540-26661-7
[28]	Bernus P., Noran O., Molina A. Enterprise Architecture: Twenty Years of GERAM Framework. In: 14th World Congress, The International Federation of Automatic Control Proceedings. 2014. Vol.47, No.2, pp.3300-3308
[29]	Camarinha-Matos L., Afsarmanesh H., Galeano N., Molina A. Collaborative Networked Organizations - Concepts & Practice in Manufacturing Enterprises. In: Jeong W. and S. Y No feds. Computers and Industrial Engineering. 2009. Vol.57, No.1. pp.46-60
[30]	Chen L., Babar M.A., Nuseibeh B. Characterizing Architecturally Significant Requirements. In: IEEE Software, 2013. Vol.30, No.2. pp.38-45
_________________ https://doi.org/10.1109/MS.2012.174
[31]	Chen Y.L., Tseng M.M. A Stair-Like CIM System Architecture. In IEEE Transactions on Component, Packaging, and Manufacturing Technology: Part C. 1997 Vol.20, No.2. pp.101-110
[32]	Chen Y.L., Tseng M.M., Yien J. Economic view of CIM system architecture. In: Production Planning & Control, 1998, Vol.9, No.3: pp.241-249
[33]	Department of Defense Deputy Chief Information Officer DoD Architecture Framework Version 2.02. 2010
_________________ https://dodcio.defense.gov/Library/DoD-Architecture-Framework/
[34]	Doumeingts G., Vallespir B., Chen D. GRAI GRID Decisional Modelling. In: Bernus P., K.Mertins and G.Schmidt, Handbook on Architectures of Information Systems. Berlin Heidelberg: Springer-Verlag. 1998. ISBN 978-3-54026661-7. pp.321-346
[35]	Doumeingts G., Clave F., Ducq Y. ECOGRAI - A method to design and to implement Performance Measurement Systems for industrial organizations - Concepts and application to the Maintenance function. In: Rolstadas A. ed. Benchmarking - Theory and Practice. IFIP Advances in Information and Communication Technology. Boston, MA: Springer. 1995
[36]	ESPRIT CONSORTIUM AMICE eds. CIMOSA - Open System Architecture for CIM. 2nd ed. Berlin: Springer-Verlag, 1993, ISBN 3-540-56256-7 or ISBN 0-387-56256-7
[37]	Evans D. Styles of Architecting: A smarter approach to architecting the Defence Enterprise, Niteworks White Paper. [online] Farnborough, UK: Niteworks. © Crown Copyright 2014. 44 pp.
_________________ https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_ data/file/692432/NWP_-_Styles_of_Architecting.pdf
[38]	Federal Enterprise Architecture Framework , 2006 [online]
_________________ http://www.itpolicy.gsa.gov/mke/archplus/fedarchl.pdf
[39]	Fox M.S. The TOVE project: towards a common-sense model of the enterprise, In: Petrie C.J. Proceedings of International Conference on Enterprise Integration Modeling Technology ICIEMT92. Cambridge, MA, USA: MIT Press, 1992, pp.310-319. ISBN 0-262-66080-6
[40]	Guarino N., Guizzardi G. "We Need to Discuss the Relationship": Revisiting Relationships as Modeling Constructs. In: Zdravkovic J., Kirikova M., Johannesson P. eds. Advanced Information Systems Engineering. CAiSE 2015. Lecture Notes in Computer Science. Vol.9097. Cham: Springer. pp.279-294
_________________ https://doi.org/10.1007/978-3-319-19069-3_18
[41]	Information Systems Audit and Control Association COBIT5: A Business and management framework for governance and management of enterprise IT, Version 5. Schaumberg, IL, USA: 2012. ISBN 978-1-60420-237-3
[42]	Levin G., Wyzalek J. Portfolio Management: A Strategic Approach. 2014, CRC Press, ISBN: 9781482251050
[43]	Martin R., Robertson E. A Formal Enterprise Architecture Framework to Support Multi-Model Analysis. In: Siau K., ed. Proceedings of the Fifth CAiSE/IFIP8.1 International Workshop on Evaluation of Modeling Methods in Systems Analysis and Design. 2000
[44]	Martin R.A., Robertson E.L. A comparison of frameworks for enterprise architecture modelling. In: Song I.Y. et al. 22nd International Conference of Conceptual Modeling (ER2003). 2003 ISBN 978-3-540-20299-9
[45]	Martin R.A., Robertson E.L., Springer J.A. Architectural principles for enterprise frameworks: Guidance for interoperability. In: Bernus P., Fox M. eds. Knowledge sharing in the Integrated Enterprise, DIISM 2004, ICEIMT 2004. IFIP - The International Federation for Information Processing. 2005. Vol.183. Springer, Boston, MA
_________________ https://doi.org/10.1007/0-387-29766-9_7
[46]	Martin R., Robertson E. "Meta" Matters. In: INCOSE International Symposium 2010. Wiley Online Library. 2010. Vol.20. No.1
_________________ https://doi.org/10.1002/j.2334-5837.2010.tb01119.x
[47]	Martin R., Robertson E., Springer J. (2004) Architecture principles for architecture frameworks, In: CAiSE*04 8th International Workshop on Evaluation of Modeling Methods in Systems Analysis and Design (EMMSAD’04). 2004. Pp.151-162
[48]	Menzel C., Mayer R.J. The IDEF Family of Languages. In: Bernus P., K.Mertins and G.Schmidt, Handbook on Architectures of Information Systems. Berlin Heidelberg: Springer-Verlag. 1998. ISBN 978-3-540-26661-7. pp.215-249
[49]	Mertins K., Jochem R. MO2GO: User Oriented Enterprise Models for Organizational and IT Solutions. In: Bernus P., K.Mertins and G.Schmidt, Handbook on Architectures of Information Systems. Berlin Heidelberg: Springer-Verlag. 1998. ISBN 978-3-540-26661-7. pp.589-600
[50]	Molina A., Velandia M., Galeano N. Virtual Enterprise Brokerage: A Structure Driven Strategy to Achieve Build to Order Supply Chains. In: International Journal of Production Research , 2007, Vol.45, No 17. pp.3853-3880
_________________ https://doi.org/10.1080/00207540600818161
[51]	Architecture Framework Version N.A.T.O. 4
_________________ https://www.nato.int
[52]	National Institute for Standards and Technology NIST Special Publication 1500-201 Framework for Cyber-Physical Systems: Volume 1 Overview. Gaithersburg, MD. USA: U.S. Department of Commerce. 2017. p.66
_________________ https://doi.org/10.6028/NIST.SP.1500-201
[53]	National Institute for Standards and Technology NIST Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations. Gaithersburg, MD. USA. U.S. Department of Commerce. 2015. P.462
_________________ https://csrc.nist.gov/publications/detail/sp/800-53/rev-4/final
[54]	National Institute for Standards and Technology Integration Definition for Functional Modeling (IDEF0), Gaithersburg, MD, USA: FIPS Publication 183, 1993
[55]	Noran O. Mapping of individual architecture frameworks. In: Bernus P., Nemes L., Schmidt G. eds. Handbook on Enterprise Architecture. Berlin Heidelberg: Springer-Verlag. 2003. pp.65-210. ISBN 978-3-540-00343-6

[56]	Office of Government Commerce Managing Successful Programmes, 3rd Edition. 2011. ISBN 10:0113310404
[57]	Office of Government Commerce Managing Successful Projects with PRINCE 2, 2009 Edition Manual. 2009 PRINCE 2. 2099. ISBN 10:0113310595
[58]	Project Management Institute A guide to the Project Management Body of Knowledge PMBOK Guide, 6th edition. Newton Square, PA: Project Management Institute, Inc. 2017. p.756. ISBN 10-1628251840
_________________ https://www.pmi.org/pmbok-guide-standards/foundational/pmbok
[59]	Project Management Institute The Standard for Program Management, 4nd edition. Newton Square, PA: Project Management Institute, Inc. 2017. p.176. ISBN 10-1628251968
_________________ https://www.pmi.org/pmbok-guide-standards/foundational/program-management/ fourth-edition
[60]	Saha P. Analyzing TOGAF from the GERAM perspective
_________________ http://www.opengroup.org/architecture/wp/saha/TOGAF_GERAM_Mapping.htm
[61]	Saha P.A. Synergistic Assessment of the Federal Enterprise Architecture Framework against GERAM (ISO 15704:2000) In: Shah P ed. Handbook of Enterprise Systems Architecture in Practice. IGI Global. 2007. pp.1-17
_________________ https://doi.org/10.4018/978-1-59904-189-6.ch001
[62]	Scheer A.W. ARIS - Architecture of Integrated Information Systems. In: Bernus P., K.Mertins and G.Schmidt, Handbook on Architectures of Information Systems. Berlin Heidelberg: Springer-Verlag. 1998. ISBN 978-3-54026661-7. pp.541-566
[63]	SEBOK Guide to the Systems Engineering Body of Knowledge, v.1.9.1, Oct. 16, 2018
_________________ https://www.sebokwiki.org/wiki/Guide_to_the_Systems_Engineering_Body_of_Knowledge_ (SEBoK)
[64]	Spur G., Mertins K., Jochem R. Integrierte Unternehmensmodellierung. Berlin: Beuth Verlag. 1993
[65]	Tarski A. The Semantic Conception Of Truth and the Foundations Of Semantics, Chapter 9 Object-Language and Meta-Language. In: Philosophy and Phenomenological Research , 1944. Vol.4, No.3. Pp.341-376
_________________ http://www.ditext.com/tarski/tarski.html
[66]	The Open Group, Architecture Development Method. In: The TOGAF Standard Version 9.2, 2018
_________________ https://pubs.opengroup.org/architecture/togaf91-doc/arch/chap05.html
[67]	The Open Group. The TOGAF Standard. Version 9.2. 2018
_________________ https://publications.opengroup.org/w182
[68]	Vernadat F.B. Enterprise Modelling and Integration: principles and applications, London: Chapman & Hall, 1996, ISBN-0-412-60550-3
[69]	Vernadat F.B. The CIMOSA Languages. In: Bernus P., K.Mertins and G.Schmidt, Handbook on Architectures of Information Systems. Berlin Heidelberg: Springer-Verlag. 1998. ISBN 978-3-540-26661-7, pp.243-264
[70]	Warfield J.N., Christakis A.N. Dimensionality. In: Systems Research 1987, Vol.4 No.2 pp.127-132
[71]	Williams T.J. The Purdue Enterprise Reference Architecture. In: Goossenaerts J. et al. eds. Computers in Industry , 1994, Vol.24, Issue 2-3, pp.141-158
_________________ https://doi.org/10.1016/0166-3615(94)90016-7
[72]	Zachman J.A. A Framework for information systems architecture. In: IBM Systems Journal. 1987. Vol.26, No.3 IBM Publication G321-5298
[73]	Bernus P., Nemes L. A Framework to Define a Generic Enterprise Reference Architecture and Methodology. In: Proceedings: The Third International Conference on Automation, Robotics and Computer Vision (ICARCV’94), 1994. Singapore: Nanyang Technical University. ISBN 9810055013, 9789810055011. Also In: Computer Integrated Manufacturing Systems, 1996. Vol.9, No.3, pp.179-191
[74]	Bernus P., Mertins K., Schmidt G. Handbook on Enterprise Architecture. Berlin Heidelberg: Springer-Verlag. 2003. 788 p. ISBN 978-3-540-00343-6
[75]	Booch G., Jacobson I., Rumbaugh J. The Unified Modeling Language Reference Manual. 1999. Reading, MA: Addison-Wesley
[76]	Buckl S., Buschle M., Johnson P., Matthes F., Schweda C.M. (2011) A Meta-language for Enterprise Architecture Analysis. In: Halpin T. et al., eds. Enterprise, Business-Process and Information Systems Modeling. 12th International Conference, BPMDS 2011 and 16th International Conference, EMMSAD 2011. Lecture Notes in Business Information Processing, 2011, Vol.81. Berlin, Heidelberg: Springer. pp.511-525
_________________ https://doi.org/10.1007/978-3-642-21759-3_37
[77]	Cavalieri S., Pezzotta G. Product-Service Systems Engineering: State of the Art and Research Challenges. In: Cavalieri S. et al. eds. Computers in Industry. 2012. Vol.63, No.4. pp.278-288
[78]	Eden A., Kazman R. Architecture, design, implementation, In: Clarke L., Dillion L. and Tichy W. Proceedings of the 25th International Conference on Software Engineering ICSE’03. 2003. pp.149-159
[79]	Finkelstein C. Information Engineering: Strategic Systems Development. Sydney, Australia: Addison-Wesley. 1992
[80]	Fischer C., Winter R., Aier S. (2010) What Is an Enterprise Architecture Principle? In: Lee R. ed. Computer and Information Science 2010. Studies in Computational Intelligence , Vol.317. Berlin: Springer
_________________ https://doi.org/10.1007/978-3-642-15405-8_16
[81]	Goranson H.T. The agile virtual enterprise: cases, metrics, tools. Westport CT USA: Quorum Books, 1999, ISBN: 1-56720-264-0
[82]	Hitchins D. Putting Systems to work. New York, NY, USA: John Wiley & Sons. 1993. ISBN: 0471934267
[83]	Jorgensen H.D., Lillehagen F., Karlsen D. Collaborative Modelling and Metamodelling with the Enterprise Knowledge Architecture In: Enterprise Modelling and Information Systems Architectures, International Journal of Conceptual Modeling. 2005. Vol.1, No.1
[84]	Kosanke K., Nell J. eds. Enterprise Engineering and Integration: Building International Consensus, Proceedings of ICEIMT’97, International Conference on Enterprise Integration and Modelling Technology. Berlin: Springer-Verlag, 1997. ISBN 3-540-63402-9
[85]	Kosanke K. Comparison of Enterprise Modelling Methodologies. In: Proceedings of the IFIP TC5/WG5.3/WG5.7 international conference on the Design of Information Infrastructure Systems for Manufacturing, DIISM’96, 1997, Chapman & Hall, London
[86]	Lapalme J. et al. Exploring the future of enterprise architecture: A Zachman perspective. In: Romero D. and F.Vernadat. Computers in Industry. 2016. Vol.79. pp.103-113
_________________ https://doi.org/10.1016/j.compind.2015.08.010
[87]	Lapalme J. Three Schools of Thought on Enterprise Architecture. In: IT Professional . 2012. Vol.14, No.6, pp.37-43
_________________ https://doi.org/10.1109/MITP2011.109
[88]	Lillehagen F., Karlsen D. Enterprise Architectures - Survey of Practices and Initiatives, In: First International Conference on Interoperability of Enterprise Software and Applications (Interop-ESA’05) , Industrial Track presentation. 2006
_________________ http://interop-esa05.unige.ch/INTEROP/Proceedings/Industrial/IND1_Lillehagen.pdf
[89]	Petrie Charles J.Jr. Enterprise Integration Modelling. In: ICEIMT Proceedings of the First International Conference on Enterprise Integration Modelling, Cambridge MA USA: The MIT Press, 1992, ISBN 0-262-66080-6.
[90]	Rabelo R.J., Noran O.O., Bernus P. Towards the Next Generation Service Oriented Enterprise Architecture. In: Halle S., Mayer W. eds. 2015 IEEE 19th International Enterprise Distributed Object Computing Workshop . 2015. pp.91-100
_________________ https://doi.org/10.1109/EDOCW.2015.34
[91]	Shorter D.N. ed. An evaluation of CIM modelling constructs - Evaluation report of constructs for views according to ENV 40 003. In Goossenaerts J. et al. eds. Computers in Industry , 1994, Vol.24, Issue 2-3, pp.159-236
_________________ https://doi.org/10.1016/0166-3615(94)90016-7
[92]	Sowa J.F., Zachman J.A. Extending and formalizing the framework for information systems architecture. In: IBM Systems Journal. 1992. Vol.31, No.3. IBM Publication G321-5488
[93]	Thompson K. The Networked Enterprise: Competing for the future through virtual enterprise networks. Meghan-Kiffer Press. 2008. ISBN 978-0929652450
[94]	Tissot F., Crump W. An Integrated Enterprise Modeling Environment. In: Bernus P., K.Mertins and G.Schmidt, Handbook on Architectures of Information Systems. Berlin Heidelberg: Springer-Verlag. 1998. ISBN 978-3-54026661-7. pp.539-567
[95]	Object Management Group Unified Architecture Framework specification Version 1.0 , Needham, MA, USA: Object Management Group Inc., 2017. p.322
_________________ https://www.omg.org/spec/UAF
[96]	Van Der Linden D.J.T., Hoppenbouwers S.J.B.A., Lartseva A., Proper H.A. Towards an Investigation of the Conceptual Landscape of Enterprise Architecture. In: Halpin T. et al. eds. Enterprise, Business-Process and Information Systems Modeling. 12th International Conference, BPMDS 2011 and 16th International Conference, EMMSAD 2011. Lecture Notes in Business Information Processing , 2011, Vol.81. Berlin, Heidelberg: Springer. pp.526-535
_________________ https://doi.org/10.1007/978-3-642-21759-3_38
[97]	Van Der Raadt B., Schouten S., Van Vliet H. Stakeholder Perception of Enterprise Architecture. In: Morrison R. et al., eds, Software Architecture: Second International Conference, ECSA 2008, Lecture Notes in Computer Science, 2008. Vol.5292. Berlin, Heidelberg: Springer, pp.19-34
_________________ https://doi.org/10.1007/978-3-540-88030-1_4
[98]	Weston R.H. Workbenches and reference models for enterprise engineering. In: Molina J.M., Sanchez J.M., Kusiak A. eds. Handbook of Life Cycle Engineering: Concepts, Tools and Techniques. 1998, London: Chapman & Hall, ISBN: 978-0-412-81250-7
[99]	Williams T.J., Hong L.I. A Specification and Statement of Requirements for GERAM (The Generalised Enterprise Reference Architecture and Methodology) with all Requirements illustrated by Examples from the Purdue Enterprise Reference Architecture and Methodology PERA, Version 1.1, Research Report 159, Purdue Laboratory for Applied Industrial Control, [1995] CIMOSA - Open System Architecture for CIM, Technical Baseline, Version 3.2, CIMOSA Association, private publication [March 1996]
[100]	Williams T.J. et al. Architectures for integrating manufacturing activities and enterprises. In: Goossenaerts J. et al., eds. Computers in Industry, 1994, Vol.24, Issue 2-3, pp.111-139
_________________ https://doi.org/10.1016/0166-3615(94)90016-7
[101]	Wirsing M., Knapp A. View Consistency in Software Development. In: Wirsing M., Knapp A., Balsamo S. eds. Radical Innovations of Software and Systems Engineering in the Future (RISSEF 2002). Lecture Notes in Computer Science , 2004. Vol.2941. Berlin: Springer
_________________ https://doi.org/10.1007/978-3-540-24626-8_24