从精益生产到多项目管理

如果企业希望有效使用其资源，经理人则需要管理项目组合，知道如何分享和复用技术及其他形式的知识，并维持恰当水平的设计和生产质量。

超越单个项目层次复用知识

在美国和日本的软件工厂，以及印度和其他地方的IT服务企业，寻求范围经济的过程中可能存在着在巨大的压力。客户对于独一无二的系统通常偏向于专门的项目团队至少有部分时间在其场所开发独特的技术。甚至对于大众市场产品，项目经理和工程师通常喜欢拥有自主权，来开发看起来适合市场的任何技术。另一方面，为了在企业层或者在企业部门内部获得效率，高管需要引入集中协调，并且超越单个项目层次复用知识或者技术。换言之，企业需要找到集权和分权的恰当平衡点，构建他们自己的权变框架以帮助中层经理人决定何时采用哪种方法。

最成功的产品开发项目经常产生于比较小型的、专注的自治团队—由金?克拉克和藤本隆宏所称的“重量级的”项目经理领导的。的确，丰田在20世纪50年代率先使用重量级的项目经理。这种方法帮助它超越日产和其他竞争者。当本田在20世纪60年代开始设计汽车时，也采用了这种开发方式，并且持续使用，获益很大。许多作家和研究项目，包括麻省理工学院精益生产方式创新实验室，聚焦于如何结合重量级的项目经理的观点与大野泰一强调的一般原理，即通过过程合理化和改进消除浪费。与美国和欧洲汽车生产商所采用的功能导向的产品开发方式相比较，这种“精益”开发方式提供了许多的优势。

传统的产品开发的“职能”管理通常将工程师组织为具有长期的连续计划的部门，以替代现有模式或者为组合添加新的模式。这种结构有益于实现比较“彻底的”创新，利用狭窄但是深入的功能性技术的累积，聚焦于内部设计而不是外包，例如开发新的引擎技术或者新的车底设计。但是，这类项目通常在不同职能领域间的协调性较弱，因为职能部门保留了对预算和人员的大部分控制权。相比之下，尤其是自20世纪80年代和90年代早期以来，丰田、本田和其他日本企业的产品开发精益管理一般组织专门的项目团队，项目成员来自不同的设计和生产职能部门。“重量级的”项目经理领导团队，并且对预算、人员、设计和营销拥有广泛的决策权。这种权力使得项目可以遵照短期的、过程型的计划，具有许多耦合的阶段(例如概念开发)以及重叠的阶段(例如设计和生产准备)。

日本人还将许多设计外包给同样协同工作的供应商。总体目标就是集中有限的研发资源，快速推出新的车型，替代旧的车型，帮助赶上外国竞争者。日本汽车生产商实际上在20世纪90年代早期明显地在产品开发和生产方面遭遇了一些“精益限制”，并且在转移到范围经济战略。例如，本田管理层意识到在研发上支出太多，因为独立的重量级团队没有复用其他项目中开发的组件，例如本田的创新性的引擎、操舵和悬置系统技术。丰田管理层得出了类似的结论：精益产品开发导致太多的产品品种和太频繁的替代车型。这两家企业都逐渐地调整了他们的方法。在随后的阶段超越了精益，出现了一种更加协调的同时管理多个项目的方法，得到的结果大多数是积极的，偶尔有一些不良后果。

新战略：多项目管理

我和延岗健太郎将这个新的战略称之为“多项目管理”。多项目管理不同于简单地使用职能组织或者传统的“重量级的”矩阵使工程部门针对不同的产品设计组件。后来的规模导向方法带来了通用在过去十几年所经历的结果，当时其大约六个部门所生产的大多数的产品看起来基本上是相同的。

多项目管理通过一个简单的战略解决了复用与差异化的平衡问题。(1)创造共享关键组件的新产品，但是在共享之前设计组件。(2)为独立的项目设立独立的开发团队，拥有他们自己的经理人和人员，由某位高级主管根据产品开发的组合战略进行协调。在这种方法中，项目经理更多是中量级，而非重量级，因为他们要向高级主管报告，而且不能完全控制诸如预算或使用哪种技术的事项。存在部分但不是完全授权。

项目独立和多项目组合计划有助于确保每个产品与众不同，并潜在地吸引不同客户，以及包含独特部分的混合体和战略复用组件。我们还认为如果多项目在时间上重叠，那么将更容易管理，因为这可以推动设计中的沟通和相互调整。我们研究了十二年内生产的几乎每一辆汽车，的确发现采取多项目方法的企业在销售和市场份额上取得了不同凡响的改进，因为客户似乎对具有新技术的特色产品反响极好。企业还节省了大量工程成本。

我们为了分析项目绩效，首先基于车身底座平台的寿命以及复用该平台的最初项目和随后项目在时间上的重叠，将汽车产品分为四类。我们通过分析车身底座和地板规范(轴距和轨道)以及悬置系统及其设计，衡量平台的变化。研究人员可以在许多不同的产业采用这种分析以识别内部平台复用。第一类，即新设计项目，主要是从零起步开发平台。或者第二类，并行技术转移项目，复用仍在进行的旧项目的平台。或者第三类，顺序技术转移项目，复用他们的平台，但是从已经完成的项目中获取平台。第四类，设计改进项目，稍微改变以前的车型就得到了平台。更多依赖并行转移技术战略的汽车生产商的表现显著优于更多依赖其他战略的企业。当他们开发了一个新的产品平台，迅速将其应用于另一个正在进行的项目之中。依赖新设计来更新其产品线的企业就不得不耗费更多的工程资源来开发新车型。顺序地转移平台或者依赖于设计改进的企业以及市场中大量较旧的技术就被淘汰掉了。

针对范围经济的组织结构选择

并行转移战略中所观察到的范围经济并不是偶然发生;该战略需要大量的规划和协调。该方法似乎与特定的组织战略配合更加有效。预先规划对于确立项目组合、协调来自于基础项目的设计和部件复用至关重要。同样重要的是重叠运行基础项目和并行转移项目，以加强项目团队间的沟通，必要时要对设计做出调整，共享工程成果。来自于两个重叠的项目的工程师可能共同地设计一个新的悬置系统或车门结构部件。

正如顺序和设计改进项目中所采取的复用新技术也比复用五年前或更早的现成设计好得多。通常，复用旧技术需要的重组工程工作量与从头开始开发新技术一样多。原因就在于五六年之后，旧技术方面的专家经常已经离开了企业，因此当试图复用旧技术时，难以咨询他们。

最后，为了使并行转移战略发挥作用，企业就需要一位高管负责多项目组合，并协调每位项目经理。冲突是很容易发生，比如说，当一个基础项目必须延长时间以设计和测试要在另一项目中复用的部件时。如果高管仅仅是根据该基础项目的预算和计划评估项目经理的表现，而不进行调整以帮助其他产品，那么该项目经理将不会有适当的激励来合作。这就是系统开发公司的软件工厂中所遇到的一部分问题。

显然，多项目管理给项目经理和工程师施加了一些限制。他们不能像在重量级项目管理系统中那样，自由地去做任何他们想做的事情。但是，仍然存在足够的空间，使团队成员在联合设计以及每个产品独特的部件或子系统方面实验和迭代，例如，车身外壳或车辆内部(客户看得最清楚的部件)。

我们抽样的所有汽车企业都曾经采用了这四种产品开发战略，除了日本人在研究期间没有采取顺序转移战略之外。美国企业也仅仅采用了一次并行转移战略。汽车生产商为了进行这些不同的项目，采用了一系列组织架构。大多数企业采用了传统的矩阵式，职能部门的工程师加入到项目中，项目由一位联络经理或项目管理办公室协调。

在这种结构下，职能经理掌握了大部分的人员和预算控制权。两家企业(本田以及复制本田模式的克莱斯勒)以产品团队形式组织，将人员、预算、计划和内容的大量控制权交给“重量级的”项目经理。几家企业(通用汽车、日产和马自达公司暂时地)采取了“准中心”组织方式，通过服务于所有项目的职能部门管理部分工程工作，例如引擎或开发驾驶培训。他们将其他工作划分到开发中心的项目中(例如，车身设计)。如果企业拥有足够的项目，则这种混合结构使项目较容易分享工程工作。第四个选择就是纯粹中心组织(丰田和福特)。企业把它们的工作分类为相似项目的群集，并且在需要时，复制工程功能。

我必须再次说明在共享优良技术和节省生产和工程成本方面，设计可复用组件极其有效。但是组件的质量必须绝对可靠，否则有缺陷的组件将在许多不同产品中扩散。

汽车和软件产品开发比较

经理人和工程师使用异型矩阵时，须决定哪些组件要完全标准化并在多个项目间无变化地复用，哪些组件或子系统需根据每个项目进行定制。这意味着多项目管理比专业化的精益团队更为复杂，因为企业需要协调职能部门以及项目团队

企业应该能够识别四类组件组或开发团队：不同的单个组件组、不同的子系统组、通用子系统组和标准化组。此外，我们的研究背景是汽车产品开发，但是经理人可以将这种框架应用到软件工厂或其他形式的产品开发之中。我们甚至可以考虑这样设计服务：一些服务“包”可以共享通用要素，同时其他的需要依客户或者服务合同类型而定。

以汽车为例，每个产品的内部和外部零部件通常不同，而且经常是客户首先注意到的部分。企业应该通过独立的产品团队设计这类与众不同的子系统。但是标准的子系统和零部件，如音频设备、座位或电池，可以在多个产品间通用，需要的协调比较少。独立的组件团队可以容易地设计这类零部件。其他昂贵的、非常值得共享的子系统，如车身底座平台、引擎或刹车系统，需要在不同的工程团队以及项目团队间进行高水平的协调。在这些情况下，企业可以创建多项目团队。当日本软件工厂，如东芝，为设计框架和针对多个客户的单个组件复用作计划时，即使他们销售的是“定制”系统也采用了这种多项目方法。微软在个人电脑软件开发中协调多个项目，在开发Office套装软件时，实施了并行技术转移。

标准的Office产品由微软之前设计、开发并作为独立产品销售的几个子系统所组成，包括：Word(文字处理)、Excel(电子数据表)、PowerPoint(图形演示)以及更近一些的Outlook(电子邮件和客户日程表)。微软自20世纪90年代中期以来，原来的桌面应用程序(Word和Excel，及紧随其后的PowerPoint)共享了近一半组件。但是直到微软特意创建Office业务单元，成立组件团队开发通用组件并协调独立的产品团队的需求，这种共享才出现。例如，实际上在开发Office套件前，Word、Excel和PowerPoint都进行文字处理、打印、剪贴编辑、文件管理和一些制图。单个的产品团队开发这些共享组件。

因为Word团队在文字处理、文件管理和打印方面最有经验，微软管理层(比尔·盖茨发起的分享运动)20世纪90年代中期要求该团队为其他Office产品团队以及其他应用产品单元开发这些模块。Excel团队最擅长于图表，因此微软为自己和其他团队开发这个模块。微软还发现，如果过多团队参与通用组件设计需求的决策，则设计任务会变得太复杂以至于难以管理。因此，总是由某个团队领导，然后领导团队负责咨询其他团队。如果在需求上存在分歧，那么由最重要的三个团队(Word、Excel和Office)投票来决定。

对于其他产品团队可以直接拿来就用于设计中的复用组件，例如标准的打印模块或文件管理模块，微软仅仅使用需要很少或不需要与其他职能部门协调的组件团队。如果组件需要特殊功能或设计更改，微软则使用多项目组件团队。例如，在Excel和PowerPoint中处理文字的用户不需要Word具有的所有功能，因此，Word团队必须咨询其他产品团队，并设计标准的文字处理模块，以便不同的产品团队能够根据自身需要削减功能。Office套件中的每项产品还具有一些独特的组件，显示了与不同团队的其他子系统的主要相关性，如PowerPoint中的演示向导(wizard)实用程序。PowerPoint产品团队可以独立地开发这个功能，但是必须确保这项技术能够与从其他团队输入的其他功能相兼容。设计审查、每日构建及集成与系统测试都是协调需求和同步组件开发的有效方法。与在并行技术转移中一样，重叠项目有助于在软件开发中协调变化、实时调整并分享工程成果。

对经理人的启示

首先，对于运营不存在明显的规模经济，但是有许多机会共享技术或专业知识的企业，范围经济极其有价值。除了自动化，这实际上是创建高效率和高效益的产品开发或者专业服务组织的最佳方法。其次，经理人必须能够胜任管理更加复杂组织的工作，这类组织以共享技术和专业知识为中心，并且在冲突或权衡取舍发生时，能够找到中间地带。如果你的企业按业务单元组织，这些单元间为利润而竞争，经常陷入如何分配收入和成本的战争中，那么你就不大可能在范围经济上取得成功。当然，这也使得此类企业容易受到精通范围战略的竞争者攻击，这些竞争者克服了组织或技术上的权衡取舍，并且更加有效地利用企业资源和能力。

例如，当高管要求项目团队共享组件或标准化过程时，就放弃一些自治权和柔性。从极端来看，如果生成的产品没有满足他们的需求，或者范围战略使某个设计糟糕的或危险的组件扩散，客户也很可能就会抱怨。但是不协调的项目也不会在针对多个客户的多个项目间利用好技术或者好创意。因此，很多时候，介于效率导向的结构，如职能工程部门，以及创造性导向的组织结构，如重量级项目团队之间的组织结构可能是软件、汽车和许多其他产业的企业的最佳选择。软件工厂和汽车产业的多项目管理都依赖于异型矩阵，高层主管监督包含相关项目和共享组件的群集，发挥着媒介作用，当执行良好时，尤其在技术相对稳定的时候，就会取得很好的效果。

非常新的技术，或被颠覆的技术似乎不适用于范围经济(即，软件工厂或多项目管理)，除非技术的稳定性和表现可预测性达到了一定水平。这似乎是日本难以将其大型机软件工厂以及强调复用组件转移到PC和互联网软件的原因之一。相比之下，通过聚焦于知识或复用领域知识，而不是复用组件，印度IT企业成功实施了许多各类项目。这也许还能解释为何多项目管理似乎在汽车产业的比较成熟的组件方面有效，而在新技术领域不是很有效，例如使用传感器和软件来替代机械零组件。复用也是在PC软件比较稳定的部分有效，例如，桌面应用程序(MicrosoftDOffice)的功能。

但是，当新技术是新颖的，客户很大可能会积极响应时，没有在尽可能多的产品间共享此技术，似乎明显在浪费工程资源和错失市场机会。在汽车产业，只要质量得到控制，并行转移战略和异型矩阵是实现共享的有效方法。当企业仅仅追求新设计时，就不会有这种收益;当企业复用旧的技术时，正如顺序转移和设计改进战略，其收益也是很有限的。

软件工厂和多项目管理的几个方面也似乎广泛地适用于交付专业服务。聚焦领域很重要，因为这使企业有可能遇到相同的客户问题，发现重复任务、标准化过程、知识复用或甚至引入自动或半自动的客户交互方式的机会，谷歌、易趣、亚马逊和其他互联网服务公司就是如法炮制。克莱顿?克里斯坦森和他的合著者在其2009年的著作《创新解决方案》中针对合理化美国保健服务和医疗系统提出了类似的建议。

最后，实际问题就是：如果范围经济具有如此明显的收益，为什么不是所有经理人和企业都采用这个法则?首先，企业需要足够大才能拥有多种产品，产品间共享组件或复用其他形式的知识和技术。许多企业满足这个要求。但是经理人需要迈出另外一步，需要重新思考其产品或服务组合及其执行的战略。经理人可能还必须调整其组织和激励计划。除非竞争所迫，与培养与众不同的能力一样，并非所有经理人都希望进行这种尝试，承担广泛分享的风险。高级经理人还必须管理一个更加复杂的组织：有意在集权和分权之间制造紧张，然后为两者投票(例如通过将多项目经理强加于项目经理之上，采用“中量级”项目经理结构)。许多经理人不喜欢矩阵结构，因为这样人们有多个领导，需要分享权力和共同决策。事实也确实如此。但是日本人(以软件工厂和汽车企业)和微软(以Office产品团队)已经表明有可能设置这样一个过程，在一个矩阵内存在首要的和次要的权利，如此谁负责什么就非常清楚了。