“管理信息化热点问题讨论”之七：CPC：不该冷清的多汁橘子（by AMT 张蓬 廉奇志）

摘要：CPC，产品协同商务，又是一个新的三字经，其实就是产品数据管理PDM的高级版本，跟MRP摇身一变成了ERP一回事儿。

在本文中，您将了解到：

CPC是不是PDM的简单WEB化？
为什么有人说ERP是做20%的文章，CPC是做80%的文章？
非制造业如何借助CPC实现协同高效？
协同产品开发的组织结构设计，有哪四部分组成？

“管理信息化热点问题讨论”之七：CPC：不该冷清的多汁橘子

by AMT 张蓬 廉奇志

“知道CPC吗？”

“知道，CPC（Collaborative Production Commerce），产品协同商务，又是一个新的三字经，其实就是产品数据管理PDM的高级版本，跟MRP摇身一变成了ERP一回事儿…”

――摘自AMT社区BBS论坛

与ERP与CRM的一片热闹相比，CPC多少显得有些冷清，在专业网站google上搜索CPC，和协同产品商务相关联的真正有价值的链接寥寥无几，好不容易碰到一个承认“知道”CPC的同业像前面这位，还给CPC扣了顶不甚光彩的帽子，CPC果真就是PDM的WEB版本吗？

撇开定义看场景：这样的产品研发与生产

场景1：马来西亚，某手机制造厂商的制造工厂。

这一天，马来西亚该工厂的制造工程师发现，生产出来的手机存在一个问题，按键的高度太低，不仅手感不好，而且会对手机拨号时的按键效果带来影响。问题确认以后，该工厂立即决定停止继续生产该型手机。

问题出在哪里呢？制造工程师开始通过计算机系统进行检查，返回的信息显示，手机按键的料号无误，但实际尺寸和说明尺寸却对不上。制作工程师开始思考，如何在这种情况下，如何用最小的代价恢复生产，并防止类似的问题再次发生。

制造工程师通过计算机环境给远在欧洲的研发工程师发了一条信息，请求帮助。

场景2：美国，该手机制造厂商的研发中心。

美国的研发工程师接到了这个信息，他开始通过计算机系统查找产品设计信息，相关的记录，结果发现问题的原因其实是供应商发放了错误的零部件，设计中的高度正确的，而供应商提供的零部件上的按键高度不足。研发工程师想到一个救急的方法，即通过加一个垫片来抬高按键的高度，但同时又担心可能会引发手机散热的问题。究竟是可行还是不可行？研发工程师继续在“知识库”中查找，看加个垫片的方法是否在其他情况下使用过。查找结果显示，使用这个方法确有先例。

于是，研发工程师描述了详细的解决方案并反馈给马来西亚的制造工程师。制造工程师接到这个解决方案，也认为方案确实能解决问题且付出的代价最小。于是，他发出正式的工程设计变更单，通过“工作流系统”，以任务列表的形式将变更任务指派给研发工程师，而研发工程师据此正式更改这个批次手机的BOM，继而制造工厂的ERP系统相应展算物料需求等。终于，一个停工事故得到了较好的解决。
场景3 中国，该手机制造厂商的集中采购中心。

故事还没有结束，这个事故的原因在于供应商的失误，为了杜绝以后此类事件的重复发生，研发工程师给中国的采购经理发去建议措施。中国的采购经理经过调查，认定确实是供应商一方的质量监控流程出了问题，根据规定，该供应商的级别需要降低，在供应商管理模块记录在案。
并不惊天动地，在上面自然发生的工作流转背后就是最早由美国Aberdeen Group咨询公司在1999年10月提出的CPC （Collaborative Product Commerce，协同产品商务，是“指一类软件和服务，它使用Internet技术，使每个相关人员在产品的全生命周期内互相协同地对产品进行开发、制造和管理，不管这些人员在产品的商业化过程中担任什么样的角色、使用什么计算机工具、身处什么地理位置或处在供应链的什么环节。”

其实，你知道CPC

CPC的由来不是到了1999年才从Aberdeen那里横空出世，从图1可以看出，CPC是很多我们熟识的概念的“殊途同归”。

图1 CPC概念的演变路径（来源：企业资源管理研究中心AMT）

图1给我们梳理出了两条清晰的主线，一条线是由软件供应商所驱动的从计算机辅助设计到产品数据管理、第二代产品数据管理（虚拟产品开发管理）再到协同产品商务的演变路径，这个路径从软件系统的角度形成协同产品商务概念并为协同产品商务模式的建立提供了可能性和必要的支撑。另一条主线是由学术界和管理界所驱动的从并行工程（concurrent engineering）到集成产品开发（integrated product development）再到协同产品开发（collaborative product development ）的演变路径。这两条主线在发展过程中相互交缠在一起，相互促进，共同发展，成了今天看似崭新的CPC。

为了更直观地把握CPC理念形成历程及其特点，我们通过表2对CPC及其前身CPC与PDM、PDM II进行了比较。

表1 CPC与PDM、PDM II 的特点比较

不该冷清的多汁橘子

有这样一些火爆的数字，“FMC公司是世界领先的化学和制药公司，其下属的能源输送集团在实施CPC系统之前，订单交付时间是18~24个月，在实施CPC系统之后，这个数字降低到3~4个月”；“洛克西德.马丁公司在实施CPC系统后，流程效率提高了30%~50%”；“宝马公司在实施CPC系统后，成功地将产品开发时间缩短了30%”。

这些国外企业通过实践发现，CPC可以帮助企业实现以下目标：

帮助企业建立跨企业的协同设计环境，实现产品的协同开发，支持异地设计、异地制造战略的实现；

提高设计重用率，产品的多样化（大规模定制的前奏）已成为一个活生生的现实，然而产品多样化很容易导致零部种类的急剧攀升，最终是企业现在成本过高的泥潭中苦苦挣扎，提高设计重用率是解决这一问题的关键。

尽可能地使设计变更提前，在设计变更一定会发生的前提下，提高设计变更过程的效率，从而在成本和效率上对企业有相当的贡献；

提高企业知识管理的质量，知识已成为企业的生命，对企业而言，最有价值的知识就是产品的知识，CPC的实施将有效地帮助企业实现对产品知识的管理从而积累企业的核心竞争力。

支持大规模定制战略的实现，目前一些主流的CPC厂商纷纷推出支持大规模定制的模块，使传统意义上很难实现的大规模定制得以实现。
于是，据估计在美国对CPC系统的投资将在2005年首次超过对ERP的投资，相形之下，国内CPC着实有些冷清，原因多方面的：我国的企业信息化建设还停留在比较初步的阶段，企业竞争的压力首先使产品的制造环节更容易受到关注，同时，一些“了解”CPC的CMIS专家们总是倾向于用技术语言描绘CPC，不少人将CPC局部地理解成是一个技术问题。

这样一些数字提示我们没有理由因冷清而忽视CPC的重要：

产品开发（产品全生命周期中生产以前的阶段）的占据成本（指在产品开发过程中，企业花在开发部门的相关费用）虽然只占产品全生命周期成本的不到20%，但产品全生命周期成本的80%是在产品设计阶段决定的。

在产品开发过程中修改错误的成本随着产品开发阶段的推进会有巨大的变化。有资料表明，如果在设计阶段修改一个错误需要花费1000元的话，在设计检验阶段这个数字上升至10000，在流程规划阶段则上升至100，000，在试验生产阶段数字又扩大10倍。

对象汽车、飞机、计算机这样的复杂产品来说，供应商贡献了产品相关成本的40%~80%。

因此，听到这样的说法，尽管通过实施ERP、SCM等系统确实能够有效的降低产品的成本，加快产品的上市时间，但不要忘记这一切发生变化的范围是在20%以内，对产品开发领域的改善却在80&的范围内赚取更多的利润。这好像是一个选择题，一个干瘪的橘子、一个多汁的橘子，你榨那一个？有些偏激，但揭示了一个巨大的企业改善的空间。

不是制造业，也能CPC？

向十个知道CPC的人问起CPC的应用范围，其中估计八九个人的答案都认定是制造业。细细梳理CPC理念和技术的演变过程也会发现，今天CPC的供应商的确大多起家于为制造业提供CAD工具的软件供应商——似乎，CPC天生就打上了制造业的烙印。那么，CPC是否就不适用于那些非制造行业的企业呢？答案是否定的。我们来看看下面这个真实的案例。

国内某地铁公司成立于20世纪90年代初期，具有追赶世界领先地铁公司的远大目标。1999年，该公司在咨询机构的协助下，制定了公司的组织机构设置方案和业务改革改革方案。2000年，组织在企业战略目标和业务管理流程的基础上，对公司信息系统进行现状分析和未来规划，同时制定管理信息系统建设的方案。

根据规划，该地铁公司的管理信息系统是一个包含ERP、CPC、PM、CRM、EIP在内的综合复杂系统，各部分将分阶段逐步实施。之所以要开展CPC系统在地铁建设行业乃至建设行业的首次应用，是源于企业运营中的真实之痛。

熟悉地铁行业的人都知道，地铁建设周期动辄几年，投资额达到100亿元人民币量级，从管理的角度讲，有效地控制项目投资和缩短工程建设周期是两个非常重要的目标。一次完整的建设，包括了设计和施工两个部分，历经预可行性研究、工程可行性研究、总体设计、初步设计、施工图设计、施工等各个阶段，需要土建、电力、通信、机车、消防等不同专业的有效配合，参与者涉及业主、设计单位、施工单位、设计咨询单位和施工监理单位等各方主体，其中，业主（地铁公司）起到整体协调和项目管理的作用。自然，这里问题来了。

首先是众多的参与者如何实现协同。我们来看看这个链条，设计单位形成设计成果→设计咨询单位进行审核→业主审核→施工单位，不同的参与者并不是一对一的简单上下游关系，而是意见不断交互、会同讨论，形成了错综复杂的网状结构。在进行信息系统规划与建设之前，设计成果的转移和协调是手工完成的，一方面设计成果的传输物化过程效率低下且很容易出错，需要付出大量额外的工作量来提高数据在整个过程中的一致性；另一方面，设计成果在物化的过程中需要经过多次的反复修改，而每一次反复几乎都需要牵扯到不同的单位，时间延迟的同时费用也根本没有节省。

其次，设计单位在设计建筑图纸时每天都在产生大量格式化图纸和技术文档，特别是采用CAD技术之后，由于设计人员可能分属不同的专业，以及设计活动的分散性，使信息常以不同的格式和介质地存储在不同的部门，由此产生了大量的异构数据。如果一直延用原来的手工管理维护方式，不仅会占用大量人力资源和空间资源，工作效率也非常低下。

尽管建设行业的几乎每一个企业都存在这些问题，但因为问题普遍存在就听之任之并无助于问题的解决。该地铁公司经分析讨论后达成共识，地铁设计与建设也是一个典型的产品协同过程，尽管具体的产品（地铁系统）和离散制造业并不相同，但在管理上有很多类似可借鉴之处，于是，决定在信息系统的建设之中上马CPC，并通过招标选型选择了具体的CPC产品。

建设CPC系统之前，该地铁公司先先花了一番力气理顺设计过程，到了CPC建设的解决方案设计阶段，围绕地铁运营特点，强化工程设计环节的规范的项目管理机制，从文档管理、工程设计变更管理和BOM（物料清单）管理等三个方面来深入研究，形成并实施了相应的方案。在这之前，尽管各方面的业务人员都很熟悉和自己相关的那一部分业务过程，但却很少有人完整地了解设计的整体过程以及设计和施工的衔接全貌。通过“理顺”，地铁公司的相关人员第一次静心坐下来，来全貌地分析探讨，甚至于公司老总在一次会议上反复两次说：“改革两年多来，今天眼前一亮……”

实施结果表明，CPC系统能有效解决该地铁公司在业务上碰到的问题，有效提升了工程设计和施工过程中的传输效率。另外，大量文档实现共享以后，促使问题和缺陷能够及时发现，降低了工程变更的频率并使工程变更尽可能地向设计的上游移动，最终降低变更带来的成本和时间花费。

由这个地铁的例子扩展开去，我们把CPC的典型应用领域概括为：

大型复杂产品研制企业

软件开发公司

各类专业设计院所

设计制造系列产品的企业

跨地区、跨国界的研发生产企业

中小型制造类企业

含有大量数据或信息以及复杂流程的应用场所，如银行、海关、码头、政府、学校等

榨汁之难，难在CPD

表1中的“跨企业协同”、本文开头的跨国场景，说起容易做起难，细究一下可以发现，CPC的“协同”有三个维度的协同：

首先是时间协同，我们知道，一个完整的产品开发链包含市场策划、概念、设计、测试、试制、大批量生产等不同的阶段，在不同的阶段，不同的专业人士将使用不同的工具对不同侧面的产品知识进行处理。CPC则使这些分散的知识通过一个统一的模型串了起来，从而在时间上打通整个产品开发链，最终有助于降低产品开发时间。

其次是空间协同，在产品开发和生产的不同阶段有着不同的协同对象，就像本文开头的场景中研发工程师和制造工程师就身处异地，协同的对象也可能超出了本企业的范围，如场景中提到的供应商。CPC借助internet，使这种协同成为可能。

然后是应用协同，不同的企业可能会采取不同的生产制造模式，如按库存生产、按订单生产、按订单设计等，不同的模式就需要不同的软件解决方案，而CPC足够灵活，能够支持不同的生产模式。

是不是只要实施CPC系统就可以这样“协同”起来？答案是否定的，问题很容易就出在“人”身上，系统再好，没人协作怎么办？

国内某知名电信设备制造商就碰到这样的问题。该公司在电信市场已开始进入高度竞争的状态下，战略上将产品开发能力作为核心竞争力。然而尽管该公司有大量优秀开发人员的储备，但在产品开发上就碰到了很大的障碍。障碍之一是技术人员、管理人员分别形成两张皮，相互抱怨，更不要谈高效的合作；障碍之二是由于管理的缺位，造成产品开发的进度、经费往往严重失控；障碍之三是有些人员无所事事的同时感到关键资源往往不足；障碍之四是决策效率低下，等决策出来时可能已经错过市场先机。

他们需要的不仅仅是技术，而是协同的产品开发（Collaborative Product Development）体系，简称CPD。协同产品开发体系是构建协同产品商务模式的核心，而协同产品开发组织又是协同产品开发体系的核心，没有相应的组织结构的支撑，协同产品开发体系中的各种管理要素，如决策、项目小组、开发活动的结构、开发工具与技术、产品战略过程、技术管理、管道管理都无法得到充分的体现。限于篇幅，下文围绕协同产品开发组织的特征和设计要点来进行阐述。

在协同产品开发体系中，围绕产品开发过程中的不同职能，组织结构模型中共包含以下体系：决策体系，项目体系，监理体系，支撑体系，如图2所示。具体地：

决策体系 在产品开发的过程中需要不同的决策，如站在整个企业组织高度的产品战略决策涉及：企业组织在几年内的产品开发的方向和范围如何？基本的产品平台如何选取？站在产品线的高度的战术决策涉及：属于该产品线的某一具体项目是否在必要的决策控制点通过评审？是否继续该项目的进程？如何为各项目分配资源，从而优化关键资源的使用？

项目体系 产品开发工作需要由具体的组织来承担。项目体系就是企业组织内部完成产品开发的主体。项目体系需要包含完成项目的各个层次的单位，不同层次的项目体系单位涉及到的项目范围也不一样。

监理体系 组织设计的一个重要原则就是责、权、利对等。接受权力分配的同时也就意味着必须接受监督，否则只会带来权力的滥用，CPD组织体系也不例外。企业最高层次的权力监督是通过法人治理结构来实现的，对产品开发单位，即项目体系的监督则是由监理体系来实现的。
支撑体系 在协同产品开发组织中，项目体系是一个动态的组织，具有清晰的生存周期，比如，项目体系中的项目组会在项目结束后解散。同时，项目组还具有交叉职能的特性，在新项目到来时将从各专业职能部门中抽取不同专业的人才组建项目组。这些职能部门和各种管理职能部门共同构成支撑体系，用于为项目体系提供各种支撑作用，成为项目组织解散之后人员的归属。

图2 协同产品开发组织的结构模型

在图2中，战略与产品决策委员会和产品线管理团队（PLMT）共同组成决策体系，战略与产品决策委员会、产品线管理团队、产品开发团队（PDT）和专业研发体系构成项目体系，专业研发体系和管理职能体系构成支撑体系。这样，在这些体系中，支撑体系为项目体系和监理体系提供服务和资源，项目体系根据资源的提供情况反馈意见据此作为部门考核的依据。监理体系负责对PDT进行财务和质量方面的监督。监理体系将监理结果汇报给战略与产品决策委员会并接受它的领导。战略与产品决策委员会领导产品线，对企业一级的战略和产品战略做出决策。战略与产品决策委员会还接受产品线管理团队的工作汇报并在一定周期内考核产品线管理团队。产品线管理团队领导PDT的工作，做出产品线一级的决策，监督并考核PDT的工作。

产品开发中的“各就各位”

在上面几大体系中，处于核心地位的是矩阵式的项目体系，它体现了协同产品开发的基本特征。项目体系共分为三个层次：战略与产品决策委员会、产品线管理团队和PDT。这三个层次的组织都具有跨部门的特性，分别是协同产品开发中不同要素的主体。例如，战略与产品决策委员会是产品战略过程的主体，产品线管理团队则是管道管理、技术管理的主体，协同产品开发团队当然是产品或技术开发的主体。下面分别说明这些不同层次的具体功能与特性，以便于相关人员“各就各位”。

战略与产品决策委员会

和科层制组织结构不同的是，协同产品开发体系中的最高决策体系不再是总裁、副总裁等职能部门，而是采取团队特征的战略与产品决策委员会。企业组织的行政领导通常是这个团队的成员，但这个团队不仅仅是由这些高高在上的领导者组成，它可能还包括企业内部的某些资深专家，也可能来自工业界的其他独立人士。具体说来，战略与产品决策委员会成员包括主管市场、财务、销售的副总裁、产品线经理、投资商等，其团队领导通常由企业组织负责人担任，如总裁。战略与产品决策委员会具有以下职责：

制定公司产品战略，对公司的经营业绩负责；

确定产品线的优先顺序和业绩目标，并提供必要的保证条件；

可根据公司的发展战略对产品线进行决策（继续、下马或转向）；

确定产品线经理人选，并授权产品线经理组建产品线管理团队，审核产品线管理团队成员的资格；

企业组织内部质量体系的建立和维护；

由于要对企业的战略与重大决策负责，为了保持战略的稳定性，战略与产品决策委员会的任期相对固定，存在的周期也要长一点，因此可以认为这是一个常设机构，尽管这并不意味着这个团队是一个静态的部门。

产品线管理团队

产品线管理团队由战略与产品决策委员会授权组建，在产品线终止时解散。实际上，在前面的介绍中已经提过，产品线管理团队是决策体系的一个组成部分。产品线管理团队在组建时就被授予了相当大的权力用以支配相当的资源。具体说来，产品线管理团队有以下的职责：

在产品线的整个生命周期内对产品线的业绩负责；

在产品线内项目的里程碑进行决策（继续、下马、或转向）；

确定产品线内的项目经理，并授权项目经理组建项目组，并审核项目组成员；

产品线管理团队由市场、研发、财务、项目管理、生产等方面的资深人员组成，协同完成对产品线的管理，该团队的负责人为战略与产品决策委员会任命的产品线经理。

协同产品开发团队

项目体系的第三个层次是协同产品开发团队，协同产品开发团队归属于某一产品线，在决定一个新的产品开发或技术开发后，产品线管理团队将任命一个项目经理，然后项目经理从专业研发部门和支撑部门内部遴选具有不同专业背景的人员，组建一个跨专业的协同开发团队。产品开发成功后进入产品管理过程，此时产品开发基本告一段落，CPT将解散。CPT成员的专业背景应当涵盖产品价值链的从市场、科研开发到生产制造、销售与服务的每一个环节。

在产品开发的不同阶段，需要介入的人员也会有所变化。表2显示了这种变化：

表2 产品开发不同阶段CPT的人员构成

随着产品规模的差异变化，CPT会略有一些变化，规模大的CPT还会区分为不同的层次，如核心小组和外围小组。核心小组的成员是CPT的稳定成员，基本上由相关资深专业人士组成，它为项目作出决策，如计划的制定、资源的分配等。外围小组成员执行核心小组的各项决策，并辅助核心小组成员作出决策。例如，在产品开发的概念阶段，需要对用户需求有大致的了解并评估市场范围。这需要大量的调查、分析工作，这些工作基本是由核心小组中的市场人士领导外围小组成员完成。

在CPT中，项目经理是非常关键的人物。成为合格的项目经理需要一定的专业水平和经验，还需要具备相当的沟通能力。CPT中的项目经理主要有以下职责：

解决冲突

制定项目计划及预算

开发成本控制

开发质量控制

人员调配和各类资源需求满足

跟踪项目合同

提供项目情况

提供对项目组成员的工作绩效评审的输入

协调决议检查点

解决计划和职能部门之间的冲突

除了决策体系和项目体系外，协同产品开发体系还包含这两个体系：支撑体系和监理体系。这两个体系基本上体现了职能分工的特点，如果说决策体系和项目体系因为具有团队特征因而可以称之为“动态体系”的话，支撑体系和监理体系可以称为协同产品开发体系中的“静态体系”组织。除了正常的员工流动（招聘、员工辞职或调动）外，这两个体系中的人员基本不会发生变化。这两个体系基本上不直接承担与产品开发相关的责任，但对产品开发起着制成作用。

支撑体系包括两种类型的部门：业务部门和职能管理部门。业务部门和价值链相对应，例如：市场部门、专业研发部门、客户服务部门等等。职能管理部门和价值链没有直接关联，但他们为企业内的其他部门或体系提供必要的支撑作用，没有他们的支撑作用，其他体系和业务部门很难进行高效的业务工作，想象一下，现代企业没有网络管理部门会发生什么样的情况？我们很难清楚地描述出每一个支撑部门的具体职责，不同的企业组织对这些部门的设置并不相同。但基本上，这些部门有这样一些公共职责：

配合项目体系完成产品开发

为项目体系提供资源

领域内新技术的应用开发与跟踪

制定并维护开发流程

部门建设

在协同产品开发体系中，项目体系中的各个单位被授予了足够大的权力。缺乏有效的监督就会造成权力失控。和现代社会中的“检察官”一样，监理体系负责对项目体系进行监控。正如一个硬币会有两面一样，监控失度同样会带来问题。为了防止监控失度，协同产品开发体系中的监理体系只有监控并向战略与产品决策委员会汇报的权力。纠正的权力则归属战略与产品决策委员会。

监理主要从两个方面来进行：财务和质量。财务监理主要监控在项目过程中的财务行为符合企业的规定。质量方面的监控主要是促使项目组按照规定的程序进行并在阶段评审时确保没有弄虚作假的行为（比如捏造的测试结果等），从而保证开发出的产品是真正高质量的产品。

在进行协同产品开发组织设计时，除了需要考虑前面提到的组织模型外，还有一些具体的细节需要加以考虑。首先是业务部门的设置，为了充分发挥资源共享，应尽量考虑整合集中。集中的原则是将业务方向相同或相似的部门整合起来，按照专业原则进行重新设置。例如，可以考虑将在不同专业部门中的软件部分抽取出来成为软件部门。这样做的一个有利之处是便于统一规划软件部门的发展，便于软件工程师的交流和提高。另外，在组建项目体系时还必须考虑企业和项目的规模。对于规模较大的企业组织，针对产品线较长的现象，可以成立战略与产品决策委员会的常设辅助机构，帮助战略与产品决策委员会处理一些日常事务，执行战略与产品决策委员会的决策。同样，在企业内部产品的专业范围广以至于很难进行整体把握的情况下，可以考虑成立产品线管理团队的辅助机构，帮助产品线管理团队进行专业把关等。

以上很多内容强调了CPC不仅仅是技术，当然CPC离开技术也是空中楼阁，欢迎通过邮件继续探讨CPC的产品比较、CPC的产品实施等话题。

作者联系方式：crikes.zhang@AMTeam.org
tony.lian@AMTeam.org