Оптимизация бизнес-процесса перед автоматизацией помогает не перенести лишние согласования в новую программу. Если заявку трижды переписывают и два руководителя проверяют одно и то же, электронные кнопки могут ускорить отправку, сохранив основную причину задержки.
Нужно увидеть работу, ожидание и решения, затем выбрать для каждого шага: убрать, объединить, изменить или автоматизировать. Ниже — условная карта внутренней заявки и способ проверить упрощение. Цель не в сокращении контроля любой ценой, а в сохранении нужного результата без ненужных передач.
Выберите один законченный процесс
Начало и конец должны иметь рабочий смысл. Например, сотрудник сформировал потребность в материале, а подразделение получило подтверждённое решение о выдаче либо мотивированный отказ. «Обработка документов» слишком широка для разбора.
Определите участников и варианты завершения. Заявка может быть одобрена, возвращена для уточнения или отклонена. Если смотреть только успешный маршрут, повторные согласования и неполные данные останутся за рамками, хотя именно они часто создают ожидание.
Соберите несколько реальных обезличенных случаев. Включите обычный, срочный и возвращённый. Не превращайте память самого опытного сотрудника в единственный источник: фактический порядок может отличаться по сменам и подразделениям.
Разделите время работы и ожидание
Для каждого шага запишите активную работу человека и календарное ожидание следующего действия. Пять минут проверки могут стоять в очереди шесть часов. Сокращение самой проверки на минуту мало изменит срок прохождения.
Уточните, в какой временной базе измеряется ожидание: рабочие часы или непрерывное календарное время. Не складывайте величины из разных баз. Также отметьте параллельные ветви: их длительности нельзя автоматически суммировать как последовательные.
Запишите причины ожидания отдельно. Отсутствие данных, пакетная обработка раз в день, недоступность согласующего и задержка передачи требуют разных решений. Общая строка «долго согласуют» не объясняет, что менять.
Условная карта заявки
Представим последовательный маршрут, измеренный в рабочих минутах. Инициатор готовит заявку 10 минут. Координатор проверяет её 5 минут после ожидания 120 минут. Руководитель подтверждает потребность 5 минут после ожидания 180. Финансовый специалист проверяет лимит 5 минут после ожидания 240. Исполнитель оформляет решение 5 минут после ожидания 60.
Активная работа занимает 30 минут: 10 + 5 + 5 + 5 + 5. Ожидание — 600 минут: 120 + 180 + 240 + 60. Полное прохождение при заданной последовательности — 630 рабочих минут, то есть 10,5 рабочего часа.
Теперь допустим, автоматическое заполнение уменьшает подготовку с 10 до 3 минут. Экономия составляет 7 минут, а полное время — 623 минуты. Улучшение полезно, но не устраняет десять часов ожидания. Именно поэтому сначала надо выяснить причины очередей.
Проверьте назначение каждого согласования
Задайте четыре вопроса: какое решение принимается, на каких данных, какое нарушение обнаруживается и кто имеет полномочия. Если два участника проверяют разные риски, похожие кнопки не делают один шаг лишним.
Например, руководитель подтверждает необходимость покупки, а финансовый специалист — доступность бюджета. Их нельзя объединить только потому, что оба нажимают «согласовать». Но повторный ввод одних реквизитов перед этими решениями может не добавлять контроля.
Если шаг существует «потому что так всегда было», найдите владельца правила и последствия удаления. Отсутствие объяснения ещё не разрешает отменить действие. Возможно, причина редкая, но существенная и не попала в выбранные примеры.
Выберите действие над шагом
Убрать можно операцию, которая не создаёт нужного результата и не обеспечивает принятого контроля. Решение подтверждает владелец процесса.
Объединить полезно одинаковые действия с общей информацией, если не теряются независимость проверки и полномочия. Например, два последовательных переноса реквизитов заменяют единым вводом.
Изменить означает пересмотреть правило, частоту или условия маршрута. Заявки в пределах подтверждённого основания могут идти иначе, если это разрешено компанией и проверены исключения.
Автоматизировать стоит устойчивое правило с понятными входами и результатом: заполнить известные реквизиты, проверить обязательные поля, передать решение нужной роли. Программа не должна молча принимать решение, которое бизнес ещё не согласовал.
Проверьте новое правило на исключениях
Предположим, координатор больше не переписывает заявку, а проверяет исходную запись. Это уменьшает ручную работу, но теперь нужно решить, что происходит при исправлении инициатором после проверки.
Назначьте правило версии: какие изменения требуют повторного просмотра, как виден прежний результат и кто получает уведомление. Иначе упрощение создаст новый разрыв — решение относится к одному содержимому, а исполнитель видит другое.
Рассмотрите отсутствие согласующего, превышение лимита, срочность и неполные сведения. Если для большинства случаев по-прежнему требуется звонок и отдельный файл, вероятно, новый процесс пока описан только для удобного маршрута.
Шаблон карты решений
- Шаг: конкретное действие и исполнитель.
- Вход: сведения, без которых действие невозможно.
- Результат: факт, решение или передача.
- Работа: измеренное активное время.
- Ожидание: длительность и причина.
- Контроль: какой риск закрывается.
- Предложение: убрать, объединить, изменить или автоматизировать.
- Ограничение: что нельзя потерять.
- Проверка: пример и ожидаемое поведение.
- Владелец: кто утверждает новый порядок.
Такую карточку можно перенести в таблицу. Важнее не форма, а связь предложения с потерей времени и сохраняемым контролем. «Внедрить сервис» само по себе не является решением по конкретному шагу.
Испытайте процесс до большой автоматизации
Небольшое организационное изменение иногда можно проверить на ограниченном наборе операций без разработки. Например, договориться об одном источнике заявки и определённом времени разбора очереди. При этом права и обязательные проверки сохраняются.
Сравните сопоставимые случаи до и после: полное время, число возвратов, активную работу и ошибки. Если очередь сократилась из-за временного личного внимания руководителя, этот фактор нужно отметить. Эффект должен сохраняться в обычной организации работы.
Высвобождённое время не приравнивается к денежной экономии. Порядок такой оценки есть в статье об окупаемости автоматизации. Для сбора подтверждений и вариантов используйте результаты предпроектного обследования.
Зафиксируйте также условия остановки эксперимента. Если новое правило увеличивает ошибки, теряет обязательное подтверждение или не выдерживает обычную нагрузку, команда возвращается к согласованному порядку и разбирает причину. Возможность такого решения помогает проверять упрощение по фактам, а не защищать уже выбранную идею.
Что передать в разработку
Разработчикам нужны согласованный маршрут, словарь объектов, условия решений и исключения. Приложите прежнюю и новую карты, чтобы было видно, зачем меняется процесс и какие показатели надо проверить после запуска.
С ExtentLab можно начать с пяти реальных заявок и карты их ожидания. Такой набор поможет выбрать первую версию внутренней системы вокруг подтверждённого улучшения, а не автоматически повторить существующие передачи в новом интерфейсе.