Менеджмент.com.ua - главная страница Мастер-класс Радислава Гандапаса по личной эффективности «Профессиональный и личный успех: скрипты и алгоритмы»
На главную
Сделать закладку
Карта сайта
Расширенный поиск
Обратная связь
Проекти MCUa
Рассылка обновлений портала


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

Раздел: Информационные технологии
Автор(ы): Г.Н. Калянов, журнал "Корпоративные системы" (№3, 2005)
размещено: 04.12.2006
обращений: 43726
отзывов: 2

По прогнозам ведущих консалтинговых компаний, через несколько лет архитектура превратится в одно из главных средств управления изменениями на предприятии. Создание архитектуры является первым шагом на пути к предприятию "реального времени".
В общем виде под архитектурой предприятия (Enterprise Architecture, ЕА) понимается всестороннее и исчерпывающее описание всех ключевых элементов предприятия и межэлементных отношений [1-4].

Согласно ISO 15704 («Industrial Automation Systems — Requirements for Enterprise-Reference Architectures and Methodologies. 1999») архитектура предприятия должна включать роль людей, описание процессов (функции и поведение) и представление всех вспомогательных технологий на протяжении всего жизненного цикла предприятия. В соответствии с документом «Federal Enterprise Architecture Framework. Dev. by: The Chief Information Officers Council (USA)» архитектура является стратегической информационной основой, которая определяет:

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

СОСТАВ И СТРУКТУРА ЕА

Архитектуру предприятия принято представлять в виде следующих слоев (рис. 1):

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

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

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

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

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

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

Архитектура приложений в свою очередь включает в себя:

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

Архитектура данных включает в себя:

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

Техническая архитектура состоит из сетевой архитектуры и архитектуры платформ. Сетевая архитектура включает:

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

Архитектура платформ включает:

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

ПРОЦЕСС ВЫСТРАИВАНИЯ ЕА

Рассматриваемый далее метод выстраивания архитектуры предприятия базируется на концепции EAP (Enterprise Architecture Planning) и современных подходах к выполнению консалтинговых проектов в области информационных технологий.

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

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

Этапы планирования архитектуры

Эти этапы организованы в виде следующей четырехуровневой схемы:

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

Более подробно — см. врезку.

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

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

ИНСТРУМЕНТАРИЙ МОДЕЛИРОВАНИЯ ЕА

Требования к среде моделирования

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

  • описания (представления) элементарных объектов (например, конкретного продукта/услуги, производимого на предприятии в настоящее время);
  • средства, используемые для порождения таких представлений (т. е. данных по объектам) согласно определенным правилам (например, ERP, SCM, CRM, СУБД).

Блок моделей архитектуры предприятия:

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

:Блок языков и методологий моделирования:

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

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

Существующие среды моделирования EA можно классифицировать следующим образом:

  • универсальные интегрирующие среды (например, Zachman Framework, GERAM); языки моделирования предприятий (например, IDEF, ARIS, BPML);
  • программные среды моделирования (например, ARIS 6 Collaborative Suite, Popkin System Archi tect, METIS);
  • мета-модели и языки мета-моделирования (например, UML Profile for Business Process Definition, UEML).

Первая проблема

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

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

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

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

Конкурирующая среда GERAM (Generalised Enterprise Reference Architecture and Methodology) определяет комплекс концепций, методов и моделей, необходимых для проектирования и сопровождения современного предприятия любого типа в течении всего времени его существования. Обеспечивается поддержка всех представленных элементов среды моделирования архитектуры на базе концепций, которые:

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

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

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

Инициация планирования

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

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

Основными задачами шага являются:

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

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

Основными задачами шага являются:

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

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

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

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

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

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

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

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

Предварительное бизнес-моделирование

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

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

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

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

Основными задачами шага являются:

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

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

Основными задачами шага являются:

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

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

  • формирование отчетов по бизнес-модели;
  • распространение отчетов и проведение презентации;
  • сбор замечаний и предложений.

Формирование снимка предприятия

Этап включает в себя следующие три шага:

  • планирование, подготовка и проведение интервью;
  • построение бизнес-модели;
  • распространение и анализ бизнес-модели.

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

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

Описание текущих систем и технологий

Целью этапа является документирование всех используемых на предприятии системных и технологических платформ, т. е. создание так называемого каталога информационных ресурсов IRC (Information Resource Catalog), по-другому — системной энциклопедии, являющейся высокоуровневым объектом, а не детальным словарем данных.

Целью первого шага является определение видов данных для IRC и проектирование форм для сбора данных.

Основные задачи шага включают:

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

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

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

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

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

Формирование архитектуры данных

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

Этап содержит четыре шага:

  • формирование списка кандидатов в сущности (трудозатраты — 10%);
  • определение сущностей, атрибутов и отношений (трудозатраты — 60%);
  • сопоставление сущностей и бизнес-функций (трудозатраты — 20%);
  • анализ результатов (трудозатраты — 10%).

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

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

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

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

Формирование архитектуры приложений

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

Основными шагами этапа являются:

  • формирование списка кандидатов в приложения (трудозатраты — 10%);
  • определение приложений (трудозатраты — 50%);
  • сопоставление приложений и функций (трудозатраты — 15%);
  • анализ применимости существующих приложений (трудозатраты — 15%);
  • анализ результатов (трудозатраты — 10%).

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

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

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

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

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

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

Формирование технической архитектуры

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

Основными шагами этапа являются:

  • идентификация технических принципов и платформ (трудозатраты — 15%);
  • определение платформ и их распределение (трудозатраты — 50%);
  • сопоставление платформ с приложениями и бизнес-функциями (трудозатраты — 20%);
  • анализ результатов (трудозатраты — 15%).

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

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

Основными задачами шага являются:

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

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

На четвертом шаге производится подготовка, распространение и анализ отчета по технической архитектуре.

Разработка плана реализации

Этап включает следующие основные шаги:

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

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

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

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

Заключительное планирование

На этом этапе осуществляется подготовка окончательного отчета по ЕА, подготовка и проведение презентации.

Переход к реализации

Основными шагами этапа являются:

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

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

Языки моделирования предприятий. К наиболее распространенными в настоящее время относятся языки IDEF, ARIS и BPML.

Основными недостатками IDEF являются:

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

ARIS в целом преодолевает перечисленные недостатки IDEF, однако его методология по сути является методологией-оболочкой: нет четко описанных регламентов действий, не предлагается уникального подхода к проблеме моделирования архитектуры предприятия. Сам язык включает более 100 типов моделей, 90% из которых практически никогда не используются, инструментальная поддержка осуществляется продуктом той же компании — разработчика методологии. Этот продукт имеет цену на порядок превышающую стоимость инструментов аналогичного класса для аналогичных платформ, и огромные трудозатраты на его разработку, что вряд ли позволит создать когда-либо конкурирующий инструментарий, поддерживающий данный язык.

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

Вторая проблема

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

Решением данной проблемы занимается рабочая группа, целью деятельности которой является создание унифицированного языка моделирования UEML (Unified Enterprise Modeling Language) с четко определенными синтаксисом, семантикой и правилами взаимоотношений (отображений) между различными языками моделирования архитектуры предприятий. Проект UEML включает разработку:

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

ЗАКЛЮЧЕНИЕ

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

В среднем каждый из вендоров осуществляет продажи программного обеспечения на сумму от 7 до 15 млн. долларов в год (исключение составляет IDS Scheer: объявленный ею доход за 2002 г. составил 211 млн. долларов, он включает не только продажи ПО, но и консалтинг, обучение, выполнение проектов и т. п.).

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

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

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

ЛИТЕРАТУРА

  1. Калянов Г. Н. Архитектура предприятия и инструменты ее моделирования // Автоматизация в промышленности. — 2004 — №7. — С. 9-12.
  2. Калянов Г. Н. Консалтинг: от бизнес-стратегии к корпоративной информационно-управляющей системе. М.: — Горячая линия — Телеком. — 2004.
  3. Электронное правительство: рекомендации по внедрению в Российской Федерации. Под ред. В. И. Дрожжинова и Е. З. Зиндера. М.: ЭКО-ТРЕНДЗ. — 2004.
  4. Spewak S.H. Enterprise Architecture Planning. N.Y.: John Wiley&Sons Inc. — 2003.

Об авторе:

    Калянов Георгий Николаевич — профессор, докт. техн. наук, заведующий лабораторией ИПУ РАН.


РЕКОМЕНДАЦИИ    
   


Бюджетирование с шаблонами бюджетов и финансовой моделью НЕ ПРОПУСТИТЕ:

Получите стратегию развития себя и компании, 17 декабря в Киеве, на практическом тренинге Игоря Вагина «Современные тренды в управлении персоналом». Закрытая встреча собственников бизнеса и руководителей.

ДЕТАЛЬНЕЕ ►

Примечание: Точка зрения авторов статей может не совпадать с точкой зрения редакции Management.com.ua.
Для авторов: Редакционная политика портала.

система корекції помилок Внимание! На сайте работает система коррекции ошибок. Найдя ошибку в слове (фразе), выделите его и нажмите Ctrl+Enter.

ЧИТАЙТЕ ТАКЖЕКНИГИ ПО ТЕМЕ
Цифровое пиратство. Как пиратство меняет бизнес, общество и культуруЦифровое пиратство. Как пиратство меняет бизнес, общество и культуру
Цифровой банк. Как создать цифровой банк или стать имЦифровой банк. Как создать цифровой банк или стать им
Пришестя роботів. Техніка і загроза майбутнього безробіттяПришестя роботів. Техніка і загроза майбутнього безробіття
Метрики для управления ИТ-услугамиМетрики для управления ИТ-услугами
Укрощение больших данных. Как извлекать знания из массивов информации с помощью глубокой аналитикиУкрощение больших данных. Как извлекать знания из массивов информации с помощью глубокой аналитики

Отзывы

Евгений, exp00@bk.ru
Спасибо за четкую систематизацию материала. Но Ваши наукоёмкие в одном месте "репозитария", а в другом "репозитория" или "рекрутинг, реинжениринг" или "сущности" приводят к закипанию...
Зачем говорить: - "менеджеры в бизнес-кафе едят бизнес-ланч", вы прочтите, все что написали своей маме...
Я был участником разработки математических моделей летательных аппартов для расследования летных происшествий. Участвовали множество смежников - ведущих НИИ и КБ(модель шасси разрабатывали ведущие ОКБ по шасси; работу автопилотов и авионики - моделировали ведущие аппаратные ОКБ и т.д.). Масса ТЗ, требований к входным и выходным данным, приемам борьбы с ошибками... Все блоки надо было согласовывать, испытывать и стыковать в один вычислительный комплекс. О сязи с полунатурными тренажерами я уже не говорю...
Все проблемы, которые вы встретите через 10..12 лет мы решали в 75...85-е годы. Даже выработаны ГОСТы к составу и содержанию документации и тд. и т.п.
Например, модели содержали стохастические подходы как к моделированию внешней среды, так и к моделированию деятельности экипажа. Даже тогда мы поняли, что разработанные подходы могут быть применимы для управления любыми динамическими объектами, пусть это будет беспилотный ЛА, огибающий рельеф местности, атомный реактор или мануфактура. Давайте учиться вместе.
С уважением - Е.В.
2006-12-06 11:41:36
Ответить

Питирим, nikbor@idegroup.com
Неужели ко всему этому можно относиться серьёзно? (Упрёк не к автору лично, а к "временам и нравам"). Бедняга Платон пытался понять, как слова связаны с вещами. Сейчас это никого не волнует. За словами может быть пустота. Декарт выдвигал свой принцип cogito, здесь же всё вперемешку: онтология и телеология, объекты и субъекты действия, пространство и время (типа "от обеда до забора"), вещь и знание вещи... И полезностью это не оправдаешь. Успехи достигнуты благодаря электронике(физике), вопреки подобной "методологии". Очень трудно (или невозможно?) изобразить объёмный (не-ньютоновский) предмет на ньютоновской плоскости.
2007-08-07 16:18:50
Ответить


Ваше имя:
E-mail:
Комментарий: 
 

  

Успешные инвестиции начинаются с бонуса 100%

bigmir)net TOP 100
МЕТОДОЛОГИЯ: Стратегия, Маркетинг, Изменения, Финансы, Персонал, Качество, ИТ
АКТУАЛЬНО: Новости, События, Тенденції, Интервью, Бизнес-образование, Комментарии, Рецензії, Консалтинг
СЕРВИСЫ: Работа, Семинары, Книги, Форумы, Глоссарий, Ресурсы, Статьи партнеров
ПРОЕКТЫ: Блог, Видео, Визия, Визионеры, Бизнес-проза, Бизнес-юмор

RSS RSS Актуально   RSS RSS Методология   RSS RSS Книги   RSS RSS Форумы   RSS RSS Менеджмент@БЛОГ
RSS RSS Видео  RSS RSS Визионери   RSS RSS Бизнес-проза   RSS RSS Бизнес-юмор


Copyright © 2001-2016, Management.com.ua
Портал создан и поддерживается STRATEGIC

Подписка на Менеджмент Дайджест

Получайте самые новые материалы на свой e-mail (1 раз в неделю)



Спасибо, я уже подписан(-а)