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

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

💡Как люди делятся на тех, кто при планировании недели представляет школьный дневник, и нет, так и среди аналитиков есть те олды, что при проектировании представляют в уме любой процесс в нотации 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. заметка также будет полезна начинающим менеджерам проекта/продукта

📚Подборка бесплатных материалов по BPMN


— Открытые лекции по BPMN (видео)

— Статьи по BPMN

— Практический курс BPMN

— BPMN Quick Guide

🔍 Как понять, что бизнес-процессу "плохо"

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

Аналитик Федя нарисовал карту бизнес-процессов, но теперь ломает голову: как понять, какому именно бизнес-процессу "плохо"?

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

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

Признаки "приболевшего" бизнес-процесса

1. Хитросплетение стрелочек на схеме — обычно это видно наглядно при моделировании БП (товарищи перфекционисты, пожалуйста, не воспринимайте буквально — только ради красоты схемы сами бизнес-процессы не стоит трогать 😅, тут речь идёт про монструозные схемы).

2. Сроки стремятся к бесконечности.

3. Нарушена логика.

4. Жалобы участников БП или жалобы на граничащий процесс — но будьте аккуратны: фраза «у нас всё сложно» звучит даже в компаниях с идеальными процессами. 

✍️ Рассмотрим на примере с редакторским бюро

Аналтик Федя разбирает основной бизнес-процесс по подготовке текста и фиксирует сроки:  

1. Отбор текста → 1 день.  
2. Корректура → 2 дня.  
3. Редактура → 2 дня.  
4. Корректура → 1 день (опять?!).  
5. Редактура → 1 день.
6. Передача на вёрстку → 5 минут.

Проблемы: 
— Корректура и редактура повторяются → тратится лишнее время. 
— Время на пункты 2-5: 6 дней (возможно, это много и необходимо выйти на более короткий срок без потери качества, т.е. это вопрос для исследования). 

Что может предложить Федя: 

— Программа-минимум: Поменять этапы местами (например: редактура → корректура → финальная проверка). 

— Программа-максимум: Внедрить ИИ для первичной проверки текста → сократить рутину.

Если возникает желание переписать все с нуля, то все равно стоит начинать с малого — ведь изменения нужно будет ещё и внедрять, а реакция людей на что-то новое не всегда однозначна 😱

📚На хабре опубликован перевод Мини-курса API-интерфейсы для самых маленьких:

— Глава 1. Введение в API-интерфейсы для самых маленьких

— Глава 2: API-протоколы. Мини-курс API-интерфейсы для самых маленьких

— Глава 3: Типы и форматы API

— Глава 4: API-аутентификация, часть 1 (базовая и ключевая)

— Глава 5: API-аутентификация, часть 2 (OAuth)

— Глава 6: Проектирование API

— Глава 7: Взаимодействие с API в режиме реального времени. API-интерфейсы для самых маленьких

— Глава 8: Реализация API. API-интерфейсы для самых маленьких


Автор оригинала: Брайан Кукси (Brian Cooksey), Zapier, перевел и дополнил данными Максим Филипп