Сделайте сравнение трассируемым: покажите, какие критерии важны, как данные переводятся в общую шкалу и меняется ли ranking при разумных изменениях.
За одну минуту
Матрица решений размещает сопоставимые альтернативы в строках, а критерии — в столбцах. Взвешенный вариант обычно:
- фильтрует варианты по обязательным требованиям;
- задаёт неперекрывающиеся критерии и наблюдаемые шкалы;
- назначает веса до раскрытия performance scores;
- оценивает варианты с источником и confidence;
- рассчитывает weighted totals;
- проверяет sensitivity к неопределённым баллам, весам и составу вариантов;
- фиксирует ответственное решение, риски и dissent.
Итог — модель явных предпочтений и данных, а не доказательство объективно лучшего ответа. Близкий или нестабильный ranking требует улучшить evidence или явно принять trade-off.
Лучше всего для: определённых альтернатив, отвечающих на один вопрос по нескольким различающим критериям.
Не использовать, если: варианты несопоставимы, одно требование уже решает eligibility или неопределённость нельзя честно выразить баллами.
Проблема, которую решает метод
Обсуждения смешивают критерии, факты и предпочтения. Один участник говорит о цене, другой о риске, а любимый вариант получает выгодные трактовки задним числом.
Матрица выявляет структуру, но может создать ложную уверенность при double counting, неясных шкалах, среднем балле для missing evidence или подстройке весов. Поэтому sensitivity analysis — часть метода.
Когда использовать метод
Используйте матрицу, когда:
- два–восемь вариантов отвечают на один decision statement;
- выбор зависит от нескольких разных outcomes;
- критерии можно операционально определить;
- trade-offs должны быть видимы reviewer'ам;
- procurement, architecture или product concepts требуют записи;
- качественные и количественные данные нужно соединить;
- команда может проверить uncertain weights и scores.
Когда не использовать метод
Не применяйте её:
- для генерации альтернатив;
- чтобы компенсировать провал обязательного требования;
- при причинно зависимых критериях, дважды считающих выгоду;
- чтобы спрятать политическое суждение за арифметикой;
- при несопоставимых единицах без normalisation;
- как единственное основание регулируемого или необратимого решения;
- когда scenario-specific downside требует отдельного risk analysis.
Для одного критерия используйте Pairwise Comparison. Для строгого разделения Musts, Wants и consequences — Kepner-Tregoe.
Необходимые входные данные
Подготовьте:
- decision statement, владельца, горизонт и review trigger;
- сопоставимые варианты, включая status quo при необходимости;
- обязательные pass/fail requirements;
- четыре–восемь различающих критериев;
- operational scales и direction of preference;
- веса, согласованные до scoring;
- evidence, uncertainty и source notes для ячеек;
- отдельный risk/consequence review.
Пошаговый процесс
1. Сформулируйте решение
Укажите, что, для кого, на какой период и кем выбирается. Варианты должны быть одного уровня.
2. Проверьте обязательные требования
Исключите или условно допустите варианты, не прошедшие настоящий non-negotiable. Не превращайте Must в высокий вес.
3. Определите независимые критерии
Каждый критерий должен отражать отдельный outcome. Проверьте, не считают ли ease of use, adoption и user satisfaction одно и то же.
4. Постройте операциональные шкалы
До оценки определите смысл каждого балла. При normalisation разных единиц запишите правило и ограничения.
5. Назначьте веса
Зафиксируйте важность до раскрытия performance вариантов. Запишите, кто и почему выбрал веса.
6. Оцените evidence и confidence
Для каждой ячейки сохраните score, источник, assumption и confidence. Unknown должен остаться видимым.
7. Рассчитайте и изучите
Умножьте score на weight и сложите. Затем изучите причины по ячейкам, а не только итоговый rank.
8. Проверьте sensitivity
Меняйте ключевые веса и uncertain scores в правдоподобных диапазонах. Пересчитайте без избыточного критерия или с легитимным новым вариантом. Найдите assumptions, меняющие результат.
9. Проверьте последствия
Отдельно рассмотрите downside, reversibility, распределение вреда и implementation dependencies вне компенсаторного total.
10. Примите и запишите решение
Владелец фиксирует выбор, rationale, sensitivity, dissent, conditions и review trigger. Матрица рекомендует, но не обладает полномочием.
Ракурс ИИ-автоматизации
ИИ может проверять арифметику, находить пустые ячейки и дубли критериев, связывать scores с sources и запускать sensitivity scenarios.
Он не должен:
- выдумывать scores или evidence;
- выводить веса stakeholders из должности;
- принимать итоговый выбор;
- прятать failed Must в total;
- normalise несовместимые меры без объяснения;
- оптимизировать модель до победы любимого варианта.
Для серьёзных решений сохраняйте version history и человеческую запись.
Визуальная модель
Текстовая альтернатива: сопоставимые варианты проходят обязательные gates, затем оцениваются по критериям и фиксированным весам с evidence и confidence. Результат проходит sensitivity check; нестабильный возвращается к данным или trade-off, устойчивый — к ответственному решению и risk review.
Интерактивный пример
Ситуация
Логистическая компания сравнивает три customer-service platform. Все проходят требования data location и audit export. Критерии: 12-месячная стоимость, integration time, accessibility, routing quality и exit effort. Любимый вариант получает 9/10 за routing только по vendor demo.
Ваш ход
Определите operational scale для routing, решите судьбу demo score и назовите два sensitivity tests.
Разбор
Routing quality проверяется на representative blinded set: 9 — не менее 95% правильной маршрутизации и 98% recall для urgent cases; 7 — не менее 90% и 95%. До теста результат — unknown, а не 9.
Sensitivity tests меняют routing performance в правдоподобном диапазоне и удваивают вес exit effort в contract-risk scenario. Если ranking меняется, recommendation условна до получения данных.
Заметки фасилитатору
- Определите criteria и scales до любимого варианта.
- Ищите double counting.
- Отделяйте measurements от preference weights.
- Используйте ranges для uncertain cost и schedule.
- Показывайте evidence по ячейкам.
- Сохраняйте dissent и authority владельца.
Ожидаемый выпуск
- точный decision statement и варианты;
- обязательные gate results;
- operational criteria и non-overlap check;
- веса с rationale;
- scores с source, assumption и confidence;
- воспроизводимый расчёт;
- sensitivity и consequence analysis;
- решение и review trigger.
Типичные ошибки
- Неопределённые шкалы. 8/10 ничего не значит без определения.
- Double counting. Связанные критерии скрыто усиливают preference.
- Unknown как average. Missing evidence должно быть видно.
- Weight tuning. Изменение после winner — оправдание задним числом.
- Ложная точность. Decimal totals не уточняют качественные данные.
- Нет sensitivity. Легко меняющийся ranking неустойчив.
Контрольный список качества
- Варианты отвечают на один вопрос.
- Обязательные требования — pass/fail.
- Критерии различают варианты и не дублируются.
- Шкалы определены операционально.
- Веса зафиксированы до scores.
- У каждого важного score есть evidence и confidence.
- Unknowns видимы.
- Sensitivity, risks, dissent и review trigger записаны.
Шаблон
| Критерий | Operational scale | Вес | Вариант A | Вариант B | Вариант C |
|---|---|---|---|---|---|
| Score / evidence / confidence | Score / evidence / confidence | Score / evidence / confidence |
Добавьте mandatory gates, normalisation, sensitivity, consequences, decision, dissent и review trigger. Используйте структурированный workspace-шаблон Decision Matrix.
Проверка знаний
Вопрос: вариант A опережает B на 0,7, но небольшое правдоподобное изменение uncertain criterion меняет их местами. Какой вывод сильнее?
A. A объективно лучший.
B. Нужны дополнительные десятичные знаки.
C. Ranking чувствителен; улучшите ключевые данные или сделайте выбор условным.
D. Удалите B.
Ответ: C. Sensitivity показывает отсутствие устойчивости.
Связанные инструменты
- Kepner-Tregoe разделяет Musts, Wants и consequences.
- Pairwise Comparison ранжирует по одному критерию.
- SCAMPER создаёт варианты.
- FMEA анализирует failure modes вне total.
- PDCA/PDSA проверяет assumption.
Источники
- NASA. NASA Systems Engineering Handbook, NASA/SP-2016-6105 Rev 2, section 6.8. Официальное руководство (откроется в новой вкладке). Доступ 26 августа 2026 г.
- NASA. “Systems Engineering Handbook Appendix: Trade Study.” Официальное определение (откроется в новой вкладке). Доступ 26 августа 2026 г.
- Frey, D. D. et al. “The Pugh Controlled Convergence method.” Research in Engineering Design, 20, 2009. DOI (откроется в новой вкладке). Независимый анализ связанного matrix method.
- Cinelli, M. et al. “How to support the application of multiple criteria decision analysis?” Omega, 96, 2020. DOI (откроется в новой вкладке). Независимый обзор sensitivity, robustness и rank reversal.