Что такое сценарий бизнес процесса

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

---

NOTE

Материал находится в процессе корректировки!

---

Содержание

26.1. Введение

26.2. Полезность бизнес-сценариев

26.3. Создание бизнес-сценария

26.3.1. Полный процесс

26.3.2. Сбор

26.3.3. Анализ

26.3.4. Обзор

26.4. Содержание бизнес-сценария

26.5. Вклады в бизнес-сценарии

26.6. Бизнес-сценарии и TOGAF ADM

26.7. Рекомендации по разработке бизнес-сценариев

26.7.1. Общие рекомендации

26.7.2. Вопросы, требующие ответов для каждой области

26.8. Рекомендации по документированию бизнес-сценария

26.8.1. Текстовая документация

26.8.2. Модели бизнес-сценариев

26.9. Рекомендации для целей и стремлений

26.9.1. Важность целей

26.9.2. Важность SMART(умных) стремлений (Objectives)

26.9.3. Категории целей (Goals) и стремлений (Objectives)

26.10. Резюме

26.1. Введение

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

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

Бизнес-сценарий описывает:

• Бизнес-процесс, приложение или набор приложений, которые допускаются
  архитектурой

• Бизнес-среду и технологии

• Людей и вычислительные компоненты (называемые «акторами»),
  которые являются участниками сценария (выполняют его)

• Желаемый результат надлежащего исполнения

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

Хороший бизнес-сценарий также отвечает характеристикам «SMART». Он:

• Конкретный (Specific), определяющий потребности, которые должны
  быть реализованы в бизнесе

• Измеримый (Measurable), определяющий ясные показатели успеха

• Достижимый (Actionable):

  • Ясно сегментирует проблему

  • Обеспечивает фундамент для определения элементов и планирования
    решения

• Реалистичный (Realistic), в котором проблема может быть решена в
  границах физической реализуемости, времени и финансовых ограниченний

• Ограниченный во времени (Time-bound), который ясно
  формулирует когда истекает возможность для реализации решения

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

26.2. Полезность бизнес-сценариев

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

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

• Неясна важность решения бизнес-проблемы.

• Неясна значимость потенциальных решений.

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

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

26.3. Создание бизнес-сценария

26.3.1. Полный процесс

Создание бизнес-сценария включает следующие действия, как
проиллюстрировано на рисунке 26-1:

1. Идентификация, документирование и ранжирование проблемы, управляющей
   сценарием

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

3. Идентификация и документирование стремлений (желаемых результатов
   успешного решения проблем); достижение «SMART»

4. Идентификация субъектов-людей (участников) и их места в
   бизнес-модели

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

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

7. Проверка соответствия цели и уточнение (только в случае
   необходимости)

Рисунок 26‑1. Создание бизнес-сценария

Обычно, бизнес-сценарий разрабатывается итеративно в фазах
сбора, анализа и фиксации информации в сценарии.

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

Три фазы разработки бизнес-сценария представлены на рисунке 26-2 и
описаны подробно ниже.

Рисунок 26‑2. Фазы разработки бизнес-сценария

26.3.2. Сбор

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

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

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

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

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

26.3.3. Анализ

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

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

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

• Заинтересованные лица

• Субъекты-люди

• Субъекты-компьютеризированные системы

• Проблемы

• Стремления

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

26.3.4. Обзор

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

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

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

26.4. Содержание бизнес-сценария

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

Есть два основных типа информационного наполнения: графика (модели) и
текстовое описание.

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

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

СОДЕРЖАНИЕ
ПРЕДИСЛОВИЕ
	ОСНОВНЫЕ ПОЛОЖЕНИЯ ДЛЯ РУКОВОДСТВА
	ДОРОЖНАЯ КАРТА ДОКУМЕНТА
БИЗНЕС-СЦЕНАРИЙ
	ОБЗОР БИЗНЕС-СЦЕНАРИЯ
		ПРЕДПОСЫЛКИ СЦЕНАРИЯ
		НАЗНАЧЕНИЕ СЦЕНАРИЯ
		ОПРЕДЕЛЕНИЯ/ОПИСАНИЯ ИСПОЛЬЗУЕМЫХ ТЕРМИНОВ
	ПРЕДСТАВЛЕНИЯ СРЕДЫ И ПРОЦЕССОВ
		ДЕЛОВАЯ СРЕДА
			Клиентура
		ОПИСАНИЯ ПРОЦЕССОВ
			Процесс «a»
			и т.д.
		ТЕХНИЧЕСКАЯ СРЕДА
			Техническая среда «a»
			и т.д.
		АКТОРЫ, ИХ РОЛИ И ОТВЕТСТВЕННОСТИ
		АКТОРЫ-КОМПЬЮТЕРИЗОВАННЫЕ СИСТЕМЫ И ИХ РОЛИ
		СВЯЗЬ КОМПОНЕНТОВ И ПРОЦЕССОВ
		АКТОРЫ-ЛЮДИ И ИХ РОЛИ
		СВЯЗЬ ЛЮДЕЙ И ПРОЦЕССОВ
		АНАЛИЗ ИНФОРМАЦИОННОГО ПОТОКА
		ПРИНЦИПЫ И ОГРАНИЧЕНИЯ
			Принципы IT
			Ограничения
		ТРЕБОВАНИЯ
	АНАЛИЗ БИЗНЕС-СЦЕНАРИЯ
		СВОДКА ПРОБЛЕМ
			Проблемы (Issues)
			Стремления (Objectives)
	РЕЗЮМЕ
	ПРИЛОЖЕНИЯ
		ПРИЛОЖЕНИЕ A: БИЗНЕС-СЦЕНАРИИ – ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ
		ПРИЛОЖЕНИЕ B-n: ЗАМЕТКИ C СЕМИНАРА ПО БИЗНЕС-СЦЕНАРИЮ

26.5. Вклады в бизнес-сценарий

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

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

Рисунок 26‑3. Относительные вклады в бизнес-сценарий

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

26.6. Бизнес-сценарии и TOGAF ADM

Наиболее заметно бизнес-сценарии фигурируют в начальной фазе Метода
Разработки Архитектуры (Architecture Development Method / ADM), фазе Архитектурного Видения, когда они
используются для определения соответствующих бизнес-требований и
выстраивании согласованности с руководством от бизнеса и другими заинтересованными
сторонами.

Однако, бизнес-требования используются во всех фазах цикла ADM, как это
показано на рисунке 26-4.

Рисунок 26‑4. Значимость требований во всех фазах ADM

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

26.7. Рекомендации по разработке бизнес-сценариев

26.7.1. Общие рекомендации

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

• Выделите время, понаблюдайте и запишите как они работают сегодня

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

• Выясните критические бизнес-правила у специалистов по проблемной
  области

• Сосредоточьтесь на том, какие потребности должны быть реализованы и
  как это должно быть достигнуто

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

26.7.2. Вопросы, требующие ответов для каждой области

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

Идентификация, документирование и ранжирование проблем

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

Если проблема слишком специфична или задает вопрос «как»:

• Поднимите красный флаг

• Задайте вопрос: «Почему Вы должны следовать этим путем?»

Если проблема слишком неопределенна или неприменима на практике:

• Поднимите красный флаг

• Задайте вопрос: «Что Вы получите или будете в состоянии
  делать, если эта проблема будет решена?»

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

• Где Вы испытываете эту специфическую проблему? В каком
  бизнес-процессе?

• Когда Вы сталкиваетесь с этой проблемой? В начала процесса, в
  середине или в конце?

Задайте вопросы, которые помогают идентифицировать затраты на решение проблемы:

• Вы оценивали затраты, связанные с этой проблемой? Если оценивали,
  каковы они?

• Имеет ли проблема скрытые затраты? Если да, каковы они?

• Покрывают ли затраты на решение этой проблемы какие-то другие затраты? Если да,
  что и сколько?

• Связаны ли проблема с низким качеством или неэффективностью в организации?

Идентификация бизнес- и технологической среды

Вопросы, касающиеся бизнес-среды:

• Какие ключевые процессы страдают от проблем? Какие главные шаги
  должны быть предприняты?

• Расположение/масштаб внутренних департаментов бизнеса?

• Расположение/масштаб внешних бизнес-партнеров?

• Какие определенные бизнес-правила и регулирующие положения имеют
  отношение к ситуации?

Вопросы, касающиеся текущей технологической среды:

• Какие технологические компоненты уже предусмотрены для разрешения
  этой проблемы?

• Есть ли какие-либо технологические ограничения?

• Применяются ли какие-либо технологические принципы?

Идентификация и документирование стремлений

В достаточной ли мере каждое утверждение »что» поддерживается разъяснением
»почему»? Если нет, попросите измеримое объяснение в следующих
областях:

• Возврат от инвестиций

• Масштабируемость

• Потребности в производительности

• Соответствие стандартам

• Простые в использовании метрики

Идентификация акторов-людей и их места в бизнес-модели

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

• Пользователь компьютера с компьютером

• Пользователь телефона с телефоном

• Расчетчик зарплаты с системой расчета зарплаты

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

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

• Разработчик

• Ремонтник

• Оператор

• Администратор

• Пользователь

Идентификация компьютерных акторов и их места в технологической модели

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

Документирование ролей, ответственностей, метрик успеха, необходимых сценариев

При определении роли, задайте такие вопросы:

• Какие основные задачи актора?

• Должен ли актор читать/писать/изменить информацию?

• Должен ли актор сообщать системе о внешних изменениях?

• Хочет ли актор быть информированным о неожиданных изменениях?

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

Имеется ли достаточная информация для идентификации, кто/как может
выполнить требование? Если нет, требуется более глубокое исследование.

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

26.8. Рекомендации по документированию бизнес-сценария

26.8.1. Текстовая документация

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

В приложениях:

• Подробно зафиксируйте все важные данные о бизнес-сценарии:

  • Описание и объяснение ситуации

  • Все измерения

  • Все роли акторов и вложенные измерения

  • Все необходимые сервисы

• Зафиксируйте критические шаги между акторами, которые разрешают
  ситуацию, и упорядочите взаимодействия

• Представьте релевантную информацию обо всех акторах:

  • Разделение ответственности среди акторов

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

  • Технические требования для сервиса должны иметь приемлемое
    качество

В основной части бизнес-сценария:

• Обобщите все соответствующие данные, детально представленные в
  приложениях

26.8.2. Модели бизнес-сценариев

• Нужно помнить цель использования модели:

  • Зафиксировать представления бизнеса и технологии в графической
    форме

  • Помочь в понимании

  • Дать отправную точку для подтверждения требования

  • Связать акторов и взаимодействия

• Диаграммы должны быть ясными и чёткими:

  • Нельзя помещать слишком много на одну диаграмму

  • Более простые диаграммы проще понять

• Число диаграмм для простой навигации:

  • Поддерживайте каталог диаграмм, чтобы избежать дублирования

26.9. Рекомендации для целей и стремлений

26.9.1. Важность целей

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

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

26.9.2. Важность SMART (умных) стремлений

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

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

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

Вместо этого, мы представляем здесь некоторый пример стремлений SMART.

Пример создания «SMART» стремлений

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

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

Чтобы сделать это стремление «SMART», мы должны ответить на вопросы,
является ли это стремление определенным, измеримым, понятным,
реалистичным и ограниченным во времени, и затем переформулировать
стремление, если потребуется.

Далее зафиксирован анализ этих критериев для заданного стремления:

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

• Измеримое: Как указано выше, стремление является измеримым, но
  могло бы быть более конкретным. Второе предложение может быть
  исправлено, например: «Это приведет к увеличению
  пользовательской эффективности на 10 % и уменьшению пользовательских
  ошибок ввода заказов на 20 %, что, в свою очередь, приведет к
  снижению затрат на ввод и корректировки на 5 %.»

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

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

• Ограниченное во времени: Стремление, как оно сформулировано, не
  ограничено во времени. Чтобы оно стало ограниченным во времени, в
  стремлении можно указать: «К концу 3-го квартала обеспечить
  непротиворечивый…».

Итоговое SMART стремление больше походит на следующее (помните, что
это всего-лишь пример):

«К концу 3-го квартала обеспечить непротиворечивый пользовательский
интерфейс через устройства пользовательского ввода, обеспечивающие
подобные функциональные возможности, который гарантирует всем
пользователям, использующим эти устройства, что все доступные для
пользователя функции и сервисы будут появляться и вести себя подобным,
предсказуемым образом независимо от приложения или сайта. Это приведет к
увеличению пользовательской эффективности на 10 % и уменьшению
пользовательских ошибок ввода заказов на 20 %, что, в свою очередь,
приведет к снижению затрат на ввод на 5 %.»

26.9.3. Категории целей и стремлений

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

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

Цель: Улучшить производительность бизнес-процесса

Улучшение бизнес-процесса может быть достигнуто через реализацию
следующих стремлений:

• Увеличенная производительность процесса

• Непротиворечивое качество результата

• Предсказуемые производственные издержки

• Увеличенное повторное использование существующих процессов

• Сокращенное время передающей бизнес-информации от одного процесса до
  другого процесса

Цель: Уменьшить затраты

Улучшение затрат может быть достигнуто через реализацию следующих
стремлений:

• Более низкие уровни избыточности и дублирования активов всюду по
  предприятию

• Уменьшенная зависимость от внешних поставщиков услуг IT по
  интеграции и настройке

• Более низкие затраты на обслуживание

Цель: Улучшить бизнес-операции

• Улучшение бизнес-операций может быть достигнуто через реализацию
  следующих стремлений:

• Увеличенный бюджет, доступный для новых бизнес-функций

• Уменьшенные затраты на ведение бизнеса

• Уменьшенное время выхода на рынок для продуктов или услуг

• Улучшенное качество услуг клиентам

• Улучшенное качество бизнес-информации

Цель: Улучшить эффективность управления

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

• Увеличенная гибкость бизнеса

• Более короткое время на принятие решений

• Более высокое качество решений

Цель: Снизить риски

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

• Простота реализации новых процессов

• Уменьшенные ошибки ввода в бизнес-процессы через сложные и
  неисправные системы

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

Цель: Улучшить эффективность организации IT

Улучшение эффективности IT-организации может быть достигнуто через
реализацию следующих стремлений:

• Увеличенный выпуск новых проектов

• Уменьшенное время для выпуска новых проектов

• Уменьшенные затраты на выпуск новых проектов

• Уменьшенное время прерывания обслуживания при выпуске новых проектов

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

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

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

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

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

Цель: Увеличить производительность пользователей

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

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

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

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

Цель: Улучшить мобильность и масштабируемость

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

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

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

Цель: Улучшить функциональную совместимость

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

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

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

Цель: Увеличить независимость от поставщика

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

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

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

Цель: Сократить затраты жизненного цикла

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

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

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

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

• Сокращенные затраты на обучение: общие системы и непротиворечивые
  человеческо-машинные интерфейсы (Human Computer Interfaces –
  HCI) обеспечивают сокращение затрат на обучение.

Цель: Улучшить защищенность

Защищенность информации в организации может быть улучшена через
реализацию следующих стремлений:

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

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

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

• 25%-ое сокращение запросов в службу поддержки, касающихся вопросов
  безопасности.

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

Цель: Улучшить управляемость

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

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

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

26.10. Резюме

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

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

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