Бизнес анализ цели и задачи

Главная картинка статьи №14

Напоминание

Предыдущей статьей из серии «Настольный справочник аналитика», нами был начат «адаптированный пересказ» основополагающего труда по бизнес анализу, «Babok», который посвящен своду лучших практик данной дисциплины. Мы закончили на том, что ввели основные предпосылки к появлению «Babok» и представили на суд аудитории подготовленный, для русскоязычного специалиста, словарь, приведенный в рассматриваемом «талмуде» 🙂

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

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

О главе первой «Введение»

1.1. Что такое «Babok»?

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

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

Эта глава обеспечивает введение основных концептов в области бизнес — анализа и описывает структуру «Babok». С 2 по 7 главы определяются задачи, которые должны быть выполнены в результате бизнес — анализа. Глава 8 описывает компетенции, которые эффективно поддерживают уровень знаний и навыков бизнес – аналитика в его деятельности. Глава 9 описывает основной инструментарий для практики бизнес — анализа.

1.2 Что такое бизнес — анализ?

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

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

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

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

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

1.3 Ключевые понятия

1.3.1 Домены

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

1.3.2 Решения

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

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

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

1.3.3 Требования

Требование это (по IEEE 610.12-1990):

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

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

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

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

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

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

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

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

1.4 Области знаний

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

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

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

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

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

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

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

Взаимосвязи между областями знаний

Рисунок 1.1. Взаимосвязи между областями знаний

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

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

1.5 Задачи

Каждая область знаний описывает задачи, выполняемые бизнес — аналитиками для достижения цели этой области знаний. Каждая задача в «Babok» представлена в следующем формате:

1.5.1 Цель

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

1.5.2 Описание

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

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

Задача имеет следующие характеристики:

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

«Babok» не предписывает процесс или порядок, в котором задачи должны выполнятся. Некоторое упорядочивание задач неизбежно, так как выполнение определенных задач, дают результаты, которые требуются для выполнения других задач. Однако, важно иметь в виду, что «Babok» предписывает только то, что должно быть выполнено обязательно. Результат может быть неполным или задача может быть изменена и пересмотрена, что может повлиять на то, что её потребуется выполнять несколько раз. Итеративный или гибкий жизненный цикл может требовать того, чтобы задачи во всех областях знаний были выполнены одновременно. Жизненные циклы с ясными определенными фазами так же будут требовать выполнения задач из разных областей знаний, в каждой фазе. Задачи могут выполняться в разном порядке, при условии, что для выполнения задачи есть все необходимые ресурсы.

Описание задачи объясняет более подробно:

  • Почему задача выполняется?
  • Что такое задача?
  • Какие результаты должны быть достигнуты при её выполнении?

1.5.3 Вход

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

  • Ясно сформированное, вне рамок бизнес анализа
  • Задача, сформированная в ходе бизнес анализа

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

Схемы входа/выхода задач

Рис. 1.2 Схемы входа/выхода задач

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

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

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

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

Вместо прощания

Ну что же, глубоковажаемые Аналитики и Аналитикессы! 🙂

Соблюдая рамки приличий и ранее предложенный формат создания статей данной серии, мы говорим Вам «До свидания!».

На этот раз наше прощание будет недолгим. У нас уже заготовлены черновики следующего очерка о «Babok», в котором будет продолжен рассказ первой главы.

Поделиться:
Нет комментариев

Добавить комментарий

Ваш e-mail не будет опубликован. Все поля обязательны для заполнения.