Компания наняла третьего менеджера, а заявки стали обрабатываться дольше. Время уходит не на работу, а на передачу заявки между людьми, и виноватых нет: каждый сделал свою часть.
Дизайн бизнес-процессов решает эту задачу: компания проектирует порядок работы заранее. У каждого шага появляются срок и ответственный, заявка перестает зависать на передаче, а если встала — видно, у кого и почему. В статье разберем, чем дизайн отличается от описания и моделирования и как спроектировать процесс с нуля.
Попробуйте бесплатно →
Что такое дизайн бизнес-процессов простыми словами
Дизайн бизнес-процессов — это проектирование целевого процесса до его запуска: компания решает, кто выполняет работу, в каком порядке, по каким правилам и с каким результатом.
Термин пришел из английского business process design. Внедренцы и консультанты используют его как синоним слова «проектирование». В вузовских программах охват шире, например дисциплина «Дизайн бизнес-процессов» в НИУ ВШЭ объединяет процессный подход, моделирование в нотациях IDEF0 и ARIS, анализ и оптимизацию. Бизнесу же нужен рабочий алгоритм.
Дизайн и проектирование бизнес-процессов дают компании:
- Регламент или схему целевого процесса, по которым работают сотрудники.
- Список ролей участников и владельца процесса, который отвечает за итог.
- Правила переходов между шагами — что происходит при отказе или спорном случае.
- Метрики процесса, по которым видно, что работа идет как задумано.
Дизайн — часть более широкой работы, которую называют управление бизнес-процессами. В этом цикле компания описывает работу, анализирует ее, перестраивает, автоматизирует и контролирует. Дизайн отвечает за перестройку: он дает целевую модель, которую потом переносят в систему.
Чем дизайн отличается от описания, моделирования и оптимизации процессов
Описание и моделирование фиксируют то, что уже работает, оптимизация улучшает существующий процесс, а дизайн создает тот, которого еще нет. Из-за путаницы в терминах компании берутся не за ту работу — например, оптимизируют процесс, который никто не проектировал.
В одном ряду с этими тремя стоят еще два понятия — реинжиниринг и автоматизация. Компании смешивают их с дизайном так же часто, хотя реинжиниринг перестраивает процесс целиком, а автоматизация подключается только к продуманному процессу. Разница между всеми шестью видна по задаче и результату.
| Термин | Что делаем | Когда применяем | Результат |
| Описание процесса | Фиксируем, как работа идет сейчас | Процесс существует, но нигде не описан | Регламент или схема AS ISCхема AS IS, или «как есть», — это описание реальной работы со всеми обходными путями и задержками |
| Моделирование | Переводим процесс в схему по правилам нотации | Нужен единый язык для отделов и IT-специалистов | Диаграмма BPMN, IDEF0, EPCНаборы правил, по которым рисуют схему процесса. BPMN подходит процессам, которые запустят в системе, IDEF0 — карте процессов верхнего уровня, EPC — цепочкам, где каждый шаг запускает следующее событие |
| Дизайн, или проектирование | Придумываем, как процесс должен работать | Процесса нет или его нужно перестроить | Целевая модель TO BEЦелевая модель TO BE, или «как должно быть», — схема процесса после перепроектирования. В ней уже описаны новые шаги, ответственные и сроки, но в работу она еще не запущена |
| Оптимизация | Убираем лишние шаги в существующем процессе | Процесс работает, но медленно | Улучшенная версия текущего процесса |
| Реинжиниринг | Перестраиваем процесс полностью, с чистого листа | Точечные улучшения уже не помогают | Принципиально новый процесс |
| Автоматизация | Передаем рутинные шаги системе | Процесс упрощен и понятен | Настроенные роботы, триггеры, маршруты согласования |
Когда компании нужен дизайн бизнес-процессов
Дизайн нужен, когда устных договоренностей команде уже мало: работы стало больше, а сама она усложнилась. Обычно к этому моменту совпадает сразу несколько признаков:
- Компания запускает новое направление, продукт или отдел, и порядка работы еще нет.
- В процессе появился новый участник, устные договоренности перестали работать.
- Один и тот же сбой повторяется, а ответственного найти не получается.
- Срок выполнения растет, хотя объем работы не изменился.
- Компания готовится к автоматизации или внедряет CRM-систему.
- Уход одного сотрудника останавливает работу целого участка.
- Клиенты жалуются на разное качество одной и той же услуги у разных менеджеров.
При этом проектировать каждый процесс не нужно. Отложите работу в трех случаях:
- Процесс ведет один человек. Менеджер проводит заявку от первого звонка до отгрузки — описывать нечего, весь порядок помещается в одну голову.
- Работа не повторяется. Творческие и проектные задачи каждый раз идут по-новому, и жесткая схема их только затормозит.
- Условия меняются каждый месяц. Схема устареет раньше, чем команда начнет ею пользоваться.
Из каких элементов состоит спроектированный бизнес-процесс
Бизнес-процесс состоит из границ, входа, выхода, шагов, ролей, правил и метрик. Уберите любой элемент — и схема превратится в картинку, по которой нельзя работать.
Разберем каждый элемент на примере интернет-магазина товаров для дома «Гринлайн». В нем 45 сотрудников, сейчас магазин проектирует обработку заявки на возврат. Компания и цифры в примере условные.
Границы процесса. Событие-старт и событие-финиш. У «Гринлайна» процесс стартует, когда клиент сообщил о возврате, и заканчивается, когда деньги ушли на его карту.
Вход процесса. То, что запускает работу: заявка, письмо, звонок, наступившая дата.
Выход процесса. Результат для клиента процесса. Здесь — возвращенные деньги и закрытая заявка.
Шаги. Действия в определенном порядке.
Роли участников. Кто выполняет шаг. Роль называют по функции, а не по фамилии: оператор поддержки, а не Ирина Шахова. Так процесс переживет отпуск и увольнение.
Владелец процесса. Человек, который отвечает за результат целиком и вправе менять правила. У «Гринлайна» это руководитель клиентского сервиса.
Бизнес-правила. Условия, записанные заранее: возврат принимают в течение семи дней после получения товара, комплектация должна быть полной, сумму свыше 15 тысяч рублей согласует руководитель.
Точка принятия решения. Место, где участник применяет правило и выбирает ветку. Правило про 15 тысяч рублей создает такую точку на третьем шаге: руководитель согласует возврат или отказывает.
Сроки и ресурсы. Норматив времени на шаг и система, в которой шаг выполняют.
Метрики процесса. Показатели, по которым видно, что процесс работает.
Часть бизнес-правил диктует закон, и они попадают в схему бизнес-процесса первыми — решением команды их не изменить. Семидневный срок «Гринлайн» взял не из головы: статья 26.1 закона о защите прав потребителей дает покупателю интернет-магазина семь дней на отказ от товара надлежащего качества. Если магазин не передал правила возврата в письменном виде при доставке, срок растягивается до трех месяцев.
Дальше команда собирает элементы в таблицу. У «Гринлайна» процесс уместился в пять шагов, и для каждого прописана ветка на случай отказа.
| № | Шаг | Исполнитель | Действие | Выход | Что, если нет |
| 1 | Прием заявки | Оператор поддержки | Проверяет дату получения и комплектацию | Заявка зарегистрирована | Семь дней на возврат истекли — оператор объясняет причину и проверяет, нет ли у товара дефекта: брак идет отдельным процессом |
| 2 | Проверка условий | Оператор поддержки | Сверяет заявку с правилами возврата | Решение: принять, отказать или уточнить | Данных мало — оператор запрашивает фото и ставит заявку на паузу |
| 3 | Согласование | Руководитель клиентского сервиса | Согласует возврат свыше 15 тысяч рублей | Возврат одобрен | Руководитель отклонил — заявка уходит оператору с обоснованием |
| 4 | Возврат средств | Бухгалтер | Переводит деньги клиенту | Деньги возвращены | Реквизиты не проходят — бухгалтер передает заявку оператору |
| 5 | Закрытие заявки | Оператор поддержки | Уведомляет клиента и закрывает заявку | Заявка закрыта | Клиент не подтвердил получение — оператор пишет повторно через два дня |
Передача результата от шага к шагу — самое уязвимое место. У «Гринлайна» заявка четыре раза меняет ответственного и на каждой передаче может зависнуть.
Исполнитель отвечает только за свой шаг, а владелец процесса — за всю цепочку. В нашем примере это руководитель клиентского сервиса: он следит, чтобы схема совпадала с реальной работой, и меняет правила, когда они расходятся. Без такого человека правила меняют на словах, схема остается прежней и через несколько месяцев по ней уже никто не работает.
Какие принципы лежат в основе дизайна бизнес-процессов
В основе дизайна лежит семь принципов. Они подсказывают, от чего отталкиваться при проектировании, сколько раз можно передавать задачу, кому отдать право решать и где остановиться с детализацией.
- Начинайте с результата. Определите, что получает клиент процесса, и стройте шаги под этот результат. Тогда процесс пройдет через все нужные подразделения, а не остановится на границе одного отдела.
- Передавайте задачу как можно реже. Каждая передача — точка ожидания и потери контекста. Если один человек может сделать два соседних шага, отдайте ему оба.
- Отдавайте решение тому, кто ближе к работе. Ставьте согласование там, где есть реальный риск. Например, оператор «Гринлайна» возвращает деньги сам и подключает руководителя только при сумме свыше 15 тысяч рублей.
- Закрепляйте каждый шаг за одним человеком. Шаг, закрепленный за отделом, не закреплен ни за кем: каждый считает, что его сделает коллега.
- Проверяйте схему на пиковой нагрузке. Прогоните ее на самом загруженном дне прошлого месяца. Если она держится только при полном штате и спокойном потоке заявок, запускать рано.
- Формулируйте шаги правилами. Каждый шаг описывайте как «условие → действие → ответственный». Такой шаг легче переносится в систему.
- Оставляйте только те шаги, без которых не обойтись. Схему, которую сотрудники не читают, они и не соблюдают. Если процесс распался на 30 шагов, объедините мелкие в один или вынесите часть в подпроцесс.
Как спроектировать бизнес-процесс с нуля
Чтобы спроектировать бизнес-процесс с нуля, пройдите восемь шагов — от границ процесса до метрик. Этапы проектирования бизнес-процессов складываются в один маршрут, и каждый следующий шаг опирается на предыдущий. Разберем их на примере «Гринлайна».
Шаг 1. Определите границы и результат. Формулируйте результат так, чтобы в нем читалось завершенное действие: деньги возвращены клиенту. Расплывчатая работа с возвратами не показывает, где процесс заканчивается.
Шаг 2. Определите клиента процесса и его требования. Клиентом бывает внешний покупатель или смежный отдел. Покупателю «Гринлайна» важны два условия: деньги приходят в обещанный срок и в полном размере.
Шаг 3. Соберите участников и роли. Составьте список ролей, а не фамилий, и назначьте владельца процесса. Позовите исполнителей: оператор расскажет про случаи, о которых руководитель может не знать.
Шаг 4. Выпишите шаги укрупненно. Начните с пяти-девяти крупных шагов без деталей. Если шагов сразу 30, выделите подпроцесс: у «Гринлайна» проверка товара на складе стала отдельным процессом.
Шаг 5. Добавьте ветвления и исключения. Опишите, что происходит при отказе, возврате на доработку или нетиповом случае. Отдельно пропишите эскалацию: спорная сумма уходит руководителю клиентского сервиса.
Шаг 6. Пропишите правила и сроки. Для каждого шага зафиксируйте условие входа, норматив времени и признак ошибки. «Гринлайн» дал оператору сутки на проверку, руководителю — четыре часа на согласование, бухгалтерии — три рабочих дня на перевод.
Шаг 7. Выберите форму фиксации. Текстовый регламент процесса подходит для линейных процессов, схема — для процессов с ответвлениями, нотация BPMN — если процесс пойдет в IT-систему.
Шаг 8. Заложите метрики. Качество дизайна процесса показывают три числа: время цикла, число передач между ролями и доля переделок. Замерьте их до запуска, иначе сравнивать будет не с чем. «Гринлайн» зафиксировал стартовые значения: время цикла — девять дней, четыре передачи, 22% заявок возвращаются на доработку. Цифры условные.
Восемь шагов закрывают все элементы из прошлого раздела: шаг 1 задает границы и выход, шаг 3 — роли участников и владельца, шаг 5 — точки принятия решения, шаг 6 — бизнес-правила и сроки, шаг 8 — метрики процесса.
Как понять, что бизнес-процесс спроектирован правильно: чек-лист
- У процесса есть один владелец, который отвечает за результат и вправе менять правила.
- Каждый шаг закреплен за конкретной ролью, а не за отделом.
- Описаны минимум два-три сценария исключений, а не только благополучный путь.
- У каждого шага есть норматив времени и признак ошибки.
- Заложены минимум три измеримых показателя.
- Новый сотрудник понимает схему за десять минут и может по ней работать.
Как перепроектировать существующий процесс от AS IS к TO BE
Чтобы перепроектировать работающий процесс, команда превращает модель AS IS в модель TO BE. AS IS показывает реальную работу со всеми обходными путями, TO BE — целевую модель после дизайна.
Собирайте AS IS не по документам. Регламент показывает, как положено, а сотрудники работают так, как удобно. Поговорите с исполнителями, а не только с руководителями, понаблюдайте за работой вживую и поднимите историю сделок в CRM: логи покажут реальные сроки и число возвратов на доработку. Такую фиксацию текущего порядка называют описанием бизнес-процессов.
В собранной модели ищите узкие места — шаги, на которых работа скапливается:
- Ожидание между шагами, когда заявка лежит в чужой почте.
- Двойной ввод одних и тех же данных в разные системы.
- Согласования, на которых согласующий не вправе отказать.
- Возвраты на доработку из-за неполных данных на входе.
- Обходные пути в мессенджерах и личных таблицах.
Разрыв между AS IS и TO BE превратите в план изменений. Выпишите, что мешает, почему так вышло, что меняем, кто отвечает, к какому сроку. Лучше в формате таблицы — так у вас будет не абстрактная схема, а список задач с исполнителями и датами.
Пример. Так выглядит разрыв между AS IS и TO BE на практике. У агрегатора услуг мобильной связи «Экомобайл» обращения и задачи жили в корпоративной почте, таблицах Google, Excel-реестрах и нескольких внутренних системах: продажи, клиентский сервис, финансы, IT и проектный офис работали каждый в своем инструменте. Модель как есть показала узкое место — руководителям было сложно контролировать сроки, загрузку сотрудников, статус заявок и качество обработки.
В целевой модели у каждого обращения появились ответственный, срок и маршрут. Партнер Smart Business развел направления CRM по B2C, B2B, дилерам и маркетплейсам, перевел обращения в смарт-процессы, добавил контроль первого контакта и напоминания о сроках, настроил дашборды по просрочкам, загрузке сотрудников и результатам подразделений.Какие инструменты и нотации используют для дизайна бизнес-процессов
Команда описывает спроектированный процесс в нотацииНабор правил, по которым рисуют схему. Схема бизнес-процесса в единой нотации читается одинаково в продажах, на складе и в бухгалтерии BPMN, IDEF0, EPC, в блок-схеме или таблице. Форму выбирайте по сложности процесса и по тому, пойдет ли он в IT-систему.
- Нотация BPMN — для процессов, которые потом запускают в системе. Схему в BPMN читает и человек, и программа. Подробнее рассказывали в этом материале.
- Нотация IDEF0 — для карты процессов верхнего уровня. Показывает, из каких крупных блоков состоит операционная деятельность компании, без деталей внутри.
- Нотация EPC — для цепочек, где каждый шаг запускает следующее событие. Подходит, когда важен не столько порядок действий, сколько то, что их запускает.
- Блок-схема — свободная схема из простых фигур. Подходит, когда нужно быстро зафиксировать процесс для своей команды и не тратить время на обучение правилам.
Форму фиксации подбирайте под сложность процесса. Таблица «шаг — исполнитель — выход» подходит для линейных процессов без ветвлений. Схема на онлайн-доске удобна, когда развилок много и команда собирает процесс вместе. Исполняемая модель в BPM-системе нужна, когда процесс должен не лежать в документе, а запускаться и работать сам.
Как работает дизайнер бизнес-процессов
Дизайнер бизнес-процессов — это визуальный конструктор, в котором процесс собирают из готовых блоков и сразу запускают в работу
Дизайн — это продумывание процесса. Дизайнер — инструмент, где эту работу превращают в исполняемую модель.
Внутри конструктора шаги выглядят как блоки: у каждого есть условие входа, действие, ответственный и срок. Между блоками ставят развилки — те самые точки принятия решения, которые вы заложили в схему.
После запуска модель работает сама. Она ставит задачи исполнителям, уведомляет участников при смене статуса, следит за сроками и хранит историю по каждой заявке. Руководитель в любой момент видит, на каком шаге застряла конкретная заявка.
На российском рынке дизайнеры встречаются в трех видах:
- Модуль внутри CRM или корпоративного портала: процесс собирают там же, где живут заявки и задачи.
- Отдельная BPM-платформа — ее берут, когда процесс идет через несколько систем и нужна своя логика.
- Конструктор внутри системы документооборота — рассчитан на согласование и подписание документов.
Если компания закупает программы по требованиям к отечественному ПО, проверьте систему в едином реестре российских программ — его ведет Минцифры.
Как проверить спроектированный процесс до запуска
Перед запуском команда тестирует процесс, проверяет исключения и обкатывает схему на пилотной группе — и только потом масштабирует ее на всю компанию. Проверка занимает недели, а переделка запущенной схемы — месяцы.
Прогоните процесс на прошлых заявках. Возьмите десять реальных обращений за прошлый месяц и проведите их по новой схеме на бумаге.
Проверьте каждое ветвление на отрицательный ответ. Если на развилке нет второй ветки, процесс к запуску не готов.
Запустите пилот. Две — четыре недели на одном отделе или одном типе заявок покажут, где схема мешает работать. Расширяйте пилот, когда исполнители перестанут ее обходить.
Опросите исполнителей. Выясняйте не то, удобна ли схема, а то, в каком случае по ней работать не получилось.
Зафиксируйте базовые значения метрик. Без стартовых цифр эффект нечем измерить: через полгода никто не вспомнит, сколько дней занимал возврат раньше.
Как заложить автоматизацию еще на этапе дизайна
Закладывайте автоматизацию в дизайн заранее. Процесс, продуманный на бумаге, и процесс, продуманный под систему, — разные схемы, даже если шаги в них совпадают. Если этого не сделать, автоматизация бизнес-процессов превратится в переделку схемы под возможности программы.
Чтобы процесс можно было автоматизировать, предусмотрите в дизайне три вещи:
- Каждый переход описан правилом: «условие → действие → ответственный».
- Все данные для решения появляются в системе, а не в голове исполнителя.
- У каждого шага есть измеримый признак завершения.
Готовые шаблоны бизнес-процессов
Для типовых задач рисовать с нуля не нужно. В Битрикс24 есть готовые шаблоны: двухэтапное утверждение, ознакомление с документом, простое голосование, утверждение по первому голосу, экспертная оценка. Маршрут согласования договора или счета вы соберете из них за несколько минут.
А для нетиповых сценариев можно использовать смарт-процессы со своими полями, стадиями и логикой автоматизации.
Роботы и триггеры
Робот выполняет действие, когда сделка или задача переходит на новый этап: ставит задачу, отправляет письмо, меняет ответственного, запускает согласование. Триггер работает наоборот — ловит внешнее событие вроде входящего звонка или оплаты счета и двигает сделку дальше. В дизайне это те самые правила «условие → действие → ответственный», только уже настроенные.
Отчеты по метрикам процесса
Время цикла, число передач и долю переделок нужно замерять постоянно, иначе процесс тихо вернется к прежнему виду. CRM-аналитика показывает, сколько заявок прошло каждую стадию и где они задерживаются. Для более сложных отчетов по набору показателей можно использовать BI Конструктор.
Пример. «РОСНА Инжиниринг» оказывает инжиниринговые услуги промышленным предприятиям: проектирует и производит вакуумное оборудование, ремонтирует и обслуживает его. Данные о клиентах лежали в Excel, почте и звонках, поэтому компания не могла собрать отчетность и не видела, на каком этапе теряет время.
Партнер «АС Проект» перенес работу в Битрикс24 и настроил две воронки сделок — от первичного контакта до закрытия, четыре смарт-процесса — под тендер, реализацию и два вида ремонта, ежедневные автоматические отчеты и персональные дашборды.
Замеры показали эффект в цифрах: время обработки лидов сократилось на 40%, конверсия лидов в сделки выросла на 25%, согласование этапов стало быстрее на 30%, а подготовка коммерческих предложений — на 20%.Битрикс24 не спроектирует процесс за компанию. Система зафиксирует и исполнит то, что придумала команда: если в схеме нет ветки на случай отказа, робот тоже не будет знать, что делать. О чем еще важно помнить:
- Процесс с десятками ветвлений требует времени на настройку и обычно помощи специалиста по внедрению.
- Если процесс меняется каждую неделю, жестко зашивать его в систему рано: переделка настроек обойдется дороже ручной работы.
Какие ошибки чаще всего допускают при дизайне бизнес-процессов
Ошибки в дизайне редко видно сразу: они проявляются, когда процесс уже запущен и переделывать его дорого. Восемь самых частых стоит проверить еще на схеме.
- Копируют чужой регламент из интернета и подгоняют под него свою работу — чужие шаги не учитывают ни ассортимент, ни состав команды.
- Собирают схему со слов руководителей и не спрашивают исполнителей — в итоге описывают как положено, а не как работа идет на самом деле.
- Назначают владельцем процесса человека без возможности менять правила — он видит сбои, но не может ничего исправить.
- Убирают готовую схему в общую папку и не рассказывают о ней команде — сотрудники продолжают работать по памяти.
- Берутся сразу за все процессы компании и не доводят до конца ни один.
- Оставляют исполнителя без инструкции на случай отказа и получают звонок руководителю по каждому нетиповому случаю.
- Зашивают непроверенную схему в систему и платят за переделку настроек.
- Измеряют эффективность процесса числом закрытых задач вместо времени цикла и доли переделок — работа кипит, а клиент ждет столько же.
в Битрикс24
Частые вопросы
Схему собирает руководитель направления или бизнес-аналитик вместе с исполнителями. Руководитель видит результат и границы процесса, исполнители знают исключения и обходные пути. Без исполнителей в схеме не окажется половины реальных случаев.
Отдельно компания назначает владельца процесса — он отвечает за результат после запуска. Проектировать и владеть может один человек, но роли разные: первая заканчивается вместе с проектом, вторая нужна постоянно.
Линейный процесс команда проектирует за несколько дней, процесс с развилками и несколькими отделами внутри — за несколько недель. Общего норматива по отраслям нет: срок зависит от числа участников и от того, насколько одинаково они понимают работу.
Дольше всего длится не рисование схемы, а сбор исключений. Именно тут выясняется, что два отдела по-разному понимают один и тот же шаг.
Начните с процесса, который сильнее всего влияет на клиента и чаще всего дает сбои: обработка заявок, жалоб или возвратов. Там ошибки заметнее, и там же быстрее окупается работа над проектированием.
Не беритесь сразу за карту процессов всей компании. Один доведенный до запуска процесс дает команде опыт и понятный результат, а незаконченный набор из 20 схем не меняет ничего.
Сотрудники нарушают схему в двух случаях: она мешает работать или о ней не рассказали. В первом исполнители нашли путь короче, и это повод разобрать их маршрут — часто он лучше спроектированного. Во втором хватит разбора и переноса логики туда, где люди работают.
Наказания тут помогают слабо. Если в процессе нет ветки под реальный случай, сотрудник все равно пойдет в обход, просто перестанет об этом рассказывать.
Плановый пересмотр раз в полгода закрывает большинство ситуаций. Внепланово команда правит процесс, когда меняются закон, продукт или структура отделов: новое правило ломает старую схему сразу.
Второй сигнал дают метрики. Если время цикла растет, а доля переделок увеличивается несколько месяцев подряд — процесс разошелся с реальной работой и его пора собирать заново.
Что в итоге
- Дизайн бизнес-процессов — это проектирование того, как должна выполняться работа.
- Дизайн, описание, моделирование, оптимизация и реинжиниринг решают разные задачи и дают разный результат. Проектировать стоит то, чего еще нет, а оптимизировать — то, что уже работает.
- Спроектированный процесс состоит из границ, входа, выхода, шагов, ролей, правил, точек принятия решения, сроков и метрик.
- Процесс проектируют с нуля по восьми шагам или перепроектируют через модели AS IS и TO BE, если он уже работает.
- Перед запуском процесс прогоняют на реальных заявках и исключениях, а базовые значения метрик фиксируют заранее.
