AS-IS vs TO-BE на собеседовании системного аналитика

Зачем спрашивают на собесе SA

AS-IS / TO-BE — стандартный подход к описанию изменений в системе / процессе. На собесе SA: «как ты подходишь к редизайну процесса», «что входит в gap-анализ», «зачем transition requirements».

AS-IS: что это и зачем

AS-IS — текущее состояние процесса / системы. «Как сейчас работает».

Зачем описывать:

• Понимать boundary текущей системы.
• Найти проблемы, которые надо решить.
• Зафиксировать opcode для сравнения.
• Избежать «перепроектирования» с потерей функциональности.

Что описывают:

• Бизнес-процессы (BPMN, swimlane).
• Системы и интеграции (component / context diagrams).
• Данные (ERD, data flow).
• Боли и проблемы (pain points).
• Метрики (cycle time, error rate, cost).

Источники:

• Интервью со стейкхолдерами / операторами.
• Документация (если есть).
• Наблюдение за работой (job shadowing).
• Логи / метрики систем.
• BPMN-моделирование с командой.

TO-BE: проектирование

TO-BE — целевое состояние. «Как должно быть».

Принципы:

• Решает зафиксированные pain points.
• Соответствует бизнес-целям и стратегии.
• Учитывает ограничения (бюджет, регуляторика, технологии).
• Может быть нескольких вариантов — сравнить.

Что включает:

• Новые процессы (BPMN TO-BE).
• Архитектура (нужны ли новые системы / интеграции).
• Изменения данных (миграция).
• Метрики достижения цели.

Подход:

• Не «инкрементальные правки» AS-IS, а свежий взгляд (хотя бы на проектировании).
• Затем сверка с реальностью — что реально внедрить.

Gap-анализ

Gap = разница между AS-IS и TO-BE.

Что анализировать:

• Functional gaps. Какие функции добавить / убрать.
• Process gaps. Какие шаги изменить.
• Data gaps. Какие сущности новые, миграция.
• Integration gaps. Какие интеграции добавить.
• Skill gaps. Какие навыки команды нужны.
• Technology gaps. Какие инструменты внедрить.

Формат:

Приоритизация gaps. MoSCoW (must, should, could, won't), business value vs effort.

Transition requirements

Transition = переход AS-IS → TO-BE. Не часть TO-BE, но критично для проекта.

Что входит:

• Миграция данных (формат, объём, downtime).
• Параллельная работа AS-IS и TO-BE (если миграция поэтапная).
• Обучение пользователей.
• Переход contract'ов с подрядчиками / поставщиками.
• Регуляторные одобрения.
• Откат (rollback plan).

Часто забывают transition в TZ — потом «у нас всё готово, но как переехать»?

Документация и нотации

Для AS-IS:

• BPMN — бизнес-процесс.
• Use case (UML) — функциональный взгляд.
• Sequence diagram — взаимодействие.
• Component diagram — архитектура.
• ERD — данные.

Для TO-BE:

• Те же нотации.
• Сравнительная матрица AS-IS vs TO-BE.
• Roadmap миграции.

Для Gap:

• Таблицы (как выше).
• Бэклог изменений.
• RACI matrix кто за что отвечает.

Частые ошибки

Слишком детальный AS-IS. На project можно потратить 6 месяцев на «как сейчас». Описывай ровно настолько, чтобы понять gap.

Идеализировать TO-BE. Реалистичность важнее красоты. Сначала bounded TO-BE, потом dream-state.

Игнорировать transition. Без плана миграции проект не выйдет в прод.

Не проверять с пользователями. Spec на бумаге работает, в реале люди ругаются. Прототипирование, walkthroughs.

TO-BE без метрик успеха. Как поймём, что сделали лучше? Цель должна быть измеримой.

Менять AS-IS только один раз. Реальность сложнее — итерации интервью, валидация.

Документировать всё в Word. BPMN / UML — инструменты для процесса. Word — для общих описаний и протоколов.

Связанные темы

• UML и BPMN на собесе SA
• BPMN gateways на собесе SA
• User Stories и Acceptance Criteria для SA
• ТЗ vs SRS на собесе SA
• Подготовка к собесу системного аналитика

FAQ

Сколько времени тратить на AS-IS?

Зависит от scope. На небольшую фичу — 1-2 интервью + диаграмма. На enterprise migration — недели/месяцы. Правило: пока понимаешь существенные нюансы.

Можно ли пропустить AS-IS для greenfield проекта?

Да, частично — нет существующего процесса. Но обычно есть «как-то делается сейчас» вне ИТ (Excel, Word, e-mail) — стоит описать.

Что такое stretch / blueline?

Альтернативные термины: stretch (TO-BE) и blueline (текущий). Используются реже.

Это официальная информация?

Нет. Статья основана на BABOK Guide (IIBA), стандартных практиках бизнес-анализа.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.