Методы анализа бизнес идеи

Вступление

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

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

«Бизнес-анализ — дисциплина выявления деловых потребностей и нахождения решений деловых проблем»

Однако, есть и другое определение. Согласно своду знаний о бизнес-анализе (Business Analysis Body of Knowledge 2.0):

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

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

По сути

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

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

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

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

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

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

Метод определения критериев принятия и оценки

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

Согласно определению, критерии в данном методе разделяются на два класса:

• Критерии принятия (каким требованиям решение должно соответствовать, чтобы был смысл в его реализации);
• Критерии оценки (какими требованиями руководствоваться для выбора между несколькими решениями).

Данные критерии должны поддаваться тестированию, а в случае, если их нельзя протестировать — разбиваться на меньшие требования, которые можно протестировать. Стоит заметить, что имеет смысл ранжировать критерии по степени значимости.

Свод знаний по бизнес-анализу упоминает о достоинствах и недостатках метода.

Достоинства

• Для agile разработки может быть необходимым, чтобы все требования были выражены в форме, которая позволяет протестировать соблюдение этих требований;
• Критерии принятия необходимы, когда требования выражают договорные обязательства.

Недостатки

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

Мозговой штурм

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

Вопросы, которые могут найти ответ могут быть следующими:

• Как мы можем решить проблему сейчас (подручными средствами)?
• Какие препятствия стоят перед нами для выбора определенного решения или подхода?
• Что может вызвать задержку?
• Как мы можем решить проблему?

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

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

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

Преимущества

• Возможность сформировать большое количество идей за короткий промежуток времени;
• Включает креативное мышление;
• Может помочь снять напряжение между участниками совещания.

Недостатки

• В значительной степени зависит от желания людей участвовать в штурме, а также стоит учитывать межличностные отношения, которые могут ограничить активность участников;
• Участники не должны создавать дебатов вокруг идей, что предлагаются. Тоесть мозговой штурм может перерасти в дебаты и потраченное впустую время.

Анализ бизнес-правил

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

В целом, правила должны поддерживать цели организации, но их не должно быть слишком много.

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

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

Пример резолютивного правила (которое определяет поведение участников процесса):

Сотрудник должен получить письменное разрешение от директора департамента безопасности на использование на работе личного ноутбука.

Или

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

Пример структурного правила (которое определяет структуру знания, что позволяет определить правдивость, ложность или отношение к определенной категории):

Оплата принимается только безналичным расчетом.

Или

Индекс выполнения сроков определяется как EV / PV, где EV — освоенный объем, а PV — плановый объем.

Преимущества

• Четкое определение правил раздельно от процессов позволяет организации менять правила без изменения процессов.

Недостатки

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

Словарь данных и глоссарий

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

Так, метод выделяет две составляющие:

Глоссарий — список терминов и их определение.

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

Словарь данных состоит из простых элементов и составных.

Простые элементы содержат следующую информацию:

• Название — уникальное имя;
• Псевдонимы (aliases) — другие названия, которые используют заинтересованные стороны для этого понятия;
• Значения — возможные значения, которые может принимать элемент;
• Описание — определение элемента в контексте решения.

Составные элементы формируются из простых. Их структура следующая:

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

Диаграммы потоков данных

Тема диаграмм потоков данных воистину достойна отдельной статьи. Существуют различные нотации (например известная всем Гейна-Сарсона в BPWin, которую многие наверняка составляли в ВУЗах или Йордана). Но вернемся обратно.

Целью диаграмм потоков данных (DFD) является отображение входа, обработки, хранения и выхода информации из системы.

Диаграммы описывают:

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

Пример одной из таких диаграмм приведен ниже:

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

В целом же можно привести и другой пример:

Диаграммы рисовались в Dia, которая является образцом ужаса в отрисовке диаграмм под GNU/Linux.

Заключение

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

Ссылки:

1. Business Analysis Body of Knowledge Overview
2. Val IT