Оптимизация бизнес-процессов: как найти потери и что менять первым

Почему ускорение работы не убирает задержку

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

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

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

Описать результат, а не должности

Схема начинается с результата для получателя. Должностные инструкции идут после него.

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

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

Поля короткого паспорта

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

Сначала договориться об этих полях полезнее, чем рисовать подробную диаграмму всех внутренних сообщений. Иначе красивая схема закрепит разногласие: один участник считает заявку законченной после подписи, а другой — только после появления товара. Разный результат делает сравнение сроков бессмысленным.

Где на самом деле теряется время

Ожидание нужно отделить от обработки. Это меняет выбор первого исправления.

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

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

Откуда берутся возвраты

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

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

Что убрать до автоматизации

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

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

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

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

Как испытать новый порядок

Изменение стоит сначала испытать на ограниченном потоке. Массовое переключение затруднит разбор ошибок.

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

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

Как принять результат

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

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

Когда помогает система

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

Например, в Битрикс24 бизнес-процессы открываются через «Автоматизация → Бизнес-процессы → Процессы», а сведения о действиях и участниках можно исследовать в протоколе, чтобы различить незапущенное задание и работу, которая уже ждёт решения сотрудника. Такая возможность иллюстрирует учёт событий, а порядок закупки и полномочия остаются решением компании. Перед выбором также уточняют доступность нужной функции в используемом продукте и тарифе. Выбор системы без этих исходных правил лишь переносит неопределённость из переписки в карточки заданий.

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

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

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

Задание на первое изменение

Первое задание описывает потерю и ожидаемое изменение. Начните с одного участка.

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

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