拉里的反击

人们后来将Oracle的逆袭归结为一场巧妙的叙事战，但它的起点，恰恰是一种对成功的隐蔽恐惧：SAP的标准化战略在征服全球市场时取得辉煌胜利，而咨询生态催生的庞大定制化产业正在系统性削弱这种标准化的长期可行性，下一次架构变革时兼容性灾难的账单尚未到期——这个判断，正是Oracle撬动SAP市场根基的支点。不是因为Oracle有更好的产品，而是因为拉里·埃里森发现了一个更锋利的武器：他不需要在产品上击败SAP，只需要让客户相信，SAP的成功本身就是一个问题。

这则广告在行业内部引发了巨大争议。SAP的合作伙伴和客户纷纷质问Oracle：E-Business Suite真的存在吗？还是只是一张效果图？

Oracle的回应是邀请一批分析师和记者到总部参观原型系统。这个原型系统确实可以运行，但功能极其有限，只能处理最简单的查询和审批流程，完全无法支撑真正的企业级业务。但Oracle的演示聚焦在视觉效果和用户体验上，而不是功能完整性上。

分析师们看到的是一个漂亮、流畅的浏览器界面，操作起来就像使用网页一样简单。相比之下，R/3的客户端界面虽然功能强大，但需要安装、配置和培训，学习成本要高得多。

这种对比是一种精心设计的误导。它用原型系统的用户体验来对比成熟产品的部署复杂度，用未来的可能性来对比现实的局限性。但它的效果是显著的。1997年底，至少有三家大型制造企业推迟了R/3的采购决策，理由是“等待Oracle的E-Business Suite成型”。

这三家企业后来有两家确实选择了Oracle，一家在1998年底回到了SAP。但延迟本身已经对SAP造成了伤害——它打乱了SAP的销售节奏，让SAP的销售团队花更多时间回答关于技术路线的问题，而不是展示产品功能。

SAP的高管们对这种局面感到愤怒。普拉特纳在1997年的一次内部会议上说，Oracle的“互联网ERP”是“空中楼阁”，是在“用幻灯片而不是产品竞争”。但他也承认，SAP需要更积极地回应互联网叙事，而不是简单地否认它的意义。

他指示研发团队加速开发基于浏览器的R/3访问层，同时要求营销团队制定更清晰的技术路线图沟通策略。

但SAP的组织结构决定了它很难在叙事战上与Oracle对抗。SAP的决策流程是共识驱动的，任何重大产品方向都需要经过多个委员会的讨论和批准。Oracle的决策流程是埃里森驱动的，他可以在一次午餐会上决定一个十亿美元级别的战略转向。

当埃里森决定将互联网叙事作为核心战略时，他只需要告诉团队：从现在开始，所有产品开发、所有营销活动、所有客户沟通都必须围绕互联网这个主题。而SAP要做出同样的决定，需要说服联合创始人、执行董事会、全球研发主管和区域市场负责人。

这种组织差异在1998年变得更加明显。这一年，Oracle在互联网叙事的支撑下，发动了一场针对SAP客户的定向挖角战。

Oracle的销售团队被授权提供极具侵略性的价格条件：任何放弃R/3转投Oracle的客户，可以获得高达50%的许可费折扣，以及免费的数据库迁移服务。Oracle还在全球范围内建立了一个“SAP替换中心”，专门负责帮助客户从R/3迁移到Oracle E-Business Suite。

虽然E-Business Suite还没有正式发布，但Oracle承诺客户可以先购买许可，等到产品发布后再实施，在此期间可以继续使用现有的R/3系统。这个策略在商业道德上引发争议。

批评者认为Oracle是在“预售空气”，用尚未完成的产品锁定客户，冻结他们的采购决策。但Oracle的回应是，客户签订的是有条件的合同，如果E-Business Suite没有按时发布，客户可以取消合同并获得全额退款。这个保证在一定程度上减轻了客户的风险顾虑，但同时也给Oracle的项目团队施加了巨大压力——如果E-Business Suite不能在1999年按时发布，公司将面临大量合同取消和信誉损失。

1998年5月，Oracle又做了一笔关键收购，以24亿美元收购了客户关系管理软件公司Vantive。这笔收购的战略意图是扩展Oracle在非制造领域的应用软件覆盖，从ERP延伸到CRM、销售自动化和客户服务。Vantive的产品在功能上不如行业领导者Siebel先进，但它有一个Siebel没有的优势：它运行在Oracle数据库上，而且技术架构相对简单，更容易整合到E-Business Suite中。

收购Vantive之后，Oracle的应用软件产品线基本覆盖了企业管理的所有主要领域：财务、人力、制造、供应链、客户关系。现在缺少的只是一个统一的交付平台。E-Business Suite项目团队在1998年下半年进入了封闭开发阶段，目标是赶在1999年上半年的Oracle OpenWorld大会上发布第一个正式版本。

SAP的处境变得更加微妙。1998年，SAP的营收突破了40亿马克，约合25亿美元，比1995年翻了一倍多。R/3的客户数量超过5000家，遍布全球各个行业。从任何传统指标来看，SAP都处于历史上最好的时期。

但Oracle的叙事战正在侵蚀SAP的市场信心。越来越多的行业分析师开始问同一个问题：SAP有互联网战略吗？这个问题本身已经预设了一个判断：没有互联网战略的公司将被淘汰。

SAP的回应是，它有互联网战略，而且正在开发相关产品。但它的回应总是慢一步，总是以解释和辩护的姿态出现，而不是以颠覆和定义未来的姿态出现。

这种不对称在1998年秋天的一次行业会议上达到了顶点。埃里森和普拉特纳同时受邀参加一个CIO论坛，并在同一个环节发言。埃里森首先发言，他用一贯的锋利语言描述了互联网ERP的未来，并宣布Oracle的E-Business Suite将在1999年发布。他说：“客户机/服务器架构是二十世纪的技术，互联网计算是二十一世纪的技术。SAP的R/3是二十世纪最好的ERP系统，但我们的客户正在为二十一世纪做准备。”

普拉特纳随后发言。他没有直接回应埃里森的挑衅，而是详细介绍了R/3的新功能，包括新的报告工具、新的供应链计划模块和新的行业解决方案。他展示了R/3在汽车、化工和消费品行业的成功案例，用数据和事实说明R/3的价值。当被主持人问及互联网架构时，普拉特纳说，SAP正在研究基于浏览器的访问方式，但企业级应用需要更多时间才能完全迁移到互联网上。他说：“我们不卖幻灯片，我们卖产品。”

这句话在现场引发了一阵笑声，但笑声中带着一种微妙的尴尬。普拉特纳的回应在逻辑上是正确的——Oracle确实在卖“幻灯片”，至少到目前为止。但论坛结束后的走廊讨论中，许多CIO表达了一种矛盾的情绪：他们尊重SAP的工程严谨性，但同时也被Oracle的远景所吸引。一位来自制造业的CIO对他的同行说：“我不确定Oracle能不能在1999年交付一个真正的互联网ERP，但我知道互联网是未来。如果SAP不拥抱互联网，我担心我的R/3投资会在五年内过时。”

这种情绪正是埃里森想要的效果。他不需要让客户立即转向Oracle，他只需要让客户对SAP产生疑虑。一旦疑虑产生，客户的采购决策就会延迟，而延迟本身就会给Oracle争取时间。

1998年，Oracle的应用软件业务营收增长了35%，达到12亿美元，虽然仍然远低于SAP的25亿美元，但增长率已经超过了SAP的22%。更重要的是，Oracle的新客户中，有超过40%来自SAP的竞争性项目——要么是SAP正在争取的客户，要么是已经在使用SAP但考虑扩展的客户。

这个数字让SAP的高管们警觉起来。1998年11月，SAP的执行董事会召开了一次战略会议，专门讨论如何应对Oracle的互联网叙事战。会议持续了两天，讨论非常激烈。一部分高管认为，Oracle的互联网叙事是“虚张声势”，SAP不应该被它牵着鼻子走，而应该继续专注于产品功能和质量。另一部分高管认为，SAP需要更积极地拥抱互联网，否则会在客户认知上失去优势。

最终的妥协方案是：SAP将加速开发基于互联网的新一代产品，但不会像Oracle那样提前宣布。这意味着SAP在产品开发上先行一步，但在叙事战场上继续落后。这个妥协方案反映了SAP组织文化的深层惯性：它无法像Oracle那样将营销叙事置于产品实现之前，因为它的整个组织架构和激励机制都是围绕产品工程构建的。

1999年5月，Oracle在旧金山举办OpenWorld大会，正式发布了E-Business Suite的第一个版本。这个版本包括了财务、采购、项目管理和客户关系管理模块，制造模块仍然在开发中，预计在1999年底发布。埃里森在主题演讲中宣布，E-Business Suite是“全球第一个完全基于互联网架构的企业应用套件”，它“无需客户端安装，无需中间件维护，所有功能通过浏览器访问”。发布会的场面盛大而隆重，埃里森的演讲被直播到全球四十多个城市。

但实际的产品演示揭示了一个不那么壮观的现实：E-Business Suite的功能深度和稳定性都远不如R/3。它的制造模块缺位，供应链计划功能有限，多语言和多币种支持不够完善。许多参加发布会的分析师和记者注意到，演示中的很多操作需要等待几秒钟才能完成，这在真实的业务环境中是无法接受的。但Oracle的回应是，这是第一个版本，后续版本会不断完善。埃里森在新闻发布会上说：“我们花了三年时间追赶SAP的功能，我们不需要再花三年。我们只需要让客户相信，互联网架构是正确的方向，而Oracle是唯一能够提供这个方向的公司。功能可以通过迭代来补充，但架构不能。一旦客户选择了错误的架构，他们就会被锁在过时的技术栈上。”

这个说法的逻辑是：功能性缺陷可以通过持续开发来弥补，但架构性错误无法通过补丁来修正。换句话说，Oracle承认自己在功能上落后，但声称自己在架构上领先。这个论证框架将竞争从功能比较转向了技术路线选择，而技术路线选择本身就是一个更容易被叙事影响的领域，因为它涉及的是未来而不是现在。

1999年下半年，Oracle的制造模块终于发布，填补了E-Business Suite最大的功能空白。虽然这个模块的功能仍然不如R/3全面，但它已经足够让一些中型制造企业考虑Oracle。特别是在那些已经在使用Oracle数据库的制造企业中，E-Business Suite的数据库绑定策略开始发挥作用。这些企业发现，如果他们已经为Oracle数据库支付了昂贵的许可费，再购买Oracle的应用软件可以获得更好的集成性和更低的维护成本。1999年结束时，Oracle的应用软件业务营收达到18亿美元，比1996年增长了近三倍。

SAP的营收仍然领先，达到约30亿美元，但增长率已经放缓到18%。更重要的是，Oracle成功地将互联网叙事植入到了企业软件市场的集体意识中。从1999年开始，任何一家评估ERP系统的企业，都会问供应商同一个问题：你们的互联网战略是什么？这个问题本身，就是Oracle叙事战的胜利纪念碑。

SAP在这一时期并非没有回应，但它的回应始终带着一种笨拙。这种笨拙不是源于技术能力的不足——SAP的工程师们完全有能力开发基于互联网的产品——而是源于一种更深层的不适应：一个习惯于用产品说话的公司，在面对一个擅长用概念说话的公司时，其优势也可能成为弱点。当SAP的工程师们在实验室里耐心地构建互联网架构时，Oracle的营销团队已经在全球范围内定义了什么是互联网ERP。当SAP的产品准备好时，客户对互联网ERP的认知已经被Oracle的叙事所塑造。这种不对称性在1999年底的一次客户调查中得到了清晰的呈现。

调查问CIO们：你认为哪家公司在互联网ERP方面处于领先地位？超过60%的受访者选择了Oracle，尽管Oracle的E-Business Suite在功能上明显不如SAP的R/3。当被问及理由时，大多数受访者说：Oracle更早地拥抱了互联网，而且它的愿景更清晰。这个结果揭示了一个残酷的事实：在技术转折期，清晰的概念比完善的产品更有说服力。

但Oracle的胜利是有代价的。E-Business Suite的第一个版本在技术上存在严重缺陷，许多早期客户在产品部署后遇到了性能问题、功能缺失和稳定性故障。

1999年底，至少有五家签订了E-Business Suite合同的大型客户推迟了项目上线，原因是产品无法满足他们的业务需求。这些客户中的一些开始私下重新评估SAP的R/3，尽管他们在公开场合仍然支持Oracle的互联网战略。这个代价在短期内没有影响Oracle的业绩，因为大多数客户的合同是多年期的，上线延迟不会立即反映在营收上。

对SAP反应更为致命的，是Oracle叙事机器不为外人道的运转机制。1997年夏天，埃里森授意成立了一个直接向他汇报的“互联网架构委员会”，其成员并非工程师，而是产品营销、分析师关系、媒体沟通和投资者关系的负责人。这个委员会的唯一任务，是将“互联网计算”从一个技术术语转化为一个产业共识。它每周召开一次会议，审视所有面向外部的信息——广告文案、新闻稿、演讲幻灯片、分析师简报——确保每一个信息都包含同一个核心判断：客户机/服务器架构正在过时，浏览器是企业应用的唯一未来。

Oracle的营销预算在这一时期大幅向分析师关系倾斜。公司邀请Gartner、Forrester和Meta Group的分析师参加闭门简报会，向他们展示Oracle的互联网架构路线图，并暗示SAP在客户端技术上的投入将成为遗留资产。这些简报会不是在产品发布之后召开的，而是在产品开发还处于原型阶段就开始了。

分析师的报告通常需要六个月才能完成，而Oracle的策略是提前布局，让分析师的报告在E-Business Suite发布之前就已经为市场预期做好了铺垫。1998年初，Gartner发布了一份关于ERP市场趋势的报告，首次提出了“后ERP时代”的概念，并指出“互联网架构将重新定义企业应用的交付和消费方式”。这份报告虽然并未明确推荐Oracle，但其分析框架与Oracle的叙事高度一致：将互联网架构定义为下一代标准，将客户机/服务器定义为上一代遗留。这份报告在CIO群体中产生了深远影响，成为Oracle销售团队在客户拜访中反复援引的第三方权威背书。

SAP并非没有注意到这种被分析师议程牵着走的危险。但它的应对方式暴露了另一种组织惯性：SAP试图用研究的严谨性来回应叙事的传播力，用自己的分析师关系团队制定一份详尽的“互联网架构可行性白皮书”，用技术论证来反驳Oracle的远景叙事。这份白皮书历时八个月才完成，其间经过SAP瓦尔多夫总部、北美研发中心和行业解决方案团队的反复修改。当它最终在1998年秋天发布时，详细论证了纯浏览器架构在企业级事务处理、离线操作、大数据量批处理等方面的局限性，并提出了“混合架构”的中间路线——客户端负责复杂交互，浏览器负责轻量级访问。

从技术角度看，这份白皮书是正确的，甚至是前瞻性的。但它在市场上几乎没有激起任何涟漪。

原因很简单：它在回答一个叙事问题，而不是提出一个叙事问题。Oracle的叙事是“互联网是新世界，客户机/服务器是旧世界”，这是一个简单的二元框架，任何人都可以理解，任何人都可以复述，任何人都可以在采购决策中引用。

SAP的回应是“新旧世界之间需要一个过渡期，混合架构是最优解”，这是一个需要技术背景才能理解的复杂论证，它无法在电梯演讲中传达，更无法成为CIO说服董事会改变技术路线的理由。

这种不对称性在Oracle的定价策略中找到了另一个支点。1998年，Oracle推出了“互联网计算许可模式”，这是一个与SAP按用户数计价完全不同的定价体系。Oracle的定价不按并发用户数计算，而是按“企业规模”——根据客户的总营收或员工数量来确定一个固定费用，不限用户数。这个定价策略本身就是一个叙事武器。

它隐含的假设是：在互联网时代，企业应用应该像网站一样，服务于所有人，而不应该按座位收费。当你按用户数收费时，你就是在限制应用的使用范围，就是在维护一种信息等级制度。而Oracle的固定费用模式，则被包装成“民主化计算”——每个员工都可以通过浏览器访问企业系统，无论他们是在办公室、在路上还是在家里。

这个定价策略在财务上是否可持续，当时没有人能给出确定的答案。但它传递了一个清晰的信息：Oracle的商业模式是为互联网时代设计的，而SAP的商业模式是为客户端时代设计的。

这个信息不需要真实，只需要可信。二十世纪九十年代末的许多CIO相信了它，至少相信到愿意用Oracle的定价模式作为与SAP谈判的筹码。

SAP的销售团队在1998年已经开始感受到这种定价叙事的压力。过去，SAP的销售代表进入客户会议室时，讨论的是功能深度、模块覆盖率、行业最佳实践。

但现在，他们发现客户的开场白变成了：“我们正在考虑Oracle的互联网架构，他们的定价模式更灵活，你们的客户机/服务器架构会不会在未来五年内需要大规模升级？”这个问题本身就是一个陷阱，因为它迫使SAP的销售代表进入防御模式，解释为什么客户机/服务器架构仍然有效，而不是攻击Oracle的产品缺陷。SAP的销售培训体系长期以来建立在产品知识的基础上，销售代表需要经过数月的培训才能掌握R/3的模块功能和技术参数。但他们从未接受过如何应对叙事战的训练。

当Oracle的销售代表在客户会议室里用“未来的架构”和“遗留的技术”这样的词汇时，SAP的销售代表只能用“我们正在开发互联网功能”来回应。这种回应等于承认了Oracle设定的框架：互联网是未来的标准，而SAP正在追赶。

换句话说，SAP在没有意识到的情况下，已经接受了Oracle为这场辩论设定的规则。而在这场规则下，SAP从一开始就处于被告的位置，要为一套自己花了二十年时间打磨的架构进行辩护。

但它埋下了一个隐患：当客户发现互联网叙事与产品现实之间的差距时，他们对Oracle的信任会受损。这种信任损失在随后几年中逐渐显现，特别是在那些对功能要求较高的制造业和金融服务业客户中。

SAP在1999年底开始意识到，它必须在叙事能力上做出改变，而不仅仅是产品能力上。普拉特纳在一次内部会议上承认：“我们低估了故事的力量。”这句话代表了一个转折点：SAP开始意识到，在技术转折期，定义未来和构建未来同样重要，甚至更重要。

但意识到问题和解决问题之间，还有一段艰难的路要走。这段路将为SAP在2000年之后的战略调整提供动力，也将揭开Oracle与SAP竞争的新阶段——一个双方都开始用对方的武器作战的阶段。1999年结束时，Oracle的拉里·埃里森可以宣称，他的反击已经成功地将SAP从不可挑战的技术领导者，变成了一个需要为自己的技术路线辩护的守成者。但成功的代价是，Oracle必须兑现它在叙事中承诺的未来。

E-Business Suite的第一个版本离这个未来还有很长的距离，而填补这段距离，需要的不是更多的叙事，而是更多的工程——这正是Oracle最不擅长的领域。SAP在工程上的优势没有消失，它只是暂时被叙事遮蔽了。当客户从被远景打动转向被交付结果检验时，这场竞争的真正胜负才会见分晓。