AS IS и TO BE: как описать и улучшить бизнес-процессы

Модели AS IS и TO BE помогают сначала увидеть бизнес-процесс таким, какой он есть на самом деле, а затем описать его желаемое состояние. Между двумя схемами находится план изменений: какие действия убрать, что автоматизировать, где перераспределить роли и как изменить логику работы, чтобы достичь цели компании.

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

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

TO BE, или «как будет», описывает улучшенный вариант того же процесса. В нём можно убрать ненужные шаги, сократить число согласований, повысить качество обслуживания и закрепить новый порядок. Целевая модель всегда опирается на AS IS: проектировать идеальное состояние без знания реальности рискованно.

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

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

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

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

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

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

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

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

Целевая модель связана с бизнес-результатом: снижением расходов, ускорением операций, повышением качества сервиса, ростом прибыли или возможностью масштабироваться. Если польза не определена, TO BE рискует превратиться в набор изменений, которые сложно оценить и ещё сложнее защитить перед командой.

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

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

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

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

Единый набор условных обозначений облегчает чтение. Если один и тот же символ на разных участках означает разные действия, участники будут трактовать схему по-своему. Подписи должны быть короткими, но достаточными, чтобы понять действие без устного объяснения автора.

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

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

AS IS-анализ отдела продаж выявляет участок, на котором теряются лиды, затянутые согласования и перегруженных менеджеров. TO BE описывает более быстрый маршрут заявки, автоматизацию воронки и распределение обращений, которое снижает ручную нагрузку.

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

AS IS обнаруживает потери товара, ошибки учёта и задержки поставок. В целевой модели можно автоматизировать складские операции, сократить время комплектации и улучшить маршрутизацию. Изменения проектируют только после проверки фактического пути товара и информации.

Службы поддержки используют модели, чтобы быстрее отвечать, распределять обращения и контролировать SLA. В TO BE запросы могут автоматически классифицироваться, назначаться ответственным, а клиент — получать уведомление после решения вопроса.

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

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

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

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

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

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

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

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

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

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

Покажите карту каждому участнику процесса и соберите поправки. Когда сотрудники подтверждают, что схема отражает фактическую работу, этап AS IS можно считать завершённым. Только теперь переходите к поиску улучшений.

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

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

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

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

Результат формулируйте измеримо. В исходнике приведены примеры: сократить обработку заявки с 40 до 10 минут, снизить количество ошибок на 60% или уменьшить нагрузку менеджеров на 30%. Такие ориентиры позволяют проверить, сработала ли новая модель после внедрения.

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

Обсудите TO BE с владельцем и участниками процесса. Люди должны понимать не только новый порядок, но и причину изменений. По возможности проверьте модель на ограниченном участке, соберите фактические результаты и скорректируйте спорные места до масштабирования.

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

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

Целевой процесс, созданный без AS IS, опирается на предположения. Команда может автоматизировать несуществующую последовательность, добавить ненужный контроль или не заметить реальную причину ошибки. Сначала факты, затем решения.

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

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

Если схема создаётся только руководством или аналитиком, она может не учесть реальную практику. Без участия команды люди также хуже понимают смысл нового порядка и легче возвращаются к старым привычкам.

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

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

Колонки доски отражают этапы целевого процесса, например бэклог, работу, проверку, согласование и готовность. Карточки движутся между ними, поэтому команда видит текущее состояние. Метки, приоритеты, ответственные, дедлайны и чек-листы добавляют нужный контекст.

Если доска показывает поток, Гант раскрывает сроки, зависимости и загрузку ресурсов. На диаграмме заметны слишком длинные согласования, сильные зависимости и растянутые этапы. Эти наблюдения помогают сопоставить целевую схему с реальным календарным планом.

Одна из частых проблем AS IS — неизвестно, кто должен выполнить следующий шаг. В TO BE можно настроить автоматическую передачу ответственности. Например, после подготовки материала задача назначается редактору, после редактуры — дизайнеру, затем — сотруднику, отвечающему за выпуск.

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

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

Соедините визуальную схему с реальными задачами и показателями. Наблюдайте, как процесс работает после запуска, сравнивайте результат с целями TO BE и корректируйте модель, если обнаружились новые ограничения. Целевое состояние — не финальная картинка навсегда, а проверяемая версия улучшенного порядка.

Закрепляйте каждый переход от AS IS к TO BE конкретным изменением: новой последовательностью этапов, назначением роли, правилом автоматизации или обновлённой инструкцией. Если отличие между схемами нельзя найти в реальной работе, оно останется только на диаграмме. После запуска снова соберите данные и обратную связь участников: они покажут, сократилось ли время, стало ли меньше ошибок и не появился ли новый обходной путь вместо старого.