Sync: add design and process improvement notes
This commit is contained in:
@@ -1,69 +1,59 @@
|
||||
---
|
||||
title: "Change Management"
|
||||
title: "Change-Management"
|
||||
type: concept
|
||||
tags: [itsm, devops, operations]
|
||||
date: 2025-03-01
|
||||
tags: [Organizational-Change, Process-Improvement, ITSM]
|
||||
sources: [testing-workflow-optimizer, understanding-complete-itsm]
|
||||
last_updated: 2026-04-21
|
||||
---
|
||||
|
||||
## Definition
|
||||
# Change-Management
|
||||
|
||||
变更管理(Change Management)是[[ITSM]]的核心流程之一,通过**结构化的方法评估、审批和实施IT变更**,在保持服务稳定性的同时实现业务所需的灵活性。
|
||||
变更管理——在组织中系统性地规划、实施和控制人员、流程和技术变更的管理学科。核心目标是降低变更风险、提高采纳率、确保变革产生预期业务价值,同时最小化对现有服务运营的干扰。
|
||||
|
||||
## Change Management Process
|
||||
## Aliases
|
||||
- 变革管理
|
||||
- 组织变革管理
|
||||
- IT Change Management(ITSM 语境)
|
||||
|
||||
```
|
||||
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
|
||||
│ Change │ → │ Impact │ → │ CAB │
|
||||
│ Request │ │ Assessment │ │ Approval │
|
||||
└──────────────┘ └──────────────┘ └──────────────┘
|
||||
↓
|
||||
┌──────────────┐ ┌──────────────┐ ┌──────────────┘
|
||||
│ Build & │ ← │ Change │ ← │ Schedule │
|
||||
│ Test │ │ Build │ │ & Prepare │
|
||||
└──────────────┘ └──────────────┘ └──────────────┘
|
||||
```
|
||||
## Core Frameworks
|
||||
|
||||
## Change Types
|
||||
### Kotter's 8-Step Change Model
|
||||
1. **Create Urgency**(创造紧迫感)——让利益相关者认识到变革必要性
|
||||
2. **Build Guiding Coalition**(组建指导联盟)——建立变革领导团队
|
||||
3. **Form Strategic Vision**(形成战略愿景)——清晰描述变革后的未来状态
|
||||
4. **Enlist a Volunteer Army**(动员志愿者)——让尽可能多的人参与
|
||||
5. **Enable Action by Removing Barriers**(消除障碍)——移除阻碍变革的结构性和文化性壁垒
|
||||
6. **Generate Short-Term Wins**(创造短期胜利)——通过快速成果建立信心
|
||||
7. **Sustain Acceleration**(持续加速)——保持势头,不给反对派喘息空间
|
||||
8. **Institute Change**(固化变革)——将变革融入组织文化
|
||||
|
||||
| 类型 | 描述 | 审批级别 |
|
||||
|------|------|---------|
|
||||
| Emergency | 紧急变更(如P1事故响应) | 快速审批 |
|
||||
| Standard | 标准变更(例行维护) | 自动审批 |
|
||||
| Normal | 常规变更(新功能部署) | CAB审批 |
|
||||
### ADKAR Model(Prosci)
|
||||
- **A**wareness(认知)——了解为什么需要变革
|
||||
- **D**esire(渴望)——愿意参与和支持变革
|
||||
- **K**nowledge(知识)——知道如何变革
|
||||
- **A**bility(能力)——能够实施新行为
|
||||
- **R**einforcement(强化)——巩固变革成果
|
||||
|
||||
## Modern Change Management (ITSM 2.0)
|
||||
## In ITSM Context(ITIL Change Management)
|
||||
在 ITSM 框架中,变更管理分为:
|
||||
- **标准变更(Standard Change)**:预批准的低风险例行变更
|
||||
- **正常变更(Normal Change)**:需经 CAB(变更顾问委员会)评估和批准
|
||||
- **紧急变更(Emergency Change)**:突发事件驱动的快速变更,事后评估
|
||||
|
||||
在[[ITSM 2.0]]中,变更管理由AI和[[IaC]]驱动:
|
||||
## In Workflow Optimization
|
||||
[[testing-workflow-optimizer]] 在实施流程优化时必须考虑变更管理:
|
||||
- **测量基线**前先建立利益相关者共识
|
||||
- **设计优化方案**需要获得关键干系人认同
|
||||
- **实施规划**必须包含培训和沟通计划
|
||||
- **自动化落地**需要克服员工的恐惧和阻力
|
||||
|
||||
### AI-Driven Risk Assessment
|
||||
- **Automated Impact Analysis** — 自动评估变更影响
|
||||
- **Failure Probability Prediction** — AI预测变更失败概率
|
||||
- **Rollback Planning** — 自动生成回滚计划
|
||||
## Common Pitfalls
|
||||
- **变革疲劳(Change Fatigue)**:频繁变更导致员工抵触
|
||||
- **忽略人因素**:只关注流程和技术,忽视人的情感
|
||||
- **缺乏可见成果**:没有短期胜利导致失去支持
|
||||
- **变革太快或太慢**:节奏失控
|
||||
|
||||
### CI/CD Pipeline Governance
|
||||
```
|
||||
Code Commit → Automated Testing → IaC Validation → Risk Score → Approval
|
||||
↓ ↓ ↓ ↓ ↓
|
||||
Git hooks Unit/Int Tests Terraform Plan ML Model Auto/CAB
|
||||
```
|
||||
|
||||
## Key Metrics
|
||||
|
||||
| 指标 | 描述 |
|
||||
|------|------|
|
||||
| Change Success Rate | 变更成功率 |
|
||||
| Failed Change Rate | 失败变更率 |
|
||||
| Rollback Rate | 回滚率 |
|
||||
| Emergency Change Ratio | 紧急变更比例 |
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[ITSM]] — 父框架
|
||||
- [[Change-Failure-Rate]] — 变更失败率
|
||||
- [[IaC]] — 基础设施即代码
|
||||
- [[CI/CD-Pipeline]] — CI/CD流水线
|
||||
- [[Rollback]] — 回滚机制
|
||||
|
||||
## Sources
|
||||
|
||||
- [[understanding-complete-itsm]] — AI-driven Change Management
|
||||
## Connections
|
||||
- [[testing-workflow-optimizer]] — 流程优化落地的必要保障机制
|
||||
- [[ITSM]] — ITSM 框架中的三大核心流程之一
|
||||
- [[Kaizen]] — 持续改进需要有效的变更管理支撑
|
||||
|
||||
46
wiki/concepts/Design-Thinking.md
Normal file
46
wiki/concepts/Design-Thinking.md
Normal file
@@ -0,0 +1,46 @@
|
||||
---
|
||||
title: "Design-Thinking"
|
||||
type: concept
|
||||
tags: [UX, Human-Centered, Innovation, Process-Improvement]
|
||||
sources: [testing-workflow-optimizer, Human-Centered-Design]
|
||||
last_updated: 2026-04-21
|
||||
---
|
||||
|
||||
# Design-Thinking
|
||||
|
||||
设计思维——一种以人为中心的创新方法论,通过共情(Empathize)、定义(Define)、构思(Ideate)、原型(Prototype)和测试(Test)五个阶段的迭代循环,解决复杂问题并创造有意义的解决方案。
|
||||
|
||||
## Aliases
|
||||
- 设计思维
|
||||
- Design Thinking Process
|
||||
- 以人为本的创新方法
|
||||
|
||||
## Five Stages
|
||||
|
||||
1. **Empathize(共情)**——深入理解用户的需求、感受、动机和行为。通过观察、访谈和沉浸式体验获取洞察。
|
||||
2. **Define(定义)**——综合共情阶段的洞察,明确要解决的核心问题(Point of View / How Might We)。
|
||||
3. **Ideate(构思)**——头脑风暴,生成大量创意和可能的解决方案,不评判,鼓励疯狂的点子。
|
||||
4. **Prototype(原型)**——用低成本、快速的方式制作解决方案的物理或数字原型。
|
||||
5. **Test(测试)**——用真实用户验证原型,收集反馈,迭代改进。
|
||||
|
||||
## Core Principles
|
||||
- **以人为中心**:始终从人的真实需求出发,而非从技术可能出发
|
||||
- **迭代而非线性**:允许反复回到前面的阶段
|
||||
- **跨职能协作**:打破 silos,融合不同背景的视角
|
||||
- **快速失败、快速学习**:通过小规模实验快速获取认知
|
||||
|
||||
## Connection to Human-Centered-Design
|
||||
Design Thinking 是 [[Human-Centered-Design]] 的系统性方法论框架——HCD 提供哲学和价值观,Design Thinking 提供可操作的流程。
|
||||
|
||||
## Connection to Workflow Optimization
|
||||
[[testing-workflow-optimizer]] 将 Design Thinking 应用于流程改进:
|
||||
- **Empathize** → 理解员工(流程执行者)的真实痛点
|
||||
- **Define** → 明确效率瓶颈和优化目标
|
||||
- **Ideate** → 构思多种可能的优化方案
|
||||
- **Prototype** → 小规模试点验证优化方案
|
||||
- **Test** → 收集反馈,迭代改进
|
||||
|
||||
## Connections
|
||||
- [[Human-Centered-Design]] — 哲学基础
|
||||
- [[Lean]] — 互补:Design Thinking 侧重创新发现,Lean 侧重效率优化
|
||||
- [[testing-workflow-optimizer]] — 应用于流程改进的方法论工具
|
||||
60
wiki/concepts/Human-Centered-Design.md
Normal file
60
wiki/concepts/Human-Centered-Design.md
Normal file
@@ -0,0 +1,60 @@
|
||||
---
|
||||
title: "Human-Centered-Design"
|
||||
type: concept
|
||||
tags: [UX, Process-Design, Employee-Experience, Design-Thinking]
|
||||
sources: [testing-workflow-optimizer]
|
||||
last_updated: 2026-04-21
|
||||
---
|
||||
|
||||
# Human-Centered-Design
|
||||
|
||||
人本设计——一种以最终用户和员工为核心的设计哲学,在设计产品、服务、流程和系统时,优先考虑人类的需求、能力、限制和情感,而非仅关注技术可行性或效率指标。
|
||||
|
||||
## Aliases
|
||||
- HCD
|
||||
- 以人为本的设计
|
||||
- 人本设计
|
||||
|
||||
## Core Principles
|
||||
1. **User Needs First**(用户需求优先)——在技术或流程约束之前,首先理解和满足人的需求
|
||||
2. **Empathy**(同理心)——深入理解用户的真实感受、痛点和心智模型
|
||||
3. **Iterative Design**(迭代设计)——通过快速原型→测试→改进的循环持续优化
|
||||
4. **Inclusion & Accessibility**(包容性与可访问性)——确保设计服务于所有用户,包括残障人士和边缘群体
|
||||
5. **Cognitive Load Management**(认知负荷管理)——减少用户在完成任务时的思考和记忆负担
|
||||
|
||||
## In Workflow/Process Design
|
||||
在流程和工作流设计中,人本设计意味着:
|
||||
- **员工满意度优先于单纯效率**:好的流程设计不仅高效,还让执行者感到有价值和满足
|
||||
- **减少认知负荷**:将复杂的决策规则可视化,提供清晰的指引
|
||||
- **保留人类判断空间**:在自动化无法处理的灰色地带保留人工决策节点
|
||||
- **可访问性**:确保流程对所有能力水平的员工都可用
|
||||
|
||||
## Connection to Workflow Optimization
|
||||
[[testing-workflow-optimizer]] 将人本设计作为核心约束:
|
||||
> "Prioritize user experience and employee satisfaction in process design"
|
||||
> "Consider change management and adoption challenges in all recommendations"
|
||||
> "Balance automation efficiency with human judgment and creativity"
|
||||
|
||||
这意味着:
|
||||
- 自动化不应完全消除人的参与感
|
||||
- 流程设计应减少而非增加员工认知压力
|
||||
- 变革建议需要考虑员工的接受度和适应成本
|
||||
|
||||
## Design Thinking Process
|
||||
1. **Empathize**(共情)——观察、访谈,理解用户
|
||||
2. **Define**(定义)——综合洞察,定义核心问题
|
||||
3. **Ideate**(构思)——头脑风暴,生成大量创意
|
||||
4. **Prototype**(原型)——快速低成本制作解决方案原型
|
||||
5. **Test**(测试)——用真实用户验证原型
|
||||
|
||||
## Connection to Lean/Six-Sigma
|
||||
人本设计补充了 [[Lean]] 和 [[Six-Sigma]] 的量化视角:
|
||||
- Lean/Six-Sigma 提供数据驱动的优化框架
|
||||
- Human-Centered-Design 提供人本视角的优化方向
|
||||
- 两者结合:优化的指标必须与人的真实需求对齐
|
||||
|
||||
## Connections
|
||||
- [[testing-workflow-optimizer]] — 流程优化中的人本设计约束
|
||||
- [[Cognitive-Load-Reduction]] — 人本设计的核心子维度
|
||||
- [[Lean]] — 互补:量化优化 + 人本方向
|
||||
- [[Design-Thinking]] — 人本设计的系统性方法论框架
|
||||
55
wiki/concepts/Kaizen.md
Normal file
55
wiki/concepts/Kaizen.md
Normal file
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: "Kaizen"
|
||||
type: concept
|
||||
tags: [Continuous-Improvement, Lean, Process-Improvement]
|
||||
sources: [testing-workflow-optimizer, devops-culture-and-transformation-fostering-collaboration-agile-practices-and-innovation-linkedin, AgilePractices]
|
||||
last_updated: 2026-04-21
|
||||
---
|
||||
|
||||
# Kaizen
|
||||
|
||||
改善(Kaizen)——日语"継続的改善"(持续改进)的音译,是一种以员工为核心、小步快跑、渐进式的持续改进哲学。核心理念:所有流程都有改进空间,每次改进即使微小,累积效果也十分显著。
|
||||
|
||||
## Aliases
|
||||
- 改善
|
||||
- 持续改进(Continuous Improvement)
|
||||
- 渐进式改进
|
||||
|
||||
## Origin
|
||||
源自丰田生产系统(TPS),由日本管理大师今井正明(Masaaki Imai)在 1986 年《Kaizen》一书中向西方推广。
|
||||
|
||||
## Core Principles
|
||||
1. **Process Focus**(过程导向)——好的结果来自好的过程,聚焦过程改进而非单纯追求结果
|
||||
2. **Everyone Involved**(全员参与)——从 CEO 到一线员工,每个人都是改进的推动者
|
||||
3. **Small Improvements**(小步改进)——大幅改进往往由无数小改进累积而成
|
||||
4. **Discipline**(纪律性)——坚持不懈,持续执行
|
||||
5. **Eliminate Waste**(消除浪费)——持续识别和消除 Mudas(浪费)
|
||||
|
||||
## Key Practices
|
||||
- **改善活动(Kaizen Event)**:短周期(1-5天)跨职能团队聚焦单一流程的密集改进
|
||||
- **PDCA Cycle**(戴明环):
|
||||
- **Plan**:计划改进
|
||||
- **Do**:执行改进
|
||||
- **Check**:检查结果
|
||||
- **Act**:标准化或重新改进
|
||||
- **5S**:整理(Sort)/整顿(Set in Order)/清扫(Shine)/清洁(Standardize)/素养(Sustain)
|
||||
- **无责归因(No-Blame Culture)**——改进系统而非惩罚个人
|
||||
- **Gemba Walk**(现场走动)——管理者到实际工作现场观察和改进
|
||||
|
||||
## Kaizen vs Six-Sigma
|
||||
| 维度 | Kaizen | Six-Sigma |
|
||||
|------|--------|-----------|
|
||||
| 节奏 | 渐进式,持续小改 | 阶段性,DMAIC 大改 |
|
||||
| 方法 | 定性为主,全员参与 | 定量为主,专家主导 |
|
||||
| 目标 | 消除浪费,流动改善 | 减少变异,接近目标值 |
|
||||
| 适用场景 | 文化变革,持续改进 | 复杂问题,系统优化 |
|
||||
|
||||
两者互补:Kaizen 营造持续改进文化,Six-Sigma 解决深层复杂问题。
|
||||
|
||||
## In DevOps Context
|
||||
DevOps 文化的四大支柱之一:Continuous Improvement (Kaizen)。实现方式:无责复盘(blameless post-mortems)、metrics驱动的瓶颈识别、混沌工程。
|
||||
|
||||
## Connections
|
||||
- [[Lean]] — 共享消除浪费的核心价值观
|
||||
- [[Six-Sigma]] — 互补:渐进 vs 阶段
|
||||
- [[DevOpsCulture]] — DevOps 文化四大支柱之一
|
||||
51
wiki/concepts/Lean.md
Normal file
51
wiki/concepts/Lean.md
Normal file
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: "Lean"
|
||||
type: concept
|
||||
tags: [Process-Improvement, Six-Sigma, Workflow-Optimization]
|
||||
sources: [testing-workflow-optimizer]
|
||||
last_updated: 2026-04-21
|
||||
---
|
||||
|
||||
# Lean
|
||||
|
||||
精益制造/精益管理方法论,源于丰田生产系统(TPS),核心目标是通过消除一切形式的浪费(Muda),最大化客户价值。
|
||||
|
||||
## Aliases
|
||||
- Lean Manufacturing
|
||||
- 精益生产
|
||||
- 丰田生产系统(TPS)
|
||||
|
||||
## Definition
|
||||
Lean 通过识别和消除非增值活动(NVA),将价值流中的等待时间、搬运浪费、过度加工、库存过剩、不必要的移动、缺陷返工和过度生产降至最低。
|
||||
|
||||
## Key Principles
|
||||
1. **价值(Value)**:从客户视角定义——客户愿意付费的转化活动
|
||||
2. **价值流(Value Stream)**:识别从原材料到交付的所有步骤,区分增值(VA)/价值赋能(VEA)/浪费(NVA)
|
||||
3. **流动(Flow)**:使增值步骤持续、不中断地运行
|
||||
4. **拉动(Pull)**:按客户实际需求而非预测来生产
|
||||
5. **完美(Perfection)**:持续追求零浪费状态
|
||||
|
||||
## Three Types of Activities
|
||||
| 类别 | 说明 | 示例 |
|
||||
|------|------|------|
|
||||
| 增值活动(VA) | 客户愿意付费的转化 | 加工零件、填写表格 |
|
||||
| 价值赋能活动(VEA) | 不直接增值但必需的支撑活动 | 质量检查、设备维护 |
|
||||
| 浪费(NVA/Muda) | 消耗资源但不创造客户价值的活动 | 等待、搬运、返工 |
|
||||
|
||||
## Seven Types of Waste (TIMWOODS)
|
||||
- **T**ransport(搬运)
|
||||
- **I**nventory(库存)
|
||||
- **M**otion(动作)
|
||||
- **W**aiting(等待)
|
||||
- **O**verproduction(过量生产)
|
||||
- **O**ver-processing(过度加工)
|
||||
- **S**kills underutilization(技能浪费)
|
||||
- **D**efects(缺陷/返工)
|
||||
|
||||
## Connection to Six-Sigma
|
||||
Lean 关注速度(消除浪费),Six-Sigma 关注质量(减少变异)。两者的融合称为 **Lean Six-Sigma**,同时优化速度和精度。
|
||||
|
||||
## Connections
|
||||
- [[Six-Sigma]] — 融合伙伴,速度+质量双优化
|
||||
- [[Kaizen]] — 互补:Kaizen 小步快跑,Lean 系统重构
|
||||
- [[Value-Stream-Mapping]] — 识别浪费的可视化工具
|
||||
61
wiki/concepts/Six-Sigma.md
Normal file
61
wiki/concepts/Six-Sigma.md
Normal file
@@ -0,0 +1,61 @@
|
||||
---
|
||||
title: "Six-Sigma"
|
||||
type: concept
|
||||
tags: [Process-Improvement, Statistical-Quality-Control, Lean]
|
||||
sources: [testing-workflow-optimizer]
|
||||
last_updated: 2026-04-21
|
||||
---
|
||||
|
||||
# Six-Sigma
|
||||
|
||||
六西格玛方法论,由摩托罗拉在 1986 年创立,通过统计分析减少流程变异和缺陷,目标将每百万机会的缺陷数(DPMO)降低至 3.4 以下(即六西格玛水平)。
|
||||
|
||||
## Aliases
|
||||
- Six Sigma
|
||||
- 6σ
|
||||
|
||||
## Core Goal
|
||||
**3.4 DPMO**(Defects Per Million Opportunities)——在考虑 1.5σ 漂移的情况下,六西格玛水平对应 99.99966% 的无缺陷率。
|
||||
|
||||
## Two Core Methodologies
|
||||
|
||||
### DMAIC(用于改进现有流程)
|
||||
1. **Define**(定义)——识别问题,确定项目范围和目标
|
||||
2. **Measure**(测量)——收集当前状态数据,建立基准
|
||||
3. **Analyze**(分析)——识别变异根本原因
|
||||
4. **Improve**(改进)——设计并实施解决方案
|
||||
5. **Control**(控制)——建立控制机制维持改进成果
|
||||
|
||||
### DMADV / DFSS(用于设计新流程)
|
||||
1. **Define**(定义)——识别需求和项目目标
|
||||
2. **Measure**(测量)——测量 CTQ(关键质量特性)和风险
|
||||
3. **Analyze**(分析)——设计方案评估
|
||||
4. **Design**(设计)——详细设计
|
||||
5. **Verify**(验证)——验证设计满足需求
|
||||
|
||||
## Belt System(人员资格体系)
|
||||
| 等级 | 职责 |
|
||||
|------|------|
|
||||
| White Belt | 基础概念理解,参与改进项目 |
|
||||
| Yellow Belt | 团队成员,理解 DMAIC,能使用基本工具 |
|
||||
| Green Belt | 项目领导者,60%+ 时间投入改进项目,精通统计分析 |
|
||||
| Black Belt | 专家领导者,100% 投入,精通高级统计分析,培训 Green Belt |
|
||||
| Master Black Belt | 战略级,培训和指导 Black Belt,组织方法论推广 |
|
||||
|
||||
## Key Metrics
|
||||
- **DPMO**(Defects Per Million Opportunities):每百万机会中的缺陷数
|
||||
- **Sigma Level**:流程能力等级(1σ ≈ 690,000 DPMO → 6σ ≈ 3.4 DPMO)
|
||||
- **Process Capability (Cp/Cpk)**:衡量流程满足规格的能力
|
||||
- **Cost of Poor Quality (COPQ)**:质量不良成本
|
||||
|
||||
## Connection to Lean
|
||||
- Lean 关注消除浪费(速度),Six-Sigma 关注减少变异(质量)
|
||||
- **Lean Six-Sigma**:两者融合,同时优化速度和精度,是 [[testing-workflow-optimizer]] 的核心方法论之一
|
||||
|
||||
## Relationship to Statistical-Process-Control
|
||||
Six-Sigma 的 Analyze 和 Control 阶段大量依赖统计过程控制(SPC)工具(控制图、过程能力分析、假设检验)
|
||||
|
||||
## Connections
|
||||
- [[Lean]] — 融合伙伴,速度+质量双优化
|
||||
- [[Statistical-Process-Control]] — Six-Sigma 的统计分析基础
|
||||
- [[Kaizen]] — 互补:DMAIC 系统性改进 + Kaizen 渐进式持续改进
|
||||
58
wiki/concepts/Statistical-Process-Control.md
Normal file
58
wiki/concepts/Statistical-Process-Control.md
Normal file
@@ -0,0 +1,58 @@
|
||||
---
|
||||
title: "Statistical-Process-Control"
|
||||
type: concept
|
||||
tags: [Six-Sigma, Quality-Control, Data-Driven-Decision]
|
||||
sources: [testing-workflow-optimizer]
|
||||
last_updated: 2026-04-21
|
||||
---
|
||||
|
||||
# Statistical-Process-Control
|
||||
|
||||
统计过程控制(SPC)——使用统计方法(主要是控制图)监控过程稳定性,区分常见原因变异和特殊原因变异,使过程可控、可预测,并支持基于数据的持续改进决策。
|
||||
|
||||
## Aliases
|
||||
- SPC
|
||||
- 统计过程控制
|
||||
- Statistical Quality Control (SQC)
|
||||
|
||||
## Core Concept: Variation
|
||||
所有过程都存在变异,SPC 的核心是区分两类变异来源:
|
||||
|
||||
| 变异类型 | 英文 | 来源 | 特征 | 处置 |
|
||||
|----------|------|------|------|------|
|
||||
| 常见原因变异 | Common Cause | 过程内在的正常随机波动 | 稳定、可预测 | 通过过程改进系统性减少 |
|
||||
| 特殊原因变异 | Special Cause | 特定外部因素导致 | 不稳定、不可预测 | 识别并消除根本原因 |
|
||||
|
||||
**Gerald M. Weinberg 第一定律**:即使是最简单的系统,只要测量足够精确,就能观察到随机涨落;因此,变异永远存在,区分其来源是关键。
|
||||
|
||||
## Control Charts(控制图)
|
||||
SPC 的核心工具,通过建立控制上限(UCL)和控制下限(LCL),监控过程是否处于统计控制状态。
|
||||
|
||||
### Common Types
|
||||
- **X̄-R Chart**(均值-极差图):监控连续数据的均值和变异
|
||||
- **X̄-S Chart**(均值-标准差图):大样本(n>10)场景
|
||||
- **p Chart**(比率图):监控不合格率等比例数据
|
||||
- **c Chart**(计数图):监控缺陷数
|
||||
|
||||
### Interpretation Rules(Western Electric Rules)
|
||||
- 1 点超出 UCL/LCL → 特殊原因,可能失控
|
||||
- 连续 9 点在中心线同一侧 → 过程漂移
|
||||
- 连续 6 点递增或递减 → 趋势
|
||||
- 连续 14 点交替上下 → 系统性周期变异
|
||||
|
||||
## SPC in Six-Sigma
|
||||
SPC 是 [[Six-Sigma]] DMAIC 中 Analyze 和 Control 阶段的核心工具:
|
||||
- **Measure**:建立过程基线和控制图
|
||||
- **Analyze**:识别特殊原因变异
|
||||
- **Control**:维持改进后的稳定过程
|
||||
|
||||
## In Workflow Optimization
|
||||
[[testing-workflow-optimizer]] 将 SPC 整合到四阶段工作流:
|
||||
- **现状分析**:使用控制图建立基线性能
|
||||
- **优化验证**:改进后通过 SPC 确认过程稳定性
|
||||
- **持续监控**:自动化监控异常信号
|
||||
|
||||
## Connections
|
||||
- [[Six-Sigma]] — SPC 是 Six-Sigma 的核心工具
|
||||
- [[Lean]] — SPC 支撑 Lean 的数据驱动决策
|
||||
- [[Kaizen]] — SPC 发现的问题通过 Kaizen 活动改进
|
||||
52
wiki/concepts/Value-Stream-Mapping.md
Normal file
52
wiki/concepts/Value-Stream-Mapping.md
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "Value-Stream-Mapping"
|
||||
type: concept
|
||||
tags: [Lean, Process-Improvement, Workflow-Optimization]
|
||||
sources: [testing-workflow-optimizer, AgilePractices, devops-culture-and-transformation-fostering-collaboration-agile-practices-and-innovation-linkedin]
|
||||
last_updated: 2026-04-21
|
||||
---
|
||||
|
||||
# Value-Stream-Mapping
|
||||
|
||||
价值流映射(VSM)——一种精益可视化工具,用于绘制和分析产品或服务从原材料到交付客户的全流程中的所有步骤,区分增值时间与非增值等待时间,从而识别改进机会。
|
||||
|
||||
## Aliases
|
||||
- VSM
|
||||
- Value Stream Map
|
||||
- 价值流图
|
||||
|
||||
## Purpose
|
||||
将流程中的每个步骤按两大类时间进行量化:
|
||||
- **增值时间(Value-Adding Time, VA Time)**:客户愿意付费的实际转化时间
|
||||
- **非增值时间(Non-Value-Adding Time, NVA Time)**:等待、移动、搬运、检查等不创造客户价值的时间
|
||||
|
||||
## Standard VSM Symbols
|
||||
| 符号 | 含义 |
|
||||
|------|------|
|
||||
| 矩形(Process Box) | 工序/步骤 |
|
||||
| 三角形(Triangle Inventory) | 库存/在制品 |
|
||||
| 推(Push Arrow) | 推式生产信号 |
|
||||
| 客户/供应商框 | 流程的输入和输出 |
|
||||
| 看板(Kaizen Burst) | 改进机会点 |
|
||||
| 看板(Kaizen Event) | 改善活动标识 |
|
||||
|
||||
## Time Line(时间线)
|
||||
VSM 底部时间线计算:
|
||||
- **总生产时间(Total Lead Time, L/T)**:从开始到完成的日历时间
|
||||
- **增值时间(Value-Added Time, VA)**:实际加工时间
|
||||
- **增值比(VA Ratio)**:VA / L/T × 100%,典型值 5-10%,说明大量时间在等待
|
||||
|
||||
## In DevOps Context
|
||||
价值流映射用于 DevOps 工作流优化:
|
||||
- **运营价值流(OVS, Operational Value Stream)**:面向客户的持续交付
|
||||
- **开发价值流(DVS, Development Value Stream)**:内部产品开发过程
|
||||
|
||||
典型 DevOps VSM 分析结果:发现问题等待时间占 90%+,实际编码/构建/测试仅占 10%
|
||||
|
||||
## Connection to Lean
|
||||
价值流映射是 [[Lean]] 的核心工具,用于识别 TIMWOODS 七类浪费的具体位置。
|
||||
|
||||
## Connections
|
||||
- [[Lean]] — 核心分析工具
|
||||
- [[AgilePractices]] — Agile/DevOps 流程优化的核心工具
|
||||
- [[Kaizen]] — VSM 发现的问题通过 Kaizen 活动改进
|
||||
Reference in New Issue
Block a user