Модели AS IS и TO BE: как есть и как должно быть
Разбираемся, что такое модели бизнес-процессов AS IS и TO BE, зачем они нужны и как их внедрить в свою работу
Представьте: ваша команда постоянно срывает дедлайны, задачи застревают на неопределенных этапах, и вы не понимаете, где именно происходят сбои. Скорее всего, проблема не в людях, а в том, что процессы компании никто толком не описал и не оптимизировал.
Для решения таких задач существуют AS IS и TO BE — инструменты, которые помогают увидеть реальное положение дел и спроектировать эффективное будущее. В статье разберемся, что это такое и почему без этого сложно управлять современной компанией.
AS IS и TO BE: что это и как работает
Модели AS IS и TO BE — это базовый подход к анализу и оптимизации бизнес-процессов, который строится на двух ключевых принципах: сначала детально описать «как есть» (AS IS), а затем спроектировать «как должно быть» (TO BE).
- AS IS — это модель текущего состояния процесса со всеми его недостатками, узкими местами и особенностями.
- TO BE — проект будущего состояния процесса после всех улучшений и оптимизации.
Основная идея проста: нельзя улучшить то, что не понимаешь, поэтому сначала нужно честно зафиксировать текущее положение дел.
Модель бизнес-процесса AS IS: как зафиксировать текущее состояние
Для работы с моделью нужно будет выяснить, как на самом деле происходит работа в компании, а не как это описано в регламентах или как кажется руководству.
Этапы создания модели AS IS
1. Соберите информацию. Начните с интервью всех участников процесса — от рядовых исполнителей до руководителей. Важно получить максимально полную картину:
- кто и что делает на каждом этапе,
- сколько времени занимает каждая операция,
- где возникают задержки и проблемы.
2. Понаблюдайте за реальными процессами. Теория часто расходится с практикой. Посмотрите, как работают сотрудники в обычном режиме и обратите внимание на:
- неформальные способы решения задач,
- дублирование функций,
- простои и ожидания.
3. Анализируйте документооборот и данные. Изучите, какие документы создаются, как они передаются и где хранятся. Проанализируйте ключевые метрики.
4. Визуализация процесса. Самый важный этап — создание наглядной схемы. Используйте стандартные обозначения BPMN или простые блок-схемы. Главное — чтобы схема отражала реальность, а не идеальные представления.
Практический пример создания модели AS IS
Рассмотрим разработку новой функции в IT-компании. На первый взгляд все просто: получили задачу от заказчика → разработали → протестировали → внедрили. Но в реальности модель AS IS выглядит сложнее:
- Получение задачи — менеджер получает задачу по email или в мессенджере.
- Неформальное обсуждение — обсуждение с командой в коридоре или чате.
- Поиск технических требований — выяснение деталей у заказчика (может занять несколько дней).
- Создание задачи в системе — часто с неполным описанием.
- Переброска между разработчиками — поиск свободного исполнителя.
- Разработка — с периодическими уточнениями требований.
- Множественные циклы тестирования и доработок.
- Согласование с заказчиком — часто несколько итераций.
- Внедрение — иногда откладывается из-за других приоритетов.
Такой анализ помогает увидеть реальные узкие места — неопределенность требований, отсутствие приоритизации, хаотичная передача задач.
Модель TO BE: проектирование идеального будущего
После честного анализа текущего состояния приходит время для создания модели TO BE. Это не локальное исправление недостатков, а именно комплексное переосмысление процесса.
Принципы создания эффективной модели TO BE:
→ Фокус на ценности. Каждый этап должен создавать ценность для конечного потребителя. Если этап не добавляет ценности — его нужно исключить или автоматизировать.
→ Минимизация передач. Чем меньше раз задача переходит от одного исполнителя к другому, тем быстрее и качественнее результат.
→ Прозрачность и контроль. Каждый участник работы должен понимать текущий статус задач и свою роль в общем потоке.
Этапы создания модели TO BE
1. Определение целей оптимизации. Четко сформулируйте, чего хотите достичь, например:
- Сократить время выполнения на 50%.
- Снизить количество ошибок в 2 раза.
- Уменьшить затраты на процесс на 30%.
- Повысить удовлетворенность клиентов.
2. Устранение узких мест. Для каждого узкого места из модели AS IS найдите решение, это может быть и автоматизация, и изменение последовательности операций, и перераспределение ролей, или даже внедрение новых инструментов.
3. Стандартизация. Опишите новые роли, ответственности и правила взаимодействия. Создайте шаблоны и чек-листы для типовых операций.
4. Интеграция с существующими системами. Убедитесь, что новый процесс совместим с другими процессами компании и используемыми инструментами.
Пример модели TO BE для процесса разработки
Возьмем ту же разработку и оптимизируем ее:
- Стандартизированное получение задач — все заявки поступают через единую систему с обязательными полями.
- Автоматическая оценка и приоритизация — система сама определяет сложность и важность задачи.
- Назначение исполнителя по алгоритму — учитывается загруженность и экспертиза разработчиков.
- Параллельное техническое планирование — пока разработчик изучает задачу, тестировщик готовит тест-кейсы.
- Разработка с автоматическим тестированием — код проверяется на каждом коммите.
- Автоматизированное развертывание — готовый код автоматически попадает в тестовую среду.
- Уведомление заказчика — автоматическая отправка ссылки для проверки.
Результат: время разработки сокращается в 2-3 раза, количество ошибок минимизируется, все участники процесса всегда в курсе текущего статуса.
Сравнение подходов AS IS и TO BE:
Как связаны модели AS IS и TO BE с современными подходами к управлению
Модели AS IS и TO BE отлично интегрируются с популярными методологиями управления:
Agile и Scrum. В гибких методологиях модели помогают:
- выявить препятствия для быстрой доставки ценности,
- оптимизировать церемонии и процессы команды,
- улучшить взаимодействие с заказчиками.
Kanban. Визуализация в Kanban — это фактически модель AS IS в реальном времени. Анализируя поток задач, вы можете найти узкие места и оптимизировать WIP-лимиты. Подробнее о применении Kanban читайте в нашей статье о бизнес-процессах.
Где можно применять модели AS IS и TO BE
Разберем, как эти модели могут соотноситься с разными отделами, и как можно изменить подход к работе.
HR-процессы
AS IS: Найм сотрудника занимает 2-3 месяца, включает множество собеседований, дублирование проверок, ручной ввод данных.
TO BE: Автоматизированная система скрининга, видео-интервью на первом этапе, интеграция с HR-системами, четкие критерии оценки.
Продажи
AS IS: Менеджер вручную ведет клиентов, теряет потенциальные сделки, дублирует работу с коллегами.
TO BE: CRM-система с автоматической квалификацией лидов, распределением по менеджерам, аналитикой воронки продаж.
Разработка продукта
AS IS: Идеи появляются хаотично, приоритеты меняются каждую неделю, команда не понимает бизнес-цели.
TO BE: Roadmap на основе данных и гипотез, MVP-подход, еженедельные релизы, A/B тестирование новых функций. Больше о методологиях разработки читайте в статье о роли Product Owner.
Роль современных систем управления в реализации моделей TO BE
Создать модель TO BE — только половина работы. Главная задача — внедрить новые процессы так, чтобы команда действительно им следовала. И здесь критически важны инструменты.
Почему Excel и бумажные процессы чаще всего не работают
Многие компании пытаются внедрить новые подходы с помощью регламентов в Word и отчетов в Excel. Это может скорее навредить, так как:
- Нет прозрачности — никто не видит текущий статус задач.
- Информация быстро устаревает — данные в таблицах не обновляются в реальном времени.
- Сложно контролировать соблюдение планов — люди возвращаются к старым привычкам.
Именно поэтому компании переходят на специализированные BPM-системы, которые созданы для управления бизнес-процессами.
Как системы управления помогают воплотить модель TO BE
Для успешного внедрения моделей мало просто схем — нужны инструменты, которые поддерживают новые процессы в повседневной работе.
Визуализация. Каждый этап процесса TO BE становится колонкой на канбан-доске. Когда задача перемещается между колонками, все участники видят реальный прогресс.
Автоматизация. Настроенные правила автоматически направляют задачи на следующий этап при выполнении определенных условий. Больше не нужно помнить все нюансы — система сама ведет по правильному пути.
Контроль узких мест Лимиты незавершенной работы (WIP) физически не позволят перегружать критические этапы. Встроенная аналитика сразу показывает, где именно задачи замедляются. Подробнее о том, как это работает на практике, можно прочитать в гайде по управлению проектами.
Типичные ошибки при реализации моделей AS IS и TO BE
Разберем самые популярные ошибки, с которым можно столкнуться при внедрении такого подхода.
Ошибки в модели AS IS
Ошибки в модели TO BE
Как изменить эффективность работы с AS IS к TO BE
Чтобы убедиться, что оптимизация принесла результат, нужно измерять ключевые показатели до и после внедрения:
Время выполнения (Lead Time). Эта метрика показывает полное время от поступления заявки до получения результата. Она помогает оценить скорость работы процесса.
Время обработки (Cycle Time). Отчет о времени активной работы над задачей, который также показывает эффективность самого процесса.
Пропускная способность (Throughput). Количество задач, выполняемых за определенное время.
Качество результата Количество ошибок и возвратов на доработку. О том, как повысить качество процессов с помощью моделей зрелости, читайте в нашей статье.
Пример измерений:
Такие измерения дают объективную картину улучшений и помогают принимать решения о дальнейшей оптимизации.
Внедрение изменений: от модели к реальности
Создание модели TO BE — это только начало. Самая сложная часть — внедрить изменения так, чтобы команда действительно начала работать по-новому.
Этапы успешного внедрения
1. Подготовка команды. Объясните, зачем нужны изменения и покажите, как новый процесс поможет каждому сотруднику.
2. Пилотный запуск. Выберите небольшой участок для тестирования, чтобы собрать обратную связь и доработать модель.
3. Поэтапное масштабирование. Постепенно расширяйте сферу, где можно внедрить новый процесс. Переводите команды по мере готовности.
Главная проблема большинства проектов оптимизации — сопротивление команды изменениям. Люди привыкают к определенному способу работы и не хотят перестраиваться. Поэтому нужно выбрать подход, который минимизирует стресс от внедрения.
Эволюционные изменения вместо революционных. Лучший способ — начать с точной копии текущего процесса AS IS в новой системе, а затем постепенно вносить улучшения. Каждое изменение можно протестировать и при необходимости откатить.
Обучение в процессе работы. Когда все визуализировано и интуитивно понятно, команда осваивает новые подходы естественным образом. Не нужно проводить длительные тренинги — люди учатся на практике, решая реальные задачи.
Заключение
Модели AS IS и TO BE — не просто теоретические концепции, а инструменты, которые помогают компаниям системно подходить к оптимизации своей работы.
Начните с малого: выберите один процесс, который вызывает больше всего проблем, опишите его текущее состояние AS IS, спроектируйте улучшенную версию TO BE и проведите пилотное внедрение. По мере накопления опыта сможете масштабировать подход на всю компанию.
