Methodology Map — карта применения пяти design-time методологий из блока №78–82: TRIZ / ТРИЗ, Kepner–Tregoe, TOC, IDEF0 и BPMN. Её задача — не учить каждой методике заново, а отвечать на практический вопрос: какой инструмент использовать для какой проблемы и в каком порядке сочетать несколько методов.
№78–82 own their methods. №83 owns selection, sequencing and handoff between them. №13 Problem Formulation happens before/alongside any methodology. №30 Simulation, №36 Formal Solvers, №45 Verification and №47 Evals validate proposed changes. №84–94 measure business/AI outcomes after implementation.
Prerequisites: №78 TRIZ, №79 Kepner–Tregoe, №80 TOC, №81 IDEF0, №82 BPMN. Strong cross-links: №13 Problem Formulation, №23 Uncertainty, №30 What-If, №40 Eval-Driven Optimization, №46 Observability, №47 Evals, №77 Production Architecture.
CONTROL: method selection heuristics/templates. DATA: problem statement, method outputs and evidence. RUNTIME: N/A, though an AI assistant may route a design request to the correct method. OFFLINE: architecture review, product/system redesign, incident analysis and operations improvement.
Success: method chosen matches the actual question; handoff artifacts are explicit; methodology stops when enough structure exists to test a solution. Failure: method used because team knows it, every issue gets one favorite template, diagrams replace evidence, or multiple methods are combined without a clear question boundary.
№83 does not invent a universal “super-methodology”. It does not merge notations into one diagram and does not claim one method subsumes the others. It owns WHEN, WHY AND IN WHAT ORDER TO USE DIFFERENT PROBLEM-SOLVING LENSES.
Technical and physical contradictions, IFR, resources, separation, inventive principles, trimming and ARIZ-style deepening.
Situation Appraisal, IS / IS NOT Problem Analysis, MUST/WANT Decision Analysis and Potential Problem Analysis.
System goal, throughput, current constraint, exploit, subordinate, elevate, Drum-Buffer-Rope and WIP management.
Purpose/viewpoint, A-0 context, ICOM, decomposition, balancing and functional ownership.
Participants, events, tasks, gateways, waits, message flows, exceptions, compensation and end states.
| Situation | Primary method | Why |
|---|---|---|
| Cause of unexpected deviation is unknown | Kepner–Tregoe | IS / IS NOT narrows causal hypotheses against observed facts. |
| Two requirements appear mutually incompatible | TRIZ | Contradiction/separation/resource logic searches beyond compromise. |
| Entire multi-stage system is slow / queues grow | TOC | Finds which factor currently limits system throughput. |
| Architecture responsibilities/functions are unclear | IDEF0 | Separates function, input, control, output and mechanism. |
| Exact process order, approvals, timers or callbacks are unclear | BPMN | Models temporal/process semantics explicitly. |
| Need to choose between known alternatives | Kepner–Tregoe Decision Analysis | MUST/WANT/evidence/risk selection. |
| Need to prepare chosen plan for failure | KT Potential Problem Analysis | Preventive, contingent and trigger logic. |
| Need to radically simplify architecture | IDEF0 → TRIZ | Map functions first, then trim/transfer mechanisms. |
| Need to improve process throughput | BPMN → TOC | Map actual flow/waits, then identify constraint. |
START ↓ WHAT IS THE PRIMARY QUESTION? “WHAT FUNCTIONS / BOUNDARIES EXIST?” → IDEF0 “WHAT HAPPENS IN WHAT ORDER?” → BPMN “WHY DID THIS DEVIATE?” → KEPNER–TREGOE PROBLEM ANALYSIS “WHICH OPTION SHOULD WE CHOOSE?” → KEPNER–TREGOE DECISION ANALYSIS “WHAT COULD BREAK THE CHOSEN PLAN?” → KEPNER–TREGOE POTENTIAL PROBLEM ANALYSIS “WHAT LIMITS THE WHOLE SYSTEM?” → TOC “WHY MUST WE ACCEPT THIS TRADE-OFF?” → TRIZ IF TWO QUESTIONS ARE PRESENT: use methods sequentially, not simultaneously by default.
| Question | TRIZ | KT | TOC | IDEF0 | BPMN |
|---|---|---|---|---|---|
| Root-cause diagnosis | Low | High | Medium | Low | Low |
| Invent new mechanism | High | Low | Medium | Low | Low |
| Resolve trade-off | High | Medium | Medium | Low | Low |
| Choose alternative | Medium | High | Low | Low | Low |
| Find system constraint | Low | Medium | High | Medium | Medium |
| Functional decomposition | Medium | Low | Low | High | Medium |
| Exact process flow | Low | Low | Medium | Low | High |
| Waits / timers / callbacks | Low | Low | Medium | Low | High |
| Rollout risk | Medium | High | Medium | Low | Medium |
| Simplify components/functions | High | Low | Medium | High | Medium |
Contradiction, IFR, resources, candidate mechanisms, secondary contradictions, experiment.
Problem facts/cause test or MUST/WANT matrix, chosen alternative, risks and review triggers.
Goal, throughput unit, constraint evidence, exploit/subordinate/elevate actions.
A-0/A0 functions, ICOM, mechanisms, controls and boundary gaps.
Participants, tasks, gateways, waits, events, exception paths and terminal states.
Find major functions, controls, mechanisms and boundaries.
Choose where order, wait, branch or handoff matters.
Specify exact lifecycle, events, participants and exception paths.
BPMN:
maps actual process:
tasks
waits
pools
callbacks
approvals
rework
↓
attach telemetry:
cycle time
queue age
WIP
capacity
failure/rework
↓
TOC:
identify current constraint
exploit
subordinate
elevate
repeat
Identifies the stage currently governing system output.
Why is capacity suddenly lower / rework higher?
IS / IS NOT + distinctions + changes + verified cause.
KT verifies cause:
“deep human review is the current
reason approval throughput is low.”
Possible fix:
reduce review depth.
But:
quality / safety may fall.
↓
TRIZ contradiction:
review must be deep
AND must be lightweight.
↓
separation by condition:
high-risk → deep human review
low-risk → deterministic/auto checks
↓
new architecture concept
Produces several distinct solution mechanisms.
MUST/WANT, evidence, sensitivity and adverse consequences.
Choose the best feasible concept rather than the most novel one.
KT Potential Problem Analysis:
potential problem:
human approval never arrives
preventive:
notify / assign owner
trigger:
24h elapsed
contingent:
escalate / expire
↓
BPMN:
[Wait approval]
boundary timer 24h
↓
[Escalate / expire]
The risk plan becomes
explicit process behavior.
No methodology workshop if cause and correction are obvious.
No need for full IDEF0/BPMN if context is already understood.
Skip process modeling if conflict is already localized.
No need to invoke TOC until performance/throughput is actually the issue.
Problem statement + one fitting worksheet + concrete next experiment.
Example: BPMN → TOC or KT → TRIZ → KT Decision.
IDEF0 + BPMN + telemetry + TOC + KT + TRIZ + simulation/evals for high-impact architecture redesign.
| Problem | Method route |
|---|---|
| RAG quality dropped after a release | KT Problem Analysis → verify cause → fix → eval. |
| Need higher quality but cannot accept 2× latency | TRIZ → adaptive/separation concept → eval. |
| Human review queue grows every day | BPMN map → TOC → exploit/subordinate/elevate. |
| Unclear whether policy engine, router or gateway owns provider eligibility | IDEF0 → functions/controls/mechanisms → contracts. |
| Need choose vector platform | KT Decision Analysis → benchmark evidence → sensitivity/risk. |
| Approval workflows sometimes hang forever | BPMN → explicit message/timer/end states → durable workflow. |
| Current bottleneck fix creates quality/security conflict | TOC → TRIZ → KT Decision/PPA. |
“OUR AI SYSTEM FEELS TOO COMPLEX” ↓ IDEF0 map major functions controls mechanisms outputs ↓ find: duplicated functions missing controls shared overloaded mechanisms dead outputs ↓ TRIZ / trimming can a mechanism be removed? can function move to existing component? can condition separate expensive behavior? ↓ KT Decision Analysis compare redesign alternatives ↓ BPMN only for workflows whose temporal behavior changed ↓ EVAL / load / security validation
ALERT ↓ KT Situation Appraisal split symptoms / prioritize ↓ KT Problem Analysis IS / IS NOT distinctions / changes ↓ verify cause ↓ if bottleneck/systemic: TOC ↓ if fix has hard trade-off: TRIZ ↓ if multiple fixes: KT Decision Analysis ↓ KT Potential Problem Analysis ↓ BPMN / workflow update only if process semantics change ↓ canary / eval / observe
IDEF0: what functions exist? what controls them? who/what performs them? ↓ BPMN: exact process participants waits exceptions ↓ TOC: which manual/technical stage limits throughput? ↓ TRIZ: can scarce manual function be reduced/transferred/automated without violating quality? ↓ KT: choose automation design and de-risk rollout ↓ Production Architecture: contracts queue/workflow HITL observability governance ↓ eval
KT may diagnose a real local problem, but TOC can show fixing it has negligible system impact. Fix only if risk/quality independently justifies it.
TRIZ may create bold concept; KT can reject it because it fails MUST objective or has adverse consequence.
A function model and process model may look structurally different without contradiction because they answer different questions.
Functions and external ICOM depend on boundary.
Pool boundaries change message vs sequence semantics.
Constraint changes when system boundary/goal changes.
Cause/contradiction can move when the modeled system expands.
input:
messy architecture / incident / process question
AI classifier:
unknown cause?
hard contradiction?
system constraint?
function boundary?
temporal workflow?
alternative selection?
rollout risk?
↓
method recommendation:
KT PA
TRIZ
TOC
IDEF0
BPMN
KT DA
KT PPA
↓
use ONE first
↓
if output exposes
a new question class:
hand off to next method
{
"problem_statement":"...",
"system_boundary":"...",
"goal":"...",
"signals":{
"unknown_cause":true,
"hard_tradeoff":false,
"multi_stage_flow":true,
"process_order_unclear":false,
"functional_ownership_unclear":false,
"alternative_selection":false,
"rollout_risk":false
},
"recommended_method":{
"id":79,
"name":"Kepner–Tregoe Problem Analysis",
"reason":"unexpected deviation with unknown cause"
},
"next_possible_methods":[
"TOC if systemic throughput impact emerges",
"TRIZ if verified fix creates contradiction"
]
}The assistant must state why a method fits the problem and what evidence/output will determine whether another method is needed next.
Example:
KT → TRIZ handoff
{
"verified_problem":"human review limits throughput",
"verified_cause":"blanket review policy",
"goal":"increase accepted tasks/day",
"hard_constraints":[
"high-risk actions require human approval"
],
"tradeoff":{
"improve":"automation rate",
"worsens":"risk / quality"
},
"evidence_refs":[...]
}
TRIZ can now work
on a grounded contradiction,
not rediscover the incident.
Traces, metrics, queues, failure data.
Rollback, prototype, load test, controlled change.
Does redesign improve actual task distribution?
Solver or what-if analysis where quantifiable.
Did selected methodology directly address the uncertainty/problem class?
Time from messy problem to testable next step.
Can next method use prior output without re-discovery?
Fewer cycles solving wrong problem / changing decision.
Claims/decisions point to telemetry, benchmark or experiment.
Method cost relative to decision/problem value.
Did resulting change improve actual system/business metric?
Can another team reproduce the analysis from structured artifacts?
| Minute | Question |
|---|---|
| 0–2 | What system boundary and outcome are we talking about? |
| 2–4 | Is this primarily cause, trade-off, constraint, function map, process map, option choice or rollout risk? |
| 4–6 | What evidence already exists? What is actually unknown? |
| 6–8 | Select the smallest method and define its expected output. |
| 8–10 | Define exit condition: what concrete result lets us stop and test/act? |
METHODOLOGY ROUTER
========================================================
SYSTEM / SCOPE
→
GOAL / DESIRED OUTCOME
→
PRIMARY UNCERTAINTY
[ ] We don't know WHY deviation happened
→ KT Problem Analysis
[ ] We need to CHOOSE among known alternatives
→ KT Decision Analysis
[ ] We chose a plan and need to DE-RISK it
→ KT Potential Problem Analysis
[ ] Requirements form a hard TRADE-OFF / contradiction
→ TRIZ
[ ] Multi-stage system throughput is constrained
→ TOC
[ ] Functional responsibilities / controls / mechanisms unclear
→ IDEF0
[ ] Sequence / waits / events / handoffs unclear
→ BPMN
--------------------------------------------------------
DO WE NEED A SECOND METHOD?
After KT diagnosis:
[ ] fix creates contradiction → TRIZ
[ ] problem is system constraint → TOC
[ ] multiple fixes → KT Decision
After TRIZ:
[ ] several concepts → KT Decision
[ ] implementation risks → KT PPA
[ ] process changes → BPMN
After TOC:
[ ] constraint behavior unexplained → KT PA
[ ] constraint fix has hard trade-off → TRIZ
[ ] process release/wait logic changes → BPMN
After IDEF0:
[ ] temporal workflow needs detail → BPMN
[ ] shared scarce mechanism → TOC
[ ] function simplification → TRIZ
After BPMN:
[ ] bottleneck / WIP → TOC
[ ] deviation → KT
[ ] process conflict → TRIZ
--------------------------------------------------------
EXIT CONDITION
What artifact must this method produce?
→
What evidence / experiment follows?
→
When do we STOP methodology work?
→
You are a design-time methodology router.
Do not immediately apply a framework.
First:
1. Restate the system boundary and desired outcome.
2. Identify the primary uncertainty/problem type:
- unknown cause;
- hard contradiction/trade-off;
- system constraint/throughput;
- unclear functional structure;
- unclear process dynamics;
- alternative selection;
- rollout/potential problem.
3. Select the SMALLEST suitable method:
KT Problem Analysis,
KT Decision Analysis,
KT Potential Problem Analysis,
TRIZ,
TOC,
IDEF0,
BPMN.
4. Explain in one sentence why it fits.
5. Define the expected structured output of that method.
6. Do not combine methods unless the first method's output
reveals a different second question.
7. When combining methods, explicitly create a handoff artifact.
8. Never treat diagrams, scores or methodology outputs as evidence.
9. End with a concrete verification step:
observation, experiment, prototype, simulation, benchmark or eval.
10. Stop when additional methodology work would not change
the next decision or experiment.
| Question | Answer |
|---|---|
| Стоит ли использовать? | Да. As a compact design-time router/reference over №78–82. |
| Separate Component? | N/A. No runtime service; optionally a worksheet/prompt/template inside design assistant. |
| Минимум 80% ценности? | Problem-type classification, one primary method, explicit expected output, handoff rules and validation step. |
| Когда overkill? | When the team already knows exactly which method/question applies and needs no routing. |
| Trigger? | “Which framework should we use?” or “we are mixing diagnosis, architecture, process and invention in one discussion”. |
| Как измерить uplift? | Faster time to actionable model, less analysis rework, better method fit, clearer handoffs and higher measured success of resulting changes. |
| Можно ли использовать AI? | Да. This is an ideal low-cost AI assistant function: classify problem type, propose the smallest method and preserve structured handoffs. |
Choose framework from problem type, not team habit.
Combine only when a second distinct question appears.
Diagnosis, invention, flow, function and process are not the same task.
Do not restart discovery between methods.
Use a 20-minute worksheet before a multi-day workshop.
All five methods depend on system context.
Validate with evidence, experiments and evals.
Stop when further formalization cannot change the next action.
LLM can choose/apply frameworks, but factual/system conclusions require external verification.
MESSY REAL-WORLD PROBLEM
↓
DEFINE:
SYSTEM BOUNDARY
GOAL
WHAT IS ACTUALLY UNKNOWN?
↓
────────────────────────────────────────
UNKNOWN CAUSE?
↓
KEPNER–TREGOE
Problem Analysis
WHAT / WHERE / WHEN / EXTENT
IS / IS NOT
distinctions
changes
cause hypothesis
verification
────────────────────────────────────────
HARD TRADE-OFF?
↓
TRIZ
technical contradiction
physical contradiction
IFR
resources
separation
inventive principles
mechanism concepts
secondary contradictions
────────────────────────────────────────
SYSTEM THROUGHPUT STUCK?
↓
TOC
goal
throughput
WIP
constraint
exploit
subordinate
elevate
repeat
────────────────────────────────────────
FUNCTIONS / OWNERSHIP UNCLEAR?
↓
IDEF0
purpose / viewpoint
A-0
INPUT
CONTROL
OUTPUT
MECHANISM
decomposition
balancing
────────────────────────────────────────
ORDER / WAIT / HANDOFF UNCLEAR?
↓
BPMN
participants
events
tasks
gateways
messages
timers
errors
wait states
compensation
end states
────────────────────────────────────────
KNOWN ALTERNATIVES?
↓
KT DECISION ANALYSIS
MUST
WANT
weights
evidence
alternatives
sensitivity
adverse consequences
────────────────────────────────────────
PLAN CHOSEN?
↓
KT POTENTIAL PROBLEM ANALYSIS
potential problem
likely cause
preventive action
trigger
contingent action
owner
────────────────────────────────────────
COMMON CHAINS:
IDEF0
→ BPMN
→ TOC
TOC
→ KT diagnosis
→ TRIZ
TRIZ
→ KT Decision
→ KT PPA
KT PPA
→ BPMN implementation
ALL CHAINS
→ PROTOTYPE / EXPERIMENT / EVAL
→ PRODUCTION ARCHITECTURE
→ OBSERVABILITY
→ REAL OUTCOME
════════════════════════════════════════
USE TRIZ
WHEN YOU NEED TO INVENT.
USE KT
WHEN YOU NEED TO DIAGNOSE,
CHOOSE OR DE-RISK.
USE TOC
WHEN YOU NEED TO FOCUS
THE WHOLE SYSTEM
ON ITS CURRENT LIMIT.
USE IDEF0
WHEN YOU NEED TO UNDERSTAND
WHAT FUNCTIONS EXIST
AND WHAT CONTROLS / ENABLES THEM.
USE BPMN
WHEN YOU NEED TO UNDERSTAND
WHAT HAPPENS OVER TIME,
WHO WAITS,
AND WHAT HAPPENS
WHEN THINGS GO WRONG.
AND IF YOU ARE ABOUT TO USE
ALL FIVE AT ONCE:
ASK AGAIN
WHICH QUESTION
YOU ARE ACTUALLY
TRYING TO ANSWER.
A. Related ECC ideas. Context-as-cache, scoped memory, lifecycle hooks, selective capabilities, feature flags, deterministic enforcement, provider-neutral adapters and eval-gated learning are applied only where relevant to №83 Methodology Map.
B–E. Existing boundary and placement. The existing conceptual boundary, class METHODOLOGY, default N/A and owner Design-time / Problem Solving remain authoritative. Runtime/control/data/offline placement is unchanged; durable state stays outside model context.
F–H. Hooks and contracts. Use bounded PRE_MODEL/POST_MODEL, PRE_TOOL/POST_TOOL, CHECKPOINT and TASK_COMPLETED events as applicable. Illustrative fields and canonical contracts are defined in NEW_CONTRACTS_SPEC.md; no universal schema is implied.
I–J. Security and evaluation. Host-side schema, permission, secret, budget, idempotency and audit checks take precedence over LLM output. Optional mechanisms require a feature flag and WITH/WITHOUT ablation; measure quality, acceptance, correction, latency, cost, escalations and severe errors.
K–L. Task profiles and cross-references. A TaskProfile selects the relevant skill, tool/context slice, memory scope and enforcement profile independently from FAST/STANDARD/DEEP. See cross-reference map, hook spec and ablation plan. Provider adapters remain outside the core.