Элементы бизнес архитектуры контекст бизнес архитектуры - Контакты компаний и предприятий на Atlaso.ru

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

Контекст и основные элементы бизнес-архитектуры

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

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

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

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

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

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

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

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

Рис.
5.7.
Контекст Бизнес-архитектуры

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

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

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

Далее рекомендуется выполнить следующие шаги.

Шаг 1. Идентификация критически важных для предприятия процессов (обычно не более восьми).

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

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

Желательно, чтобы рекомендуемое число таких процессов, не превышало «волшебного числа» 8 в соответствии с известным принципом: «семь плюс-минус два» объекта. При необходимости схожие бизнес-процессы могут быть объединены в группы или классы.

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

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

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

Шаг 5. Идентифицировать и документировать основные категории информационных объектов (опять же рекомендуется не более восьми).

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

Источник

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

организационно-штатную структуру.

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

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

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

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

•средства и методы разработки и сопровождения приложений.

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

•базы данных и хранилища данных;

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

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

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

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

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

•аварийные планы по обеспечению бесперебойной работы сетей в условиях чрезвычайных обстоятельств.

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

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

•операционные и управляющие системы, утилиты и офисные программные системы;

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

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

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

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

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

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

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

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

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

а) оценку влияния компонента на процесс;

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

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

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

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

Контекст и основные элементы бизнес-архитектуры

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

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

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

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

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

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

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

•Каков внешний контекст деятельности организации?

•В чем состоят основные функции и добавочная стоимость, которая является итогом деятельности организации?

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

•Какие информационные взаимосвязи и процессы обработки информации необходимы?

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

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

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

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

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

Модели бывают различных типов: модели процессов/потоков работ, функциональные модели, организационные модели, модели данных/ресурсов, временные модели типа диаграмм Ганта, модели причинно-следственных связей. Факт заключается в том, что нет «одной, самой лучшей» модели для описания бизнес-процессов. Можно провести аналогию с графиками, которые используются для иллюстраций. Круговая диаграмма с сегментами, пропорциональными по размеру проценту чего-либо целого, отлично подходит для определенных задач, но ее нельзя использовать для иллюстрации и анализа всех типов данных (например, изменений каких-то данных во времени). Точно также при анализе бизнес-процессов выбранный метод моделирования должен отражать цели анализа. Оптимизация процесса по времени и четкий анализ взаимодействия между участниками процесса могут потребовать разных моделей.

Для автоматизации моделирования процессов сложился специальный класс программных продуктов. Наиболее известными являются такие продукты, как ARIS, Software Architeсt, BPWin (новое название – AllFusion Process Modeler), хотя в большом количестве случаев стандартных графических пакетов типа Microsoft Visio, текстового редактора и электронной таблицы бывает достаточно. В данном курсе мы не будем останавливаться на сравнительном анализе этих и других средств, и отсылаем читателя к специализированным публикациям.

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

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

•используемые данные (что?);

•процессы и функции (как?);

•места выполнения этих процессов (где?);

•организации, персоналии-участники, системы (кто?);

•управляющие события (когда?);

•цели и ограничения, определяющие работу системы (зачем?).

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

1)бизнес-процессы / цели и стратегия построения бизнеса;

2)организационная компонента / организационное окружение;

3)информация / информационное окружение;

4)приложения / обеспечивающее окружение.

Структура организационной компоненты

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

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

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

Структура информационной компоненты

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

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

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

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

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

Организация компоненты «Приложения»

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

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

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

Источник

Контекст и основные элементы бизнес-архитектуры

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

Ключом к построению хорошей бизнес-архитектуры является определение бизнес-процессов, их функций и характеристик. Это становится основой для построения архитектуры ИТ-приложений, которые обеспечивают автоматизированную поддержку этих процессов. Хотелось бы в связи с этим привести следующую цитату из книги Unleashing the Killer Арр [11]: «Вы тогда достигаете цели, когда становится невозможно определить, где заканчиваются бизнес-аспекты и где начинаются технологии».

? используемые данные (что?);

? процессы и функции (как?);

? места выполнения этих процессов (где?);

? организации, персоналии-участники, системы (кто?);

? управляющие события (когда?);

? цели и ограничения, определяющие работу системы (зачем?).

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

1) бизнес-процессы / цели и стратегия построения бизнеса;

2) организационная компонента / организационное окружение;

3) информация / информационное окружение;

4) приложения / обеспечивающее окружение.

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

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

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

Можно привести следующие определения по целевым постановкам задач для бизнес-архитектуры: «Если архитектура ИТ-предприятия описывает то, как компоненты ИТ объединяются вместе для достижения нужного результата, то точно так же бизнес-архитектура описывает, как элементы бизнеса соединены вместе» [12].

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

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

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

? показатели результативности. Этот аспект состоит в определении ключевых показателей результативности (КПР) работы организации, их текущих и желаемых уровней. Модель КПР используется как средство мониторинга исполнения бизнес-процессов. Для определения показателей результативности работы организации применяются различные методики, например широкую популярность завоевала методика Роберта Каплана и Дейвида Нортона «Balanced Score Card (BSC)». BSC представляет собой систему, основанную на причинно-следственных связях между стратегическими целями, отражающими их параметрами и факторами получения планируемых результатов. Она рассматривает четыре проекции: финансовую, взаимоотношения с потребителями, операционной эффективности и человеческого потенциала организации, цели и задачи которых взаимосвязаны и отражены финансовыми и нефинансовыми показателями.

Данный текст является ознакомительным фрагментом.

Читайте также

118. Основные элементы лизинговой операции

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

26. Собственный капитал и его основные элементы

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

95. Основные элементы лизинговой операции

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

4.3. Функции и основные элементы налогообложения

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

22. Основные элементы статистического графика

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

13. Основные элементы страхования

13. Основные элементы страхования
Лица . В каждом страховом правоотношении обязательно участвуют два лица: страховщик и страхователь ; могут (необязательно) участвовать еще два лица – выгодоприобретатель и застрахованное лицо . Страховщик и страхователь непременно

Основные элементы бухгалтерского учета

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

2. Основные элементы статистического графика

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

Основные элементы

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

Основные элементы концепции кайдзен

Основные элементы концепции кайдзен
Менеджмент должен использовать следующие основные элементы концепции, чтобы реализовать стратегию кайдзен:• Кайдзен и менеджмент.• Процесс, а не результат.• Следуй циклам PDCA/SDCA.• Качество – прежде всего.• Говори, используя

Комитет архитектуры бизнес-процессов

Комитет архитектуры бизнес-процессов
Этот комитет рассматривался на этапе архитектуры

Основные элементы рекламного текста

Основные элементы рекламного текста
Здесь представлены 23 основных элемента рекламного текста, которые следует иметь в виду при написании рекламы (см. главу 18).1. Шрифт.2. Первое предложение.3. Второе предложение.4. Заголовки параграфов.5. Описание продукта.6. Новизна.7.

Основные элементы фирменного стиля

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

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

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

Плюсы и минусы различных подходов к разработке бизнес-архитектуры

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

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

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

Источник

Рис. 2.1 — Контекст Бизнес-архитектуры

Модели бизнес-архитектуры бывают различных типов:

· модели процессов/потоков работ,

· функциональные модели,

· организационные модели,

· модели данных/ресурсов,

· временные модели типа диаграмм Ганта,

· модели причинно-следственных связей.

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

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

Далее рекомендуется выполнить следующие шаги:

Шаг 1. Идентификация критически важных для предприятия процессов (обычно не более восьми).

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

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

· процессы, в которых имеются возможности для экономии.

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

· декомпозиция функций/процессов;

· анализ бизнес-событий;

· моделирование местоположений выполнения функций/процессов;

· модель интеграции функций/процессов.

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

Декомпозиция функций/процессов должна:

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

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

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

· идентифицировать пересечения и излишние функции/процессы.

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

Таблица 2.2. Компоненты декомпозиции функций/процессов

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

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

Таблица 2.3. Компоненты анализа бизнес-событий

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

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

Таблица 2.4. Компоненты модели местоположений

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

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

Таблица 2.5. Компоненты модели интеграции

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

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

· Анализ цепочек создания добавочной стоимости (А нужно ли вообще выполнять этот шаг?)

· Динамическое моделирование (Как эта модель выполнения бизнес-функций будет себя вести при различных значениях на входе и доступных ресурсах, и как со временем будет меняться поведение процесса?)

· Анализ пересечений и непокрытых областей (Gap-overlap analysis) (Будет ли наша бизнес-архитектура иметь избыточные элементы, и есть ли в ней «пробелы»?)

· Соотнесение затрат с активностями (Activity-based costing) (На каких процессах, каналах продаж и заказчиках мы реально зарабатываем или теряем деньги?)

· Обучение (Как эти бизнес-процессы соотносятся с другими?)

· Общая стоимость владения (Сколько стоит этот процесс?)

· Возврат инвестиций (ROI) (Будет ли достигнут возврат инвестиций в данный бизнес-процесс и когда?)

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

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

Обзор компонентов Multisim Компоненты – это основа любой схемы, это все элементы, из которых она состоит. Multisim оперирует с двумя категориями…

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

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

Источник

Время на прочтение
6 мин

Количество просмотров 2.8K

Бизнес-архитектура и ее место в компании

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

Таким образом, архитектура в городе — это наука не только о строительстве и проектировании, но еще и о структурировании.

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

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

TOGAF

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

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

Взгляд со стороны ИТ

Зачем вообще разрабатывать единую архитектуру для работы компании? Рассмотрим этот вопрос с точки зрения Блока информационных технологий Страхового Дома ВСК.

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

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

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

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

Основные бизнес-составляющие

Так случилось, что в один момент ИТ‑архитектура нашей компании устарела и перестала отвечать на вызовы рынка. Развитие ее стало долгим, дорогим и мучительным. Появилась явная цель — избавиться от старых приложений (legacy out) и реализовать новые.

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

Сервисы

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

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

В методологии Agile, во фреймворке SAFe, есть понятие «Value stream». Это картирование — сбор и анализ информации о процессах в потоке, оптимизация операций с точки зрения ценности действий и целесообразности затрат. Ценность рассматривается с точки зрения клиента.

Можно сказать, что наши сервисы — это маленькие велью стримы. Они нарезаны вокруг услуги, продукта, канала продаж и взаимодействий.

Структура сервиса

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

Способности

Способность (Capability) — это умение (или навык) компании. Мы только начинаем работу в этом направлении. На данный момент совместно с Ассоциацией ФинТех (далее — АФТ) разработан драфт функциональной карты страхового рынка. На ее основании реализован каталог способностей до 3 уровня.

Структура каталога способностей

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

Дашборды

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

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

Пример cтруктуры дашборда

Архитектура решения

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

Фронт работ над ПО: развитие функционала по первичному учет сервисов, интеграция с Jira, автоматическое обновление дашбордов, формирование требований и разработка функционала по работе со способностями.

Касательно сервисов, важно отметить следующие пункты:

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

Архитектура решения

Перспективы развития

В 2022 году мы определили целевую концепцию и разработали базовый функционал по сервисам. Далее рассматриваем следующий план взаимодействия с Бизнесом:

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

Стратегия развития бизнес‑архитектуры следующая:

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

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

Заключение

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

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

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

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

Если у Вас есть интерес — пишите skirillov@vsk.ru

Источник