Как описать бизнес-процесс: пошаговый разбор от начала до результата

• Бизнес-процессы

К вопросам по статье

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

Как выбрать границы

Сформулируйте процесс действием и результатом: например, обработать входящий запрос до решения о подготовке предложения. Укажите, какое событие запускает работу и кто получает итог. «Продажи» — название функции; для обследования его обычно нужно сузить до понятного маршрута.

Определите единицу прохождения: обращение, заказ, документ или сотрудник. Это поможет не смешать несколько параллельных историй. Один клиент способен иметь несколько заказов, а у одного заказа — несколько документов. Схема должна показывать, что именно движется по выбранному маршруту.

Как собрать описание

1. Возьмите реальный обезличенный пример завершённой работы.
2. Восстановите шаги и участников по документам и событиям.
3. Запишите вход и результат каждого действия.
4. Отметьте ожидания и передачи между ролями.
5. Добавьте частые возвраты, отказы и отмены.
6. Проверьте маршрут с исполнителями и владельцем процесса.

Для первой версии подходят короткий текст и список шагов. Когда требуется формальная схема, можно использовать BPMN; спецификация OMG задаёт её элементы. Нотация помогает выражать договорённость, но не создаёт её вместо участников.

Паспорт процесса: короткая рамка до подробного разбора

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

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

Рабочий процесс самого обследования

Вход: цель анализа, несколько завершённых случаев, доступные документы и представители ролей. Участники: владелец процесса, исполнители, получатели результата и аналитик. Выход: согласованная карта, список исключений, решения по противоречиям и требования к дальнейшему изменению.

Сначала выберите конкретный случай. Попросите показать, откуда он пришёл и чем закончился. Не ограничивайтесь общей фразой «всегда делаем так»: у людей есть привычные сокращения и неописанные обходы. Реальная запись помогает восстановить последовательность и задать уточняющие вопросы.

Затем пройдите действия по времени. На каждом шаге назовите полученные данные, исполнителя, действие и результат. Отделите работу от ожидания. Два часа расчёта и несколько дней ожидания исходных данных требуют разных решений, хотя в общем рассказе могут называться одной неделей подготовки.

Далее найдите передачи. Автор считает шаг завершённым после отправки, а получатель — только после проверки комплектности. Между этими событиями может находиться неуправляемое ожидание. Нужно показать его явно и определить владельца, а не соединять роли одной стрелкой без смысла принятия.

После основного маршрута добавьте частые отклонения. Отказ, неполные сведения, исправление документа и отсутствие сотрудника помогают проверить модель. Если они не помещаются в одну читаемую схему, используйте связанное описание. Не стоит превращать первую страницу в плотный плакат со всеми редкими событиями компании.

Как описывать отдельный шаг

Хороший шаг содержит действие и предмет: проверить комплектность запроса, согласовать условия, передать результат. Названия «обработка» или «работа с клиентом» слишком широкие, если по ним нужно определить ответственность и требования. Уточняйте только до уровня, необходимого для текущего решения.

Для шага определите наблюдаемый результат. Если сотрудник проверил сведения, что изменилось: появилась отметка, выбран маршрут, отправлен запрос уточнения? Важно иметь способ отличить выполненное действие от ожидания. При этом не каждый шаг обязан создавать новый документ; достаточно принятого свидетельства результата.

Не смешивайте действие и внутреннюю реализацию. «Нажать синюю кнопку» не объясняет смысл и устареет после изменения интерфейса. В процессе указывают, что подтверждается, а пользовательская инструкция показывает, как это выполнить в конкретной системе. Связь между ними сохраняется, но документы решают разные задачи.

Эта таблица раскрывает больше, чем список названий. По ней можно задать вопросы к данным, правам и автоматизации. Если вход шага не соответствует выходу предыдущего, найдена потенциальная проблема передачи. Не нужно маскировать её дополнительной общей стрелкой: требуется уточнение процесса.

Как проверять факты и расхождения интервью

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

Для существенного утверждения укажите основание: документ, наблюдение, системное событие или подтверждение владельца. Если есть только мнение, обозначьте его как гипотезу. Это особенно важно для оценок времени и частоты. Фраза «постоянно теряется» задаёт вопрос обследования, но ещё не подтверждает масштаб.

Когда источники противоречат друг другу, сохраните вопрос и способ разрешения. Не выбирайте автоматически самое удобное описание для будущей системы. Если действующий регламент не совпадает с работой, нужно понять причину: устаревший документ, допустимое исключение или нарушение принятого правила. У каждого варианта свои дальнейшие решения.

Как описывать исключения без перегрузки схемы

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

Для каждого исключения задайте владельца и допустимое продолжение. Если процесс остановлен, должно быть понятно, кто принимает решение и что ему нужно узнать. Состояние «ждём» без предмета и следующего шага не является полноценным описанием. Оно лишь переносит неопределённость в другое слово.

Редкие варианты можно вынести в связанный реестр. В основном маршруте оставьте указатель на условие, а подробности держите рядом с владельцем и правилом. Такой подход сохраняет читаемость для руководителя и достаточность для реализации. У схемы должен быть понятный уровень, иначе участники начнут обсуждать разные степени подробности одновременно.

Матрица проверки модели процесса

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

Как перейти от описания к автоматизации

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

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

Не смешивайте текущую и будущую модели в одном наборе шагов. Сохраните факт отдельно, затем сформулируйте изменения и основания. Иначе команда не поймёт, какое действие уже выполняется, какое принято для следующей версии и какое остаётся лишь предложением аналитика.

Что передать после описания процесса

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

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

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

Результат анализа тоже может быть отдельным этапом

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

Подтверждённый результат этого этапа — подготовленное ТЗ для декомпозиции и оценки разработчиками. Это не описание уже работающей интеграции. Для приёмки бизнес-анализа проверяются полнота постановки и разрешённые вопросы; проверка программной реализации появится на следующем этапе.

Контрпример: отправили документ, но не передали работу

В условном процессе менеджер прикрепил предложение и перевёл карточку расчётчику. По рассказу менеджера передача завершена. Расчётчик не может начать: в документе нет выбранной комплектации, а вопрос о ней остался в личном чате. Если соединить роли одной стрелкой, причина ожидания исчезнет со схемы.

Разделите отправку и принятие. Для принятия назовите необходимый состав данных, того, кто его проверяет, и действие при нехватке. Затем проведите пример без одного необходимого значения. По описанию должно быть понятно, кто получает вопрос и кому принадлежит незавершённая работа.

Разберу процесс перед автоматизацией

Опишите работу, которая застревает между сотрудниками, и покажите один обезличенный завершённый случай. Я восстановлю шаги и передачи, выделю спорные правила и подготовлю требования к изменению. Бизнес-анализ перед автоматизацией. Написать в Telegram · Написать в MAX