В предыдущей статье мы разобрали четвёртое базовое понятие BABOK — Решение (Solution). Мы выяснили, что оптимальное решение — не то, которое технически совершенно, а то, что наилучшим образом закрывает сформулированную потребность в данном контексте с учётом реальных ограничений. Ключевое словосочетание здесь — «в данном контексте». Но что именно скрывается за этим словом?
Представьте: команда провела безупречный анализ заинтересованных сторон, точно сформулировала потребность, спроектировала переход и выбрала оптимальное решение. А потом выяснилось, что регулятор запретил использование облачных технологий для хранения персональных данных. Или что организационная культура компании настолько иерархична, что любое изменение без явного одобрения топ‑менеджмента обречено на саботаж снизу. Или что технологический стек компании несовместим с выбранным решением, а на его замену нет ни бюджета, ни времени. Всё это — контекст.
Разберём пятое базовое понятие BABOK — Контекст (Context).
Почему пятое базовое понятие именно «Контекст»?
К этому моменту цепочка BABOK выглядит так: мы знаем:
Но все эти ответы существуют не в вакууме. Они существуют внутри конкретной среды — рыночной, регуляторной, технологической, культурной.
Контекст — это то, что определяет границы возможного. Он не говорит, что делать. Он говорит, что нельзя сделать — и поэтому является самым жёстким ограничением из всех шести понятий.
Почему именно пятым, после Решения? Потому что контекст влияет на все предыдущие понятия сразу:
Заинтересованные стороны — кто из них реально влиятелен, во многом определяется организационной культурой и структурой власти.
Потребность — рыночные изменения и регуляторные требования порождают новые потребности быстрее, чем команды успевают их осознать.
Изменение — культурный контекст определяет, приживётся ли изменение или будет отвергнуто организмом компании.
Решение — технологический ландшафт и регуляторные ограничения сразу отсекают целые классы технически привлекательных решений.
Ценность — экономический и рыночный контекст определяет, будет ли созданная ценность актуальна к моменту внедрения или устареет.
Аналитик, игнорирующий контекст, — это архитектор, который проектирует здание, не изучив геологию грунта. Красивый проект. Но при первой же нагрузке — трещины.
Что такое Контекст и где кроется подвох?
Согласно глоссарию BABOK v3.0:
Контекст — все обстоятельства и условия, которые влияют на изменение, которые находятся под влиянием изменения, или которые способствуют пониманию изменения.
Контекст — это всё, что относится к изменению в рамках его среды. Контекст может включать настроения, виды поведения, убеждения, конкурентов, культуру, демографию, цели, правительства, инфраструктуру, языки, потери, процессы, продукты, проекты, продажи, времена года, терминологию, технологию, погоду и любые другие элементы, соответствующие этому определению.
Обратите внимание на формулировку: «всё, что влияет». Это принципиально отличает контекст от остальных понятий BABOK. Заинтересованные стороны можно перечислить. Потребность можно сформулировать. Решение можно зафиксировать. Контекст — нельзя исчерпать. Он всегда шире того, что мы успели изучить.
Главный подвох — иллюзия стабильности. Команда фиксирует контекст на этапе инициации проекта и дальше работает так, будто мир остановился. Но рынки меняются, регуляторы выпускают новые нормативы, конкуренты запускают продукты, руководство компании меняет приоритеты. Контекст — не статичная картинка, а живая среда, за которой нужно следить на протяжении всего проекта.
Второй подвох — слепые зоны. Каждая команда видит тот контекст, к которому привыкла. Разработчик видит технологический стек. Юрист — регуляторные риски. Маркетолог — рынок. Никто в одиночку не видит полной картины. Роль бизнес‑аналитика — собрать эти фрагменты воедино и обнаружить то, что ускользнуло от взгляда каждого из участников.
Четыре измерения контекста: что именно нужно анализировать
BABOK описывает контекст через понятие Business Analysis Information Architecture и выделяет несколько ключевых аспектов среды, влияющих на бизнес‑анализ. На практике я работаю с четырьмя измерениями, которые охватывают большинство значимых контекстуальных факторов:
1. Регуляторный контекст: что нельзя, даже если очень хочется
Это самое «жёсткое» измерение — оно не обсуждается и не согласовывается. Регуляторные требования либо выполняются, либо проект несёт юридические, финансовые и репутационные последствия.
Что входит в регуляторный контекст:
Законодательство и нормативные акты — ФЗ-152 от 27.07.2006 (персональные данные), Базель III/IV (финансовые организации), отраслевые стандарты.
Внутренние политики и регламенты — информационная безопасность, управление рисками, комплаенс. Нередко жёстче, чем внешние требования.
Требования регулятора — для финансовых компаний это Банк России и его нормативные акты; для медицины — Росздравнадзор; для телекома — Роскомнадзор.
Лицензионные и договорные ограничения — использование определённых технологий может нарушать лицензионные соглашения или условия партнёрских договоров.
Типичная ошибка: регуляторный контекст анализируется постфактум — когда решение уже выбрано и команда начала разработку. Именно так возникают ситуации, описанные в первой статье цикла: внутренний регулятор запрещает запуск уже готового продукта.
Правило БКС: «любая идея проходит через регуляторное сито до того, как попасть в бэклог». Это не бюрократия. Это защита от потраченных впустую спринтов.
2. Технологический контекст: что реализуемо при существующем стеке
Технологический контекст — это не только то, какие системы уже стоят в компании. Это вся экосистема: зрелость инфраструктуры, компетенции команды, архитектурные решения прошлого, уровень технического долга.
Что входит в технологический контекст:
Существующий ИТ‑ландшафт — какие системы работают, как они связаны между собой, какие «узкие места» и зависимости есть в архитектуре.
Технический долг — насколько «старый» код и инфраструктура ограничивают внедрение новых решений. Технический долг — это невидимый налог на каждое новое решение.
Компетенции команды — самая современная технология бесполезна, если её некому поддерживать. Зрелость команды — часть контекста, а не только кадровый вопрос.
Вендорские зависимости — насколько компания «привязана» к конкретным поставщикам, каковы условия поддержки и жизненный цикл используемых продуктов.
Стандарты и архитектурные принципы — принятые в компании паттерны, которые новое решение обязано соблюдать или явно обосновывать отступление от них.
Кейс из практики: в одном проекте команда выбрала перспективный open‑source фреймворк для построения правил бизнес‑логики. Технически — отличный выбор. Но анализ технологического контекста показал: в компании нет ни одного специалиста, знакомого с этой технологией, а время на найм и обучение не вписывается в сроки проекта. Был выбран менее «элегантный», но хорошо знакомый команде инструмент. Проект был сдан в срок.
3. Организационно‑культурный контекст: что приживётся, а что будет отвергнуто
Это самое сложное для формализации измерение — и при этом одно из наиболее важных. Организационная культура определяет, как принимаются решения, насколько люди готовы к изменениям, кто реально влиятелен вне зависимости от оргструктуры.
Что входит в организационно‑культурный контекст:
Структура власти и принятия решений — кто на самом деле решает? Официальный согласователь в системе и фактический ЛПР — нередко разные люди. Аналитик, который не разбирается в политическом контексте организации, теряет согласования.
Толерантность к изменениям — есть компании с культурой экспериментирования («провалились быстро — хорошо, сделали вывод»), и есть компании с культурой стабильности («не сломано — не чини»). Скорость и глубина изменений должна соответствовать этому порогу.
Неформальные нормы и «как у нас принято» — каждая организация имеет негласные правила, которые сильнее формальных регламентов. Игнорирование этих норм — прямой путь к пассивному саботажу.
История предыдущих проектов — если последние три трансформационных проекта провалились, доверие к новым инициативам будет нулевым. Это часть контекста, с которым нужно работать, а не игнорировать.
Практический инструмент BABOK для анализа культурного контекста — Organization Modelling: описание структуры, ролей, ответственностей и отношений внутри организации. Не как нарисовано на схеме, а как работает на самом деле.
4. Рыночный и конкурентный контекст: что актуально сейчас и через год
Это внешнее измерение контекста — то, на что организация влиять не может, но к чему обязана адаптироваться.
Что входит в рыночный контекст:
Рыночные тренды и изменение потребительского поведения — потребность, актуальная сегодня, может утратить приоритет к моменту, когда решение будет готово. Особенно критично в быстро меняющихся рынках: финтех, e‑commerce, медиа.
Действия конкурентов — конкурент, запустивший аналогичный продукт раньше, меняет восприятие ценности вашего решения. То, что было «уникальным преимуществом» год назад, стало «table stakes» сегодня.
Макроэкономический контекст — изменение процентных ставок, инфляция, курсовые колебания влияют на приоритизацию инвестиций. Проект, утверждённый при одном бюджетном горизонте, может потерять финансирование при другом.
Технологические сдвиги — появление новых технологий может как открыть новые возможности (ИИ, открывший новые способы автоматизации), так и обесценить уже сделанные инвестиции (рынок мобильных приложений, убивший десктопные решения).
Инструмент BABOK для анализа внешнего контекста — PESTLE‑анализ (Political, Economic, Social, Technological, Legal, Environmental) в сочетании с SWOT. Это не академическое упражнение — это карта ограничений и возможностей, которую нужно актуализировать в ключевых точках проекта.
Контекст как живой организм: почему его нельзя зафиксировать раз и навсегда
Одна из самых дорогостоящих ошибок в управлении проектами — работа с устаревшей картой контекста. Команда описала бизнес‑среду на старте, зафиксировала ограничения и предположения — и дальше ведёт проект, как будто мир стоит на месте.
Контекст меняется на всём протяжении проекта. Вот типичные триггеры, которые меняют контекст прямо в середине проекта:
Правило: ревизия контекста должна быть запланирована как обязательная точка в каждом значимом этапе проекта — не реакция на кризис, а плановый контрольный «check».
Классическая ошибка: «карта не совпала с местностью»
Приведу кейс, который наглядно показывает, как игнорирование сразу двух измерений контекста — регуляторного и культурного — приводит к провалу технически грамотного проекта.
Контекст: Крупная финансовая компания запустила проект по внедрению аналитической платформы на базе облачного решения зарубежного вендора. Техническое решение было выбрано безупречно: признанный мировой лидер рынка, богатый функционал, хорошая экосистема интеграций. Команда провела детальный анализ потребностей и сформировала сильные требования.
Что произошло:
За четыре месяца до планового запуска внутренний комплаенс‑офис поднял вопрос о хранении клиентских данных: по российскому законодательству персональные данные граждан РФ обязаны храниться на серверах внутри страны. Зарубежный облачный вендор не имел российских дата‑центров.
Параллельно в ходе пилота выяснилось, что культура принятия решений в компании предполагает обязательное согласование с несколькими комитетами, что не было учтено в плане проекта. Каждое согласование занимало 3–4 недели.
Проект встал. Команда потратила ещё два месяца на поиск альтернативного вендора с российской инфраструктурой, переработку требований и повторное согласование.
Общая задержка составила 7 месяцев. Часть функционала была утрачена при переходе на другое решение. Бюджет превышен на 40%.
Где была ошибка? Регуляторный контекст (ФЗ-152) и культурный контекст (многоступенчатые согласования) не были проанализированы до выбора решения. Оба фактора были очевидны и предсказуемы — при условии, что их анализировали. Этот кейс — не история о невезении. Это история об аналитике, который изучил потребность, но не изучил среду, в которой потребность существует.
Рабочие техники: как анализировать контекст?
В BABOK v3.0 анализ контекста описан прежде всего в области знаний Strategy Analysis (глава 6) — в частях Analyse Current State и Define Future State. Ниже — четыре наиболее практичных инструмента, которые дают наиболее полную картину:
1. Анализ текущего состояния (Current State Analysis)
Прежде чем проектировать будущее — необходимо точно понять настоящее. Current State Analysis — это не просто описание «как есть». Это структурированное понимание среды: почему система работает именно так, какие силы удерживают её в текущем состоянии, что изменится при переходе к To‑Be.
Компоненты Current State Analysis:
Capabilities Map — карта текущих бизнес‑возможностей: что организация умеет делать хорошо, что делает посредственно, чего не умеет совсем.
Process Map (as‑is) — реальные процессы, верифицированные с операционными пользователями.
System Landscape — карта всех систем, их взаимосвязей, зависимостей и точек интеграции. Часто открывает «скелеты в шкафу» — системы, о существовании которых не все знали.
Constraint Catalogue — явный список ограничений: регуляторных, технических, финансовых, временных. Ограничения не всегда устранимы — их нужно знать и закладывать в дизайн решения.
2. PESTLE + SWOT: внешнее и внутреннее
PESTLE (Political, Economic, Social, Technological, Legal, Environmental) даёт структурированный взгляд на внешний контекст. SWOT (Strengths, Weaknesses, Opportunities, Threats) позволяет соединить внешний контекст с внутренними возможностями организации.
Практическое правило: PESTLE и SWOT не являются разовым артефактом. Их нужно обновлять при каждом значимом изменении контекста — не раз в квартал по расписанию, а при появлении новых регуляторных документов, рыночных событий или стратегических решений руководства.
Важный нюанс для финансовых компаний: блок L (Legal) в PESTLE должен покрывать не только законодательство, но и нормативные акты Банка России, внутренние положения и политики. В финансовой отрасли они нередко жёстче федеральных законов.
3. Матрица допущений и рисков контекста
Любой аналитик работает с допущениями о контексте — явными или нет. Явные допущения лучше: их можно проверить, оспорить и актуализировать. Скрытые допущения — источник самых болезненных сюрпризов.
Структура матрицы:
Допущение о контексте | Измерение | Если допущение неверно | Как проверим |
Регулятор не изменит требования к хранению данных в горизонте проекта | Регуляторный | Архитектура хранения данных потребует полного пересмотра | Мониторинг нормативных актов раз в месяц |
Текущий технологический стек поддерживает нужные интеграции | Технологический | Потребуется замена или доработка ключевых компонентов | Проверка совместимости на этапе прототипа |
Команда имеет необходимые компетенции для реализации | Технологический | Задержки и перерасход бюджета на найм/обучение | Оценка компетенций команды до старта разработки |
Стратегические приоритеты бизнеса не изменятся | Культурный | Проект потеряет поддержку и финансирование | Ежеквартальная ревизия с спонсором |
4. Context Diagram (диаграмма контекста)
Простой, но очень эффективный инструмент из BABOK (раздел 10.13) — визуальное представление системы в её окружении: какие внешние субъекты взаимодействуют с системой, какие потоки данных и событий проходят через её границу.
Context Diagram решает конкретную проблему: на старте проекта команда часто имеет размытое понимание границ системы. Кто снаружи, кто внутри? Какие внешние системы, регуляторы, пользователи и партнёры взаимодействуют с решением? Диаграмма контекста отвечает на эти вопросы одним листом — и становится точкой согласования между всеми Заинтересованными сторонами.
Практическое правило: Context Diagram рисуется одной из первых, ещё до начала детального сбора требований. Она же является инструментом управления скоупом — любое требование, которое выходит за границу диаграммы, должно быть явно обосновано.
Опыт «БКС Мир инвестиций»: Context Review как обязательная точка проекта
В компании «БКС Мир инвестиций» мы ввели обязательную процедуру Context Review — ревизии контекста проекта. Она проводится в трёх точках жизненного цикла: на старте проекта, перед каждым значимым архитектурным решением и за 4–6 недель до релиза.
Что мы проверяем на каждой ревизии:
Регуляторная актуальность: появились ли новые нормативные акты или разъяснения регулятора, которые влияют на проект? Изменились ли требования по информационной безопасности или защите данных?
Технологическая актуальность: не изменились ли планы вендоров по поддержке используемых технологий? Не возникли ли новые технические ограничения или зависимости?
Организационная актуальность: не сменился ли спонсор или ключевые заинтересованные стороны? Не изменились ли стратегические приоритеты бизнеса?
Рыночная актуальность: не изменился ли рыночный контекст настолько, что потребность, под которую создавалось решение, утратила приоритет?
Если на Context Review обнаруживаются значимые изменения — это не повод для паники. Это повод для осознанного пересмотра: либо корректируем решение под новый контекст, либо фиксируем риск и принимаем его осознанно. Что недопустимо — продолжать двигаться по плану, делая вид, что ничего не изменилось.
Дополнительный инструмент, который мы используем, — реестр допущений. Каждое ключевое допущение о контексте фиксируется явно с указанием того, кто его принял, как оно будет мониториться и что произойдёт при его нарушении. Это звучит бюрократично, но на практике именно этот документ чаще всего «спасает» проект при смене спонсора или внешних условий: новый участник может быстро понять, на каких предположениях строилось решение.
Мини‑чеклист: «Действительно ли я понимаю контекст?»
Проанализированы все четыре измерения контекста: регуляторное, технологическое, организационно‑культурное и рыночное?
Регуляторное «сито» пройдено до выбора решения, а не после начала разработки?
Контекстные допущения зафиксированы явно с указанием того, как они будут мониториться?
Нарисована Context Diagram — границы системы согласованы со всеми ключевыми Заинтересованными сторонами?
Технологический контекст (ИТ‑ландшафт, компетенции, вендорские зависимости) проанализирован до финального выбора решения?
Запланированы точки ревизии контекста в ключевых этапах проекта?
Организационно‑культурный контекст изучен — кто фактически принимает решения, каков порог толерантности компании к изменениям?
Рыночный контекст проверен: будет ли потребность актуальна к моменту запуска решения?
Итог
Контекст — пятое звено в причинно‑следственной цепочке BABOK: Нет правильных заинтересованных сторон → нет правильной потребности → изменение не спроектировано → выбрано неправильное решение → контекст не изучен → созданная ценность нежизнеспособна.
Контекст — это не фоновое знание, которое «и так понятно». Это структурированный анализ, который требует времени, инструментов и регулярного обновления.
Умение видеть то, что лежит за пределами явного задания, — замечать регуляторные сигналы раньше, чем они стали кризисом, чувствовать культурное сопротивление до того, как оно стало саботажем, понимать технологические ограничения раньше, чем они стали блокером — именно это отличает бизнес‑аналитика экспертного уровня от аналитика‑исполнителя.
Что дальше в цикле?
Следующая — финальная — статья цикла будет про Ценность (Value): как убедиться, что всё, что было сделано — заинтересованные стороны определены, потребность сформулирована, изменение спроектировано, решение выбрано и реализовано в правильном контексте — действительно принесло результат? Что такое ценность в понимании BABOK, чем она отличается от «пользы» и «выгоды», и почему без измерения ценности бизнес‑анализ остаётся незавершённым.
