Back to Details

kepner-tregoe-analysis

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Kepner-Tregoe Problem Solving and Decision Making

Kepner-Tregoe问题解决与决策制定

Conduct rigorous KT analysis using the four rational processes with built-in quality validation, specification matrices, and weighted decision scoring.
使用内置的质量验证、规格矩阵和加权决策评分机制，开展严谨的KT分析。

Overview

概述

Kepner-Tregoe is a structured methodology comprising four interconnected processes for systematic problem-solving and decision-making. Developed in the 1960s, it emphasizes fact-based analysis over intuition, separating problem identification from decision-making.
The Four Rational Processes:
  1. Situation Appraisal (SA): What's going on? (Clarify, separate, prioritize)
  2. Problem Analysis (PA): Why did this happen? (IS/IS NOT specification, cause identification)
  3. Decision Analysis (DA): What should we do? (MUSTS/WANTS, alternative evaluation)
  4. Potential Problem Analysis (PPA): What could go wrong? (Risk anticipation, contingency planning)
Kepner-Tregoe是一套包含四个相互关联流程的结构化方法论，用于系统化问题解决与决策制定。该方法于20世纪60年代提出，强调基于事实的分析而非直觉，将问题识别与决策制定环节分离。
四大理性流程:
  1. 情境评估（SA）: 当前状况如何？（澄清、分类、排序）
  2. 问题分析（PA）: 问题为何发生？（IS/IS NOT规格说明、原因识别）
  3. 决策分析（DA）: 我们应采取何种行动？（MUSTS/WANTS、备选方案评估）
  4. 潜在问题分析（PPA）: 可能出现哪些问题？（风险预判、应急预案制定）

Workflow

工作流程

Process 1: Situation Appraisal

流程1：情境评估

Entry point for complex or unclear situations with multiple concerns.
Collect from user:
  1. List all current concerns, threats, opportunities, or issues (brainstorm without filtering)
  2. For each concern: What tells us this is a concern? What's at stake?
Separate and Clarify each concern:
  • Is this a PROBLEM (deviation needing cause explanation)?
  • Is this a DECISION (choice to be made)?
  • Is this a POTENTIAL PROBLEM (future risk to plan for)?
  • Does this need to be broken into sub-concerns?
Prioritize using SUI Framework:
  • Seriousness: What's the impact if unresolved? (H/M/L)
  • Urgency: How time-sensitive? (H/M/L)
  • Impact/Trend: Is it growing worse? (H/M/L)
Quality Gate: Each concern must be assigned to exactly one KT process (PA, DA, or PPA) before proceeding.
适用于处理复杂或模糊、包含多个关注点的场景。
需从用户处收集的信息:
  1. 列出所有当前的关注点、威胁、机遇或问题（头脑风暴，无需筛选）
  2. 针对每个关注点：哪些迹象表明这是一个关注点？涉及哪些利害关系？
拆分并澄清每个关注点:
  • 这是否是一个问题（需要解释原因的偏差）？
  • 这是否是一个决策（需要做出的选择）？
  • 这是否是一个潜在问题（需要提前规划应对的未来风险）？
  • 是否需要将其拆分为子关注点？
使用SUI框架进行优先级排序:
  • 严重性（Seriousness）: 若未解决，影响如何？（高/中/低）
  • 紧迫性（Urgency）: 时间敏感度如何？（高/中/低）
  • 影响/趋势（Impact/Trend）: 情况是否在恶化？（高/中/低）
质量关卡: 在推进前，每个关注点必须被精准分配到KT的某一个流程（PA、DA或PPA）中。

Process 2: Problem Analysis

流程2：问题分析

Use when seeking the root cause of a deviation from expected performance.
Phase 2A: Deviation Statement
Collect from user:
  1. What OBJECT has the problem? (Be specific - not "the system" but "the hydraulic pump model H-450")
  2. What DEVIATION or defect does it have? (Observable symptom, not assumed cause)
Format: "[Object] is experiencing [Deviation]"
Quality Gate: Deviation statement must be:
  • Specific and observable
  • Describing a change from expected state
  • Free of assumed causes
  • Single object + single deviation (split if multiple)
Phase 2B: IS/IS NOT Specification Matrix
Build a 4-dimension specification comparing what IS observed vs. what IS NOT but COULD BE:
DimensionIS (Observed)IS NOT (Could be but isn't)Distinction
WHATWhat object/defect IS observed?What similar objects/defects are NOT affected?What's different or unique about the IS?
WHEREWhere IS the problem observed?Where COULD it occur but doesn't?What's distinct about the IS location?
WHENWhen IS it observed? (First, pattern, lifecycle)When COULD it occur but doesn't?What's distinct about the IS timing?
EXTENTHow many/much IS affected?How many/much COULD be but isn't?What's the boundary?
Critical Questions per Dimension:
  • WHAT: Which specific items? What type of defect exactly? What condition?
  • WHERE: Which location/position/stage? Geographically where? In which system/process?
  • WHEN: First noticed when? Pattern (constant, intermittent, cyclical)? In product lifecycle when?
  • EXTENT: How many units? What percentage? What magnitude? Trending?
Phase 2C: Distinction Analysis
For each IS/IS NOT pair, ask: "What is DIFFERENT, CHANGED, PECULIAR, or UNIQUE about the IS compared to the IS NOT?"
Record all distinctions - these are clues to the cause.
Phase 2D: Possible Cause Generation
For each distinction, ask: "What CHANGE in or related to this distinction could have caused the deviation?"
List all possible causes generated from distinctions.
Phase 2E: Cause Testing
Test each possible cause against EVERY specification:
Possible CauseExplains WHAT IS?Explains WHAT IS NOT?Explains WHERE IS?Explains WHERE IS NOT?...Score
Scoring: ✓ (explains), ? (partially/unknown), ✗ (doesn't explain)
Most Probable Cause = fewest ✗ marks, most ✓ marks
Phase 2F: Cause Verification
For the most probable cause(s):
  1. How can we verify this IS the cause?
  2. What test/observation would prove it?
  3. Can we replicate the problem by introducing this cause?
  4. Can we eliminate the problem by removing this cause?
适用于寻找偏离预期性能的根本原因。
阶段2A：偏差说明
需从用户处收集的信息:
  1. 出现问题的**对象（OBJECT）**是什么？（需具体，例如不说“系统”，而说“H-450型液压泵”）
  2. 存在何种**偏差（DEVIATION）**或缺陷？（可观察到的症状，而非假设的原因）
格式: "[对象] 出现了 [偏差]"
质量关卡: 偏差说明必须满足：
  • 具体且可观察
  • 描述与预期状态的变化
  • 不包含假设的原因
  • 单个对象+单个偏差（若有多个需拆分）
阶段2B：IS/IS NOT规格矩阵
构建一个包含4个维度的规格表，对比实际观察到的IS与可能发生但未发生的IS NOT：
维度IS（已观察到）IS NOT（可能发生但未发生）差异点
WHAT观察到哪些对象/缺陷？哪些类似对象/缺陷未受影响？IS项有何不同或独特之处？
WHERE问题出现在何处？可能出现问题但未出现的位置是哪里？IS位置有何独特之处？
WHEN问题何时被观察到？（首次出现时间、模式、生命周期阶段）可能出现问题但未出现的时间是何时？IS时间有何独特之处？
EXTENT受影响的数量/程度是多少？可能受影响但未受影响的数量/程度是多少？边界是什么？
各维度关键问题:
  • WHAT: 具体是哪些物品？确切是何种缺陷？处于何种状态？
  • WHERE: 哪个位置/环节/阶段？地理上的何处？哪个系统/流程中？
  • WHEN: 首次发现的时间？模式（持续、间歇、周期性）？产品生命周期的哪个阶段？
  • EXTENT: 受影响的单位数量？占比多少？严重程度？是否有恶化趋势？
阶段2C：差异点分析
针对每一组IS/IS NOT，提问：“与IS NOT相比，IS项在哪些方面存在差异、变化、特殊或独特之处？”
记录所有差异点——这些是找到原因的线索。
阶段2D：可能原因生成
针对每个差异点，提问：“该差异点的何种变化可能导致了偏差？”
列出所有从差异点推导出来的可能原因。
阶段2E：原因验证
针对每个可能的原因，对照所有规格进行验证：
可能原因是否解释WHAT IS？是否解释WHAT IS NOT？是否解释WHERE IS？是否解释WHERE IS NOT？...评分
评分标准：✓（可解释），?（部分解释/未知），✗（无法解释）
最可能原因 = ✗标记最少、✓标记最多的选项
阶段2F：原因确认
针对最可能的原因：
  1. 我们如何确认这就是原因？
  2. 何种测试/观察可以证明这一点？
  3. 引入该原因能否复现问题？
  4. 移除该原因能否消除问题？

Process 3: Decision Analysis

流程3：决策分析

Use when selecting between alternatives to achieve an objective.
Phase 3A: Decision Statement
Collect from user:
  1. What decision must be made?
  2. What is the desired outcome/objective?
Format: "Select [what] to achieve [outcome]"
Phase 3B: Objectives Classification
Collect from user:
  • What are all the criteria/objectives for this decision?
Classify each objective:
ObjectiveTypeWeight (if WANT)
Must meet safety regulationsMUSTN/A
Budget under $50,000MUSTN/A
Implementation timeWANT8
Ease of maintenanceWANT6
Vendor reputationWANT4
MUSTS = Mandatory, non-negotiable requirements. Pass/Fail only. WANTS = Desired outcomes. Weight 1-10 based on importance.
Phase 3C: Alternative Generation
List all possible alternatives/options. Eliminate any that fail ANY MUST criterion.
Phase 3D: Alternative Scoring
For each surviving alternative, score against each WANT (1-10 scale):
AlternativeWant 1 (×W)Want 2 (×W)Want 3 (×W)Total Weighted Score
Option A8 × 8 = 646 × 6 = 367 × 4 = 28128
Option B7 × 8 = 568 × 6 = 485 × 4 = 20124
Use: 
python scripts/calculate_scores.py
for automated scoring.
Phase 3E: Risk Assessment
For top 2-3 alternatives, identify adverse consequences:
  • What could go wrong with this choice?
  • How likely is this risk? (H/M/L)
  • How serious if it occurs? (H/M/L)
Phase 3F: Decision
Select alternative with best balance of weighted score and acceptable risk profile.
适用于在多个备选方案中选择以达成目标的场景。
阶段3A：决策说明
需从用户处收集的信息:
  1. 必须做出何种决策？
  2. 期望的结果/目标是什么？
格式: "选择 [对象] 以达成 [结果]"
阶段3B：目标分类
需从用户处收集的信息:
  • 该决策的所有标准/目标是什么？
对每个目标进行分类:
目标类型权重（若为WANT）
必须符合安全法规MUST不适用
预算低于50,000美元MUST不适用
实施时间WANT8
维护便捷性WANT6
供应商声誉WANT4
MUSTS = 强制性、不可协商的要求，仅通过/不通过。 WANTS = 期望的结果，根据重要性赋予1-10的权重。
阶段3C：备选方案生成
列出所有可能的备选方案/选项，排除任何未满足任一MUST标准的方案。
阶段3D：备选方案评分
针对每个留存的备选方案，对照每个WANT进行评分（1-10分制）：
备选方案需求1（×权重）需求2（×权重）需求3（×权重）加权总分
选项A8 × 8 = 646 × 6 = 367 × 4 = 28128
选项B7 × 8 = 568 × 6 = 485 × 4 = 20124
使用：
python scripts/calculate_scores.py
进行自动化评分。
阶段3E：风险评估
针对排名前2-3的备选方案，识别不利后果：
  • 选择该方案可能出现哪些问题？
  • 该风险发生的可能性有多大？（高/中/低）
  • 若发生，严重程度如何？（高/中/低）
阶段3F：决策
选择加权评分最优且风险可接受的备选方案。

Process 4: Potential Problem Analysis

流程4：潜在问题分析

Use when planning implementation to anticipate and mitigate risks.
Phase 4A: Plan Statement
Collect from user:
  1. What action/plan is being implemented?
  2. What are the critical steps/milestones?
Phase 4B: Potential Problem Identification
For each critical step:
  • What could go wrong?
  • What has gone wrong in similar situations before?
Phase 4C: Risk Evaluation
Potential ProblemLikelihood (H/M/L)Seriousness (H/M/L)Combined Risk
Vendor delays deliveryMHHIGH
Staff unavailableLMLOW
Combined Risk = Higher of the two ratings (conservative approach)
Phase 4D: Preventive Actions
For HIGH and MEDIUM risks:
  • What can be done to REDUCE the likelihood?
  • Assign responsibility and deadline
Phase 4E: Contingent Actions
For risks that cannot be fully prevented:
  • What will we do IF this problem occurs?
  • What is the trigger to activate contingency?
  • Who is responsible for monitoring the trigger?
适用于规划实施阶段，以预判并缓解风险。
阶段4A：计划说明
需从用户处收集的信息:
  1. 正在实施的行动/计划是什么？
  2. 关键步骤/里程碑有哪些？
阶段4B：潜在问题识别
针对每个关键步骤：
  • 可能出现哪些问题？
  • 类似场景中曾出现过哪些问题？
阶段4C：风险评估
潜在问题可能性（高/中/低）严重性（高/中/低）综合风险
供应商延迟交付中高高
人员不可用低中低
综合风险 = 取两个评级中的较高值（保守评估方式）
阶段4D：预防措施
针对高风险和中风险：
  • 可采取何种措施降低发生可能性？
  • 分配责任人与截止日期
阶段4E：应急措施
针对无法完全预防的风险：
  • 若该问题发生，我们将采取何种行动？
  • 触发应急预案的条件是什么？
  • 谁负责监控触发条件？

Quality Scoring

质量评分

Each analysis is scored on six dimensions (see references/quality-rubric.md):
DimensionWeightDescription
Problem Specification20%IS/IS NOT completeness and precision
Distinction Quality20%Meaningful, change-oriented distinctions
Cause-Specification Fit20%Cause explains all IS and IS NOT data
Decision Criteria Rigor15%Clear MUSTS/WANTS separation and weighting
Risk Analysis Depth15%Comprehensive PPA with actionable contingencies
Documentation Quality10%Clear, traceable, auditable record
Score Interpretation: ≥85 Excellent | 70-84 Acceptable | <70 Needs Revision
Generate score: 
python scripts/score_analysis.py
每项分析从六个维度进行评分（详见references/quality-rubric.md）：
维度权重描述
问题规格说明20%IS/IS NOT的完整性与精准度
差异点质量20%有意义、面向变化的差异点
原因与规格匹配度20%原因能否解释所有IS与IS NOT数据
决策标准严谨性15%MUSTS/WANTS的清晰区分与权重分配
风险分析深度15%全面的PPA与可执行的应急预案
文档质量10%清晰、可追溯、可审计的记录
评分解读: ≥85 优秀 | 70-84 合格 | <70 需要修订
生成评分：
python scripts/score_analysis.py

Reference Materials

参考资料

  • IS/IS NOT Guidance: references/is-is-not-guide.md - Detailed matrix construction
  • Decision Analysis Guide: references/decision-analysis-guide.md - MUSTS/WANTS criteria
  • Common Pitfalls: references/common-pitfalls.md - Mistakes and remediation
  • Quality Rubric: references/quality-rubric.md - Detailed scoring criteria
  • Worked Examples: references/examples.md - Complete KT analyses
  • IS/IS NOT指南: references/is-is-not-guide.md - 规格矩阵构建详解
  • 决策分析指南: references/decision-analysis-guide.md - MUSTS/WANTS标准说明
  • 常见误区: references/common-pitfalls.md - 错误案例与补救方法
  • 质量评估标准: references/quality-rubric.md - 详细评分标准
  • 实战案例: references/examples.md - 完整KT分析示例

Scripts

脚本工具

  • scripts/calculate_scores.py
    - Decision Analysis weighted scoring
  • scripts/generate_report.py
    - Professional HTML/PDF report generation
  • scripts/score_analysis.py
    - Quality assessment scoring
  • scripts/calculate_scores.py
    - 决策分析加权评分工具
  • scripts/generate_report.py
    - 专业HTML/PDF报告生成工具
  • scripts/score_analysis.py
    - 质量评估评分工具

Integration with RCCA Toolkit

与RCCA工具包的集成

KT integrates with other analysis tools:
  • Problem Definition → KT PA: Use 5W2H to gather initial facts, then build IS/IS NOT specification
  • KT PA → 5 Whys: After identifying most probable cause, use 5 Whys to drill deeper if needed
  • Fishbone → KT PA: Brainstorm potential causes with Fishbone, then test against KT specification
  • KT DA → FTA: After selecting alternative, use FTA to analyze failure modes of the chosen solution
  • KT PPA → FMEA: Expand PPA risks into full FMEA for critical implementations
KT可与其他分析工具集成：
  • 问题定义 → KT PA: 使用5W2H收集初始事实，再构建IS/IS NOT规格说明
  • KT PA → 5 Whys: 识别最可能的原因后，若需要可使用5 Whys进一步深挖
  • 鱼骨图 → KT PA: 使用鱼骨图头脑风暴潜在原因，再对照KT规格说明进行验证
  • KT DA → FTA: 选择备选方案后，使用FTA分析所选方案的失效模式
  • KT PPA → FMEA: 将PPA风险扩展为完整的FMEA，用于关键实施项目