特斯拉自建 ERP 的背后

国内有位博主摘编了有关企业应用市场的一个故事。这个故事说到特斯拉在 2012 年即将推出 Model S 之际，因为不满意 SAP 的 ERP 产品的灵活性和价格，选择废弃 SAP，改用低代码开发平台 Mendix，用了 25 个人，四个月时间自建 ERP 系统。

这个故事的主人公是当时 Tesla 的 CIO，Jay Vijayan。

一家汽车制造企业的信息系统无疑是非常复杂的。但在当时，SAP 的汽车行业解决方案肯定已经包含了全球汽车制造行业的最佳实践，一定能够帮助 Tesla 建立起基本的信息架构。一位做出如此决策的 CIO 想必一定不信任企业软件行业。但实际上，这位印度裔的 IT 高管本人在传统企业软件行业就职多年，从 VMWare，到 Oracle。他对 SAP，Oracle 这类集成解决方案的企业应用套件不可谓不熟悉。从 2000 年开始，他在两家 IT 巨头企业负责的就是 ERP 相关的企业套件开发。

如果换了另外一家汽车企业的 CIO，会不会做出跟他类似的决策呢？我觉得大概率不会。全球几乎所有的汽车整车厂商都买得起，也用得起品牌化的商业套件，有人选择 SAP，有人选择 Oracle。这些品牌套件对于汽车企业 CIO 来说，买的就是一个放心。要能够做出舍弃现成的选择，自力更生，只有行家里手才会这么做。这就像普通人买固定规格的品牌电脑，极客会买来配件自己 DIY 一样。Vijayan 作为 ERP 产品公司的老兵，选择不买 ERP 产品，而是自建，他要在内部说服老大 Elon Musk，估计也是靠他的履历。如果在 Vmware 和 Oracle 干了十年以上的人说可以不买，可以自己实现，那还是比较可信的。

如果你听说一家汽车企业自己花了很多钱开发出一套 ERP，结果不能解决问题，最终还是乖乖地买了 SAP 的方案，你可能觉得这样的故事更可信一些。

问题是，为什么 Vijayan 的决策能够成为现实？自建 ERP 为什么没有成为特斯拉的梦魇？

1）自建信息系统的抽象要求大幅降低

如果你要开一家饭馆，必须要考虑到周边顾客的不同口味，你可能要准备五十种以上的菜谱，自然也就需要多品种的原料进货。但是如果要为自己家做一顿晚饭，你只需要买自己爱吃的菜就可以。商品服务和自用服务永远存在这样的复杂度对比。

这个例子可能有点过度简单，软件产品的复杂归根到底是因为它的抽象要求。比如你用一个 CRM 应用，能够管理自己的客户订单，订单中可以增加产品明细，产品明细可以从产品目录中选择，产品目录包含多层次的结构，购买 A 产品必须同时配套 B 产品；如果你要给客户打折，你既可以选择百分比折扣，也可以选择折让一个绝对值，甚至可以两个一起干。我们用软件能够有这样的灵活度，是因为软件厂商根据纷繁复杂的商业实践，抽象出了这样的逻辑和结构，让它能够满足大量客户的需求。

DIY 的系统就扔掉了架构抽象的一部分包袱。虽然依然需要一定程度的抽象，但只要密切地吻合自己的需求就可以，不必考虑其他行业和其他企业的差异。

而且，DIY 系统可以更大胆地使用直接具体而非抽象的命名。比如特斯拉必然会涉及到充电站管理，利用商业套件来管理，一般就需要借用抽象的资产管理模块，一个充电站，一个充电桩，都必须归属抽象的“资产”定义，在资产项目中还必须配置和充电站相关的资产类目。但是，自建系统就可以大大方方地直接叫做“充电站管理”。这既简化了结构，也让用户更容易理解。

换句话说，像 SAP 这样的通用管理软件，并非不能用于特定行业的具体场景。只是它为了行业普适的需要，不得不建立更复杂的抽象层次，让行业解决方案的设计和实施者能够通过配置管理实现行业落地。特斯拉自建 ERP 的落地则不需要这个过度复杂的抽象过程。

特斯拉甚至能够根据自己的业务模式对软件模块做出合理的舍弃。比如特斯拉并不存在经销商系统（Dealer Management System），而经销商管理是汽车行业 ERP 的核心模块。去掉这一层会让整个 ERP 系统简单很多。当然，特斯拉也有自己独有的需求，比如车辆软件的在线升级，软件包的选择甚至要和出厂的批次准确关联。

2）Vijayan 掌握了成熟的架构模型

除了能够在商品级 ERP 产品基础上做减法，特斯拉的这位 CIO 还有支持他决策的法宝，那就是汽车制造业相关的架构模型知识。这个智慧资产并不是 SAP 软件的版权，也不属于任何其他软件企业，它不受任何知识产权法律的保护。

在信息系统架构中，最重要的两个部分就是数据架构和流程架构，其中尤属数据架构更为重要，因为它是流程架构的基础。这些知识对于成熟 ERP 产品的开发和实施者来说是最重要，也是最有用的领域知识。在很多 IT 咨询项目中，咨询公司给出的实施方案中最有价值的也是这些部分。我知道一位英国的退休 IT 专家，就在自己的个人网站上卖几千份各种各样商业数据库的 ER 图（实体关系图）。你付他几千英镑，他把整个库都刻盘给你。Vijayan 的经验肯定足以覆盖这些部分。

当然大家也不要低估了这些模型的规模和实现的难度。对于汽车制造业这样的复杂协作体来说，ERP 软件所涉及的数据对象至少有几百个，还有彼此之间错综复杂的关联关系。围绕不同业务环节的流程至少有数千个之多。所有这些架构知识都最终要转换成命名准确、结构清晰和逻辑完善的软件开发需求。

很多复杂的事情会让普通人望而生畏，但是行家里手就是不一样，他对复杂事物的内部结构了然于胸，自然能就地取材，巧手成器。我们听到过退休工程师自己造飞机的故事觉得很离奇，但对于飞机工程师来说，他的确认为天下不只只有买飞机一个选择，也可以自己造飞机。

3）低代码开发工具的助力

即便是行家里手，他要在短时间内开发出替代 SAP 商业产品的软件必然也需要工具。在 Vijayan 的采访文章中，他曾经提到在 2012 年 Model S 发布之前，特斯拉只有非常有限的时间来完成自建 ERP 系统的开发，所以他选择了一个在制造业有一些名气的 Mendix 低代码开发平台（后来被西门子收购）。低代码开发平台对企业关系数据应用的实现做了很多预先的封装工作。创建一个数据表，再建立录入和查询用的表单，配套数据增删查改相关的工作流，这些过程几乎都不用重复写代码。这就是为什么 Vijayan 能够用四个月来实现。这个速度并不让我惊讶。今天的低代码/零代码工具在四个月的尺度下的确可以完成非常复杂和大型的应用了。况且，据他自己说，还用了 25 个人。这 25 个人无疑是为了按业务环节分工，来同步创建大量的数据表和流程，从而缩短整体项目周期。

低代码开发工具能够实现的企业应用的确非常范式化，但是，绝大多数的企业应用本身就是范式化的。尤其像 ERP 这样的中后台应用，它就是由数据架构、视图权限、统计分析和工作流等组件来组成的，99%的用户操作都可以抽象为数据的增删查改操作。这就是为什么企业应用开发必然走向这个模式化搭建的方向，而不必完全依赖原生技术栈。

实际上，即使是 SAP，Oracle 和微软的企业应用产品，它们也都支持低代码的应用自定义。Salesforce 的 Lightning，微软的 Dynamics, Oracle 的 APEX 都是类似的工具。SAP 可能是在这个策略下最晚行动的巨头，它也在本月发布了 RUUM 的公测版本。虽然它定位是满足 SAP 客户长尾的个性化需求，但实际上用来解决骨干场景是一样的逻辑。

特斯拉在 2014 年以后还是回到了原生开发的策略上，换成微软的技术栈，用.Net 开发出了最终版本的内部 ERP 系统，被成为 WARP。但我相信，特斯拉内部肯定依然在用低代码产品来解决很多问题，不可能所有的需求都跑去软件研发团队那里去排队。传统的 DevOps 过程注定是昂贵的。国内的蔚来汽车技术团队甚至自己开发了一款叫“赤兔”的低代码平台，用来更快响应内部的 IT 需求。

同样，我也相信特斯拉绝对不会傻到完全不用商业软件产品。ERP 能够自建，不代表所有的应用都能够或者需要自建。比如特斯拉绝对不可能自己开发工业设计软件，也不需要开发自己的办公 Office 应用，这些专有产品就是应该买来开箱即用。灵活的选择，永远都是最理智的选择。

Vijayan 2016 年就离开了特斯拉，据说他一直在筹备一家新的初创企业，但始终对外保密。我大胆地猜测，他在开发一款面向大型企业的零代码应用开发产品，也许他对当年的 Mendix 也有很多不满。

作者为明道云创始人，明道云即是一款零代码/低代码企业应用平台，文中没有提到明道云，并不代表我不想推广明道云给大家尝试。相反，我觉得明道云是一款比 Mendix 更加易用，符合中国用户需要的应用平台产品。点击阅读原文访问明道云。