Software project management and quality control - A quality management framework based on statistic process control - This framework transform social process into engineering process to leverage existing engineering process control tool and technique - There are more than for ERP project backlog sample attached.

1. Project management –
軟體專案品質管理
Jesse
2010-7-14
Version 3.0

2. Agenda
 軟體品質工程
 軟體品質的衡量與案例
 品質銷售策略
 方法論框架
 專案案例分析-基礎
 專案案例分析-進階
 Q&A
 附錄: 軟體合同形式

3. 軟體品質的問題
 品質是檢驗出來的?
 品質是做出來的?
 品質是客戶調查出來的?
 品質是規劃出來的?
 品質是制度問題?
 品質是文化問題?
 品質是產業問題?

4. 服務品質工程
服務品質工
程
專案規劃
方法論設計
系統設計
架構與任務
設計
差異分析與
設計
專案執行
品質管制
量測與處理 預測與修正 診斷與調整
專案範圍
•時程與架構
系統範圍
•模組與資源
業務流程管制
•需求/方案
專案過程管制
•階段目標
•過程統計
成本管
制
品質損失
函數

5. 品質成本分析
Action
解決
方法
差異
類型
成本
因子
成本
類型
服務品質成
本
預防成本
培圳 工程差異 團隊規劃
新人
TECH/MFG
售前規劃 計劃差異
Solution
Review
Solution
Mgr
自有客戶
偵測成本
方案檢查
流程管制
內部失效成
本
作業成本
200: 實際差異
Project
review
標準化方法
PPR
專案分享
外部失效成
本
200
完工差異
客戶因素
失去機會 其他問題 其他差異

6. 品質管理的成長階段
操作式品管
•顧問個別發揮
•個人員確保元件整合及
訂定合理公差的觀念
領班式品管
•實施方法+顧問同步
•PM = 協調顧問
•20世紀初葉，工業制
度採分工制度,工作標
準
檢驗式品管
•注重產業方案設計
•PM=方案經理
•裝配線生產, 不需技術
的人員操作, 設立專任
的檢驗員
統計式品管
•專案PDCA+統計分析
•PM = 專案領導
•1924, 休哈特, 製程品
質的變異程度控制, 驗
收抽樣制度
全面式品管
•專案PDCA+BPI
•PM = Change mgmt
•1960, 品管圈, 品質第
一、消費者導向、下工
程也是顧客
* 參考費根堡博士

7. 小結
 應用軟體專案是 Adaptive模式, 所以軟
體品質是
◦ 產業問題, 需明確制度與技術的產權邊界
◦ 制度問題,需提早交付驗證
◦ 要測試才能檢驗
◦ 需逐步實踐
◦ 需客戶反饋
 不是Predictive/Formal/Waterfall 模式

8. Agenda
 軟體品質工程
 軟體品質的衡量與案例
 品質銷售策略
 方法論框架
 專案案例分析-基礎
 專案案例分析-進階
 Q&A
 附錄: 軟體合同形式

9. ERP 專案目標
 案例:
◦ 縮短結帳平均時間:
 10天  5天
◦ 縮短研發平均時間:
 70週  38週
 問題:
◦ 是專案目標或企業目
標?
◦ 何者比較好?
 結帳53 vs.101
 即(2~8) vs. (9~11)
ERP績效
項目
績效指標
生產力 員工生產力
周轉率 存貨周轉率
應收帳款周轉率
投資報酬率
決策 改進決策品質
縮短決策時間
信息 資訊即時性
資訊正確
各部門資訊分享
員工滿意度 員工滿意度
* Benchmarking Partner

10. 處理效率:
過程管制
案例: K公司設計流程
企業目標:
提高企業核心能力, 提升獲利力
ASIS
Continuous
Business
Process
Improvement
TOBE
10
產品設計
模具設計
28
週
70
週
產品設計
模具設計
10
週 38
週
BPI
如果變異增大呢?
•像701週 vs. 38  30週?
•月結 5  3天

11. -
1.00
2.00
3.00
4.00
5.00
6.00
Inception Elaboration Build Transition Production
Z-User
Z-User
Cp
Phase
現況 專案
規劃
方案
設計
開發
整合
轉換 上線
ERP 的專案目標:
提高企業流程處理能力
ASIS Definition Elaboration Build Transition
Production
TOBE
11
ERP phase
Cp: Capability of Process
處理效率:
過程管制

12. 企業流程(群體) 專案內流程(樣本) 統計數據
流程分析
流程管理
流程分析
業務推演
流程主管單位
流程品質管
制
專案與企業流程關係
流程
主管
專案
範圍
專案
過程
管理
企業
價值鏈
流程
主管
專案
範圍
專案
過程
管理
測定抽樣
無限群體
測定
處置
處置
抽樣 測定
有限群體
0
2
4
6
8
10
12
14
16
X
X
X
X
X

13. = 0.05 project’s risk for AQL,
ex. 過多整合測試(CRP) 提高專案(甲/乙方)成本
= 0.10
Enterprise’s risk for FTPD,
ex. 需求遺漏缺少必要開發
專案方案/流程的允收
機率 (Probability of
Acceptance)
Percent
Defective
LTPDAQL
0 1 2 3 4 5 6 7 8
100
95
75
50
25
10
0
專案的作業水準為企業整體應用新流程作業水準的抽樣。
FTPD(Flow tolerance percent defect)
軟體專案的作業特性曲線
(Operation Characteristic Curve)

14. 軟體專案的作業特性曲線模擬
(Operation Characteristic Curve)
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
0% 2% 4% 6% 8% 10% 12% 14% 16% 18% 20%
允收機率
不良率
OC曲線
CRP:1
CRP:2
CRP:3
CRP:6

15. ERP 專案目標: 傳統系統角度
定義
CRP1.0
設計
CRP2.0
建立
CRP3.0
Go Live
用戶角色
提供需求
學習操作
轉換
CRP4.0
用戶在專案過程的成長
•協助顧問瞭解業務
•學習系統操作或限制
專案過程的統計分析
•以系統問題與主觀調查統計為主

16. ERP 專案目標: 漸進式改變
用戶及部門
發展階段
初學階段 學習階段 執行階段 自主階段
專案領導型態 指示 教練 支持 授權
流程部門 功能/流程
方案設計
溝通
方案驗證
溝通 培訓
IT 功能
應用架構
方案設計
開發工具
開發
問題處理
問題分析
定義
CRP1.0
設計
CRP2.0
建立
CRP3.0
Go Live
人員組織角色
初學者
作業者
溝通者
執行者
架構師
轉換
CRP4.0

17. -
1.00
2.00
3.00
4.00
5.00
6.00
Inception Elaboration Build Transition Production
Z-User
Z-User
實例: Z公司用戶流程能力評估
Cp
Phase

18. 實例: Z/S用戶的流程能力比較
 比較分析: S 公司4 個月上線, Z公司8 個月上線
◦ 設計階段:
 S 公司用戶與顧問投入人數較Z公司多一倍
◦ 建立階段:
 S 公司開發時間短, 測試發生瓶頸, 流程處理能力下降
◦ 上線階段:
 S 公司為新公司, 多名主管更換, 並且多名關鍵使用者任務調整
Inception Elaboration Build Transition Production
S-User 2.01 1.86 0.42 1.76 3.90
Z-User 1.70 2.06 2.90 3.08 5.06
-
1.00
2.00
3.00
4.00
5.00
6.00
S-User
Z-User

19. 實例: 用戶的階段能力評估因
子Z公司:
•定義階段(Inception): : 需求/操作培訓/流程收集
•設計階段(Elaboration): : 配置培訓/流程規劃
• . . .
S公司:
• 空值表示樣本數少於15, 不納入統計
Data
数据
数据-交易
数据-基础
数据-程序/处理
数据-规则
Design
GAP
方案设计
Else
CRP20
CRP30
CRP40
PROD
未分类
例外处理
EndUser
培训
操作问题
SOP
IT
IT管理
IT管理-服务管理
IT管理-权限
PM
项目管理
项目计划
高阶汇报
Process
流程
流程-企业架构
流程-部门内部
流程-部门间
Req.
需求
需求-变更
System
系统
系统-DBA
系统-ERP
系统-ERP配置
系统-开发
系统-集成
Train
展示/配置

20. 實例: Z/S公司用戶/顧問任務比例
-
200.00
400.00
600.00
800.00
1,000.00
1,200.00
1,400.00
1,600.00
1,800.00
2,000.00
User
Consultant
-
200.00
400.00
600.00
800.00
1,000.00
1,200.00
1,400.00
Inception Elaboration Build1 Transition1 Production1
User
Consultant
 Z公司:
◦ 用戶在建立階段開
始逐步負責流程/方
案調整, 由顧問協助
 S公司:
◦ 由於時間不夠, 用戶
在轉換階段才接手
 S公司養成時間不
足, 人員/組織未能
形成平衡狀態

21. 實例: S公司用戶/顧問任務比例
 用戶:
◦ 定義/設計階段: 以流
程收集與規劃為主
◦ 建立階段: 方案設計/
調整為主
◦ 轉換階段: 資料收集
/測試
 顧問
◦ 定義階段 : 需求與
方案設計為主
◦ 設計階段: 方案設計
為主
◦ 轉換階段: ERP與開
發的系統問題處理
為主
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Inception Elaboration Build1 Transition1 Production1
IT
PM
EndUser
Train
Data
System
Req.
Design
Process
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Inception Elaboration Build1 Transition1 Production1
IT
PM
EndUser
Train
Data
System
Req.
Design
Process

22. 小結: S公司的Pareto分析
 問題比例分析
◦ 70%議題為流程/需求變
更: 用戶和IT能負責處理
◦ 10%為系統問題: 由顧問
負責
 上線後, 用戶自我管理
◦ 可持續進行改善流程與方
案活動

23. Agenda
 軟體品質工程
 軟體品質的衡量與案例
 品質銷售策略
 方法論框架
 專案案例分析-基礎
 專案案例分析-進階
 Q&A
 附錄: 軟體合同形式

24. 什麼是品質-性價比
•大野耐一:價格由市場決定，企業要獲得利潤只有靠降低成本
•專案利潤 = 品質價值 – 品質成本(100+200 code+售前成本)
•顧問服務的性價比 =
•降低品質成本
•提高品質價值

25. 軟體專案的產品是什麼?
類別
品牌
商業供應鏈
產品設計
生產過程管
理
製造元素:
人工
廠商
Apple
電信/軟體/
媒體業
Apple+鴻海
鴻海
工人
實體產品
iPhone
Business
Model
服務/軟體
iPhone
生管/QA
組件
實體性價比
簡約設計:
生活
簡約設計:
作業
簡約設計:
操作
生產成本/
過程管理
跳樓
實施服務產品
專案管理:
專案經理?
整合服務:
專案經理?
方案設計:
方案經理
品質/變革:
管理
顧問?
服務性價比
資訊文化:
整合即時
資訊文化:
供應鏈整合
BPI:
方案整合
專案過程管
理SPC
顧問能力與
經驗
SPC: Statistical Process Control, 統計過程控制

26. 微笑曲線
Apple+電信服務
AIC
Apple/鴻海
AIC.PM.SPC
工人
AIC.顧問
Apple
Oracle + AIC
Apple/鴻海
AIC.PM.Solution

27. 27
如何管理流程改善過程?
傳統瀑布式::由IT維護 ERP系統業
務規則
BPI::流程主管部門定義, 並維護ERP系
統業務規則
IT 部門./
ERP 交易
Plan
Source
Make
Market
Sell
Support
Plan
Source
Make
Market
Sell
Support
ERP
交易
主資料/
業務規則
※單據流轉式的管理架構 ※業務財務一體化的管理架構

28. 28
軟體專案實施類型
0
200
400
600
800
System-based Solution-based Asset-based
People
Process
Solution
System
階段 2
People/
Process
Support
階段 3
Solution
Improve
階段 2
People/
Process
Support
階段 3
Solution
Improve
•由OC 曲線對應實施類型(CRP run 為1, 3, 6)

29. 軟體專案品質的3個迷失
軟體工程角度
軟體傳統工程
知識建模/
再利用
設計樣式
UML
架構設計/
Design for test
軟體社會工程 組織變更/學習
RUP
Agile
品質管理角度
軟體品質管理
(損失成本)
設計
同步工程/穩健
設計
CRP的設計方
式/成本評估
生產 過程管制圖
服務品質管理 變革/教育
軟體開發成本
可見
實質影響
效率
效能
主觀感受
不可見 未來影響
效率
效能
暴力法
系統設計

30. 軟體品質管理的問題-
為什麼要做管制?
如何做好軟體專案經理?
- 如何衡量任務品質
有信心保證專案成功
有問題不怪我
不留證據
避免犯錯
不完全合同:
商業談判過程
建立可預測的
專案管理系統
預防錯誤:
事件趨近客觀機率
專案性價比:
衡量投入產出
沒信心專案會成功 照章辦事
害怕錯誤:
照本宣科
容易/怕衝突

31. Agenda
 軟體品質工程
 軟體品質的衡量與案例
 品質銷售策略
 方法論框架
 專案案例分析-基礎
 專案案例分析-進階
 Q&A
 附錄: 軟體合同形式

32. 實施問題分析
方法過程原因
實施問
題
主要問
題
議題充分提出
並驗證解決
如何保證議題
充分提出
流程導向
提出: 主管部門
+作業部門
流程導向
如何保證議題
充分解決
相依性需求
解決: 顧問+主
管部門+IT;
CRP
方案文件/系統
如何保證方案
經過驗證
品質管理
驗證: 主管部門
+作業部門
CRP

33. 方法論框架
Project Execution and Control
Project
Start
Delivery Method
Inception Elaboration Build Transition Production
Project
Closure
時程控制 溝通管理 品質管理 問題管理 風險管理 變更管理
任務劃分 業務模型 方案設計 變革管理

34. 方法論框架安排
(Arrangement)
Project Execution and Control
Project
Start
Delivery Method-AIM/AIM4BF
OA
Definition
BRM/GAP
Elaboration
SIT
Build
UAT
Transition
Production
Project
Closure
時程控制 溝通管理 品質管理 問題管理 風險管理 變更管理
任務劃分 業務模型 方案設計 變革管理

35. 品質管理/任務劃分
Project Execution and
Control
Project
Start
Delivery Method-AIM/AIM4BF
OA
Definition
BRM/GAP
Elaboration
SIT
Build
UAT
Transition
Production
Project
Closure
時程控制 溝通管理 品質管理 問題管理 風險管理 變更管理
任務劃分 業務模型 方案設計 變革管理
階段劃分及議題分類
需求 设计 建立 转换 上线
CRP20 CRP30 CRP40 PROD 操作问题-User
CRP30 CRP40 PROD 操作问题-User 操作问题-KU
CRP40 PROD 项目计划 操作问题-KU 需求-变更
PROD 项目计划 项目管理 需求-变更 流程
项目计划 项目管理 需求 流程 流程-企业架构
项目管理 需求 需求-变更 流程-企业架构 流程-部门间
需求 流程 流程 流程-部门间 流程-部门内部
流程 流程-企业架构 流程-企业架构 流程-部门内部 方案设计
流程-企业架构 流程-部门间 流程-部门间 方案设计 系统
方案设计 流程-部门内部 流程-部门内部 系统 系统-DBA
系统 方案设计 方案设计 系统-DBA 系统-ERP配置
数据 系统 系统 系统-ERP配置 系统-ERP
GAP 数据 系统-ERP配置 系统-ERP 系统-整合
未分类 GAP 系统-ERP 系统-整合 系统-开发
例外处理 展示/配置 系统-开发 系统-开发 IT管理
未分类 数据 IT管理 IT管理-权限
例外处理 GAP IT管理-权限 IT管理-服务管理
展示/配置 IT管理-服务管理 上线
未分类 上线 SOP
例外处理 SOP 培训
培训 数据
数据 数据-基础
数据-基础 数据-规则
数据-规则 数据-交易
数据-交易 数据-程序/处理
数据-程序/处理 未分类
未分类 例外处理
例外处理

36. 品質管理/業務模型
Project Execution and
Control
Project
Start
Delivery Method-AIM/AIM4BF
OA
Definition
BRM/GAP
Elaboration
SIT
Build
UAT
Transition
Production
Project
Closure
時程控制 溝通管理 品質管理 問題管理 風險管理 變更管理
任務劃分 業務模型 方案設計 變革管理
R12 Flow Template
• Stand BP080: 1.0
Current Logical Model
• BP080: 1.1
Required Logical Model
• BP080: 1.2
Required Physical Model
• GAP list
CRP
1.1
CRP
1.2
CRP
2.0
Definition Phase: CRP1.1
• Perform Logicalization
Definition Phase: CRP1.2
Add New System
Requirements,Consider
Business System Options
Elaboration Phase: 2.0
Add Implementation Details,
Consider Technical System
Options
As IS
Tobe + IFRS
系統設計/
開發
Surround
interface
管控階段中的CRP結果

37. 品質管理/方案設計
Project Execution and
Control
Project
Start
Delivery Method-AIM/AIM4BF
OA
Definition
BRM/GAP
Elaboration
SIT
Build
UAT
Transition
Production
Project
Closure
時程控制 溝通管理 品質管理 問題管理 風險管理 變更管理
任務劃分 業務模型 方案設計 變革管理
方案設計的品質檢查點:
CRP = 品管圈
4 5 6 7 8 9 10 11 12 1
方案定義
• CRP1.1
• Architect Workshop
• Flow GAP Analyst
設計階段
• TO-BE Flow Design
• CRP2.1
• CRP2.2
• CEMLI Evaluation
• Data Conversation
Strategy
建立階段
• 建立.0 Preparation
• CRP3.1
• CRP3.2
轉換階段
• CRP4.0 Preparation
• CRP4.1
• CRP4.2
上線
SUMMARY
2010 2011
流程
組織
方案/系統
人員
流程
組織
方案/系統
人員
流程
組織
方案/系統
人員
流程
組織
方案/系統
人員

38. 品質管理/方案設計cont.
Project Execution and
Control
Project
Start
Delivery Method-AIM/AIM4BF
OA
Definition
BRM/GAP
Elaboration
SIT
Build
UAT
Transition
Production
Project
Closure
時程控制 溝通管理 品質管理 問題管理 風險管理 變更管理
任務劃分 業務模型 方案設計 變革管理
方案設計的檢查點及對應人員
- 方案確認為部門主管
CRP2.0方案準備流程
BPM(Business Process Mapping) Flow
關鍵使用者–流程
負責人
專案經
理
Project Schedule –
2.1 Phase Schedule
顧問
經理/總監–流程
負責人
(核心團隊)
周計畫 – BPM
Project Schedule –
2.0 Phase Schedule
業務流程
1d
關鍵用戶–作業人
員
設計上層流程
2d
説明設計細節流
程
審核並確認2d
審核並確認 設計細節流程
審核並確認 審核並確認
Design
Detail levels
flows
D1:1-SEP D10
周計畫 –
BPM/CRP2.1
流程清單
BP080
BF100
TE040

39. 品質管理/變革管理
Project Execution and
Control
Project
Start
Delivery Method-AIM/AIM4BF
OA
Definition
BRM/GAP
Elaboration
SIT
Build
UAT
Transition
Production
Project
Closure
時程控制 溝通管理 品質管理 問題管理 風險管理 變更管理
任務劃分 業務模型 方案設計 變革管理
需求 設計 建立 轉換
ERP
學習
進度
操作 配置 設計 教授
主要
任務
初步
需求
部門
溝通
系統
整合
教授
主要
目標
需求
確認
方案
確認
整合
測試
轉換
階段
產出
部門
需求
未來
流程
測試
結果
數據
及
SOP
顧問
任務
需求
討論
方案
設計
方案
驗證
方案
調整
議題
紀錄
顧問
顧問/
用戶
用戶
用戶
/IT

40. 品質管理/變革管理cont.
Project Execution and
Control
Project
Start
Delivery Method-AIM/AIM4BF
OA
Definition
BRM/GAP
Elaboration
SIT
Build
UAT
Transition
Production
Project
Closure
時程控制 溝通管理 品質管理 問題管理 風險管理 變更管理
任務劃分 業務模型 方案設計 變革管理
變革管理:
漸進式
用戶及部門
發展階段
初學者 學習者 執行者 自主者
專案領導型態 指示 教練 支持 授權
流程部門 功能/流程
方案設計
溝通
方案驗證
溝通 培訓
IT 功能
應用架構
方案設計
開發工具
開發
問題處理
問題分析
CRP1.0 CRP2.0 CRP3.0 Go Live
人員組織角色
初學者
作業者
溝通者
執行者
架構師
CRP4.0

41. 軟體專案品質原則
 雙方品質承諾
◦ 領域議題會充分提出並滿足
 實施團隊了解領域議題及經驗
◦ 專案規劃能對議題建立共識方案
 雙方資源安排能滿足目標要求
◦ 專案管理
 依據雙方目標共識監控
 一致的專案管理原則
◦ 對需求/問題有共識
 Issue count
◦ 對需求/問題處理狀態及結果有共識
 Issue map to deliverable
 Issue link to project schedule
◦ 衡量基準為處理時間
 Handle time measure as quality

42. 軟體專案的品質原則
 資料收集
◦ PDCA 第一步是資料收集
◦ 軟體專案為企業流程的抽樣
 最佳化原則
◦ BPI 原則:
 流程主管 = 產權所有人 = 具舉證能力(收集/分析能力)
 例如, 如何認定客制化的必要性, 要規範由誰何時提出
 反之則組織未達帕累托效率
◦ 局部最佳化會產生暴力軟體開發法
 產生企業資源不合理分配
 結論:
◦ 專案需應用SPC 監控流程能力與產權分配

43. Agenda
 軟體品質工程
 軟體品質的衡量與案例
 品質銷售策略
 方法論框架
 專案案例分析-基礎
 專案案例分析-進階
 Q&A
 附錄: 軟體合同形式

44. 組織
流程
方案
軟體品質管理的問題-
如何做?
ERP 專案
高階主
管
用戶核
心團隊
顧問
用戶核
心團隊
有明確因
果關係
可以計量
分析
可衡量與
修正
歸納統計,
努力就成功
流程
組織

45. 軟體品質管理的問題-
如何做?
專案性價比:
投入產出管理
統計假設:
努力就成功
一致的品質目標
Issuelog 無漏
零缺點
供需平衡:
即時計劃控制
可衡量:
平均處理時間
核心團隊同時為
投入/產出
分層按流程統計
專案性價比:
投入產出結構
投入/產出管理
主要投入:
軟體
顧問
用戶核心團隊
流程/需求/方案
主要產出:
系統
用戶核心團隊
有明確因
果關係
可以計量
分析
可衡量與
修正
歸納統計,
努力就成功

46. Knowledge Transfer
POST GO LIVE
End-user training
Flow owner training
Standard training
• Maintenance Training
• Operation Training
• Process Training
• Operator
• Communicator/Executioner
• Architect
• Tools
• Architecture
• Application
46

47. Knowledge Transfer
47
用戶及部門
發展階段
Inception
初學階段
Elaboration
學習階段
Build
執行階段
Transition
自主階段
專案領導型態 指示 教練 支持 授權
流程部門 功能/流程
方案設計
溝通
方案驗證
溝通 培訓
IT 功能
應用架構
方案設計
開發工具
開發
問題處理
問題分析
Inception Elaboration Build GoLiveTransition
POST GO LIVE
End-user training
Flow owner training
Standard training

48. 0
100
200
300
400
500
600
700
800
900
9/1
9/8
9/15
9/22
9/29
10/6
10/13
10/20
10/27
11/3
11/10
11/17
11/24
12/1
12/8
12/15
12/22
12/29
開啟累計
計劃累計
完成累計
議題趨勢與追踪
Definition
CRP1.0
Elaboration
CRP2.0
Build
CRP3.0
Transition
CRP4.0
•Iterative: pull up
issue/requirement
•計劃差異
•執行差異
•CRP: Conference Room Pilot, 業務推演

49. 控制圖-按事件日期
0
5
10
15
20
9/1
9/8
9/15
9/22
9/29
10/6
10/13
10/20
10/27
11/3
11/10
11/17
11/24
12/1
12/8
12/15
12/22
12/29
1/5
Xbar
CL
UCL
LCL
合計
-
10
20
30
40
50
9/1
9/8
9/15
9/22
9/29
10/6
10/13
10/20
10/27
11/3
11/10
11/17
11/24
12/1
12/8
12/15
12/22
12/29
1/5
R圖
CL
UCL
LCL
Definition
CRP1.0
Elaboration
CRP2.0
Build
CRP3.0
Transition
CRP4.0

50. 專案排程原則
– mutual trust based on truth
0
20
40
60
80
100
120
140
160
180
1-Sep
2-Sep
3-Sep
4-Sep
5-Sep
6-Sep
7-Sep
8-Sep
9-Sep10-Sep11-Sep12-Sep13-Sep14-Sep15-Sep16-Sep17-Sep18-Sep19-Sep20-Sep21-Sep22-Sep23-Sep24-Sep25-Sep26-Sep27-Sep28-Sep
开启累计
完成累计
计划累计
•Estimated Open Issue=5/days
•Planned AHT < 5 days
•Complete AHT by CRP run
AHT: Averaged Handle Time

51. 比例趨勢圖– S公司采购流程
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
9/17
9/19
9/21
9/23
9/25
9/27
9/29
10/1
10/3
10/5
10/7
10/9
10/11
10/13
10/15
10/17
10/19
10/21
10/23
10/25
10/27
10/29
10/31
部门内部工作
MES程序错误
用户操作错误
部门间协调
ERP程序错误
二次开发程序BUG
其他系统问题
未知错误
•采购订单历史资料录入系统
•因为物料资料不全，因此批准供应商
不全
•10月22日完成所有需检验物料的设定，
则已下的采购订单还未做接收的情况如
何处理？
•固定资产接收发放过程中设备部要求有入库
单和领用单
•BOM中的物料没有最小包装量，资材在发料
时会发生困难
•8月底外借品数量未纪录入系统
•采购接收未将松江厂与S1线的区分开，导致
库存无法做接收，制造部无法结单
•资产含税价录入系统，否则财务转资出错
•SJF和S1收料在系统中收料由于量大不能保证
按计划录入系统

52. 比例趨勢圖– T公司流程
0%
5%
10%
15%
20%
25%
30%
35%
40%
45%
08-1-6
08-1-7
08-1-8
08-1-9
08-1-10
08-1-11
08-1-12
08-1-13
08-1-14
08-1-15
08-1-16
08-1-17
08-1-18
08-1-19
08-1-20
08-1-21
08-1-22
操作问题
流程-部门间
流程-部门内部
方案设计
新需求
系统
IT管理

53. 53
比例趨勢圖–Z公司
32%
0%
5%
10%
15%
20%
25%
30%
35%
40%
流程-部门间
系统类
操作问题
新需求
IT管理
未分类1
流程-部门内部
方案设计

54. 54
流程-部門間:起因部門分析
製造受影響最大 研發中心占48%起因
0
5
10
15
20
25
30
35
40
45
50
制造中心
资材组
商务管理部.销售
计划组
报关组
采购中心
财务中心
研发中心
质量及客服中心
项目管理
信息中心
质量及客服中心
商务管理部.销售
制造中心
资材组
财务中心
计划组
采购中心
研发中心
研发中心
48%
采购中心
18%
计划组
10%
其他
24%

55. 研發中心-提出問題分類
0
5
10
15
20
25
30
35
40
2008-6-1
2008-6-3
2008-6-5
2008-6-7
2008-6-9
2008-6-11
2008-6-13
2008-6-15
2008-6-17
2008-6-19
2008-6-21
2008-6-23
2008-6-25
2008-6-27
2008-6-29
流程-部门间
系统类
操作问题
新需求
IT管理
流程-部门内部

56. 部門間問題 -責任單位為研發中心
分类 细项
计数项:产生日期
问题分类 细部分类 汇总
数据问题 变更数据-研发单位 23
变更数据-来源单位 19
新增数据-研发单位 6
新增数据-来源单位 6
规则问题 规则及流程确认 5
规则错误-编码规则 4
規則錯誤-編碼規則 1
规则错误-单位转换规则 1
流程问题 研发流程-部门间 9
研发流程-公司间 1
操作问题 操作问题 4
服务 维护及时性 2
总计 81
数据问题
67%
规则问题
14%
流程问题
12%
操作问题
5%
服务
2%
细部问题分析

57. 部門間問題 -責任單位為研發中心
影響
部門
原因 建議措施
製造： • BOM資訊準確性
• 工藝路線準確性
• 料號屬性完整性
– 研發ERP加強對系統切換導入資料的審核（已有專人審核
BOM）
– 加強操作人員規範化（切換之初操作不熟練，現已多次培訓並
加強審核）
– 料號屬性按照製造要求更新（包括排版粒數、定型資訊）
資材 • 料號導入準確性
• 料號屬性準確性
– 更改/更新有誤料號（設為停用）
– “有效期控制”為資材需求更改
行銷 • BOM審核及時性
• 包裝材料完整性
– 定型產品傳單研發後有專人審核BOM
– 大樣仍按照正常評審流程走研發,ERP維護審核BOM
– 研發ERP組審核BOM時根據資料加入包裝材料及輔料
PMC • BOM清單準確性
• BOM審核及時性
• 物料屬性準確性
– 包含停用材料或需用替代料的BOM除研發審核BOM,也需計畫
發現後及時回饋研發更新
– “製造或採購”屬性系統有時不能帶入子組織,需繼續查看
… •… –…

58. 0
2
4
6
8
10
12
14
16
產生日期
4/1
4/17
4/22
4/29
5/8
5/11
5/13
5/15
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
Xbar
CL
UCL
LCL
FuncAll
0
0
轉換階段: 研發流程
遠因分析
趨勢, 研組Xbar/R圖顯示:
•研發組轉換階段工作逐步吃緊
-
5
10
15
20
產生日期
4/8
4/18
4/25
5/7
5/10
5/12
5/14
5/16
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
R圖
CL
UCL
LCL
FuncAll
•原因分析:
•箽事會未贊成清理歷史庫存, 資料量大, 檢查及調整任務重
•部門主管輪調, 部門資深人員離職,支持力道不足

59. 個案的人員訓練趨勢追踪
汇总
-
10.00
20.00
30.00
40.00
50.00
60.00
70.00
80.00
90.00
資材組
報關組
财务中心.成本
質量及客服中
心
研發中心
采购中心
计划組
财务中心
制造中心
商務管理部.銷
售
汇总
请将页字段拖至此处
平均值项:平均成绩
单元
在此处放置系列字段
平均
-
10.00
20.00
30.00
40.00
50.00
60.00
70.00
80.00
2008年
5月
12日
2008年
5月
13日
2008年
5月
14日
2008年
5月
15日
2008年
5月
16日
2008年
5月
17日
2008年
5月
18日
2008年
5月
19日
2008年
5月
20日
2008年
5月
21日
2008年
5月
22日
2008年
5月
23日
2008年
5月
24日
平均
 問題
◦ 重點加強部門
 品質/製造部門
◦ 需加強部門
 採購
 研發
 方案
◦ 各部門培訓
◦ 跨部門培訓方式
 由流程部門培訓部門關
鍵使用者
 再自行培訓各部門用戶
異常

60. Agenda
 軟體品質工程
 軟體品質的衡量與案例
 品質銷售策略
 方法論框架
 專案案例分析-基礎
 專案案例分析-進階
 Q&A
 附錄: 軟體合同形式

61. 管制圖: 平均值與全距管制圖
 Xbar往上, 平均值遞增
◦ 表示資源安排問題, 造成
議題處理不完
◦ 例如, 方案設計, 資料準
備等時間拖長
 R往上, 變異性遞增
◦ 表示勞逸不均, 計劃問題,
需調整資源或時程
 例如, 料號整合議題未完
成, 瓶頸在mfg組, 另兩組
會idle

62. ALL - 1
-
5
10
15
20
25
R圖
CL
UCL
LCL
FuncAll 0
0
1
2
3
4
5
6
7
8
9
10
Xbar
CL
UCL
LCL
FuncAll
0
0
•R圖顥示: 擴散
•分層: 分組有問題
•Xbar顯示:
•正常表示有分層問題, 勞逸
不均
異常
趨勢, 重心由設計階段轉移開發及用戶支持
* 開發支持為分組統計

63. ALL-2
-
5
10
15
20
25
R圖
CL
UCL
LCL
FuncAll 0
0
2
4
6
8
10
12
14
16
18
20
Xbar
CL
UCL
LCL
FIN
MFG
DIS
•R圖顥示:
•檢查整合議題, 避免問題擴
散及平衡資源
•需安排支持資源
•提高議題重要性, 即時檢查
•XBar顥示:
•製造組有瓶頸議題
•分銷/財務組太閒

64. DIS
0
1
2
3
4
5
6
7
8
9
10
Xbar
CL
UCL
LCL
DIS
0
0
-
5
10
15
20
2/172/202/252/27 3/4 3/6 3/103/123/143/193/213/253/273/31 4/2 4/7 4/9 4/114/154/17 1/0 1/0 1/0 1/0 1/0
R圖
CL
UCL
LCL
DIS 平均值 - HT
•R圖顥示:擴散
•分層:系統異常,無法複制:
客戶退貨檢驗後無法更正不穩定, 小組有溝通問題
- 需支持OM 關鍵使用者和其他部門溝通
趨勢, 週計劃要加強review跨部門溝通結果

65. MFG
0
2
4
6
8
10
12
14
16
18
20
Xbar
CL
UCL
LCL
MFG
0
0
-
2
4
6
8
10
12
14
16
2/172/202/222/262/28 3/6 3/113/133/193/273/31 4/2 4/7 4/124/17 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0
R圖
CL
UCL
LCL
MFG 平均值 - HT
異常,製造顧問需加強ASCP方案設計, 工作量太大
X
X
X
X
X
X
X
X X
X
X

66. FIN
-
5
10
15
20
R圖
CL
UCL
LCL
FIN 平均值 - HT
0
2
4
6
8
10
12
14
16
Xbar
CL
UCL
LCL
FIN
0
0
X
X
X
X
X
X

67. CRP 1.0/2.0 workload
comparison
0%
20%
40%
60%
80%
100%
PM
Requirement
SystemSolution
Process
CRP1.0
CRP2.0

68. CRP 1.0 Workload analysis
-
2.00
4.00
6.00
8.00
10.00
12.00
ASCP BOM CST GL OM PM PO QA WIP AP AR CE FA INV
Consultant
Customer
Average AHT= 5.27
•顧問/客戶差異太大: •PO 太長

69. CRP 2.0 Workload analysis
-
2.00
4.00
6.00
8.00
10.00
12.00
14.00
16.00
ASCP BOM CST GL OM PM PO QA WIP AP AR FA INV HR
Consultan
Customer
Average AHT= 4.41

70. All
0
2
4
6
8
10
12
14
16
18
20
產生日期
9/11
9/13
9/17
9/19
9/21
9/24
9/26
10/7
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
Xbar
CL
UCL
LCL
FuncAll
0
0
-
2
4
6
8
10
12
14
9/7
9/12
9/14
9/18
9/20
9/22
9/25
9/28
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
R圖
CL
UCL
LCL
FuncAll平均值 - HT

71. MFG
0
5
10
15
20
25
30
35
40
45
50
產生日期
產生日期
2/17
2/19
2/20
2/21
2/22
2/25
2/26
2/27
2/28
2/29
3/5
3/6
3/7
3/11
3/12
3/13
3/14
3/19
3/20
3/27
3/28
3/31
4/1
4/2
4/3
4/7
4/8
4/12
4/15
4/17
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
Xbar
CL
UCL
LCL
MFG
0
0
-
5.00
10.00
15.00
20.00
25.00
30.00
35.00
40.00
45.00
50.00
2/17
2/19
2/20
2/21
2/22
2/25
2/26
2/27
2/28
2/29
3/5
3/6
3/7
3/11
3/12
3/13
3/14
3/19
3/20
3/27
3/28
3/31
4/1
4/2
4/3
4/7
4/8
4/12
4/15
4/17
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
R圖
CL
UCL
LCL
MFG 平均值 - HT
•ASCP:
•周生产计划方式的实现
•确认不同订单类型对应的计划模
式，如专项备料订单，寄售订单对
应的计划运行模式。
* 脫褲子放屁分析法

72. DIS
0
5
10
15
20
25
30
35
產生日期
產生日期
2/17
2/19
2/20
2/21
2/25
2/26
2/27
2/28
3/4
3/5
3/6
3/7
3/10
3/11
3/12
3/13
3/14
3/17
3/18
3/19
3/20
3/21
3/24
3/25
3/26
3/27
3/28
3/31
4/1
4/2
4/3
4/7
4/8
4/9
4/10
4/11
4/14
4/15
4/16
4/17
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
Xbar
CL
UCL
LCL
DIS
0
0
-
5.00
10.00
15.00
20.00
25.00
30.00
2/17
2/19
2/20
2/21
2/25
2/26
2/27
2/28
3/4
3/5
3/6
3/7
3/10
3/11
3/12
3/13
3/14
3/17
3/18
3/19
3/20
3/21
3/24
3/25
3/26
3/27
3/28
3/31
4/1
4/2
4/3
4/7
4/8
4/9
4/10
4/11
4/14
4/15
4/16
4/17
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
1/0
R圖
CL
UCL
LCL
DIS 平均值 - HT
提供进口物料的关税
•資料: 未结订单和价目表中存在旧料号无
新料号对应
•流程: 已登记订单销售订单类型（销售形
态)变更处理方式
•销售订单类型整合确定
* 脫褲子放屁分析法

73. 控制圖分析原則
異常圖形分析
簡單形式
週期/傾向/轉變/
系統變異
複雜形式
穩定/不穩定混
合
異常
分組
成層
相依關係
交互作用
不穩定
簡化方法
簡單分析法
變異消除法
資料重新安排
法
設計實驗法

74. 數據調整- 原始數據
•標注部份為開發需求
•己計劃/取消應記為同日

75. 數據調整-分類及狀態調整
•己計劃/取消應記為同日
•開發需另外統計
ASCP:
•工單週期
•訂單類別排程
PO:
•進口關稅提供

76. 分布不對: 取樣需要以天為基準
ASCP:
•工單週期
•訂單類別排程
PO:
•進口關稅提供

77. 分布不對: 取樣需要以天為基準
Autofill: 某日沒有議題時,
假設和前一日期相同
Sum: 跨組平均再加總
By Team: 分組計數再加
總
 計數以整體專案平均時,
分布越接近常態
0
2
4
6
8
10
12
14
16
2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46
Autofill/Sum

79. Agenda
 軟體品質工程
 軟體品質的衡量與案例
 品質銷售策略
 方法論框架
 專案案例分析-基礎
 專案案例分析-進階
 Q&A
 附錄: 軟體合同形式

80. Project contract type
 Fixed Price / Fixed Scope
 Time and Materials
 Time and Materials with Fixed Scope and a
Cost Ceiling
 Time and Materials with Variable Scope and
Cost Ceiling
 Phased Development
 Bonus / Penalty Clauses
 Fixed Profit
 “Money for Nothing, Changes for Free”
 Joint Ventures
 the "Sprint Contract"
http://agilesoftwaredevelopment.com/blog/peterstev/10-agile-contracts

81. Fixed Price / Fixed Scope
 Structure: Agree on the deliverables, deliver it.
Send a bill. Customers like fixed price projects
because it gives them security (or at least they
think so).
 Scope changes: The name says it all, doesn't it?
The change request game (correction: change
request process) is intended to limit scope
changes. This process is costly, and the changes
are usually not preventable. Since the customer
almost by definition wants more scope, ending the
project can be difficult. The supplier wants the
customer to be happy, so the supplier usually
yields. The words ‘et cetera’ are very dangerous
in the specification of a fixed price requirement.
 Risk: Obvious risk is on the side of the supplier. If
the estimates are wrong, the project will lose
money. Less obvious risks are the change
request game, through which the supplier
negotiates additional revenue through scope
changes. If the supplier had badly underestimated
the effort or risk, or quoted an unrealistically low
price, the losses can even threaten the existence
of the supplier, which also presents a problem to
the customer.
 Relationship: Competitive to indifferent.
Customer generally wants to have more and the
supplier wants to do less. The supplier wants the
customer to be happy, so usually the supplier
yields.

82. Time and Materials
 Structure: Work for a month,
then send the customer an
invoice. Suppliers like it,
because the customer carries
the risk of changing his mind.
 Scope: Not a priori fixed.
Sooner or later, the customer
doesn't want to pay any more,
so the project comes to an
end.
 Risks: carried 100% by the
client. Supplier has little
incentive to keep costs down.
Effort to ensure that only
legitimate effort and expenses
are invoiced can be
substantial.
 Relationship: Indifferent. The
supplier is happy when more
work comes because more
work means more money.

83. Time and Materials with Fixed
Scope and a Cost Ceiling
 Structure: Same as fixed price,
fixed scope, except if the vendor
gets finished early, the project costs
less, because only actual effort is
invoiced.
 Scope: Same as fixed price, fixed
scope.
 Risks: This appears to represent the
‘best of both worlds’ from the
customer’s point of view. If it
requires less effort than expected, it
costs less. But the once the cost
ceiling has been achieved, it
behaves like a fixed price project.
 Relationship: Dependent. From the
supplier’s point of view, the goal is to
hit the cost ceiling exactly. There is
no incentive for the supplier to
deliver below the maximum
budgeted cost. The customer has
probably treated the project
internally as a fixed price project,
and so has no incentive little
renounce scope to save money.

84. Time and Materials with
Variable Scope and Cost
Ceiling  Structure: Same as time and
materials except a cost ceiling
limits the financial risk of the
customer.
 Scope: Same as a fixed price,
fixed scope project.
 Risks: the budget will expire
without achieving the
necessary business value for
the customer. Customer won’t
get everything he asks for.
 Relationship: Cooperative.
The combination of limited
budget and variable scope
focuses both customer and
vendor on achieving the
desired business value within
the available budge.

85. Phased Development
 Structure: Fund quarterly releases
and approve additional funds after
each successful release.
 Scope Changes: Not explicitly
defined by the model. Releases are
in effect time boxed. The knowledge
that there will be another release
next quarter makes it easier to
accept postponing a feature to
achieve the time box.
 Risk: Customer’s risk is limited to
one quarter’s worth of development
costs.
 Relationship: Cooperative. Both the
customer and the supplier have an
incentive that each release be
successful, so that additional
funding will be approved.

86. Bonus / Penalty Clauses
 Structure: Supplier receives a
bonus if the project completes early
and pays a penalty if it arrives late.
The amount of bonus or penalty is a
function of the delay
 Scope Changes: difficult to accept
because changes potentially impact
the delivery date, which is surely not
allowed.
 Risk: Does the customer have an
incentive for early completion? The
ROI arguments must be compelling
and transparent. Otherwise the
customer gets a cheaper solution
the longer it takes.
 Relationship: could be cooperative,
but might degenerate into indifferent
if the customer does not truly need
the software by the date agreed.

87. Fixed Profit
 Structure: any project budget
consists of effective costs and profit.
The parties agree on the profit in
advance, e.g. $100,000. Regardless
of when the project is completed, the
contractor receives the incurred
costs plus the agreed profit.
 Scope is fixed-
 Risk is shared. If project finishes
early, the customer pays less, but
the supplier still has his profit. If the
project exceeds budget, the
customer pays more, but the
supplier does not earn additional
profit. After the target delivery date,
the supplier may not invoice any
more profit, just cover his costs.
 Relationship: Cooperative - both
have a clear incentive to finish early.
The customer saves money and the
supplier has a higher profit margin.

88. “Money for Nothing, Changes
for Free”
 Structure: This works with agile
software projects because there is
little or no work in progress. After
each sprint, functionality is either
complete or not started. Work is
basically on a Time and Materials
basis with a cost target, often with
the intention that the project should
not use up the entire project budget.
After a certain amount of
functionality has been delivered, the
customer should realize that enough
business value has been realized
that further development is not
necessary and can therefore cancel
the project. A cancellation fee equal
to the remaining profit is due.
 Scope: can be changed. Planned
but unimplemented features can be
replaced with other stories of the
same size. Additional features cost
extra.
 Risk: Shared. Both parties have an
interest in completing the project
early. Customer has lower costs,
supplier has a higher margin.

89. Joint Ventures
 Tips: Treat the project as a
separate company: One team,
co-located, with development
and product marketing/product
owner role. Think realistically
about friendly and not so
friendly separation scenarios
 Structure: Two partners
invest in a product of joint
interest. Money is unlikely to
flow directly between the
partners in the development
phase, but each party must
have an ROI, which may
come from revenue sharing or
just benefits from using the
software.
 Scope: Defined to suit the
needs of the partnership.
 Risks: Two of everything.
Decision chains can get long.
Rivalries can develop between
the teams. Different models
for extracting value from the
product can lead to different
priorities differing willingness
to invest.

90. Sprint Contract
 Structure: This is not really a
commercial contract, but simply the
agreement between the Product
Owner and the Team for one sprint.
 Scope: The implementation team
agrees to do its best to deliver an
agreed on set of features (scope) to
a defined quality standard by the
end of the sprint. (Ideally they
deliver what they promised, or even
a bit more.) The Product Owner
agrees not to change his instructions
before the end of the Sprint.
 Risk: a Scrum project can be
considered is a series of mini
projects with fixed parameters: Time
(Sprint Length), Scope (Sprint
Backlog), Quality (Definition of
Done) and Cost (Team Size*Sprint
Length). Only the scope can vary
and this is measured every sprint.

92. 92
Observations
Mitigate
low
performance.
Performance
time
cutover
Reduce
time to
cutover.
Reduce low
performance
Period.
Continuously
increase
performance.
Such a business analyst’s or
developer’s toolkit would
server to:
– Shorten development
and maintenance
cycles
– Mitigate lapses in
productivity
– Shorten time of high
errors and omissions
– Support and improve
human performance
continuously
– Reduces the
complexity of business
processes as the
primary means of
improving human
performance

93. Evolution of Quality
Statistical
Quality
Control
Total
Quality
Management
Six Sigma
Business
Process
Reengineering
Ford
Production
System
Toyota
Production
System
Lean
Lean
Six Sigma
MRP,
MRP II
Supply Chain
ERP
CRM
Quality:
Productivity:
Information
Technology:
JIT
Lean
Six Sigma
Supply Chain
Source: Furterer 2004 (ASQ CQSDI)

94. 關鍵用戶評估
部門 關鍵
用戶
ERP
技能
溝通
技巧
設計
能力
工作
時間
工作
管理
學習
能力
AVG
銷售&市場 0.5 2.0 2.0 2.0 1.0 3.0 1.8
計畫.
訂單管理
0.5 2.0 3.0 1.0 1.0 3.0 1.8
採購 1.0 1.5 2.0 1.0 1.0 2.0 1.4
物流 1.0 1.5 2.0 1.0 1.0 2.0 1.4
計畫 0.8 0.8 1.0 1.0 1.0 2.0 1.1
專案管理部 1.0 2.0 2.0 1.0 2.0 2.0 1.7
製造中心 1.0 1.5 2.0 0.5 1.0 2.0 1.3
品質 0.5 1.5 2.0 1.0 1.0 1.5 1.3
財務 ALL 0.5 0.5 0.5 1.0 2.0 1.0 0.9
All AVG 0.8 1.5 1.8 1.1 1.2 2.0 1.4

95. APPENDIX
Software project management
framework
STRICTLY CONFIDENTIAL 95

96. Softoware Project Management
Framework
Engineering Institutional Leadership Communicati
on
Cultural PDCA Property system
for institution
design
Good Luck Nemawashi /
Democratic
centralism
Strategic Requirement
Modeling
Asset Based
Community
Development
Service
leadership
Trust circle
Tactic Application
Architect
Process
ownership
building
Situational
leadership
Directive
communication
Operational Application
Lifecycle
Management
Better process
design
MBO Moment Of
Truth
Personal Team Skill
Heart
Brain

97. 软件专案管理框架
工程 制度 领导 沟通
文化面 质量管理 产权制度 幸运学 民主集中制
战略面 需求模型 资产导向 服务领导 信任圈
战术面 方案设计 流程责任 情境领导 指导沟通
作业面 作业管理 流程导向 目标管理 情境表达
团体程度
用
心
程
度