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

Поделитесь работой в социальных сетях

Если эта работа Вам не подошла внизу страницы есть список похожих работ. Так же Вы можете воспользоваться кнопкой поиск

Введение

1.3. Слои в архитектуре

Список литературы

Введение

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

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

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

1.1. Ключевые элементы архитектуры предприятия

Управление архитектурой предприятия (Enterprise Architecture) создает основу для синхронизации объектов внутри предприятия и в то же время обеспечивает их непрерывное изменение для целей оптимизации бизнеса.

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

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

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

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

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

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

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

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

Еще одним ключевым элементом архитектуры с точки зрения взаимосвязи бизнес-архитектуры и ИТ-архитектуры являются требования к информационной системе. Фактически модели требований – это целевой функционал ИТ-решения, который структурируется по бизнес-процессам или по подразделениям. На основании этих требований и существующих моделей бизнес-процессов, а также с учетом построенных моделей данных проектируется новая (целевая) архитектура приложений. При этом помимо методологий управления архитектурой предприятия для решения поставленных задач необходимо использовать и отраслевые стандарты. Например, в случае телекоммуникационных компаний в качестве основы можно использовать материалы методологии New Generation Operation System and Software (NGOSS), которая была создана в 2001 г. TeleManagement Forum и содержит следующие модели:

1. модель операций телекоммуникационной компании eTOM (Enhanced Telecom Operations Map – eTOM);
2. информационная модель телекоммуникационного предприятия (Enterprise-wide Information Framework Shared Information and Data Model – SID);
3. структура приложений телекоммуникационной компании (Applications Framework – Telecom Applications Map – TAM ).

1.2. Модели и инструменты архитектуры приложений

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

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

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

1. Имеющийся портфель прикладных систем. Это каталог имеющихся приложений и компонент, который отражает их связи с поддерживаемыми ими бизнес-процессами, интерфейсы с другими системами, используемую и требуемую информацию, используемые инфраструктурные шаблоны. Чтобы быть реально полезным инструментом, он также должен помогать в идентификации тех элементов портфеля, которые можно использовать повторно и многократно в рамках предприятия, и стимулировать такое повторное использование.
2. Планируемый портфель прикладных систем. Представляет функциональность, которая требуется для обеспечения желаемого состояния бизнес-архитектуры и архитектуры информации предприятия.
3. План миграции. Процесс перехода от текущего к будущему портфелю прикладных систем в рамках ИТ-проектов. Проекты также могут объединяться в портфели проектов. Первым шагом в планировании портфеля прикладных систем является оценка текущего состояния портфеля и того, насколько он соответствует потребностям организации со стратегической и технологической точек зрения, т.е. с точки зрения задач, стратегий бизнеса и с точки зрения технического состояния и стратегий использования технологий на предприятии. Соответствие бизнес-стратегиям оценивается на основе вклада прикладных систем в достижение бизнес результатов, что определяется бизнес-архитектурой предприятия. Технологическое соответствие оценивается на основе анализа того, насколько прикладные системы соответствуют принципам и технологическим стандартам, принятым в технологической архитектуре предприятия. Существуют различные способы оценки портфеля и различные классификации прикладных систем предприятия. Одной из возможных моделей оценки портфеля прикладных систем является оценка их по двум критериям – ценность с точки зрения бизнеса и техническое состояние. Оценка портфеля служит отправной точкой в идентификации проблемных областей и возможностей для лучшего удовлетворения потребностей бизнеса и принятия решения об инвестициях в новые системы или обновление существующих. В результате такой оценки прикладные системы относятся к одной из четырех возможных категорий:
   1. системам грозит вывод из эксплуатации (замена) или консолидация;
   2. системы, требующие переоценки или перепозиционирования;
   3. системы, требующие обновления;
   4. системы, требующие сопровождения и развития.

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

1.3. Слои в архитектуре

Концепция слоев - одна из общеупотребительных моделей, используемых разработчиками программного обеспечения для разделения сложных систем на более простые части. В архитектурах компьютерных систем, например, различают слои кода на языке программирования, функций операционной системы, драйверов устройств, наборов инструкций центрального процессора и внутренней логики микросхем. В среде сетевого взаимодействия протокол FТР работает на основе протокола ТСР, который, в свою очередь, функционирует "поверх" протокола IР, расположенного "над" протоколом Ethernet. Итак, рассмотрим основные причины интереса к слоям архитектуры программных систем:

Слои легко формализуются. Интуитивно понятно, что если система разбита на ряд слоев, то слой n – это компонент или набор компонентов системы, которые используют только компоненты слоя n-1 и могут быть использованы только компонентами слоя n+1.

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

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

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

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

Схема архитектурных слоев обладает и определенными недостатками:

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

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

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

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

Рассматриваемая в статике архитектура предприятия состоит из следующих элементов:

1. миссия и стратегия, стратегические цели и задачи;
2. бизнес-архитектура ;
3. системная архитектура .

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

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

1. сформулированные миссия и стратегия банка, стратегические цели и задачи;
2. бизнес-архитектура в текущем (as is) и планируемом (to be) состоянии,
3. системная архитектура в текущем (as is) и планируемом (to be) состоянии;
4. планы мероприятий и проектов по переходу из текущего состояния в планируемое.

Таким образом, планируемая системная архитектура является архитектурой «to be» только на определенном витке развития предприятия.

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

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

В архитектуре предприятия следует выделять следующие слои:

1. Фронт-офис (Front-Office)

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

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

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

1. Мидл-офис (Middle-office)

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

Примеры подразделений мидл-офиса:

Подразделение проверки заемщиков в службе безопасности,

Подразделение управления рисками.

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

Примеры информационных систем мидл-офиса:

Система ведения позиционного учета,

Система проверки заемщика в бюро кредитных историй,

Система расчета скорингового балла по кредитной заявке.

1. Бэк-Офис (Back-Office)

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

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

1. Учёт (Accounting)

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

1. Информационное хранилище (DWH)
2. Отчётность (Reporting)

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

Примеры систем отчётности:

Система управленческой отчётности,

Система аналитической отчётности,

Система ключевых показателей эффективности подразделений предприятия,

Система формирования показателей для расчёта скорингового балла по кредитной заявке.

Список литературы

1. Васильев Р. Б., Калянов Г. Н., Левочкин Г. А., Лукинова О. В. Стратегическое управление информационными системами; Интернет-университет информационных технологий, Бином. Лаборатория знаний - Москва, 2013 . - 512 c.
2. Гриценко Ю. Б. Архитектура предприятия: Учебное пособие / Гриценко Ю. Б. – 2011. 256 с.
3. Данилин А.В., СлюсаренкоА.И., Учебный курс – Архитектура предприятия [Электронный ресурс] - Режим доступа: http://www.intuit.ru/department/itmngt/entarc/
4. Калянов Г.Н. Моделирование, анализ, реорганизация и автоматизация бизнес-процессов. Учебное пособие: М.: Финансы и статистика, 2006.

PAGE 17

Другие похожие работы, которые могут вас заинтересовать.вшм>
803.		Архитектура гостиничного предприятия	36.04 KB
	Архитектурные аспекты построения и размещения гостиниц. Роль интерьера и дизайна гостиниц на гостиничное предложение. Введение Специфика гостиниц заключается в многообразии функций этих объектов. Благоприятные условия жизнедеятельности человека в гостиницах обеспечиваются благодаря созданию комфорта как в самом здании гостиницы так и на территории прилегающей к ней.
17390.		Архитектура Великого Новгорода	324.25 KB
	Преобладает точка зрения что старый город это так называемое Городище находящееся на правом берегу Волхова в двух километрах от современного города. Чтобы более глубоко познакомится с архитектурой этого города была работы выбрана тема Архитектура Новгорода XI-XV веков. Техника подобных произведений заключалась в том что по зачерненным медным листам резцом наносился рисунок и в его канавки вплавлялась золотая проволока. Ее можно отнести к древнейшим: доска на которой она написана очень старая по ряду признаков и характеру...
19556.		Сталинский вертикализм и архитектура	24.72 KB
	Для того чтобы уяснить специфику собственно советского пути и формообразования и содержания советской архитектуры нужно изучать ограничения и предписания которые накладывались общегосударственной организацией профессиональной деятельности на образ мыслей конкретных мастеров. и с другой - планы квартир сталинского ампира содержащих террасы гостиные комнаты для домработниц и проч.: Неоклассицизм неоклассика термин принятый в советском искусствознании для обозначения различных по социальной направленности и идеологическому...
17255.		Храмовая архитектура Москвы	595.99 KB
	Яркая окраска кирпичных стен церкви Троицы расчлененных нарядной декоративной отделкой из белого резного камня и цветных поливных изразцов покрытие из белого немецкого железа золотые кресты на зеленых черепичных главках все вместе взятое создавало неотразимое впечатление...
13405.		Архитектура Старовавилонского царства	528.04 KB
	Центром ее был город Вавилон Бабили означает Ворота бога цари которого во II тыс. Расцвет Старовавилонского царства пришелся на время правления шестого царя I Вавилонской династии Хаммурапи. При нем Вавилон из небольшого города превратился в крупнейший экономический политический и культурный центр Передней Азии.
7046.		Архитектура и структура ПК. Принцип фон Неймана	9.14 KB
	ПК называют относительно недорогой универсальный микрокомпьютер, рассчитанный на одного пользователя. Современные ПК проектируются на основе принципа открытой архитектуры.
6695.		Архитектура базы данных. Физическая и логическая независимость	106.36 KB
	Там приводятся следующие определения банка данных базы данных и СУБД: Банк данных БнД это система специальным образом организованных данных баз данных программных технических языковых организационно-методических средств предназначенных для обеспечения централизованного накопления и коллективного многоцелевого использования данных. База данных БД именованная совокупность данных отражающая состояние объектов и их отношений в рассматриваемой предметной области. Система управления базами данных СУБД совокупность языковых и...
18392.		Разработка учебно-методического комплекса по дисциплине «Архитектура ЭВМ»	606.23 KB
	Потом круг пользователей расширился в первую очередь за счет ученых использовавших вычислительные машины для проведения машинных экспериментов. Электронным учебником называется продукт образовательного характера который может быть воспроизведен только с помощью средств информатики в том числе и компьютера соответствующий утвержденной программе обучения или программе разработанной автором для предложенного курса и имеющий принципиально новые черты по сравнению с обычным учебником.п Электронный учебник может быть предназначен для...
9225.		АРХИТЕКТУРА И ЭЛЕМЕНТНАЯ БАЗА ЛОКАЛЬНЫЕ ВЫЧИСЛИТЕЛЬНЫХ СЕТЕЙ ЛА	150.96 KB
	Наступившие XXI столетие и третье тысячелетие все настойчивее ставят вопрос: какие летательные аппараты (ЛА) истребительной авиации обеспечат превосходство в воздухе? На поставленный вопрос следует однозначный ответ - ими станут истребители следующего, 5-го поколения, реактивной эры авиации. Провести четкую грань между поколениями ЛА трудно и не всегда возможно. Да и сама смена поколений процесс довольно медленный.
21769.		Процессоры Intel, архитектура процессоров, чипсеты и их характеристики	95.27 KB
	Центральный процессор (Микропроцессор, ЦП) - часть аппаратного обеспечения компьютера, отвечающая за выполнение арифметических операций, заданных программами, и координирующая работу всех устройств компьютера. Процессор представляет собой специально выращенный полупроводниковый кристалл, на котором располагаются транзисторы

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

Вообще говоря, при разработке и использовании архитектуры предприятия, конечно же, целесообразно придерживаться какой-либо одной методики, которая обеспечивала бы единство в подходах и соответствующие наборы инструментов для описания архитектуры. Мы кратко рассмотрим наиболее известные методики в "Методики описания архитектур. Модели Захмана и Gartner, методики META Group и TOGAF" и "NASCIO. Модели "4+1" и SAM. Методики Microsoft и другие. Выбор "оптимальной" методики" . Здесь же мы детализируем наше общее представление о понятии " архитектура предприятия".

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

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

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

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

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

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

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

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

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

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

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

Итак, прежде чем продолжить, приведем еще одно определение архитектуры предприятия, которое дано на сайте www.geao.org "Всемирной Организации Корпоративной Архитектуры" (GEAO – Global Enterprise Architecture Organization):

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

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

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

Мы уже отмечали, что движущей силой архитектуры предприятия является целостное видение, пронизывающее внутриорганизационные границы. Представленная на рис. 4.1 схема, предложенная GEAO, иллюстрирует различные уровни абстракции, связанные с описанием предприятия. Отметим, что в рамках одной организации имеется только одна архитектура предприятия, но при этом на уровне отдельных систем может существовать большое количество архитектур уровня решений (solution architecture ). Архитектура предприятия покрывает как аспекты, связанные с бизнесом, так и аспекты, связанные с ИТ, а также процессы развития, эволюции архитектуры и структуры управления и контроля за этими процессами ( governance ), которые обеспечивают переход от текущего состояния архитектуры в будущее желаемое состояние.

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

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

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

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

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

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

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

Зачастую стандартные ответы на эти вопросы связаны с упором на оптимизацию бизнес-процессов организации и, соответственно, перечислением «базового набора» параметров оптимизации:

♦ дублирование функций;

♦ узкие места;

♦ затратные центры;

♦ качество выполнения отдельных операций;

♦ избыточные операции;

♦ возможности автоматизации;

♦ возможности внедрения систем управления качеством;

♦ возможности сертификации по ISO 900х.

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

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

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

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

♦ формализация и документирование информации (знаний) об организации.

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

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

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

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

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

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

♦ задачи;

♦ показатели эффективности;

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

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

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

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

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

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

Рис. 1. Проблематика управления знаниями в организации в части бизнес-процессов

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

Рис. 2. Перспективные решения по использованию знаний о бизнес-процессах при принятии управленческих решений

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

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

а) ISO 15704 – стандарт по формальному описанию архитектуры предприятия, который был предложен рабочей группой IFAC/IFIP (International Federation of Automatic Control/International Federation for Information Processing);

б) ISO 15288 – стандарт, определяющий жизненный цикл системы;

в) ISO 12207 – стандарт, определяющий жизненный цикл программного обеспечения.

Существует более 30 дополнительных «поддерживающих» стандартов системной и программной инженерии (например, ISO 14258, определяющий концепции и правила моделирования предприятия).

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

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

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

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

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

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

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

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

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

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

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

В подтверждение данных тезисов в отношении роли и места бизнес-моделирования можно привести высказывание аналитика Gartner Джима Синура (Jim Sinur): «На самом деле большинство предприятий в действительности не понимают всей глубины и масштабов выполняемых ими бизнес-процессов, если они не занимались бизнес-моделированием в последнее время» . В целом необходимо отметить, что по различным экспертным оценкам большинство предприятий будут вести проекты, которые так или иначе будут затрагивать различные аспекты проблемы совершенствования бизнес-процессов, несмотря на неоднозначные оценки практики реинжиниринга бизнес-процессов середины 1990-х годов.

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

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

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

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

Очевидно, что постановки задач по моделированию для производственной (коммерческой) организации существенно могут отличаться от задач государственного контрольного (надзорного) органа. По этой причине, безусловно, необходима специфическая настройка каждой из методик высокого уровня под область моделирования. На эту потребность вполне адекватно реагирует рынок консалтинговых услуг. Так, в настоящее время есть практически значимые модели для различных отраслей экономики и госструктур, которые реализованы на основе разных методологий и инструментальных средств моделирования, таких как методология ARIS и базирующееся на ней семейство программных продуктов компании IDS Sheer AG, язык моделирования UML и средство разработки объектно-ориентированных информационных систем Rational Rose компании IBM, методология IDEF, DFD и продукт AllFusion Modeling Suite (ранее BPwin и ERwin) компании Computer Associates и др.

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

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

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

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

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

♦ внедряются электронные административные регламенты;

♦ формируются механизмы информационной и консультационной поддержки;

♦ оптимизируется организационная структура.

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

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

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

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

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

♦ разработчики информационных и технологических систем;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1) систематизация и формализация – построение описательных моделей;

2) построение аналитических и оптимизационных моделей.

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

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

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

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

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

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

♦ Какие интегральные стоимостные и временные затраты требуются для реализации конкретного бизнес-процесса (подпроцесса)?

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

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

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

♦ Какие операции (должностные функции) закреплены за конкретной должностной единицей в рамках осуществления целевой деятельности организации?

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

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

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

♦ определение этапности;

♦ определение ролей в проекте;

♦ формирование и управление в проектной команде и т. д.

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

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

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

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

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

Информационные технологии и управление предприятием Баронов Владимир Владимирович

Зачем требуется понятие архитектуры

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

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

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

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

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

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

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

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

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

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

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

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

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

Облегчение управления изменениями в любых аспектах предприятия:

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

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

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

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

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

Совершенствование процессов планирования капиталовложений и инвестиционного управления;

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

Достижение экономии на основе совместного использования услуг в масштабах всего предприятия;

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

Данный текст является ознакомительным фрагментом. Из книги Все о счетах-фактурах автора Клокова Анна Валентиновна

3.4. Счет-фактуру требуется исправить В предыдущих разделах анализировались ошибки, которые допускаются при заполнении счетов-фактур и возникновение последствий при предъявлении НДС к вычету по таким счетам-фактурам. Согласно пункту 1 статьи 169 НК РФ документом, служащим

Из книги Управление дебиторской задолженностью автора Брунгильд Светлана Геннадьевна

3. ЧТО ТРЕБУЕТСЯ ЗНАТЬ О КОНТРАКТАХ И ДОГОВОРАХ Надлежит законы и указы писать явно, чтоб их не перетолковывать. Правды в людях мало, а коварства много. Под них такие же подкопы чинят, как и под фортецию. Петр

Из книги Управление салоном красоты автора Шамкуть Ольга Владимировна

Что требуется 1. Документы о регистрации фирмы (форма собственности и устав).2. Договор аренды с регистрацией.3. Заключение СЭС.4. Заключение пожарной инспекции.5. Разрешение на деятельность от районной Управы (выдается бесплатно).6. Разрешение на торговлю сопутствующими

Из книги Новая эпоха - старые тревоги: Политическая экономия автора Ясин Евгений Григорьевич

Требуется политическая организация Итак, нужна демократия. Это сегодня уже не красивое слово, а жизненная потребность для страны. Но она должна опираться на какие-то социальные и политические силы, которые стали бы за демократию бороться. А что же наши демократы? Увы, они

Из книги Покажите мне деньги! [Полное руководство по управлению бизнесом для предпринимателя-лидера] автора Рэмси Дэйв

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

автора

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

Из книги Информационные технологии и управление предприятием автора Баронов Владимир Владимирович

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

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

Требуется переводчик Проблему дополнительно усложняет то, что каждый из четырех (PAEI) – типов вкладывает разный смысл в слова «быть», «хотеть» и «требоваться» исходя из своеобразия собственной картины мира.Предприниматель, как правило, принимает решения, воспринимая

Из книги Самое главное в PR автора Олт Филип Г.

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

автора Джестон Джон

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

Из книги Управление бизнес-процессами. Практическое руководство по успешной реализации проектов автора Джестон Джон

Образец типовой архитектуры Обобщенные целевые показатели: в следующие три года обеспечить рост выручки от реализации на 200 %; обеспечить рост прибыли на 150 % в следующие три года.Общие принципы: наши корпоративные ценности: лучшая ценность за уплаченную

Из книги Теория ограничений Голдратта. Системный подход к непрерывному совершенствованию автора Детмер Уильям

Зачем нужно понятие «утверждение»? Для чего мы пользуемся понятием «утверждение»? Если говорится, что «пропущено какое-то утверждение», значит, в логическом дереве не упомянут некий важный элемент (причина, следствие, промежуточная цель или задача и т. д.). Используя

Из книги Истинный профессионализм автора Майстер Дэвид

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

Из книги Практика и проблематика моделирования бизнес-процессов автора Всяких Е И

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

Из книги Легко не будет [Как построить бизнес, когда вопросов больше, чем ответов] автора Хоровиц Бен

Требуется некоторый опыт Эти предпринимательские планы заставили вспомнить о собственном первом опыте работы с венчурными инвесторами.В 1999 году, получив первый транш финансирования для Loudcloud, мы с партнерами отправились к нашему новому инвестору – венчурному

Из книги Метод Сильвы. Искусство управления автора Сильва Хосе

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

Кому и зачем нужна «Архитектура предприятия»?

Copyright © 2009 Забегалин Е.В.

1 Современное состояние архитектурных методологий и практик

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

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

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

«Enterprise Architecture», по-русски «Архитектура предприятия» (АП), сложилась в общую дисциплину как ступень исторического развития множества методологий, относящихся к архитектуре автоматизированных информационных систем - это методологии Дж. Захмана, Ст. Спивака, CIMOSA, GERAM, TOGAF и др. Анализ этого исторического процесса достаточно содержательно представлен в .

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

The Zachman Framework for Enterprise Architecture ;

стандарт ISO 19439:2006 «Enterprise integration - Framework for enterprise modelling»;

стандарт ISO 15704:2000. Industrial automation systems - Requirements for enterprise-reference architectures and methodologies;

«Federal Enterprise Architecture» (FEA), практикуемая и развиваемая правительством США ;

«Extended Enterprise Architecture Framework» (E2AF), развиваемая независимой организацией «Institute For Enterprise Architecture Developments» ;

The Open Group Architecture Framework (TOGAF) .

Наряду с этим в России в 2000 году была разработана и опубликована концептуальная архитектурная схема «3D-Предприятия», в которой матричные идеи Дж. Захмана были дополнены третьим – временным – измерением для отражения трансформации структуры предприятия .

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

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

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

В интересах практического приложения дисциплины АП преодоление указанной искусственности может быть начато с поиска ответа на вопрос: кому и зачем на предприятии может быть нужна «Архитектура предприятия»?

2 Назначение «Архитектуры предприятия»

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

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

Рисунок 2 - Обобщенная структура предприятия

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

Рисунок 3 - «Архитектура предприятия» может быть использована для поддержки основных функций менеджмента

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

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

в контуре стратегического управления предприятием - это формализация и предоставление

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

Рисунок 4 - Основные функции «Архитектуры предприятия»

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

"Zachman Framework for Enterprise Architecture", "Extended Enterprise Architecture Framework", "TOGAF",

"GERAM", стандартом ISO 19439-2006 (уровни "Generic", "Partial", "Particular").

После Дж. Захмана наиболее конкретно и последовательно управленческие уровни использования АП предложены в схеме «3D-Предприятия» - «Главные потребности, цели, планы, ограничения», «Бизнес-модель», «Логическая модель», «Техническая архитектура», «Детальная реализация», «Практика использования» .

3 Состав «Архитектуры предприятия»

Все архитектурные методологии сходятся в том, что для достаточно содержательного описания устройства предприятия (организации) необходимо использовать множество различных точек зрения (views) на это устройство. Эти точки зрения могут называться также архитектурными доменами, содержательными аспектами и т.п. Описание (и моделирование) структуры предприятия во множестве различных точек зрения и дает в итоге «Архитектуру предприятия».

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

в Zachman Framework for Enterprise Architecture - это "Data", "Function", "Network", "People", "Time", "Motivation";

в Extended Enterprise Architecture Framework (E2AF) - это "Business", "Information", "Information

Systems", "Technology Infrastructure";

в GERAM и в ISO 19439-2006 - это "Function", "Information", "Resource", "Organization";

в TOGAF - это "Business", "Information", "Application", "Technology".

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

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

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

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

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

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

В «Матрице Захмана» этот аспект обозначается наименованием первой строки "Scope" ("The purpose of the Row 1 are to define the boundaries of the Enterprise, what is being included …" ).

В Federal Enterprise Architecture (FEA) - это "Performance Reference Model".

В E2AF и в GERAM логический аспект в явном виде не выделен и включен в аспект "Business". Однако в основных принципах E2AF утверждается: "No strategy, no enterprise architecture ... No Scope - No enterprise architecture

The Scope and the Goals & Objectives sets the level of abstraction of the enterprise architecture ... Business Drivers, Goals & Objectives are leading ..." .

В TOGAF логическому аспекту соответствует "Architecture Vision" ("... key elements of the "Architecture Vision" - ...

enterprise mission, vision, strategy, and goals ..., include architecture principles, define breadth of coverage of enterprise, the specific architecture domains …" ).

Подводя итог обзору логического аспекта и пользуясь философским языком, можно утверждать необходимость логического аспекта структуры предприятия для представления "Интегральной идеи предприятия", "Интегрального замысла предприятия", "Интегрального понятия предприятия", по-английски можно предложить - "The Notion of the Enterprise".

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

В GERAM, в ISO 15704-2000, ISO 19439-2006 для структурирования временного аспекта предложено множество стадий жизненного цикла: "Identification", "Concept", "Requirements", "Design", "Implementation", "Operation", "Decommission".

В методологии TOGAF - Architecture Development Method (ADM) - временной аспект отражается последовательностью стадий разработки, внедрения и изменения самой «Архитектуры предприятия».

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

Рисунок 5 - Основные точки зрения на структуру предприятия

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

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

организационная архитектура - это организационная структура предприятия;

имущественная архитектура - это структура собственности предприятия;

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

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

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

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

структура бизнес-функций и бизнес-процессов предприятия;

структуры потоков материалов и информации на предприятии.

Рисунок 6 - Комплексное представление «Архитектуры предприятия»

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

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

Бизнес-архитектура - это архитектура предприятия, рассматриваемая без его ИТ-архитектуры.

4 Как получить и использовать «Архитектуру предприятия»

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

Первый путь потребует от менеджмента предприятия:

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

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

самостоятельной разработки и документирования методического обеспечения АП;

самостоятельной разработки АП.

Разработка АП внешними консультантами потребует от менеджмента предприятия заключения контракта на выполнение работ:

по непосредственной разработке АП;

по разработке и документированию методического обеспечения АП;

по созданию архитектурной службы предприятия.

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

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

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

Список использованных источников

1. Зиндер Е. «3D-предприятие» – модель стратегии трансформирующейся системы. «Директор информационной службы», №4, 2000. http://www.sept2000.ru/articles/2008/03/03/1/ .

2. Зиндер Е. Архитектура предприятия в контексте бизнес-реинжиниринга. «Intelligent Enterprise/Корпоративные системы», №4, №7, 2008.

3. Галактионов В. Системная архитектура и ее место в архитектуре предприятия. «Директор информационной службы», №5, 2002.

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

5. Дрожжинов В., Штрик А. Стандартизация архитектуры государственных ведомств США. PC Week/RE. №28, №31, 2005.

6. Zachman John A. The Zachman Framework. http://www.zachmaninternational.com/

7. The Office of Management and Budget. Federal Enterprise Architecture (FEA). http://www.whitehouse.gov/omb/e-gov/fea/

8. Schekkerman J. Extended Enterprise Architecture Framework Essentials Guide. Institute For Enterprise Architecture Developments, 2006. http://www.enterprise-architecture.info/

9. The Open Group Architecture Framework (TOGAF). http://www.opengroup.org/architecture/togaf8doc/arch/toc.html

10. Generalized Enterprise Reference Architecture and Methodology (GERAM). IFIP–IFAC, 1999.

11. Иванова И.А. Менеджмент: Учебное пособие. - М.: Издательство РИОР, 2004.

Facebook

Twitter

Вконтакте

Google+

Отчетность