国内一位博主摘录了一个关于企业应用市场的故事。这个故事告诉我们，当特斯拉即将在2012年推出ModelS时，因为对SAp ERp产品的灵活性和价格不满意，它选择放弃SAp，转而使用低代码开发平台Mendix。用了25个人在4个月的时间建立了自己的ERp系统。

这个故事的主人公是当时特斯拉的CIO JayVijayan。

汽车制造企业的信息系统无疑是非常复杂的。然而，在当时，SAp的汽车行业解决方案肯定包含了全球汽车制造业的最佳实践，这肯定会帮助特斯拉建立一个基本的信息架构。做出这种决定的首席信息官一定不信任企业软件行业。但事实上，这位印度-born的信息技术主管已经在传统的企业软件行业工作了多年，从VMWare到甲骨文。他不熟悉SAp和甲骨文等集成解决方案的企业应用套件。自2000年以来，他一直在两家IT巨头负责ERp相关的企业套件开发。

如果换了另一家汽车公司的CIO，他会做出类似的决定吗？我认为这是不可能的。世界上几乎所有的汽车制造商都买得起，他们也买得起品牌商务套房。有人选择SAp，有人选择甲骨文。对于汽车企业的首席信息官来说，这些品牌套件是一种安心。为了能够放弃现成的选择，自力更生，只有专家才会这样做。就像普通人买的是固定规格的品牌电脑，极客买的是DIY的配件。Vijayan作为ERp产品公司的元老，选择不买ERp产品，而是自己打造。他必须在内部说服老板ElonMusk，这估计取决于他的简历。如果在Vmware和甲骨文工作了十几年的人说自己可以做，而不是买，那还是可信的。

如果你听说一家汽车公司花了很多钱开发了一个ERp，但解决不了问题，最后还是乖乖地买了SAp解决方案，你可能会觉得这个故事更可信。

问题是，为什么维贾扬的决定变成了现实？为什么自建ERp没有成为特斯拉的噩梦？

一个

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

如果你想开一家餐馆，你必须考虑你周围顾客的不同口味。你可能要准备50多个食谱，这自然需要多种原料。但是如果你想为家人做饭，你只需要买你喜欢的食物。商品服务和自用服务之间总是有这样的复杂性对比。

这个例子可能有点简单。归根结底，软件产品的复杂性是由于它的抽象需求。例如，如果您使用一个客户关系管理应用程序，您可以管理自己的客户订单。订单中可以添加产品详细信息。产品详情可从中产品目录中选择产品目录包含多级结构。购买A类产品必须附有B类产品；如果你想给顾客打折，你可以选择百分比折扣或绝对折扣，甚至两者兼而有之。我们可以如此灵活地使用软件，是因为软件制造商根据复杂的业务实践抽象出这样的逻辑和结构，从而可以满足大量客户的需求。

DIY系统抛弃了架构抽象的部分负担。虽然还需要一定程度的抽象，但只需要与自己的需求紧密匹配，不需要考虑其他行业和其他企业的差异。

而且，DIY系统可以更大胆地使用直接具体的命名，而不是抽象的命名。比如特斯拉必然涉及到充电站的管理，一般要借用一个抽象的资产管理模块，一个充电站，一个充电桩，都必须属于“资产”的抽象定义。在资产项目中，还必须配置与充电站相关的中，资产类别。但是，自建系统可以直接称为“充电站管理”。这简化了结构，使用户更容易理解。

换句话说，像SAp这样的通用管理软件并非不能用于特定行业的特定场景。但对于行业的通用需求，则必须建立更复杂的抽象层次，让行业解决方案的设计者和实现者通过配置管理实现行业落地。自建ERp在特斯拉落地不需要这个过于复杂的抽象过程。

特斯拉甚至可以根据自己的商业模式合理放弃软件模块。例如，特斯拉，没有经销商管理系统，经销商管理是汽车行业ERp的核心模块。去掉这一层将使整个ERp系统变得简单得多。当然，特斯拉也有自己独特的要求，比如车辆软件的在线升级，软件包的选择甚至应该与工厂批次准确相关。

2

Vijayan已经掌握了成熟的架构模型

特斯拉的CIO除了能够在商品级ERp产品的基础上做减法之外，还有一个支持他决策的法宝，那就是与汽车制造相关的架构模型知识。该知识资产不是SAp软件的版权，也不属于任何其他软件企业，不受任何知识产权法的保护。

在中的信息系统架构中，最重要的两个部分是数据架构和流程架构，而中尤为重要，因为它是流程架构的基础。对于成熟的ERp产品的开发人员和实施人员来说，这些知识是最重要和最有用的领域知识。在中，的许多信息技术咨询项目中，这些是中咨询公司给出的实施计划中最有价值的部分。我认识一位英国的退休信息技术专家，他在个人网站上出售数千张各种商业数据库的ER图(实体关系图)。你付给他几千英镑，他给你整个库都刻盘维贾扬的经历一定足以涵盖这些部分。

当然，我们不应该低估这些模式的规模和难度。对于像汽车制造业这样复杂的协作，ERp软件涉及的数据对象至少有上百个，它们之间存在着复杂的关系。至少有成千上万个流程围绕着不同的业务环节。所有这些架构知识最终都会转化为命名准确、结构清晰、逻辑完善的软件开发需求。

很多复杂的事情会让普通人望而生畏，但专家不一样。他对复杂事物的内部结构了如指掌，自然能就地取材，成为能工巧匠。我们听过退休工程师自己造飞机的故事，但就飞机工程师而言，他确实认为世界上只有一个选择，他们也可以自己造飞机。

3)低代码开发工具的帮助

即使是专家，如果他想开发软件，在短时间内取代SAp商业产品，也需要工具。在Vijayan在中，的采访文章中，他曾经提到，在2012年ModelS发布之前，特斯拉完成自建ERp系统开发的时间非常有限，所以他选择了一个Mendix低代码开发平台(后来被西门子)这个在制造业很有名的平台。低代码开发平台为企业关系数据应用的实现做了大量的预封装工作。创建数据表，然后创建表单进行录入和查询，支持数据增加、删除、查询和修改的工作流程。这些过程几乎不需要反复编写代码。这就是为什么Vijayan可以在四个月内实现。这个速度并不令我惊讶。今天的低代码/零代码工具真的可以在四个月内完成非常复杂和大规模的应用程序。此外，根据他自己的说法，使用了25个人。这25个人无疑是在努力根据业务环节同步创建大量的数据表和流程，从而缩短整个项目周期。

可以通过低代码开发工具实现的企业应用程序确实非常面向范例，但是大多数企业应用程序本身都是面向范例的。尤其是像ERp这样的中后台应用，由数据架构、视图权限、统计分析和工作流组成，99%的用户操作可以抽象为数据的添加、删除、查询和修改操作。这就是为什么企业应用程序开发必然会朝着这个模型构建方向发展，而不是完全依赖原生技术栈。

事实上，即使是SAp、甲骨文和微软的企业应用程序都支持低代码应用程序定制。Salesforce的Lightning、微软动力、甲骨文的ApEX都是类似的工具。SAp可能是最后一个根据这一战略采取行动的巨头，它也在本月发布了RUUM的测试版。虽然定位于满足长尾SAp客户的个性化需求，但实际上解决骨干场景也是同样的逻辑。

2014年后，特斯拉回归原生发展战略，在微软，改为技术栈，用开发内部ERp系统的最终版本。Net，它被称为WARp。但是我相信在特斯拉，低代码产品仍然被用来解决很多问题，不可能所有的需求都去软件R&D团队排队。传统的DevOps过程必然是昂贵的。蔚来的国内汽车技术团队甚至开发了一个名为“赤兔”的低代码平台，以更快地响应内部it需求。

同样，我也相信特斯拉永远不会蠢到根本不使用商业软件产品。ERp可以自建，这并不意味着所有的应用都可以或需要自建。例如，特斯拉绝对不可能开发自己的工业设计软件和自己的办公应用程序。这些专利产品应该买现成的。灵活选择永远是最理性的选择。

Vijayan2016于2016年离开特斯拉。据说他一直在为一家新的初创公司做准备，但总是保守秘密。我大胆猜测他是在为大企业开发零代码应用开发产品，可能他对Mendix有很多不满。

作者是明道云， 任向晖，创始人，明道云是零代码/低代码企业应用平台。仅仅因为文没有提到，并不意味着作者不想向大家宣传。相反，我认为明道云是一个比Mendix更容易使用的应用平台产品，满足了中用户的需求

明道云团队最近出版了《零代码企业应用搭建指南》这本书，在微信官方账号上为我们的读者开放了50个免费接书的地方。如果你对零码/低码感兴趣，可以扫描下面海报的二维码填写信息。如果你成功收到，你会收到短信通知。机会有限，赶快去争取吧！

« 苹果公司在大中华区实现两位数的增长，销售额增长87% | 蝉妈妈数据解读：洪兴牛的直播浏览量突破1亿次 地震强度是民族品牌增长的关键动力 »