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