Оптимизация бизнес-процессов: как проверить и внедрить улучшение

Сергеев Никита

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

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

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

Как выбрать процесс для улучшения

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

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

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

Как увидеть исходное состояние

Пройдите несколько реальных случаев от начала до конца. Зафиксируйте не только активную работу, но и ожидание, возвраты на уточнение, повторные передачи. Разделяйте наблюдение и объяснение: «заявка ждала два дня» — факт, а «сотрудник не заинтересован» — предположение.

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

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

Как задать цель и ограничения

Цель должна описывать результат процесса, а не выполненное действие. «Внедрить форму» — действие. «Уменьшить число возвратов заявки из-за недостающих сведений» — возможный результат. Форму можно внедрить успешно и не решить проблему.

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

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

Как перейти от симптома к гипотезе

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

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

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

Как организовать пробный запуск

Цикл PDCA предлагает спланировать изменение, провести ограниченную проверку, изучить результат и действовать на основе полученного знания. Этот порядок описывает American Society for Quality. Он полезен тем, что внедрение не заканчивается фактом запуска новой процедуры.

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

Объясните сотрудникам смысл проверки. Им нужно понимать, какие сведения собирать и куда сообщать о затруднениях. Обсуждение изменений не заменяется рассылкой инструкции в день старта.

Учебный пример оценки результата

До изменения рассмотрели 20 сопоставимых стандартных возвратов. Шесть заявок возвращали на уточнение, суммарное активное время обработки составило 400 минут. В пробном запуске ещё 20 случаев обрабатывали с проверкой полноты на входе: уточнение потребовалось двум, активное время составило 360 минут.

Доля уточнений уменьшилась на 20 процентных пунктов, среднее активное время — на 2 минуты. В этом наборе наблюдений разница общего времени составляет 40 минут. Эти числа не доказывают причинный эффект: выборка небольшая, а условия могли отличаться. Они дают основание проверить гипотезу дальше.

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

Как решить, продолжать ли внедрение

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

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

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

Как закрепить работающий порядок

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

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

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

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

Эта часть относится к управлению изменениями. Хороший расчёт эффекта не заменяет работы с людьми, которые должны поддерживать новый способ выполнения задач.

Когда подключать автоматизацию

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

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

Как начать собственный проект улучшения

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

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

Практика вместо теории

Научитесь проводить изменения в команде

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

Смотреть программу

Вопросы и ответы

• Оптимизация всегда означает сокращение затрат?

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

• Можно ли начать с автоматизации?

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

• Как отличить полезное изменение от случайного результата?

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

• Что делать, если пилот не дал улучшения?

  Разберите данные и условия выполнения. Можно изменить гипотезу, сузить область применения или отказаться от меры; распространение неудачного решения не является обязательным продолжением.

• Когда процесс можно считать улучшенным?

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

По теме