Ключевые концепции бизнес-анализа

Глава «Ключевые концепции бизнес-анализа» содержит в себе информацию, которая обеспечивает основу для другого контента, концепций и идей в рамках руководства BABOK. Данная глава обеспечивает бизнес-аналитиков базовым пониманием центральных идей, необходимых для понимания и применения Руководства BABOK в своей повседневной практике по бизнес-анализу.
Эта глава состоит из:

• Центральная концептуальная модель бизнес-анализа (BACCM): определяет концептуальную основу для профессии в бизнес-анализе.
• Основные термины: даются определения основных понятий, которые выделены из-за их важности для руководства BABOK.
• Схема классификации требований: определяются уровни или типы требований, которые помогают бизнес-аналитику и другим заинтересованным сторонам в классификации требований.
• Заинтересованные стороны (Stakeholders): определяются роли и характеристики групп или лиц, которые участвуют или затрагиваются в ходе деятельности по бизнес-анализу в пределах изменения.
• Требования и проектирование (дизайн): описываются различия между требованиями и дизайном и их важность, поскольку они относятся к бизнес-анализу.

Центральная концептуальная модель по бизнес-анализу

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

Шесть ключевых концепций в модели BACCM:

• Change (Изменение),
• Need (Потребность),
• Solution (Решение),
• Stakeholder (Заинтересованная сторона),
• Value (Ценность), и
• Context (Контекст).

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

BACCM может быть использована для:

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

Таблица «Модель BACCM»:

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

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

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

Рисунок «Модель BACCM»:

Ключевые термины

Бизнес-анализ

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

Информация по бизнес-анализу

Информация по бизнес-анализу относится к обширным и разнообразным наборам информации, которые бизнес-аналитики анализируют, трансформируют и формируют отчет. Информация по бизнес-анализу — это информация любого рода, любого уровня детализации, которая описывает что используется в качестве входных данных, что является выходными данными для работы по бизнес-анализу. Например, информация по бизнес-анализу включает в себя сбор результатов, требований, дизайнов, вариантов Решений, границ Решения и стратегии изменений.
Информация по бизнес-анализу имеет большое значение для обеспечения многих объектов, которые описаны в задачах и мероприятиях в руководстве BABOK, в том числе входных и выходных данных. Например, когда выполняется пункт «Управление информацией в Плане по бизнес-анализу», информация включает в себя все перечисленные выше примеры. Если Руководство BABOK описывает «План управления требованиями», в который включается важные выходные данные, такие как выявление результатов, варианты Решений, Стратегия изменений.

Дизайн (проектирование)

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

Предприятие

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

Организация

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

План

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

Требование

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

Риск

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

Схема классификации требований

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

• Бизнес-требования: высказывание целей, задач и результатов, которые описывают почему было инициировано изменение. Они могут применяться для всего предприятия, бизнес-области или для конкретной инициативы.
• Требования заинтересованных сторон: описывают потребности заинтересованных сторон, которые должны быть выполнены для удовлетворения бизнес-требований. Они могут служить в качестве моста между бизнес-требованиями и требованиями к Решению.
• Требования к Решению: описывают возможности и качества Решения, которые удовлетворяют требования заинтересованных сторон. Они обеспечивают соответствующий уровень детализации, позволяющий вести разработку и внедрение Решения. Требования к Решению можно разделить на две подкатегории:
  • Функциональные требования: описывают возможности, которые Решение должно иметь в терминах поведения и информации, которой Решение будет управлять;
  • Нефункциональные требования или требования к качеству обслуживания: не относятся непосредственно к поведению функциональности Решения, а скорее описывают условия, при которых Решение должно оставаться эффективным, или качества, которым Решение должно удовлетворять.
• Переходные требования: описывают возможности, которые Решение должно иметь и условия, которым Решение должно удовлетворять, чтобы обеспечить переход от текущего состояния к будущему состоянию, но которые будут не нужны после того, как изменения будут осуществлены. Эти требования отличаются от других типов требований, поскольку они носят временный характер. Переходные требования относятся к таким темам как — преобразование данных, обучение и обеспечение непрерывности бизнеса.

Заинтересованные стороны (стейкхолдеры)

Каждая задача включает в себя список заинтересованных сторон, которые скорее всего будут участвовать в исполнении этой задачи или которые будут затронуты при ее исполнении. Стейкхолдер — это человек или группа людей, с которыми бизнес-аналитик будет взаимодействовать напрямую или косвенно. Руководство BABOK не требует заполнения этих ролей для любой инициативы. Любая заинтересованная сторона может являться источником требований, допущений или ограничений.
Этот список не является исчерпывающим перечнем всех возможных классификаций заинтересованных сторон. Некоторые дополнительные примеры людей, которые вписываются в каждую эту общую роль, перечислены ниже приведенных определений. В большинстве случаев, там будет несколько ролей заинтересованных сторон в рамках каждой категории. Аналогичным образом, один человек может выполнять более одной роли.
Для целей Руководства BABOK, общий перечень заинтересованных сторон включает в себя следующие роли:

• business analyst (бизнес-аналитик),
• customer (клиент/заказчик),
• domain subject matter expert (Эксперт по предметной области Домена),
• end user (конечный пользователь),
• implementation subject matter expert (Эксперт по реализации в предметной области),
• operational support (операционная поддержка),
• project manager (менеджер проектов),
• regulator (регулятор/регулирующий орган),
• sponsor (спонсор),
• supplier (поставщик), и
• tester (тестировщик).

Business Analyst (Бизнес-аналитик)

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

Customer (Клиент/заказчик)

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

Domain Subject Matter Expert (Эксперт по предметной области Домена)

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

End User (Конечный пользователь)

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

Implementation Subject Matter Expert (Эксперт по реализации в предметной области)

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

Operational Support (Операционная поддержка)

Операционная поддержка отвечает за повседневное управление и техническое обслуживание системы или продукта.
Пока что отсутствует возможность определить список ролей операционной поддержки, которые подходят для всех инициатив, некоторые из наиболее распространенных ролей — это: операционные аналитики, аналитики продукта, поддержка пользователей (help desk), менеджер по релизам.

Project Manager (Менеджер проектов)

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

Regulator (Регулятор/регулирующий орган)

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

Sponsor (Спонсор)

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

Supplier (Поставщик)

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

Tester (Тестировщик)

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

Требования и дизайны

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

Таблица «Требования и дизайн»:

Заинтересованные лица могут предъявить потребность или Решение для предполагаемой необходимости. Бизнес-аналитик использует мероприятия, описанные в разделах «Выявление и взаимодействие», «Стратегический анализ», «Анализ требований и определение Дизайна», «Оценка решения» для того, чтобы трансформировать запрос в требование или дизайн. Независимо от того, что находится в центре внимания заинтересованных сторон, важность роли бизнес-аналитика заключается в постоянном задавании вопроса «Почему?». Например, «почему это требование или дизайн необходимо для создания ценности для предприятия и для облегчения достижения целей и задач предприятия?»

Рисунок «Требования и цикл проектирования»:

Перевод выполнил: Шамаев Иван (ivan.shamaev@gmail.com). Копирование материалов статьи запрещено!