заказ→Подготовили
заявку→Производство
приняло заявку
Результат передачи — следующая команда может начать работу.
Процесс, проект и задача: где границы
Заявка может пройти через несколько отделов, прежде чем кто-то сможет считать её выполненной. Для начала нужно договориться, какой именно путь мы рассматриваем.
Допустим, клиент согласовал заказ. Менеджер готовит заявку, руководитель проверяет условия, производство уточняет данные и принимает работу. Через день приходит другой заказ и проходит похожий путь. Эта повторяющаяся последовательность действий с определённым результатом — бизнес-процесс. Отдельная заявка проходит один экземпляр этого процесса.
Что именно будем менять
Задача — конкретное действие: проверить комплектность заявки. Проект — ограниченная во времени работа по созданию или изменению чего-либо: например, внедрить новый порядок передачи заказов. После завершения проекта заказы продолжат поступать, а процесс — работать. Поэтому у проекта внедрения может быть руководитель, который не будет отвечать за процесс после запуска.
Границы зависят от вопроса. Чтобы изучить передачу заказа, можно начать с подтверждения клиента и закончить принятием заявки производством. Чтобы разобраться со сроком исполнения заказа, придётся продолжить наблюдение до готового результата. Обе границы допустимы, если участники одинаково их понимают.
Как заметить слишком широкую формулировку
«Улучшить продажи» не говорит, какую повторяющуюся работу мы исследуем. Внутри есть поиск клиентов, подготовка предложения, согласование условий и передача заказа. У этих процессов разные участники и причины задержек. Для первого разбора удобнее выбрать один участок, сохранив связь с общим результатом.
В паспорте процесса стоит указать событие начала, событие окончания и то, что передаётся следующему участнику. Если конец описан как «менеджер отправил письмо», проверьте, означает ли это, что получатель уже может приступить к работе. Иначе задержка просто окажется за пределами выбранного участка.
Как выбрать процесс для первого улучшения
Для первого разбора подходит проблема, которую можно увидеть, измерить и обсудить с людьми, выполняющими работу.
Представим три жалобы: «долго согласуем заявки», «не хватает людей» и «клиенты недовольны». Они могут быть связаны, но пока не показывают, где начинается исследование. Более узкая формулировка звучит так: типовые заявки после подтверждения клиента ждут решения руководителя, и производство не может запланировать их обработку.
Выбор по нескольким признакам
Сначала оцените последствия задержки. Что не может сделать клиент или следующий участник? Затем — повторяемость. Одна необычная заявка может требовать отдельного решения, но не изменения общего порядка. Наконец, проверьте доступность: можно ли посмотреть реальные заявки и поговорить с участниками?
Есть и вопрос влияния. Если изменение зависит от нескольких внешних организаций, первый пилот может оказаться слишком сложным. Это не делает проблему неважной. Просто для учебного проекта разумнее выбрать участок, на котором владелец и участники готовы проверить гипотезу.
Не выбирать решение заранее
Фраза «нам нужен новый трекер» уже задаёт способ действия. Но команда может ждать из-за неполных данных или неясных полномочий. Чтобы не подгонять исследование под выбранный инструмент, сначала опишите наблюдаемую проблему и источник сведений о ней.
Можно сравнить два-три кандидата по последствиям, повторяемости, доступу к данным и возможности провести пилот. Необязательно сводить всё к единому баллу: оценка «влияет сильно» без основания создаёт видимость точности. Полезнее записать, что известно, а что ещё предстоит выяснить.
Клиент, владелец и критерий результата
Отправленная заявка и пригодная к работе заявка — разные результаты. Разница становится заметна на следующем этапе.
В нашем условном примере продажи считают передачу завершённой, когда отправили письмо. Производство обнаруживает, что в письме нет размеров изделия, и возвращает запрос. Менеджер выполнил своё действие, но следующий участник не получил того, что ему нужно для работы.
Кто получает результат
Клиентом процесса может быть покупатель или другая команда. Для процесса передачи заказа непосредственный получатель — производство. Его потребность можно описать конкретно: получить согласованные условия и достаточно данных, чтобы принять заказ. Это помогает определить критерий готовности заявки.
Критерий должен быть проверяемым. «Качественная заявка» допускает разные трактовки. «Указаны состав заказа, размеры, срок и подтверждение клиента» уже позволяет проверить комплектность. При этом список нужно согласовать с получателем: дополнительные поля без назначения только увеличат работу менеджера.
Кто отвечает за весь путь
Владелец процесса отвечает за его результат и организует изменения, когда работа между участниками не складывается. Это не означает, что он выполняет все действия. Важно, чтобы у него были полномочия договариваться об общих правилах или понятный способ получить решение от тех, у кого эти полномочия есть.
Цель улучшения связывает потребность клиента с показателем. Например: уменьшить время от подтверждения заказа до принятия полной заявки. Целевое значение имеет смысл выбирать после исходных замеров и обсуждения ограничений. Одновременно нужно определить, какой показатель нельзя ухудшить, — например, долю заявок, которые производство возвращает на уточнение.
Короткая проверка · по желанию
Менеджер отправил заявку без размеров, производство её вернуло. Какой критерий лучше описывает результат передачи?
Главное из урока
Процесс и цель
Определите начало и конец процесса, его получателя и владельца. Сформулируйте наблюдаемую проблему до того, как предлагать решение.
Отметка сохраняется только в этом браузере.