Что такое бизнес-требования, почему они так важны, как их выявить и в каком виде сформулировать: краткое руководство для начинающих системных и бизнес-аналитиков.
Бизнес-требования и бизнес-потребности
Иногда начинающие аналитики и менеджеры проектов под бизнес-требованиями понимают пожелания, полученные от бизнес-заказчиков, т.е. стейкхолдеров со стороны бизнеса: клиента, конечного пользователя или эксперта предметной области. Однако, такие пожелания являются пользовательскими требованиями или требованиями стейкхолдеров, хотя в исходном изложении представляют собой некий «поток сознания», который точно не соответствует критериям качественной формулировки требований. В любом случае, требования стейкхолдеров являются производным от бизнеса-требований, которые имеют универсальный характер для всего предприятия, а не выражают точку зрения его отдельных участников.
Согласно классификации требований по BABOK®Guide именно бизнес-требования являются основой всех остальных видов требований: пользовательских (требования стейхолдеров) и требований к решению (функциональных и нефункциональных). Источником происхождения бизнес-требования является бизнес-потребность, сформулированная как проблема или возможность. Чтобы проще всего понять смысл этого термина, формулировка бизнес-потребности в виде проблемы сводится к прямым или косвенным финансовым потерям на уровне всего предприятия или его части. Например, потеря 20% клиентских заявок от 50 входящих обращений в неделю выливается компании в 75 тысяч рублей недополученного дохода при 50%-ной конверсии заявки в продажу стоимостью 15 тысяч рублей:
0,2*50*0,5*15=75
Если бизнес-потребность представляется как возможность, речь идет о потенциале роста рынка и/или пропускной способности предприятия. Например, увеличение скорости обработки клиентских заявок на 20% от 50 до 60 входящих обращений в неделю позволит компании заработать на 450 тысяч рублей больше при 50%-ной конверсии заявки в продажу стоимостью 15 тысяч рублей:
50*1,2*0,5*15=450
Проще говоря, бизнес-потребность в виде проблемы означает потерю денег в компании, а как возможность – потенциал их заработать. Хотя рекомендуется формулировать бизнес-потребность в конкретных деньгах, на практике это не всегда получается. В этом случае следует все же сделать примерную оценку в численном выражении. Например, если бизнес-потребность сводится к улучшению клиентской лояльности, ее следует выразить в значениях ключевых метрик, таких как NPS (Net Promote Score), CSAT (Customer Satisfaction Score), отток клиентов ChR (Churn Rate) и коэффициент удержания CRR (Customer Retention Rate). Причем 2 последние метрики (ChR и CRR) уже напрямую коррелируют с деньгами в виде LTV (Lifetime Value). Например, если необходимо сократить отток клиентов на 15%, ценность этого бизнес-требования уже можно рассчитать, зная значения LTV или ARPU (Average revenue per user).
Также бизнес-требования могут быть представлены в контексте бизнес-процессов, например, сократить время обработки первичного обращения на 25%. Время очень хорошо конвертируется в деньги: понять материальную ценность этого бизнес-требования поможет метод функционально-стоимостного анализа, который позволяет определить себестоимость в зависимости от времени выполнения процесса и потребляемых ресурсов. Подробно об этом я расскажу отдельно.
Таким образом, бизнес-требование отвечает на вопросы «Почему это нужно?» и представляет собой отображение корпоративных целей, задач и результатов, объясняющих причины изменение и критерии оценки его реализации. Основными источниками бизнес-требований являются ситуации, когда главного выгодоприобретателя бизнеса (инвестора, собственника) не устраивают текущие ключевые показатели эффективности работы компании: доходы, затраты, длительность создания продукта (оказания услуги) или их качество (% ошибок, отзывов с низкой оценкой). Бизнес-требования напрямую следуют из бизнес-потребности и далее детализируются в требованиях стейкхолдеров, а затем уже в функциональных и нефункциональных требованиях к решению. Причем решение не обязательно является информационной системой, оно может представлять собой комплекс организационных мероприятий по изменению текущих бизнес-процессов и структур.
Разобравшись с важностью бизнес-требований, далее рассмотрим, как их выявить, сформулировать и трассировать в следующие уровни.
Основы бизнес-анализа: вход в профессию для начинающих
Код курса
INTRO
Ближайшая дата курса
13 января, 2025
Продолжительность
24 ак.часов
Стоимость обучения
54 000 руб.
Как сформулировать бизнес-требования: 7 ключевых шагов
Учитывая первичность бизнес-требований, без их определения невозможно приступить к разработке спецификации (SRS, Software Requirements Specification) или, говоря по-русски технического задания (ТЗ). Если в команде разделены роли системного и бизнес-аналитика, за выявление бизнес-требований и требований стейкхолдеров отвечает бизнес-аналитик, оформляя их в концепцию решения, BRD (Business Requirements Document) или StRS (Stakeholder Requirements Specification) согласно стандарту ISO IEEE 29148-2011 (2018). Далее на основании этого документа системный аналитик разрабатывает функциональные и нефункциональные требования к информационной системе, которая должна удовлетворить исходные бизнес-потребности.
Однако, сегодня во многих командах роли системного и бизнес-аналитика сливаются в одном человеке. Поэтому, перед тем как приступить к разработке ТЗ, предлагаю вам следующий алгоритм спецификации бизнес-требований и связанных с ними артефактов (контекстных ограничений и бизнес-правил):
- Определить ключевые показатели эффективности бизнеса на уровне финансовых, клиентских или процессных метрик. Например, доход, ARPU, коэффициент удержания клиентов, количество клиентских заявок, обработанных в срок, максимальная длительность обработки клиентской заявки и т.д.
- Совместно с владельцем компании или главным инвестором понять, какие из текущих значений этих KPI (Key Performance Indicators) не устраивают этого выгодоприобретателя и сформулировать это как бизнес-потребность в виде проблемы или возможности. Например, потеря 20% клиентских заявок от 50 входящих обращений в неделю обходится компании в 75 тысяч рублей недополученного дохода при 50%-ной конверсии заявки в продажу стоимостью 15 тысяч рублей (BN-1).
- Определить желаемые значения KPI в виде SMART-цели (Specific, Measurable, Achievable, Relevant, Time-bound) на обозримом временном горизонте, например, 1 год. Например, полное отсутствие, т.е. 0 потерянных (полученных, но необработанных в плановый срок) заявок к 01.10.2023.
- Сформулировать бизнес-требование с привязкой к ранее определенным желаемым значениям KPI в виде SMART-цели. Например, сократить долю потерянных (полученных, но необработанных в плановый срок) заявок с 20% до 0% к 01.10.2023 (BReq-1).
- Выявить ограничения, свойственные для этого контекста, например, особенности отрасли или домена, которые надо учитывать при поиске решения. Например, необходимость работать с персональными данными российских пользователей согласно ФЗ-152 или необходимость ответа на претензию в течение 30 дней с момента ее получения согласно ч. 5 ст. 4 АПК РФ. Сюда же могут относиться проектные ограничения, такие как общий бюджет на изменение, включая все статьи расходов.
- Специфицировать бизнес-правила, которые связаны с бизнес-требованиями, поскольку описывают логику их формирования или ограничивают их область действия. Например, плановый срок обработки клиентской заявки составляет 48 часов(BR-1). А заявки от юридических лиц на сумму от 100 тысяч рублей получают наивысший приоритет (BR-2) и должны быть обработаны в течение 24 часов с момента их поступления (BR-3). Для каждого бизнес-правила также следует задать источник его происхождения: нормативный акт, внутренняя политика и пр.
- Определить акторов, которые помогут достичь ранее сформулированной цели в виде бизнес-требования. Например, в случае обработки клиентских заявок это может быть менеджер по продажам и начальник отдела продаж. Далее именно эти стейкхолдеры будут источником пользовательских требований к решению, от организационных изменений на уровне бизнес-процесса до функций и показателей качества CRM-системы. Для этого отлично подходит техника карты влияния (Impact Map), о которой я расскажу в следующий раз. Также на этом этапе для выявления акторов как исходных факторов возникновения проблемы пригодятся техники причинно-следственного анализа, в частности, диаграммы Исикавы и метод 5Why, о чем я писала здесь.
Таким образом, можно трассировать бизнес-потребность к бизнес-требованиям и бизнес-правилам. В нашем примере это будет выглядеть так:
| Бизнес-потребность | Бизнес-требование | Бизнес-правила |
| Проблема: BN-1. Потеря 20% клиентских заявок от 50 входящих обращений в неделю Следствие: 75 тысяч рублей недополученного дохода при 50%-ной конверсии заявки в продажу стоимостью 15 тысяч рублей | BReq-1. Сократить долю потерянных (полученных, но необработанных в плановый срок) заявок с 20% до 0% к 01.10.2023 | BR-1. Плановый срок обработки клиентской заявки не более 48 часов |
| BR-2. Заявки от юридических лиц на сумму от 100 тысяч рублей получают наивысший приоритет | ||
| BR-3. Заявки с наивысшим приоритетом должны быть обработаны в течение 24 часов с момента их поступления |
Надеюсь, что подобный алгоритм поможет вам лучше формулировать бизнес-требования и связанные с ними бизнес-правила, поскольку с этого начинается любой ИТ-проект, включая разработку требований к созданию новой или изменению существующей информационной системы.
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
TTIS
Ближайшая дата курса
2 декабря, 2024
Продолжительность
16 ак.часов
Стоимость обучения
36 000 руб.
Освоить эти и другие техники и приемы практической работы аналитика вы сможете на курсах нашей Школы прикладного бизнес-анализа в лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
