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

Показывать лекцию целиком

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

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

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

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

2.1.1 Основные составляющие

Перечислим шесть основных видов деятельности, описанных в BABOK 3.0[2], которые и составляют область бизнес-анализа.

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

Рис. 5

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

2.1.2 Немного истории и об истоках

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

Методология — учение о методах, способах и стратегиях исследования предмета.

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

Оптимизация — процесс максимизации выгодных характеристик, соотношений и минимизации расходов[3].

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

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

Рис. 6

2.1.3 Структура и функции бизнес-анализа

В этом разделе продолжим ориентироваться на BABOK, как best practice, описывающую и регламентирующую рассматриваемый вид деятельности. Попытаемся представить бизнес-анализ в виде линейной схемы (рис. 7). Структура бизнес-анализа складывается из действий, которые выстраиваются в единый рабочий процесс. Это реализует задуманные изменения в виде конкретного результата, который может быть измерен, оценен и в дальнейшем усовершенствован. Главная цель проведения бизнес-анализа заключается в реализации изменений, которые помогут повысить ценность рассматриваемой деятельности. Перед тем как заниматься улучшениями, нужно понять, что необходимо улучшить. Объективность понимания может быть достигнута только тогда, когда бизнес-аналитик или другой специалист, выполняющий бизнес-анализ, оценит ситуацию, для которой планируется проводить изменения, с разных точек зрения, а достоверность оценки будет определяться сбалансированными позициями каждой из них. Отправной точкой бизнес-анализа должны быть идеи заказчиков (стейкхолдеров) и условия, зафиксированные в управленческих документах компании. Идеи заказчиков привносят реальный практический контекст желаемого результата (практика), а документы формируют теоретическое понимание того, в каком виде должна находиться организация в рассматриваемый момент времени (теория).

Рис. 7

Теория и практика в совокупности формируют представление о стимулах, движущих силах, мотивах и реальном состоянии анализируемой деятельности. На этом этапе появляется артефакт — бизнес-требования. Артефакты мы будем рассматривать немного позже. Стимулы и мотивы, дополненные точкой зрения сотрудников, выполняющих деятельность, в которую предполагается вносить изменения, позволяют сформировать более четкое представление необходимых усовершенствований, которые планируется провести. Более четкое представление формализуется в виде еще одного артефакта — пользовательских требований. Пользовательские требования должны адаптироваться и дополняться контекстом конкретной информационной системы. Вот тут бизнес-аналитик, в классическом понимании этого рода деятельности, заканчивает свою инженерию требований[4] и передает пальму первенства системному аналитику. После этого, если требуется, создается следующий артефакт — функциональные требования. Он дополняется техническими подробностями, необходимыми для реализации требований в конкретной информационной системе или наборе систем. Затем происходит реализация требований. Пальма первенства снова возвращается бизнес-аналитику, и завершающим шагом, после того как реализованы все необходимые изменения, является оценка выполненного решения. Если контекст реализованных изменений позволяет, через определенное время эксплуатации реализованных требований выполняется поиск возможностей улучшения. Теперь уделим внимание артефактам, которые появляются по ходу выполнения описанного процесса.

2.1.4 Артефакты деятельности

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

Рис. 8

Выделим следующие типы документов и акцентируем на них внимание:

Бизнес-требования.
Пользовательские требования.
Бизнес-правила.

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

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

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

Объем: не более 1–2 предложений.
В формулировке пользовательских требований должны быть приведены ответы на следующие вопросы:
- Кто выполняет действие? — Роль
- Когда выполняется действие? — Последовательность действий
- Какое действие выполняется? — Суть требования
- Для чего выполняется действие? — Результат
Не обязательно, но желательно отражать предусловия и постусловия выполнения действия.

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

Пользовательские требования формулируются как на привычном языке, так и в виде определенной нотации (use case). Нотации мы обсудим позже. Назначение пользовательских требований — разработка последовательности действий (в виде функционала) в информационной системе. Пользовательские требования описывают цели использования конкретной информационной системы пользователями[6]. Использование пользовательских требований возможно в ситуации, когда разработчик представляет поведение пользователя и может самостоятельно принять решение относительно деталей реализации функциональности. Если для конкретных условий рабочего проекта такое невозможно, значит, уровень пользовательских требований недостаточен для старта процесса разработки и нужно переходить на другой уровень описания требований. Об ответственной за это роли системного аналитика мы будем говорить далее.

Последний артефакт, который требуется обсудить, — бизнес-правила. Этот тип артефакта дополняет бизнес-требования на основе информации, регламентирующей деятельность компании в целом. Бизнес-правила определяют результат процесса в зависимости от контекста деятельности компании[7], являются продвинутым инструментом бизнес-анализа и становятся понятными только при наработанном навыке написания пользовательских и бизнес-требований. Они могут быть как внешними по отношению к компании, так и внутренними. Внешние бизнес-правила задаются и регулируются «над» («мета») уровнем функционирования организации. Примером источников бизнес-правил по отношению к предприятию являются:

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

Пример внешних бизнес-правил:

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

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

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

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

2.1.5 Как развиваться в этом направлении

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

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

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

Junior (начинающий специалист).
Middle (средний или практикующий специалист).
Senior (ведущий или продвинутый специалист).

Рис. 9

Путь Junior-специалиста начинается с момента осознанной практической деятельности. Это время становления и самоопределения на выбранном профессиональном пути. Junior-аналитик должен уметь (или быстро научиться) приносить пользу. Эта польза не будет иметь очень высокой практической значимости, но явится важным вкладом в общее дело процесса, проекта или командной работы. Представители организаций заказчиков (работодателей) и Junior-специалисты должны четко и однозначно понимать, что цель их совместного сотрудничества — сделать все для быстрого перехода на следующую ступеньку взаимоотношений (уровень Middle). Этот путь обычно занимает 1–2 года, но при условии постоянного самообучения и практики. Junior-специалист уже хорошо ориентируется в best practices и понимает, как их применять.

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

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

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

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

Описание таких ролей можно продолжать (Team Lead, технический директор, советник и т. д.). Нередко конкретная рабочая ситуация формирует роль в компании, которая как раз отвечает за интеграцию смежных с анализом процессов, и специалист занимает ее, принося пользу компании и себе. Главное — на всех этапах становления не стоит забывать о важности постоянного обучения и самообучения[10]. Именно при условии постоянного обучения (самообучения) и применения полученных навыков на практике ваше развитие и продвижение по профессиональной лестнице не заставят себя ждать.

Контрольные вопросы

Настало время провести калибровку и самопроверку по вопросам бизнес-анализа (рис. 9.1).

В чем состоит назначение бизнес-анализа?
1. Почему бизнес-анализ — востребованная сфера деятельности?
В чем состоит специфика использования бизнес-анализа?
1. Что выделяет бизнес-анализ как сферу деятельности?
2. Что роднит между собой анализ и бизнес-анализ?
В чем состоит уникальность контекста бизнес-анализа?
1. Какие факторы необходимы в контексте, чтобы использование бизнес-анализа стало востребованным?
2. Формирует ли бизнес-анализ собственный контекст?
Какова область применения бизнес-анализа?
1. Когда бизнес-анализ становится востребованным?
2. В каких областях бизнес-анализ неприменим?