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

Система управления

Метамодель бизнес-архитектуры

Главная / Менеджмент /
Архитектура предприятия / Тест 5

Доменом архитектуры является:

Доменом архитектуры является:

Доменом архитектуры является:

Доменом архитектуры является:

Доменом архитектуры является:

Доменом архитектуры может быть архитектура: 

Руководящие принципы относятся к:

Цели, задачи относятся к: 

ИТ - архитектура относятся к:

ИТ - стандарты относятся к:

Процедуры относятся к:

Руководства относятся к:

Правильно упорядочена последовательность:

Правильны принципы: 

Правильные принципы: 

Правильны принципы: 

Правилен принцип: архитектура

Неправилен принцип: архитектура

Примеры управления данными - обеспечение:

Примеры управления данными - обеспечение:

Примеры управления данными - обеспечение:

Правилен принцип для любой ИТ-организации:

Правилен принцип для любой ИТ-организации:

Правилен принцип для любой ИТ-организации:

Существуют принципы:

Существуют принципы:

Существуют принципы:

В правила организации информации для управления предприятием входит:

Вопросом во фрагменте: "выявление управляющих параметров →​ ? →​ управление траекторией системы" цикла управления предприятием помечен этап:

Вопросом во фрагменте: "обработка и анализ информации →​ ? →​ выявление управляющих параметров" цикла управления предприятием помечен этап:

Если возможности технологии "привязывают" к решаемым проблемам, то такая концепция разработки информационных систем называется:

Если актуальные проблемы "привязывают" к возможностям технологии, то такая концепция разработки информационных систем называется:

Цели, приоритеты в управлении информационной системой определяются:

К основным свойствам любой модели относится:

К основным свойствам любой модели относится:

К основным свойствам любой модели относится:

Методы архитектуры предприятия

В преддверии старта курса «Enterprise Architect» подготовили для вас текстовую версию демоурока, который провел эксперт OTUS — Петр Подымов.

В рамках урока поговорили:

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

• о применении архитектурного подхода в вопросах трансформации;

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

В будущем Курс «Enterprise Architect» будет построен таким образом, что мы сформулируем бизнес-кейс для трансформации и далее последовательно будем  его решать, чередуя теоретические и практические занятия.

Зачем нужна цифровая трансформация?

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

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

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

Почему это происходит?

Имеют место два фактора:  

• Меняются клиенты, меняется рынок. Рынок становится более быстрым. Клиенты становятся более разборчивыми и требовательными.

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

И в совокупности эти факторы требуют совершенно другого от бизнеса.

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

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

Что такое цифровая трансформация, как ее измерить?

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

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

 1. Неисчерпаемый перечень.

2. Скорость  внедрения изменений

3. Данные dеitadreavon

4. Про клиента

5. Открытость  

6. Быть  актуальными

Также фундаментом любой архитектуры являются такие параметры:

• Эффективность;

• Безопасность;

• Надежность.

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

Поговорив о сути и направлении цифровой трансформации, следует рассказать о том, как и где принимаются решения?

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

• с одной стороны, достаточно структурированной и системной;

• с другой стороны, этот человек должен хорошо понимать, куда компания движется, и как его идеи в эту стратегию встраиваются;

• также важна коммуникация.

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

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

• у тебя есть идея;

• ты знаешь, как эту идею структурировать.

Ты должен:

• Идею описать;

• Хорошо представить идею;

• Обосновать;

• Понимать, каким образом компания примет решение о том, что эта идея будет запущена или не будет.

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

Как устроено принятие решения об изменениях в организации.

Любое  изменение –  это выделение бюджета.
Любое  выделение бюджета – это инвестиции.

 Бюджет  может выделяться:

• Напрямую, комитетом, в виде какой-то суммы;

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

Важно понимать, какая «фича» более актуальна, более приоритетна, с учетом текущих ограничений, текущих планов.

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

Процесс, формирующий общий портфель изменений

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

Инвестиционная стратегия. Склонность к риску. Насколько мы готовы экспериментировать. Насколько консервативны при отборе решений, в которые мы вкладываем деньги.

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

Исполнение портфеля. Управление результативностью портфеля. Качество  проектной деятельности. Метрики, попадание в сроки.

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

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

1. Захватываем  архитектуру предприятия — это  наша основа.

2. Заглядываем и видим  портфель изменений.

3. Смотрим  на результативность портфеля  с точки зрения обратной связи. (сдвигаются /не сдвигаются сроки, что меняется).

4. Участвуем  в инвестиционном процессе.

TOGAF – достаточно старый стандарт, которому больше 20 лет. Пережил несколько реинкарнаций, без существенных изменений.

The Open Agile Architecture – новый стандарт. Как  заниматься архитектурой в agile среде.

Почему именно ADM (Architecture Development Method)?

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

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

АDM

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

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

A. Видение архитектуры. Исходя из того куда движется компания, понимание того, где мы находимся и куда мы хотим прийти, какой наша организация должна стать.
B. Бизнес-архитектура. Более структурированный анализ. Как должен быть устроен наш бизнес. Как  должна эволюционировать наша бизнес-модель, и операционной модель.
C. Архитектура информационных систем.
D. Техническая архитектура. Как это реализуется технологически.
E. Возможности и решения. Какие технические решения нам нужны, чтобы реализовать функции в тех приложениях, которые мы у себя заложили, или которые решили развивать.
F. Планирование миграции. Планируем переход из состояния А, в состояние Б. 
G. Управление реализацией. Как некая дорожная карта изменений компании последовательно/параллельно. Важно следить за отклонениями реализации от видения, архитектуры движения, которые мы нарисовали ранее.
H. Управление изменениями архитектуры. Любое событие, которое возникает в реальном мире, может повлиять на наше понимание организации, понимание того, куда эта организация должна двигаться.

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

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

Последовательность действий

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

Анализ бизнес-архитектуры

Первый шаг – это разработка бизнес-архитектуры в какой-то области. Бизнес-архитектура – это не только ландшафт бизнес-процесса.

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

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

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

• Value Streams – потоки ценности. Фундаментальные вещи, о том как организация доставляет ценность? Как организация работает? В чем ее бизнес состоит?

• Information – то как элементы бизнес-архитектуры связаны с архитектурой информационной.

• Organization – привязка всего к организационной структуре.

• Vision, strategy, and tactics – мотивация компании. Видение стратегии, куда компания движется.

• Stakeholder – лица, принимающие решения.

• Policies, Rules, Regulations – политики.

• Products & Services – продукты и услуги, то есть то, что на витрине перед клиентом.

• Initiatives & Projects – инициативы и проекты, то есть объекты изменений.

• Metrics & Measures – показатели. То, как мы это мерим.

Начать лучше всего с capability (компетенции).
Под компетенциями понимается совокупность:

• навыков и знаний;

• методологий и подходов;

• технологических инструментов.

Компетенция –  это возможность организации делать что-то.

ПРИМЕР:

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

Здесь мы видим, что на одной картинке объединены четыре сущности.

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

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

Для того чтобы реализовать этот процесс, нужно:

• уметь реализовать функционал регистрации согласования компании;

• должна быть реализована настройка;

• должно быть моделирование;

• анализ хода компаний;

• обработка коммуникации в каналах коммуникаций.

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

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

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

Информационная архитектура

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

 Для чего она нужна?

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

• Прикладное значение — выделение контекстов.

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

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

• какие объекты есть;

• кто за них отвечает;

• как эти объекты появляются и потребляются в рамках потока ценностей.

Что мы видим на рисунке?

Контекст продаж:

• клиент;

• продукт;

• территория;

• человек;

• продавец и тд.

 Контекст поддержки:

• клиент;

• продукт;

• ticket  (инцидент);

• дефект;

• связь его с версией продукта.

В рамках этих контекстов начинаем прикладное проектирование.

Архитектура приложений

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

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

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

Для того, чтобы модульность работала хорошо, нужна открытость.

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

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

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

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

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

Следующая фаза

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

Мы идем по такой цепочке:

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

И только после этого мы выбрали и наш выбор обоснован — понятно на что мы тратим деньги, понятно почему. 

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

Как строятся современные системы

Выделяем отдельно презентационный слой.

• делаем определенный универсальный интерфейс.

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

• процессный движок;

• движок бизнес-правил;

• движок отработки кейсов.

 Интеграционный слой, который работает с внешними приложениями.

 Инфраструктурный слой:

• Мониторинг;

• Хранение;

• Безопасность;

• Развёртывание.

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

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

План миграции

Наша картина была бы не полной, если мы не составили план.

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

• Какой у нас общий прогноз на дальнейшее развитие этого решения?

• Какие компетенции постепенно нам нужно будет добавить в команду?

• По каким этапам у нас будет идти развитие?

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

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

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

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

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

Основная ценность – в запуске таких идей. Некая основа (карта), которая помогает делать всё остальное.

Материал подготовлен в преддверии старта курса «Enterprise Architect»

• Узнать подробнее о курсе

Хронологически правильна последовательность приоритетов бизнес-моделирования:

• (Правильный ответ) программирование, тестирование, оценка адекватности
• тестирование, программирование, оценка адекватности
• оценка адекватности, программирование, тестирование

«Узким местом» ИТ-стратегии в бизнесе является:

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

Наибольшее влияние на использование ИТ в бизнесе оказывает:

• (Правильный ответ) адаптивный стиль бизнеса
• (Правильный ответ) виртуализация бизнеса
• (Правильный ответ) сокращение длительности бизнес-процессов

Выберите продолжение фразы: ИТ-стратегия определяет, в основном,

• ресурсы достижения целевого состояния
• (Правильный ответ) процесс, способы достижения целевого состояния
• спрос на продукт
• потребительские качества конечного продукта

Хронологически правильна последовательность приоритетов принятия решения в бизнесе:

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

Бизнес-стратегия базируется на:

• (Правильный ответ) изменениях во времени
• (Правильный ответ) формирование целей и задач
• (Правильный ответ) бизнес-решениях

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

• прорыв — просветление — ожидание — продуктивность
• (Правильный ответ) прорыв – ожидание – просветление — продуктивность
• продуктивность – прорыв – просветление – ожидание

Организация типа В (пo Gartner) – это организация:

• класса безопасности В
• пионер технологии
• (Правильный ответ) допускающая определенный риск

На ИТ-бюджет оказывают наибольшее влияние:

• (Правильный ответ) ИТ-архитектура
• штат работников
• объем реструктуризации

В технологическом развитии любой ИТ есть этапы:

• верификация
• (Правильный ответ) продуктивность
• (Правильный ответ) ожидание

Стратегия процветания бизнеса ориентируется обычно на:

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

Организация типа С (пo Gartner) – это организация:

• (Правильный ответ) принимающая новое, когда это полностью ясно
• класса безопасности С
• пионер технологии

Использование ИТ в организации имеет составляющую:

• (Правильный ответ) спрос на услуги
• спрос на работников
• спрос на нишу рынка

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

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

Правильно утверждение:

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

Системное проектирование — это:

• монодисциплинарный подход
• (Правильный ответ) междисциплинарный подход
• проектирование любой системы

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

• системная и прикладная
• реальная и виртуальная
• (Правильный ответ) системная и программная

Целью управления ИТ бизнеса не является:

• уменьшение скорости передачи сообщений
• (Правильный ответ) увеличение степени сжатия сообщений
• динамичность

Современный бизнес характерен всегда:

• Р2Р
• большим реинжинирингом бизнес – процессов
• (Правильный ответ) высоким межфункциональным взаимодействием

Верно утверждение:

• ИТ-архитектура всегда зависима от ИТ-службы
• ИТ-архитектура независима от ИТ-персонала
• (Правильный ответ) ИТ-архитектура не всегда зависима от ИТ-службы

Архитектура ИТ-семейство

• (Правильный ответ) концепции и руководств
• (Правильный ответ) интерфейсов
• (Правильный ответ) шаблонов и стандартов

Верно утверждение:

• Знания = Архитектура информации + данные
• Архитектура информации — знания
• (Правильный ответ) Архитектура информации — данные, информация и знания

На «владельцев» бизнес — процессов ориентирован уровень архитектуры:

• контекста
• (Правильный ответ) концептуальный
• логический

На вопрос: «С помощью каких технологий можно построить решение?» отвечают на уровне архитектуры:

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

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

• (Правильный ответ) полностью никогда не завершаема
• всегда завершаема, но не всегда полно
• полностью всегда завершена

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

• «ветвей и границ»
• (Правильный ответ) «разделяй и властвуй»
• рекурсии

На вопрос: «Каковы индустриальные ценности?» отвечает уровень:

• логический
• (Правильный ответ) контекста
• физический

Правилен принцип: архитектура

• (Правильный ответ) учитывает рынок
• определяет рынок
• не обязана учитывать рынок

Правилен принцип для любой ИТ-организации:

• (Правильный ответ) иметь интегрированное управление
• вести виртуальные расчеты
• проводить пионерскую рекламу

Цели, задачи относятся к:

• систематическому уровню
• (Правильный ответ) стратегическому уровню
• тактическому уровню

ИТ — архитектура относятся к:

• тактическому уровню
• (Правильный ответ) стратегическому уровню
• оперативному уровню

Руководящие принципы относятся к:

• (Правильный ответ) стратегическому уровню
• промежуточному уровню
• тактическому уровню

Процедуры относятся к:

• уровню запросов
• (Правильный ответ) тактическому уровню
• стратегическому уровню

Примеры управления данными — обеспечение:

• (Правильный ответ) доступности
• связности
• (Правильный ответ) управляемости

Правильны принципы:

• архитектура неадаптивна
• (Правильный ответ) бизнес-требования формирует архитектуру
• (Правильный ответ) архитектура адаптивна

Вопросом во фрагменте: «выявление управляющих параметров >? ? >? управление траекторией системы» цикла управления предприятием помечен этап:

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

Цели, приоритеты в управлении информационной системой определяются:

• актуальностью и входными параметрами
• (Правильный ответ) стоимостью и актуальностью
• стоимостью и типом системы

Правилен принцип для любой ИТ-организации:

• информация – пассив
• (Правильный ответ) покомпонентной разработки
• (Правильный ответ) информация — актив

Каталог прикладных систем всегда должен включать:

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

Классификационным критерием является:

• география
• (Правильный ответ) транзакции
• время

Эффективность ИТ определяется соотношением:

• (Правильный ответ) цена/время реализации (ввода)
• цена/объем поставки
• эффект/затраты

Основная область архитектуры приложений:

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

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

• время разработки
• стоимость разработки
• (Правильный ответ) консолидация

Каталог прикладных систем всегда должен включать:

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

Каталог прикладных систем всегда должен включать:

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

Портфель прикладных систем включает всегда:

• каталог поставщиков
• депозитарий
• (Правильный ответ) каталог приложений

Каталог прикладных систем всегда должен включать:

• область деятельности разработчика
• подкаталоги
• (Правильный ответ) область бизнес-приложений

Процесс перехода от текущего к будущему портфелю прикладных систем — это:

• бизнес-план
• план эвакуации
• (Правильный ответ) план миграции

«Предприятие реального времени» — это предприятие:

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

На вопрос: «С помощью каких технологий можно построить решение?» отвечают на уровне архитектуры:

• логическом
• (Правильный ответ) реализации
• концептуальном

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

• время выполнения
• состав ИТ-менеджмента
• (Правильный ответ) средства проектирования

Архитектуры по уровню различаются

• (Правильный ответ) охватом
• (Правильный ответ) масштабом
• географией месторасположения

Портфель прикладных систем — это интегрированный набор:

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

Реальное преимущество наличия адекватной ИТ-инфраструктуры:

• (Правильный ответ) интегрируемость прикладных систем
• декомпозируемость прикладных систем
• агрегируемость

Реальное преимущество наличия адекватной ИТ-инфраструктуры:

• экономия на рекламе
• (Правильный ответ) экономия на закупках
• экономия на продажах

Основной характеристикой адаптивной системы является:

• самозаключение
• самоудаление
• (Правильный ответ) самозащита

Основные идеи адаптивной инфраструктуры:

• выделение ресурсов — автоматизированное
• (Правильный ответ) выделение ресурсов — автоматическое
• саморегулирование ресурсов

Уровни размещения инфраструктуры верно следуют друг за другом в варианте:

• (Правильный ответ) публичная — технологическая — локальная
• схема – информация – структура
• локальная — публичная — технологическая

Основной характеристикой адаптивной системы является:

• (Правильный ответ) самовосстановление
• прерывание
• ликвидация

Технология META Group выделяет различного типа доменов технологической архитектуры:

• 3
• (Правильный ответ) 2
• 4

Ряд моделей: Garther, МЕТА Group, TOGAF лучше продолжить:

• WindowsNT
• Microsoft
• (Правильный ответ) Giga Group

К методике ISO близок стандарт:

• Ethernet
• КОИ
• (Правильный ответ) The Open Group

Верно «определение» архитектуры как:

• (Правильный ответ) «правил» для руководства
• руководящих «стандартов»
• «исключений» из правил для руководства

Вторая строка таблицы Захмана соответствует:

• (Правильный ответ) концептуальной модели
• модели отношений
• второму пользователю

К требованиям описания ИТ-архитектуры не относится:

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

Основным правилом заполнения таблицы Захмана является независимость:

• строк
• столбцов
• (Правильный ответ) клеток

Ряд моделей: Garther, МЕТА Group, TOGAF лучше продолжить:

• Groler
• B2B
• (Правильный ответ) Zachman

Для описания конкретного решения используется шаблон:

• (Правильный ответ) «Дизаин»
• «Реклама»
• «Презентация»

В домен управления системами NASCIO входит:

• управление банками
• (Правильный ответ) управление активами
• управление пассивами

SAM — модель архитектуры

• тактическая
• (Правильный ответ) стратегическая
• смешанная

В домен управления системами NASCIO входит:

• обеспечение непрерывного тренинга
• (Правильный ответ) обеспечение непрерывности бизнеса
• расчет прибыли

Для описания конкретного решения используется шаблон:

• (Правильный ответ) «Требования»
• «Интерактив»
• «Транзакция»

Домены NASCIO:

• (Правильный ответ) информационное управление
• (Правильный ответ) информационная безопасность
• ГОСТ

Положительные стороны проектирования «сверху — вниз»:

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

Отрицательные стороны проектирования «снизу — вверх»:

• конкретность
• связность
• (Правильный ответ) необходимость наличия опыта

Оптимальный состав МЕТА — команды:

• оптимизатор, реализатор, технолог
• (Правильный ответ) стратег, проектировщик, тренер, советник, контролер
• математик, экономист, технолог, проектировщик, эксперт

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

• обычный, необычный, статус
• обычный, сегментный, статус
• (Правильный ответ) обычный, сегментный, статус-кво

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

• (Правильный ответ) разработку плана перехода
• (Правильный ответ) выполнение плана
• пересмотр плана

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

• (Правильный ответ) разработчики архитектур отдельных доменов
• разработчики отдельных интерфейсов
• разработчики архитектур бизнес-проектов

Аспект стандартизации включает:

• элемент спецификации
• элементарный набор графических примитивов
• (Правильный ответ) элемент архитектуры системы

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

• (Правильный ответ) обратная связь
• мера Хартли
• повторяемость операций

Повторяемый уровень организационной зрелости характеризует:

• завершенность процесса
• (Правильный ответ) набор базовых процессов
• неповторяемость

Необходимо при проектировании архитектуры рассматривать промежутки времени:

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

Стратегическое окно для «хорошей» архитектуры — это:

• 10 месяцев
• 20 месяцев
• (Правильный ответ) 30 месяцев

Наиболее важным при управлении архитектурой является:

• (Правильный ответ) осознание бизнес-стратегии
• (Правильный ответ) изучение бизнес-стратегии
• экономия средств

Возможны функции систем разработки архитектуры предприятия:

• диверсификация
• (Правильный ответ) кросс-ссылки
• (Правильный ответ) организационные структуры

Наиболее важным при управлении архитектурой является:

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

Домены NASCIO:

• (Правильный ответ) управление доступом
• (Правильный ответ) сети и коммуникации
• коммуникативные связи

На вопрос: «С помощью каких решений можно построить решение?» отвечают на уровне архитектуры:

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

На вопрос: «Каковы общие принципы использования технологий ?» отвечает уровень:

• логический
• физический
• (Правильный ответ) концептуальный
• контекста

Когнитивная решетка Gartner состоит из осей:

• (Правильный ответ) претенденты
• (Правильный ответ) лидеры
• мыслители

На вопрос: «Какой «фронт — офис» или «бэк — офис» будет использоваться?» отвечает уровень:

• (Правильный ответ) концептуальный
• логический
• контекста
• физический

По методике АДМ, процесс разработки включает фазы:

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

Бюджет развития — это часть ИТ-бюджета:

• (Правильный ответ) оставшаяся от обязательных затрат
• вся обязательная часть затрат
• затраты на зарплату

Положительные стороны проектирования «сверху — вниз»:

• легкость проектирования
• (Правильный ответ) ясность бизнес — потребностей
• (Правильный ответ) ясность ситуации

Инвестиции в ИТ-инфраструктуру обычно:

• небольшие
• (Правильный ответ) крупные
• средние

Принципом управления и контроля архитектуры предприятия является выполнение процедуры:

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

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

• матрицы
• строки
• (Правильный ответ) столбца

Вопросом во фрагменте: «выявление управляющих параметров ?? ? ?? управление траекторией системы» цикла управления предприятием помечен этап:

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

Модели и моделирование

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

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

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

Примерами качественных и описательных моделей являются:

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

Примерами количественных моделей могут служить:

• математические модели, которые могут быть описаны системами уравнений. Решение уравнений может быть в простейшем случае найдено в аналитической форме, в более сложных случаях применяются различные численные методы. Достаточно часто применяются электронные таблицы, с помощью которых могут быть проведены исследования типа «что – если». В зависимости от используемых средств эти модели могут быть исполняемыми или чисто описательными;
• динамические исполняемые модели, которые строятся с использованием специализированных программных или программно-технических средств и позволяют исследовать поведение описываемых ими объектов в различных внешних условиях. Модели последнего типа относятся к числу наиболее сложных и часто применяются на этапе выбора архитектуры сложных систем со многими элементами и связями, особенно когда поведение элементов описывается нелинейной или случайной функцией. Хотя разработка такой модели и проведение исследований требуют определенных затрат времени и ресурсов, во многих случаях применение таких моделей оказывается экономически обоснованным (см 6.7), а в отдельных областях, связанных с военными, космическими, ядерными и другими объектами такого рода – единственно возможным.

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

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

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

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

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

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

Эти модели описывают архитектуру предприятия на различных уровнях абстракции, которые соответствуют «взглядам» на предприятие различных категорий людей. Процесс условно отображен в виде следующей таблицы, в которой в качестве иллюстрации приведены примеры возможных моделей для каждого домена архитектуры и каждого уровня абстракции [4.7]. Во-первых, заметим, что, по сути, это соответствует модели архитектуры Захмана, которая описана в 5.2. А во-вторых, с одной стороны, это список не является исчерпывающим, а с другой, на уровне описания архитектуры предприятия в целом, могут отсутствовать модели «нижних» уровней абстракции.

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

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

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

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

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

Действия

1. Бизнес-возможности

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

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

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

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

2. Функции

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

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

3. Процессы

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

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

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

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

4. Потоки ценности

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

Потоки ценности основываются на бизнес-возможностях и состоят из бизнес-процессов.

Результаты

5. Продукты

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

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

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

6. Бизнес-информация

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

Бизнес-информация также используется для оценки эффективности деятельности.

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

7. События

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

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

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

Действующие лица

8. Организационные единицы

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

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

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

Организационная единица – это должность. Структурные орг. единицы состоят из орг. единиц.

Каждая организационная единица – набор ролей. Собственно набор ролей и формирует орг. единицу.

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

9. Роли

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

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

Средства

10. Расположения

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

11. Рабочие места

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

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

12. Приложения

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

13. Ресурсы

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

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

14. Технологии

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

Участники

15. Внешние заинтересованные стороны

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

Заинтересованные стороны могут менять бизнес-возможности.

16. Внутренние заинтересованные стороны

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

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

Изменения

17. Программы

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

18. Проекты

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

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

Контуры метамодели

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

Это верно как для механических, информационных систем, так и систем, основанных на взаимодействии людей.

В метамодели бизнес-архитектуры мы называем такие циклы контурами.

Контур бизнес-архитектуры – циклическая последовательность элементов бизнес-архитектуры. Контур показывает взаимосвязи элементов в соответствии с базовыми бизнес-потребностями, коих мы выделяем 6:

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

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

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

1. Базовый контур

Базовый контур сформирован из трех больших блоков: ориентиры, участники и блок, сформированный из всех оставшихся блоков.

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

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

А заинтересованные стороны, в свою очередь, задают составляющие блока «Ориентиры». На этом контур замыкается.

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

2. Продуктовый контур

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

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

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

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

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

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

3. Контур управления

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

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

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

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

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

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

4. Реактивный контур

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

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

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

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

5. Контур изменений

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

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

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

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

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

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

6. Контур ресурсов

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

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

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

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

Изменения функций и процессов приводит к изменениям в ролевой и организационной структурах.

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

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

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

Появились вопросы по бизнес-архитектуре? Свяжитесь с нами!