特斯拉自建ERP的背后

[好文分享：www.ii77.com]

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