Бизнес-процессы: что это и как описать на примере

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

Что делает работу процессом

Работу делает процессом повторяемая связь между событием запуска, действиями участников и проверяемым выходом. Для обработки заявок запуском служит полученный запрос, входом — контакты и условия клиента, выходом — отправленное предложение или обоснованный отказ. Между запуском и выходом работа переходит от менеджера к инженеру и обратно. Если порядок передач меняется от случая к случаю, описание сначала фиксирует фактические варианты, а затем команда выбирает правило для повторения.

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

Чем он отличается от задачи

Процесс отличается от задачи повторяемостью: «обработать клиентскую заявку» описывает маршрут для разных обращений, а «ответить компании N на запрос от 5 октября» — одно выполнение этого маршрута. Проект, в свою очередь, имеет ограниченный результат и конец, например внедрение нового порядка работы с заявками. В ходе проекта команда может изменить процесс, но отдельная заявка от этого не становится проектом.

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

Какие виды процессов бывают

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

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

Когда процесс стоит описать

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

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

Как выбрать первый поток работы

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

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

Какие границы задать перед описанием

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

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

Что запускает процесс

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

Момент запуска нельзя переносить на дату, когда менеджер впервые открыл письмо: иначе время ожидания до открытия исчезнет из картины. Источником времени может служить почтовый ящик или форма, где обращение поступило. Рабочая карточка помогает координировать действия, но не заменяет первичное письмо как факт получения запроса.

Что считать его завершением

Завершением процесса считают доставленный клиенту ответ: предложение с согласованными условиями либо обоснованный отказ. Владелец процесса подтверждает, что выбранный исход соответствует правилу команды и у конкретной заявки есть ответственный за закрытие. Перемещение карточки в колонку «Готово» обозначает рабочий статус, но без отправленного ответа не доказывает завершение процесса для клиента.

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

Как зафиксировать работу как есть

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

Рисунок 1. Текущий маршрут заявки: получение → проверка полноты → оценка инженера → согласование → ответ клиенту. Ожидание согласования выделено отдельно.

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

У кого собрать фактические шаги

Фактические шаги собирают у того, кто получает заявку, у того, кто принимает её для оценки, и у владельца итогового ответа. Менеджер показывает вход и переписку с клиентом; инженер объясняет, какие данные нужны для оценки; руководитель продаж показывает момент согласования и критерий отказа. Последнюю заявку проходят вместе по времени, не ограничиваясь воспоминанием о «типичном» порядке.

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

Где отметить решения с исключениями

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

Рисунок 2. Две развилки процесса: «данных достаточно» и «условия выполнимы». Каждая ветка заканчивается следующим владельцем или ответом клиенту.

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

Как выбрать формат описания

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

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

Какой уровень детализации нужен

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

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

Какие поля включить в таблицу

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

Если в одном шаге нет результата, строку уточняют или объединяют с соседним действием. Колонка «кто проверяет» нужна только там, где есть проверка; роль нельзя помещать в колонку «где проверить». Заполненный маршрут ниже показывает поля на одном процессе, а не набор универсальных шаблонов для любой компании.

Как выглядит заполненный пример

Заполненный пример описывает условный процесс обработки клиентской заявки у небольшой команды. Письмо или форма приносит контакт, предмет запроса и исходные данные. Руководитель продаж владеет процессом, менеджер ведёт контакт и передачу, инженер оценивает выполнимость. Выходом служит отправленное предложение либо мотивированный отказ. Целевой ответ по полному входу — за один рабочий день; два дня ожидания согласования ниже — учебная ситуация, а не статистика Strive или клиента.

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

Что показывает маршрут заявки

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

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

Где возникает задержка

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

Рисунок 3. «Как есть» — проект ответа без назначенного окна согласования; «после» — руководитель продаж принимает его в согласованное окно либо назначает замещающего. Схема показывает изменение правила, а не обещание автоматического сокращения срока.

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

Как проверить описание с командой

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

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

Какие показатели покажут проблему

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

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

Как перенести процесс в Strive

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

Рисунок 4. Официальный экран канбан-доски Strive: задачи разложены по колонкам. Подпись не приписывает интерфейсу автоматическое построение схемы процесса.

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

Какие шаги превратить в задачи

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

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

Что закрепить регламентом

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

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