1
Фиксируем AS IS
Как процесс фактически работает сейчас.
SOLDATOVA · бизнес-процессы
Оптимизация бизнес-процессов убрать потери, а не просто ускорить работу
Процесс редко становится эффективнее только потому, что сотрудникам поставили более жёсткие сроки. Если внутри остаются лишние действия, очереди, дублирование, ненужные согласования и размытые роли, давление лишь ускоряет движение внутри неэффективной конструкции.
Главный принцип
Оптимизировать нужно систему работы, а не скорость человека
Сначала определяется причина потерь. После этого меняется именно тот элемент процесса, который ограничивает результат: шаг, согласование, передача, роль, ресурс или правило принятия решения.
Хорошая оптимизация делает процесс
проще, короче, прозрачнее
и менее зависимым от ручного управления.
Посмотреть логику изменений →
Маршрут оптимизации
01
Диагностика Где реально возникает потеря.
02
Устранение причины Что можно убрать, объединить или изменить.
03
TO BE Как процесс должен работать после изменений.
04
Метрики Как понять, что изменение действительно сработало.
Не путать
Работать быстрее не всегда значит работать эффективнее
Если проблема находится в самой конструкции процесса, ускорение отдельных сотрудников не устраняет её. Оно лишь заставляет людей быстрее доходить до следующего ограничения.
№ Попытка ускорить Оптимизация
01
«Считайте быстрее»
Хотя большая часть срока уходит на ожидание исходных данных.
→
Исправить качество входных данных
Чтобы расчёт начинался сразу, без нескольких возвратов.
02
«Согласовывайте оперативнее»
Хотя большая часть решений вообще не требует участия руководителя.
→
Убрать лишнее согласование
И определить границы, внутри которых решение принимается самостоятельно.
03
«Проверяйте внимательнее»
Хотя одни и те же данные перепроверяются несколькими участниками.
→
Определить одну точку контроля
И единый источник корректных данных.
04
«Работайте без ошибок»
Хотя требования к результату передаются устно и меняются по ходу.
→
Стандартизировать результат этапа
Чтобы следующий участник заранее понимал, что должен получить.
Оптимизация начинается там,
где вместо требования
«делайте быстрее»
появляется вопрос
«почему этот процесс вообще занимает столько времени?»
Шаг 01 · диагностика
Перед изменением процесса нужно найти конкретную причину потери
Оптимизация без диагностики часто превращается в набор случайных улучшений. Один этап ускорили, второй автоматизировали, третий переписали — но общий результат почти не изменился, потому что настоящее ограничение осталось на месте.
2
Находим потерю
Где исчезают время, качество или ресурс.
3
Ищем причину
Почему потеря возникает снова и снова.
4
Определяем изменение
Какой элемент процесса нужно изменить.
5
Задаём эффект
По какой метрике проверим результат.
Оптимизировать стоит
не то место, которое больше всего раздражает,
а то ограничение,
устранение которого действительно меняет результат процесса.
Шаг 02 · лишние действия
Первый способ ускорить процесс — перестать делать то, что не создаёт результат
В процессе могут годами сохраняться действия, которые когда-то имели смысл, появились после единичной ошибки или просто были добавлены «для надёжности». При оптимизации каждое действие нужно заново проверить на необходимость.
01
Что создаёт ценность?
Действие непосредственно меняет результат
или необходимо для обязательного требования.
Его сохраняем.
02
Что существует только «на всякий случай»?
Дополнительная проверка,
копия документа,
повторный ввод информации
или промежуточный отчёт,
которым никто не пользуется.
03
Что можно объединить?
Два последовательных шага
могут выполняться одновременно
или одним участником,
если между ними нет реальной зависимости.
04
Что можно убрать полностью?
Если после удаления шага
качество,
безопасность
и результат процесса не меняются,
возможно,
этот шаг больше не нужен.
Шаг 03 · согласования
Не каждое решение должно подниматься на следующий уровень
Согласование полезно, когда решение действительно несёт риск, влияет на деньги или выходит за полномочия роли. Но если типовые решения каждый раз требуют одобрения руководителя, согласование превращается в постоянную очередь.
До оптимизации
Исполнитель подготовил решение
→
Руководитель отдела
→
Коммерческий директор
→
Собственник
После оптимизации сначала определяются границы решений
Самостоятельно
Типовые решения
внутри заранее установленных границ.
С уведомлением
Решение принимается сотрудником,
руководитель получает информацию.
С согласованием
Только решения,
которые реально выходят за полномочия,
бюджет или уровень риска.
Шаг 04 · дублирование
Один результат не должен создаваться дважды
Дублирование не всегда заметно: сотрудники могут добросовестно выполнять одинаковые проверки, вести параллельные таблицы и повторно собирать данные, потому что система сложилась именно так.
Найдите места, где одна и та же информация или функция живёт в нескольких точках
Условный пример:
менеджер фиксирует срок заказа в CRM,
координатор переносит его в Excel,
производство ведёт собственную таблицу,
а руководитель собирает четвёртый файл для контроля.
Было
CRM менеджера
таблица координатора
таблица производства
отчёт руководителя
→
После оптимизации
один источник данных
единый владелец информации
понятное правило обновления
отчёт строится из того же источника
Устранение дублей
сокращает не только время работы.
Оно уменьшает количество расхождений
и споров о том,
«какая версия данных правильная».
Шаг 05 · роли
После упрощения процесса закрепите новую ответственность
Даже хорошо спроектированный маршрут быстро вернётся в старое состояние, если участники не понимают, кто отвечает за каждый результат, какие решения принимает самостоятельно и что именно передаёт следующему этапу.
01
Владелец процесса
Кто отвечает
за конечный результат процесса целиком,
а не только за отдельный участок.
02
Владелец этапа
Кто создаёт конкретный промежуточный результат
и передаёт его дальше.
03
Границы решений
Что участник решает самостоятельно,
а в каких случаях
требуется следующий уровень.
04
Критерий передачи
В каком состоянии результат
считается готовым
для следующего участника процесса.
Оптимизированный процесс
должен существовать
не только на схеме,
но и в распределённой ответственности.
Шаг 06 · TO BE
Новый процесс должен быть проще по конструкции, а не просто быстрее
После диагностики можно проектировать модель TO BE — то есть процесс, который должен работать после изменений. На этом этапе важно не переносить старую схему в новый регламент, а убрать сами причины потерь.
AS IS
Как процесс работает сейчас
В текущей модели накопились действия, которые когда-то возникли по отдельным причинам, но со временем стали восприниматься как обязательные.
01
Повторные согласования
Типовое решение каждый раз снова поднимается руководителю.
02
Дублирование данных
Одну информацию вводят и проверяют несколько участников.
03
Размытая ответственность
Участников много, но владелец конечного результата не определён.
→
TO BE
Как процесс должен работать
Новая модель сохраняет только те действия, которые действительно необходимы для результата, качества или управления риском.
01
Типовые решения — по правилам
Руководитель подключается только к заранее определённым исключениям.
02
Данные вводятся один раз
Следующие этапы используют единый источник информации.
03
У результата есть владелец
Ответственность не теряется между функциональными участками.
Условный пример
Если коммерческое предложение в пределах стандартной скидки сейчас проходит три согласования, оптимизация — не попросить согласующих отвечать быстрее. Можно установить границу, внутри которой менеджер принимает решение самостоятельно, а руководитель подключается только при выходе за согласованные условия.
Хороший TO BE отвечает на вопрос:
какое минимальное количество действий
действительно необходимо,
чтобы стабильно получить нужный результат?
Шаг 07 · метрики результата
Оптимизацию нужно подтвердить изменением результата
Новая схема может выглядеть логичнее, но это ещё не означает, что процесс действительно стал лучше. Поэтому до внедрения изменений нужно определить, по каким показателям мы будем проверять эффект.
Что измерять после изменения процесса
Набор метрик зависит от процесса. Важно сравнивать показатели, которые действительно отражают скорость, качество, ресурсы и конечный результат.
До → после
01
Время цикла
Сколько проходит от входа процесса до готового результата.
02
Количество возвратов
Сколько раз результат возвращается назад на исправление или уточнение.
03
Стоимость процесса
Какие трудовые, финансовые и другие ресурсы требуются для результата.
04
Качество результата
Как часто процесс с первого раза создаёт результат нужного качества.
Метрика До После Что изменилось
Срок обработки 5 дней 3 дня Убрано лишнее ожидание
Возвраты на доработку 18% 7% Улучшен вход этапа
Количество согласований 4 1 Типовые решения делегированы
Цифры здесь условные.
Смысл сравнения в другом:
каждое изменение процесса
должно иметь заранее определённый измеримый эффект.
FAQ
Частые вопросы об оптимизации бизнес-процессов
Основные вопросы, которые возникают, когда компания хочет сократить потери и перестроить процессы.
Оптимизация бизнес-процессов —
это изменение конструкции процесса,
которое позволяет получать нужный результат
с меньшими потерями времени,
ресурсов и управленческого внимания.
Задача не просто ускорить сотрудников,
а устранить причины задержек,
лишних действий,
возвратов и дублирования.
Сначала необходимо зафиксировать текущий процесс AS IS
и понять,
где возникают основные потери и ограничения.
Только после диагностики имеет смысл проектировать
новую модель TO BE.
Иначе компания рискует менять участки,
которые не являются реальной причиной проблемы.
В первую очередь проверяют действия,
которые не создают ценность,
не снижают значимый риск
и не являются обязательным условием результата.
Это могут быть повторный ввод данных,
лишние проверки,
согласования типовых решений
или действия,
появившиеся исторически,
но больше не выполняющие полезной функции.
Нет.
Согласование необходимо,
если оно действительно управляет риском
или требует решения более высокого уровня.
Оптимизация убирает не контроль как таковой,
а избыточные согласования,
которые повторяются для типовых ситуаций
и не меняют конечное решение.
До внедрения изменений
нужно определить метрики результата:
срок процесса,
количество возвратов,
качество,
стоимость,
объём или другой значимый показатель.
После изменений сравнивается фактический результат.
Оптимизация считается полезной,
если улучшение подтверждается данными.
Автоматизация может быть следующим этапом,
если процесс уже понятен,
роли и ответственность определены,
а лишние действия устранены.
Автоматизация не должна закреплять старые потери:
сначала лучше упростить процесс,
а затем автоматизировать действительно нужные действия.
Следующий шаг
Если процессы постоянно приходится ускорять вручную, проблема может быть в самой конструкции работы
Дополнительный контроль,
новые дедлайны
и требование «работать быстрее»
редко устраняют системную причину потерь.
На диагностике мы определяем,
какие процессы действительно ограничивают результат,
где возникают лишние действия,
согласования и дублирование
и что нужно менять в первую очередь.
Провести диагностику ↗ 01 · Диагностика
Фиксируем AS IS
и реальные причины
потерь внутри процесса.
02 · TO BE
Проектируем более простую
и управляемую конструкцию
без лишних действий.
03 · Результат
Определяем метрики
и проверяем,
действительно ли изменения дали эффект.