**国内有位博主摘编了有关企业应用市场的一个故事。这个故事说到特斯拉在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也有很多不满。**