Вступление
Поскольку на хабре не было найдено подобных статей, решил внести свой вклад, а также надеюсь, что кому-то эта информация пригодится в его дальнейшей деятельности. Итак, почему бизнес-анализ на сайте ИТ-направленности? Ответ будет несколько скучным для читателя – организации хотят оптимизировать свою работу и функционировать максимально эффективно. Во многих случаях (хотя и не во всех) выходом из ситуации является использование ИТ. Примером можно назвать автоматизацию работы сотрудников, более эффективное использование имеющихся ресурсов, оптимизация процессов и т. д. Вот так информационные технологии стали рядом в помощь.
Тема на самом деле довольно интересная и материалов на русском или украинском языках довольно мало. На мой взгляд, одной из причин этому есть относительно недавнее его появление. Хотя следует добавить, что методы, о которых мы будем вести речь рассматриваются по отдельности во многих учебниках на многих языках.
Определение бизнес-анализа возьмем из Википедии, чтобы не придумывать велосипед:
«Бизнес-анализ — дисциплина выявления деловых потребностей и нахождения решений деловых проблем»
Однако, есть и другое определение. Согласно своду знаний о бизнес-анализе (Business Analysis Body of Knowledge 2.0):
«Бизнес-анализ является набором заданий и методик, которые предназначены использоваться в качестве связующего звена между участниками бизнеса с целью понять структуру, правила и функции организации и предложить решения, которые позволят организации достичь поставленных целей».
В значительной степени источником для данной статьи служил как раз свод знаний о бизнес-анализе, который автор в данный момент активно изучает.
По сути
Для вступления достаточно и мы переходим непосредственно к самой сути статьи. Анализ, как метод научного познания, выражается изучением объекта путем разбиения его на составные части. Для бизнеса это наиболее выгодный метод, поскольку любой бизнес — это система, состоящая из составных частей, которые взаимодействуют между собой с целью получить прибыль (или в случае некоммерческих организаций — принести пользу или ценность). Наши заграничные коллеги в похожих случаях используют слово «value», которое словари трактуют как «стоимость» или «ценность».
Как мы можем анализировать бизнес? С какой стороны к нему подойти? На самом деле, подходить можно и нужно с разных сторон, чтобы построить целостное представление о его составляющих и их работе.
Для выполнения задач бизнес-анализа используются различные методы. Причем для выполнения одной задачи могут служить как один так и несколько методов. Довольно просто общих слов — перейдем к более конкретным вещам.
Наиболее часто используемыми на практике среди бизнес-аналитиков являются следующие методы:
- Определение критериев принятия и оценки;
- Мозговой штурм;
- Анализ бизнес-правил;
- Словарь данных и глоссарий;
- Диаграммы потоков данных;
- Моделирование данных;
- Анализ принятия решений;
- Анализ документов;
- Интервью;
- Метрики и ключевые показатели производительности;
- Анализ не функциональных требований;
- Моделирование организации;
- Отслеживание проблем;
- Моделирование процессов;
- Практические занятия по выявлению требований;
- Сценарии и варианты использования.
Данные методы могут включать в себя подмножества методов (как например метод моделирования данных).
Метод определения критериев принятия и оценки
Целью метода является определение критериев, которым должны соответствовать критерии для того, чтобы они были приняты заинтересованными лицами.
Согласно определению, критерии в данном методе разделяются на два класса:
- Критерии принятия (каким требованиям решение должно соответствовать, чтобы был смысл в его реализации);
- Критерии оценки (какими требованиями руководствоваться для выбора между несколькими решениями).
Данные критерии должны поддаваться тестированию, а в случае, если их нельзя протестировать — разбиваться на меньшие требования, которые можно протестировать. Стоит заметить, что имеет смысл ранжировать критерии по степени значимости.
Свод знаний по бизнес-анализу упоминает о достоинствах и недостатках метода.
Достоинства
- Для agile разработки может быть необходимым, чтобы все требования были выражены в форме, которая позволяет протестировать соблюдение этих требований;
- Критерии принятия необходимы, когда требования выражают договорные обязательства.
Недостатки
- Критерии оценки или принятия, выраженные договорными обязательствами может быть проблематично изменить в силу юридических или политических причин.
Мозговой штурм
Целью метода является генерирование новых идей, которые будут служить материалом для дальнейшего анализа.
Вопросы, которые могут найти ответ могут быть следующими:
- Как мы можем решить проблему сейчас (подручными средствами)?
- Какие препятствия стоят перед нами для выбора определенного решения или подхода?
- Что может вызвать задержку?
- Как мы можем решить проблему?
Для проведения мозгового штурма необходимо подготовить четкое определение темы для обсуждения, временных рамок, определить ожидания от данного обсуждения, определить критерии для оценки идей и выбрать соответствующих людей с определенным опытом в сфере, которая подлежит обсуждению.
В процессе проведения мозгового штурма все идеи должны предлагаться без обсуждения, критики или оценки и при этом участники штурма могут строить новые идеи на основе предложенных ранее. Кроме того, все идеи должны быть записаны.
В конце штурма необходимо обсудить идеи и выкинуть дублирующиеся. Результатом будет список идей, которые в той или иной мере должны ответить на поставленные вопросы.
Преимущества
- Возможность сформировать большое количество идей за короткий промежуток времени;
- Включает креативное мышление;
- Может помочь снять напряжение между участниками совещания.
Недостатки
- В значительной степени зависит от желания людей участвовать в штурме, а также стоит учитывать межличностные отношения, которые могут ограничить активность участников;
- Участники не должны создавать дебатов вокруг идей, что предлагаются. Тоесть мозговой штурм может перерасти в дебаты и потраченное впустую время.
Анализ бизнес-правил
Целью метода является выявление правил, которые определяют, ограничивают или разрешают определенную деятельность, работу или функционирование.
В целом, правила должны поддерживать цели организации, но их не должно быть слишком много.
- Правила должны быть определены терминами, которые будут понятны исполнителям;
- Правила не должны содержать описаний как они будут поддерживаться;
- Должны быть определены в декларативной форме на самом базовом уровне (тоесть не должны потом разбиваться на еще несколько);
- Правила должны быть отделены от процессов;
- Правила должны поддерживаться так, чтобы организация могла поддерживать их в актуальном состоянии.
Правила могут быть резолютивными или структурными, в зависимости от того, на чем они делают акцент.
Пример резолютивного правила (которое определяет поведение участников процесса):
Сотрудник должен получить письменное разрешение от директора департамента безопасности на использование на работе личного ноутбука.
Или
Перед слиянием в главную ветку разработчик должен протестировать код.
Пример структурного правила (которое определяет структуру знания, что позволяет определить правдивость, ложность или отношение к определенной категории):
Оплата принимается только безналичным расчетом.
Или
Индекс выполнения сроков определяется как EV / PV, где EV — освоенный объем, а PV — плановый объем.
Преимущества
- Четкое определение правил раздельно от процессов позволяет организации менять правила без изменения процессов.
Недостатки
- Правила могут вступать в конфликты друг с другом, что должно регулярно проверяться с появлением новых правил или изменением старых.
Словарь данных и глоссарий
Как свод знаний по бизнес-анализу, так и методология Val IT одной из основ для успешной деятельности организации ставят использование единой терминологии заинтересованными сторонами. Кроме того, это упрощает процесс дальнейшего анализа и сбора требований, поскольку участники понимают о чем именно идет речь и могут понятно и четко излагать свои требования.
Так, метод выделяет две составляющие:
Глоссарий — список терминов и их определение.
Словарь данных — словарь, который включает в себя список данных, их определение и допустимые или возможные значения. Словарь данных может также определять комбинации, в которые данные могут объединяться.
Словарь данных состоит из простых элементов и составных.
Простые элементы содержат следующую информацию:
- Название — уникальное имя;
- Псевдонимы (aliases) — другие названия, которые используют заинтересованные стороны для этого понятия;
- Значения — возможные значения, которые может принимать элемент;
- Описание — определение элемента в контексте решения.
Составные элементы формируются из простых. Их структура следующая:
- Последовательности — показывают порядок простых элементов (в последовательностях простые элементы всегда определяются в четко определенной последовательности);
- Повторения — показывают, что простые элементы могут несколько раз появляться в составном элементе;
- Опциональные элементы — могут присутствовать или отсутствовать в составном элементе.
Диаграммы потоков данных
Тема диаграмм потоков данных воистину достойна отдельной статьи. Существуют различные нотации (например известная всем Гейна-Сарсона в BPWin, которую многие наверняка составляли в ВУЗах или Йордана). Но вернемся обратно.
Целью диаграмм потоков данных (DFD) является отображение входа, обработки, хранения и выхода информации из системы.
Диаграммы описывают:
- Внешние сущности, которые получают информацию от системы или ее отдают ей;
- Процессы систем, которые преобразуют данные;
- Хранилища данных, где информация сохраняется определенное время;
- Потоки данных, по которым данные перемещаются между внешними сущностями, процессами и хранилищами данных.
Пример одной из таких диаграмм приведен ниже:
Звездочкой отмечен простой элемент данных, который является опциональным. Кстати, на диаграмме нужно было бы показать что результатом сообщения об ошибке должен быть ответ заказчику с исправленной ошибкой. Кстати, добавляйте свои примеры диаграмм — интересно было бы увидеть как другие описали бы тот же прием и обработку сообщений об ошибках.
В целом же можно привести и другой пример:
Диаграммы рисовались в Dia, которая является образцом ужаса в отрисовке диаграмм под GNU/Linux.
Заключение
Хотя мы и рассмотрели лишь часть из методов (которых существуют десятки), часть из них вы наверняка используете и надеюсь, что вам было интересно.
Ссылки:
