Основы бизнес-анализа деятельности корпорации. Учебное пособие

–инструменты и оборудование;

–сырье и материалы;

–рабочие потоки;

–информационные потоки;

–участники (роли);

–документы;

–базы данных и программное обеспечение;

–показатели.

Вкаждом бизнес-процессе есть:

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

еепроцессов);

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

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

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

События передают управление от одной функции к другой и возникают в результате определенных действий участников процесса. Они могут быть также результатом исполнения функций. В отличие от функций, которые имеют некоторую продолжительность, события происходят моментально и являются констатацией свершившегося факта. При определении события в него включают объект, состояние которого описывает событие, и описание самого состояния. Можно привести следующие примеры событий: «Заказ получен», «Факс отправлен», «Товар доставлен». Любой процесс всегда начинается и заканчивается событием;

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

41

несколько.

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

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

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

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

Согласно одной из классификаций выделяют три вида биз- нес-процессов (табл. 2).

Таблица 2 - Виды бизнес-процессов

Бизнес-процесс имеет три основные характеристики - стоимость, длительность, уровень удовлетворенности потребителя (табл. 3).

42

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

Таблица 3 - Основные характеристики бизнес-процессов

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

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

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

-единичный технологический процесс - технологический процесс изготовления или ремонта изделия одного наименования независимо от типа производства;

-типовой технологический процесс - технологический процесс изготовления группы изделий с общими конструктивными

итехнологическими признаками;

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

Технологический процесс предполагает четко регламентированную последовательность действий, определяемую ГОСТами

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

43

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

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

Вопросы и задания для самоконтроля

1.Охарактеризуйте концептуальную модель бизнес-

анализа.

2.Назовите базовые понятия бизнес-анализа и раскройте

их.

3.Перечислите ключевые понятия и охарактеризуйте их взаимосвязи с базовыми понятиями.

4.Каковы особенности концепции бизнес-анализа и его отличия от комплексного анализа?

5.Дайте характеристику профессии бизнес-аналитика в соответствии с профессиональным стандартом «Бизнесаналитик».

6.Каковы основные умения бизнес-аналитика в соответствии с профессиональным стандартом?

7.Назовите основные знания бизнес-аналитика в соответствии с профессиональным стандартом.

44

ТЕМА 3. ТЕХНИКИ БИЗНЕС-АНАЛИЗА

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

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

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

BABOK Guide.

3.1 Критерии приемки и критерии оценки (acceptance and evaluation criteria)

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

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

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

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

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

45

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

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

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

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

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

46

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

Атрибутами ценности могут быть:

–характеристики производительности;

–удобство использования, безопасность, масштабируемость и надежность;

–способность предоставлять необходимую и конкретную информацию;

–способность выполнять или поддерживать определенные процессы;

–применимость решения в конкретных ситуациях и контекстах;

–наличие определенных функций и возможностей. Критерии приемки и оценки должны быть сформулирова-

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

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

3.2. Управление бэклогом (backlog management)

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

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

47

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

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

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

Могут быть установлены правила, которыми определяется, что и когда следует добавить в бэклог, например, если в проекте имеют место существенные дефекты.

При этом права на ведение бэклога продукта и бэклога спринта различаются. Бэклог продукта, как правило, составляет владелец продукта в начале разработки продукта на первом планировании спринта. Бэклог спринта создает команда разработчиков на каждом планировании нового спринта. Иными словами, бэклог продукта «живет» на протяжении всей разработки продукта, а бэклог спринта — на протяжении 1–4 недель (в течение одного спринта).

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

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

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

Приведем примеры элементов бэклога:

48

–пользовательские истории;

–функциональные и нефункциональные требования;

–варианты использования;

–описание дизайна;

–заказы клиентов;

–элементы риска;

–изменение требований;

–описание дефектов (неполадок);

–запланированный передел работы;

–техническое обслуживание;

–проведение представления проекта;

–формирование документации.

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

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

Таблица 4 - Пример составления бэклога в форме пользовательской истории

Пользовательская история

Как студент я хочу подать заявку на включение меня в спортивную сек-

цию, чтобы поддерживать здоровье

Как студент я хочу заполнить медицинскую информацию о себе, чтобы ру-

ководитель мог оценивать мое состояние здоровья

Как студент я хочу зарегистрироваться в системе, чтобы иметь возмож-

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

Как руководитель я хочу одобрить заявку, чтобы студент мог ходить в

спортивную секцию

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

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

49

вать в продукте) и оценку ценности (т.е. насколько данный элемент ценен для заинтересованной стороны).

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

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

Неоднородный список может включать в себя три типа элементов разного размера. Главное требование к таким элементам заключается в том, что разработчик должен иметь возможность реализовать его в продукте за один подход (спринт). Первый из таких элементов - это пользовательская история (user stories). Следующий элемент - эпик (epic) несколько больше. Его уже нельзя реализовать за один подход (спринт). И третий элемент — большие и наименее определенные пожелания заказчика, которые называются темами.

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

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

В простейшем виде бэклог продукта можно вести в обычных таблицах, например в Excel или в Google docs. Кроме того, можно использовать такие инструменты, как JIRA, Hygger и др.

Бэклог должен быть «живым», т.е. легко изменяемым по ходу разработки продукта, когда выясняются новые требования

50