特斯拉自研ERP,为企业信息化带来哪些启示?
6140
2021-01-15 17:02    文章来源:企业数字化咨询
文章摘要:特斯拉自行开发ERP取代SAP系统的事情,引起了一大波吃瓜群众围观吃瓜

 特斯拉自行开发ERP取代SAP系统的事情,引起了一大波吃瓜群众围观吃瓜。为什么会引起如此反响,个人猜测大部分原因在于人们已经习惯了SAP、金蝶、用友等供应商拿着PPT侃侃而谈“上ERP是找死、不上ERP是等死”,然后都花钱购买服务上软件,可是特斯拉这次竟然冒天下之大不韪动SAP、oracle的奶酪,着实令人震惊。但是这次特斯拉特立独行的打破了世俗的眼光,抛弃了已有数不胜数的成功经验,悬梁刺股、凿壁偷光的自己研发ERP,竟然还成功了,的确让人汗颜,众所周知在制造业的数字化领域,汽车行业一直是最先进的排头兵,SAP更是在这个领域绝对的王者,Tesla以外的汽车企业Top10中,有9家使用的都是SAP。

俗话说兵熊熊一个,将熊熊一窝,特斯拉的钢铁侠马斯克频频出境已经让人们领略过其风采,但这次主持研发特斯拉ERP的这位狠人却并未太多人所熟悉。

Jay Vijayan,印度裔人士,出生于印度第四大城市金奈(泰米尔语:''Chennai'')。在加盟特斯拉前曾经在Oracle、Vmware等公司任职,在加盟特斯拉前曾经担任VMware的技术高级总监。履历非常光鲜,在企业数字化领域头部公司均有所历练。但是纵然拥有这样的履历,当初提自建ERP时该团队只有25个工程师,要是一般的CIO以这样的团队老板还让自建系统,即使不吓尿,也得转头回位置上开始写辞职报告。

被逼上梁山

而提出自建ERP的想法也并不是空穴来风、意兴阑珊,而是特斯拉“IT现在有太多系统了,我希望IT只要一套系统就够了!这个系统不仅能够实现企业内部的运营管理,也能够连接外部的客户,甚至可以远程连接到正在马路上行驶的特斯拉电动车”。除了企业内部的需求导向,另外的原因也在于外部供应商已经不满足他们的需求,也就是说即使交给SAP完成该信息化建设,也是需要在其现有功能之上开发一部分的,原因主要在于:

1) 敏捷性:作为电动车的新兴势力,必须以极快的速度和敏捷的速度来推动汽车行业的根本变革,也就是说这个系统需要满足极大柔性,需要随时迎接变化;

2) 传统系统已经固化:目前诸如SAP、用友ERP等系统由于是面向某个行业的可配置的解决方案集合,所有的系统都不是为某一个公司,而本身的系统平台也不可能仅仅为某一个行业定做。从本质上讲,这些信息化系统已经非常臃肿,因为他是将所有企业共性需求抽取而形成的综合解决方案,凡是能够满足的企业多,则必定会面临灵活度差的缺点。

3) 无缝系统整合:特斯拉的本身的愿景是建立一个垂直整合的组织,在这个组织中,信息在各个部门之间无缝地流动。为了实现这一愿景,特斯拉必须有一个简单而集中的业务系统软件,它可以连接所有部门,并实现跨部门的信息无缝流动。在市场上找不到一个能满足这种需求的IT系统。也就是说即使他们购买SAP软件也只是应用其中一部分,比如码的理念、配置驱动的研发、供应链、仓储管理、全生命周期的预测算法、工程变更的自动化应用、JIT、ANDON、动态成本控制等等。但如果要打造。 

综合来讲鉴于特斯拉内部希望做到汽车行业引领者,而外部并不具备满足其所有需求的信息化系统,所以自研ERP听起来豪言壮语,可是细细想来也是充满了无奈,有些被逼上梁山的味道。

自研ERP之路

1、特斯拉早期直接使用了当时最好的低代码开发平台Mendix(西门子花了8亿美金收购了Mendix);,系统于2012年7月上线;

2、经过8年的迭代,Tesla核心的数字化系统,已经完全由自主开发,并且全公司遵循统一的软件开发管理准则;

3、这套系统的内部名称叫Warp Drive(“Warp”),包括了所需要使用的供应链、产品规划、库存、销售订单管理、资产、财务、潜在客户管理等绝大部分业务流程;

4、维护这套系统现在需要超过250个工程师;

通过网上如上描述可获知:特斯拉一开始并不是冲着ERP去的,而是因为SAP的行业解决方案已经不满足其需求,而是利用SAP的企业资源管理功能作为托底,然后利用低代码开发平台mendix进行开发,也就是说最初的定位其实是SAP覆盖不到的功能进行开发,整体完善的功能搭建完成之后然后再反噬SAP的功能空间,最终形成了包含特斯拉企业内外部业务的信息化系统。

而且,最重要的是即使上线之后仍然用友250名运维团队(这个数字有毒),这也给国内部分企业希望走信息化系统自研之路的企业泼了一盆凉水,就撇开马斯克义无反顾式的自研决定,还是Jay Vijayan辉煌的企业数字化服务履历,就是250+的运维团队又有多少企业可以提供。并且特斯拉也并不是在一无所有的情况下进行一场冒险之旅,因为开始阶段SAP是起到内部管理托底的作用,才会允许他进行一场说走就走的自研旅行。

自研ERP的成功之钥

Ø  企业数字化服务能力

从事企业信息化的人员基本上都认可一个内容:真正困扰企业信息化发展的并不是IT技术,而是TOGAF经常提到的业务架构、功能架构与数据架构,而在Oracle、Vmware等企业数字化服务商从业的Jay Vijayan对于这些企业模型自然并不陌生,而且加上汽车制造业相关的架构模型知识已经趋于成熟,甚至现招一位汽车信息化的行业专家也并不是不可以。

Ø  低代码开发架构

低代码开发平台对企业关系数据应用的实现做了很多预先的封装工作。创建一个数据表,再建立录入和查询用的表单,配套数据增删查改相关的工作流,这些过程几乎都不用重复写代码。这就是为什么Vijayan能够用四个月来实现。这个速度并不让我惊讶。今天的低代码/零代码工具在四个月的尺度下的确可以完成非常复杂和大型的应用了,而且他也是站在已有SAP系统功能的情况下开发,然后反过来再逐步替代,也就是说他是站在巨人肩膀上的牛顿。

Ø  前车之鉴

自研ERP其实更多的是噱头,听起来唬人,但是真实的情况是前期在SAP满足不了的功能之外利用低代码平台进行开发,然后反过来替代了一部分SAP的功能,前后顺序一旦颠倒造成的影响可想而知,如果给一张白纸的企业,交给Vijayan自研ERP的任务,估计他的遗言会变成“自研ERP成功日,家祭无忘告乃翁”。

企业信息化的未来发展

目前已经进入了软件定义世界的范畴,大到企业管理,小到举办企业年会投影用的留言小程序,软件在其中都扮演不可替代的作用。这样局面造成了软件开发人员需求量剧增,程序员的梗也是在这种情况下盛传。

而诸如小程序、公众号的二次开发更多是站在腾讯已经搭建好的大的平台之上,利用一些已经封装完成的模块来进行修改,这样才让小程序迭代看起来如此频繁,如果同样的迭代放在企业端,信息部或者CIO早已经换了几茬了,原因在于企业的信息化建设更多是牵一发而动全身,比如一个百十人的制造型企业竟然会有大小十几个总监,所谓麻雀虽小五脏俱全,引用周星驰《喜剧之王》当中的名言没有小角色只有小演员。只有规模小的企业但是业务系统一定是包罗万象的,所以企业信息化系统的变更频次是相对可控的。

但是鉴于如今市场对于企业响应速度要求越来越高,造成企业内部组织架构频繁变更,业务流程实时更新,进而造成企业管理系统也需要频繁翻新,所以企业信息化系统之前那种建设一个系统为子孙后代服务的思想已经严重落伍。目前越来越多的企业已经有了购买二次开发平台的需求,按道理给企业交付的应该是直接面向业务团队的SAAS服务才行,这也明显能够感觉到企业已经逐渐认识到在业务频繁变更的表象之下应该有一个统一平台,所以我们可以断言未来企业仍然脱离不了ERP、MES与PDM三驾马车,但是与该业务类似的诸如售后服务、客户管理等额外的拓展功能会在统一的开发平台之上做开发,以ERP、MES与PDM的功能作为托底然后对企业业务的单点需求进行优化与补充。

工业互联网平台会催生更多“自研ERP”的故事

当企业信息化变更的频次会越来越多,这就造成对于能够满足工业级或者产业级的平台的需求越来越迫切,在这个阶段我国适时提出了工业互联网:工业互联网的本质是通过开放的、全球化的工业级网络平台把设备、生产线、工厂、供应商、产品和客户紧密地连接和融合起来,高效共享工业经济中的各种要素资源,从而通过自动化、智能化的生产方式降低成本、增加效率,帮助制造业延长产业链,推动制造业转型发展。

通过概念我们也可以用初中肄业的语文水平来进行解读一下:打造开发的、全球化的工业级平台。所以当我们在为特斯拉自研ERP或震惊、或欢呼时,我国其实已经仿佛开了游戏的上帝视角一般进行工业互联网押注。

特斯拉自研ERP之路与工业互联网进行一一对比的话,特斯拉利用的低代码平台其实就是工业PAAS,用于抽象整个企业对于信息化的共性功能,但是这部分功能基本已经下沉到流程、用户与数据管理层级,因为面向用户的服务功能每个企业都是千差万别的。而特斯拉第一步以SAP功能为托底进行研发的功能其实就是新型的工业APP范畴,代表着敏捷、自由定制、更贴合用户习惯等性质。

也就是说工业互联网PAAS平台越成熟,中国企业则会出现更多诸如“自研XX系统”的故事,因为有ERP、MES与PDM大系统托底,由于高度可配置开发的平台作为依托,数以万计的工业APP将会面世,会出现更多中国版的自研故事。

640.png

企业信息化从业者的未来之路

企业信息化从业者目前大致分为两类:业务顾问与开发顾问,SAP的顾问是按照模块、业务/开发进行严格划分的,但是随着工业互联网PAAS平台会逐步成熟,二次开发平台的开发门槛会越来越低,企业所需的功能大部分只需要实施配置即可,并不需要太多比较深入的开发,比如电脑刚开始发明的时候开启系统是需要专门人士写程序,但是现在基本已经实现了傻瓜式应用。同样的道理目前华为推出面向DevCloud_DevOps开发平台也封装了一些面向开发人员的工具,提升效率的同时降低了开发准入度,也就是说开发会越来越趋于简单,其发展轨迹可参考手动挡—自动挡—自动驾驶。

也就是说开发顾问会逐渐向业务咨询方向发展,帮助客户梳理流程、然后重塑流程,因为企业流程重塑的发起者往往需要以第三者的姿态去梳理。

而随着软件作用的不断提升,企业对于单点性质的系统应用软件需求会逐步提升,所以规模性企业并不排除会增加信息部人数的可能,进而在企业已有的功能之上完成单点功能的优化补充,提升客户、供应商或者内部业务人员的用户体验,所以对于向削尖脑袋往甲方去的同学是一个利好消息。


版权声明:

凡本网内容请注明来源:T媒体(http://www.cniteyes.com)”的所有原创作品,版权均属于易信视界(北京)信息科技有限公司所有,未经本网书面授权,不得转载、摘编或以其它方式使用上述作品。

本网书面授权使用作品的,应在授权范围内使用,并按双方协议注明作品来源。违反上述声明者,易信视界(北京)信息科技有限公司将追究其相关法律责任。

评论