НУЖНА ЛИ СХЕМА AS IS ПЕРЕД АВТОМАТИЗАЦИЕЙ ПРОЦЕССОВ: ПОЧЕМУ БЕЗ ПОНИМАНИЯ ТЕКУЩЕЙ РЕАЛЬНОСТИ НЕЛЬЗЯ МЕНЯТЬ ПРОЦЕСС 

23 июня 2026

Ошибка в процессе быстро превращается в денежную потерю. 

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


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


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

Вопрос не в том, делать AS IS или нет. Вопрос — какой глубины. 

AS IS нужен в большинстве проектов, но глубина описания различается. Чем больше в процессе участников, ручных операций, согласований, исключений и системных стыков, тем подробнее должно быть описание текущего состояния. Глубина AS IS зависит и от приоритета процесса: его важности, проблемности и влияния на другие процессы. В закупках, управлении запасами, возвратах, обработке претензий, планировании производства, распределении заказов и документообороте AS IS обычно оправдан уже на старте. Такая схема показывает, где процесс ветвится, кто принимает решение, на каком шаге возникает задержка и какие данные переходят между ролями и системами.

Для каждого процесса одинаковая глубина не требуется. Если процесс линейный, короткий, выполняется одной ролью и почти не имеет исключений, детальная отрисовка часто не нужна. Речь может идти о локальной автоматизации уведомления, переносе простой формы в цифровой вид или настройке типового согласования внутри одного подразделения. В таких случаях достаточно кратко зафиксировать текущие шаги, входы, выходы и правила принятия решения. Это AS IS в упрощенном виде. 

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

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


Практическая польза AS IS — он отделяет реальные проблемы от предположений. В дистрибуции часто кажется, что причина срыва поставки — склад, хотя источник задержки скрыт в правилах резервирования или ручной перепроверке заказа. В ритейле нередко пытаются ускорить приемку товара через новую систему, хотя узкое место — в расхождении ролей между магазином и центральным офисом. Схема позволяет увидеть процесс целиком и не автоматизировать хаос.

Глубина описания должна соответствовать цели проекта. Для выбора организационных улучшений обычно достаточно уровня этапов, ролей, документов, систем и основных развилок. Для постановки задачи на разработку требуется большая глубина — с бизнес-правилами, исключениями, статусами, точками контроля и составом данных. Избыточная детализация вредна так же, как и поверхностность: команда тратит время на мелочи и теряет фокус на решающих узлах процесса.


Заниматься отрисовкой AS IS должен не один человек. Бизнес-пользователь знает реальную практику, аналитик превращает разрозненные действия в рабочую модель. Самый устойчивый вариант — совместная работа владельца процесса и аналитика с верификацией у непосредственных исполнителей. Именно исполнители лучше других знают фактический ход работы, исключения и неформальные обходные сценарии. Внешний консультант полезен там, где нужна независимая оценка и опыт похожих проектов. Тогда схема отражает реальность и сохраняет практическую ценность для проекта.

Работа без AS IS повышает риск трех ошибок: автоматизации лишних действий, пропуска критичных исключений и переноса внутренних противоречий в будущее ПО. В результате команда получает систему, которая плохо поддерживает операционную работу. После запуска это проявляется в обходных таблицах, ручных корректировках и новых запросах на доработку.

Меняется не сам AS IS, а способ его фиксации. Для простых процессов подходят короткие диагностические сессии, наблюдение за работой пользователей, интервью с участниками, быстрое прототипирование и изучение данных из действующих систем. Эти методы помогают собрать минимальный AS IS быстрее, но не заменяют понимание текущего процесса там, где цена ошибки высока.

Связь AS IS с будущим ПО прямая — модель «как есть» задает границы проектирования «как должно быть». Она показывает, что действительно нужно менять, что можно убрать и что необходимо сохранить в новой системе ради устойчивости бизнеса.

Правило простое: глубина AS IS определяется ценой ошибки. Высокая цена — детальная схема. Простой локальный процесс — краткая фиксация. Но в любом случае: не начинайте автоматизацию без понимания текущего состояния. Иначе вы автоматизируете хаос. 

Ошибка в процессе быстро превращается в денежную потерю. 

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


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


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

Вопрос не в том, делать AS IS или нет. Вопрос — какой глубины. 

AS IS нужен в большинстве проектов, но глубина описания различается. Чем больше в процессе участников, ручных операций, согласований, исключений и системных стыков, тем подробнее должно быть описание текущего состояния. Глубина AS IS зависит и от приоритета процесса: его важности, проблемности и влияния на другие процессы. В закупках, управлении запасами, возвратах, обработке претензий, планировании производства, распределении заказов и документообороте AS IS обычно оправдан уже на старте. Такая схема показывает, где процесс ветвится, кто принимает решение, на каком шаге возникает задержка и какие данные переходят между ролями и системами.

Для каждого процесса одинаковая глубина не требуется. Если процесс линейный, короткий, выполняется одной ролью и почти не имеет исключений, детальная отрисовка часто не нужна. Речь может идти о локальной автоматизации уведомления, переносе простой формы в цифровой вид или настройке типового согласования внутри одного подразделения. В таких случаях достаточно кратко зафиксировать текущие шаги, входы, выходы и правила принятия решения. Это AS IS в упрощенном виде. 

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


Практическая польза AS IS — он отделяет реальные проблемы от предположений. В дистрибуции часто кажется, что причина срыва поставки — склад, хотя источник задержки скрыт в правилах резервирования или ручной перепроверке заказа. В ритейле нередко пытаются ускорить приемку товара через новую систему, хотя узкое место — в расхождении ролей между магазином и центральным офисом. Схема позволяет увидеть процесс целиком и не автоматизировать хаос.

Глубина описания должна соответствовать цели проекта. Для выбора организационных улучшений обычно достаточно уровня этапов, ролей, документов, систем и основных развилок. Для постановки задачи на разработку требуется большая глубина — с бизнес-правилами, исключениями, статусами, точками контроля и составом данных. Избыточная детализация вредна так же, как и поверхностность: команда тратит время на мелочи и теряет фокус на решающих узлах процесса.


Глубина описания должна соответствовать цели проекта. Для выбора организационных улучшений обычно достаточно уровня этапов, ролей, документов, систем и основных развилок. Для постановки задачи на разработку требуется большая глубина — с бизнес-правилами, исключениями, статусами, точками контроля и составом данных. Избыточная детализация вредна так же, как и поверхностность: команда тратит время на мелочи и теряет фокус на решающих узлах процесса.

Заниматься отрисовкой AS IS должен не один человек. Бизнес-пользователь знает реальную практику, аналитик превращает разрозненные действия в рабочую модель. Самый устойчивый вариант — совместная работа владельца процесса и аналитика с верификацией у непосредственных исполнителей. Именно исполнители лучше других знают фактический ход работы, исключения и неформальные обходные сценарии. Внешний консультант полезен там, где нужна независимая оценка и опыт похожих проектов. Тогда схема отражает реальность и сохраняет практическую ценность для проекта.

Работа без AS IS повышает риск трех ошибок: автоматизации лишних действий, пропуска критичных исключений и переноса внутренних противоречий в будущее ПО. В результате команда получает систему, которая плохо поддерживает операционную работу. После запуска это проявляется в обходных таблицах, ручных корректировках и новых запросах на доработку.

Меняется не сам AS IS, а способ его фиксации. Для простых процессов подходят короткие диагностические сессии, наблюдение за работой пользователей, интервью с участниками, быстрое прототипирование и изучение данных из действующих систем. Эти методы помогают собрать минимальный AS IS быстрее, но не заменяют понимание текущего процесса там, где цена ошибки высока.

Связь AS IS с будущим ПО прямая — модель «как есть» задает границы проектирования «как должно быть». Она показывает, что действительно нужно менять, что можно убрать и что необходимо сохранить в новой системе ради устойчивости бизнеса.

Правило простое: глубина AS IS определяется ценой ошибки. Высокая цена — детальная схема. Простой локальный процесс — краткая фиксация. Но в любом случае: не начинайте автоматизацию без понимания текущего состояния. Иначе вы автоматизируете хаос. 

Если вы пропустили вебинар — не беда 

Полная запись выступления и все презентационные материалы доступны ниже. 

Сохраните и отправьте коллегам, кто отвечает за рост продаж и работу с данными. Также мы дарим вам БЕСПЛАТНЫЙ аудит готовности ваших данных и процессов к применению нового подхода в управлении продажами — для этого напишите нам кодовое слово “Аудит 9/25”.

Читать другие статьи