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