TO-BE
TO‑BE (буквально «как должно быть») — это целевое состояние бизнес-процессов, то есть как процессы должны работать после оптимизации, автоматизации или изменения организационной структуры.
Главная цель TO‑BE модели:
- устранение узких мест, дублирования и ошибок,
- создание прозрачных и стандартизированных процессов,
- подготовка к автоматизации и масштабированию.
Разница между AS‑IS и TO‑BE
| Характеристика | AS‑IS (как есть) | TO‑BE (как должно быть) |
|---|---|---|
| Цель | Фиксация текущих процессов | Оптимизация и улучшение процессов |
| Подход | Наблюдение, анализ, сбор данных | Проектирование, стандартизация |
| Использование | Диагностика проблем | Внедрение изменений и автоматизация |
| Фокус | Текущие проблемы | Эффективность, скорость, прозрачность |
TO‑BE строится на основе AS‑IS, исправляя недостатки и оптимизируя поток работы.
Как проектировать TO‑BE
Сбор данных AS‑IS
Интервью с сотрудниками, анализ существующих схем, выявление узких мест.Выбор нотации
- BPMN — для визуализации ролей и потоков
- IDEF0 — для декомпозиции процессов
- UML — для ИТ-систем и программной реализации
Построение схемы TO‑BE
- Контекстная диаграмма: процесс и окружение
- Декомпозиция: подпроцессы и этапы
- Детальные потоки: задачи, роли, решения
Пример мини-таблицы «TO‑BE шаги»:
| Этап TO‑BE | Действие | Ответственный |
|---|---|---|
| Анализ текущего процесса | Сбор данных, интервью, наблюдения | Бизнес-аналитик |
| Оптимизация шагов | Исключение лишних действий | Руководитель отдела |
| Создание схемы | BPMN диаграмма | Процессный аналитик |
| Верификация | Согласование с отделами | Руководство |
Когда использовать TO‑BE
- При автоматизации и внедрении ERP/BPM-систем
- Для стандартизации процессов и повышения прозрачности
- При переходе от AS‑IS к целевым процессам
- Для выявления и устранения проблем: дубли, задержки, ошибки
TO‑BE помогает компаниям работать быстрее, прозрачнее и эффективнее.
Основные ошибки при построении TO‑BE
- Игнорирование реальности AS‑IS → модель нереализуемая
- Слишком сложные схемы → трудность восприятия
- Игнорирование ресурсов, ролей, ограничений
Пример модели TO-BE
Приведем пример формализованного основного бизнес-процесса мебельной компании в модели TO-BE спроектированного на основе нотации BPMN.
Формализованный бизнес-процесс «Заказ на корпусную мебель»:
Больше примеров моделей в статье.
Заключение
TO‑BE модель процессов — ключевой инструмент для оптимизации, стандартизации и автоматизации бизнес-процессов. Даже короткая схема TO‑BE позволяет:
- увидеть слабые места,
- устранить дубли,
- подготовить процессы к внедрению систем.
Чек-лист
- Составить AS‑IS модель
- Определить цели TO‑BE
- Выбрать нотацию (BPMN/IDEF0/UML)
- Создать схему TO‑BE
- Проверить и согласовать с командой
- Внедрить и контролировать эффективность
FAQ: TO-BE
Что такое TO-BE простыми словами?
TO-BE (читается «ту би») — это модель целевого состояния бизнес-процессов «как должно быть» после оптимизации, автоматизации или реорганизации. Главная цель: устранить узкие места, дублирование ошибок и подготовить процессы к масштабированию.
Чем TO-BE отличается от AS-IS?
AS-IS фиксирует текущее состояние «как есть» с реальными проблемами. TO-BE проектирует будущее «как должно быть» после улучшений. AS-IS отвечает на вопрос «что происходит сейчас?», TO-BE — «как мы хотим, чтобы работало?». TO-BE всегда строится на основе AS-IS.
Как построить TO-BE модель? Пошаговая инструкция
Собрать и проанализировать AS-IS (интервью, наблюдения, документация)
Выявить узкие места и точки оптимизации
Выбрать нотацию моделирования (BPMN/IDEF0/UML)
Построить схему: контекстная диаграмма → декомпозиция → детальные потоки с ролями и решениями
Проверить и согласовать с командой
Какую нотацию выбрать для TO-BE: BPMN или IDEF0?
BPMN — стандарт для визуализации ролей и потоков, понятен и бизнесу, и IT. IDEF0 — для строгой функциональной декомпозиции (военные/госпроекты). Для большинства коммерческих проектов выбирают BPMN 2.0.
Какие главные ошибки при построении TO-BE?
Игнорирование реальности AS-IS → модель нереализуема
Слишком сложные схемы → никто не понимает
Игнорирование ресурсов, ролей и ограничений
Идеализация без учёта бюджетов и сроков
Где взять примеры TO-BE моделей?
Типовые примеры: кредитный скоринг в банке, обработка страховой претензии, согласование закупок, приём заказа в мебельной компании (BPMN-схема с пулами, дорожками, шлюзами).
TO-BE и BABOK — как связаны?
BABOK — международный стандарт бизнес-анализа. В нём модели AS-IS/TO-BE — обязательная техника для анализа требований и проектирования решений. Знание BABOK требуется для позиции бизнес-аналитика при работе с TO-BE.
TO-BE в Agile — как использовать?
В Agile TO-BE формирует vision целевого процесса. Требования к TO-BE собираются в бэклог и реализуются итерациями. Приоритизация задач идёт от целевой модели процесса.
TO-BE и BPMN 2.0 — обязательно ли использовать?
BPMN 2.0 — самый популярный стандарт для TO-BE, но не единственный. Можно использовать UML Activity, IDEF0, ARIS eEPC. Главное — чтобы нотация была понятна всем участникам. BPMN 2.0 оптимален для сложных процессов с ветвлениями.
TO-BE и внедрение ERP — как связаны?
Перед внедрением ERP (1С, SAP, Microsoft Dynamics) обязательна модель TO-BE. Она показывает, как процессы будут работать в целевой системе, выявляет GAP-разрывы между AS-IS и стандартными функциями ERP. TO -BE определяет объём доработок и кастомизации.
Как измерить эффективность TO-BE? Какие KPI использовать?
Сравнивай метрики до и после: время цикла процесса, процент ошибок/переделок, загрузка сотрудников, удовлетворённость клиентов (NPS), стоимость операции. TO-BE должна содержать целевые KPI для каждого процесса.
Нужно ли описывать все процессы компании в TO-BE?
Нет. Выбирай ключевые и сквозные процессы, которые влияют на клиента, прибыль и стратегические цели. Второстепенные — укрупнённо или после пилотных проектов.
Как часто обновлять TO-BE модель?
При изменении стратегии, внедрении новых систем или реорганизации. В стабильной среде — 1 раз в год. Иначе модель расходится с реальностью и теряет ценность для управления