产品开发组织超模块化及其对创新的影响

产品开发组织超模块化及其对创新的影响
———以丰田汽车为案例的研究
[摘要]本文从产品模块化与组织模块化非对应关系的立论出发，基于对丰田汽车开发系统的典型案例研究，重点探讨了模块化产品开发中超模块组织的性质、成因、结构形态及其在产品创新中的作用。

研究发现，模块化产品的开发过程并不一定要采取与之“同构”的模块化组织形式，相反，以超模块组织来加强开发过程中各任务模块之间的联系，有利于促进整个产品系统的突破性创新。

本文将模块化产品开发系统中采用超模块组织形式归结为影响产品系统创新绩效的调节变量，由此深化了对组织模块化结构表现形态及其前因后果的认识。

一、引言
在商界实践的研究中我们发现，丰田汽车公司从20世纪90年代中后期开始，一改以往汽车中常见的集成化产品开发模式（藤本隆宏，2007），对汽车研发系统的组织结构进行了历史性的变革，由此带来了其产品开发中诸如采用油电混合动力技术的“普锐斯”轿车这样的突破性创新。

尽管从2009年下半年以来丰田出现了售出车辆多起召回事件，但从其前两代“普锐斯”并未发现存在类似质量问题，以及召回车“刹车反应迟缓”问题的解决恰好运用了加强分系统（模块）之间联接与集成的“超模块”原理这些事实来推断，本文在这一案例研究中总结的产品开发系统组织模式及其对创新作用的理论及命题具有典型性和启发意义。

丰田借助重组产品开发系统推动创新的实践，蕴含着产品模块化、组织模块化与产品创新之间深刻的内在关系原理。

而且，丰田产品开发系统的变革历时10余年，其以既不是惯常的集成化也不同于完全模块化的新组织模式来推进“普锐斯”混合动力车的成功开发，以及后来在第三代“普锐斯”的局部优化改进中因忽视模块间关联而引致“召回”事件，从正反两方面反映了“超模块”组织模式的价值所在①。

鉴此，本文选择以丰田汽车在20世纪90年代重组后的“开发中心”体制为个案分析对象，深入考察产品开发系统的组织适宜在多大程度上模块化，以及执行开发任务的各部门之间应具有怎样的相互依存关系和组织结构形态，同时结合丰田在“普锐斯”轿车开发中采用的跨职能联结机制，具体探析设计制造模块化产品的企业能否及如何在产品系统层面取得突破性创新。

二、案例分析
1.拆分“大矩阵”与新设商品开发中心
1953年，丰田公司任命第一位“主查”（1989年后改称“主任工程师”）担任新车开发的项目经理，由此开始形成以项目为基础的产品开发管理体制。

为了平衡专业职能分工与项目管理之间的关系，丰田在产品开发系统中实行矩阵式组织结构：横向为跨职能的产品开发项目小组，由主任工程师负责；纵向为按设计职能划分的工程部，实行部门经理负责制。

随着公司的成长，这一在纵横交错中形成的矩阵变得十分庞大。

20世纪90年代初期，纵向工程部16个，横向开发项目组15个，成为一个15×16的“大矩阵”。

在实际运作中，由于丰田鼓励主任工程师高度关注负责开发项目的成败，导致很多项目组开发出大量并非多款车普遍使用的全新零部件。

而且，主任工程师在整合新产品开发力量时，通常至少需要对分布在12个工程部的48个二级工程技术部门进行协调，难以取得预期的协同效果。

还有，职能部门中专业分工细致的工程师们需要同时参与10多个互不相关的项目，往往只关注自己所负责的十分具体的技术事项，对项目之间有效转移或利用“系统的知识”失去兴趣。

1990年初，为了更好地处理项目管理与资源共享之间的关系，丰田公司决定重新评价其“主任工程师”制，尝试改变产品和技术开发的组织形态。

1992年，丰田按照“平台相似性和技术共享“的原则拆分了产品开发系统的16个工程部，重组成立了三个商品（汽车）开发中心：第一、二中心分别负责后轮驱动、前轮驱动的平台及相
关车型开发，第三中心负责功能型和轻型卡车的平台及相关车型开发。

重组后，每个开发中心内部仅设5个工程部和1个规划部，且每个中心同期的新车开发项目减少到5个。

这样，原先15×16的大矩阵就裂变并简化为三个5×5的小矩阵。

另外，主任工程师需在矩阵关系中协调的二级职能部门的最大数量减少到15个。

产品规划部的职能也在重组中发生了变化。

调整前，负责各类产品开发的平台主管经理和其下的主任工程师都归属同一个产品规划部，重组后，三个商品开发中心分别在内部设立了规划部。

产品规划部原来是管辖平台主管经理及其下的主任工程师的直线部门，现在转变为各个中心内的参谋部门。

在结构重组的同时，丰田加强了开发中心负责人的领导职权，要求三个开发中心负责人承担起两项重要职责：一是帮助主任工程师做好不同工程部门之间的整合工作；二是对各职能工程部门进行有效监管。

中心负责人还被赋予矩阵管理者的角色，使主任工程师与职能经理同时向他汇报，由他全权处理矩阵结构中项目和职能两条线之间的冲突。

2.零部件、分总成开发与整车开发的分离
在分设三个商品开发中心的同时，1993年，丰田把原本高度重视研究工作的研究与高级开发（RAD）集团改组为专门负责零部件及分总成开发的第四中心，并把三个商品中心中从事通用零部件和分总成开发及其生产工艺流程开发的相关人员转移到了第四中心。

在第四中心与三个商品开发中心的分工协作关系上，丰田坚持了如下原则：新产品开发中需要专门定制或者需与其他部件密切协调的零部件，列入特定项目的开发内容中，交由前三个商品开发中心之一具体负责；无需考虑具体项目的通用零部件以及需前沿技术支持的零部件，由第四中心负责。

鉴于分总成系统开发需要多学科交叉，丰田在第四中心内部引进了“跨领域系统项目”（Cross-areaSystemProjects），即由来自各个不同技术领域的工程师和研究人员组成项目小组。

这些项目小组在行政关系上隶属于第四中心内设的规划部，但项目领导人由中心负责人直接挑选和任命。

后续数年间，跨领域交叉系统项目小组开发出了一系列需要同时在多个方面创新的分总成系统，如技术先进而成本较低的防抱死制动系统（ABS），就是由第四中心开发成功后被配置到了三个商品中心开发的所有新车上，从而成为多个项目共享的通用的分总成。

为了使基础研究工作不因RAD集团向开发中心方向改组而有所削弱，丰田重新成立了一个专门从事研究的部门。

原有的“丰田中央研究与开发实验室“仍旧作为独立的研究机构从事基础研究。

这样，在整个研发系统中，第四中心的职责是向三个商品开发中心的新车开发提供潜在的可共享的技术支持，以开发”构成产品系统的零部件和分总成及其生产工艺流程“为重点，并通过“跨领域（分）系统项目”方式解决在特定分系统开发中涉及的各学科、各技术领域的配合问题。

3.“普锐斯”混合动力车开发中的组织体系创新
1992年之后在丰田开发的众多品牌汽车中，“普锐斯”是丰田在油电混合动力总成基础上开发出来的革命性的新产品，其开发过程充分展现了丰田在新产品开发方面的组织体系创新。

1993年9月，丰田公司决定研发一款适合新世纪的车型。

1994年7月，在明确了“燃油经济性高、小尺寸但有宽敞内部空间”的开发愿景后，丰田公司任命内山田武司担任此项目的主任工程师。

内山田的专业背景是测试工程，在丰田重组研发系统期间曾担任总架构设计师，当时在丰田内部被认为是非专业的、“不在主任工程师职业发展轨道上”的人士。

内山田本人对此也深感意外，他非常清楚，以丰田公司传统上对主任工程师的要求衡量，自己并非这方面的行家。

内山田决定借助专家的力量，他上任后所做的第一件事，就是组建一个跨职能的专家团队，成员包括“所在开发中心核心工程部门的人员、第四中心负责先行技术开发的工程师和生产系统的同步工程师“等。

内山田领导该专家团队，在一个他们称之为“作战室”（Obeya，又称“大部屋”）的大房间内共同审查项目的各项进展及讨论所有重要的决策问题。

内山田所创建的“大部屋”制，并不是简单地让工程师们在一起上班，而是促使参与该项目的各职能小组负责
人（工程经理）通过定期举行的时间可能并不长的“跨职能会议“来共同做出产品开发方面的决策。

之前，主任工程师在做出决定前往往需要逐一与工程负责人讨论，花数周时间来获得共识。

内山田则借助“大部屋”引入了“关键工程负责人“集体议事、共同决策的机制。

而且，随着项目的推进，由跨部门的职能负责人与主任工程师一起面对面解决问题的“大部屋”，随之从设计场所转移到了生产部门中，涉及的决策事项从概念到造型设计，再到原型开发，再转到量产准备等，因此，被称为“移动的大部屋”（TravelingObeya）。

在频繁而密集的跨职能互动中，“大部屋”日渐发展成为行之有效的工作协调会，而不是一般的例会。

在开发“普锐斯”过程中，内山田要求专家团队研究30款已有的丰田车型，并要求全球四个丰田设计室参与车身方案投标竞争。

尤为特别的是，在参与竞标的各个设计室分别独立开展车身造型设计的同时，车身工程部门的专家们从一开始就着手并行地开展一些初步结构工程工作，他们以各自假想的将胜出的车身外形方案为基础，采用“多方案法“绘制出了数以百计的车身结构草图。

这与传统上在各模块的设计独立完成后再顺序开展工作的“迭代法”明显不同，丰田是在各模块开发团队并行提出的各种不同的多方案集的交叠中使彼此相匹配的设计方案最终产生。

这种被摩根和莱克（2008）归纳为“会聚法”（ConvergentApproach）的方法虽然可能延缓开发决策过程，但它能使各模块之间的界面问题得到比较经济、有效的解决。

同时，丰田的工程师们还使用系统的“参数化设计”方法，每当某些参数改变时，功能先进的设计软件都能迅速地显示其对系统性能的影响，以此提高交集或会聚过程的效率，防止出现不必要的返工。

另外，在各商品开发中心内多个开发项目同期推进的情况下，丰田以“均衡流”（LeveledFlow）的过程逻辑来组织新产品开发工作。

在错开各项目以保持资源需求平衡的同时，丰田把各个具体车辆开发的总体计划拆分为具有不同内容和时间要求但又都满足在流程后期“会聚”条件约束的各子系统开发工作进度表，以便在并行工程进行中既均衡各部门的工作量，又保证各项目特定的时间（如车展、投产）要求。

这样，尽管各子系统进度计划的变更会影响整个项目的进度，但“大部屋”制提供的无缝合作环境，可以为打造“均衡流”创造良好的条件。

借助这种过程逻辑，丰田努力使各个子系统开发过程“成为一个紧密联结的链条”（摩根，莱克，2008）。

1997年10月，丰田公司向全球市场推出了具有划时代意义的“普锐斯”混合动力车。

这款车在动力和造型设计方面都是行业的领先者，燃油排放指标远优于国际环保标准，很多配件和车身部件都实现了重大突破。

比这款车的诞生更有意义的是，内山田在开发“普锐斯”过程中尝试的“大部屋”制，显现出了其在新车开发中促进跨职能联结方面的独特优势，从而在1997年被丰田公司正式确认为一种新的开发流程规范。

三、研究发现与讨论
1.组织模块化和产品模块化、产品创新绩效之间的关系
已有关于产品模块化与组织模块化及产品创新关系的研究文献，大部分集中在讨论产品模块化是否是企业采用模块化组织的决定因素，以及由此引起的产品创新实现的层次和水平上。

这些研究倾向于探讨或检验如下一种反映“技术决定论”的关系框架（见图1）：产品模块化带来组织
模块化，而组织模块化作为“中介”会推动产品模块的突破性
创新，但无法促进甚或可能阻碍产品系统的突破性创新。

丰田公司第四中心的成立，标志着其汽车开发在实体产品
设计方面已经开始改变过去的集成系统模式。

然而，在开发模
块化产品过程中，丰田并不是如一些学者
（Sanchez&Mahoney，1996）主张的那样采取与产品模块
化程度相当的模块化组织模式。

像“普锐斯”轿车这样的开发，
并未采用先由各个工程部门依据产品结构或生产流程各自独立地开发出分系统或零部件而后再组合在一起形成整体产品系统的方式，而是在三个并列的商品开发中心内部“小矩阵”的结构框架下，由主任工程师引领各职能领域的工程技术负责人聚集于“大部屋”中谋求各任务模块的协同。

实践表明，这一与模块化产品“非同构”的组织结构形态，推动了丰田在进入新世纪前后取得包括“普锐斯”在内的一系列非凡的创新型产品。

由此，本文得到如下最为基本的发现，即命题1：组织模块化与产品模块化并非一贯地“同构”,设计及生产模块化产品的企业，可以突破与产品模块化简单对应的组织模块化范式，转而根据需要选用与其产品开发战略相适宜的组织结构形式。

丰田产品研发系统自1992年以来按“开发中心”体制进行的组织变革，积极地影响着该公司的产品创新过程与结果。

“普锐斯”的成功，远远超出了某些零部件或分总成系统的模块化创新或者局部设计改进，而是从整体上成就了一款与传统轿车有着本质差异的新车，取得产品系统创新的突破。

这一实绩显示：像汽车这类大型的以模块化方式设计的产品，其实也完全能够取得整个产品系统而不仅限于个别模块层次的突破性创新。

显然，问题的关键并不在于产品系统本身是集成性的还是可解构为众多模块化单元，而是产品开发过程的各工程或技术活动是如何配合和实现协调的。

如果一味地强调组织设计模式与产品设计模式之间的一一对应关系，那么，过强的职能模块分工导向会导致所开发的产品最终难以在整个系统层面实现突破性创新，因为这种对应或同构会限制职能或任务模块之间的交流，阻滞各个工程领域之间相依关系的发展。

反之，企业若能突破这一传统认识，不再寻求产品模块化决定下的组织模块化架构，则可能带来类似于丰田在“普锐斯”新车开发上所取得的成功。

因此，旨在追求整个产品系统而不仅仅是产品中某个或某些模块的突破性创新的企业，应摒弃将组织设计模式与产品设计模式简单对应的逻辑，设法寻求以某种对目标的实现更为适当的、非模块化的组织模式来实施模块化产品开发。

由此，本文得到命题1a：在产品模块化设计的企业中，完全模块化的组织结构模式只能带来局部的、产品模块层次上的突破性创新；以非模块化的结构模式来组织产品设计过程，则有可能在整个产品系统层次上取得突破性创新。

从实践回顾看，如果没有始于1992年的强化“跨职能“联结的组织架构变革，以及内山田所创立的“大部屋”制及其本人在新车开发过程中所进行的强有力协调，很难想像丰田公司会取得成功开发“普锐斯”混合动力车这样的突破性创新成果。

丰田的组织创新实践说明：在既定的产品模块化设计的技术框架下，组织结构模式可以与产品模块化不一致；而且，在强有力的跨边界协调之下，与产品结构非同构的组织结构有可能促进企业在“产品模块和整个产品系统“两个层次上都取得突破性创新。

本案例研究显示，产品开发过程的组织结构模式并非是由产品结构特点所决定的内生变量，相反，它可以是独立的，因而并不成为产品结构变量与产品创新绩效之间关系的中介（Mediating）变量。

因此，传统上有关组织结构模式在产品模块化设计模式与产品创新绩效之间发挥中介作用的论断，未能准确揭示组织结构模式与产品模块化、产品创新绩效之间的内在关系。

表现出与产品结构非同构或异构形态的组织结构模式，可以在产品模块化设计模式与产品创新
绩效之间的关系中发挥调节（Moderating）作用。

由此，我
们得出衍生命题1b及反映这些变量之间关系的调节效应模型
（见图2）。

命题1b：模块化产品开发过程的组织是否在结构
形态上是模块化的，会对产品模块化设计方式与突破性创新绩
效之间的关系起重要调节作用。

在高程度模块化的组织结构情
形下，产品模块化设计方式只能带来”产品模块“层次的突破
性创新；与产品模块化结构不相对应的非模块化组织结构，会
促进模块化设计产品在”系统“层次上取得突破性创新。

2.创新型产品开发组织的模块化程度与跨边界协调机制
命题1述及的“非模块化的组织结构”，并非仅仅指传统认识上的集成化或一体化组织模式。

相关文献显示，反映松散耦合系统的“近解构”特性的模块化组织，会因模块之间实现集结的具体方式不同而有所差别（Brusoni&Prencipe，2005；王建安，张钢，2008）。

BaldwinandClark（2000）主张的模块系统是由清晰的、标准化的界面联系规则来协调或处理各模块之间的关系，然而，从模块组合（Combinability）维度（Salvador，2007）来说，各模块在实现彼此间耦合或配合的过程中，并不能总是依靠清晰的既定规则做出“自动响应”，往往需要依特定的情势做出“人为响应”（Brusoni&Prencipe，2005）。

这样，在模块间界面联系规则未经事先的设计而成为清晰的“可见信息”的情况下，各模块单元的行动者对于模块间的关系协调具有很大的能动性。

在重组前的15×16大矩阵结构下，丰田汽车开发系统中负责开发任务模块的各职能部门同时关注的开发项目多达15个，相互之间不容易在特定汽车开发项目中密切配合，而且与以研究为工作重点的RAD集团之间的联系也很弱，开发系统呈现出一种开发流程任务模块化程度非常高的结构形态，技术专家之间缺乏跨职能的交流，各自在狭窄的专业面上谋求技能的纵深发展，并且以不贴近任何特定产品项目的“标准化”技术为其所参与的各个项目提供服务。

在图3a所示的“大矩阵”
结构下，作为项目经理的主任
工程师，从形式上说有权管理
从提出创意到设计、试制、定
型的整个产品开发过程。

但在
实际运行中，主任工程师要跨
职能协调和整合诸多工程部门，
难度很大。

工程部门的专业职
能分工很细，部门设置数量多，
这本身就潜存着大量的跨职能协调问题。

而且，因参与项目多，职能部门经理没有足够时间去研究和管理各具体项目的技术细节问题，项目之间的技术力量平衡和资源共享问题也变得非常复杂。

另外，产品规划部总经理辖下的平台主管经理和主任工程师都要同时与工程部门经理构成矩阵关系，由此形成了一种“双层”矩阵。

形式上被赋予了跨职能协调权责的主任工程师，必须通过平台主管经理来进行“上层”矩阵的跨职能协调，这又带来主任工程师的上司（平台主管经理）和职能经理的上司（工程部经理）两者权限划分不清的问题。

同时，产品规划部内的主任工程师和平台主管经理都没有直接监管各职能部门的权限，未能真正形成以“项目“为导向的组织形式。

重组成立三个商品开发中心后，开发中心负责人接受各职能领域工程部经理的工作汇报，拥有比以往的平台主管经理权限更大且更为直接的矩阵管理权。

从图3b所示的矩阵中“行”这条线可以看出，被分解到三个“小矩阵”中的各工程部门，在所参与的开发项目减少到5项之后，服务对象开始向共享某个平台的同类产品聚焦。

与此同时，随着矩阵中“列”的数量减少，各工程部门职能模块的责任面也得到了加宽。

这些调整使得原先职能高度细分的工程部门的专业化程度明显降低，为跨职能合作奠定了基础。

丰田公司在开发系统中进行的上述重组因何能够构造出一种带来产品系统突破性创新的组织体系呢？以下从四个方面进行分析与归纳。

（1）“大矩阵”分解为三个“小矩阵”虽然使各项工程活动的范围经济性降低，但按平台相似性划分为各自内设有工程职能部门的三个商品开发中心，使专业面有所拓宽的各个开发任务模块（图3中以英文字母编号的“职能”）的规模由“过小”转为“适中”（这是相关职能合并以及先行的零部件及分总成开发剥离的结果），而它们直接服务
的对象（图3中以数字编号的“项目”）缩减至1/3后，各职能部门的工程活动具有了更大的针对性和可组合性。

表面上看，这三个中心仍然是按模块化解构原理进行开发任务的分割，但是，它们都围绕特定项目之顾客需求特点而在各工程领域任务模块间进行密切的整合，以便在较为宽厚的职能基础上，通过加强各工程领域的技术集成，开发出各具特色的产品系统（整车）。

较之以前专业面狭窄但服务对象泛化的“职能烟囱”式技术能力提升，“小矩阵”中各任务模块更专注于积累和发展起专业领域的“平台能力”，即提升本中心内特定类型平台及相关派生产品开发所需的技术能力。

因此，就基本立场来说，它们不再以职能工作为重心，而更注重如何在特色化开发项目中从专业领域角度出发做出贡献，这就为整个产品系统的技术整合或集成提供了基础性条件。

对比丰田公司重组前后产品开发组织的特点，我们发现，与重组前因各任务模块高度专业化和模块化切割而导致产品开发工作“并不能真正以项目为导向”的运作方式相区别，三个开发中心内设的“小矩阵”结构展现了另外一种组织发展趋向，即加强开发过程各任务模块的可组合性和连接性。

在“小矩阵”结构下，承担各项不同工程任务的各职能部门，围绕特定新产品开发项目的运作形成了密切的联系和耦合。

我们采用Garudetal.（2003）的概念界定，将这种组织模式称为“超模块”组织。

“普锐斯”车的开发过程说明，这一新型组织模式具有两大特征：从“模块化解构”维度看，开发过程中涉及的任务模块虽然按不同职能进行了（近）解构，但它们并没有固定地被配置到某个特定项目团队中，而是被灵活机动地组合进某个新品开发过程中，是具有相对独立性的模块；从“模块化集结”维度看，各任务模块的承担者并不是按事先设计好的界面规则“自动”地产生松散性合作，而是围绕整体产品开发中需要达成的能满足顾客对特色化产品需要的特定技术集成要求而能动地密切配合。

显然，在开发像轿车这样具有显著差异化需求特性的产品时，按“情势”法则进行高质量的技术集成（而不像电脑那样按行业通用标准进行“拼装”）对于产品竞争力至关重要。

为了确保整个开发任务系统能够达到工程技术方面的组合或集成水平，参与开发过程的各部门在相关工程职能的模块化集结中就不能仅仅按照通常模块化逻辑下的完全“自动响应”方式进行整合。

由此，我们归纳得出命题2：模块化系统解构的方式不仅决定着模块的大小和数量，也影响其后的系统整合的难易程度及方式。

对于同时执行多项产品开发任务的企业来说，在构建开发系统的模块化组织时，需要妥善处理和平衡各任务模块在跨产品项目的“可共享性”与项目内跨职能的“可组合性”之间的关系。

结合丰田产品开发系统在重组前后“大”、“小”矩阵中纵横向关系的特点，我们可从上述基本命题中推出命题2a：产品开发过程虽然具有按工程职能分解为各任务模块并使之在服务于众多产品项目中实现广泛的技术共享的可能性，但是，过分强调可分解性会导致整个开发系统的模块数量增多，并因各模块专业职能分工过细而出现模块化切割现象，从而给项目领导人在产品系统层面的整合工作带来困难；命题2b：适当拓宽各任务模块的责任面，并明确其技术能力在若干项目中共享的范围，会使规模适中、服务对象受限但可组合性增大了的各任务模块，在相互之间以“人为响应”方式进行的较强联结中形成“超模块”组织形态。

（2）丰田在依照平台相似性缩减各职能领域之工程技术的共享范围的同时，通过集中的零部件和分总成开发，加大了嵌入各个产品模块中的先行技术的共享范围。

丰田在将原RAD集团改组为作为“下游”开发系统之组成部分的第四中心后，原先集结于单个产品开发项目的“纵向一体化”流程中的各个产品模块（包括底盘部件、发动机、驱动装置和电子等分系统及零部件）的开发任务，遂从整车开发工作流程中剥离了出来，由此使产品组件开发方面的任务模块化解构程度明显加大，而这点更好地顺应了当今汽车产品模块化设计的技术变化趋势。

Salvador（2007）在整理关于产品系统模块化概念各种定义的文献时区分说，“产品模块化”是与组件（或模块）的可分解性、共用性和可组合性都存在关联的构念，而“生产模块化”则主要与组件的可分解性关联，“设计模块化”却是主要与组件的可组合性关联。

根据这些内涵区别，结合丰田公司将底盘部件、发动机、驱动装置和电子等分总成开发及共用的汽车生产流程设计等工作从三个商品开发中心中剥离出来的实践，我们推断，汽车制造商完全可以更多地利用汽车组件可分解性的特点，把产品组件开发和生产任务从整车开发中分离出来，交由独立的机。