IT & Моделирование бизнес-процессов. Что, как, зачем?

Всем привет! Поговорим об одном из hard skills хорошего аналитика: умение моделировать бизнес-процессы. В статье расскажу о трех вещах: зачем нужны процессы, как их описывать, свой опыт работы. Погнали!

Disclaimer: Описанный текст является моим личным мнением, основанным на собственном опыте и навыках (Я — старший бизнес-аналитик в команде разработки крупной российской компании)

Часть 1. Откуда берется бизнес-процесс? Модель AS IS/TO BE.

Утро. Ничего не предвещало беды, бизнес-аналитик занимался техдолгом, и вдруг он: новый проект. Заказчик прибегает с большими глазами и требует: нужен раздел в системе, который будет делать "А", потому что без этого невозможно жить. Проект начинают обсуждать, выделяют основные боли, и задают заказчику вопрос: а что ты хочешь в итоге?
Заказчик обычно отвечает: ну, у меня сотрудники работают вот так, а я хочу вот так "Б", сделайте мне в системе интерфейс с логикой, как я прошу.
То, что описал заказчик( «А" и "Б») — это модель AS IS/TO BE. Он пришел с описанием, как есть сейчас и как он хочет, чтобы было.
На самом деле все, что вам сказал заказчик — это AS IS — модель «как есть», модель текущего состояния.
Свойства AS IS модели:
Обычно уже существующий процесс (иногда костыльный, иногда неполный), который нужно улучшить: через ПО, людей, аналитику и другое. Через модель AS IS/TO BE можно выявить узкие места, которые затем улучшатся.
На этом этапе сбора информации аналитику следует описывать строго то, как работает сейчас, а не идеализированное представление заказчика. И до того момента, как вы не выясните всю информацию полностью, не бегите разрабатывать новые кнопки в вашей системе.
Лайфхак: чтобы с головой не окунаться в моделирование, сначала запишите текстом весь существующий процесс, потом согласуйте видение с заказчиком и можно идти дальше.
ЧАВО: А что, если существующего процесса нет? И он новый?
Ответ: Все, с чем приходит заказчик: с процессом в голове или с процессом на бумажке — это все AS IS, даже если он клянется вам, что это TO BE (как должно работать) .
Процесс AS IS описали и начинаем брейнштормить дальше. То, что мы описали в рамках грумингов с командой, заказчиком и обретшее здравый смысл — это процесс «как должно быть».
Свойства TO BE модели:
Улучшенная модель AS IS. Отображает те функции, которые помогут разработать целевое решение для проекта.
На этапе TO BE модели можно решить, посредством чего будет выполнен проект: иногда разработка — слишком дорогое удовольствие для задачи, которая не окупится.
Модель TO BE тоже можно описать словами, предварительно согласовать с заказчиком до того, как приступать к моделированию.
Итог: описали модель «как есть«, описали модель »как должно быть» и рассказали заказчику. Ему понравилось: начинаем моделировать.
P. S. Текстом описывать необязательно, обычно я это делаю в условиях сжатых сроков, так получается быстрее. Если моделировать, а потом вносить каждые правки и переделывать, может уйти один-два спринта, в условиях проекта на месяц-два — это непозволительная роскошь.
При этом я настоятельно рекомендую фиксировать все процессы в вашем проекте/продукте, даже если кажется, что это ерунда, а вы пишете требования для разработки — на самом деле это конечно не так.
Польза процессов:
Они хотя бы есть на бумаге. Никто не вспоминает, как это вообще работает, от чего улучшали. Это помогает при разработке новых функциональностей, в том числе экономит время: вам не надо каждый раз на новых встречах вспоминать, с чего все начиналось.
Пример из жизни:
В начале моей работы в компании мы делали интеграционный проект с смежными командами и когда уже проект был сделан, через месяц-два к нам пришли сотрудники компании, которые сказали, что все фигня. Информация приходит неполная. Долго разбирались, что не так: оказалось в начале проекта не собрали бизнес-процесс и мы не знали о большом блоке, который вел один человек в Excel несколько лет. Он уволился, спросил: кому-то может данные передать, все забили, доступ к файлу пропал, а мы потеряли важную часть процесса. В итоге потом смежная команда получила огромный проект на доработку, а все потому, что мы изначально не узнали, как работает процесс. Да, процессы — вещь сложная, иногда противная, но "Сила в правде. У кого правда, тот и сильнее(AS IS процесс)":) )

Часть 2. Средства моделирования процессов.
Визуализировать бизнес-процесс можно через три основных способа:
- текстовый (часть 1)
- табличный (вход-выход)
- графический (через нотации моделирования процессов)
Я использую все три в разных случаях.

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

Какую нотацию выбрать? Какие бывают?
Основных три: IDEF0, EPC, BPMN. В своей работе я использую нотацию BPMN 2.0.

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

Часть 3. Моделирование.

Один из вариантов описания процесса такой:

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

2. Как подробно описываем.
Определите, верхнеуровнево или низкоуровнево вы описываете процесс: верхнеуровневое описание обычно включает в себя подпроцессы нижнего уровня.
Например: процесс модуля планирования с заведением, согласованием и пересогласованием планов — верхнеуровневый процесс. Механика отправки Email-уведомлений участнику процесса согласования — процесс нижнего уровня.

3. Где начало и конец?
Определите, что является началом вашего процесса, что вы хотите получить в завершении.

4. Прямой сценарий.
Опишите прямую последовательность действий из пункта А в пункт Б и зафиксируйте их на процессе.

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

6. Фиксируем все на бумаге.

Пара статей на эту тему:

Бонус для тех, кто дочитал до конца: пример объема верхнеуровнего TO BE процесса с моей работы. На сбор информации AS IS и моделирование TO BE (в формате встречи и текстовой записи) ушло 4 рабочих часа и 5 человек: два представителя заказчика и три представителя команды. На моделирование ушло 4 рабочих часа (делала я одна) .

Всем спасибо!