В BABOK второй раздел посвящен ключевым понятиям бизнес-анализа. Это не набор техник и не формальное описание задач в различных областях знаний бизнес-анализа. Это концептуальный каркас профессии. В отличие от Раздела 1, где читателю дается общее определение бизнес-анализа, Раздел 2 задает понятийную основу, без которой дальнейшие главы превращаются в разрозненный инструментарий.
Для практикующего бизнес-аналитика данный раздел играет прежде всего методологическую роль: он формирует язык, через который описываются изменения, ценность, заинтересованные стороны, решения и контекст. Разбор этого раздела особенно важен для специалистов, стремящихся выстроить системное мышление и повысить зрелость своей аналитической практики.
Если вы пропустили разбор первого раздела, то с ним всегда можно ознакомиться тут.
2.1. Модель базовых понятий бизнес-анализа (BACCM)
Центральным элементом раздела является Business Analysis Core Concept Model (BACCM). Модель включает шесть взаимосвязанных понятий:
- Изменение
- Потребность
- Решение
- Ценность
- Заинтересованные стороны
- Контекст
Важно понимать: BACCM — это не абстрактная схема ради схемы. Это инструмент мышления. Каждая задача бизнес-анализа, независимо от области знаний, может быть рассмотрена через призму этих шести понятий.
Изменение
Изменение — это преднамеренная трансформация предприятия с целью повышения его эффективности.
Бизнес-анализ существует именно ради управления изменениями. Если нет изменения — нет и предмета работы бизнес-аналитика.
Практическая интерпретация: при старте любой инициативы бизнес-аналитик должен формализовать, какое именно изменение происходит. Изменение может касаться процессов, организационной структуры, ИТ-систем, бизнес-модели или поведения пользователей. Неформализованное изменение приводит к размыванию границ инициативы и конфликтам ожиданий.
Потребность
Потребность — это проблема или возможность, требующая рассмотрения.
В зрелой практике бизнес-аналитик не ограничивается формулировкой «заказчик хочет новую систему». Он выявляет стратегическую или тактическую потребность, лежащую в основе этого запроса.
Потребность может быть вызвана:
- ухудшением показателей
- появлением новых регуляторных требований
- технологическими ограничениями
- конкурентным давлением
- стратегическим поворотом компании
Практический аспект: если потребность сформулирована поверхностно, решение будет локальным и, скорее всего, не принесет устойчивой ценности.
Решение
Решение — это конкретный способ удовлетворения потребности.
Решение может быть:
- процессным
- организационным
- технологическим
- комбинированным
Важное различие: решение далеко не всегда связано с внедрением или доработкой ИТ-системы. Ошибка начинающих бизнес-аналитиков заключается в том, что они преждевременно фиксируются на автоматизации, не исследуя альтернативные варианты.
Практика показывает, что корректная декомпозиция решения требует анализа ограничений предприятия, зрелости процессов и доступных ресурсов.
Ценность
Ценность — это стоимость, важность или полезность чего-либо для заинтересованных сторон в конкретном контексте.
Ценность может быть материальной (финансовый эффект, сокращение затрат) и нематериальной (репутация, мотивация сотрудников, снижение рисков).
Ключевая мысль: ценность относительна. Один и тот же вариант решения может быть ценным для операционного блока и не иметь ценности для финансового департамента.
Практическое следствие: бизнес-аналитик обязан явным образом определить критерии ценности и связать их с измеримыми показателями. Без этого невозможно корректно формировать и рекомендовать решение.
Заинтересованные стороны
Заинтересованная сторона — это лицо или группа лиц, имеющие отношение к изменению, потребности или решению.
В рамках BACCM заинтересованные стороны рассматриваются через призму их влияния, вовлеченности и степени воздействия изменения на них.
Практический аспект: управление заинтересованными сторонами — это не вспомогательная активность, а ядро аналитической работы. Неполная карта стейкхолдеров приводит к сопротивлению изменениям и искажению требований.
Контекст
Контекст определяет условия, в которых существует потребность и реализуется решение.
Он может включать в себя:
- организационную структуру
- рыночную среду
- регуляторные ограничения
- технологический ландшафт
- культуру предприятия
Контекст динамичен. Изменение контекста может полностью обесценить ранее принятые решения.
Практическое применение: при разработке стратегии изменения бизнес-аналитик обязан явно фиксировать допущения контекста. Это снижает риск принятия решений в условиях устаревших предпосылок.
Взаимосвязь базовых понятий
Сила BACCM заключается не в перечне формализованных терминов, а в их взаимосвязи между собой. Потребность инициирует изменение. Изменение реализуется через решение. Решение должно создавать ценность для заинтересованных сторон. Все это происходит в определенном контексте.
Если одно из понятий меняется, пересмотру подлежат остальные. Например, изменение регуляторной среды (контекст) может изменить восприятие ценности решения. Или появление новой заинтересованной стороны способно изменить критерии приемки.
Для зрелого бизнес-аналитика BACCM становится ментальной моделью проверки качества выполненного анализа.
2.2. Ключевые термины
Подраздел 2.2 формирует понятийный аппарат, необходимый для корректного использования руководства. Среди ключевых терминов:
- Бизнес-анализ — деятельность, обеспечивающая возможность изменений через определение потребностей и рекомендацию решений.
- Информация бизнес-анализа — любые данные, используемые в качестве входов или результатов аналитической работы.
- Требования и дизайны — различные формы описания того, что должно быть реализовано.
- Бизнес-потребность, бизнес-цель, бизнес-проблема — термины, отражающие стратегический и тактический уровни анализа.
Практическая значимость этого подраздела довольно часто недооценивается. Нечеткое использование терминов в проектной документации приводит к методологическим конфликтам. Например, смешение понятий «бизнес-цель» и «требование к решению» искажает процесс приоритизации.
Зрелая аналитическая практика требует дисциплины используемого языка. Термины из Раздела 2 могут быть использованы как основа для корпоративного глоссария.
2.3. Схема классификации требований
Схема классификации требований в BABOK формирует структурированный взгляд на требования как на разноуровневую систему взаимосвязанных артефактов. Это не просто удобная группировка, а логика декомпозиции от стратегии к реализации.
В рамках Раздела 2 выделяются следующие категории требований:
- Бизнес-требования
- Требования заинтересованных сторон
- Требования к решению
- Переходные требования
Бизнес-требования
Бизнес-требования описывают цели, задачи и показатели, которые организация стремится достичь.
Они формулируются на стратегическом или тактическом уровне и отвечают на вопрос: зачем инициируется изменение?
Практический аспект: бизнес-требования должны быть связаны с измеримыми целевыми показателями. Если формулировка не позволяет определить критерии достижения, она не выполняет управленческую функцию.
Требования заинтересованных сторон
Требования заинтересованных сторон конкретизируют ожидания определенных групп или ролей.
Они являются мостом между стратегией и решением.
Именно на этом уровне могут возникать основные противоречия: разные группы по-разному интерпретируют потребность и ценность. Зрелая аналитическая практика предполагает прозрачную фиксацию этих различий.
Требования к решению
Требования к решению делятся на:
- Функциональные
- Нефункциональные (качество сервиса)
Функциональные требования описывают поведение решения. Нефункциональные определяют ограничения и характеристики качества: производительность, безопасность, надежность, удобство использования и др.
Распространенная ошибка — фокусироваться исключительно на функциональности при игнорировании качественных характеристик, что приводит к снижению реальной ценности решения.
Переходные требования
Переходные требования описывают временные условия, необходимые для перехода от текущего состояния к будущему.
Они актуальны только на этапе внедрения.
В качестве примера, переходные требования могут включать в себя миграцию данных, обучение пользователей, временные процедуры или интеграционные механизмы.
Практическая ценность выделения переходных требований в отдельный вид требований заключается в снижении рисков внедрения и предотвращении перегрузки основного решения временной логикой.
2.4. Заинтересованные стороны
Раздел 2 систематизирует понятие заинтересованных сторон и подчеркивает их центральную роль в бизнес-анализе.
Заинтересованная сторона — это лицо или группа, имеющая отношение к изменению, потребности или решению.
В контексте BACCM заинтересованные стороны рассматриваются через:
- степень влияния на изменение
- степень влияния изменения на них
- уровень вовлеченности
- их интересы и ожидания
Практический вывод: анализ заинтересованных сторон должен быть формализованным процессом, а не интуитивной оценкой. Карта заинтересованных сторон, матрица влияния и коммуникационный план становятся не формальностью, а инструментами управления рисками.
Недооценка стейкхолдеров приводит к сопротивлению, задержкам и искажению требований. Мой разбор взаимодействия со стейкхолдерами в рамках теории игр можно почитать тут.
2.5. Требования и дизайны
Подраздел 2.5 вводит принципиально важное разграничение между требованиями и дизайнами.
Требование — это формулировка потребности или ограничения. Дизайн — это конкретный способ реализации требования.
Это разграничение позволяет избежать преждевременного перехода к техническим решениям. Бизнес-аналитик, подменяющий требование дизайном, ограничивает пространство альтернатив.
Пример:
Требование — обеспечить сокращение времени обработки заявки до 5 минут. Дизайн — внедрить автоматизированную систему маршрутизации.
Первое оставляет пространство для выбора способа реализации. Второе фиксирует конкретный способ реализации.
Практический смысл разграничения:
- Повышается гибкость выбора решения
- Снижается риск технологической предвзятости
- Улучшается качество оценки альтернатив
Практическое применение раздела 2 BABOK в работе бизнес-аналитика
Раздел 2 BABOK полезен тем, что его можно применять не «после изучения», а в процессе работы. Если области знаний (разделы 3–8) отвечают на вопрос «что делать и как делать?», то Раздел 2 отвечает на вопрос «о чем мы вообще говорим и называем ли вещи своими именами?». На практике это означает: BACCM, классификация требований, работа со стейкхолдерами и разделение требований/дизайнов можно превратить в регулярные процедуры контроля качества анализа.
Ниже приведены основные сценарии применения, которые покрывают типовые ситуации бизнес-аналитика: от инициациирования до изменений в требованиях, от конфликтов до оценки результата.
1. Экспресс-диагностика инициативы (до начала сбора требований)
Частая ошибка проектов: команда начинает собирать требования, не определив, что именно является потребностью, какое изменение рассматривается, кто реально принимает решения и что в данном контексте считается ценностью. BACCM позволяет сделать короткую диагностику на 30–90 минут и получить ясность до старта глубокой проработки.
Как применять
На первой встрече (или в рамках мини-воркшопа) бизнес-аналитик последовательно фиксирует шесть понятий:
- Потребность: проблема/возможность, подтвержденная фактами, а не мнением. Здесь важны симптомы, причинность и «что будет, если ничего не делать».
- Изменение: какая именно трансформация предполагается (процесс, оргструктура, правила, технология, поведение пользователей).
- Заинтересованные стороны: кто затронут и кто влияет. Это разные множества, и они должны быть описаны отдельно.
- Ценность: что будет считаться успехом и как это измеряется (включая нематериальные эффекты, но выраженные однозначно измеримыми индикаторами).
- Решение: гипотеза решения и пространство альтернатив. На старте решение может быть неопределенным, но границы поиска должны быть проговорены заранее.
- Контекст: ограничения среды (регуляторика, ИТ-ландшафт, культура, текущая зрелость процессов, сезонность, внешние зависимости).
Результат
Минимальный артефакт — одностраничная «карта инициативы» (может быть в виде таблицы), которая служит общим основанием для дальнейшей работы. Если на этом этапе обнаруживается, что понятия не согласованы (например, разные стейкхолдеры по-разному понимают потребность или ценность), проекту нужен не «сбор требований», а повторное определение смысла.
2. Уточнение формулировки потребности (чтобы не лечить симптомы)
Раздел 2 помогает дисциплинировать работу с потребностью: потребность не равна запросу на функциональность и не равна «хотим новую систему». В зрелой практике бизнес-аналитик превращает «запрос» в потребность, а потребность — в проверяемую конструкцию.
Как применять
Бизнес-аналитик фиксирует:
- наблюдаемые факты (метрики, SLA, ошибки, потери, жалобы, простои)
- предполагаемые причины
- последствия без изменений (cost of delay или хотя бы качественное описание ущерба)
- желаемый эффект (в форме измеримого улучшения)
Почему это важно
Когда потребность ясна, становится возможна корректная работа с альтернативами: часто на уровне потребности выясняется, что ценность достигается не внедрением системы, а изменением правил, ответственности, контроля качества данных или перераспределением нагрузки.
3. Управление конфликтами через ценность и заинтересованные стороны
В проектах конфликт редко является «личным». Обычно это конфликт разных видов ценности: разные группы оптимизируют разные показатели, имеют разные риски и разные ограничения контекста. BACCM позволяет переводить эмоциональный спор в предметный: что именно является ценностью для каждой группы и почему.
Как применять
Для каждой ключевой заинтересованной стороны бизнес-аналитик фиксирует:
- ожидаемую ценность (выгоды и потери)
- риски (что ухудшится или станет опаснее)
- критерии приемки (что должно быть истинно, чтобы сторона приняла результат)
- степень влияния (может ли блокировать решение)
- степень воздействия изменения (насколько сильно пострадает/выиграет)
Далее бизнес-аналитик сопоставляет эти элементы и выявляет «узлы противоречий»: где ценности несовместимы, где критерии приемки конфликтуют, где контекстные ограничения одной группы делают невыполнимыми ожидания другой.
Результат
Появляется основание для управленческих решений: не «кто прав», а «какие компромиссы возможны», «какие критерии приоритизируем» и «какие риски принимаем».
4. Превращение классификации требований (2.3) в схему работы
Сама по себе классификация требований часто воспринимается как учебно-методологическая. На практике она может стать очень мощным инструментом, если использовать ее как структуру для управления объемом, трассируемостью и качеством.
4.1 Бизнес-требования как формализация смысла изменений
Бизнес-требования должны строго формализовывать цель изменения и критерии успеха. На практике это означает:
- привязку к бизнес-целям и показателям
- фиксирование целевого состояния (пусть даже высокоуровневого)
- согласование на уровне, где есть полномочия менять приоритеты
Если бизнес-требования не оформлены, проект превращается в «поставку функций» без гарантии ценности.
4.2 Требования заинтересованных сторон как портфель ожиданий
Этот слой — место, где накапливаются ожидания разных групп и где чаще всего возникают скрытые конфликты. Практический прием, который будет особенно эффективен: не смешивать требования разных групп в один список. Иначе исчезает контекст происхождения каждого конкретного требования и теряется возможность управлять компромиссами.
4.3 Требования к решению как проектируемая система
Разделение на функциональные и нефункциональные требования — критично. В зрелых инициативах нефункциональные требования не придаток к функциональным, а часть ценности. Например, «ускорить обработку» невозможно без требований к производительности, надежности и качеству данных.
Практический прием: нефункциональные требования необходимо связывать с рисками и критериями приемки, иначе они остаются декларативными.
4.4 Переходные требования как обеспечение внедрения
Переходные требования — типичный источник провалов: решение готово, но организация не может перейти в новое состояние (не произведена миграция данных, пользователи не обучены, регламенты не обновлены, интеграции работают частично). На практике переходные требования нужно выделять отдельным пакетом, планировать и оценивать ресурсно, иначе они «выпадают из scope».
5. Требование vs дизайн (2.5) как антидот против преждевременных решений
Одно из самых ценных практических применений Раздела 2 — дисциплина в используемой терминологии, которая предотвращает ситуацию «мы еще не поняли потребность, но уже спорим о кнопках и технологиях».
Как применять
Бизнес-аналитик вводит правило — каждую формулировку проверять вопросом:
- Это описывает потребность/ограничение (требование) или способ реализации (дизайн)?
- Можно ли удовлетворить это требование несколькими способами?
- Если это дизайн, какое требование он удовлетворяет и почему этот способ выбран?
На практике особенно полезна двухколоночная фиксация: «требование» и «дизайн-гипотезы». Это позволяет держать пространство альтернатив открытым до момента, когда решение действительно нужно зафиксировать.
Где это особенно важно
- В ИТ-проектах, где стейкхолдеры приходят с готовым «решением» вместо потребности
- В автоматизации процессов, где «внедрить систему X» подменяет задачу достижения бизнес-эффекта
- В ситуациях, где выбор дизайна определяет стоимость владения и риски (например, безопасность, архитектура, зависимость от вендора)
6. Управление границами (scope) и предотвращение бесконтрольного расширения требований
Раздел 2 помогает работать с объемом предполагаемых изменений не через формальные рамки, а через смысловую структуру:
- границы определяются не списком функций, а связкой потребность → ценность → изменение в конкретном контексте
- если новая идея не усиливает ценность или не относится к текущей потребности, она не должна присутствовать в текущей инициативе
Практический прием — каждое новое требование прогонять через три вопроса:
- Какую потребность оно поддерживает?
- Какую ценность оно добавляет (или какой риск снижает)?
- Как оно меняет контекст и заинтересованные стороны?
Это превращает обсуждение «давайте добавим еще одну фичу» в управляемое решение о ценности.
7. Проверка качества требований
BACCM можно использовать как универсальный че-лист качества любого требования или пакета требований. Это особенно полезно при ревью спецификаций, user story, BRD, SRS или описания процессов.
Как применять
Бизнес-аналитик задает вопросы:
- Потребность: какое истинное основание у этого требования?
- Изменение: что именно изменится в деятельности, ответственности, данных, поведении?
- Ценность: как можно понять, что это принесло пользу?
- Заинтересованные стороны: кто выигрывает/проигрывает, кто принимает, кто использует?
- Контекст: какие ограничения и допущения встроены в требование?
- Решение: это требование или уже выбранный дизайн? какие есть альтернативы?
Если на эти вопросы нет ответов, требование чаще всего окажется либо неполным, либо спорным, либо неуправляемым по изменениям.
8. Подготовка к внедрению и управление переходом
Переходные требования из 2.3 и элементы 2.4–2.5 позволяют выстроить внедрение как часть аналитической работы, а не как формальную обязанность проектного менеджера. На практике внедрение требует:
- изменения регламентов и ролей
- подготовки данных
- обучения и коммуникаций
- обновления метрик и контроля
Если бизнес-аналитик удерживает в фокусе связку «изменение → стейкхолдеры → ценность», внедрение перестает быть просто финальным этапом, а становится продолжением логики требований.
9. Применение в Agile и продуктовой разработке (без конфликтов терминов)
Раздел 2 полезен и в Agile-контексте. Там легко потеряться в user story и backlog, забыв про потребность и ценность. BACCM помогает удерживать стратегическую линию.
На практике:
- бизнес-требования отражаются в целях продукта/OKR
- требования стейкхолдеров становятся источником эпиков/тем
- требования к решению превращаются в user story и acceptance criteria
- нефункциональные требования оформляются как quality attributes/constraints и включаются в Definition of Done
- переходные требования планируются в релизных активностях (миграции, обучение, изменения процессов)
BABOK не будет конфликтовать с Agile, если использовать его как понятийный каркас.
Практический инструмент для читателя: BACCM-паспорт инициативы + многослойная карта требований
После прочтения такого длинного разбора полезно иметь артефакт, который можно применить завтра утром, без сложных внедрений. Хочу предложить вам, дорогие читатели, два связанных друг с другом инструмента.
1. BACCM-паспорт инициативы (1–2 страницы)
Назначение: быстро унифицировать понимание инициативы у всех участников, создать основу для коммуникации и контроля скоупа.
Состав (плотно, без избыточной формы):
- Потребность: проблема/возможность, факты, последствия без изменений.
- Изменение: что меняем (процесс/правила/оргструктура/ИТ/поведение).
- Ценность: показатели успеха, бенефиты/потери, как измеряем, когда считаем достигнутым.
- Заинтересованные стороны: ключевые группы, влияние/воздействие, критерии приемки, риски сопротивления.
- Контекст: ограничения, допущения, внешние зависимости, сезонность, регуляторика.
- Решение: гипотезы вариантов, ограничения реализации, критерии выбора.
Как использовать: обновлять при каждом значимом изменении контекста или приоритетов. Этот паспорт становится своеобразным источником истины для объяснения почему мы делаем именно так.
2. Многослойная карта требований (по классификации 2.3)
Назначение: превратить список требований в управляемую структуру.
Форма: четыре блока, каждый связан с предыдущим:
- Бизнес-требования (цели/показатели)
- Требования стейкхолдеров (ожидания групп)
- Требования к решению (функциональные/нефункциональные)
- Переходные требования (внедрение)
Правило качественной многослойной карты требований: любой элемент нижнего слоя должен иметь «родителя» в верхнем. Если требования к решению не поддерживают ценность и бизнес-требования, они должны быть поставлены под сомнение. Если переходные требования не зафиксированы, внедрение сопряжено с рисками.
Итог
Второй раздел BABOK кажется небольшим по объему, но он выполняет ключевую функцию: задает понятийную систему, которая делает бизнес-анализ управляемым. BACCM формирует каркас мышления, позволяющий удерживать смысл инициативы и проверять полноту анализа. Схема классификации требований превращает требования из разрозненного перечня в многослойную структуру от целей к внедрению. Разделение требований и дизайнов защищает от преждевременных решений и сохраняет пространство альтернатив до момента совершения обоснованного выбора. Понимание заинтересованных сторон как центрального элемента изменения делает бизнес-аналитика не «фиксатором требований», а управляющим коммуникацией и компромиссами.
Практическая ценность Раздела 2 раскрывается в том, что он применим на каждом шаге: для диагностики инициатив, управления конфликтами, контроля скоупа, проверки качества требований и обеспечения внедрения.
Именно поэтому иногда полезно регулярно возвращаться к нему в проектах: он не дает «рецептов», но дает то, без чего рецепты не работают, — корректную рамку для принятия решений и сохранения ценности в реальном контексте предприятия.