Согласованная цель
Проблема, желаемое изменение и признак ценности сформулированы так, чтобы команда могла проверить связь будущего решения с задачей бизнеса.
Проверка бизнес-задачи до проектирования и разработки
Бизнес-анализ цифрового проекта
Проводим бизнес-анализ перед разработкой цифровой системы. Изучаем процессы, роли, правила, данные и ограничения, выявляем проблемы и формируем согласованную модель требований для следующего этапа.
Что за услуга?
Что такое бизнес-анализ проекта?
Бизнес-анализ связывает идею цифрового проекта с процессами, ролями и показателями компании. S.O.L CORP описывает текущее и целевое состояние, выявляет участников, правила, исключения и источники данных. Результат помогает выбрать приоритетные функции, оценить эффект и не переносить в новую систему неэффективные ручные операции.
Практическая ценность
Что получает заказчик после анализа
Понятные границы
Зафиксировано, какие роли, процессы и сценарии входят в проект, что переносится на следующий этап и что не относится к цифровому решению.
Сравнимые варианты
Решение не выбирается по привычке. Варианты сопоставляются по ценности, ограничениям, риску, зависимости и стоимости следующего шага.
Обоснованный маршрут
Заказчик понимает, нужен ли прототип, ТЗ, техническое исследование, MVP или другой формат, и какие материалы переходят в следующий этап.
Когда нужен анализ
В каких ситуациях бизнес-анализ необходим
Есть идея, но не определён продукт
Нужно отделить потребность от первого варианта реализации и понять, какой результат действительно нужен пользователю и бизнесу.
Участники ожидают разное
Руководитель, продажи, операционная команда и IT по-разному видят приоритеты, роли, данные и критерии готовности.
Автоматизируется процесс
Перед разработкой важно описать текущие действия, решения, исключения, данные и ответственность, а не переносить хаос в новый интерфейс.
Проект затрагивает несколько систем
Нужно определить владельцев данных, границы интеграций, зависимости и изменения процессов до технического проектирования.
Нужно выбрать первую итерацию
Функций и гипотез больше, чем можно проверить сразу. Анализ помогает выделить минимальный полезный объём без случайного урезания ценности.
Методика BA-SCOPE-01
Что входит в бизнес-анализ проекта
Глубина анализа зависит от числа процессов, ролей, систем и неизвестных данных. Двенадцать областей проверяются отдельно, а выводы связываются между собой и с решением о следующем этапе.
- 01
Проблема и причина обращения
Фиксируем наблюдаемую ситуацию, её последствия и факты, которые отделяют проблему от общего недовольства.
- 02
Изменение и ценность
Определяем желаемое состояние и признак, по которому заказчик сможет оценить полезность решения.
- 03
Контекст
Изучаем подразделения, продукты, правила, сезонность, каналы, существующие системы и внешние ограничения.
- 04
Заинтересованные стороны
Определяем роли, потребности, полномочия, ответственность за решения и источники предметной информации.
- 05
Текущий процесс
Описываем события, действия, решения, данные, исключения, ручные операции и точки потерь в текущем состоянии.
- 06
Целевой процесс
Моделируем согласованное будущее состояние без преждевременной детализации экранов и программных модулей.
- 07
Бизнес-правила
Фиксируем условия, расчёты, полномочия, статусы и исключения, которые определяют поведение процесса.
- 08
Границы решения
Показываем, какие процессы, роли и системы меняются, что остаётся без изменений и что не входит в проект.
- 09
Допущения и ограничения
Отмечаем непроверенные предположения, бюджетные, правовые, организационные и технические рамки.
- 10
Зависимости
Выявляем данные, решения, подрядчиков, доступы и изменения, без которых проект не сможет перейти к реализации.
- 11
Варианты решения
Сравниваем организационные и цифровые варианты по ценности, рискам, ограничениям и сложности следующего шага.
- 12
Приоритеты и готовность
Выделяем первый полезный объём, открытые вопросы и критерий перехода к прототипу, ТЗ или разработке.
Материалы анализа
Что передаётся по завершении работ
Аналитическая записка
Проблема, потребность, ценность, контекст, выводы, ограничения и открытые вопросы.
Модели процессов
Текущее и целевое состояния, роли, события, решения, данные и исключения в согласованной детализации.
Карта границ
Состав первой итерации, зоны вне проекта, зависимости и решения, которые требуют отдельного этапа.
Рекомендация следующего шага
Варианты решения, приоритеты, риски и критерий готовности к прототипу, ТЗ, оценке или разработке.
Выбор формата
Чем отличаются бриф, бизнес-анализ и техническое задание
| Формат | Когда подходит | Что получает заказчик |
|---|---|---|
| Бриф | Нужно быстро собрать исходные вводные, пожелания, контакты, ограничения и доступные материалы. | Список исходных данных и вопросов. Противоречия, процессы и варианты решения ещё не обязаны быть проверены. |
| Бизнес-анализ | Нужно понять потребность, процессы, заинтересованные стороны, ценность, границы и обоснованный следующий шаг. | Согласованная модель задачи, варианты, первая итерация, зависимости, риски и критерий готовности. |
| Техническое задание | Границы решения выбраны и требуется детально зафиксировать функции, данные, интеграции и приёмку. | Проверяемые функциональные и нефункциональные требования для оценки, разработки и сдачи. |
Экспертная работа
Как применяем BA-SCOPE-01
Метод не начинает проект с перечня экранов. Сначала проверяется связь между потребностью, ценностью, участниками, процессом и границей решения. Каждый вывод имеет источник, статус и влияние на следующий шаг.
Проверяем контекст
Проводим интервью, изучаем документы и системы, наблюдаем процесс и отделяем факты от предположений.
Трассируем решения
Связываем проблему, заинтересованную сторону, правило, вариант, ограничение и ожидаемую ценность.
Согласуем границы
Проверяем, что первая итерация создаёт самостоятельную пользу, а исключённые части явно зафиксированы.
Пример аналитического решения
Как определяется граница первой итерации
Пример показывает принцип принятия решения. Реальные роли, процессы и объём определяются по данным проекта.
- Контекст
- Менеджеры повторно вводят заявку из сайта во внутреннюю систему, но каталог, расчёт цены и документооборот принадлежат разным подразделениям и пока не согласованы.
- Анализ
- Сопоставляем путь заявки, роли, обязательные данные, точки решения и доступные интерфейсы. Отделяем передачу заявки от несогласованных процессов каталога и документов.
- Решение
- Первая итерация включает проверенную форму, единый набор данных, передачу заявки, статус и журнал ошибки. Каталог и документооборот вынесены в отдельное исследование.
- Критерий готовности
- Владелец процесса подтверждает границу, роли и результат; обязательные данные определены; зависимость от внутренней системы проверена; открытые вопросы имеют ответственных и следующий шаг.
Оценка работ
От чего зависят сроки и стоимость бизнес-анализа
Оценка зависит от числа процессов, подразделений, ролей, систем, вариантов решения и неизвестных данных. На объём влияют доступность владельцев процессов, необходимость наблюдения за работой, качество документов, число интервью и согласующих сторон, сложность бизнес-правил, наличие интеграций, правовых ограничений и исторических данных. Небольшую задачу можно исследовать как один ограниченный сценарий. Корпоративный продукт с несколькими контурами требует поэтапного анализа и отдельных контрольных решений. До знакомства с контекстом нельзя честно обещать фиксированный срок или полноту исследования. Сначала согласуются границы самого анализа, его участники, формат материалов и критерий завершения.
Пример решения
Анализ внутреннего процесса обработки заявок
- Задача
- Определить, какой цифровой продукт нужен компании, где сотрудники повторяют действия и какие части процесса можно обоснованно включить в первую итерацию.
- Решение
- Описали текущий путь заявки, роли, решения и системы, выделили факты и гипотезы, построили целевое состояние, сравнили варианты и ограничили первый релиз передачей заявки, статусом и журналом ошибки.
- Результат
- у проекта есть согласованная цель, граница, зависимости и критерий перехода к техническому заданию.
Этапы работ
Как проходит бизнес-анализ проекта
- 1
Определяем рамку анализа
Согласуем причину обращения, решения, которые нужно принять, участников, материалы и критерий завершения.
- 2
Собираем факты
Проводим интервью, изучаем документы, интерфейсы, отчёты и доступные данные, наблюдаем реальную работу.
- 3
Моделируем текущее состояние
Фиксируем события, роли, действия, решения, данные, исключения и точки потерь.
- 4
Формулируем потребность
Связываем проблему, заинтересованные стороны, желаемое изменение и проверяемый признак ценности.
- 5
Сравниваем варианты
Рассматриваем организационные и цифровые решения, зависимости, ограничения, риски и стоимость следующего шага.
- 6
Согласуем целевое состояние
Определяем процесс, границы, первую итерацию, допущения, открытые вопросы и ответственных.
- 7
Передаём решение
Оформляем материалы, проводим проверку с участниками и фиксируем переход к прототипу, ТЗ или разработке.
Риски без анализа
Какие ошибки предотвращает бизнес-анализ
Начать с экранов вместо задачи
Интерфейс детализируется до понимания процесса и ценности. Анализ возвращает проект к потребности и решению.
Пропустить важную роль
Решение согласовано с руководителем, но не учитывает сотрудника, владельца данных или контролирующее подразделение.
Размыть границы проекта
Каждое обсуждение добавляет функции. Карта границ показывает первый полезный объём и отдельные инициативы.
Автоматизировать несогласованный процесс
Система закрепляет противоречивые правила. Текущее и целевое состояния проверяются до технической реализации.
Опыт, экспертиза и доверие
Кто отвечает за методику бизнес-анализа
Методика S.O.L CORP основана на анализе задачи, проверке исходных данных и применении профильной документации. Для каждой услуги мы определяем состав работ, ограничения, критерии результата и порядок проверки. Решения адаптируются под конкретный проект и согласуются с заказчиком до начала реализации.
- Ответственный за материал
- S.O.L CORP
- Область компетенции
- Разработчик движка Layer и основатель S.O.L CORP. Разработка цифровых продуктов с 2017 года. Область компетенции: бизнес-анализ, моделирование процессов, проектирование сайтов и веб-приложений, роли и права, архитектура, API, интеграции, технические задания и критерии приёмки.
- Дата проверки
Следующие этапы после бизнес-анализа
Вопросы и ответы
Ответы на вопросы о бизнес-анализе проекта
Чем бизнес-анализ отличается от предпроектной аналитики?
Бизнес-анализ подробно исследует потребность, ценность, заинтересованные стороны, процессы, правила и варианты решения. Предпроектная аналитика шире и может дополнительно включать техническое обследование, контент, интеграции, архитектуру, прототип и предварительную оценку. На небольшом проекте работы могут выполняться в одном цикле, но результаты и границы всё равно фиксируются отдельно.
Нужен ли бизнес-анализ, если уже есть техническое задание?
Если ТЗ актуально, согласовано с владельцами процессов и объясняет связь требований с задачей бизнеса, повторный полный анализ может не понадобиться. Сначала проверяются границы, противоречия, открытые вопросы и изменения контекста. Если документ перечисляет функции без потребности, ролей и правил, требуется ограниченный аналитический этап.
Можно ли провести анализ без готового описания процессов?
Да. Описание процессов часто является результатом работы, а не обязательным входом. Нужны доступ к владельцам и исполнителям, примеры документов, интерфейсов и реальных ситуаций. Аналитик собирает факты через интервью, наблюдение и разбор сценариев, а затем проверяет модель с участниками.
Какие сотрудники должны участвовать?
Состав зависит от решения. Обычно нужен владелец бизнес-результата, сотрудники реального процесса, владельцы данных и систем, а также лица, которые утверждают ограничения или принимают результат. Один руководитель может не знать исключения ежедневной работы, а исполнитель не всегда определяет стратегическую ценность.
Является ли результатом анализа список функций?
Список функций может входить в материалы, но сам по себе не является достаточным результатом. Нужны проблема, ценность, роли, процессы, правила, границы, зависимости, варианты, риски и решение о следующем шаге. Детальная спецификация функций формируется в техническом задании после выбора границ решения.
Можно ли сразу оценить разработку после бизнес-анализа?
Иногда да, если границы, сценарии, данные, интеграции и ограничения достаточно определены для требуемой точности. Для сложной системы после бизнес-анализа могут понадобиться прототип, техническое обследование или ТЗ. Результат анализа прямо показывает, каких данных не хватает и какой этап уменьшит неопределённость.
Кому принадлежат аналитические материалы?
Порядок владения и передачи фиксируется в договоре. Заказчик получает согласованные материалы в формате, который можно использовать с внутренней командой или другим подрядчиком. Ограничения могут относиться только к сторонним лицензируемым материалам, если они применяются, и должны быть оговорены заранее.
Работаете ли вы только с компаниями Санкт-Петербурга?
Нет. S.O.L CORP находится в Санкт-Петербурге и ведёт проекты по всей России. Интервью и согласования можно проводить дистанционно. Для анализа важнее доступ к участникам, фактам, документам и системам, чем физическое расположение команды.
Начнём с задачи
Обсудим бизнес-анализ проекта?
Опишите проблему, желаемое изменение, участников, существующий процесс или продукт, известные ограничения и решение, которое нужно принять. Приложите бриф, схему, регламент, пример документа или текущий интерфейс, если они есть. Мы определим границы анализа, необходимых участников и следующий шаг.
support@solcorp.ru Пн–Пт, 10:00–19:00 МСК