Портфолио бизнес-аналитика без опыта: что показать на одном кейсе

Учебный кейс: заявка на доступ

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

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

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

Новая заявка → проверка комплектности
  сведений не хватает → На уточнении → заявитель дополняет → повторная проверка
  сведения полные → рассмотрение → Одобрена / Отклонена
Для отклонения нужна причина. Одобрение здесь не означает выдачу доступа.

Для BPMN обозначьте участников дорожками, действия задачами, развилку решения шлюзом, начало и завершение событиями. Не называйте текстовую последовательность готовой BPMN-моделью: диаграмму нужно отдельно нарисовать и сверить с правилами.

От потребности к проверяемому требованию

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

1. R1 — комплектность. До рассмотрения нужны название системы и обоснование. Если обоснование пустое, заявка остаётся на уточнении и показывает, что нужно заполнить.
2. R2 — причина отказа. Если согласующий отклоняет заявку, заявитель видит причину. Отклонение без причины в этом учебном процессе недопустимо.
3. R3 — разделение ролей. Для примера принимаем правило: заявитель не согласовывает собственный запрос. Если роли совпали, нужен другой согласующий. Это выбранное условие кейса, а не универсальное правило любой организации.

Критерий для R1
Дано: у заявки указана система, но нет обоснования.
Когда: заявитель передаёт её на рассмотрение.
Тогда: заявка не попадает согласующему, остаётся на уточнении,
а сообщение явно называет недостающее обоснование.

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

Что положить в портфолио

• README: задача, участники, границы, ваш вклад и обозначение учебного характера.
• Схема процесса: исходный файл и доступный для просмотра экспорт; состояния совпадают с текстом.
• Требования: ID, формулировка, основание, критерий приёмки и статус вопроса.
• Сценарии: полный запрос, неполные данные, отказ и конфликт ролей.
• Выводы: что обнаружили при проверке и как изменили артефакты.

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

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

Как проверить и представить проект

Пройдите каждый сценарий по схеме и требованиям. Для R1 проверьте пустое и заполненное обоснование; для R2 — отказ с причиной и без неё; для R3 — разных участников и совпадение ролей. Запишите обнаруженные расхождения, а не только успешный путь.

Короткий рассказ строится так: какую проблему разбирали → какое решение выбрали → почему → как проверили → что осталось неизвестным. Не приписывайте кейсу экономию времени, рост продаж или внедрение, которых не было.

В резюме хватит нескольких строк и ссылки: как описать проект бизнес-аналитика. На встрече можно подробнее разобрать вопросы о требованиях и процессе.