亚马逊为什么能够做得越来越大，它成功的关键是什么？很多人会提出各种不同的因素，比如说亚马逊坚持客户优先，亚马逊拥有完善的物流，亚马逊不断地把收入投入到建设等等。但是，一个大家不怎么熟悉，技术性更强的因素是，亚马逊其实是一家重视服务接口标准化的“超级API”公司。Christopher Laing认为，正是2002年贝索斯颁布的那道API指令，奠定了亚马逊成为当今的电子商务巨头的基础。而且，亚马逊的这种做法还是很多公司都可以效仿的，因为这可以扫除组织变革的障碍。

2002 年的时候，亚马逊的杰夫·贝索斯 (Jeff Bezos) 发布了一份备忘录，这份备忘录后来成为了科技行业的教规。这份备忘录叫做“API 指令”（API Mandate），一般被认为是亚马逊对技术方面做出的声明，所以只是受到技术人员的广泛赞赏，但却被高管们完全忽视了。这是很不幸的。因为，可以毫不夸张地说，API指令彻底变革了亚马逊的业务，并为它的成功奠定了基础。而且更好的一点是，跟这家全球性的科技巨头所做的很多事情不同，任何企业几乎都可以复制和使用这个。

在这篇文章当中，我们将讨论这份备忘录，以及它是如何为激进的组织转型建立系统以及激励措施的。

备忘录

据报道（注1），这份备忘录是这样的，从今天起，所有的团队都要以服务接口的方式，提供数据和各种功能。

团队之间必须通过接口来通信。不允许任何其他形式的互操作：不允许直接链接，不允许直接读其他团队的数据，不允许共享内存，不允许任何形式的后门。唯一许可的通信方式，就是通过网络调用服务。

具体的实现技术不做规定，HTTP、Corba、PubSub、自定义协议皆可。所有的服务接口，必须从一开始就以可以公开作为设计导向，没有例外。这就是说，在设计接口的时候，就默认这个接口可以对外部人员开放，没有讨价还价的余地。不遵守上面规定者，一律开除。谢谢；祝你过得愉快！

为了便于理解这意味着什么，我们不妨举个例子。假设亚马逊把你招了进来，要你针对澳大利亚市场销售家居装饰产品。你需要做很多事情才能开始卖，比方说要给数据库设置一些新的产品类别、要到亚马逊的网站上把商品列上架、确定要备货的类型和数量，以及让亚马逊的仓库存放那些产品（注2）。

在亚马逊这里，这些原子功能每一个都是一系列的 API 调用。API，应用程序编程接口（Application Programming Interface），是一种可以让其他的软件跟自己对话并访问自身功能的软件。API 在各种技术当中都随处可见，而这就是贝索斯所谓的“服务接口”。

业务编程接口

实现一项业务成果可能需要数百个这样的原子功能。在大多数的组织当中，大家都是通过跟无数的利益相关者举行多次的会议、进行团队之间的协调、让其他人在自己的日程安排当中优先考虑你的工作，以及靠其他需要大量接触、以人为中心的流程来完成的。任何人在任何规模的组织当中看到过这种情况的都会知道，这可能会导致长达数月或数年的延误——如果说最终能办成的话。

在我们的例子里，API 指令要求负责把商品上架的团队要把自己团队要做的事情作为 API 公开出来，而不是靠人际沟通来解决。你有新的商品要上架？那就调用 API——然后你的商品就可以上架了。没有没完没了的会议、沟通不到位、延误或自己造成的组织混乱（注3）。这些 API 与其说是 API，不如说是 BPI——业务编程接口（Business Programming Interfaces）。

这种差异的重要性怎么强调都不为过。这就是亚马逊之所以能够迅速进入它所关注的任何市场的秘诀。这看起来似乎不太可能，但亚马逊令人难以置信的增长在很大程度上都要归功于 API指令（注4）。套用Benedict Evans的话来说，它已经把亚马逊变成了“制造出更多亚马逊的机器”。

系统蚕食文化

API 指令执行得当的关键机制是它是系统性的，而且跟激励措施保持一致。

组织转型尝试的失败很常见，因为实施转型需要成百上千的人朝着同一个方向去努力，而这往往会跟他们自身的利益背道而驰。这通常会演变成争夺“理智与感情之战”，要么需要一场“文化转变”，但却忽视了那些思想和文化为什么没有能够朝着那个方向发展的原因。

变革要想扎根下来，需要有一套基于机制的系统，用这套系统来激励每一个个体或单位独立地强化这套系统。API 指令的系统性影响我们现在已经看得很清楚了，但系统的效力却要依赖于确保参与的激励机制。

亚马逊的指标体系都是公开可见的，这就会刺激着每一支团队在提供功能的时候，都要尽量让其他团队利用自己功能的能力最大化。从很多方面来说，这模仿了市场本身的功能——要想在竞争激烈的市场当中赚钱，最好的办法是尽可能对你的客户有用。

这套系统，以及相应的激励措施，它们共同创造出一股能够推动组织转型的自然力量。不需要不断地威逼利诱那些顽固分子去参与，相反，这是一个沿着系统创造出来的方向持续演进和改进的过程。文化是结果，而不是原因。

三条经验

乍看之下，API 指令似乎是技术领导而不是 CEO 写出来的。里面没有提到任何跟业务目标、战略、投放范围，甚至产品或客户有关的内容。业务人员关心的一切显然都不存在，但是一旦你理解了这份指令影响时，就会知道这也许是商业史上最重要的一份备忘录。我们从中可以学习到三条经验。

第一条经验是，任何公司只要足够复杂都可以自己去实施 API指令，而且至少可以很好地实现跟亚马逊接近的灵活性和可扩展性。当然，每一家公司是不是都拥有领导技能足够熟练的领导，知道如何去利用这些优势，则是另一回事。

第二条经验是，组织变革是通过系统和激励机制而不是通过文化来实现的。技术是这种变革的主要催化剂，因为技术是结构化的，有序的，本身就适合系统性的应用。

第三条经验是，技术对业务的重要性不仅远超高管们的想象，而且实现技术潜能意味着企业的核心运营会发生根本性的转变，这样才能利用技术的特性。如果商业战略不是由对技术有着深刻理解的人来制定的话，那么几乎可以肯定，这项战略注定会不如预期。

像亚马逊这样的公司都在哪里？

既然API指令这么好，那为什么像亚马逊这样的企业少之又少？其中一个重要的原因也许是，很少有高管了解甚至喜欢技术，从而能够有效地利用技术来获得竞争优势。即便是经验丰富的公司也往往会忽视建构自身业务的激励措施，并无视技术所推动的业务转型的系统方法。好消息是，像亚马逊这样的公司已经为我们其他人点亮了一条前进的道路。在明确了解来 API 指令的真正含义后，任何组织都可以掌握这种真正的变革。你所需要的，只是一份措辞强硬的备忘录而已。