产品开发组织超模块化及其对创新的影响——以丰田汽车为案例的研究，本文主要内容关键词为：产品开发论文,其对论文,丰田汽车论文,案例论文,组织论文，此文献不代表本站观点，内容供学术参考，文章仅供参考阅读下载。
一、引言
在商界实践的研究中我们发现，丰田汽车公司从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-area System Projects)，即由来自各个不同技术领域的工程师和研究人员组成项目小组。这些项目小组在行政关系上隶属于第四中心内设的规划部，但项目领导人由中心负责人直接挑选和任命。后续数年间，跨领域交叉系统项目小组开发出了一系列需要同时在多个方面创新的分总成系统，如技术先进而成本较低的防抱死制动系统(ABS)，就是由第四中心开发成功后被配置到了三个商品中心开发的所有新车上，从而成为多个项目共享的通用的分总成。
为了使基础研究工作不因RAD集团向开发中心方向改组而有所削弱，丰田重新成立了一个专门从事研究的部门。原有的丰田中央研究与开发实验室仍旧作为独立的研究机构从事基础研究。这样，在整个研发系统中，第四中心的职责是向三个商品开发中心的新车开发提供潜在的可共享的技术支持，以开发构成产品系统的零部件和分总成及其生产工艺流程为重点，并通过“跨领域(分)系统项目”方式解决在特定分系统开发中涉及的各学科、各技术领域的配合问题。
3.“普锐斯”混合动力车开发中的组织体系创新
1992年之后在丰田开发的众多品牌汽车中，“普锐斯”是丰田在油电混合动力总成基础上开发出来的革命性的新产品，其开发过程充分展现了丰田在新产品开发方面的组织体系创新。
1993年9月，丰田公司决定研发一款适合新世纪的车型。1994年7月，在明确了“燃油经济性高、小尺寸但有宽敞内部空间”的开发愿景后，丰田公司任命内山田武司担任此项目的主任工程师。内山田的专业背景是测试工程，在丰田重组研发系统期间曾担任总架构设计师，当时在丰田内部被认为是非专业的、“不在主任工程师职业发展轨道上”的人士。内山田本人对此也深感意外，他非常清楚，以丰田公司传统上对主任工程师的要求衡量，自己并非这方面的行家。内山田决定借助专家的力量，他上任后所做的第一件事，就是组建一个跨职能的专家团队，成员包括所在开发中心核心工程部门的人员、第四中心负责先行技术开发的工程师和生产系统的同步工程师等。内山田领导该专家团队，在一个他们称之为“作战室”(Obeya，又称“大部屋”)的大房间内共同审查项目的各项进展及讨论所有重要的决策问题。
内山田所创建的“大部屋”制，并不是简单地让工程师们在一起上班，而是促使参与该项目的各职能小组负责人(工程经理)通过定期举行的时间可能并不长的跨职能会议来共同做出产品开发方面的决策。之前，主任工程师在做出决定前往往需要逐一与工程负责人讨论，花数周时间来获得共识。内山田则借助“大部屋”引入了关键工程负责人集体议事、共同决策的机制。而且，随着项目的推进，由跨部门的职能负责人与主任工程师一起面对面解决问题的“大部屋”，随之从设计场所转移到了生产部门中，涉及的决策事项从概念到造型设计，再到原型开发，再转到量产准备等，因此，被称为“移动的大部屋”(Traveling Obeya)。在频繁而密集的跨职能互动中，“大部屋”日渐发展成为行之有效的工作协调会，而不是一般的例会。
在开发“普锐斯”过程中，内山田要求专家团队研究30款已有的丰田车型，并要求全球四个丰田设计室参与车身方案投标竞争。尤为特别的是，在参与竞标的各个设计室分别独立开展车身造型设计的同时，车身工程部门的专家们从一开始就着手并行地开展一些初步结构工程工作，他们以各自假想的将胜出的车身外形方案为基础，采用多方案法绘制出了数以百计的车身结构草图。这与传统上在各模块的设计独立完成后再顺序开展工作的“迭代法”明显不同，丰田是在各模块开发团队并行提出的各种不同的多方案集的交叠中使彼此相匹配的设计方案最终产生。这种被摩根和莱克(2008)归纳为“会聚法”(Convergent Approach)的方法虽然可能延缓开发决策过程，但它能使各模块之间的界面问题得到比较经济、有效的解决。同时，丰田的工程师们还使用系统的“参数化设计”方法，每当某些参数改变时，功能先进的设计软件都能迅速地显示其对系统性能的影响，以此提高交集或会聚过程的效率，防止出现不必要的返工。
另外，在各商品开发中心内多个开发项目同期推进的情况下，丰田以“均衡流”(Leveled Flow)的过程逻辑来组织新产品开发工作。在错开各项目以保持资源需求平衡的同时，丰田把各个具体车辆开发的总体计划拆分为具有不同内容和时间要求但又都满足在流程后期“会聚”条件约束的各子系统开发工作进度表，以便在并行工程进行中既均衡各部门的工作量，又保证各项目特定的时间(如车展、投产)要求。这样，尽管各子系统进度计划的变更会影响整个项目的进度，但“大部屋”制提供的无缝合作环境，可以为打造“均衡流”创造良好的条件。借助这种过程逻辑，丰田努力使各个子系统开发过程“成为一个紧密联结的链条”(摩根，莱克，2008)。
1997年10月，丰田公司向全球市场推出了具有划时代意义的“普锐斯”混合动力车。这款车在动力和造型设计方面都是行业的领先者，燃油排放指标远优于国际环保标准，很多配件和车身部件都实现了重大突破。比这款车的诞生更有意义的是，内山田在开发“普锐斯”过程中尝试的“大部屋”制，显现出了其在新车开发中促进跨职能联结方面的独特优势，从而在1997年被丰田公司正式确认为一种新的开发流程规范。
三、研究发现与讨论
1.组织模块化和产品模块化、产品创新绩效之间的关系
已有关于产品模块化与组织模块化及产品创新关系的研究文献，大部分集中在讨论产品模块化是否是企业采用模块化组织的决定因素，以及由此引起的产品创新实现的层次和水平上。这些研究倾向于探讨或检验如下一种反映“技术决定论”的关系框架(见图1)：产品模块化带来组织模块化，而组织模块化作为“中介”会推动产品模块的突破性创新，但无法促进甚或可能阻碍产品系统的突破性创新。
丰田公司第四中心的成立，标志着其汽车开发在实体产品设计方面已经开始改变过去的集成系统模式。然而，在开发模块化产品过程中，丰田并不是如一些学者(Sanchez & Mahoney，1996)主张的那样采取与产品模块化程度相当的模块化组织模式。像“普锐斯”轿车这样的开发，并未采用先由各个工程部门依据产品结构或生产流程各自独立地开发出分系统或零部件而后再组合在一起形成整体产品系统的方式，而是在三个并列的商品开发中心内部“小矩阵”的结构框架下，由主任工程师引领各职能领域的工程技术负责人聚集于“大部屋”中谋求各任务模块的协同。实践表明，这一与模块化产品“非同构”的组织结构形态，推动了丰田在进入新世纪前后取得包括“普锐斯”在内的一系列非凡的创新型产品。由此，本文得到如下最为基本的发现，即命题1：组织模块化与产品模块化并非一贯地“同构”，设计及生产模块化产品的企业，可以突破与产品模块化简单对应的组织模块化范式，转而根据需要选用与其产品开发战略相适宜的组织结构形式。
图1 技术决定论下组织模块化与创新的关系
丰田产品研发系统自1992年以来按“开发中心”体制进行的组织变革，积极地影响着该公司的产品创新过程与结果。“普锐斯”的成功，远远超出了某些零部件或分总成系统的模块化创新或者局部设计改进，而是从整体上成就了一款与传统轿车有着本质差异的新车，取得产品系统创新的突破。这一实绩显示：像汽车这类大型的以模块化方式设计的产品，其实也完全能够取得整个产品系统而不仅限于个别模块层次的突破性创新。显然，问题的关键并不在于产品系统本身是集成性的还是可解构为众多模块化单元，而是产品开发过程的各工程或技术活动是如何配合和实现协调的。如果一味地强调组织设计模式与产品设计模式之间的一一对应关系，那么，过强的职能模块分工导向会导致所开发的产品最终难以在整个系统层面实现突破性创新，因为这种对应或同构会限制职能或任务模块之间的交流，阻滞各个工程领域之间相依关系的发展。反之，企业若能突破这一传统认识，不再寻求产品模块化决定下的组织模块化架构，则可能带来类似于丰田在“普锐斯”新车开发上所取得的成功。因此，旨在追求整个产品系统而不仅仅是产品中某个或某些模块的突破性创新的企业，应摒弃将组织设计模式与产品设计模式简单对应的逻辑，设法寻求以某种对目标的实现更为适当的、非模块化的组织模式来实施模块化产品开发。由此，本文得到命题la：在产品模块化设计的企业中，完全模块化的组织结构模式只能带来局部的、产品模块层次上的突破性创新；以非模块化的结构模式来组织产品设计过程，则有可能在整个产品系统层次上取得突破性创新。
从实践回顾看，如果没有始于1992年的强化跨职能联结的组织架构变革，以及内山田所创立的“大部屋”制及其本人在新车开发过程中所进行的强有力协调，很难想象丰田公司会取得成功开发“普锐斯”混合动力车这样的突破性创新成果。丰田的组织创新实践说明：在既定的产品模块化设计的技术框架下，组织结构模式可以与产品模块化不一致；而且，在强有力的跨边界协调之下，与产品结构非同构的组织结构有可能促进企业在产品模块和整个产品系统两个层次上都取得突破性创新。本案例研究显示，产品开发过程的组织结构模式并非是由产品结构特点所决定的内生变量，相反，它可以是独立的，因而并不成为产品结构变量与产品创新绩效之间关系的中介(Mediating)变量。因此，传统上有关组织结构模式在产品模块化设计模式与产品创新绩效之间发挥中介作用的论断，未能准确揭示组织结构模式与产品模块化、产品创新绩效之间的内在关系。表现出与产品结构非同构或异构形态的组织结构模式，可以在产品模块化设计模式与产品创新绩效之间的关系中发挥调节(Moderating)作用。由此，我们得出衍生命题1b及反映这些变量之间关系的调节效应模型(见图2)。命题1b：模块化产品开发过程的组织是否在结构形态上是模块化的，会对产品模块化设计方式与突破性创新绩效之间的关系起重要调节作用。在高程度模块化的组织结构情形下，产品模块化设计方式只能带来产品模块层次的突破性创新；与产品模块化结构不相对应的非模块化组织结构，会促进模块化设计产品在系统层次上取得突破性创新。
2.创新型产品开发组织的模块化程度与跨边界协调机制
图2 组织结构模式对产品模块化与创新关系的调节
命题1述及的“非模块化的组织结构”，并非仅仅指传统认识上的集成化或一体化组织模式。相关文献显示，反映松散耦合系统的“近解构”特性的模块化组织，会因模块之间实现集结的具体方式不同而有所差别(Brusoni & Prencipe，2005；王建安，张钢，2008)。Baldwin and Clark(2000)主张的模块系统是由清晰的、标准化的界面联系规则来协调或处理各模块之间的关系，然而，从模块组合(Combinability)维度(Salvador，2007)来说，各模块在实现彼此间耦合或配合的过程中，并不能总是依靠清晰的既定规则做出“自动响应”，往往需要依特定的情势做出“人为响应”(Brusoni & Prencipe，2005)。这样，在模块间界面联系规则未经事先的设计而成为清晰的“可见信息”的情况下，各模块单元的行动者对于模块间的关系协调具有很大的能动性。
在重组前的15×16大矩阵结构下，丰田汽车开发系统中负责开发任务模块的各职能部门同时关注的开发项目多达15个，相互之间不容易在特定汽车开发项目中密切配合，而且与以研究为工作重点的RAD集团之间的联系也很弱，开发系统呈现出一种开发流程任务模块化程度非常高的结构形态，技术专家之间缺乏跨职能的交流，各自在狭窄的专业面上谋求技能的纵深发展，并且以不贴近任何特定产品项目的“标准化”技术为其所参与的各个项目提供服务。
在图3a所示的“大矩阵”结构下，作为项目经理的主任工程师，从形式上说有权管理从提出创意到设计、试制、定型的整个产品开发过程。但在实际运行中，主任工程师要跨职能协调和整合诸多工程部门，难度很大。工程部门的专业职能分工很细，部门设置数量多，这本身就潜存着大量的跨职能协调问题。而且，因参与项目多，职能部门经理没有足够时间去研究和管理各具体项目的技术细节问题，项目之间的技术力量平衡和资源共享问题也变得非常复杂。另外，产品规划部总经理辖下的平台主管经理和主任工程师都要同时与工程部门经理构成矩阵关系，由此形成了一种“双层”矩阵。形式上被赋予了跨职能协调权责的主任工程师，必须通过平台主管经理来进行“上层”矩阵的跨职能协调，这又带来主任工程师的上司(平台主管经理)和职能经理的上司(工程部经理)两者权限划分不清的问题。同时，产品规划部内的主任工程师和平台主管经理都没有直接监管各职能部门的权限，未能真正形成以项目为导向的组织形式。
重组成立三个商品开发中心后，开发中心负责人接受各职能领域工程部经理的工作汇报，拥有比以往的平台主管经理权限更大且更为直接的矩阵管理权。从图3b所示的矩阵中“行”这条线可以看出，被分解到三个“小矩阵”中的各工程部门，在所参与的开发项目减少到5项之后，服务对象开始向共享某个平台的同类产品聚焦。与此同时，随着矩阵中“列”的数量减少，各工程部门职能模块的责任面也得到了加宽。这些调整使得原先职能高度细分的工程部门的专业化程度明显降低，为跨职能合作奠定了基础。
(a)15×16矩阵中职能模块间广泛而虚弱的联系
(b)三个5×5矩阵中开发项目内密集而较强的联系
图3 丰田产品开发系统结构重组前后的组织形态对比
资料来源：根据迈克尔·库斯玛诺等(2004)整理。
丰田公司在开发系统中进行的上述重组因何能够构造出一种带来产品系统突破性创新的组织体系呢？以下从四个方面进行分析与归纳。
(1)“大矩阵”分解为三个“小矩阵”虽然使各项工程活动的范围经济性降低，但按平台相似性划分为各自内设有工程职能部门的三个商品开发中心，使专业面有所拓宽的各个开发任务模块(图3中以英文字母编号的“职能”)的规模由“过小”转为“适中”(这是相关职能合并以及先行的零部件及分总成开发剥离的结果)，而它们直接服务的对象(图3中以数字编号的“项目”)缩减至1/3后，各职能部门的工程活动具有了更大的针对性和可组合性。表面上看，这三个中心仍然是按模块化解构原理进行开发任务的分割，但是，它们都围绕特定项目之顾客需求特点而在各工程领域任务模块间进行密切的整合，以便在较为宽厚的职能基础上，通过加强各工程领域的技术集成，开发出各具特色的产品系统(整车)。较之以前专业面狭窄但服务对象泛化的“职能烟囱”式技术能力提升，“小矩阵”中各任务模块更专注于积累和发展起专业领域的“平台能力”，即提升本中心内特定类型平台及相关派生产品开发所需的技术能力。因此，就基本立场来说，它们不再以职能工作为重心，而更注重如何在特色化开发项目中从专业领域角度出发做出贡献，这就为整个产品系统的技术整合或集成提供了基础性条件。
对比丰田公司重组前后产品开发组织的特点，我们发现，与重组前因各任务模块高度专业化和模块化切割而导致产品开发工作“并不能真正以项目为导向”的运作方式相区别，三个开发中心内设的“小矩阵”结构展现了另外一种组织发展趋向，即加强开发过程各任务模块的可组合性和连接性。在“小矩阵”结构下，承担各项不同工程任务的各职能部门，围绕特定新产品开发项目的运作形成了密切的联系和耦合。我们采用Garud et al.(2003)的概念界定，将这种组织模式称为“超模块”组织。“普锐斯”车的开发过程说明，这一新型组织模式具有两大特征：从“模块化解构”维度看，开发过程中涉及的任务模块虽然按不同职能进行了(近)解构，但它们并没有固定地被配置到某个特定项目团队中，而是被灵活机动地组合进某个新品开发过程中，是具有相对独立性的模块；从“模块化集结”维度看，各任务模块的承担者并不是按事先设计好的界面规则“自动”地产生松散性合作，而是围绕整体产品开发中需要达成的能满足顾客对特色化产品需要的特定技术集成要求而能动地密切配合。显然，在开发像轿车这样具有显著差异化需求特性的产品时，按“情势”法则进行高质量的技术集成(而不像电脑那样按行业通用标准进行“拼装”)对于产品竞争力至关重要。为了确保整个开发任务系统能够达到工程技术方面的组合或集成水平，参与开发过程的各部门在相关工程职能的模块化集结中就不能仅仅按照通常模块化逻辑下的完全“自动响应”方式进行整合。由此，我们归纳得出命题2：模块化系统解构的方式不仅决定着模块的大小和数量，也影响其后的系统整合的难易程度及方式。对于同时执行多项产品开发任务的企业来说，在构建开发系统的模块化组织时，需要妥善处理和平衡各任务模块在跨产品项目的“可共享性”与项目内跨职能的“可组合性”之间的关系。
结合丰田产品开发系统在重组前后“大”、“小”矩阵中纵横向关系的特点，我们可从上述基本命题中推出命题2a：产品开发过程虽然具有按工程职能分解为各任务模块并使之在服务于众多产品项目中实现广泛的技术共享的可能性，但是，过分强调可分解性会导致整个开发系统的模块数量增多，并因各模块专业职能分工过细而出现模块化切割现象，从而给项目领导人在产品系统层面的整合工作带来困难；命题2b：适当拓宽各任务模块的责任面，并明确其技术能力在若干项目中共享的范围，会使规模适中、服务对象受限但可组合性增大了的各任务模块，在相互之间以“人为响应”方式进行的较强联结中形成“超模块”组织形态。
(2)丰田在依照平台相似性缩减各职能领域之工程技术的共享范围的同时，通过集中的零部件和分总成开发，加大了嵌入各个产品模块中的先行技术的共享范围。丰田在将原RAD集团改组为作为“下游”开发系统之组成部分的第四中心后，原先集结于单个产品开发项目的“纵向一体化”流程中的各个产品模块(包括底盘部件、发动机、驱动装置和电子等分系统及零部件)的开发任务，遂从整车开发工作流程中剥离了出来，由此使产品组件开发方面的任务模块化解构程度明显加大，而这点更好地顺应了当今汽车产品模块化设计的技术变化趋势。
Salvador(2007)在整理关于产品系统模块化概念各种定义的文献时区分说，“产品模块化”是与组件(或模块)的可分解性、共用性和可组合性都存在关联的构念，而“生产模块化”则主要与组件的可分解性关联，“设计模块化”却是主要与组件的可组合性关联。根据这些内涵区别，结合丰田公司将底盘部件、发动机、驱动装置和电子等分总成开发及共用的汽车生产流程设计等工作从三个商品开发中心中剥离出来的实践，我们推断，汽车制造商完全可以更多地利用汽车组件可分解性的特点，把产品组件开发和生产任务从整车开发中分离出来，交由独立的机构(如丰田的第四中心，或者承担“外包”任务的外部模块供应商)专门负责，这将使当前汽车行业“模块化生产程度较低”的状态得到改变。与此同时，剥离了组件(零部件或分总成)开发任务的项目团队，可以全力围绕各组件在特定产品系统中的可组合性问题，进行与顾客特色化需求相吻合的技术集成。在这一组合与集成过程中，“普锐斯”产品开发的实践显示，与倚重组件可分解性的模块化生产方式不同，在模块化产品整体系统的设计中，各工程部门在完成各自分工负责的模块设计职能时，需要兼顾设计方案的创新性和兼容性。由此，我们归纳得出命题3：将零部件和分总成开发从整体产品系统开发中剥离出来的“去耦合”措施，有利于企业提升产品各组件可分解性并促进模块化生产在更大范围实施；而在弱耦合的产品模块开发任务被解构出来后，整体产品系统的开发过程可以更加关注相关组件的可组合性，以此确保技术集成在整个系统层面得以实现。
(3)丰田公司第四中心在从处于研发流程“上游”环节的研究(R)向“下游”环节的先行技术开发(D)转变的过程中，负责整车开发的三个商品开发中心内只留下在特色化汽车开发中需要加以密切整合的少量工程职能任务模块，而整车开发工作前期的各产品模块的技术开发及相应的制造工艺流程开发则以集中的、规模化的方式进行，这样不仅利于降低开发成本，也促进了通用模块在更多产品项目中的共享。而且，丰田在集中负责通用零部件及分总成开发的第四中心内部又依照产品分系统(产品模块类别)分设各个专业开发部门，这体现了与实体产品模块化“同构”的先行技术开发组织的完全模块化趋向。进一步地，以第四中心的运作特点来总结，“交叉领域(分)系统项目”的实施使来自不同学科或技术领域的工程师及研究人员能够围绕特定分系统(分总成)的开发而相互交流，在此跨领域合作中设计和生产出了诸如防抱死制动系统(ABS)这样的通用组件系统或模块。对通用性的充分考虑，促使第四中心在组织产品模块开发中更注重研究、开发和生产工程之间的纵向联结，而不是若干个模块(分系统)之间的横向联结，这点使定位于各产品模块之先行技术开发的第四中心与从事特色化整车开发的三个商品开发中心的内部结构显现出“异构”的特征。
进一步从模块化程度上考察重组后的丰田汽车开发系统可以发现，丰田的三个商品开发中心在剥离了各个产品模块开发职能后，以“小矩阵”来加强特定项目内部各任务模块之间的跨职能联结，而第四中心却在内部设立专业化模块开发机构时遵循了高度模块化解构的逻辑，在弱化各模块间横向联结的同时加强了特定模块技术开发中上、下游之间的纵向联结。这两种“不对等”的结构安排显示了丰田汽车开发系统重组后在组织模式上的权变性。那就是，在产品分总成及零部件开发中通过提高组织模块化程度，促进各专业开发机构在实现各自的技术突破中进行独立实验，创造出若干性能先进的备择产品模块，供后续阶段的整车开发项目选用。与模块开发工作是以任务高度模块化的方式来组织有所不同，丰田的整体产品系统改组为以体现人为响应的超模块模式来组织，由此促进各工程任务模块之间围绕开发特色化汽车的任务而进行相对紧密的联结。这种超越产品实体模块化的超模块组织模式的形成，使得重组变革后的丰田公司一方面能在各产品共用模块的集中开发中取得汽车快速改型和低研发成本上的联合优势；另一方面能在强调产品系统各部分密切整合的集成化整车开发中建立起突破性创新的机制。“普锐斯”混合动力车开发项目的运作过程，形象地反映出摆脱了“技术决定论”逻辑的超模块组织模式探索应用的显著成效。基于这一发现，我们归纳得出命题4：在创新型产品开发中，同实体产品模块化匹配的模块(包括零部件和分总成)开发组织的高度模块化与整体产品系统开发组织的超模块化这两种“异构”模式的并存和结合，有利于企业构建起一种既能高效完成各产品模块的技术开发任务，又能实现产品系统整合中各工程任务模块间紧密联结的突破性创新体系。
(4)丰田在将整车开发组织的结构形态由职能模块化分割转变为模块化程度减弱的新型组织模式后，在内山田的主导下形成了开发中心内部跨部门或跨工程职能的横向联结机制，甚至形成了跨商品开发中心与第四中心的纵向项目协调机制。特别是，“小矩阵”结构与“大部屋”制的结合，使得整车开发中跨越多个工程领域的技术整合，有了便利地进行“人为响应”的基础架构(Infrastructure)。在“普锐斯”开发过程中，即便是在公司高层给以十分紧迫的时间压力时，内山田仍然坚持以“多方案并行工程法”来推进整车系统设计界面问题的联合解决。这一实践显示，与零部件及分总成等产品模块开发任务的“去耦合”趋向相反，丰田整车开发中各工程任务模块间出现了基于“人为响应”的“强耦合”。
更进一步地，在产品模块开发从整车开发工作中分离出来后，第四中心的工程师们在进行其负责的关键模块的高级技术研发时，不但与“上游”的中央研发机构在提供相关的先行技术基础概念方面加强了联系，而且还常常吸收来自“下游”的生产系统中的同步工程师们参与到模块开发团队中，并与将第四中心开发的零部件或分总成作为“输入”的各商品开发中心的设计工程师保持频繁的联系(如后者参加前者举办的“新技术发布会”，前者参加后者在“移动的大部屋”中召集的商讨活动)。在重组前，RAD集团的工程师往往是从丰田中央研究院等基础研究机构获得技术概念，然后脱离于具体的商品开发项目而进行共用的高级技术研发。随着“跨领域(分)系统项目”在第四中心的推行，以及各商品开发中心内项目团队以“移动的大部屋”来因应具体商品开发过程不同阶段对本中心以外的上游或下游单位技术能力的需要，丰田新产品研发系统中的纵向信息沟通和跨领域技术协调得到了明显改善。而且，在“大部屋”制度下，本中心内参与特定开发项目的各职能领域的工程负责人会短暂但频繁地聚集在一起讨论问题，从而搭建起了各职能部门间横向沟通的桥梁。依靠加强各学科领域或工程任务分工后的各部门之间交互联结的超模块组织模式，丰田以一种在通常的模块化组织中所没有的跨边界协调的人为响应机制，有力地保障了“普锐斯”等产品的突破性创新。由此，我们归纳得出命题5：在创新型产品开发中，得到强授权的项目领导人在矩阵内外进行的跨边界协调与人为响应，是企业借助超模块组织模式实现整个产品系统突破性创新的重要保障机制。
四、结论与研究局限
本文借鉴“设计模块化”研究中有关实体产品设计结构与设计过程任务结构是否“同构”的分析逻辑(Baldwin & Clark，2000；Salvador，2007)，在典型案例研究中探索产品开发过程组织模块化的具体结构表现及其对创新绩效的影响。本研究的主要理论价值是，明确阐释了整体产品系统开发与产品模块开发之任务结构及其组织形式的差异，并具体剖析了超模块化组织模式在模块化产品开发系统中得以形成的原因、条件及其对产品模块和系统层面创新的作用。沿着少数研究者最近正在探讨的组织模块化与产品模块化非对应关系的思路，本文以典型个案比较深入的探讨了超模块组织模式如何与人们常规认识的模块化组织模式相区别，以及如何在促进模块化设计产品在整个系统层面取得突破性创新中发挥作用。在以超模块组织的“调节”作用来修正已有的关于模块化组织在产品模块化设计与创新绩效之间起“中介”作用的传统模块化理论的同时，本文的研究不仅仅为正在致力于提升自主研发能力的中国企业构建或改进其产品研发组织体系提供了一个可资借鉴的参照案例，并且在5个命题的归纳提炼中对于产品模块化与组织模块化关系的理论发展做出了贡献。
本文的发现是在单案例研究中取得的，存在着与此方法相联系的固有的“外部效度”缺陷。另外，由于跨国调研的困难，本研究中采用的案例资料基本上是“二手”的。为了使这些间接来源的数据能够基本可靠地反映丰田公司研发系统的真实情况，我们在对他人报告案例资料(库斯玛诺，延岗健太郎，2004；摩根，莱克，2008)的“再分析”中设法尽可能多地获取来自各种渠道的信息，并在这些资料的验证与补充方面做了一批国内赴丰田研修人员的访谈。不过，即便采取了这些弥补性措施，以“二手”资料为主格调的研究仍使本文的研究结论存在需审慎对待及进一步验证的必要。为此，我们希望未来对创新过程组织问题展开更多的国内外案例比较研究，并努力寻求以大样本实证数据来检验案例研究结论的普适性。另外，对于创新性产品开发系统来说，超模块组织结构的形成有着多方面的复杂原因，需要进一步深入探讨。
注释：
①据对丰田“召回”车问题及解决方案的分析，第三代“普锐斯”轿车出现的问题是，因为在防抱死制动系统(ABS)中安装了一种新的电子控制程序，结果在某些路况之下，当自动刹车系统启动时，汽车从再生刹车系统转为传统液压刹车系统时会出现较长的时间滞延，导致驾车者在连续轻踩刹车时发现其“反应迟缓”。而导致这一问题的原因被发现是：新款“普锐斯”中电控软件程序的改进影响了制动系统刹车的性能。丰田给出的解决办法是，花20-30分钟改写这些召回车的软件程序，以电子控制系统的升级来解决刹车系统问题。可以看出，“召回”车问题的核心是在产品改进后的分系统(模块)之间的联结与集成方面，也就是改进型“普锐斯”中加装的新的软件程序这一电子系统的问题(即产品个别模块上的局部优化设计)破坏了整个产品系统。隐藏于模块间关联之中的问题和答案的发现，正好验证了本文从第一代“普锐斯”开发过程中总结的“超模块”组织的功效。丰田对召回的第三代“普锐斯”刹车反应迟缓问题的纠正，实际上是对本文所提炼观点的一个虽然反面但颇具延伸性意义的“复制”。
标签：丰田论文; 模块化设计论文; 新车丰田论文; 丰田普锐斯论文; 产品开发过程论文; 矩阵管理论文; 集成创新论文; 项目组织论文; 组织职能论文; 矩阵分解论文; 组合模式论文; 日本汽车论文; 一汽丰田论文;