Памяти Владимира Аршинова
философа коммуникации и сложностности.

Более 30 лет я участвую в проектах организационного развития — как консультант, аналитик, интервьюер, проектировщик организационных структур, разработчик финансовых и бизнес моделей, бизнес-тренер. Я работал со стартапами, малым и средним бизнесом, но всё чаще меня приглашают в крупные холдинги, госорганы и университеты, где задачи организационные структуры и процессы нетривиальны, а отношения внутри организаций очень сложны.

Сегодня хочу поделиться своим опытом использования одного из самых мощных, но недооценённых инструментов — методологией, основанной на фреймворках так называемых "Точек зрения" (Point of View, PoV).

Это не про очередной бизнес-план и бизнес-модель, а про то, как принимать решения там, где классические методы уже не работают. Там, где на арену выходи ее величество сложность или как говорил мой философский учитель сложностность.

Почему "один план на всех" — это иллюзия

В стартапе или малом бизнесе всё просто. У вас одна цель, один вектор, одна команда. Можно сесть, написать краткий бизнес-план, определить KPI и идти вперёд.

Но в крупной организации это невозможно. Там нет единой истины. Есть множество истин. Например, совладельцы и инвесторы думают о капитализации и долгосрочной устойчивости. Генеральный директор — о стратегии группы и синергиях. Директора бизнес-единиц — о своей нише и конкурентной среде. Финансовый директор — о ликвидности и бюджете и кассовых разрывах. IT-директор — об инфраструктуре и кибербезопасности. HR-директор — о кадрах и культуре.

Каждый из них видит свою реальность. Пытаться слить всё в один документ — значит обесценить каждый взгляд или втянуться в бесконесное "перетягивание канатов". И к тому же, любой план устаревает ещё до того, как его напишут. Рынок меняется, политика меняется, технологии меняются.

Выход: не модель, а согласование

Решение — не в поиске единой, универсальной модели, а в структурированном согласовании множества моделей. Эта идея, на первый взгляд современная, на самом деле уходит корнями в глубокую историю управления сложными системами. Люди давно поняли: когда объект настолько велик и многогранен, что не помещается в одном взгляде, нужно смотреть на него с разных сторон.

Представьте строительство собора в Средневековье. Архитектор видел общий замысел и пропорции, каменщики — прочность кладки, плотники — конструкцию кровли, а заказчик — соответствие божественному замыслу и бюджету. Не было единого чертежа, понятного всем, но была система, позволявшая согласовать эти разные "истины".

Сегодняшние фреймворки — это цифровые аналоги той самой системы согласования.
Они лежат в основе мощных методологий, проверенных временем и масштабом.

Фреймворк Захмана — можно считать цифровым наследником средневекового собора. Созданный в 1987 году, он выглядит как строгая матрица, где каждая ячейка — это взгляд определённой роли (владелец, архитектор, строитель) на определённый аспект системы (что, как, где). Это попытка систематизировать ту самую многоголосицу, которая строила великие соборы.

4+1 View Model Крухтена — родилась в 1995 году из необходимости согласовать взгляды на сложные программные системы. Логический, процессный, физический и другие виды — это не просто диаграммы, а инструменты диалога между разработчиками, менеджерами и пользователями. Она признаёт, что "система" для программиста и для бизнес-аналитика — это разные реальности.

DoDAF (Department of Defense Architecture Framework) — самый зрелый пример. Разработанный для описания архитектуры систем обороны США, он стал ответом на катастрофическую сложность военных проектов. С десятками тысяч подрядчиков, миллионами компонентов и строк кода, универсальная модель этого хаоса бессмысленна. DoDAF вводит набор стандартизированных "представлений" (views), которые позволяют всем участникам — от генералов до инженеров — говорить на одном языке, не теряя своей специфики.

Советско-российский аналог этого подхода — системно-мыследеятельная методология (СМД-методология), развитая школой Георгия Петровича Щедровицкого.

В то время как западные фреймворки (DoDAF, Захман) предлагают в первую очередь структурные и технические стандарты для описания систем, СМД добавляет к этому мощный философский и методологический фундамент, уходящий корнями в философию деятельности (воспринятую через призму марксистской традиции). СМД исходит из простой, но революционной идеи: социальная реальность не дана нам раз и навсегда. Она активно конструируется людьми. Ключевая категория здесь — коллективная мыследеятельность как способ организованного изменения мира и самого субъекта.

Центральным для СМД является понятие организации как среды и коллективного агента мыследеятельности. Чтобы изменить сложную систему, недостаточно иметь её модель. Необходимо сформировать коллективного актора — организацию и команды, способные к концептуальному (логическому, организованному, проектному) мышлению и коллективному действию. А для этого её участники должны согласовать свои позиции (точки зрения!), выстроить отношения, определить общую цель и выработать совместные средства её достижения.

Именно в этом смысле СМД предвосхитила современные гибкие методологии.
Подход утверждает, что сложная проблема не решается единственным экспертом, а требует организации мыследеятельности.

В ходе такой работы разные, часто противоречивые взгляды не отбрасываются, а синтезируются в новое, более сложное целое — общую программу действий и разделяемое понимание ситуации. Это не просто «моделирование» ради прогноза, а практика порождения нового качества — коллективной способности к действию и рефлексии.

Таким образом, западные фреймворки можно рассматривать как превосходные инструментальные языки для описания, а СМД подход — как мета-методику, обеспечивающую философию и практику для организации самого процесса коллективного мышления и деятельности. И в эпоху, когда технологии моделирования становятся все мощнее, именно эта человеческая способность — к организации мыследеятельности становится ключевым стратегическим ресурсом и главным ограничивающим фактором.

Достаточно часто в кругах ИТ-аналитиков можно услышать знакомую жалобу:
«Я построил модель по Захману, рассчитал все представления по DoDAF, а она не работает. Ею никто не пользуется». Или ещё хуже: «У нас целый отдел аналитиков, мы провели полную диагностику, рассчитали и построили "правильные" модели — а на местах всё по-прежнему, сотрудники "снизу" просто игнорируют нашу аналитику, а начальству все время некогда».

За этими фразами скрывается глубокая методологическая ошибка — представление о фреймворке как о "самой верной" модели, которую нужно просто "рассчитать и внедрить" только потому, что она "оптимальна" или "эффективна".

Это иллюзия. Мы не можем "остановить" живую организацию с помощью даже самой идеальной модели. Организация — это не статичная конструкция, а динамическая система, где каждый участник имеет свою позицию, интересы и собственное понимание реальности.

Модель — это не "истина", а средство коммуникации. Она не должна диктовать, как устроена организация «на самом деле». Её задача — создать общее поле для диалога, где разные точки зрения могут быть выражены, согласованы и превращены в совместное решение.

Фреймворки вроде DoDAF, Захмана или 4+1 — это не инструкции для сборки, а структуры для согласования. Они не предлагают одну истину, а дают возможность каждому — от собственника до рядового сотрудника — увидеть свою часть системы и понять, как она связана с другими.

Когда мы строим модель не для того, чтобы "доказать свою правоту" и "экспертность", а чтобы помочь команде договориться, она перестаёт быть "чёрным ящиком умных аналитиков" и превращается в инструмент коллективного мышления.
Именно в этом её ценность.

У нас в России, на фоне общего увлечения западными практиками, стала особенно популярной тема soft skills — коммуникационных навыков, эмоционального интеллекта, навыков ведения сложных диалогов. И безусловно, эти навыки важны. Но часто их развивают в вакууме, как будто хороший разговор сам по себе способен изменить организацию.

На практике оказывается, что даже самые изощрённые техники коммуникации бессильны, если в компании не выстроена архитектура опыта — система, в которой знания, решения и уроки из прошлого не теряются, а становятся общим достоянием. Когда каждый руководитель "изобретает велосипед", а прошлые конфликты и компромиссы не зафиксированы, никакие soft skills не помогут избежать их повторения.

Коммуникация сталкивается с жёсткими организационными и управленческими ограничениями: иерархией, разрозненными KPI, отсутствием общих процессов. Люди учатся "слушать активно", но не имеют общих инструментов для согласования. А ведь инструменты вроде фреймворков "Точек зрения" — это не просто диаграммы, это организационные протоколы, которые создают поле для диалога.

Soft skills — это про уровень человека. Но чтобы коммуникация работала на уровне организации, нужна архитектура взаимодействия — нечто, что по своей природе выходит за рамки индивидуальных навыков. Иначе получается как с танцорами: каждый может идеально владеть техникой, но если нет общей партитуры и хореографии, ансамбль не сложится. Организационные фреймворки не просто наборы диаграмм. Их общая суть — признание множественности истин для организации.

Они утверждают: система и ее архитектура описывается не одной моделью, а набором взаимосвязанных представлений, каждое из которых соответствует определённой точке зрения заинтересованной стороны. Задача не в том, чтобы слить их воедино, а в том, чтобы найти точки соприкосновения, баланс и, в конечном счёте, согласие.

Их общая суть: система описывается не одной моделью, а набором взаимосвязанных представлений (views), каждое из которых соответствует определённой точке зрения (viewpoint) заинтересованной стороны.

Мы не пытаемся построить «единую истину». Мы признаём множественность истин и ищем точки их пересечения, баланс и согласие.

Мой подход: 6 базовых этапов работы с точками зрения

За годы практики у меня сложилась чёткая последовательность. Вот основные этапы.

Этап 1: Уточнение запроса, проблемы и цели

Успех всего процесса зависит от первого и главного шага — формулировки чёткой и ясной цели. Без ответа на вопрос «Зачем мы это делаем?» любая методология рискует превратиться в бессмысленное академическое упражнение.
Наша первоочередная задача — вместе с заказчиком сформулировать конкретный запрос, который станет компасом для всей дальнейшей работы.
Именно он определяет состав участников и набор тех точек зрения, которые будут критически важны для достижения результата.

Запросы могут быть разными. Вот примеры.
Разработка новой стратегии — когда старая модель роста исчерпала себя и больше не работает.
Преодоление системного кризиса — когда нарастающий хаос в процессах и постоянные конфликты между подразделениями начинают угрожать устойчивости бизнеса. Разрешение организационного конфликта — когда, например, «холодная война» между финансовым и IT-блоками парализует ключевые инициативы.
Проведение цифровой трансформации — когда необходимо синхронизировать масштабные технологические изменения с трансформацией бизнес-модели.
Подготовка к масштабированию — когда текущая организационная структура не выдерживает давления быстрого роста или выхода на новые рынки.

Этот первоначальный, правильно сформулированный запрос и является нашим компасом.

Этап 2: Уточнение онтологии (можно использовать ER-диаграмму)

Это — фундамент всей работы. Без чёткого и согласованного описания онтологии процесс превратится в хаотичное обсуждение, где каждый говорит о своём. Нам нужно создать общую карту реальности, которую все участники будут признавать как отправную точку. Сначала мы выделяем ключевые сущности системы — не более тридцати, чтобы сохранить ясность. Это могут быть бизнес-единицы, основные процессы, информационные системы, ключевые рынки или регуляторные органы. Важно не перечислить всё подряд, а выделить то, что действительно влияет на проект или организацию.

Затем мы определяем основные роли — точки зрения агентов, чьи действия и решения формируют поведение всей системы. Их тоже стоит ограничить — двенадцать вполне достаточно. Это, например, генеральный директор, финансовый директор, IT-директор, директора ключевых бизнес-единиц. Каждый из них представляет не просто должность, а целую позицию в системе с её интересами и ответственностью.

Дальше идёт самое важное — мы начинаем выстраивать сети требований и обязательств между этими агентами. Что один требует от другого? Когда финансовый директор ждёт отчёт от IT? Какие SLA на доступность систем он считает критичными? Что директор по безопасности требует от бизнес-единиц в плане соблюдения политик? Эти взаимные обязательства и формируют «нервную систему» организации. На этом этапе мы также фиксируем внешние и внутренние ограничения — бюджетные рамки, регуляторные требования, сроки, технологические возможности. Они задают границы, в которых может происходить любое согласование.

И, наконец, мы стараемся понять, по каким правилам принимаются решения. Это не просто формальные процедуры, а глубинные принципы: «никаких инвестиций без окупаемости за три года», «все изменения в инфраструктуре требуют моего одобрения», «высвобождение ресурсов для стратегических инициатив группы — приоритет». Эти правила становятся «алгоритмами поведения» для наших агентов в симуляции.

Всё это вместе — сущности, роли (точки зрения), требования, ограничения, правила — формирует логическую модель системы, своего рода «конституцию» для предстоящей игры.
Это не окончательная истина, но общее поле для диалога, где каждый сможет увидеть не только свою позицию, но и позиции других.

Результаты этого этапа можно и нужно зафиксировать двумя ключевыми артефактами.
Во-первых, в виде ER-диаграммы (диаграммы сущность-связь).
Она становится наглядной и строгой картой системы, фиксируя:
Базовые сущности — ключевые элементы системы (бизнес-единицы, процессы, информационные системы, рынки).
Агентов — роли, чьи действия и решения формируют поведение системы (гендир, финдир, IT-дир и др.).
Связи между ними — визуализация требований, обязательств и ограничений, которые мы выявили.
Помимо ER-диаграммы результатом этого этапа могут быть первые обобщенные версии точек зрения, оформленные фреймворком Захмана или моделью 4+1.

Во-вторых, в виде детализированного технического задания на моделирование. Эта документация дополняет диаграмму, превращая её из статичной схемы в живой "скрипт" для симуляции.
В нём прописываются:
Конкретные правила поведения и принятия решений для каждого агента.
Численные ограничения (бюджеты, SLA, сроки).
Механизмы взаимодействия и обмена информацией.
Требования к данным, которые будут "питать" модель.

Вместе эти два артефакта — и ER-диаграмма, и техническое задание образуют прочный фундамент для следующего шага в виде построения цифрового двойника или проведения деловой игры. Они превращают разрозненные знания и интуицию в согласованную, формализованную основу для согласования.

Этап 3: Выбор подхода для работы с точками зрения на организацию

Выбор подхода для работы с "точками зрения" — это не техническая прихоть, а стратегическое решение, которое определяет весь характер процесса.

Здесь нет универсального "лучшего" способа, а есть набор возможных путей, каждый из которых дает разные возможности и имеет свои ограничения, в зависимости от контекста, ресурсов и зрелости организации.

Один из самых прямолинейных подходов — это работа вручную с консультантами, без привлечения сотрудников. Консультанты обобщают запрос и онтологию, создают ТЗ и формируют текущие позиции агентов на основе которых дают рекомендации.
Это как создать проект закона в закрытой комнате экспертов.
Плюс очевиден: процесс максимально контролируем, быстр и конфиденциален. Консультанты, обладая внешним взглядом, могут быстро выявить противоречия и предложить решение. Однако цена за эту эффективность — полное отсутствие вовлечённости. Решение, принятое "сверху", рискует стать для сотрудников чуждым, непонятным, а значит — и неисполняемым.
Это риск создания "чёрного ящика", где процесс скрыт, а доверие утрачено.

С появлением ИИ возникла соблазнительная возможность — использовать нейросеть и консультантов, оставаясь в "закрытом режиме". Представьте: вы загружаете в нейросеть все доступные данные — старые отчёты, бизнес-планы, регламенты — и просите сетку смоделировать, как поведут себя носители разных точек зрения.

Это даёт мощную аналитику и позволяет за считанные часы пройти путь, на который раньше уходили месяцы. Но здесь скрывается подводный камень. Нейросеть — это "чёрный ящик" в квадрате. Как она пришла к выводу, что финансовый директор должен уступить IT-директору? Объяснить это будет крайне сложно. Кроме того, если на вход подаётся "мусор" — устаревшие или противоречивые данные — на выходе будет тот же "мусор", но уже в красивой упаковке. Это как доверить судьбу корабля автопилоту, обученному на картах XVII века.

Альтернативой нейросетям является агентное моделирование (Аgent-based model или АВМ) в руках консультантов. Здесь логика прозрачна: каждый директор, каждый отдел — это "агент" с чётко прописанными правилами поведения (например, "не выделять бюджет без окупаемости за 2 года"). Модель показывает, как из этих простых правил рождаются сложные системные эффекты — например, постоянный срыв сроков. Это позволяет тестировать гипотезы: "Что будет, если мы изменим правило согласования?" Плюс в понятности и управляемости. Но цена — в подготовке. Настройка такой модели требует большого труда по формализации знаний и сбору данных, что отодвигает старт проекта.

Если же цель — не просто получить решение, а изменить культуру, то лучший путь — деловая игра с самими сотрудниками, без цифровых инструментов на основен сформированной заранее онтологии и ТЗ.
Это как народное вече. Люди берут на себя роли своих коллег и в реальном времени проигрывают конфликты. Здесь достигается максимальная вовлечённость и эмпатия: финансист начинает понимать, что чувствует IT-директор. Однако такой процесс легко скатывается в хаос. Без сильного модератора дискуссия превращается в баталию, а масштабировать его на всю компанию невозможно.

Современный золотой стандарт — это синтез: деловая игра + цифровой инструмент (будь то нейросеть или АВМ) + консультанты. Представьте сценарий: команда топ-менеджеров проводит сессию, обсуждая конфликт между бизнес-единицами. В реальном времени консультант запускает симуляцию на основе АВМ, показывая, к каким системным последствиям приведёт та или иная позиция. Это сочетание живого диалога и объективной аналитики. Однако такой подход требует значительных инвестиций и высокой зрелости команды, готовой слушать не только друг друга, но и данные.

Мой личный выбор — это деловая игра в сочетании с агентным моделированием и консультантами. Это баланс между вовлечённостью, прозрачностью и аналитической мощью. Человеки принимают решения, агентная модель показывает последствия, консультант направляет процесс. Главное условие успеха — сильный модератор, который не навязывает своё мнение, а помогает команде услышать себя.

Этап 4: Подготовка инструментов и людей

Подготовка инструментов и участников моделирования, это переход от теории к практике, когда абстрактные идеи и формализованные правила превращаются в рабочие механизмы для симуляции.

Сначала идёт настройка агентного моделирования (АВМ).
Настройка агентного моделирования (АВМ) — это не просто загрузка правил в электронную таблицу, а реализация рабочей среды, где эти правила оживают.Если на предыдущем этапе принято решение использовать АВМ как основной инструмент, то следующим шагом становится выбор и внедрение специализированного программного обеспечения. Это требует инвестиций, времени и совместной работы команды консультантов и сотрудников компании.

Процесс включает в себя закупку и установку ПО, обучение команды (как консультантов, так и ключевых сотрудников) работе с платформой, настройку среды, адаптацию её под специфику нашей онтологии и правил.

Примеры программного обеспечения для агентного моделирования

В мире существует несколько мощных платформ, каждая со своими сильными сторонами. Например, AnyLogic: Это, пожалуй, самый популярный и гибкий инструмент на рынке. Его главное преимущество — гибридность. AnyLogic позволяет комбинировать агентное моделирование с другими методами, такими как системная динамика и дискретно-событийное моделирование. NetLogo это бесплатная, открытая платформа, разработанная в Северо-Западном университете. Она невероятно популярна в научной среде и отлично подходит для обучения и создания прототипов. NetLogo имеет низкий порог входа, что позволяет быстро "набросать" модель и проверить идею. Repast (Recursive Porous Agent Simulation Toolkit) это серия инструментов с открытым исходным кодом, разработанных Аргоннской национальной лабораторией. Repast предоставляет максимальную гибкость и контроль для опытных разработчиков.
Таким образом, создание виртуального "двойника" организации — это не только концептуальная работа по описанию правил, но и серьёзное технологическое начинание, требующее выбора подходящего инструмента и вовлечённости команды в его освоение.

Далее мы берём онтологию, которую создали на предыдущем этапе — ту самую ER-диаграмму с сущностями, ролями и связями — и "оживляем" её в рабочей среде.

Каждая ключевая роль (генеральный директор, финансовый директор, IT-директор) становится цифровым агентом. Мы загружаем в модель их правила поведения: например, "Финансовый директор не утверждает инвестиции без срока окупаемости менее 3 лет" или "IT-директор требует от бизнес-единиц полное описание изменений за 14 дней до внедрения". Это как создать виртуальный "двойник" организации, где каждый её участник действует по своим внутренним законам.

Одновременно может идти подготовка нейросети (если мы решили использовать нейросетку). Здесь главная задача — не просто запустить алгоритм, а обеспечить ему качественное "топливо". Мы собираем все доступные данные: финансовые отчёты, показатели эффективности процессов, структуру персонала, историю проектов.

Но просто "засыпать" всё это в нейросеть — значит гарантировать бессмысленный результат. Сначала проводится тщательная очистка и структурирование: убираются дубликаты, исправляются ошибки, противоречивые данные сверяются с экспертами. Только после этого данные становятся пригодными для анализа. Например, если в одном отчёте указан бюджет на IT в размере 100 млн, а в другом — 120 млн, мы не выбираем наугад, а выясняем у финансистов и IT-руководителей, какая цифра корректна и почему.

Параллельно мы подготавливаем участников будущих деловых игр. Это не просто "приходите на встречу", а полноценный брифинг. Мы объясняем суть методологии, знакомим с онтологией, даём понять, что от них требуется. Участники проекта могут погружаться не только с свою роль и точку зрения, но в позицию другого руководителя. Иногда проводятся тренировочные сессии, на которых, например, финансовый директор "примеряет" на себя роль директора по безопасности, чтобы понять, откуда берутся его требования. Это развивает эмпатию и ломает стереотипы.

И, наконец, мы создаём сценарии для симуляции. Это не фантастические предсказания, а конкретные "что если?" вопросы, которые волнуют топ-команду.

Например "Что если мы запустим агрессивную программу масштабирования на три новых рынка?". "Что если бюджет на ИТ-инфраструктуру будет сокращён на 20%?". "Что если одна из бизнес-единиц будет продана?"

Эти сценарии становятся "пусковыми крючками" для симуляции в модели или на деловой игре, позволяя увидеть, как система в целом отреагирует на конкретные стратегические решения.

Этап 5: Проведение серии игр с агентами

Запускаем симуляцию. Это момент истины, когда абстрактные правила и формализованные требования оживают.

Агенты — будь то цифровые двойники в программе или люди, играющие роли ключевых руководителей на деловой игре — начинают действовать в рамках заданных им правил. Процесс может проходить в виртуальной среде агентного моделирования или в формате интенсивной рабочей сессии, но суть одна: мы создаём замкнутый экспериментальный полигон для сложной организации.

В течение симуляции я, как консультант стараюсь. не вмешиваться, а наблюдать.
Моя задача — не управлять, а видеть.
Надо зафиксировать то, как в системе проявляются её скрытые механизмы.
Где и почему возникают конфликты? Например, мы видим, что директор по безопасности постоянно блокирует инициативы IT-директора. В симуляции становится ясно: это не личная вражда, а системный эффект.
Правила IT-директора ("максимальная гибкость и скорость внедрения") напрямую противоречат правилам директора по безопасности ("максимальная защита и контроль"). Конфликт неизбежен, пока не будет найден компромисс на уровне правил.
Где появляются "узкие места"? Симуляция показывает, что финансовый директор регулярно срывает сроки отчётности. Почему? Потому что его агент не может начать работу, пока не получит данные от всех бизнес-единиц.
А одна из бизнес-единиц, следуя своим правилам ("сначала закроем сделку, потом заполним отчёт"), всегда опаздывает. Такое "узкое место" в реальности могло бы годами оставаться невидимым, маскируясь под "недобросовестность" одного подразделения. Какие гипотезы подтверждаются, а какие рушатся? Например, топ-менеджмент считал, что главная проблема — недостаток бюджета на IT.
Симуляция показывает, что даже при увеличении бюджета на 20% ситуация не улучшается, потому что основной тормоз — нефинансовый, а в отсутствии чёткого процесса согласования требований.
Гипотеза "больше денег = больше эффективности" рушается, открывая путь к поиску другого решения. Процесс не однократный. Он итеративный.

После каждой симуляции или игровой сессии надо остановиться. Это время для рефлексии. Участники обсуждают увиденное: "Так ли мы жёстки в своих требованиях?", "Что мы можем уступить?", "Какие наши правила больше мешают, чем помогают?".

Затем следует балансировка требований. На основе рефлексии участники корректируют свои правила: может быть, финансовый директор готов подождать на два дня, если бизнес-единицы гарантированно подадут промежуточные данные? Может быть, IT-директор согласится на более строгие процедуры безопасности в обмен на приоритет в распределении ресурсов?

Только после этого запускается новая итерация. Симуляция повторяется с обновлёнными правилами. И снова мы наблюдаем, анализируем, рефлексируем.

Через несколько таких циклов система сама выходит на баланс, а команда приходит к согласованной стратегии, выросшей из живого процесса диалога, а не навязанной сверху.

Этап 6: Фиксация и документация результатов

Фиксация результатов — это не просто составление финального документа, а создание живой карты принятых решений. Мы фиксируем не только итоговую стратегию, но и весь путь, который к ней привёл. Это позволяет в будущем не только знать, что было решено, но и понимать, почему.

Мы отвечаем на ключевые вопросы. Какие точки зрения были учтены, а какие — скорректированы? Например, мы фиксируем, что первоначальное требование IT-директора о 100%-й доступности всех систем было смягчено после симуляции, которая показала, что для 80% бизнес-процессов достаточно уровня в 95%. Это не "поражение" IT, а осознанный компромисс, зафиксированный в протоколе. На каких компромиссах мы остановились?

Явно прописываем, где были найдены балансы. Скажем, финансовый директор согласился на увеличение бюджета на цифровизацию, но при условии, что каждая бизнес-единица будет выделять 15% своих ресурсов на внедрение новых процессов. Такой компромисс становится не устной договорённостью, а частью стратегического артефакта. Какие гипотезы подтвердились, а какие — опроверглись?

Фиксируем результаты симуляций. Например, гипотеза "увеличение штата HR решит все проблемы найма" была проверена и отклонена — модель показала, что основной узкий момент — не в количестве HR-менеджеров, а в устаревшем процессе согласования вакансий между директорами.

Это знание сохраняется и помогает избежать ошибок в будущем. Всё это превращает итоговый документ из "мёртвого плана", который пылится на полке, в живой, дышащий артефакт. Он становится не просто инструкцией, а памятью организации — её коллективным опытом, зафиксированным в процессе сложного, но продуктивного согласования.

Кейсы из практики

Кейс 1: Бурно растущий многопрофильный холдинг

Перед нами стояла сложная задача: холдинг, состоящий из десяти бизнес-единиц, переживший бурный рост, оказался на грани системного сбоя. Организационная структура была настолько запутанной, что превратилась в лабиринт, а постоянные конфликты за ресурсы между подразделениями блокировали любые инициативы.

Заказчик хотел не просто перерисовать схему своей организации, а создать новую, живую оргструктуру, способную выдержать будущий рост и превратить конкуренцию в синергию.

Проект начался с основ. Была создана рабочая группа, которая описала онтологию системы, чётко выделив ключевые сущности и роли. Каждый директор стал "агентом" со своими целями, ограничениями и требованиями к другим. Затем была проведена серия деловых игр с членами совета директоров. В ходе деловых игр они не просто обсуждали, а буквально "проживали" конфликты и последствия своих решений в безопасной среде.

В результате они вышли не на очередной компромисс, а на подлинное согласие.
Была принята новая стратегия и оргструктура, которая не навязывалась сверху, а выросла из процесса диалога. Она стала балансом интересов, где были учтены как амбиции бизнес-единиц, так и потребности общей инфраструктуры, став прочным фундаментом для устойчивого развития.

Кейс 2: Университет

Перед университетом стояла непростая задача: нужно было сбалансировать хрупкую финансовую систему, где поступления от государственного финансирования и доходы от внебюджетной деятельности всё больше расходились с растущими операционными затратами.
Цель, поставленная ректором состояла в том, чтобы не просто перераспределить деньги, а выстроить устойчивую стратегию. Требовалось чётко разделить управление проектами и текущими процессами, а также оптимизировать штатное расписание, чтобы оно соответствовало реальной нагрузке и стратегическим приоритетам.
После серии глубоких сессий с ректоратом на основе методологии "точек зрения" были смоделированы ключевые потоки денег и решений, определены точки зрения наблюдательного совета, ректора, проректоров, факультетов, студентов (по сегментам), государства, работодателей и партнеров (по сегментам). Были описаны модели финансирования, распределения учебной и научной нагрузки, административной работы.
Это позволило увидеть, где возникают дисбалансы, а где — скрытые резервы.
В результате была принята новая стратегия финансирования и финмодель, введены новые стандарты управления проектами и обновлённое штатное расписание, которое отражало не административные пожелания, а реальную картину потребностей университета.

Кейс 3: Проект государственно-частного партнёрства

Перед командой стояла сложная задача: нужно было не просто составить концессионного соглашения, а сформировать живую дорожную карту для проекта государственно-частного партнёрства. Требовалось привлечь частных инвесторов, выстроить доверительные отношения с органами власти и выработать общий вектор действий для всех участников, у которых изначально были разные цели и приоритеты.

Цель, поставленная руководителем состояла в том, чтобы создать не просто план, а согласованную стратегию, в которой каждый участник видел бы своё место и ценность.

На начальном этапе была описана онтология проекта, чётко выделены ключевые точки зрения — инициаторов, партнёров, регуляторов, описаны ресурсы и риски. Затем была проведена серия деловых игр с инициаторами проекта. В ходе симуляций они "проживали" и просчитывали возможные сценарии: как реагируют власти на тот или иной шаг, как частные партнёры оценивают риски, где возникают точки напряжения.

В результате проект вышел не на компромисс, а на подлинное согласие. Была сформирована детальная дорожная карта и чёткий план взаимодействия с госорганами, который стал общим знаменателем для всех участников проекта.

Ограничения метода

Как учил сэр Карл Раймунд Поппер, претендовать на универсальность и вездесущность может только религия. Научные методы, напротив, всегда ограничены и фальсифицируемы. Их сила не в том, чтобы объяснить или подписываться на всё, а в том, чтобы честно признавать свои границы.

Именно в этом — зрелость науки и научного метода: не в поиске волшебной палочки, а в понимании, где и как метод работает, а где он начинает хромать. Методология Точек зрения — это мощный инструмент, но он не является исключением.

Вот в чём её основные ограничения и уязвимости, с которыми необходимо считаться.

Сопротивление и политические игры. Методология требует от руководителей раскрывать свои скрытые цели, правила и ограничения. В политизированной среде это воспринимается как угроза, а не как возможность. Участники могут сознательно искажать информацию, чтобы сохранить влияние или ресурсы.

Низкая зрелость и недостаток доверия. Для успеха необходима культура открытости и готовность к рациональному компромиссу. Если в организации принято скрывать проблемы и искать виноватых, процесс превратится в формальность или еще один повод для конфликта.

Ресурсоемкость и «усталость от диалога». Процесс итеративных сессий требует огромных затрат времени и интеллектуальной энергии самых дорогих сотрудников компании (топ-менеджеров). Есть риск, что они не дойдут до финала, потеряют интерес или будут участвовать формально.

Проблема ответственности. Результатом является не директива «сверху», а коллективно выработанное решение. В случае неудачи возникает соблазн возложить вину на «плохую модель» или «неэффективный процесс», а не на самих участников, что размывает ответственность.

Проблема репрезентативности: Чьи «точки зрения» мы учитываем? Всегда есть риск упустить ключевых, но «тихих» стейкхолдеров (например, ключевых инженеров, представителей клиентов, рядовых сотрудников) или, наоборот, придать чрезмерный вес самым громким голосам. Модель будет неполной или перекошенной.

Риск «аналитического паралича» (Analysis Paralysis). Процесс может увязнуть в бесконечных итерациях уточнения и симуляции в погоне за «идеальным» согласованием. В результате компания упускает время для реальных действий, подменяя их бесконечным моделированием.

Упрощение реальности. Какую бы сложную модель мы ни построили, она остается упрощением. Опасность в том, что команда начнет верить в то, что цифровой двойник — это и есть реальность, и утратит чувствительность к непредсказуемым, непроформализуемым факторам (внезапный технологический прорыв, изменение поведения конкурентов, форс-мажор).

Зависимость от качества модерации. Успех на 80% зависит от навыков фасилитатора. Слабый модератор не сможет управлять групповой динамикой, нейтрализовать манипуляции или перевести личные амбиции в конструктивное русло.

«Мусор на входе — мусор на выходе» (Garbage In, Garbage Out). Это фундаментальная проблема любого моделирования. Если исходные данные (правила, цели, исторические данные) некачественны, предвзяты или устарели, то и выводы симуляции будут ложными, несмотря на всю сложность алгоритмов.

Сложность формализации «мягких» факторов. Как точно выразить в правилах агента корпоративную культуру, неформальные отношения между директорами, уровень доверия или интуицию эксперта? Эти факторы часто являются решающими, но либо остаются за скобками модели, либо сильно упрощаются.

Интерпретируемость (Explainability) результатов. Особенно остро эта проблема стоит для моделей на основе нейросетей («черный ящик»). Почему модель выдала именно такой результат? Если команда не понимает логики, она не будет доверять выводам и откажется от них. Даже в случае с прозрачным ABM цепочки причинно-следственных связей могут быть чрезвычайно сложны для восприятия.

Затраты на разработку и поддержку. Создание и, что важно, постоянное обновление цифрового двойника — это дорогое IT-решение, требующее узкоспециализированных компетенций (системные аналитики, data scientists, разработчики моделей).

Рик оптимизации прошлого, а не изобретения будущего. Модель, построенная на основе текущих «точек зрения» и исторических данных, по своей сути консервативна. Она оптимизирует существующую систему. Но что, если нужна не оптимизация, а прорывная трансформация? Методология может незаметно стать инструментом подавления инноваций, которые изначально кажутся «неоптимальными» для текущей конфигурации.

Слепые зоны. Модель не может учесть то, о чем не знают или не думают ее создатели. Внезапные изменения во внешней среде (геополитика, новые регуляции, пандемия), о которых изначально не спросили ни у одной из «точек зрения», могут мгновенно обесценить все полученные согласования.

Методология на основе фреймворков Точек зрения это не волшебная таблетка, а мощный, но сложный инструмент, который требует чрезвычайно высокой организационной культуры и зрелости.

Ее главная уязвимость в том, что она бессильна в руках тех, кто не готов к честному диалогу, рефлексии и принятию коллективной ответственности. Она не заменяет стратегическое лидерство, а лишь усиливает его — при условии, что лидеры готовы к тому, что модель может показать им неприглядные истины об их собственной организации.

Выводы

Когда мы признаём, что нет единой истины, а есть множество валидных позиций, процесс принятия решений становится не просто формальностью, а настоящим диалогом.

Это кардинально повышает вовлечённость руководителей: они не получают "готовый план сверху", а участвуют в его создании. В результате стратегия перестаёт быть мёртвым документом и превращается в живую, адаптивную систему, способную реагировать на изменения. Важнейшее преимущество — возможность увидеть не только отдельные решения, но и системные эффекты, которые возникают из взаимодействия этих решений.

Однако, как и любой мощный инструмент, эта методология требует уважения к себе.

Она предъявляет высокие требования к зрелости организации. Процесс дорогостоящий и времязатратный, он не подходит для быстрых решений и простых целей.

Без опытного модератора, способного держать баланс и направлять диалог, он легко может скатиться в хаотичное обсуждение или превратиться в формальность.

И, конечно, это не панацея: если проблему можно решить простым совещанием — не стоит запускать масштабный проект.

Итог прост: методология "Точки зрения" не даёт готовых ответов. Она помогает пройти путь — путь от конфликта к согласию, от разрозненных взглядов к общей стратегии. И именно этот путь, а не статичный документ, становится ключом к устойчивому развитию в мире постоянной неопределённости.

Владислав Тарасенко

Доцент МГТУ им. Н.Э. Баумана, более 30 лет занимающийся исследованием и проектирование систем, увлечен философскими основами вычислительной техники и искусственного интеллекта. Специализируется на соединении абстрактных теорий с практической реализацией.