|
1998年7月6日，香港新机场赤角正式开通运营。这个耗资200亿美元的建筑项目终于可以让人喘一口气了。然而，当新机场开通运营之时，令人窘迫的问题出现了：电子信号显示了错误的信息，电话系统被迫关闭，行李不见了，客货运搁浅不前。
200亿美元复杂的建筑结构的确是有史以来全球最大的建筑项目之一。在项目中，半个世界的挖掘机队伍都在忙忙碌碌地参与这浩大工程的建设。数十个承包合约和建筑项目时刻等待着协调，以完成在同一时间进行的数千项不同的又常常相互关联的复杂活动。尽管项目不时地面临着绝境，但项目最终还是从绝境中走出来了。 然而，本文开头所描述的困境还是产生了，而且这难题使机场损失了6亿美元。但这个难题与机场的建筑项目没有一点关系。他们全都来自计算机硬件与软件。
事实上，香港新机场遇到的软件开发的问题是软件业司空见惯的失败案例之一。软件业的成功只是个例外。
开始即意味着失败
Standish集团针对美国大约8000个软件项目进行了调查研究，结果表明：所有软件项目中令人惊讶地有84%未能按时完成、按预算完成或者安装所有预先要求的特性；所有项目中有超过30%在完成之前被取消了，其他则明显超过了期限，并且（平均来说）超过了预算的189%。
另一项研究发现，高度复杂的项目中有超过50%被取消了。也就是说，这样一个项目从一开始，失败的机会就要比成功的机会更高。
软件总是让人觉得战战兢兢。在上个世纪的80年代初，美利坚银行就经历了MasterNet系统失败的噩梦。为了能够抓住信息技术带来的机遇，使美利坚银行成为信托业的巨子，1982年秋天，美利坚银行决定建立一套业务和客户管理的软件系统。在经过18个月的详尽研究分析之后，一份预算为2000万美元的计划批准了，项目计划的截止时间是1984年12月31日。然而，一个除夕来了又走了，系统并没有出现。直到1986年年中，在最初期限的一年半之后，银行才得以向客户演示一个还有着太多漏洞的系统。
1987年3月，系统在晚了27个月投入正式工作。而此时，美利坚银行的IT噩梦开始了。银行在晚了3个月才能发布会计报表，于是，客户的信任开始丧失，企业客户抽走了价值40亿美元的基金。最后，美利坚银行的管理层放弃了这个项目。
这种灾难也许是在静悄悄地发生，但丹佛机场的灾难、“亚利安娜”火箭的爆炸，一直到波音“德尔塔”3号火箭的爆炸，都是软件给人留下的轰天巨响。
谁是罪魁祸首？
软件业为什么这么容易失败？到底谁是罪魁祸首？
在盖大楼的时候，也许几块砖的错误摆放或者有瑕疵并不影响整座大楼的平地拔起。但这对于软件来说就不一样了。大多数软件产品都是由上百万行源代码构成。例如，Windows95操作系统有大约1100万行代码，每一行代码至少执行一个命令，而它则会影响程序的其他部分，并且也和其他行相互影响。拿一本有300多页共计达11000多行文字的书本来做参照，Windows95打印出来的源代码则会填满大约1000本这样的书。在这些书中，每一本书只要有一个小小的排印错误，则就会导致整个系统的崩溃。
软件之所以会轻易失败的原因，除了它的源代码的复杂之外，软件系统中不同模块之间的大量相互影响也是重要原因。在软件程序中，著名的“80∶20”法则失去威信，因为一个软件程序要差不多100%地适合工作，而不仅仅是接近如此。
软件业失败的因素贯穿了软件开发的全过程。
当安达信公司为一家大的运输公司设计一个信息系统时，他们难以预测新系统会被如何使用。原因是货运市场的迅速变化，以及缺乏任何已有系统进行比较和验证。注意到这种不确定性，安达信最后不得不采用一种特别有弹性的方法设计系统结构，允许在不同的交易模式之间进行转换，而不需要任何的开发工作。客户需求很难确定，结构就必须保持相对开放，以便适应接下来的变化；否则，昂贵的返工甚至是从头开始的局面就会接踵而来。
雅虎在推出它的个人化网站MyYahoo!之前，就估计自己将不得不做三次实质性的返工，因为它必须把竞争对手在此期间推出的新特性考虑在内。这是不断变化的需求使然。
一家面向对象的软件技术公司，原来在一个软件项目的设计中包含了一个复杂的特性，它预定通过为多任务组织缓存来节省系统资源。但在做该项目的过程中，该公司发现这个特性实际上是有害而不是有助于系统的表现，而这在编码之前是不容易被预计出来的。对象设计公司不得不放弃了这一特性。这是设计在人的大脑中不容易被完全预测所造成的。
此外，软件系统，特别是软件产品，高度依赖于软件开发和运行的技术环境。当你在开发时所选择的开发工具在不断地产生新版本或者改变了设计和工作的思路，那么依赖于这种技术环境的软件开发就不得不惶惶然以应变。
“软件”遇到什么情况会夭折？
“失败在软件业是件常事，而时间估计不足引起的问题比所有其他的问题加起来还要多。”软件开发专家布鲁克斯说。而位于美国西雅图的软件著作作家麦康奈尔则补充道：“在较早阶段精确估计一个项目不只是很难的，而且在理论上是不可能的。”麦康奈尔的话反映了这样的一个事实: 最终产品的设计和特色只有在过程中才能变得清晰，而不是在开始之时。所以，项目开始时高度的不确定性使固定的时间表和最终期限成为不可能。
但很多公司并不想把这一点考虑进来，经理们从一开始就要求一张精确的时间表和开支计划。“事实上，太多的软件项目经理同意提出建立在没有任何分析或者只有很少的预测分析之上的估算。”麦康奈尔对此评论道。“而这，在一个建筑项目中，永远不会发生。”
而正是在这样一个需要高度分析的行业里，这种令人惊讶的非分析的方法使很多软件项目夭折或者失败。
过分乐观的开发人员。许多开发人员，特别是那些没有太多经验的，总是假设一切都将进展顺利。他们常常拍着胸脯打保票，认为自己可以按照时间表来交货，而事实常令他们懊恼不已。
企图通过增加人手来缩短项目日程。一些开发人员的错误是认为增加项目人手就可以缩短项目日程。这通常是错误的，原因有两个：首先，开发工作往往无法在许多工作者之间进行分割，相互依赖性使某些任务要求必须按顺序进行。正如布鲁克斯所说：“生小孩总是需要9个月，无论安排了多少女人。”其次，人手增加的同时，花在交流上的时间将同步增长。
低估项目需要的“制造”软件的时间。专业服务公司常常会走上一条错误的路线：为几个顾客开发了一些相似的系统之后，他们开始尝试着开发一个标准产品，具有为数十个用户提供的相同功能。原因很简单：大众软件市场和企业解决方案软件产品必须比服务业中的定制代码设计得更为广泛，因为它们必须致力于应对更多可能的应用和挑战。此外，软件产品必须比服务软件更多地遵循技术环境，因为顾客使用不同的操作系统和硬件系统。再次，产品说明必须更加清晰以利别人使用，或者扩展它们。
来自营销、客户和管理者的压力。一些软件开发管理专家认为，在所有软件错误里，40%是由压力产生的。软件专家伯姆在TRW公司就经历了一个由压力而产生的错误，这使他们在一个为期两年的项目上超支20%。这个项目的目标是建立一个命令和控制系统，设计运行于一个由几台计算机组成的网络上。需求分析包含了一个条款，要求系统在万一网络中有一台计算机出现故障的时候依然是健全的，但在设计中，该条款被忽视了。由于极其巨大的时限压力，设计审查根本就没有做。后来，当系统在编码中的缺陷被发现之后，整个结构不得不重新设计。他们不得不更换几个主要组件，并重写大量代码。此外，说明文件和测试案例也不得不重新编写。最后TRW将这类错误的原因添加到了它的高风险清单上，这使他们提高了在未来的项目中避免这类事故的机会。
在这类问题中，之所以会有巨大的压力，这产生于几个环节。首先，营销部门或者专业服务公司的独立客户，总是希望能够缩短日程，以便减少开发时间，以利于最快地投放市场或赶上外部期限。其次，管理层前沿不现实的期望也很常见。管理层总是倾向于用过分乐观的时间表对开发小组增加压力。而开发经理们常常既没有经验、也没有权威来和高层领导者进行成功的谈判。
“在盖好屋顶之后重建地基。”——软件业的特色蠕变。“没有人会强迫一个建筑者在上好了屋顶之后重建其地基，但在软件业，这是件常事。”PLATINUM公司的CTO波佩克说。这是指软件公司在产品开发时，所忍受的一些称为“特色蠕变”的现象。波佩克对此是有感而发，因为他经历过这样的折磨。当他还在Locus公司时，该公司正为大型计算机网络开发一个操作系统。IBM看到了这个产品，非常喜欢它，并要求做一个基本的改变——使之与IBM的网关兼容。这是个小小的要求，但却花了大量工作和一年的时间完成。“我们不得不重新设计整个系统，并重写50%的代码。”波佩克说。
在专业服务公司，重要客户充当了“需求添加者或改变者”的角色。来自客户组织各部分的“小”变动或者增添不知不觉进入了特色蠕变的清单。更糟的是这些愿望并没有反映在清单上，而是给了单个的开发人员或者顾问。这常常使专业服务公司不可能去跟踪特色蠕变。
在不可能中寻找成功
尽管软件开发如此地容易失败，但例外的公司还是诞生了。的确，他们同失败的软件公司一样面临着这样的软件开发环境：有时，它们承受着压力，要在不现实的期限前完成。其他时候，就在项目接近尾声之时，顾客仍在不停地要求新特色。而问题也来自软件本身巨大的潜在复杂性；软件首先应该具有什么功能，客户要求并不明确，而且开发项目自身也不确定。
但是那些确立了正确步骤的软件公司已经在避免这些失败方面取得了巨大进步。首先，成功公司并不忽视不确定性——它们应对它。它们同样建立质量控制机制，这同时加快了整个流程。而且它们已经达到新的范式，比如用可重复使用的组件来制造软件。
这些成功的软件公司正是在种种的不确定性和不可能中寻找成功的。麦肯锡公司通过大规模的调研发现了这些“在不确定性和不可能中找到成功”的奥秘。
向不确定性开战
成功公司并不忽视软件开发过程在时间和开支方面极大的不确定性，相反，它们向这些不确定性开战。
立足于灵活。成功的途径之一是保持产品特色的灵活性，而不是保证期限。例如，一家公司决定在某个时间发行某个产品，但将按照“必须做、应该做和能够做”的等级优先考虑这个产品的特色：必须做的特色必须明确结合到系统之中——以使系统运行和提供基本特性；应该做的特色如果有时间剩余会被实施；能够做的特色通常被推迟到下一次版本的发行——除非有奇迹发生。
适合上游-下游的变化。位于法国巴黎的一家软件工具提供商Ilog公司，开发项目有两个不同阶段，上游阶段被构造为“产生有创意的思想”流，安排了集体讨论以创造思想。“我们手握手坐成一圈，”Ilog的CTO艾伯特半开玩笑地说，“人们在过道上聊，咖啡角上都是人，整个地方看起来根本不像我们在干什么正事儿。”Ilog认识到创造过程是需要时间的。
在第一阶段里的创意投资在以后会有回报，会有更多更好的想法和更好的结构，艾伯特说。
在第二阶段——下游阶段，公司就完全变了样。对第一阶段里的思想的实施成了焦点——“不允许精神涣散。”人们专注于自己的工作，在自己的办公室里喝咖啡，会议更有中心，并且更短。
花工夫去省时间。在对TRW公司实施的一个项目进行的研究中，伯姆注意到，对软件设计后来的改进，其开支是即时改进的50到200倍。这个统计说明了在开发过程的上游阶段把事情做对的重要性。“即使上游的活动似乎在延迟项目的‘真正工作’，”麦康奈尔说，“但实际上正相反。它们在为项目的成功打基础。”此外，在上游阶段选择的产品结构不但影响整个项目，而且也常常关系到产品未来的成功。一个优越的产品结构在以后产品的可扩展性、标准性和维护等方面都有许多优势，从而真正占据竞争优势。
在人力方面的强大投入
“一个有才华的软件开发者的创造性可以是一个普通者的十倍，即使他们有着相同的过往经历。”麦康奈尔颇有感慨地说。麦肯锡公司在调研中交谈过的开发经理都同意这一点。“一个有才华的木匠会在建一项好工程时做许多决定。他通过直觉做出正确的事。”巴瑞扎，一位经验资深的开发经理说，“对一个开发人员来说也是如此。许多关于结构和编码的决定是相当直觉，依赖长期的阅历和才华。很难汇集它们，但结果会有巨大的差别。”
软件开发项目应该配备最好的人手。“最好是找到一个有创造力的程序员，而不是指望某一个程序员会变得有创造力。”麦康奈尔说。同样的原则也适用于团队。
创造有力的团队结构。并非每一个程序员都是明星选手。“在组织成长时，你会有些平庸的开发人员——这几乎是不可避免的，”PLATINUM的CEO菲利波夫斯基说，“顶尖高手们屈指可数。”
但成功的公司学会了如何将明星与那些并非同样出色的人组合在一起。如同一支医院急救队的人员配置，有一两个顶尖程序员，其他人协助他们。
比方说，顶尖医护队的“管理者”处理办公场所、供应和基本人事问题。“编辑者”接受医师不成熟的思想，并产生好的附有参考资料和更多信息的文件汇编。“工匠”创造并维护医师及其手术队伍所需的特殊工具，比如基本开发或工具检测。最后，“测试者”构造方案以检查医师的个人工作板块并监督已完成产品的测试。
把握顶尖人才。当几年前PLATINUM的一位顶尖程序员说他将不得不离开公司，因为他的妻子在加利福尼亚得到了一份好工作时，公司的COO休曼南斯基完全拒绝接受。由于不想失去这名好员工，休曼南斯基安排将终端建在这名开发人员在加利福尼亚的新居——以及他在内华达山上的小屋里。从那时起，这位快乐的员工(明显不是一个早起者)在中午起身，游戏或者徒步旅行，并为PLATINUM工作，从下午3点到凌晨3点。“当时如果我们没有建立起途径，克服地理边界限制的话，今天我可能已经出局了。”休曼南斯基说。
自此，当PLATINUM在全国范围网罗人才时，地处遥远的员工显得更加重要。“我们别无选择。问题是，把他们全迁到芝加哥来，然后失去他们，还是让他们呆在他们的所在地。”休曼南斯基解释道。人们呆在那儿，而PLATINUM投资于电信基础设施和流程整合。
在更高业绩和更多自由的流程上投资
软件工程研究所(SEI)的专家们将所有软件开发组织中的75%排在成熟度1，即一种“混乱”状态。开发人员间的合作常常处于一种特别的状态——不协调、无汇总，也没有质量检测。但是，软件开发者和管理者在建立牢固的、精心制作的开发步骤和流程上还是有些三心二意。他们认为这些努力会打击创造性和团队的士气。
但是更近一些的观察否定了这种普遍的看法。事实上，正好相反。在流程开发上的投资会有回报。开支会被更好的质量和更短的开发时间所补偿，而随着项目结束时花在许许多多漏洞上的时间越来越少，士气也提高了。
事实上，麦肯锡研究过的成功公司发行的软件，只有其他公司软件所包含缺陷的平均三分之一，这可以由不断上升的客户满意程度反映出来。按照伯姆的说法，修补错误所花的时间占了典型开发时间的大约50%。“这是效率低下和风险的巨大来源，”伯姆说，“而缺陷未被发现的时间越长，修补的工作量越大。”
所以，通过采用保证质量的流程，软件公司除了可以避免客户不满意之外，还可以节省时间和工夫。在一份南加州大学的研究中发现，当公司提高了其开发流程的成熟水平时，确实在整体上节约了时间。平均说来，在其水平从1(混乱的)上升到5(持续增长)时，每上升一个等级，总的开发成本下降5%～10%。在洛克希德公司(它达到了等级5)，其成熟流程的结果是震撼性的：在5年连续的软件流程改善后，缺陷下降了90%，上市时间下降40%，而开发费用下降了75%。
创造性和士气上升，而非下降。大多数软件开发者并不是流程的拥护者——他们认为流程使工作“没有创造性”。但是，对60%以上曾经运行软件流程改善规划的组织的调查表明，情况恰恰相反。在使用精心设计的流程的公司中，大约60%的员工的士气极佳或良好，相反，在那些很少面向流程的公司里，这一比例只有20%。这个结果对开发者和管理者都是一致的。而在真正应用流程的人之中，超过80%的人强烈反对流程阻碍了创造性或者使组织僵硬和官僚化这一看法。麦肯锡公司的调查采访再次证实了这些发现。
许多“流程提高者”即将到来。改善流程的方法很多。一种是“能力成熟模型”方法，由软件工程研究所(SEI)创造；另一种是琼斯和他的SPR公司的SPR方法，大多数的工具和方法集中于从一开始就保证质量。他们同样强调避免返工和更好的文件汇总及测试。许多小些的咨询公司专门应用和培训这些方法。
这些方法中有两个特别重要：受益者介入和日常构建。这些技术在麦肯锡公司全球调查的成功公司里已经十分有用。
使项目受益者广泛介入
在Standish集团对8000个美国软件工程的调查中，用户参与成了在软件开发过程中惟一最重要的成功因素。麦肯锡的全球调查证实了这一点。而且它也显示，十分重要的是，不仅包含传统终端用户，而且还包含其他受益者，如营销部门。
睡在软件公司的客户。在麦肯锡公司的调查中，比起不成功公司，成功公司其客户参与重要性平均要高20%。这有许多好处。较早的客户参与能阐明其要求，以防在后来阶段广泛返工。同时，早些向用户说明额外特性的开支，帮助他们优化特色，以及防止昂贵的、不必要的“遍地种金”。最后，允许用户预览软件有助于程序员发现软件产品的脱漏和错误。
世界领先的软件公司正在将越来越多的资源倾注在用户参与上。微软有它自己的工艺性实验室——由平面镜、摄影机和其他设备装备的单独的房间。它们全部用于观察和记录由终端用户做的测试。Intuit在20世纪80年代初，因其毫不夸张的“跟踪用户”到其家中以确定他们的特殊需求而声名大噪。
户通常是十分支持的，并准备出力。他们中有些甚至成了软件公司的常客。当Sun的硅谷网络应用工具分公司Netdynamics开发其2.0版时，一名用户差不多在开发地点住了整整一个星期，以便与开发人员更密切地相互交流。
专业服务公司甚至比产品公司需要更强的用户参与。缺乏大宗买进的最终用户会导致整个项目的失败。此外，在项目过程中，用户得做出许多决定，他们影响了日程、开支或功能。密切介入软件的用户更能理解其决定的含义，而且他们通常做出更快、更好的决定；他们有更现实的期望，也了解在所附加特色和开支及时间之间的权衡。
在欧洲最大的专业软件服务公司Cap Gemini，所有来自客户的“额外要求”都被追踪，而客户严格地对此负责。但在任何要求被满足之前，Cap Gemini的顾问们将质疑客户是否需要那些额外特色——客户会为其付钱。例如，客户常常改变用户界面或报告格式。这些改动本质上更像是装门面的，并没有增加新的价值，但却要花大价钱去完成。
在许多情况下，Cap Gemini的客户一旦认识到这层含义时，就会放弃他们的要求。而此后，他们常常对Cap Gemini更为满意。一次最近的研究证明，用户满意度通常随着紧密介入而显著上升。
这些论点大多也可用于内部，尤其是市场营销部门。
与开发经理联姻的营销专家。在对象设计公司，每一个在要求确定之后公布的产品附加功能，都必须由一个专门的“公司变更委员会”核准。“只有真正重要的改变能够通过，”前工程副总裁巴瑞扎说，“而且我们放弃其他功能作为交换，以保持最小的特色蠕变。”巴瑞扎把在开发项目中遵循和控制变化视为保证期限的最重要成功因素之一。营销和开发人士不得不在客户对额外功能的兴趣与完成他们的工作量之间进行权衡。如果这些想法变化很大，是否能确保有一个开发人员和营销专家共同支持的决定，巴瑞扎没有深入。“我告诉营销和开发人员：你们两个是结婚了。而我并不准备做婚姻顾问。”他半开玩笑地说。
不仅是特色的变化，总体的项目成功也应该由用户追踪。
经常与所有受益者进行项目评估。在一家安全交易处理软件供应商BROKAT，所有受益者一直会被告知项目进展。用户和营销人员与一个项目追踪电子系统联系。“让他们完全了解，能睡个好觉，”CEO安德里斯说，“而这使我们能够及早确定可能的风险。”在成功的服务公司里，项目评价要多两倍以上。BROKAT并非独一无二。我们全球调查的成功公司严格追踪其项目的成功——并且与所有受益者分享结果。在成功的公司里，重大项目评估的时间间隔要比不成功者平均短40%以上。对于专业服务公司，与客户一起进行的公开评估是十分重要的：它们直接影响客户对项目表现的感觉。在成功的服务公司里，项目评价要多两倍以上。
除了广泛的用户参与，日常构建也是软件开发的一个有力工具。在调查中只有几家公司曾面对建立日常构建的挑战，而一旦成功，就会有随后的回报。
日常构建：早晨的第一件事是消除缺陷
不像汽车公司花6到9个月来建立一个汽车原型，软件公司每天建立一个原型，被称为日常构建。
在设计一辆汽车时，一群人负责设计广泛测试，必要的变化被确定。一个关键挑战来自部件之间的相互依赖。比方说，发动机设计的变化会影响车罩下的其他部件。一个更大的发动机突然占用了空调器的空间；它必须被移走，而靠近发动机的其他部件也得如此。要完成一个汽车原型，6到9个月是必需的。
与之相似，独立的软件队伍负责开发最终软件产品的部件。他们开发之后，测试其功能，并纠正其缺陷。最后，建起了一个原型，用以测试系统如何作为一个整体运行。差别在于，利用它们的数字媒体，软件公司可以经常建立原型。
在麦肯锡的全球调查中，他们发现成功公司中有94%每天或至少每周完成构建，而不成功公司绝大多数每月甚至更少去做构建。许多没有日常构建的公司说它们想要将这些过程置于适当位置——但它们发现这一期望很难达到。
那么一个日常构建是如何运作的?而且即使很难建立，同时增加了项目的日常开支，为什么仍然很需要?
日常构建如何运作?开发队伍为他们专有的组件独立工作。在白天结束时，他们测验和调试一个代码，通过将其插入过去原型的一个拷贝，来看看它在整个系统前后关系中的表现。一旦它与过去原型一起运行，他们就为一个新的日常原型提供他们的代码。所有其他队伍也做同样的事，而在白天结束时，所有的新组件都齐备了。晚上，所有组件被自动连接——而一个新原型就建起来了。这个原型——目前的日常构建——自动经历一系列测试，以检验当这些组件相互影响时会发生什么。第二天上午，到公司来的每一个开发人员会接到一个在通宵测试中发现的所有缺陷的清单，加上一个新原型的拷贝。这些开发者的第一个任务是纠正在一个构建中发现的所有缺陷，然后为新功能工作。
为什么日常构建如此有威力?很容易想像在一个每个月甚至更长时间建立原型的组织里会发生什么。要花几个星期去挖掘此前已经寻找了很长时间的那些错误。没有相互影响的测试，开发人员只能找到他们自己的部件内部的缺陷，但绝对没有那些相互影响的组件之间的缺陷。
有了日常构建，缺陷在它们产生之后立刻被纠正了，这缩短了发现和改正的时间。集成错误也相应减少。
于是，尽管日常构建很难建立，它仍有巨大的优点。总体上，日常构建明显提高了生产力和终端产品的质量。它们为整个项目提供了比过去好得多的状态控制，而且也提高了士气。“士气的影响是令人吃惊的。当有一个能运行的系统时，即使只是一个简单的系统，积极性就会上升。”布鲁克斯说。于是再一次，就像其他看起来“冗长乏味的过程”一样，这一个过程提高了业绩以及士气。
上面两个例子——日常构建以及受益者介入——说明了良好的开发流程的威力。但除了提高士气和质量水平之外，在软件开发中一个真正的业绩提高还没有来临。
合成组件时代？
数十年来，开发经理一直在呼唤新的“神奇解决方法”，以便可以在软件开发中带来一个根本的或真正的革命性进展。而今，合成组件正在显著改变软件开发游戏。
许多软件专家赞同软件组件的变革会有帮助。考克斯曾经观察到：如果软件开发能从“自己建设一切”转向“简单地集成定制的可重复使用组件”方式，这对整个行业就意味着巨大的生产力和质量提升。
但使用组件开发还面临着种种困难。比如要求大量前期投资，需要改变开发人员的整个思想形式。
由于有巨大的利益，看上去组件重复利用会在软件业被广泛采用。大多数大型软件公司至少已经认识到这股潮流，并正为此投资。未来对组件的通常标准，像为客户开清单的标准功能，将会更加促进组件再利用。同时，像SAP R/3这样的软件已经显示了标准化的巨大潜力。R/3和其他标准化的ERP解决方案，如Baan或Oracle的产品，正在替代大多数定制的ERP软件，而且创造了巨大的生命力和质量提高.
|
