Бизнес-аналитик собрал, описал и задокументировал требования, — все отлично. Вот только, когда дело доходит до реализации, оказывается, что у команды и заказчика остался 101 вопрос без ответа.
Частично найти ответы на эти вопросы помогает понимание техник моделирования бизнес-процессов. Как подготовиться к моделированию и какие ошибки чаще всего допускают бизнес-аналитики, рассказала Юлия Загоруйко, CEO в Risepreneur Украина, Agile и организационный коуч, спикер курса Supreme BA.
Как моделирование бизнес-процессов помогает сэкономить время заказчика и команды
Ответим на самые частые вопросы, которые студенты задают на лекциях по моделированию.
Бизнес-процесс — это последовательность работ, направленных на создание продукта или услуги для потребителей.
Моделирование — описание действий, участников с помощью языков моделирования (BPMN 2.0, UML, ARIS, IDEF и других) в графическом или текстовом виде. Собранные данные трансформируются в картинку или список, которые позволяют понять суть и структуру бизнес-процесса в целом.
Визуальная картина процессов и требований помогает:
- Проанализировать структуру и поведение системы, чтобы выявить взаимосвязи и зависимости.
- Визуально увидеть схему взаимодействий между модулями и участниками процесса и благодаря этому понять, что можно улучшить.
- Разобраться, почему что-то в системе не работает, выявить потенциальные проблемные зоны в действиях, ветках или событиях.
- Улучшить понимание существующей или будущей системы как бизнесом, так и командами разработки.
- Увидеть проблемные зоны и зоны роста еще на этапе проектирования.
Пример: вы моделируете работу отдела бизнес-анализа и ожидаете трех новых сотрудников. Как построить максимально эффективную структуру отдела? Опишите все бизнес-процессы в отделе, как их можно распределить между людьми, — и сможете увидеть зоны для масштабирования.
Для моделирования есть место на всех этапах SDLC цикла:
- На старте проекта модели помогают структурировать решения и разбавить требования. Когда требования написаны не только текстом, но и дополнены картинками, их легче обсуждать с клиентом.
- При подготовке артефактов ВА составляет описания для продуктов и находит пробелы.
- На этапе коммуникации моделирование помогает выстроить эффективное взаимодействие с целевой аудиторией.
Давайте рассмотрим основные системные модели:
- Функциональная — сценарии использования или Use Cases. Они помогают описать все функции системы с точки зрения пользователя. Если процесс нужно описывать со стороны клиента, в 90% случаев будем использовать Use Case.
- Объектная — структура объектов, связанных между собой с помощью определенных атрибутов и операций.
- Диаграмма взаимодействия — динамическая модель, которая показывает переходы внутри системы.
Функциональную модель выбирают для описания взаимодействия пользователя и системы. Объектную и динамическую модели используют для описания структуры и процессов внутри системы.
Подготовка к моделированию
Что аналитику нужно для того, чтобы приступить к моделированию? Многие говорят: «Выучить языки моделирования». Это не весь ответ, потому что подготовка включает и другие этапы:
- Собрать информацию. Вспомните базовые навыки бизнес-анализа, особенно, проведение интервью. Определите, какие работы нужно выполнить, как они связаны, кто является актерами. В этом значении «кто» — это не только люди, но и системы, триггеры, скрипты, устройства, которые выполняют работы.
- Прописать порядок выполнения работ. Четкая последовательность не обязательна — работы могут перемешиваться, распределяться или идти параллельно.
- Проверить доступ к ресурсам. Так как этот вопрос не отображается на модели и остается «фоновым», о нем часто забывают. Какие ресурсы могут понадобиться для моделирования? Например, информация, лицензии, согласования, инфраструктура под бизнес-процессы, может быть интеграция с другой системой, чтобы процесс стал триггером.
- Поставить цель. Какой результат вы ожидаете получить от конкретной работы в частности и от процесса? Уже на этапе подготовки определите зоны ответственности с помощью RACI матрицы. Она не является частью процесса моделирования, но помогает выявлять возможные пробелы.
После того, как вы ресурсы подготовлены и бизнес-цели определена, важно оценить доступные факторы и выбрать тип диаграммы для моделирования, к примеру BPMN или Activity.
Есть основные сценарии, по которым мы определяем, когда используется тот или иной тип диаграмм
Activity Diagram — это UML-диаграмма, на которой показаны действия, их связь и последовательность и используется:
- Для описания несложных бизнес процессов
- Для описания процессов, внутри системы
- Когда необходимо ответить на вопрос, как система должна выполнять заранее определенные функции.
Business process modeling notation (BPMN) – графическая нотация для моделирования бизнес-процессов. BPMN считают универсальным языком для моделирования, но активнее применяют в больших компаниях, где много процессов, которые нужно автоматизировать.
Плюсы BPMN:
- Описание процессов, исключающее двойные трактовки.
- Основа для эффективной автоматизации процессов.
- Общий язык для всех участников процесса.
- Подтверждение высокого уровня квалификации аналитика.
Можно ли заменить одну диаграмму другой? Универсального ответа нет — есть ряд кейсов, которые доказывают, что диаграммы взаимозаменяемы, но BPMN решает более сложные задачи по автоматизации, в ней больше возможностей, элементов, событий и типов задач.
Алгоритм моделирования
Независимо от языка моделирования, алгоритм состоит из четкой последовательности шагов:
- Определите задачу, которую нужно моделировать.
- Обозначьте начало и конец процесса, а также все задачи, сначала только на верхнем уровне.
- Укажите последовательность элементов в нужном порядке.
- Детализируйте модель.
- Определите исключения.
А нулевым пунктом советую взять правило: «Сначала выстроить модель в голове, а уже потом накладывать ее на бумагу или тулзу».
Основные ошибки в моделировании
Рассматривайте факапы как лучший способ чему-то научиться и не относитесь к себе слишком критично — я тоже допускала некоторые ошибки из этого списка и хочу ими поделиться:
Описание процесса ради описания
Эту ошибку допускают начинающие бизнес-аналитики, когда не ставят моделированию цель. Выучили, почитали нотацию, разобрались в языке, — и начали рисовать, вместо того чтобы понять, для чего вы моделируете и кто это будет использовать.
Неверно выбран язык моделирования процесса
Иногда случается, что команды из разных сторон описывают процессы разными языками, например, Activity и BPMN. Поэтому, если вы понимаете, что рисовать и читать модели будут больше одного человека, еще на старте убедитесь, что люди смогут прочитать вашу модель и ничего не нужно будет перерисовывать. Есть ли у команды знания UML или BPMN? Выберите язык, на котором модель будет понятна и читаема.
Слишком подробное описание бизнес-процесса
Старайтесь оставлять только главное. Что делать, если заказчик требует прорисовать процесс более детально? Например, сделайте диаграмму высокого уровня, а дальше расписывайте детализированно. Даже в начале можно максимально объединить подпроцессы в процессы. Несмотря на то, что в таком случае у вас получится много диаграмм, рекомендую максимально использовать и объединять.
Комментарии перекрывают тексты
Некрасивая ошибка, которая характеризует бизнес-аналитика не с лучшей стороны. Поэтому перед тем как поделиться диаграммой, конвертируйте формат и проверьте, чтобы работы не перекрывались описаниями или комментариями.
Недостаточный анализ моделируемой области
Сначала разберитесь, как работают текущие процессы и только после этого начинайте моделировать, иначе ошибок не избежать.
Забытая документация
Эта ситуация возникает, если не обсудили результат на выходе — не прописали, что сервис или продукт должны иметь какую-то документацию.
Разрозненные бизнес-процессы
Такая ошибка случается, когда вместо отлаженного процесса есть только отдельные действия и разные люди выполняют их по-своему. Например, участники команды пишут документацию в разных приложениях: Google Docs, Confluence или в описаниях задач в Jira. Самое сложное в этой ситуации — построить единый бизнес-процесс для всех из несочетаемых документов.
Расскажу недавний кейс. В текущих процессах компании были несоответствия. Сначала клиент говорил, что все правильно, но через три дня пришел ко мне снова: «Юля, ты была права. Исторически, у нас есть Redmine, которым во всей компании пользуются только два человека. И они вносят сумятицу в бизнес-процесс. С точки зрения процесса у нас все сложилось только тогда, когда мы выяснили, откуда появляются задачи и кто до сих пор пользуется Redmine.
Процессы в никуда
Нарисуйте сколько угодно красивые процессы — они не будут работать, если не подумать о реализации. На фоне каждой задачи, которую вы рисуете, должно быть понимание, как это будет работать. Если слишком уйти в процесс и забыть об удобстве и понятности, то возникает риск, что команда не разберется в нарисованном.
Я тоже совершала такую ошибку: рисуем статусы workflow в Jira, представляем, как тестировщики или разработчики будут проходить по этим статусам. Все выглядит последовательно и реалистично, а на презентации процессов слышу: «Да мы поседеем, пока дойдем до середины истории». Всегда держите в уме точку назначения процессов и стройте простые workflow. И если вам кажется, что упрощать уже некуда, попробуйте убрать еще одно действие 😉
Подводим итоги
Моделирование помогает визуально изобразить последовательности, связи бизнес-процессов, а также главных актеров и структуру. Этот инструмент помогает бизнес-аналитику в выявлении проблемных зон и зон роста, а в дальнейшем и в оптимизации работы команды.
Чтобы правильно смоделировать, нужно собрать информацию и ресурсы, прописать последовательность работ, поставить цель. Как избежать главных ошибок? Придерживайтесь алгоритма и учитесь моделировать процессы без софта — хороший специалист умеет рисовать решения даже на салфетке.
Ошибки — отличная возможность научиться и стать лучше, но если факапы мешают вам профессионально расти, на курсе Supreme BA вы получите недостающий опыт и сможете перейти от простого сбора и документирования требований к поиску самого оптимального для всех решения.