Автоматизировать хаос или сначала оптимизировать процесс

Система ускоряет и полезное, и лишнее

Понедельник, девять утра. Сотрудник получает заявку по электронной почте, переносит данные в таблицу, уточняет недостающее поле в чате, отправляет файл руководителю и ждёт согласования. После возврата он повторяет часть действий. В проекте автоматизации этот маршрут уже нарисован: форма вместо письма, карточка вместо таблицы, электронные согласования вместо сообщений.

Выглядит как прогресс. Но остаётся более важный вопрос: зачем нужны все шаги и какое решение принимается на каждом из них?

Автоматизация хорошо исполняет формализованный маршрут. Она не решает сама, нужен ли второй ввод данных, какое согласование действительно меняет результат и кто отвечает за нестандартный случай. Если эти вопросы не разобраны, система закрепляет текущий порядок. После запуска обход лишнего шага становится не просто привычкой, а нарушением настроенного процесса.

Поэтому выбор технологии начинается после управленческого решения о целевом процессе. Не обязательно перестраивать всю компанию и месяцами рисовать схемы. Достаточно взять один сквозной процесс, проверить реальные операции и отделить четыре действия: что остановить, что упростить, что стандартизировать и что автоматизировать.

Что автоматизация не исправляет

У процесса есть как минимум четыре дефекта, которые нельзя устранить одним переносом маршрута в цифровую систему.

1. Действие не создаёт результата. Данные повторно переписывают между каналами, отчёт формируют, но не используют, документ хранит копию информации из другой системы. Автоматизация сократит время действия, но не ответит, зачем оно существует.
2. Передача не содержит решения. Заявка проходит несколько согласований, однако критерии каждого решения не различаются. Электронный маршрут ускорит доставку карточки и одновременно сохранит очередь ожидания.
3. Правило зависит от памяти сотрудника. Одинаковые случаи обрабатываются по-разному, обязательные данные уточняются после старта, основания возврата не зафиксированы. Система потребует явного правила — и команда рискует принять первую удобную формулировку за правильную.
4. Исключение не имеет владельца. Обычный сценарий понятен, а спорная заявка уходит в чат, руководителю или «тому, кто знает». Без маршрута исключений цифровой процесс остановится либо сохранит ручной параллельный контур.

Процессный подход ISO 9001 предлагает сначала определить ожидаемый результат, входы и выходы, последовательность, взаимодействия, ответственность, риски и способы проверки, а затем управлять процессом как циклом улучшения. Это следует из официального руководства ISO/TC 176. В России ГОСТ Р ИСО 9001-2015 действует и предназначен для организаций любого вида и размера. Упоминание стандарта не означает, что компании обязательно нужна сертификация. Здесь важен сам управленческий каркас.

Главная граница проста: технология может выполнить правило, но решение о ценности действия, допустимом риске и владельце результата остаётся за бизнесом.

Карта четырёх решений до настройки системы

Возьмите один процесс от события до результата и последовательно заполните четыре строки. Не начинайте с функций будущей системы. Начинайте с работы, которая должна остаться после изменений.

Этот порядок не требует доводить процесс до полной неизменности. Живой процесс всё равно будет развиваться. Требуется другое: стабильное ядро должно быть достаточно понятно, чтобы команда могла отличить штатный случай от исключения и проверить, улучшился ли результат.

Исторический пример полезен именно последовательностью, а не цифрами. В публичном отчёте Росатома за 2011 год среди задач производственной системы отдельно названы диагностика и оптимизация процессов, запуск программ по результатам диагностики, выстраивание потоков и стандартизация рабочих мест. Это промышленный контекст пятнадцатилетней давности, поэтому его нельзя переносить как универсальную инструкцию. Но он хорошо показывает различие между улучшением порядка работы и внедрением инструмента.

Как увидеть реальный процесс без месяца моделирования

Регламент описывает договорённость. Для решения об оптимизации нужно увидеть исполнение. Иногда они совпадают. Иногда схема заканчивается словами «согласовать с руководителем», а реальная работа продолжается в письмах, таблицах и звонках.

Для первой диагностики возьмите десять последних завершённых экземпляров одного процесса. Десять — рабочая рекомендация НТА, а не статистическая гарантия. Если операции сильно различаются по типу, риску или подразделению, выборку нужно расширить и разделить на однородные группы.

По каждому экземпляру зафиксируйте:

• событие, которое запустило процесс;
• ожидаемый результат и фактический исход;
• роли и передачи между ними;
• время работы и время ожидания;
• возвраты и причину каждого возврата;
• повторный ввод и ручные сверки;
• исключения и человека, который принял решение;
• источник данных, по которому можно повторить проверку.

Если системы ведут журналы событий, они помогают увидеть фактические маршруты. Для базового анализа нужны хотя бы идентификатор экземпляра, название события и отметка времени; качество данных определяет качество вывода. Это подробно разобрано в открытой академической главе Foundations of Process Event Data. Но process mining не обязателен. Когда цифрового следа нет, достаточно наблюдения, интервью с участниками и ручной выборки — с честной оговоркой о границах данных.

Не пытайтесь описать всё. Глубина модели должна отвечать на решение: какие потери подтверждены, какой целевой маршрут предлагается и что пока неизвестно. Схема ради схемы — ещё один процесс без пользователя результата.

Когда процесс достаточно стандартизирован

Стандартизация не означает запрет на исключения. Она означает, что обычный сценарий повторяем, а исключение распознаётся и получает владельца.

Перед настройкой системы проверьте шесть условий.

1. Результат назван. Команда одинаково понимает, чем заканчивается процесс для клиента или внутреннего получателя.
2. Вход определён. Известно, какое событие запускает работу и какие данные обязательны в этот момент.
3. Критерии решений различаются. Каждое согласование или проверка имеет собственный вопрос и основание.
4. Роли назначены. Понятно, кто выполняет шаг, кто владеет результатом и кто решает нестандартный случай.
5. Исключения ограничены. Основные виды отклонений перечислены; для неизвестного случая есть безопасная остановка и эскалация.
6. Есть базовый уровень. До изменения измерены хотя бы время цикла, возвраты или ошибки — те характеристики, ради которых начинается проект.

Если хотя бы одно из первых пяти условий отсутствует, настройка превращается в скрытое проектирование бизнес-правил силами интегратора и интерфейса. Это не запрет на проект. Это сигнал вернуть решение владельцу процесса до того, как спорная логика станет дорогой конфигурацией.

Связанная диагностика готовности процесса к автоматизации отвечает на соседний вопрос: какой процесс вообще стоит брать в обследование. Здесь задача уже: исправить дефекты внутри выбранного процесса до автоматизации.

Как измерить, стало ли лучше

Скорость — заметный, но не единственный результат. Исследования redesign рассматривают взаимосвязанные измерения времени, стоимости, качества и гибкости. Улучшение одного показателя может ухудшить другой: например, жёсткое правило сокращает вариативность, но создаёт больше ручных исключений. Обзор таких эвристик опубликован в рецензируемой работе Reijers и Limam Mansar.

Для одного процесса выберите небольшой набор показателей, связанный с решением:

• время: полный цикл и ожидание между действиями;
• качество: доля возвратов, ошибок или незавершённых случаев;
• стоимость: трудоёмкость ручных операций и сопровождения;
• гибкость: доля исключений, которые процесс обрабатывает без неуправляемого обхода;
• результат: характеристика, ради которой существует процесс — она выбирается владельцем, а не копируется из чужого кейса.

Сначала зафиксируйте исходный уровень на сопоставимой выборке. Затем измените процесс и проверьте тот же набор. Сам факт запуска системы не является показателем улучшения. Рецензируемое исследование Zellner и соавторов предлагает отдельно проверять, действительно ли практика redesign внедрена, и отдельно — изменились ли показатели процесса. Для управленческого решения это важное различие: новая форма может быть готова, а лишнее согласование всё ещё работать.

Не обещайте процент экономии до измерения. Ценность первой итерации может состоять в более скромном результате: команда впервые видит границы процесса, причины возвратов и владельцев исключений. Это уже основа для следующего решения, но ещё не финансовый эффект.

Где здесь НТА

НТА начинает автоматизацию с обследования выбранного процесса: результата, фактического маршрута, данных, исключений и ответственности. После этого можно осмысленно выбирать способ реализации — доработку корпоративной системы, BPM-маршрут, интеграцию или другой инструмент.

Для процессов продаж отдельный разбор внедрения CRM без автоматизации старых ошибок показывает, какие решения коммерческая функция должна принять до настройки. BPMSoft Старт — один из возможных контуров реализации, когда правила и границы процесса уже определены. Платформа не подменяет это решение.

Если требуется проверить один сквозной процесс до проекта, команда НТА может провести рабочую сессию по текущему маршруту, потерям, исключениям и доказательствам готовности. Результатом должен стать не каталог функций, а решение: что убрать, что закрепить и только затем что автоматизировать.

Тест понедельником

В ближайший рабочий день выберите один процесс и откройте десять последних завершённых случаев. На одной странице отметьте:

1. Шаги, после которых результат не меняется.
2. Передачи и ожидания без отдельного решения.
3. Возвраты из-за данных, которые можно было запросить на входе.
4. Правила, которые два сотрудника объясняют по-разному.
5. Исключения, у которых нет явного владельца.

Для каждого пункта выберите одно действие: остановить, упростить, стандартизировать или оставить для автоматизации. Если команда может объяснить целевой маршрут, критерии и базовый показатель без слов «обычно» и «дальше разберёмся», процесс готов к техническому проектированию. Если нет — пауза дешевле конфигурации, которую придётся обходить с первого понедельника.

Будущее должно выдержать понедельник: сотрудник понимает следующий шаг, исключение не разрушает маршрут, руководитель видит достоверный результат, а система исполняет правило, которое бизнес выбрал осознанно.

Важное уведомление

Материал носит информационный характер и не является индивидуальной консультацией, проектной документацией, инструкцией по внедрению или гарантией результата. Применимость описанных подходов зависит от процессов, систем, данных, требований безопасности и иных условий конкретной организации. Перед внедрением или изменением ИТ‑систем необходимо самостоятельно оценить риски и привлечь профильных специалистов.