哈索的平台

纵览1999年全球企业软件市场的版图，大型企业在企业软件上的累计投入已经超过三千亿美元，但一个悖论正在吞噬这些投资的价值：系统之间的集成成本，在当年就高达四百亿美元以上。AMR Research在第四季度发布的调查报告将这一困局比作一座没有统一城市规划的城市——每栋建筑都按照自己的蓝图建造，而连接它们的道路、桥梁和管道系统却要靠每家住户自己搭建。这个比喻后来被反复引用。

当这份报告被送到SAP沃尔多夫总部的董事会上，哈索·普拉特纳把它摊在桌上，翻到那张柱状图：1995年到1999年间，企业软件许可证收入的年复合增长率为百分之二十八，而集成服务支出的增长率却达到了百分之四十一。他把目光从图表上抬起，对在座的董事们说了一句话：“客户不是在买软件，客户是在缝合软件。谁能为他们缝合，谁就拥有客户。”

在芝加哥以西三十英里的地方，麦当劳总部的数据中心里，十二台IBM大型机昼夜不停地运转，恰恰印证着这个判断。这里运行着七套彼此独立的企业软件系统：财务和制造用的是SAP R/3，人力资源是PeopleSoft，供应链管理刚刚切换到了i2，客户关系管理的Siebel系统正在部署，此外还有一套遗留的物流系统和两套自开发的报表工具。麦当劳的CIO曾在一次行业闭门会议上描述过这个局面：每年IT预算的百分之二十三不是花在新功能上，而是花在让这些系统彼此对话上。每当任何一个供应商发布新版本，麦当劳的四十人集成团队就要开始一轮为期三个月的回归测试，检查两百多个接口是否依然畅通。这个比例不是麦当劳独有的。

这个判断的语境是清晰的：Oracle的拉里·埃里森正在市场上用互联网叙事攻城略地。E-Business Suite被包装成一套统一的、基于互联网架构的应用套件，埃里森在每一个公开场合都在强调一个词——“统一”。统一的数据库、统一的应用服务器、统一的用户界面。这个叙事在1999年具有强大的吸引力，因为它是针对麦当劳式困境的直接回应：如果所有应用都来自Oracle，集成成本将不复存在。

但普拉特纳看得更透。他在1999年秋天的一次内部战略会议上，让团队做了一个简单的计算：如果一家典型的全球五百强企业要完全替换到Oracle的E-Business Suite，它需要放弃在SAP、PeopleSoft、Siebel和i2系统上累计投入的、平均高达两亿四千万美元的软件资产，以及更贵的、无法用金钱衡量的十几年的业务流程定制和员工培训。这个替换成本是如此之高，以至于埃里森的统一叙事在逻辑上只有一个漏洞：它假设客户愿意为了统一而推倒重来。

普拉特纳的判断是：绝大多数客户不会这么做。他们会继续生活在碎片化的现实中，而谁能为这个现实提供最好的管理工具，谁就会成为他们不可或缺的供应商。这个判断构成了SAP从1999年到2002年战略转型的起点。它不是对Oracle叙事的被动回应，而是一次主动的重新定位：SAP不再试图说服客户用SAP替换所有其他系统，而是把自己变成连接所有系统的中枢。这个定位一旦成立，SAP的竞争对手就不再是Oracle或PeopleSoft或Siebel，而是集成成本本身。SAP要销售的产品，不再是某一个应用模块的功能深度，而是让客户已有的所有应用模块协同工作的能力。

但这个定位在SAP内部引发了激烈的反对。反对声音最集中的地方，是SAP的应用开发部门，尤其是那些从八十年代就加入公司的资深开发经理。这些人在过去十年里，将德国制造业的最佳实践一行一行地编码为R/3的标准化流程。他们相信SAP的成功根基在于对业务流程的深度理解，在于能够告诉客户“这是行业最佳实践，你应该按照这个流程来做”。在他们看来，平台化战略意味着SAP将承认一个他们花了十年否认的事实：在某些应用领域，别人做得更好。

1999年11月，一位负责制造模块的资深副总裁在内部会议上站起来发言，他的声音里带着明显的愤怒。会议纪要虽然经过了措辞上的软化，但核心逻辑保留了下来：“如果我们告诉客户，他们可以用Siebel的CRM而不是我们的，那么三年后他们会问，为什么还要用SAP的财务模块而不是Oracle的？五年后他们会问，为什么还要用SAP的制造模块而不是i2的？”这个逻辑链条是清晰的，也是冷酷的：平台化战略的终点，可能是SAP自身的模块被逐一替代，SAP从一个产品公司变成一个纯粹的连接器公司，而连接器的利润率永远低于产品的利润率。

平台派的核心人物是普拉特纳本人，以及他身边一群关注企业架构的技术战略家。他们的论点建立在一个经验数据之上：在SAP过去五年实施的超过两万个项目中，百分之六十二的定制开发工作不是在扩展R/3的功能，而是在编写R/3与其他系统的接口。这个数据来自SAP自己的项目实施审计，它的含义是明确的：客户已经在用脚投票。他们不会因为买了SAP就放弃其他供应商，他们只是在痛苦地缝合这些系统。

如果SAP不提供一套标准的集成平台，这些客户会转向谁？答案有三个：第三方中间件厂商，如TIBCO或webMethods；系统集成商，如埃森哲或IBM全球服务部；或者，Oracle的E-Business Suite——不是因为它更好，而是因为它至少承诺了统一。平台派的结论是：与其让集成能力成为每个客户独自承担的隐形成本，不如让SAP把集成本身变成产品。这样，SAP的护城河就不是某一个应用模块的深度，而是整个应用生态的连接枢纽。当一家公司用SAP的财务系统、PeopleSoft的人力资源和Siebel的客户关系管理时，如果SAP提供了连接这三者的标准平台，那么替换SAP的财务系统就不再是一个孤立的决策，而是一个需要同时替换集成平台的决策——这个替换成本比单独替换一个应用模块高出一个数量级。

这场辩论在1999年12月初达到了白热化。普拉特纳召集了一次连续两天的战略会议，地点不在沃尔多夫的主楼，而在距离总部十五公里的一家酒店里，以避免日常事务的干扰。参加会议的是SAP执行董事会的全部成员，加上各产品线的负责人和首席架构师，总共不到三十人。会议的第一天，应用开发部门与平台战略部门各自陈述立场，争论的焦点从技术架构延伸到商业模式，再延伸到SAP的组织身份。

第二天上午，普拉特纳做了一个长达九十分钟的发言。他没有用PowerPoint，而是在白板上画了一张图。这张图后来成为SAP平台战略的原始蓝图。图的左侧是SAP现有的应用模块：财务、制造、销售、人力资源。图的右侧是竞争对手的应用模块：PeopleSoft的人力资源、Siebel的客户关系管理、i2的供应链管理。图的中部是一个方框，普拉特纳在方框里写了三个词：消息路由、数据映射、流程编排。然后他从方框向左右两侧画了箭头，每个箭头上标注的不是技术协议，而是业务语义——采购订单、客户主数据、成本中心、物料清单。

普拉特纳转过身来，对会议室里的人说：“我们不一定要拥有每一个应用。但我们必须拥有应用之间的对话。对话本身就是产品。”这个表述在会议纪要中被记录为“对话即产品”，它后来成为mySAP.com战略的核心隐喻。

普拉特纳的推演是：如果SAP坚持产品公司的定位，它将在每个应用领域面对不同的最佳选手——CRM对Siebel，供应链对i2，人力资源对PeopleSoft——这是一场永远打不完的多线战争。而如果SAP转型为平台公司，这些竞争对手的客户同时也是SAP的潜在客户，因为只要它们的系统需要与SAP的核心财务和制造模块通信，SAP的集成平台就可以成为收费的通道。普拉特纳的原话是：“我们不需要在每一个战场上取胜。我们只需要成为所有战场之间的交通枢纽。”

这个推演说出了平台战略最深刻的经济逻辑：从向客户销售应用软件，转向向客户销售应用之间的连接。连接本身成为了产品，而产品的价值不取决于它实现了什么业务功能，而取决于它连接了多少个系统、协调了多少种数据格式、保证了多少个跨系统事务的一致性。这个价值定位一旦被客户接受，SAP的竞争壁垒就从功能深度转向了集成广度——一个竞争对手可以复制SAP的任何一个应用模块，但很难复制SAP平台上已经连接的上万个系统实例和数千个预置的集成适配器。

1999年12月，SAP在费城举办了mySAP.com的全球发布会。这不是一次普通的产品发布。SAP包下了费城会议中心的主展厅，搭建了一个模拟的全球企业运营中心：大屏幕上实时显示着跨越三个大洲的供应链状态，二十个工作站分别运行着SAP、PeopleSoft、Siebel和i2的系统，但它们共享一个统一的Web门户界面。演示场景经过精心设计：一个采购经理通过浏览器发起请购，系统自动调用了SAP的物料管理模块检查库存，同时通过一个开放的接口向Ariba的电子采购平台发送询价，在收到报价后，再通过另一个接口触发PeopleSoft的人力资源模块更新成本中心的预算。整个过程在技术上是跨应用的，但在用户体验上是统一的。

普拉特纳在主题演讲中说了一句后来被广泛引用的话：“客户不应该关心一个业务流程跑在哪个供应商的系统上，就像打电话的人不需要知道信号经过了哪些交换机。”这句话暴露了SAP战略转型的真正雄心：成为企业应用层的操作系统。在个人电脑的世界里，微软的Windows定义了应用程序如何与硬件交互、如何彼此通信、如何管理内存和文件系统。普拉特纳的愿景是，在企业应用的世界里，mySAP.com将定义不同业务模块如何交换数据、如何协调事务、如何管理主数据的一致性。这个定位一旦成立，SAP就从ERP市场的参与者变成了整个企业软件生态的规则制定者。

但费城的发布会展示的还是一个愿景，而不是一个可交付的产品。mySAP.com在1999年底还只是一个叙事包装——它用精心设计的演示场景呈现了SAP的战略方向，但没有提供实现这个方向的技术基础设施。真正的工程挑战在于，SAP必须开发一套能够连接不同技术栈、不同数据模型、不同事务处理机制的集成平台，而且这套平台必须足够稳定，能够承载全球最大企业的核心业务流程。

这不是写一组API那么简单。SAP的R/3系统基于ABAP语言和自有的数据字典，而它需要连接的PeopleSoft系统用的是关系数据库和C++编写的应用服务器，Siebel用的是微软的SQL Server数据库和Java编写的Web服务器，i2则运行在Unix平台上，使用专有的内存驻留算法进行供应链优化计算。让这些系统在事务级别上保持一致——例如，一个跨系统的采购订单要么在所有系统中完整提交，要么在所有系统中完整回滚——需要一套全新的分布式事务协调机制。这个机制必须能够在不同数据库的事务管理器之间传递提交和回滚指令，必须在某一步失败时能够将已经执行的操作逆向恢复，必须能够处理网络中断、系统崩溃和超时等各种异常情况。

这个工程任务落在了SAP在沃尔多夫的一个新成立的架构实验室身上。实验室的代号是“NetWeaver”，这个名称在2000年初首次出现在SAP的内部技术文档中。NetWeaver的设计原则从一开始就与Oracle的E-Business Suite走了完全不同的路线。Oracle的策略是将所有应用统一到自己的数据库和应用服务器上，用技术栈的一致性换取集成的简化。这是一个工程师偏爱的解决方案：如果你控制所有层面，你就可以优化所有层面，你可以保证数据模型的一致性，可以保证事务处理的原子性，可以保证安全策略的统一执行。

但NetWeaver的设计师们接受了一个更混乱的现实：企业的应用环境是异质的，而且将永远异质。他们的目标不是消除异质性，而是管理异质性。这个哲学差异在NetWeaver的第一个技术白皮书中被表述为一句话：“我们不假设客户会放弃已有的系统。我们假设客户已有的系统会继续存在十年以上，而我们的任务是让这十年变得可以忍受。”

NetWeaver的核心组件是一个称为“Exchange Infrastructure”的消息代理。它的设计理念是：任何应用系统，无论是SAP的还是非SAP的，都可以通过适配器连接到这个代理，代理负责在不同的数据格式、通信协议和业务规则之间进行翻译和路由。这个设计在概念上类似于互联网的路由器——路由器不关心数据包的内容来自哪个应用，它只负责把数据包送到正确的目的地。但在企业应用层面，这个翻译任务远比网络路由复杂：一个采购订单在SAP系统中可能用物料编号作为主键，而在i2系统中用SKU编号，在Siebel系统中用产品ID。Exchange Infrastructure必须维护一套跨系统的主数据映射规则，确保当SAP说“物料4711”时，i2理解的是“SKU-ACME-4711”，而Siebel理解的是“产品ID-ACME-Widget”。

这个主数据映射的复杂性，是Oracle的E-Business Suite试图通过统一数据库来回避的问题。在Oracle的架构中，所有应用共享同一个数据字典，因此不存在主数据不一致的问题——所有应用都使用同一个客户表、同一个产品表、同一个供应商表。但Oracle为此付出的代价是：客户必须放弃所有非Oracle的应用，或者在Oracle的数据库上重新实现这些应用。这意味着将PeopleSoft的人力资源数据模型迁移到Oracle的数据模型上，将i2的供应链优化表结构转换为Oracle的表结构，将Siebel的客户关系管理对象映射为Oracle的行和列。这本质上是一种技术上的焦土政策：为了统一，你必须先烧掉所有竞争对手的痕迹。

NetWeaver选择了更艰难但更现实的道路：接受主数据必然不一致的现实，然后提供一套工具让客户管理这种不一致。这套工具后来演变为SAP的主数据管理模块（MDM），它在2002年之后成为NetWeaver平台中最具战略价值的组件之一。MDM的设计思想是：不试图强制所有系统使用同一套主数据，而是建立一套映射规则和同步机制，让不同系统的主数据在关键字段上保持一致，同时允许非关键字段的差异继续存在。例如，客户地址在SAP中可能用德语格式存储（邮编在前，城市在后），在Siebel中用美国格式存储（城市在前，州和邮编在后），MDM不强制统一格式，而是确保当SAP向Siebel发送客户数据时，格式被正确转换。

NetWeaver的第二个关键组件是“Web Application Server”，它将SAP的ABAP应用服务器与一个兼容J2EE标准的Java应用服务器融合在同一个运行时环境中。这个设计决策在SAP内部引发了激烈的技术争论。ABAP是SAP的专有语言，拥有超过两百万行的R/3业务逻辑代码，是SAP最核心的技术资产。全球有超过两万名ABAP开发者在SAP的生态系统中工作，他们构成了SAP最忠实的技术社区。Java是开放的互联网标准，拥有更广泛的开发者基础，但SAP对Java运行时环境没有控制力——Java的演化方向由Sun Microsystems和Java社区决定，而不是由沃尔多夫决定。

一部分工程师主张完全拥抱Java，放弃ABAP，以吸引更广泛的开发者社区。他们的论点是：ABAP是一种专有语言，它的开发者池是有限的，而Java的开发者池是无限的。如果SAP坚持ABAP，它将永远无法吸引硅谷的年轻开发者，这些人在大学里学的是Java，他们不会为了SAP去学一门只在沃尔多夫使用的语言。另一部分人坚持ABAP的优越性，认为放弃ABAP等于放弃SAP二十年积累的编程范式——ABAP的设计是针对企业业务逻辑的，它在数据库访问、事务处理、报表生成等方面有着Java无法比拟的效率。

普拉特纳本人的技术判断打破了僵局。他在2000年夏天的一次架构评审会上指出，SAP的客户已经在ABAP技能上投入了巨大人力，强迫他们转向Java将引发客户的反叛。但越来越多的企业IT部门开始要求基于标准的开发环境，特别是那些需要将SAP与互联网应用集成的客户——他们的Web开发团队用的是Java，他们不想为了集成SAP而学一门新语言。普拉特纳的解决方案是一个双引擎架构：同一个应用服务器同时支持ABAP和Java，两者共享同一套内存管理、会话管理和安全机制。这个设计让SAP既保留了对现有生态的兼容，又打开了对互联网标准的世界。

这个双引擎架构在技术上是优雅的，但在实现上是痛苦的。ABAP和Java的内存模型完全不同：ABAP使用静态内存分配，在编译时确定内存布局；Java使用动态内存分配和垃圾回收，内存布局在运行时不断变化。让两种内存模型在同一进程中和谐共存，需要一套复杂的隔离机制，确保ABAP的内存操作不会破坏Java的堆结构，反之亦然。NetWeaver的架构团队花了近两年时间才将这个双引擎打磨到可以承受生产环境负载的水平。但一旦实现，它就给了SAP一个Oracle无法复制的优势：在Oracle的应用服务器上，Java是唯一的开发语言，这意味着Oracle失去了所有那些在ABAP生态中积累了十年经验的开发者。而SAP的平台同时向两个社区开放，它的潜在开发者基础比Oracle大了一个数量级。

NetWeaver的第三个核心组件是“Business Intelligence”，它源于SAP在1997年收购的一家以色列公司。商业智能在2000年之后成为企业软件的新战场，因为客户开始意识到，在完成了ERP系统的建设之后，下一个需求是从这些系统中提取决策支持信息。Oracle的策略是依靠数据库层面的查询优化和数据仓库技术，将BI定位为数据库的自然延伸——如果你已经用Oracle数据库存储了所有数据，那么Oracle的BI工具可以最有效地查询这些数据。

SAP的策略则是将BI嵌入NetWeaver平台，让它能够从多个应用系统中提取数据，而不仅仅是SAP自己的系统。这个差异在战略上至关重要。如果一家公司同时使用SAP的ERP和Siebel的CRM，它可以用SAP的BI工具分析客户行为与财务数据之间的关联——例如，哪些营销活动带来了最高的回款率，哪些客户群体的信用风险与购买频率相关。而Oracle的BI工具只能看到Oracle应用中的数据。这意味着，在多供应商的现实环境中，SAP的BI工具因为能够跨越供应商边界而变得更有价值，而Oracle的BI工具因为只能在Oracle的围墙内工作而失去了战略意义。

2001年春天，SAP在内部启动了一个代号为“Project Madrid”的计划，目标是将mySAP.com的愿景落实到一套可交付的产品套件中。这个计划的负责人是夏嘉曦，一位在SAP内部以执行力著称的技术副总裁。夏嘉曦的团队面临一个经典的工程管理困境：NetWeaver的架构设计需要时间打磨，但市场窗口不等人。Oracle的E-Business Suite虽然在技术上粗糙，但它已经在市场上建立了一个清晰的互联网叙事，而SAP的客户开始不耐烦地质问：“你们的互联网产品在哪里？”

夏嘉曦的解决方案是将mySAP.com拆分为两个层面：面向客户的解决方案套件和面向开发者的技术平台。解决方案套件包括mySAP CRM、mySAP SCM、mySAP SRM等一系列以“mySAP”命名的应用模块，它们共享一个基于Web的用户界面，并且通过NetWeaver的Exchange Infrastructure实现彼此集成。技术平台则是NetWeaver本身，它作为独立的产品提供给客户和合作伙伴，让他们能够在SAP的技术基础设施上开发和集成自己的应用。这个双层结构巧妙地将市场压力转化为了产品节奏：应用模块可以快速推向市场，回应客户对互联网功能的迫切需求；技术平台则可以按照自己的工程节奏打磨，因为它面向的是开发者和系统集成商，这些人对成熟度的要求更高，但对时间窗口的敏感度相对较低。

mySAP.com的应用模块在2001年陆续发布。从技术角度看，这些模块并不完全是新产品。mySAP CRM的核心业务逻辑大量复用了R/3的销售与分销模块，mySAP SCM的优化引擎来自SAP在1998年收购的一家德国供应链软件公司，mySAP SRM的采购流程引擎来自R/3的物料管理模块。真正的创新在于用户界面和集成方式：所有mySAP应用都通过浏览器访问，它们共享一个统一的门户框架，用户可以在同一个屏幕上看到来自不同模块的信息——库存数据来自SAP的物料管理，供应商评分来自mySAP SRM，客户订单状态来自mySAP CRM。这个门户框架本身就是一个轻量级的集成平台，它允许客户将非SAP的应用也嵌入到门户中，前提是这些应用提供了Web接口。

但真正的战略武器不是mySAP.com的应用模块，而是NetWeaver平台本身。2002年初，SAP在汉诺威CeBIT展会上正式发布了NetWeaver的第一个版本。发布会的演示场景与1999年费城的mySAP.com发布会形成了对照：两年前，演示的重点是用户通过浏览器完成一个跨应用的业务流程；两年后，演示的重点是开发者如何用NetWeaver的工具将三个不同供应商的系统集成为一个协调的整体。观众从业务用户变成了技术架构师，信息从“SAP可以连接所有应用”变成了“SAP可以成为你所有应用的基础设施”。

这个信息的转变反映了SAP战略转型的深层逻辑：SAP不再仅仅是一个应用软件供应商，它正在成为一个企业应用的基础设施提供商。应用软件的价值在于它实现了什么业务功能——财务记账、库存管理、生产排程。基础设施的价值在于它连接了什么——多少个系统、多少种数据格式、多少个跨系统事务。应用软件的替换成本是功能替代的成本：找一个能做同样事情的软件。基础设施的替换成本是重新布线的成本：把已经连接的所有系统断开，再重新连接到新的基础设施上。后者的成本比前者高出一个数量级，而且随着连接数量的增长而增长。

NetWeaver的第一个版本包含了超过两百个预置适配器，覆盖了当时市场上主流的ERP、CRM、SCM和数据库系统。这些适配器不是简单的数据格式转换器，它们封装了目标系统的业务语义。例如，连接PeopleSoft的适配器不仅知道如何将SAP的采购订单格式转换为PeopleSoft的格式，还知道PeopleSoft的采购审批流程需要哪些额外的数据字段——审批层级、预算检查规则、供应商资质验证——以及PeopleSoft在处理部分收货时的特殊逻辑：如果一张采购订单有十个行项目，而只收到了前三个，PeopleSoft如何更新订单状态、如何触发发票验证、如何处理未交货的七个行项目。

这些知识不是从技术文档中可以轻易获取的，它们来自SAP与客户在无数个联合项目中的经验积累。每一个适配器背后，都是SAP的工程师花了数月时间在客户现场与目标系统搏斗的成果。这种知识积累构成了SAP平台战略最深的护城河。

Oracle可以用营销叙事说服客户相信统一的数据库架构是更好的选择，但当客户真正开始实施时，他们会发现，将一套运行了十年的PeopleSoft人力资源系统迁移到Oracle数据库上，需要的不仅是数据迁移工具，还需要对PeopleSoft的业务逻辑有深入理解——而Oracle的工程师恰恰缺乏这种理解，因为PeopleSoft是Oracle的竞争对手。SAP的NetWeaver团队则不同，他们在帮助客户集成PeopleSoft系统的过程中，积累了关于PeopleSoft内部机制的大量知识，这些知识被编码为适配器和集成指南，成为了SAP平台的一部分。

这是平台战略的一个微妙之处：它让SAP从竞争对手的成功中获利。每当一家公司选择了Siebel的CRM而不是SAP的CRM，SAP的应用部门失去了一笔收入，但SAP的平台部门获得了一个潜在的集成项目——因为这家公司几乎肯定会用SAP的ERP系统，而它们需要让Siebel与SAP对话。在传统的产品公司逻辑中，失去应用订单就是纯粹的损失。在平台公司的逻辑中，失去应用订单可能意味着获得一个平台订单，而平台订单的长期价值往往高于应用订单，因为平台一旦部署，替换成本极高。

这个逻辑在2002年开始在财务数据上显现。SAP的许可证收入在2001年经历了短暂的下滑——部分原因是互联网泡沫破裂后的IT支出紧缩，部分原因是Oracle的竞争压力——但在2002年恢复了增长。根据SAP 2002年年度报告，总营收从2001年的七十三亿欧元增长到七十四亿欧元，增幅虽然温和，但收入结构的变化更为显著：与集成服务相关的收入在2002年增长了超过百分之三十，远高于应用许可证收入的增长率。这些集成服务收入包括NetWeaver平台的许可证、集成适配器的销售，以及SAP咨询部门提供的系统集成服务。

普拉特纳在2002年第四季度的财报电话会议上，首次将“集成收入”作为一个独立的增长指标提出，这标志着SAP在内部已经完成了从产品公司到平台公司的认知转变。

但平台战略的真正代价不是财务上的，而是组织上的。当SAP开始将自己定位为“企业应用的中枢平台”时，它必须回答一个令应用开发部门不安的问题：如果平台的价值在于连接所有应用，那么SAP自己的应用在平台上是享有特权地位，还是与竞争对手的应用平等竞争？如果是前者，那么SAP就是在利用平台偏袒自己的应用，这将削弱平台作为中立连接者的可信度——客户会问：你的平台对Siebel的集成支持和对SAP CRM的集成支持是同等的吗？如果不是，我为什么要信任你的平台？如果是后者，那么SAP的应用部门就必须在功能上与Siebel、i2和PeopleSoft正面竞争，而它们不再能依靠“因为是SAP所以集成更好”的优势。

普拉特纳的选择是后者。他在2002年的一次内部备忘录中明确写道：“NetWeaver平台必须对SAP应用和非SAP应用提供同等的集成支持。如果我们的CRM模块不如Siebel，那么客户应该能够用Siebel替代我们的CRM，而NetWeaver不应该因此惩罚客户。”这段话在SAP的应用开发部门引发了轩然大波。CRM团队的负责人公开质疑：如果公司不保护自己的应用，那么应用部门的研发投入还有何意义？如果SAP CRM和Siebel在NetWeaver上享有同等的集成待遇，客户为什么要选择SAP CRM？

普拉特纳的回答是：应用部门的意义在于做出最好的应用，而不是做出因为平台锁定所以客户不得不接受的应用。如果SAP CRM在功能上不如Siebel，那么客户选择Siebel是正确的，SAP应该从平台收入中获得补偿，而不是用平台锁定来强迫客户接受一个次优的应用。这个回答定义了SAP此后二十年的组织张力。应用部门和平台部门成为了公司内部的两个竞争性力量：应用部门希望平台为自己的产品提供特殊优化——更快的集成响应、更丰富的预置映射、更优先的适配器更新——平台部门则坚持技术中立原则，认为任何对SAP应用的特殊优待都会损害平台作为中立基础设施的长期可信度。

这种内部竞争在短期内造成了大量的协调成本——两个部门在每一个集成接口的设计上都要争论优先级和资源分配——但在长期内产生了一个健康的机制：SAP的应用被迫在功能上保持竞争力，而SAP的平台被迫在开放性上保持可信。当2003年之后Salesforce开始在CRM市场崛起时，SAP的CRM团队已经习惯了在功能上正面竞争，而不是依靠平台锁定的保护——这个习惯在后来的云时代变得至关重要。

Oracle的E-Business Suite在2001年至2002年间经历了一场静默的信任危机。这场危机的根源不在于Oracle的营销能力——埃里森的互联网叙事依然具有感染力——而在于产品交付与叙事之间的鸿沟开始被客户感知。E-Business Suite的第一个版本在1999年发布时，Oracle承诺了一套完全基于互联网架构的统一应用套件：所有应用共享同一个数据库、同一个应用服务器、同一个数据模型。但早期采用者很快发现，Oracle所谓的“统一”更多是用户界面层面的——所有应用都通过浏览器访问——而不是架构层面的。

在浏览器背后，Oracle的财务模块、制造模块和人力资源模块仍然运行在不同的数据模型上，它们之间的集成依赖大量的PL/SQL存储过程。这些存储过程的维护复杂性与SAP的ABAP接口并无本质区别，甚至因为Oracle的模块来自多次收购而更加混乱。Oracle的财务模块来自它自己的开发，制造模块来自对一家名为Datalogix的小公司的收购，人力资源模块来自对PeopleSoft的模仿性开发——这三个模块的数据模型由三组不同的工程师在不同的时间设计，它们对“客户”“供应商”“产品”“成本中心”这些基本业务对象的定义存在微妙的差异。

在演示环境中，这些差异被精心设计的演示脚本掩盖了。但在真实的客户环境中，当数据量达到数百万条记录、并发用户数达到数千人时，这些差异就会暴露为性能瓶颈、数据不一致和难以追踪的逻辑错误。2001年，一家美国大型零售商在尝试部署Oracle E-Business Suite的制造模块时，发现该模块的数据模型与Oracle财务模块的数据模型存在根本性的不一致：制造模块使用标准成本法——将实际成本与标准成本的差异计入差异账户——而财务模块使用实际成本法——直接记录实际发生的成本。两者之间的差异需要一套复杂的成本差异分摊逻辑来弥合。

这套逻辑在Oracle的演示环境中运行良好，但在该零售商的真实数据量下——每天超过一百万条成本记录——性能急剧恶化，月末结账流程从预期的四小时延长到了三十六小时。这家零售商最终暂停了项目，并聘请了一家咨询公司来评估是否应该回到SAP的R/3。这个案例在Oracle内部被严格保密，但在SAP的销售团队中广为流传，成为了一个有力的反面教材。

SAP的销售人员在面对犹豫的客户时，不再直接攻击Oracle的营销叙事——那太强大了——而是提出一个简单的问题：“你们是否愿意做一个为期两周的概念验证测试，用你们自己的数据量来跑一下Oracle的制造模块和财务模块之间的集成？”这个问题是致命的，因为它将战场从叙事层面转移到了工程层面，而工程层面正是Oracle的软肋。

这类案例的累积效应在2002年开始显现在市场份额数据上。根据AMR Research的统计，在2001年至2002年间，Oracle在制造业ERP市场的份额从百分之十五下降到百分之十二，而SAP的份额从百分之二十八上升到百分之三十一。在CRM市场，Siebel依然保持领先，但SAP的mySAP CRM在2002年获得了包括西门子和宝马在内的几个标志性客户。这些客户选择SAP CRM的原因，不是因为它比Siebel在功能上更强大——事实上，在2002年，Siebel的CRM在销售自动化和呼叫中心管理方面仍然优于SAP的CRM——而是因为它与SAP ERP的集成成本远低于Siebel与SAP ERP的集成成本。

西门子的评估团队计算了一个数字：如果用Siebel的CRM，集成到SAP ERP的成本大约是CRM软件本身许可证成本的一点七倍；如果用SAP的CRM，集成成本是零点三倍。这个差距不是来自功能差异，而是来自预置集成——SAP CRM和SAP ERP之间的集成适配器是现成的，而Siebel和SAP ERP之间的集成需要从头开发。这个选择逻辑恰恰印证了普拉特纳的平台战略：当集成成本成为客户决策的关键变量时，平台的价值就超过了单个应用的功能深度。客户不再问“哪个CRM最好”，而是问“哪个CRM与我的ERP集成成本最低”。在这个问题面前，SAP的CRM即使功能上略逊于Siebel，也能因为集成优势而胜出。

但平台战略也带来了一个SAP无法完全控制的后果：它让客户开始习惯于一个多供应商的世界，在这个世界中，没有一家供应商能够满足所有需求，而集成平台成为了新的权力中心。这个习惯在短期内对SAP有利，因为SAP是集成平台的提供者。但在长期内，它埋下了一个隐患：如果集成平台本身可以被替代——例如，被一种新的、基于互联网标准的集成架构替代——那么SAP的平台优势就会瓦解。

而这个替代者正在2002年的硅谷悄然兴起。Salesforce在1999年成立，到2002年已经拥有超过五千个客户。它提供的不是ERP而是CRM，但它的交付方式——完全通过互联网，无需安装任何软件，按月和按用户数付费——正在定义一种新的企业软件消费模式。这个模式的核心不是技术架构而是商业模式：客户不需要购买软件许可证、不需要购买服务器、不需要雇佣集成团队，只需要一个浏览器和一张信用卡。Salesforce的创始人马克·贝尼奥夫在2002年的一次行业会议上说了一句让传统软件供应商不安的话：“软件的时代结束了。从现在开始，一切都是服务。”

普拉特纳在2002年底已经看到了这个趋势。他在一次内部战略会议上警告说：“NetWeaver解决了今天的问题——如何让现有的系统协同工作。但它没有解决明天的问题——如果未来的系统根本不需要集成，因为它们从一开始就运行在同一个云上。”

这个警告显示，SAP的平台战略虽然成功地回应了Oracle在1999年发起的互联网叙事进攻，但它本质上是对一个碎片化现实的防御性适应，而不是对一个统一化未来的进攻性定义。SAP通过接受碎片化赢得了短期的战略主动权，但这个主动权的前提是碎片化持续存在。如果云计算的愿景——所有应用运行在同一个基础设施上——最终实现，那么SAP的集成平台将从一个不可或缺的连接器变成一个可以绕过的中间层。

这个矛盾在2002年还只是一个理论上的担忧，但它在随后的五年中将逐渐成为SAP面临的最重大的战略挑战。Oracle在这个问题上有一个天然的优势：它的数据库已经运行在全球大多数企业的数据中心里。如果未来的企业应用确实运行在云上，Oracle的数据库可以成为那个云的底层基础设施——它已经在那里了。SAP没有这个优势，它的平台运行在应用层而不是数据层。普拉特纳的平台战略让SAP在应用层的竞争中赢得了架构上的主动权，但它没有解决一个更根本的问题：当数据层本身成为新的平台时，应用层的平台是否还有存在的必要？

2002年结束时，SAP站在一个矛盾的位置上。它在产品层面用mySAP.com和NetWeaver回应了Oracle的挑战，在市场份额上重新巩固了领先地位——SAP在全球ERP市场的份额从1999年的百分之二十六上升到2002年的百分之三十一，而Oracle的份额从百分之十四下降到百分之十二。在战略高度上，它将竞争从功能对比提升到了架构层面：客户不再只是比较SAP的财务模块和Oracle的财务模块哪个更好，而是开始思考一个更根本的问题——在多供应商的现实环境中，谁应该成为连接所有系统的中枢？

但SAP也在这个过程中接受了一个它曾经拒绝接受的现实：没有任何单一供应商可以满足大型企业的所有软件需求。这个接受让SAP成为了一个更成熟的公司——它不再试图成为一切而是试图连接一切——但也让它失去了一个曾经驱动它二十年增长的核心信念：SAP的系统可以是企业唯一的系统。当这个信念消散后，SAP的护城河就不再是“我们提供一切”，而是“我们连接一切”。

这是一个更现实的定位也是一个更脆弱的定位，因为连接者的角色可以被替代——替代者往往来自那些不受历史包袱约束的新进入者：他们不需要兼容过去三十年的技术遗产、不需要维护两千个预置适配器、不需要同时支持ABAP和Java。他们可以从零开始为云计算时代重新设计连接的方式。

普拉特纳在2002年圣诞前夕发给全体员工的邮件中用一句简短的话总结了这一年：“我们学会了在别人的系统旁边生存这是痛苦的但也是必要的。”这句话没有说出的后半句是：学会了在别人的系统旁边生存的SAP也必须学会在一个有Salesforce、有云计算、有新一代挑战者的世界中生存。在那个世界里平台的价值不再取决于它连接了多少个旧系统而取决于它能否在一个新系统不断涌现旧系统逐渐消亡的生态中始终保持不可或缺。这个问题的答案不在沃尔多夫的架构实验室里而在硅谷那些刚刚拿到A轮融资的创业公司的车库里。