Представим компанию, в которой покупка обычного офисного кресла требует пяти последовательных согласований. Сотрудник создаёт заявку. Руководитель её подтверждает. Финансовый отдел проверяет бюджет. Закупки уточняют условия приобретения. Затем заявка снова возвращается к руководителю.
Компания решает автоматизировать процесс. Появляются электронные формы, маршрутизация, уведомления, статусы и интеграции. Система успешно проходит приёмку. Но сотрудник по-прежнему получает кресло через две недели.
Почему автоматизация технически успешна, а бизнес-результат практически не изменился? Разберём эту ситуацию как учебный пример проектирования бизнес-процессов.
Проблема: автоматизировали действия, а не результат
Одна из распространённых ошибок цифровой трансформации — начинать проект с описания существующего процесса, не проверив, насколько он рационален.
Бизнес приносит разработчикам регламент.
Аналитики фиксируют его в BPMN или другом удобном представлении.
Разработчики реализуют маршрутизацию, пользовательские роли, состояния заявки, уведомления и аудит действий.
Система начинает работать в точном соответствии с техническим заданием. Именно здесь скрывается проблема!!!
Техническое задание может быть выполнено полностью, даже если исходный процесс спроектирован плохо. Автоматизация устраняет ручные действия, но не всегда устраняет причины задержек. В результате компания получает более технологичную версию прежней неэффективности.
Пример процесса AS-IS
Рассмотрим условный маршрут:
Инициатор → Руководитель → Финансы → Закупки → Руководитель → Исполнение
У каждого этапа есть исполнитель, статус, срок и уведомление. На первый взгляд всё логично: но при внимательном рассмотрении появляются вопросы.
Почему руководитель принимает решение дважды?
Что именно проверяет финансовый отдел?
Какие закупки требуют отдельной проверки бюджета?
Можно ли выдавать стандартное оборудование со склада без прохождения полного маршрута?
Какие этапы предусмотрены законодательством или внутренними обязательными правилами, а какие существуют исключительно по историческим причинам?
Если эти вопросы не задать до разработки, система закрепит все обнаруженные избыточные операции. Более того, после внедрения их бывает сложнее убрать: действия уже встроены в программную логику, роли, интеграции, отчётность и процедуры поддержки.
Сколько стоит одно лишнее согласование?
Возьмём учебную модель.
Компания обрабатывает 100 заявок в месяц, в каждой присутствует одно дублирующее согласование, руководитель тратит на него в среднем 6 минут.
За год получаем:
100 заявок × 12 месяцев × 6 минут = 7200 минут.
Это 120 часов рабочего времени в год.
Если принять условную полную стоимость рабочего часа руководителя за 2000 рублей, затраты на это действие составят:
120 × 2000 = 240 000 рублей в год.
Здесь важно не подменять понятия, 240 тысяч — расчётная стоимость затраченной мощности, а не гарантированная экономия денежных средств.
Устранение согласования само по себе не уменьшает фонд оплаты труда. Но высвобожденное время можно направить на другие задачи, снизить потребность в сверхурочной работе или уменьшить дополнительные расходы при росте нагрузки. Также расчёт не включает стоимость ожидания, повторных обращений, уведомлений и возможных задержек.
Даже одна небольшая операция на большом количестве повторений может оказаться существенной.
Время обработки и время ожидания
Ещё одна ошибка — оценивать только скорость выполнения операций внутри системы. Допустим, заявка проходит за четыре часа, из них сотрудники непосредственно работают с ней двадцать минут, остальные три часа сорок минут она ждёт следующего исполнителя.
Можно ускорить заполнение формы с трёх минут до тридцати секунд. Но это практически не изменит общее время прохождения заявки. Для анализа полезно разделять три показателя:
Lead time — время от создания заявки до получения результата.
Touch time — суммарное время непосредственной работы исполнителей.
Waiting time — время ожидания между этапами.
Если основная часть lead time приходится на очереди, оптимизировать только пользовательский интерфейс недостаточно. Нужно исследовать маршрут, количество передач, правила приоритизации и доступность исполнителей.
Как может выглядеть процесс TO-BE
Вернёмся к покупке кресла.
Вместо того чтобы автоматически переносить существующую последовательность в новую систему, сначала определим нужный результат. Сотрудник должен получить подходящее рабочее кресло в разумный срок и в пределах установленных ограничений. После этого можно спроектировать более короткий маршрут.
Для стандартных заявок, соответствующих утверждённым условиям:
Заявка → Автоматическая проверка → Выдача со склада или заказ → Завершение
Для нестандартных заявок:
Заявка → Проверка ограничений → Согласование ответственным лицом → Исполнение
Конкретная реализация зависит от политики закупок, бюджета, требований охраны труда и других обязательных норм. Мы не отменяем контроль ради скорости. Мы размещаем контроль именно там, где он необходим.
В программной архитектуре это может означать выделение правил обработки стандартных случаев и отдельного маршрута для исключений.
При этом нужно сохранить историю действий, возможность пересмотра решений и необходимые механизмы финансового контроля.
Что измерять после изменений?
До начала разработки стоит зафиксировать исходные значения показателей.
Например:
Медианное и 90-й перцентиль времени прохождения заявки.
Количество ручных операций и повторных согласований.
Долю стандартных заявок, обрабатываемых без дополнительного вмешательства.
Количество ошибок, возвратов и нарушений установленных сроков.
Расчётную стоимость обработки одной заявки.
После внедрения показатели сравниваются на сопоставимых категориях заявок. Важно отдельно отслеживать исключения. Ускорение стандартных случаев не должно приводить к пропуску обязательных проверок или увеличению количества проблемных решений.
Иначе мы просто обменяем задержки на новые риски.
Где здесь нужен искусственный интеллект?
С появлением LLM соблазн автоматизировать всё подряд стал ещё сильнее. Теперь можно попросить AI классифицировать заявку, извлечь необходимые сведения из текста, подготовить ответ, выявить недостающую информацию и предложить маршрут обработки. Это полезные возможности! Но если исходный процесс содержит два одинаковых согласования, искусственный интеллект не обязан самостоятельно понимать, что одно из них нужно удалить. Он может идеально поддерживать ошибочную бизнес-логику и для эффективного применения AI необходимы понятные границы ответственности.
Например, модель может определить тип заявки и извлечь необходимые поля.
Детерминированные проверки могут подтвердить соответствие установленному лимиту.
Система маршрутизации направит заявку по заранее определённому пути.
А неоднозначные или высокорисковые случаи попадут к ответственному сотруднику.
При работе с документами важна ещё одна характеристика: возможность проверить основания вывода модели. Если AI сообщает, что договор требует поставки за три дня, пользователь должен иметь возможность открыть соответствующий пункт.
Уверенность модели не заменяет документального подтверждения.
Пять вопросов перед автоматизацией
Для предварительного аудита процесса я использую простую логику.
Первый: какой измеримый результат должен получать пользователь или клиент?
Второй: какие действия создают ценность, а какие существуют по историческим причинам?
Третий: какие проверки обязательны и какой конкретный риск они предотвращают?
Четвёртый: где находится основная задержка — в выполнении операции или ожидании?
Пятый: какие показатели должны измениться после внедрения?
Только после получения ответов имеет смысл выбирать технологию.
Это может быть BPM-система, небольшой скрипт, интеграция, AI-агент или вообще изменение организационного правила. Иногда самое эффективное техническое решение — не писать новый код и для разработчика это звучит немного обидно.
Зато для бизнеса может оказаться очень выгодно!
Как этот принцип связан с AI-продуктами
Сейчас я развиваю собственные проекты на базе искусственного интеллекта. Один из них — TenderFocus, сервис, над которым работаю в области анализа закупочной документации. Здесь возникает та же задача: не просто прочитать документы при помощи AI, а помочь человеку быстрее находить существенные условия, проверять источники и принимать решение. Сама по себе генерация ответа не создаёт достаточной ценности, если пользователь не может проверить его точность и использовать результат в реальном рабочем процессе. Именно поэтому оптимизацию процесса и проверяемость выводов я считаю важнее количества AI-функций.
Вывод
Автоматизация не равна оптимизации!!
Можно создать безупречную систему, которая выполняет ненужные операции.
Можно ускорить обработку заявки, не уменьшив время ожидания.
Можно внедрить AI и увеличить количество действий, требующих человеческой проверки.
Поэтому последовательность должна быть обратной: сначала понять результат, затем исследовать процесс, убрать лишние действия, сохранить обязательный контроль и только после этого выбирать инструменты автоматизации. В нашем условном примере компания убрала четыре ненужных согласования. И по итогу в компании:
Сотрудники стали получать оборудование быстрее.
Пропала необходимость в дублирующих уведомлениях.
Но появился новый управленческий риск.
Руководитель, которого перестали спрашивать пять раз в день, предложил создать рабочую группу по оценке последствий сокращения рабочих групп :)
Кажется, у нас следующий проект)
Комментарии 0