國內有位博主摘編了有關企業(yè)應用市場的一個故事。這個故事說到特斯拉在2012年即將推出Model S之際，因為不滿意SAP的ERP產品的靈活性和價格，選擇廢棄SAP，改用低代碼開發(fā)平臺Mendix，用了25個人，四個月時間自建ERP系統(tǒng)。
這個故事的主人公是當時Tesla的CIO，Jay Vijayan。
一家汽車制造企業(yè)的信息系統(tǒng)無疑是非常復雜的。但在當時，SAP的汽車行業(yè)解決方案肯定已經包含了全球汽車制造行業(yè)的最佳實踐，一定能夠幫助Tesla建立起基本的信息架構。一位做出如此決策的CIO想必一定不信任企業(yè)軟件行業(yè)。但實際上，這位印度裔的IT高管本人在傳統(tǒng)企業(yè)軟件行業(yè)就職多年，從VMWare，到Oracle。他對SAP，Oracle這類集成解決方案的企業(yè)應用套件不可謂不熟悉。從2000年開始，他在兩家IT巨頭企業(yè)負責的就是ERP相關的企業(yè)套件開發(fā)。
如果換了另外一家汽車企業(yè)的CIO，會不會做出跟他類似的決策呢？我覺得大概率不會。全球幾乎所有的汽車整車廠商都買得起，也用得起品牌化的商業(yè)套件，有人選擇SAP，有人選擇Oracle。這些品牌套件對于汽車企業(yè)CIO來說，買的就是一個放心。要能夠做出舍棄現成的選擇，自力更生，只有行家里手才會這么做。這就像普通人買固定規(guī)格的品牌電腦，極客會買來配件自己DIY一樣。Vijayan作為ERP產品公司的老兵，選擇不買ERP產品，而是自建，他要在內部說服老大Elon Musk，估計也是靠他的履歷。如果在Vmware和Oracle干了十年以上的人說可以不買，可以自己實現，那還是比較可信的。
如果你聽說一家汽車企業(yè)自己花了很多錢開發(fā)出一套ERP，結果不能解決問題，最終還是乖乖地買了SAP的方案，你可能覺得這樣的故事更可信一些。
問題是，為什么Vijayan的決策能夠成為現實？自建ERP為什么沒有成為特斯拉的夢魘？
1
自建信息系統(tǒng)的抽象要求大幅降低
如果你要開一家飯館，必須要考慮到周邊顧客的不同口味，你可能要準備五十種以上的菜譜，自然也就需要多品種的原料進貨。但是如果要為自己家做一頓晚飯，你只需要買自己愛吃的菜就可以。商品服務和自用服務永遠存在這樣的復雜度對比。
這個例子可能有點過度簡單，軟件產品的復雜歸根到底是因為它的抽象要求。比如你用一個CRM應用，能夠管理自己的客戶訂單，訂單中可以增加產品明細，產品明細可以從產品目錄中選擇，產品目錄包含多層次的結構，購買A產品必須同時配套B產品；如果你要給客戶打折，你既可以選擇百分比折扣，也可以選擇折讓一個絕對值，甚至可以兩個一起干。我們用軟件能夠有這樣的靈活度，是因為軟件廠商根據紛繁復雜的商業(yè)實踐，抽象出了這樣的邏輯和結構，讓它能夠滿足大量客戶的需求。
DIY的系統(tǒng)就扔掉了架構抽象的一部分包袱。雖然依然需要一定程度的抽象，但只要密切地吻合自己的需求就可以，不必考慮其他行業(yè)和其他企業(yè)的差異。
而且，DIY系統(tǒng)可以更大膽地使用直接具體而非抽象的命名。 比如特斯拉必然會涉及到充電站管理，利用商業(yè)套件來管理，一般就需要借用抽象的資產管理模塊，一個充電站，一個充電樁，都必須歸屬抽象的“資產”定義，在資產項目中還必須配置和充電站相關的資產類目。但是，自建系統(tǒng)就可以大大方方地直接叫做“充電站管理”。這既簡化了結構，也讓用戶更容易理解。
換句話說，像SAP這樣的通用管理軟件，并非不能用于特定行業(yè)的具體場景。只是它為了行業(yè)普適的需要，不得不建立更復雜的抽象層次，讓行業(yè)解決方案的設計和實施者能夠通過配置管理實現行業(yè)落地。特斯拉自建ERP的落地則不需要這個過度復雜的抽象過程。
特斯拉甚至能夠根據自己的業(yè)務模式對軟件模塊做出合理的舍棄。比如特斯拉并不存在經銷商系統(tǒng)（Dealer Management System），而經銷商管理是汽車行業(yè)ERP的核心模塊。去掉這一層會讓整個ERP系統(tǒng)簡單很多。當然，特斯拉也有自己獨有的需求，比如車輛軟件的在線升級，軟件包的選擇甚至要和出廠的批次準確關聯。
2
Vijayan掌握了成熟的架構模型
除了能夠在商品級ERP產品基礎上做減法，特斯拉的這位CIO還有支持他決策的法寶，那就是汽車制造業(yè)相關的架構模型知識。這個智慧資產并不是SAP軟件的版權，也不屬于任何其他軟件企業(yè)，它不受任何知識產權法律的保護。
在信息系統(tǒng)架構中，最重要的兩個部分就是數據架構和流程架構，其中尤屬數據架構更為重要，因為它是流程架構的基礎。 這些知識對于成熟ERP產品的開發(fā)和實施者來說是最重要，也是最有用的領域知識。在很多IT咨詢項目中，咨詢公司給出的實施方案中最有價值的也是這些部分。我知道一位英國的退休IT專家，就在自己的個人網站上賣幾千份各種各樣商業(yè)數據庫的ER圖（實體關系圖）。你付他幾千英鎊，他把整個庫都刻盤給你。Vijayan的經驗肯定足以覆蓋這些部分。
當然大家也不要低估了這些模型的規(guī)模和實現的難度。對于汽車制造業(yè)這樣的復雜協(xié)作體來說，ERP軟件所涉及的數據對象至少有幾百個，還有彼此之間錯綜復雜的關聯關系。圍繞不同業(yè)務環(huán)節(jié)的流程至少有數千個之多。所有這些架構知識都最終要轉換成命名準確、結構清晰和邏輯完善的軟件開發(fā)需求。
很多復雜的事情會讓普通人望而生畏，但是行家里手就是不一樣，他對復雜事物的內部結構了然于胸，自然能就地取材，巧手成器。我們聽到過退休工程師自己造飛機的故事覺得很離奇，但對于飛機工程師來說，他的確認為天下不只只有買飛機一個選擇，也可以自己造飛機。
3）低代碼開發(fā)工具的助力
即便是行家里手，他要在短時間內開發(fā)出替代SAP商業(yè)產品的軟件必然也需要工具。在Vijayan的采訪文章中，他曾經提到在2012年Model S發(fā)布之前，特斯拉只有非常有限的時間來完成自建ERP系統(tǒng)的開發(fā)，所以他選擇了一個在制造業(yè)有一些名氣的Mendix低代碼開發(fā)平臺（后來被西門子收購）。低代碼開發(fā)平臺對企業(yè)關系數據應用的實現做了很多預先的封裝工作。創(chuàng)建一個數據表，再建立錄入和查詢用的表單，配套數據增刪查改相關的工作流，這些過程幾乎都不用重復寫代碼。這就是為什么Vijayan能夠用四個月來實現。這個速度并不讓我驚訝。今天的低代碼/零代碼工具在四個月的尺度下的確可以完成非常復雜和大型的應用了。況且，據他自己說，還用了25個人。這25個人無疑是為了按業(yè)務環(huán)節(jié)分工，來同步創(chuàng)建大量的數據表和流程，從而縮短整體項目周期。
低代碼開發(fā)工具能夠實現的企業(yè)應用的確非常范式化，但是，絕大多數的企業(yè)應用本身就是范式化的。尤其像ERP這樣的中后臺應用，它就是由數據架構、視圖權限、統(tǒng)計分析和工作流等組件來組成的，99%的用戶操作都可以抽象為數據的增刪查改操作。這就是為什么企業(yè)應用開發(fā)必然走向這個模式化搭建的方向，而不必完全依賴原生技術棧。
實際上，即使是SAP，Oracle和微軟的企業(yè)應用產品，它們也都支持低代碼的應用自定義。Salesforce的Lightning，微軟的Dynamics, Oracle的APEX都是類似的工具。SAP可能是在這個策略下最晚行動的巨頭，它也在本月發(fā)布了RUUM的公測版本。雖然它定位是滿足SAP客戶長尾的個性化需求，但實際上用來解決骨干場景是一樣的邏輯。
特斯拉在2014年以后還是回到了原生開發(fā)的策略上，換成微軟的技術棧，用.Net開發(fā)出了最終版本的內部ERP系統(tǒng)，被成為WARP。但我相信，特斯拉內部肯定依然在用低代碼產品來解決很多問題，不可能所有的需求都跑去軟件研發(fā)團隊那里去排隊。傳統(tǒng)的DevOps過程注定是昂貴的。國內的蔚來汽車技術團隊甚至自己開發(fā)了一款叫“赤兔”的低代碼平臺，用來更快響應內部的IT需求。
同樣，我也相信特斯拉絕對不會傻到完全不用商業(yè)軟件產品。ERP能夠自建，不代表所有的應用都能夠或者需要自建。比如特斯拉絕對不可能自己開發(fā)工業(yè)設計軟件，也不需要開發(fā)自己的辦公Office應用，這些專有產品就是應該買來開箱即用。靈活的選擇，永遠都是最理智的選擇。
Vijayan 2016年就離開了特斯拉，據說他一直在籌備一家新的初創(chuàng)企業(yè)，但始終對外保密。我大膽地猜測，他在開發(fā)一款面向大型企業(yè)的零代碼應用開發(fā)產品，也許他對當年的Mendix也有很多不滿。
作者是明道云創(chuàng)始人任向暉，明道云是一款零代碼/低代碼企業(yè)應用平臺。文中沒有提到明道云，并不代表作者不想推廣明道云給大家嘗試。相反，我覺得明道云是一款比Mendix更加易用，符合中國用戶需要的應用平臺產品。
明道云團隊近期出版了書籍《零代碼企業(yè)應用搭建指南》 ，向我們公眾號的讀者開放50個免費領書名額。如果您對零代碼/低代碼感興趣，可以掃描下方海報的二維碼填寫信息。若領取成功，則會有短信通知你。機會有限，抓緊時間領取吧！
申請創(chuàng)業(yè)報道，分享創(chuàng)業(yè)好點子。點擊此處，共同探討創(chuàng)業(yè)新機遇！
