特斯拉自建ERP的背後

國內有位博主摘編了有關企業應用市場的一個故事。這個故事說到特斯拉在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也有很多不滿。

作者是明道雲創始人任向暉，明道雲是一款零程式碼/低程式碼企業應用平臺。文中沒有提到明道雲，並不代表作者不想推廣明道雲給大家嘗試。相反，我覺得明道雲是一款比Mendix更加易用，符合中國使用者需要的應用平臺產品。

明道雲團隊近期出版了

書籍《零程式碼企業應用搭建指南》

，向我們公眾號的讀者開放50個免費領書名額。如果您對零程式碼/低程式碼感興趣，可以掃描下方海報的二維碼填寫資訊。若領取成功，則會有簡訊通知你。機會有限，抓緊時間領取吧！