IPD推行成功的关键要素（七）检查点的合理设计

（一）项目管理的三个重要概念

项目生命周期中有三个重要概念，分别是：检查点( Check Point )、里程碑( Mile Stone )和基线( Base Line )，他们一起描述了在什么时候( When )对项目进行什么样控制。

检查点：指在规定的时间间隔内对项目进行检查，比较实际与计划之间的差异，并根据差异进行调整。可将检查点看作是一个 固定采样时点，而时间间隔根据项目周期长短不同而不同，频度过小会失去意义，频度过大会增加管理成本。

里程碑：里程碑一般是项目中完成阶段性工作的标志，标志着上一个阶段结束、下一个阶段开始，将一个过程性的任务用一个结论性的标志来描述，明确任务的起止点。一系列的起止点就构成了引导整个项目进展的里程碑。里程碑定义了当前阶段完成的标准（Exit Criteria）和下一新阶段启动的条件和前提（Entry Criteria）。

基线：指⼀个(或⼀组)配置项在项⽬⽣命周期的不同时间点上通过正式评审⽽进⼊正式受控的⼀种状态。基线其实是⼀些重要的⾥程碑，但相关交付物要通过正式评审并作为后续⼯作的基准和出发点。基线一旦建⽴后变化需要受控制。

在实际项目中，周例会、月例会是检查点的表现形式，面向高层的阶段汇报是基线的表现形式。检查点时间一般会比较固定，检查的内容不确定，由高层管理者参与或在项目组层面进行操作，主要是检查项目进展情况、问题解决情况、进度偏离情况等。里程碑时间不固定，一般会根据流程和项目计划确定，是人为设置的项目进阶标志，在里程碑时间点需要对项目进行状态进行评审，检查项目是否达到了预期目标，从而决定项目走向，在里程碑节点，可以由项目组进行评审，也可以由高层进行评审。基线是项目进行到一定阶段或达到某一要求，可以作为下一阶段的工作基础，称之为基线，基线时间点的评审是由高层参与的决策性评审，决定了项目阶段工作是否达标，是否可以进入下一阶段或项目终止，任何影响基线内容的变化都需要走严格的变更流程。可以说重要的检查点是⾥程碑，重要的需要客户确认的⾥程碑，就是基线。

（二）IPD中的检查点/里程碑/基线

IPD流程可以说是项目管理方法论在产品开发项目中的具体应用，而项目管理是应用IPD流程所必需的管理技能和工具。因此，项目管理中检查点、里程碑、基线的概念对IPD流程的成功应用也是十分关键的。

在IPD框架中，检查点是不会在流程中体现的，而是通过日常管理机制来落实的。在企业中，项目启动后并不是把项目所有工作都交给项目组就可以了，管理要经常性的听取项目组的汇报，了解项目进展情况，对项目中出现的问题及时协调资源解决。在中小企业，可以设置项目组和管理层两级检查点，项目较多的情况下可以通过周例会来进行检查，项目不多的情况下可以设置双周例会或月例会进行检查。

至于里程碑和基线，在IPD框架中，其命名与项目管理中的概念有所区隔。在IPD框架中的将里程碑和基线细化为决策点（DCP）、技术检查点（TR）以及项目检查点，其中DCP是在各个点对项目投资进行决策，TR是在各个点对项目方案的技术情况进行检查，而项目管理检查点主要是基于保障于产品顺利交付的目的，从计划制定、供应链准备、生产制造准备、发布接单准备角度设置的检查点。从各企业IPD推行情况来看，DCP和TR设置一致性比较高，而项目检查点设置则差异性很大。对于基线，在IPD框架下，以计划阶段通过IPMT批准的项目计划作为基线，基线的内容包含了关键时间节点、技术方案、项目范围、成本等内容。

（三）IPD中的DCP设计

在IPD中设置DCP目的就是为了让IPMT在关键时间点基于事实进行决策，在风险可控时为下一阶段的工作提供资源及管理支持，在项目风险不可控时及时止损，保证企业效益最大化。

因受企业产品方案复杂度、运营模式等因素的影响，不同企业在开发流程中DCP的设置点、设置数量会有所不同，一般最少需要有4个DCP，多的可达8-10个DCP。在IPD流程中比较常见的是4DCP设计，即概念决策评审（CDCP）、计划决策评审（PDCP）、发布评审(ADCP)(替代原可获得性评审)、生命周期终止评审（LDCP/EOLDCP）。这些决策评审点并不是随意设置的，不同的决策评审点有不同的目的和意义。

• CDCP ：在概念阶段结束时要召开一个概念决策评审会上，PDT正式向IPMT报告正式版本的业务计划书，由IPMT来决定项目是继续还是终止。若得到批准，IPMT将做出下一阶段开始前所需的承诺，项目进入计划阶段。

• PDCP ：在计划阶段结束时，PDT应通过评估产品的市场机会、可能采用的技术和制造方法/风险，成本/预计开发周期以及财务情况来进一步明确产品方案，PDT向IPMT展示最终的业务计划书、产品规格等内容，由IPMT做出继续/终止的决策。

• ADCP ：这是产品在推向市场前的决策评审点，评估各个职能为新产品发布所做准备的情况，IPMT需要基于评估情况做出明确决策，是按计划进行产品发布、延迟发布还是项目终止。

• LDCP ：这是设置在产品生命周期即将结束时的决策评审点，由生命周期管理团体（LMT）根据生命周期管理计划、产品的市场绩效表现向IPMT提出产品生命周期终止计划和建议，并由IPMT做出同意/不同意的决策结论。

在实际执行中，并不是所有的企业都做的那么规范，都会花费很长时间为项目做Charter。有些企业为了保证项目质量，会把项目启动纳入决策点，保证项目启动前团队已经做了充分的准备，为项目的顺利执行提供保证。

针对一些大型制造业，产品切换周期长、切换工作复杂、对公司的经营影响大，这些企业会把LDCP进行拆分，拆分为EOM(End of Marketing停止营销)、EOP（End of Production停止生产）和EOS（End of service停止服务）三个DCP。

在实际项目应用中，一般全新复杂项目或全新业务模式下的项目，会执行所有的DCP，但对于一些简单项目、产品升级项目，项目启动DCP是没有的，CDCP、PDCP经常会合并，针对升级项目，LDCP一般会和以前的项目合并。

针对DCP评审，一般情况下是由IPMT作为评委，但有些企业因规模较大，一个IPMT下会有多个利润中心，为了保证决策的准确性、及时性，建议将DCP评审决策权下放到利润中心的负责团队。

（四）IPD中的TR设计

技术评审点、评审内容的设计与企业的业务特点、项目复杂度有直接的关系。一般来讲，最常见的IPD流程中会设置6-8个技术评审点，对于项目复杂度较低、创新性一般的产品项目，有时也可以设置4-5个技术评审点。其中比较广为接受的是7技术评审点方案，如下图所示。

• TR1：概念阶段技术评审点：方案需求和概念评审，这里需求包含了市场需求和公司内部的需求（DFX需求），评审内容包括：市场需求传递、可制造性、可测试性、可服务性等方面的需求

• TR2：计划阶段技术评审点1：需求分解和需求规格评审（功能需求评审，产品级规格），检查产品包需求到产品设计规格传递的完备性，是对产品规格和总体技术方案的评审，评审内容包括：设计方案的技术可行性、产品部件的重用度、产品目标成本达成措施的有效性、DFX（可制造性、可测试性、可服务性等方面的设计）、技术风险及应对措施。

• TR3：计划阶段技术评审点2：总体方案评审（系统设计，架构设计，概要设计），检查产品设计规格到概要设计之间的完备性。评估产品概要方案的缺陷；分析技术风险，形成应对措施；概要设计成本估算和产品目标成本对比。

• TR4：开发阶段技术评审点1：构建模块/系统评审（详细设计，BBFV测试结果），检查构件模块测试验证结果是否满足概要设计要求，该评审又被看作是SDV准入评审。

• TR4A：开发阶段技术评审点2：功能样机SDV结果和初始产品的准备情况，目标是确定功能需求已经得到满足，性能需求已经基线化，但在这个阶段性能需求未得到完全满足，该评审是SDV通过及SIT准入评审。

• TR5：开发阶段技术评审点3：初始产品的质量（SIT结果）评审，TR5目的是确保产品符合预定的功能和性能要求，已经具备批量生产的条件。该评审是SIT准出及SVT准入评审

• TR6：验证阶段技术评审点：量产评审（SVT测试、制造系统验证等），重点评估批量生产供应链的准备情况，包括生产工艺的成熟性、批量生产质量的一致性，确保产品生产能力能够满足供应要求。

7TR是针对技术链比较长的企业，在高端、复杂、全新产品自主开发的情况下的操作，绝大部分企业不需要做这么多的TR评审，即使做评审，不同类型企业评审的侧重点也会有区别。

TR1，针对OEM/ODM企业，就不用太关注市场需求传递，将重点集中在可制造性、可测试性、可服务性方面。针对升级产品，由于需求和综合方案变化不大，该评审可以省略。

TR2/TR3,针对品牌型企业，有众多供应商负责众多部件的开发工作，企业不需要过多关注部件层面技术的可行性，不需要给出特别详细的设计规格，更多的是关注系统层面综合方案的完整性、可行性，所以可以将TR2/TR3进行合并。

TR4，可只针对新部件安排，成熟部件可以不做TR4。

TR4A/TR5,针对升级产品，可以考虑合并。

TR评审一般由PDT组织，PDT核心代表或ITMT成员做评委，在实际操作中常见误区有以下几个：

• 所有TR的评委都是同一拨人，不同TR的内容不同，要安排不同的人员做评委，以便在项目中体现该业务部门的最高技术水平。

• 僵化的执行TR，把TR僵化为过点，使各个职能如临大敌、不堪重负，甚至出现为了过点而过点的情况。

• 忽略了TR的真正目的,TR的真正目的是为了借助行业、企业、业务内所有专家的力量，通过评审尽可能早、尽可能多的发现问题，并对疑难问题提供解决方案，为项目的顺利展开扫清障碍。因此TR评审要尽可能的客观公正，不要屁股决定脑袋，要以项目的成功为最终目的。

（四）项目管理检查点设计

虽然IPD的中文名称为集成产品开发，但近年来研发项目管理的焦点已经从开发转移到了交付，即项目的关注点已经转变为关注项目组最终是否能够按时交付满足令客户满意的产品方案。因此，在项目中处理要关注DCP和TR外，企业还需要基于业务需要、管理水平来设置项目管理检查点，以保证项目的顺利交付。

企业不同、业务不同，项目管理检查点的设置不同，下面以联想某业务的设计为例进行说明。

项目管理检查点在不同层级大大小小几十个，基本上可以分为业务级、项目级和职能级，职能级涉及太多细节，本文就重点介绍业务级和项目级的检查点。

业务级的项目管理检查点有两个EPR（Execution Plan Review 执行计划评审）和MDRR（Manufacturing Development Readiness Review制造开发准备评审），之所以称这两个评审为业务级的，是因为这两个评审是由PDT牵头安排，邀请业务部门内专家或公司内专家参加的评审，PDT各关键职能都要就项目情况进行汇报，重视程度远在各个TR之上，虽然级别没有各个DCP高，但邀请专家涉及面更广。因为EPR会对项目在计划阶段的工作是否到位、承诺的计划是否可行进行全面评审，要尽可能的发现潜在问题，因为EPR之后Plan Exit的承诺将作为项目基线来考核项目组；MDRR则是要评审SIT设计的稳定性及SVT准备情况，MDRR的评审结果将对SIT Exit产生直接影响，也决定了项目是否可由开发阶段转入到验证阶段。

项目级的项目管理检查点比较多，一般是由相关职能代表汇报，PDT团队进行评审，确认各职能相关工作准备情况。

• SCRR（Supply Chain Readiness Review 供应链准备情况评审），由制造代表进行汇报，确保可信需求传递和供应承诺的交付物状态。

• DSRR（Data & System Readiness Review 数据&系统准备情况评审），由营销代表汇报，确认数据和IT订单启用准备情况。

• MSRR（Marketing & Sales Readiness Review 营销&销售准备情况评审），由营销代表汇报，确认区域详细的市场营销和销售执行活动准备就绪。

• ……。

这部分内容和企业业务情况、管理水平、IT建设等相关性很高，各个企业的设计差别很大，不再一一介绍。

（五）小结

检查点设计是IPD框架设计的重要内容之一，直接影响IPD流程的可执行性及执行效率，在DCP、TR层面，可借鉴优秀企业的经验进行设计，但在项目层面要进行合理的裁剪；在项目管理层面，需要结合业务情况、业务管理水平进行设计。无论哪个层面的检查点设计都要避免僵化的照搬照抄。

一己之见，欢迎拍砖。