前面我们介绍了在管理层和执行层，产品开发和供应链管理如何打通。人员的复用、有效的沟通确实能够有力地促进产品开发和供应链之间的合作，但一旦出现人员变化等情况，这种好不容易建立起的联系似乎就不那么牢靠了。因此除了以上两点之外，流程也是一项研发与供应链结合的重要保障，它把研发和供应链合作的管理规则确定下来，让正确的做法得以重复，而不再因人而异。

我们在第三章中介绍了结构化的研发流程。结构化的流程清楚展示了产品开发的全过程和关键节点，让产品开发的核心小组能清楚地了解需要做什么、做事的先后顺序和合作的关系。

成熟的企业，在研发流程运行一段时间后，通常会根据一般耗用时间，制定出产品开发的参考时间周期，相当于给产品开发提供一个参考时间。这种时间周期参考不一定是唯一的，一家公司的产品如果非常复杂，也可以存在若干个时间周期参考。时间周期参考可以辅助核心小组制定出更可行的项目计划，并通过项目间竞争，不断探索发现缩短研发周期的新机会。

在供应链管理中，对时间周期的要求也很高。供应链的主要目标之一就是按照市场需求以最快的速度实现生产和交付。但在供应链的实际运作中，存在诸多限制条件：原材料采购从下单到收货需要有一定周期；工厂的产能有限；除此之外，生产加工、运输也都有一定的周期要求……这些限制条件通常被称为供应约束。

在科技行业中，普遍存在的、制约产品生产的供应约束是采购周期。因为在一项新产品开发中，研发总会对一些器件、模组等进行定制，研发设计要求被传递给上游的供应商，请他们按照定制要求供应物料。这些物料的采购周期通常比较长，如果在这个过程中出现设计修改，供应商也需要随之修改。这样在一来一往之间，采购周期就会被拉得更长。而产品的生产，往往因为等待那一两个关键的定制物料到货，而被耽搁延误。

产品生产如果是因为这样的原因被延误，往往会导致研发和供应链之间的一场“内战”。研发责怪供应链不能及时把物料采购回来，影响了项目的进度。而供应链则责怪研发一而再、再而三地修改设计，让采购周期变得难以控制。

类似这种矛盾就可以通过在制定产品开发的周期时间时充分考虑采购周期约束，得到一定的缓解。每个公司一般都会对产品开发流程中的关键里程碑设定开发进度有明确要求，比如，在某个技术评审之前，产品必须经过样机测试；在产品上市之前的一段时间内，产品必须经过小规模试产。

通过从这些关键里程碑时点倒推关键物料的采购周期，就能推导出研发最晚在什么时间必须锁定设计、确认物料，否则将导致整个研发周期的推迟。这样一来，公司就可以根据采购周期和产品开发的时间周期参考来调整产品开发流程。如果一项开发步骤结束时，预留到关键里程碑的时间不足以完成采购，那么这项开发步骤就需要更早地开始，以保证在产品生产之前，所有物料都能到货。

把供应约束反映到研发流程中，能够提醒研发在确定的时间点必须完成开发任务，也能提醒供应链在这个时间点必须启动采购。这样的做法能够强化产品开发与供应链的融合，培养了彼此的默契，还能使产品开发周期越来越合理，产品上市时间越来越接近预期。

实战案例：链接产品开发与供应链管理

我们曾帮助一家消费电子产品公司同时实施培思和SCOR，以实现其产品开发与供应链的端到端改善。

这家消费电子产品所处的行业竞争非常激烈，行业内产品更新换代的速度非常快。一个新产品上市后，销售旺期只有前3个月，而上市6个月后，产品的生命周期就接近尾声了。

然而，这家公司的产品几乎在上市时都遇到产品开发与供应链协同的困难。通常在上市的第一个月，新品生产的良品率总是偏低，珍贵的销售旺期就这样白白错失了约1/3。(www.daowen.com)

在对这家公司进行全面诊断之后，我们发现，无论在产品开发还是供应链管理方面，公司都存在着许多问题。不仅如此，公司在产品开发与供应链之间的链接也相当薄弱。这种薄弱既出现在管理层，也出现在执行层。

以这家公司的一个业务单元为例，业务单元的职能部门管理者都在各自的专业领域富有经验、充满活力且尽心尽力。当他们在发现产品上市存在问题时，会主动牵头与其他职能部门讨论，以期尽快将问题解决。然而，我们发现，参与讨论的部门具有很大的随意性，每次都不太一样。一方面，发起会议的部门仅仅根据经验判断来邀请参会部门，另一方面，受邀部门有时会因各种原因而未能出席。

业务单元的许多重要决策正是通过这种方式做出的。例如，一款重要产品开发到一半，但由于某部件出现供应短缺，产品和采购通过讨论决定替换成另外一种部件。这个决策做出之后，并没有及时通知到质量和生产，导致原来设定的测试方案已经不适用，样机生产过程中的组装要求没有做相应的调整。测试进度因此延期40%　～　50%，最终导致项目试产时间不足，工艺验证不充分，一些质量问题一直遗留到了量产还没有得到妥善解决。

后来，我们建议该业务单元成立产品审批委员会（PAC）和产销协同委员会（S&OP委员会），这两个组织作为产品开发和供应链管理中唯一的官方决策渠道。通过固定的跨职能委员会成员构成及会议制度，提升管理和信息的透明度，把决策放到桌面上，以加强配合和协作。

管理层对这种集中决策的形式表示支持，但也有部分管理者仍存在顾虑。他们认为集中决策虽然好，但可操作性差。他们没有时间参加那么多的会议，而且如果他们定夺不了，还要等到公司一级的最高决策委员会来拍板，时间未免拉得太长。

为了打消这些顾虑，我们帮助这个业务单元清晰设定了PAC和S&OP委员会，两个委员会按照职责范围确定虚拟团队人员，只有主管产品、供应链计划和市场的负责人需要同时出席两个委员会，做到两个委员会的信息互通和决策方向一致。

除此之外，PAC和S&OP的会议频率和时间也被规范化了。两个委员会的会议被有意地规划在了每月同一天的上下午，而公司级的最高决策委员会会议则放在此后的第二天，以便及时决策前一天讨论中未决、需要上升的事项。这样紧凑的安排下，管理层就能更好地安排自己的日程，大家都默契地把固定会议的时间提前空出来，参与到集中决策中，管理效率大幅提升了。

业务单元管理层也同时制定了临时会议召集办法，来管理两次会议中可能出现的紧急事项。但在一段时间后，通过固定频率PAC和S&OP委员会的会议，许多风险被跨职能的委员会提前识别出来，紧急事项越来越少了，临时会议只是非常少见的一种情况。

同样在这个业务单元，执行层在长期产品开发与供应链不对齐的情况下，摸索出了一套“特色”的工作方式。过去在产品测试中，物料很难按照预期的时间到齐，所以项目团队会把一次完整的测试拆成若干小测试，到一部分物料，测试一部分。这种片面的测试结果，总在量产时带来意料不到的问题。

因此，我们把这个业务单元的研发和供应链业务骨干们召集在一起，共同梳理了产品开发步骤的周期时间参考以及关键物料的采购周期，并确认了嵌入在产品全生命周期中关键里程碑的准入条件。根据这些要素，这个业务单元的第一张附带时间要求的产品开发蓝图被制定出来了。产品的研发时间周期非但没有拉长，反而在将一些串行步骤改为并行之后，有所缩短了。

一位来自供应链的业务骨干看着这份工作成果，感慨地说，“我原来从来没有想过，在项目前期，我就需要开始参与到产品开发的过程中了！”

在通过管理层和执行层双管齐下的改善后，这个业务单元的新产品的试产测试更加全面了，新产品导入的效率和量产的良品率都有了极大的提升。在新产品上市的第1个月，缺货率从90%以上，显著下降到了30%以下，销售机会不再像原来那样，白白地从眼前溜走了。