Что такое Should Do?

Should Do: Разрыв между текущим и желаемым состоянием

Should Do ("Что нужно делать") — это одна из ключевых концепций в бизнес-анализе. Она описывает разрыв между тем, как процесс работает сейчас (As Is), и тем, как он должен работать (To Be). Это фундамент для определения требований к системе.

Определение Should Do

Should Do — это набор правил, процедур и механизмов, которые необходимо внедрить для достижения целей организации и устранения текущих проблем.

Это НЕ "в идеальном мире", а вполне реалистичное, достижимое состояние с учетом:

• Бюджетных ограничений
• Технических возможностей
• Временных рамок
• Деловых приоритетов

Как выглядит процесс анализа As Is → Should Do

Шаг 1: Документирование текущего состояния (As Is)

Что нужно понять:

• Кто выполняет процесс (роли, отделы)
• Какие шаги сейчас выполняются
• Какие системы используются
• Где возникают задержки и ошибки
• Какова стоимость текущего процесса
• Какие проблемы испытывают пользователи

Методы:

• Интервью с пользователями
• Наблюдение за реальной работой
• Анализ логов и метрик
• Диаграммы AS IS (в нотации BPMN)

Пример As Is:

Клиент отправляет заявку → Оператор вводит в Excel → 
Менеджер вручную проверяет → Отправляет по email → 
Утверждает боссу → Отправляет SMS клиенту
Время: 3-5 дней, ошибки при ручном вводе

Шаг 2: Выявление проблем и боли (Pain Points)

Типичные проблемы:

• Длительность: процесс занимает 3-5 дней вместо нескольких часов
• Ошибки: ручной ввод приводит к 10% ошибок
• Масштабируемость: не может работать с растущим объемом
• Невидимость: никто не знает статус заявки
• Затраты: нужны дополнительные люди при росте объемов
• Удовлетворение: клиенты недовольны скоростью

Шаг 3: Определение целей (Goals)

Что хотим достичь:

• Сократить время обработки с 3 дней до 1 часа
• Снизить ошибки с 10% до 0.1%
• Позволить клиентам отслеживать статус в реальном времени
• Снизить затраты на обработку на 50%
• Масштабировать без дополнительных людей

Цели должны быть SMART:

• Specific (конкретные)
• Measurable (измеримые)
• Achievable (достижимые)
• Relevant (релевантные)
• Time-bound (с временной границей)

Шаг 4: Проектирование желаемого состояния (Should Do / To Be)

Разработка нового процесса:

Клиент заполняет форму на сайте → 
Система автоматически валидирует → 
Триггер для менеджера → 
Менеджер (если нужно) корректирует → 
Автоматическое утверждение (или ручное) → 
Автоматическая отправка SMS/email → 
Клиент видит статус в личном кабинете
Время: 5-30 минут, ошибки 0%

Компоненты Should Do описания

Процессы:

• Какие шаги новые
• Какие шаги удаляются
• Какие шаги остаются
• Где происходит автоматизация

Роли и ответственность:

• Кто что делает
• Какие роли созданы/удалены
• Требования к компетенции

Система поддержки:

• Какая IT система нужна
• Интеграции
• Требования к данным

Показатели успеха:

• Метрики, которые будем отслеживать
• Целевые значения
• Как измерять

Пример Should Do требований

Should Do: Система управления заявками

• Клиент может создать заявку через веб-форму (24/7)
• Система автоматически валидирует данные (формат, обязательные поля)
• Менеджер получает notification в системе
• Менеджер видит all relevant info в одном месте
• Менеджер может добавить комментарий/вопрос к клиенту
• Автоматическое отправление email если нет ответа 24 часа
• Утверждающее лицо получает batch of заявок (раз в день)
• Клиент видит status and timeline в своем личном кабинете
• Клиент может изменить заявку если статус = draft/on review
• После утверждения автоматически отправляется подтверждение
• Клиент может оценить опыт взаимодействия
• Все данные сохраняются для аудита

Разница между Should Do и Could Do

Should Do (нужно):

• Решает основные проблемы
• Реалистично в текущем контексте
• Приносит максимальную ценность за инвестированные ресурсы

Could Do (могли бы):

• Nice-to-have фичи
• Может быть в будущем
• Требует дополнительных ресурсов
• Например: AI чат-бот для первой линии поддержки

Документирование Should Do

В требованиях я пишу:

## Should Do: Автоматизация обработки заявок

### Как это работает сейчас (As Is)
- Время обработки: 3 дня
- Ошибки при вводе: 10%
- Затраты: 0.5 FTE на обработку

### Проблемы
- Клиент ждет слишком долго
- Много ошибок
- Не масштабируется

### Цели (Should Do)
- Время обработки: < 1 часа
- Ошибки: < 0.1%
- Затраты: 0.1 FTE (автоматизированный процесс)

### Как это будет работать (To Be)
- [описание нового процесса]
- [какая система нужна]
- [какие интеграции]

### Метрики успеха
- SLA: 95% заявок обработано < 1 часа
- Error rate: < 0.1%
- Customer satisfaction: >= 4.5/5

Почему Should Do важен для BA

1. Фокус: помогает не отвлекаться на nice-to-have
2. Основа для требований: Should Do превращается в требования для разработки
3. Управление expectations: стейкхолдеры видят реалистичные цели
4. Измерение успеха: можно потом проверить достигли ли целей
5. ROI: обосновывает инвестиции в проект

Итоговый процесс

As Is → Выявление проблем → Goals → Should Do → Requirements → Design → Development → Testing → Should Do achieved?

Если Should Do не достигнут — нужно анализировать почему и что корректировать.