IAMPM
65000
+38 (091) 481 01 38+7 (495) 128 58 05info@iampm.club
BA

Моделирование бизнес-процессов: советы для IT Business Analysts

15 апреля 2021

  • Автор: Юлия Загоруйко

  • Сложность: норм

  • Время: 5 мин

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

Частично найти ответы на эти вопросы помогает понимание техник моделирования бизнес-процессов. Как подготовиться к моделированию и какие ошибки чаще всего допускают бизнес-аналитики, рассказала Юлия Загоруйко, CEO в Risepreneur Украина, Agile и организационный коуч, спикер курса Supreme BA.

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

моделирование 1

Ответим на самые частые вопросы, которые студенты задают на лекциях по моделированию.

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

Моделирование — описание действий, участников с помощью языков моделирования (BPMN 2.0, UML, ARIS, IDEF и других) в графическом или текстовом виде. Собранные данные трансформируются в картинку или список, которые позволяют понять суть и структуру бизнес-процесса в целом.

Визуальная картина процессов и требований помогает: 

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

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

Для моделирования есть место на всех этапах SDLC цикла:

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

Давайте рассмотрим основные системные модели:

  1. Функциональная — сценарии использования или Use Cases. Они помогают описать все функции системы с точки зрения пользователя. Если процесс нужно описывать со стороны клиента, в 90% случаев будем использовать Use Case.
  2. Объектная — структура объектов, связанных между собой с помощью определенных атрибутов и операций. 
  3. Диаграмма взаимодействия — динамическая модель, которая показывает переходы внутри системы. 

Функциональную модель выбирают для описания взаимодействия пользователя и системы. Объектную и динамическую модели используют для описания структуры и процессов внутри системы.

Подготовка к моделированию

Что аналитику нужно для того, чтобы приступить к моделированию? Многие говорят: «Выучить языки моделирования». Это не весь ответ, потому что подготовка включает и другие этапы:

  • Собрать информацию. Вспомните базовые навыки бизнес-анализа, особенно, проведение интервью. Определите, какие работы нужно выполнить, как они связаны, кто является актерами. В этом значении «кто» — это не только люди, но и системы, триггеры, скрипты, устройства, которые выполняют работы. 
  • Прописать порядок выполнения работ. Четкая последовательность не обязательна — работы могут перемешиваться, распределяться или идти параллельно. 
  • Проверить доступ к ресурсам. Так как этот вопрос не отображается на модели и остается «фоновым», о нем часто забывают. Какие ресурсы могут понадобиться для моделирования? Например, информация, лицензии, согласования, инфраструктура под бизнес-процессы, может быть интеграция с другой системой, чтобы процесс стал триггером.
  • Поставить цель. Какой результат вы ожидаете получить от конкретной работы в частности и от процесса? Уже на этапе подготовки определите зоны ответственности с помощью RACI матрицы. Она не является частью процесса моделирования, но помогает выявлять возможные пробелы.

После того, как вы ресурсы подготовлены и бизнес-цели определена, важно оценить доступные факторы и выбрать тип диаграммы для моделирования, к примеру BPMN или Activity. 

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

Activity Diagram — это UML-диаграмма, на которой показаны действия, их связь и последовательность и используется:

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

Business process modeling notation (BPMN) – графическая нотация для моделирования бизнес-процессов. BPMN считают универсальным языком для моделирования, но активнее применяют в больших компаниях, где много процессов, которые нужно автоматизировать.

Плюсы BPMN:

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

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

Алгоритм моделирования

моделирование 2

Независимо от языка моделирования, алгоритм состоит из четкой последовательности шагов:

  1. Определите задачу, которую нужно моделировать. 
  2. Обозначьте начало и конец процесса, а также все задачи, сначала только на верхнем уровне. 
  3. Укажите последовательность элементов в нужном порядке.
  4. Детализируйте модель.
  5. Определите исключения. 

А нулевым пунктом советую взять правило: «Сначала выстроить модель в голове, а уже потом накладывать ее на бумагу или тулзу».

Основные ошибки в моделировании

Рассматривайте факапы как лучший способ чему-то научиться и не относитесь к себе слишком критично — я тоже допускала некоторые ошибки из этого списка и хочу ими поделиться:

Описание процесса ради описания

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

Неверно выбран язык моделирования процесса

Иногда случается, что команды из разных сторон описывают процессы разными языками, например, Activity и BPMN. Поэтому, если вы понимаете, что рисовать и читать модели будут больше одного человека, еще на старте убедитесь, что люди смогут прочитать вашу модель и ничего не нужно будет перерисовывать. Есть ли у команды знания UML или BPMN? Выберите язык, на котором модель будет понятна и читаема.

Слишком подробное описание бизнес-процесса

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

Комментарии перекрывают тексты

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

Недостаточный анализ моделируемой области

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

Забытая документация

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

Разрозненные бизнес-процессы

Такая ошибка случается, когда вместо отлаженного процесса есть только отдельные действия и разные люди выполняют их по-своему. Например, участники команды пишут документацию в разных приложениях: Google Docs, Confluence или в описаниях задач в Jira. Самое сложное в этой ситуации — построить единый бизнес-процесс для всех из несочетаемых документов. 

 Расскажу недавний кейс. В текущих процессах компании были несоответствия. Сначала клиент говорил, что все правильно, но через три дня пришел ко мне снова: «Юля, ты была права. Исторически, у нас есть Redmine, которым во всей компании пользуются только два человека. И они вносят сумятицу в бизнес-процесс. С точки зрения процесса у нас все сложилось только тогда, когда мы выяснили, откуда появляются задачи и кто до сих пор пользуется Redmine.

Процессы в никуда 

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

Я тоже совершала такую ошибку: рисуем статусы workflow в Jira, представляем, как тестировщики или разработчики будут проходить по этим статусам. Все выглядит последовательно и реалистично, а на презентации процессов слышу: «Да мы поседеем, пока дойдем до середины истории». Всегда держите в уме точку назначения процессов и стройте простые workflow. И если вам кажется, что упрощать уже некуда, попробуйте убрать еще одно действие 😉

Подводим итоги 

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

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

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

Юлия Загоруйко

Юлия Загоруйко

Co-Founder в Gallantra Business Intelligence с 15 годами опыта в IT. Сертифицированный Agile Professional и SAFe specialis. Умеет работать с самыми сложными заказчиками и анализировать запутанные требования. Спикер курсов I am BA и Supreme BA.