课程总体链接：https://apptu3z5hq71009.pc.xiaoe-tech.com/index

时长：59:40，讲师  黄良生

目录：   1.为什么需要SOW？   2.写好SOW的基础     3.评好SOW的标准    4.用好SOW的理念    5.课后思考总结

1.为什么需要SOW？

无忧交付金字塔：成就客户，成就用户，成就自我

SOW    vs    甩锅协议

举例：。。。99元香港一日游

有没有从头到尾的看过最新版的SOW模板？建议详细的看一下详细的SOW模板。

常见雷区：  口头，没有SOW，最佳实践，平滑升级，全面预算，流量不限，存储不限，蓝图与实施分家，满足管理所需报表，没有开发资源签开发项目。 首先不了解客户的业务场景

易出现风险的区域，需要既要懂开发，又要懂交付，还要售前介入。。。

实际上在项目实施中会有很多坑，如果缺少SOW的约定和机制，就很容易陷到坑里。

什么是SOW？

就是一种书面的程序化的东西，对项目目标、范围、服务进行明确的界定，明确了双方的一些责任，从而保障双方的利益，实现项目目标，保障项目顺利落地。

SOW的价值

控制项目成功交付，成本、时间、收益、风险、质量。既是一个项目经理的一个管理的基准，又是项目沟通的工具，又具有一定的控制功能，同时也具有营销价值树立专业形象，提升~

SOW的作用

实施方案和SOW的区别

• SOW属于从合同，用于和客户定义项目实施的责权和项目细节具有法律效力的文件，是未来项目实施过程的指导文件和争议解决依据。

• 项目实施方案，技术说明文档，用于向客户说明如何进行项目实施的文档，让客户了解实施方实施能力。

2.写好SOW的基础

• 以前的要求是10万以下用简版，现在是30万以下的项目用简版SOW。（需要关注下交付管理部的通知规定）

• 得有多份SOW优秀案例。

产品VS组织范围清楚， 功能模块明确，业务范围清晰。

• 注意不要按标准产品模块内容贴到SOW里面--实施要点内容说明。 如对全面预算的分歧。

你得懂版本管理

1.     SOW可能由不同领域的顾问一起完成

2.     SOW需要多次反复修订

3.     SOW需要与客户多次互动

4. 版本管理一般原则   .V0.1 与客户达成共识  | .V1.0经过跟客户（外部团队）进行过一轮评审之后的结论  |Vx.y.z   X跟甲方达成>Y乙方内部>Z自己调整

SOW的导入

• 由谁来编写

• 什么时候介入  

SOW输入-业务需求及产品差异分析表

业务需求及产品疲累差异分析表，结合相应课程的实例，要以客户的语言清晰地描述出客户的业务场景和需要。

工作底稿：业务需求及产品匹配差异分析表与WBS关系

层层递进，相互分解逐层分解的一个关系。WBS并不是简单的按照实施方法论进行展开。

WBS制作关键点

• 向下分级，阶段与子阶段

• 工作包及交付策略

• 工作间逻辑关系

• 每行分解到单一工作

• 每行工作最多五天

• 每行工作对应交付物

• 每行工作仅对应一个人

• 人按级别分工

WBS是项目经理对项目进行的一个系统性的思考，人天也是由WBS进行输出。

WBS可以回答SOW中的4W2H[不包含为什么]

工作底稿：WBS的价值

• 到底花多少钱正确？ 通过WBS确定到底是是项目要花多少人天，进行准确估算。

• 实施人天如何构成？ 通过WBS清晰展现人天构成，想客户讲清楚为什么每个工作包需要这么多人天，明明白白。

• 金蝶是否有实施能力？通过WBS专业向下分解技术，展现出金蝶项目实施的能力，证明金蝶不是随意报价欺骗客户。

工作量人天评估方法   [怎么算都不准确]

• 概算-人天计算器         

• 预算-资源配备RAM

• 预算-WBS估算

• 回测-历史人天/百万

工作底稿：WBS自下而上评估人天。  按WBS展开，由最底层逐层进行评估后加总。

工作底稿：WBS资源计划及交付成本评估

工作底稿：资源配备计划表（RAM）

小结：SOW结构-8要素

3.评好SOW的标准

报给总部评审的时候，是需要暴露出项目风险。

SOW评审常见问题

• 交付组织范围不明确。   如公司名称是XXX公司实际是集团性公司。

• 过度承诺，客户化开发范围不可控。  提供个性化报表-不限个数，

• 过度承诺，交付风险不可控。  确保XX与Oracle ERP及XX软件成本计算逻辑一致

• WBS颗粒度太粗。  超过5人天的颗粒度已经很粗了。 如项目启动会就1人天。项目的任务分解的不够细，

• 把握SOW评审时机，客户评审完后就比较被动。   相关文档内部分有，部分没有。

• 需求的边界不清晰。 如报表的数量。

• 方案的技术性、真实性。

SOW评审要求-SOW审核八重点

• 需求是否清晰

• 技术是否可行   并不是所有东西都可以做，考虑瓶颈

• 范围是否明确   如开发范围，

• 资源是否合理   是否有关键资源，一定要分到角色，要配备相应级别的顾问，

• 成本是否准确   依赖于SOW等一系列相应的文档。

• 风险是否识别

• 验收标准明确

• 文档是否达标
  

SOW其他评审要求：

• 针对业务需求及产品匹配差异分析表

• 针对WBS资源计划及交付成本评估表

• 评审SOW（SOW是具有法律效力的，实施地点要具体明确，不能是某某客户的总部办公室，组织和模块，开发等）
  

• 评估项目损益表、合同。    合同-PMO审核交付解决方案风险  [需求看得清，成本估的准，利润有保障]-合同边界清晰-[过程可控制，结果可预测，成果可衡量]

4.用好SOW的理念

甲乙方理解项目管理六重约束条件

• 范围基线-实施主体、产品模块、业务范围、报表范围、客户化开发、接口及培训范围。

• 成本基线-实施人天、人天成本、差旅费及其他相关费用

• 进度基线-计划开始日期，计划完成日期，里程碑事件

1. 质量关系到客户的预期期望，到验收。

2. 顾问的人天一经发生是不可逆的。

SOW是ERP实施的基础

VBS-WBS-SOW的价值

完整的体系，如果在商机推进过程中使用VBS-WBS-SOW，有助于

• 完善与确认客户价值主张，书面化验收标准。

• 提升项目价值（客户预算），增加利润 ，

• WBS有助于价格谈判。 

• 清晰界定项目边界，快速达成SOW，  

• 提升双方执行力，增加甲方的资源投入。   

• SOW是项目交付策略、能力、方法、资源等方面的承诺。

总结：以客户为中心，做最值得托付的顾问

与客户共同成长。

5.课后思考总结

对SOW、WBS、项目实施人天估算错误的后果有哪些？

• 不能按期向客户交付项目，影响客户对项目预期的时间安排，客户预期的项目上线的价值。

• 内部实施顾问资源调配出问题：因错误的估算计划，导致新项目无法按时开始实施。

• 如人天估算较少，易导致项目成本超出预估。

• 偏差较大的人天估算，会导致项目报价不准确偏低，不能保障利润。

• 实施人员的技术能力及顾问资源支持不足对项目交付的影响。

----------------------------------------------------over-------------------------------------------------------------------

END

优秀的SOW会经常需要在售前阶段投入大量工作成本，在负责程度高的项目甚至影响销售合同的签约，需要很好的去把控这个点

优秀

圣人之心