Этапы мониторинга бизнес плана

Настольный справочник аналитика

Глава 2. Планирование и Мониторинг бизнес анализа

Приступим!

Солнечного и плодотворного времени дня, уважаемые коллеги!

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

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

Ну что же, введение сделано, рамки очерчены, и кофе налит, так что продолжаем!

Планирование и Мониторинг бизнес анализа

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

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

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

Рис. 2.1 – Диаграмма входов/выходов процесса планирования и мониторинга бизнес-анализа

2.1 План методов Бизнес-анализа

2.1.1 Цель

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

2.1.2 Описание

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

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

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

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

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

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

2.1.3 Входы

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

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

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

Рис.2.2 – Диаграмма входов/выходов плана подходов БА

2.1.4 Элементы

Почти все методологии разделяются на ПОП и ПОИ

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

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

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

.1 Сроки выполнения бизнес анализа

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

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

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

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

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

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

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

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

.3 Приоритезация требований

Определение того, как требования будут приоритезированны, и как будут использоваться эти приоритеты, определяющие рамки решения. Методы приоритезации требований обсуждаются в Приоритетность требований (6.1) . Также см. главу 5: анализ предприятия для получения информации о определения рамок решения и Глава 4: Управление Требованиями и коммуникациями, информацию об управлении рамками решения. Методы определения приоритетов будут также использоваться при выполнении Распределения требований (7.2) . ПОИ, как правило, уделяют большое внимание эффективным методам приоритезации требований, из-за небольшого объема задач, реализуемых в каждой итерации или релизе.

.4 Управление изменениями

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

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

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

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

.5 Бизнес-анализ процессов планирования

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

.6 Коммуникации с стэйкхолдерами

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

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

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

.7 Анализ требований и Инструменты управления ими

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

.8 Комплексность проекта

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

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

Уровень неопределенности требований частично зависит от области проекта.

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

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

2.1.5 Методы

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

Моделирование процесса (9.21): Процессные модели могут быть использованы для определения и документирования подходов бизнес-анализа.

Сквозной структурный контроль (9.30): Это может быть использовано, как средство проверки созданного, выбранного, или адаптированного подхода к бизнес-анализу.

2.1.6 Заинтересованные стороны

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

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

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

Тестер: Подход бизнес-анализа должен способствовать соответствующим мероприятиям по тестированию.

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

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

2.1.7 Выход

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

Продолжение грядет…

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

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

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

Мы желаем Вам постоянного совершенствования и развития и надеемся на скорую встречу.

Источник