JK | Бизнес и Системный Анализ

Требования: функциональные vs нефункциональныеФункциональные требования (FR): что система должна делать. Нефункциональные (NFR): как она должна это делать (качество).Примеры FR:⏺️создать заявку⏺️изменить статус заказа⏺️выгрузить отчётПримеры NFR:⏺️время ответа < 2 секунд⏺️доступность 99.5%⏺️аудит изменений⏺️безопасность/роли⏺️ограничения на объём данныхЕсли NFR не собрать вовремя, они всплывут через время на бою в виде проблем с производительностью и безопасностью.

12 вопросов на интервью, чтобы быстро прояснить требованияШаблон вопросов:⏺️Какой бизнес‑результат нужен (метрика)?⏺️Кто пользователь и что для него “успех”? ⏺️Где начинается и заканчивается сценарий? ⏺️Какие исключения “болят” чаще всего? ⏺️Какие решения принимаются и по каким правилам? ⏺️Какие статусы объекта существуют (заявка/заказ)? ⏺️Какие данные обязательны? ⏺️Какие роли и права? ⏺️Какие интеграции и источники данных? ⏺️Какие SLA/временные ограничения? ⏺️Какие риски/ограничения (закон, безопасность)? ⏺️Как будем принимать (критерии)?

Роль бизнес-аналитика на проекте: границы системы и контекстБазовые артефакты, которые готовит БА и которые экономят недели:⏺️контекстная диаграмма (система + внешние акторы/системы)⏺️список стейкхолдеров и их целей⏺️границы ответственности (что не делаем)Аналитик сначала делает понятным “что строим”, а потом уже “как”.

Как за 1 час собрать RACI и закрыть “серые зоны”Делаем так:▶️Берем 8–12 ключевых шагов процесса (можно из SIPOC/BPMN). ▶️Колонки - роли (не конкретные ФИО людей, а чаще должности): Менеджер, Руководитель, Бухгалтерия, ИТ. ▶️Заполняем R/A/C/I, правило: на шаге должен быть хотя бы один R, и обычно один A. ▶️Выявляем типовые проблемы:⏺️два A ➡️ конфликт полномочий⏺️нет A ➡️ “никто не отвечает”⏺️лишком много C ➡️ вечное согласование⏺️роль везде R ➡️ перегруз (узкое место)Результат можно сразу превратить в регламент и требования к статусам/уведомлениям в системе.

Swimlane + матрица RACIСхема с дорожками (swimlane) отвечает на вопрос: кто делает шаг. RACI отвечает на вопрос: кто за что отвечает.RACI расшифровка:⏺️Responsible - делает⏺️Accountable - отвечает за результат (обычно один)⏺️Consulted - консультирует⏺️Informed - информируется

User Story vs Use Case vs SRS: что выбратьНеправильный формат описания требований часто дороже, чем его отсутствие. Бывает, что формат выбирается “как модно”, а не “как полезно”, и тогда получается либо слишком кратко, либо бюрократично. Проблема не в том, что команда пишет User Story или SRS. Проблема - когда формат не соответствует рискам проекта.Быстрый ориентир:⏺️User Story хороши для продукта с частыми итерациями и UI. Но в них часто теряются интеграции и ошибки.⏺️Use Case сильнее в сценариях и альтернативных ветках.⏺️SRS полезен, когда много NFR, регуляторики и нужна трассируемость.Пример: интеграция двух систем. Если описать как User Story “как пользователь хочу…”, то вы почти точно забудете:❌идемпотентность❌таймауты/ретраи❌коды ошибок❌порядок вызовов❌маппинг данныхПрактичный гибрид (часто лучший вариант):⏺️User Story (зачем)⏺️AC (как проверяем)⏺️Sequence diagram (как системы общаются)⏺️таблица данных/маппинг (что передаем)

DFD диаграммы потоков данных и зачем они аналитикуDFD показывает не “шаги процесса”, а потоки данных между:⏺️внешними сущностями (клиент, банк, партнёр)⏺️процессами (обработки)⏺️хранилищами данных (БД/реестры)Когда DFD особенно полезен:⏺️вы разбираете интеграции и источники данных;⏺️есть несколько систем и “непонятно, где правда”;⏺️нужно описать обмен данными без погружения в UI.

IDEF0 для “Оформление договора” за 60–90 минутКак быстро собрать модель:▶️ Формулируем функцию верхнего уровня: “Оформить договор”. ▶️ Заполняем ICOM:⏺️Input: заявка/коммерческое предложение/данные клиента⏺️Control: шаблоны, политика скидок, лимиты, требования юристов⏺️Output: подписанный договор, счёт/приложения⏺️Mechanism: менеджер, юрист, CRM, ЭДО▶️ Декомпозируем на несколько подфункций:⏺️подготовить реквизиты⏺️сформировать договор⏺️согласовать условия⏺️подписать⏺️зарегистрировать/архивироватьПосле такой декомпозиции легко понять, где нужны роли, статусы, автоматизация и интеграции (CRM / ЭДО).

Definition of Ready (DoR): чек‑лист “готово к разработке?”Если задача вроде бы понятна, но разработка стартует по сырому описанию, в котором отсутствуют критерии приемки, то потом случаются переработки, конфликты ожиданий, и плывут сроки...Большинство срывов сроков начинается не в разработке. Они начинаются в момент, когда команда берет в работу задачу, у которой нет четких границ и правил.Definition of Ready - это договоренность: какие минимальные вещи должны быть в задаче до оценки/разработки.Мой практичный DoR (сокращенная версия):⏺️Цель: что улучшаем и как измеряем⏺️Scope / Out of scope⏺️Роли/акторы + права доступа⏺️Основные сценарии (happy path)⏺️Исключения (ошибки, отмены, нет данных)⏺️Бизнес‑правила (таблица “условие → действие”)⏺️Данные: поля, справочники, источники⏺️Интеграции: кто с кем, формат, ошибки⏺️Макеты/описание UI (если есть интерфейс)⏺️NFR: производительность, логирование, безопасность⏺️Критерии приемки (AC) + примеры⏺️Риски/открытые вопросы и кто их закрываетНа примере функционала "фильтрации":⏺️Пользователь может фильтровать список по статусу, периоду, ответственному.⏺️Фильтр сохраняется между обновлениями страницы.⏺️При пустом результате показываем “Ничего не найдено” и кнопку сброса.⏺️Время ответа при 10к записей - до 2 секунд.

IDEF0 - что это и когда лучше BPMNIDEF0 - нотация про функции: что делает система/подразделение, а не “как по шагам бежит процесс”. Отлично подходит для декомпозиции “сверху вниз”.Базовая логика блока IDEF0:⏺️Input (вход) - что преобразуем⏺️Control (управление) - правила/регламенты/ограничения⏺️Output (выход) - результат⏺️Mechanism (механизм) - кто/чем выполняем (люди, ИС, ресурсы)Когда брать IDEF0:⏺️нужно быстро структурировать “что вообще делаем” и где границы⏺️много функций и подразделений, но шаги пока рано детализировать,⏺️вы описываете область для автоматизации (что должна поддержать ИС).

AS‑IS / TO‑BE: модели про “как есть” и “как будет”AS‑IS - это модель процесса “как сейчас”. TO‑BE - “как должно быть после изменений” (автоматизация, регламент, новые роли).Зачем вообще делать оба:⏺️AS‑IS позволяет увидеть реальные узкие места, дубли, ожидания, потери данных, “ручные костыли”, эта модель нужна.⏺️TO‑BE превращает улучшения в конкретные правила и шаги - то, что можно внедрить и проверить.Главная ошибка - рисовать TO‑BE сразу, “как хотелось бы”, не понимая реальную работу. В итоге любовная лодка разбивается о быт: теряются исключения и появляются серые зоны ответственности.И еще важное: TO‑BE не обязан быть “идеальным”. Он обязан быть внедряемым: с учетом людей, сроков, бюджета, инструментов.

Требования за час: интервью, после которого не нужны недели уточненийБывало ли, что интервью превращается в разговор “обо всем и ни о чем”, а после нет структуры требований. Хорошее же интервью завершается пониманием списков сценариев, правил и критериев приемки.Интервью - это не “поговорить”. Это способ быстро превратить хаос в структуру. Я использую таймбокс 60 минут, чтобы на выходе получить артефакты, которые можно отдать в разработку/оценку.Структура на 60 минут:▶️ Контекст (5 мин): зачем меняем? что болит? какая метрика успеха? ▶️ Роли (10 мин): кто пользователи, кто владелец процесса/данных, кто согласует? ▶️ 3 ключевых сценария (20 мин): “как сейчас” и “как должно быть”. ▶️ Исключения (10 мин): ошибки, отмены, просрочки, спорные случаи. ▶️ Данные и интеграции (10 мин): откуда берем, куда отдаем, кто “источник истины”. ▶️ Приемка (5 мин): как поймем, что сделали правильно?Пример вопросов, которые “спасают” интервью:⏺️“Как выглядит успешный результат через 1 месяц после запуска?”⏺️“Какие 3 операции выполняют чаще всего?”⏺️“Какие решения принимаются по правилам, а какие - вручную?”⏺️“Где чаще всего ошибки/возвраты и почему?”⏺️“Какие поля обязательны и что считать валидным?”Выход после 60 минут:⏺️список ролей⏺️3–5 сценариев⏺️черновик процесса (BPMN/flow)⏺️список правил и спорных мест⏺️первичные критерии приемки

Один процесс в EPC и BPMN: как выбрать и не споритьНа примере “выдача доступа новому сотруднику”.▶️ Сначала нужно зафиксировать цель модели. ⏺️Если цель - регламент и обучение: чаще выигрывает EPC (или очень упрощенный BPMN).⏺️Если цель - автоматизация: чаще выигрывает BPMN.▶️ Далее - сделать “скелет”, он одинаковый по смыслу: Событие: “сотрудник принят”, действие: “создать заявку на доступ”, событие: “заявка создана”, действие: “ИТ выдаёт доступ”, событие: “доступ выдан”.▶️ Добавить ответственность. ⏺️В BPMN - дорожками (HR/ИТ/Руководитель). ⏺️В EPC - через привязку функций к орг.единицам (или простую подпись роли).▶️ Решить проблему чтения: Часто достаточно договориться: “для бизнеса публикуем EPC, а для проекта автоматизации держим детальный BPMN как рабочую модель”.

EPC (ARIS) - в чем отличие от BPMN и где его применятьEPC (Event‑driven Process Chain), часто связанный с ARIS, - это нотация, где процесс описывается как чередование событий и функций: “что случилось” / “что делаем” / “что стало”.Сильная сторона EPC: он хорошо заходит бизнес‑аудитории, потому что логика “событие‑действие‑событие” близка к реальному описанию работы (получили заявку ➡️ проверили ➡️ заявка подтверждена).Когда EPC особенно полезен:⏺️нужно описать регламент на уровне “понятно руководителю и исполнителю”;⏺️вы работаете с компаниями, где исторически принят ARIS;⏺️важно подчеркнуть состояния/события, а не “технику исполнения”.Когда удобнее BPMN: если вы описываете сложные интеграции, ожидания, события сообщений, таймеры, исключения - в BPMN для этого больше стандартных конструкций.В реальных проектах нотация - это инструмент. Цель - согласование и внедрение. Если нужна помощь выбрать формат и сделать модели так, чтобы ими реально пользовались - пишите.

BA vs “просто ТЗ”: почему "сделайте как у конкурента" - это дорого и больноКогда Заказчик приносит ТЗ, и оно звучит так: “как у конкурента, только лучше” - это не ТЗ. Это риск переделок, конфликтов и сдвига сроков.Довольно частая история - приходит документ на 1–2 страницы, где написано “нужен личный кабинет”, “нужна CRM”, “нужен процесс согласования”. Команда кивает, начинает разработку - и уже на первой демонстрации выясняется, что все понимали задачу по‑разному: и выглядит не так, и работает тоже совершенно не так, как представлял себе Заказчик.Почему так происходит? Потому что такое "ТЗ" часто описывает желание, а не поведение системы и не правила бизнеса.Пример: “Нужно согласование заявок”. Вопросы, которые обычно всплывают после начала работ над подставленной задачей:⏺️Кто инициатор: сотрудник, руководитель, внешний клиент?⏺️Какие статусы и переходы: создано ➡️ на согласовании ➡️ отклонено ➡️ доработка ➡️ утверждено?⏺️Что является основанием отклонения и кто видит причину?⏺️SLA: сколько времени на согласование, что делать при просрочке?⏺️Исключения: отпуск согласующего, замена, эскалация.⏺️Интеграции: уведомления, 1С, почта, ЭДО.⏺️Права: кто может править заявку после отправки?Работа бизнес/системного аналитика заключается не в том, чтобы просто “написать документ”, а в том, чтобы снять неопределенность и зафиксировать минимальный набор артефактов:⏺️границы и цели (scope, out of scope)⏺️роли и ответственности⏺️процесс (BPMN/flow)⏺️бизнес‑правила⏺️данные/справочники⏺️интерфейсы/интеграции⏺️критерии приемки