Объекты бизнес архитектуры это

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

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

2. Бизнес Архитектура предприятия

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

Состав, структура и процесс выстраивания архитектуры

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

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

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

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

Исследования выполнены автором в рамках работ Фонда ФОСТАС в 2003 г. Публикация осуществляется на основе разрешения, полученного Фондом от МЭРТ.

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

Архитектура данных включает: БД и хранилища данных; системы управления БД или хранилищами данных; правила и средства санкционирования доступа к данным. Техническая архитектура состоит из сетевой архитектуры и архитектуры платформ. Сетевая архитектура включает:

Архитектура бизнеса. Общий обзор. Что это и зачем

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

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

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

Моделирование архитектуры

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

Среда моделирования архитектуры предприятия должна включать четыре компонента.
1) Блок элементарных объектов предприятия:
описания (представления) элементарных объектов (например, конкретного продукта/услуги, производимого на предприятии в настоящее время);
средства, используемые для порождения таких представлений (т.е. данных по объектам) со-гласно определенным правилам (например, ERP, SCM, CRM, СУБД).
2) Блок моделей архитектуры предприятия:
собственно модели различных видов (процессно-функциональные, информационные, ресурсные, организационные и др.), состоящие из элементов, абстрактно отображающих элементарные объекты;
средства моделирования, обеспечивающие анализ, проектирование и использование моделей.
3) Блок языков и методологий моделирования, включая:
общемодельные конструкции;
процессы моделирования архитектуры предприятия;
средства, поддерживающие процесс определения и модификации методологий и языков.
4) Блок языков мета-моделирования и мета-методологий для описания концепции, синтаксиса и семантики языков моделирования и методологий их применения, а также для описания процессов построения этих языков и методологий.

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

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

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

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

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

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

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

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

Идея создания семейства стандартов IDEF (Integrated Computer Automated Manufacturing Definition) родилась в середине 70-х годов в ВВС США как решение проблемы повышения производительности и эффективности информационных технологий, возникшей при реализации программы ICAM (Integrated Computer Aided Manufacturing). Часть этого семейства из 14 стандартов, относящихся к методам и технологиям создания моделей сложных систем и проектирования компьютерных систем, имеет непосредственное отношение к моделированию бизнес-процессов, а именно: IDEF0 (модель функций), IDEF1 и его расширение IDEF1X (информационная модель и модель данных соответственно), IDEF2 (динамическая модель), IDEF3 (модель процессов) и IDEF4 (объектно-ориентированные методы проектирования). Часть стандартов семейства фактически осталась на бумаге (стандарт IDEF2), другая часть (IDEF0 и IDEF1X) превратилась в стандарт правительства США, известный как FIPS. Основными недостатками IDEF являются:

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

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

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

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

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

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

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

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

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

1. Галактионов В.И. Системная архитектура и ее место в архитектуре предприятия//Директор информационной службы. 2002. № 5.
2. Разработка типовых требований к процессам информатизации органов государственной власти, включая разработку единой методологии построения «электронного прави-тельства»//Отчет о НИОКР. Фонд ФОСТАС, № госрегистрации 1027739757561, инв. № 2811/01. Москва. 2003.
3. Электронное правительство: рекомендации по внедрению в РФ /Под ред. В.И. Дрожжинова и Е.З. Зиндера, ЭКО-ТРЕНДЗ. Москва.

2004.
4. Harmon P. Developing an Enterprise Architecture // Business Process Trends, January, 2003.
5. Report on the State of the Art in Enterprise Modeling, University of Namur, 2002.

• моделирование бизнеса с позиции менеджера, включающее построение концепций с использованием графических образов (пиктограмм) для представления бизнес-объектов и событий;
• моделирование бизнес-процессов, бизнес-функций, ресурсов;
• моделирование оргструктуры, включая ее нисходящую логическую схему, а также логические схемы принятия решений;
• преобразование бизнес-моделей в модели приложений и технологической архитектуры.
• универсальные интегрирующие среды (например, Zachman Framework, GERAM);
• языки моделирования предприятий (например, IDEF, ARIS, BPML);
• программные среды моделирования (например, ARIS 6 Collaborative Suite, Popkin System Architect, METIS);
• мета-модели и языки мета-моделирования (например, UML Profile for Business Process Definition, UEML).
• концепциях, ориентированных на человека (описание ролей, поддержка осуществляемых ролями процессов);
• процессно-ориентированных концепциях для описания бизнес-процессов;
• концепциях, ориентированных на технологии, для описания технологической поддержки процессов (моделирования и использования моделей).
• наличие всего трех типов моделей — функциональной, информационной и процессной, остальные аспекты архитектуры если и могут быть отображены, то на примитивном, недостаточном для серьезного анализа уровне;
• отсутствие интеграции даже для перечисленных трех типов моделей (при этом отсутствует как концепция интеграции, так и какая-либо реализация на уровне инструментов одного и того же производителя).
• общего, визуального, базированного на шаблонах языка для коммерческих инструментальных средств моделирования предприятий и программных систем класса workflow;
• стандартизованных, независимых от инструментов механизмов передачи знаний (моделей) между проектами;
• репозитория моделей предприятий.
• оказание помощи менеджерам при анализе потенциальных изменений и их реализации;
• предоставление основы для совместной работы бизнес-менеджеров и ИТ-менеджеров над целями, бизнес-процессами и выстраиванием предприятия в целом;
• предоставление единого хранилища всей информации о предприятии;
• обеспечение менеджерам поддержки в принятии решений: они могут обозревать отношения, задавать вопросы, идентифицировать проблемы, выполнять моделирование и т.д.

Источник: avtprom.ru

Архитектура системы и Бизнес-архитектура

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

Архитектура и строительные конструкции

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

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

Строительный проект состоит из двух основных частей: архитектурно-строительной и инженерной.

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

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

• Системы водоснабжения и канализации – схема разводки водоснабжения, аксонометрическая схема водоснабжения, схема разводки канализации.
• Отопления и вентиляции – схема разводки отопления, схема разводки вентиляции, обвязка котла (при его наличии).
• Электроснабжения – разводка освещения, разводка силовых сетей, схема ВРУ, система по заземлению.

… место для размышлений …

Для IT-архитекторов, которые «в танке» и любят сравнивать себя с зодчими:

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

Архитектура системы

Теперь рассмотрим определение, которые ближе к IT. За основу возьму выдержки из статьи.

Архитектура – фундаментальные понятия или свойства системы в ее окружении, воплощенные в ее элементах, отношениях и принципах ее проектирования и эволюции. (Из: ISO/IEC/IEEE 42010:2011)

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

Архитектура – это проектные решения, которые тяжело изменить. (Мартин Фаулер)

Однако, существует тонкость с характеристикой «тяжело изменить».

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

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

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

Можно утверждать, что таким образом раскрывается значение слова «фундаментальные» в определении «Архитектуры» по ISO, это то что тяжело изменить.

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

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

Проблема

Проблема у указанных выше определений, хотя они и полезные, всё же есть, они оторваны от идеи, заложенной в систему. Выделять архитектуру по критерию «тяжело изменить» довольно странно.

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

… место для размышлений …

Большая часть системных архитекторов вышло из программистов, они все технократы. Это всё придумали они. 🙂
При работе с архитектурой лучше сфокусироваться на назначение Системы.

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

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

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

Бизнес-архитектура

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

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

• Субъекты – это организационно штатная структура.
• Деятельность – это бизнес-процессы, функции и сервисы.
• Объекты – это результат деятельности и материал для деятельности. При этом результатом и материалом может быть физическим или информационным.

Концепция «Три вида деятельности»

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

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

Outsource управления:
Хотите потерять бизнес? Отдайте управление на outsource. 🙂

Концепция «Циклы Деминга»

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

• Планирование
• Действие
• Проверка
• Корректировка

Посмотрим нашу конкретную проектную работу, производство продукта или оказание услуги:

• Кто спланировал этот процесс?
• Какие есть регламентные и нормативные документы?
• Кто выполняет действия?
• Как выполняется проверка?
• Как выполняется корректировка?

Концепция «Принятие решения»

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

• Уяснение задачи
• Оценка ситуация
• Разработка вариантов решения
• Выбор решения

Давайте сопоставим эту концепцию с нашими проектами:

• Как выполняется уяснение задачи?
• Как выполняется оценка ситуации?
• …

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

Принцип «Целевое назначение должно определять архитектуру»

Тут важно напомнить определение архитектуры:

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

Целевым назначением обычно является основная деятельность. Управляющая деятельность направлена на основную деятельность. Поддерживающая деятельность обеспечивает ее.

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

Принцип «Архитектура должна соответствовать руководству»

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

Возможен внутренний конфликт.

… место для размышлений …

Определение Бизнес-архитектуры

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

Из существующих определений мне нравится, которое дала группа Architecture Board Special Interest Group (BASIG) (Специальный совет по архитектуре OMG)

A Blueprint Of The Enterprise That Provides A Common Understanding Of The Organization And Is Used To Align Strategic Objectives And Tactical Demands.

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

Архитектор

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

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

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

Какими компетенциями он должен обладать?

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

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

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

… место для размышлений …

Ссылки

1. http://www.ovikv.ru/строительный_проект.htm
2. pubs.opengroup.org/architecture/togaf9-doc/arch/toc.html
3. pubs.opengroup.org/architecture/togaf9-doc/arch/chap20.html
4. docs.microsoft.com/ru-ru/dotnet/architecture/modern-web-apps-azure/architectural-principles
5. www.omg.org/bawg/business_architecture_overview.htm

• архитектура
• архитектура системы
• бизнес-архитектура

Источник: habr.com

Бизнес-архитектура организации: стратегия построения за 10 минут

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

Понятие бизнес-архитектуры организации

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

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

С какой целью создается, преимущества и недостатки

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

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

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

Обязательно прочитайте: Бизнес-процессы в организации за 5 шагов: Описать и Внедрить
Значение для бизнеса

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

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

Стратегия построения за 10 минут

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

Заключение

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

Оставляйте заявку на БЕСПЛАТНУЮ стратегическую сессию-аудит вашего маркетинга с нашим специалистом:

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

Источник: adwai.digital