Презентация карты процесса помогает принять решение: она показывает, где начинается работа, где возникает ожидание, кто отвечает за каждую передачу и чем подтверждается завершение этапа. Для первого черновика можно использовать письменный план и создание презентации из текста в Presenti. После этого карту нужно проверить вместе с людьми, которые выполняют процесс на практике.
Определите границы процесса и результат
Запишите событие начала, событие завершения и получателя результата. «От заказа до оплаты» — слишком широкий охват для одной встречи; «от согласованного заказа до первого счёта» — более удобная граница. Укажите, что остаётся за пределами карты, чтобы участники не приняли учебную схему за полную модель работы.
Выберите детализацию под аудиторию. Руководителям нужны этапы и решения; исполнителям — передачи, системы и маршруты исключений. Сделайте один обзорный слайд и несколько слайдов с увеличенными фрагментами вместо того, чтобы сжимать все операции в одну нечитаемую схему.
Определите границы карты на одной заявке
Рассмотрим вымышленную внутреннюю дизайн-службу. Сотрудник заказывает баннер для кампании; координатор проверяет задание; дизайнер готовит материал; заказчик принимает его. Начало процесса — поступление заявки, конец — принятие итогового файла заказчиком. Планирование кампании, утверждение правил бренда и публикация кампании остаются за этими границами.
Вопрос презентации: «Почему полностью подготовленные заявки ждут начала дизайна?», а не «Как ускорить весь маркетинг?». Более узкий вопрос определяет, какие отметки времени и передачи работы нужны на слайдах. Записи ниже созданы для учебного примера: это не измерения Presenti или её клиента.
Рекомендации ASQ по блок-схемам предлагают определить границы и пройти карту вместе с участниками процесса. Используйте такой разбор, чтобы уточнить карту текущей работы, прежде чем рисовать желаемый будущий процесс.
Покажите передачи и зоны ответственности
Для каждого шага запишите ответственного, входные данные, результат и следующего получателя. Отмечайте передачу там, где меняется ответственность, а не только используемый инструмент. Если в шаге участвуют две команды, отдельно назовите того, кто принимает решение, и того, кто предоставляет подтверждающие материалы.
Используйте последовательные и конкретные глаголы: проверить, согласовать, запланировать, опубликовать, сверить. Существительное вроде «проверка» может скрывать ожидаемое действие. Названия систем оставляйте в дополнительных подписях: тогда процесс будет понятен и после смены инструмента.
Содержание схемы с дорожками, готовое для слайда
| Дорожка | Шаг и входные данные | Результат / следующий получатель | Стрелка исключения |
|---|---|---|---|
| Заказчик | Передать цель, размеры, текст и нужную дату. | Запись заявки поступает координатору. | Сюда возвращается запрос недостающих сведений. |
| Координатор | Проверить задание и подтвердить готовность. | Готовая к дизайну заявка попадает в очередь дизайнера. | Неполное задание → заказчик с указанием того, чего не хватает. |
| Дизайнер | Взять готовую заявку и создать баннер. | Макет с номером версии отправляется заказчику. | Неясный текст → координатор для уточнения. |
| Заказчик | Сравнить макет с согласованным заданием. | Принятие файла закрывает заявку. | Исправление в рамках задания → дизайнер; изменение объёма → координатор. |
На обзорном слайде превратите каждую строку в дорожку и расположите очередь готовых заявок между координатором и дизайнером. Подпишите оба выхода из условия «Задание полное?», не полагаясь только на цвет стрелки. Полезно отделить цикл исправлений: устранить опечатку и заказать новый размер баннера после начала работы — разные события.
Выделите ожидание, возвраты и контроль
Показывайте время ожидания отдельно от времени выполнения работы. Даже при эффективных операциях очередь может быть главным источником задержки. Изобразите петли доработки и причину возврата к предыдущему шагу. Это даст аудитории конкретный объект для улучшения.
Контроль должен быть заметен и соразмерен риску. Укажите подтверждение завершения важного шага — например, запись согласования или результат сверки. Не представляйте саму схему как доказательство соблюдения требований: она лишь показывает, где должна находиться проверка.
Отделите прошедшее время от трудозатрат
В одном условном случае полное задание поступает в очередь в 09:00, дизайн начинается в 11:00, макет отправляют в 11:45, а заказчик принимает его в 12:15 того же дня. Всего проходит 195 минут: 120 минут ожидания дизайна, 45 минут производства и 30 минут до приёмки. Эти интервалы можно складывать, поскольку в упрощённом случае нет параллельной работы и доработок.
Не называйте все 195 минут «временем дизайна». И устранение очереди длиной 120 минут не обязательно сэкономит два часа труда сотрудников: ожидание и трудозатраты — разные показатели. Для реального сервиса сначала договоритесь, включаются ли в отсчёт ночи, выходные и приостановленные заявки, и только потом сравнивайте случаи.
| Условный случай | Готовность → начало дизайна | Производство | Макет → приёмка | Всего прошло |
|---|---|---|---|---|
| R-01 | 120 мин | 45 мин | 30 мин | 195 мин |
| R-02 | 90 мин | 60 мин | 20 мин | 170 мин |
| R-03 | 150 мин | 40 мин | 30 мин | 220 мин |
В подтверждающей записи нужны ID случая, время готовности, начала работы, отправки макета и приёмки, а также причина исключения. Если заявка возвращается на доработку, выделите дополнительный интервал отдельно, а не пытайтесь втиснуть его в прямой маршрут без возвратов.
Объясните узкое место с опорой на данные
Выберите одно узкое место для основной истории. Сравните ожидаемую длительность цикла с наблюдениями и укажите период измерения. Если выборка мала, сообщите об этом. Диапазон или пояснение о надёжности оценки точнее передаёт ситуацию, чем подробное среднее значение без контекста.
Затем покажите два осуществимых изменения и компромисс для каждого. Более быстрая передача может потребовать нового правила согласования, а автоматизация — перенести нагрузку на обработку исключений. Карта должна помогать обсуждать эти варианты, не обещая, что одна перестройка устранит все проблемы.
Какие выводы подтверждаются данными, а какие — нет
Подходящий заголовок слайда: «В этих трёх примерах ожидание в очереди готовых заявок занимает больше всего времени». Его подтверждают все три условных случая. Утверждение «Дизайнер — узкое место» сильнее, чем позволяют данные. Причиной задержки могут быть время передачи, конкурирующие приоритеты, нехватка ресурсов или слишком ранняя отметка о готовности.
Сравните два предложения. Просматривать очередь дважды в день легко попробовать, но срочные заявки могут ждать между просмотрами. Постоянно работающий пункт приёма мог бы реагировать быстрее, однако для него нужны ресурсы, необходимость которых команда ещё не обосновала. Покажите оба компромисса и сначала испытайте менее затратное изменение. Не подписывайте будущую стрелку словом «мгновенно», пока такой процесс не опробован.
Сохраняйте показатели производства и приёмки рядом со временем очереди. Более короткое ожидание не означает улучшения, если работа выполняется в спешке и растёт число доработок. Карта должна показывать места сбора данных, а не выдавать предполагаемую экономию за наблюдаемый результат.
Назначьте ответственного и следующий тест
Завершите презентацию нужным решением, ответственным, минимальным пробным изменением и датой проверки результата. Ссылки на подтверждающие данные или инструкцию вынесите в приложение. В следующей версии карты зафиксируйте, что изменилось и переместилось ли узкое место.
Перед выступлением попросите исполнителя пройти по карте один обычный случай и одно исключение без вашей помощи. Если он не может проследить стрелки или не согласен с обозначенными ответственными, исправьте карту до того, как просить руководителей одобрить изменение.
Последний слайд с решением
Предлагаемая проверка: для следующих десяти полных заявок координатор просматривает очередь в два согласованных момента каждого рабочего дня и называет следующего ответственного. Ответственный: координатор службы. Записи: четыре отметки времени выше, а также доработки и срочные исключения. Разбор: после приёмки десятой заявки сравнить ожидание с отдельно собранными исходными данными при одинаковых правилах отсчёта времени.
Десять заявок здесь — небольшой рабочий пилот, а не статистически обоснованная выборка. Если следующие заявки заметно отличаются по сложности, рассматривайте их отдельно, а не приписывайте разницу эффекту вмешательства. Сокращение ожидания при росте числа изменений объёма работы может означать, что нужно уточнить критерий готовности заявки.
Покажите четыре вида: границы, текущие передачи работы, данные о времени и предлагаемую проверку. Подробный журнал случаев оставьте в материалах к слайду с данными. Руководителям будет понятно, какое решение принять, а исполнителям хватит подробностей, чтобы оспорить карту.
Чтобы показать, что меняется в предлагаемом процессе, используйте пример презентации «до и после»: одинаковые границы сравнения помогают отличить более простой порядок работы от измеренного улучшения.
