✨Как описывать бизнес-процессы: мини-гайд

Привет, друзья! Если вы не знаете, как подступиться к задаче по описанию бизнес-процессов, то ловите шпаргалку ниже.

Формат описания зависит от цели и аудитории:

1. Для обучения сотрудников.
— Формат: кратко, ёмко, с визуальными инструкциями,
— Лайфхак: можно добавить чек-листы, скриншоты.

2. Для сертификации или аудита
— Формат: строго по стандарту, с  детальным описанием условий и действий (ну прям чтобы не придраться).

3. Для автоматизации
— Формат: не усложняйте. Если у вас не используется BPMN-движок, то стоит обойтись без исполняемого/аналитического уровней описания BPMN-диаграмм. Для согласования изменений с бизнесом стоит использовать упрощённый формат, а если вокруг нет ценителей BPMN, то — хоть простую блок-схему.
Если потребители результатов работы аналитика только разработчики, а диаграмму сопровождают детальные требования, то для визуального моделирования лучше использовать UML.

Возможные шаблоны:
— Шаблон для табличного описания БП
— Набор схем бизнес-процессов в формате BPMN
— Нотация BPMN. Практическое моделирование
— Пример блок-схемы


Предыдущий пост по теме:
Что такое бизнес-процесс?

Следующий пост по теме:
🗯Как научиться "видеть" бизнес-процессы

🗯Как научиться "видеть" бизнес-процессы

Привет, друзья! Если с описанием бизнес-процессов все ясно и есть куча источников, откуда эти знания можно почерпнуть (если есть вопросы или боли, пишите в комментарии или в бота), то с выявлением бизнес-процессов могут возникнуть сложности.

💡Как люди делятся на тех, кто при планировании недели представляет школьный дневник, и нет, так и среди аналитиков есть те олды, что при проектировании представляют в уме любой процесс в нотации IDEF0. Ловите лайфхак — умение мыслить "квадратами" позволит вам быстрее выявлять бизнес-процессы.

Любой хаос можно упорядочить, если определить:
— Входы (I): то, что поступает на вход (например, заявки, расходные материалы, сырье и т.д.);
— Выходы (O): результат выполнения бизнес-процесса (оказанная услуга, готовый материал, продукт и т.д.);
— Действия: шаги, которые преобразуют входы (I) в выходы (O) (обработка заявки, изготовление деталей и т.д.);
— Механизмы (M): то, что помогает преобразовать входы в выходы (инструменты и т.д.);
— Управление (C): то, что регламентирует выполнение процесса (стандарты, регламенты и т.д.).

Не стремитесь учить IDEF0, это просто один из способов научиться мыслить "квадратами".

✍️Рассмотрим на примере

Дано: аналитик Федя, вчерашний студент, должен составить карту бизнес-процессов в редакторском бюро.

С чего начать Феде?

1. С вопросов

— Чем занимается редакторское бюро?
Редактурой и корректурой.

— Кто его клиенты?
Авторы и издательства.

— Какую ценность они получают?
Готовый к публикации текст (статью, книгу).

2. Выявление процессов

Какие процессы необходимы для реализации таких услуг?

Продажи (реклама, пиар), редактура, корректура, ведение договоров, управление финансами, ведение бух и налогового учёта и т.д. Какие-то процессы могут быть отданы на аутсорс.

3. Фиксация модели процессов верхнего уровня

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

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

А верхнеуровневое описание удобнее фиксировать в формате диаграмм, выделяя "квадраты" со следующими метаданными:
— Вход: сырой текст от автора;
— Действия: корректорская и редакторская правки, согласование, вёрстка, согласование;
— Механизмы: сервис для работы с документами, эл. почта, чат в мессенджере;
— Управление: айдентика, стандарты оформления.

Примеры и шаблоны:
— Карта процессов верхнего уровня компании и матрица RACI c помощью drawio и google sheets
— Построение верхнероувневой модели деятельности компании на основе принципов системной инженерии. 
— Построение архитектуры бизнес-процессов

P.S. Надо было назвать пост "Аналитик Федя и упорядоченный хаос" 😅

📎Предыдущий пост по теме:
Как описывать бизнес-процессы: мини-гайд

🫠Аналитик vs люди

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

Как с этим бороться?
Задавать уточняющие вопросы.

Примеры таких вопросов:
— верно ли я понял(а)?
— пожалуйста, уточните, что вы имеете в виду под ... ?
— приведите, пожалуйста, пример?

Если вам кажется, что все очевидно и вы с таким не сталкивались, то просто приведу наглядный пример. Примите, пожалуйста, участие в опросе ниже 👇

Привет, друзья!

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

🤔И как же быть аналитику?

1. Избегать абстракций и расплывчатых терминов.

Например, заменить абстрактные понятия на конкретные величины (по согласованию с заказчиком):
• Пара-тройка → 3 рабочих дня (или 6 😅).
• Немного → 2.

2. Фиксировать договорённости письменно.

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

4. Задавать вопросы. Много вопросов (но в пределах разумного 😅).

❔️Примеры вопросов

Вопросы могут быть:

— открытыми (помогают выявить скрытые нюансы и подразумевают развернутый ответ):

Что конкретно Вы имеете в виду под парой-тройкой дней?  Пожалуйста, приведите пример

— закрытыми (фиксируют конкретные детали, подразумевают ответ или да, или нет):

Верно ли я понимаю, что 'пара-тройка' — это максимум 3 дня?

P.S. Получился не пост, а краткое пособие начинающего душнилы 😂

P.P.S. В следующей серии пособия душнилы читайте, как составить протокол встречи (meeting notes).

Друзья, привет!

Ещё одна заметка в копилку начинающего душнилы аналитика.

Как зафиксировать ответы на вопросы, если требований еще нет и еще нечего валидировать?

Если у вас была встреча, самый простой формат фиксации ответов и решений – это ведение протокола встречи (meeting notes).

В протоколе встречи указывается:
— когда была встреча;
— участники;
— повестка;
— принятые решения;
— дальнейшие действия (кто, когда и что должен сделать);
— открытые вопросы.

✅️После встречи:

1.  Разошлите протокол всем участникам (сам текст протокола или ссылку на страницу в confluence).

2. Если есть спорные моменты, то попросите подтверждение ("Подтвердите, что я вас верно понял по пункту 3") или сформулируйте вопрос ("Иван, пожалуйста, обратите внимание на пункт 3, мы договорились о трех или о пяти днях?")


📝 Пример протокола встречи

Дата: 27.02.2025

Участники: Пётр Петрович, Иван Иванов, Фёдор Фёдоров

Обсуждали:
— обратную связь по демо от заинтересованных лиц;
— сроки реализа.

Договорились:
1. перенести релиз до внедрения доработки для  бухгалтерии;
2. зафиксировать требования (@Фёдор Фёдоров, до 05.03.2025);
3. выкатить доработку через 2 недели.

Открытые вопросы:
@Петр Петрович, по п.3 — релиз планируем на 14.03.2025? Или перенесём с пятницы на понедельник?

P.S. заметка также будет полезна начинающим менеджерам проекта/продукта