以下是現場速記。
上海愛湃斯科技（ClickPaaS）CEO 胡柏
胡柏：各位領導、各位朋友，感謝大家今天下午的時間。低代碼、無代碼可能是過去一兩年發展非常快，概念被大家所知。實際我們在15年回國做這件事情的時候，整個賽道都是很冷的，無論是產業界還是資本界，對到底什么是模型化驅動，什么是低代碼，其實了解并不多。
我在下面聽，前面一位尚老師在講在雙碳領域，怎么去構建他們的信息系統?原來我在甲骨文，甲骨文當年有一個非常大的收購行為，收購了cibel，它被甲骨文并購之后，他就從甲骨文離職了，他做了一家共叫C3，做十年前美國的雙碳、碳積分、碳交易的系統。他為什么轉做碳交易?因為他沒有固定化的場景，因為他整個業務形態一直在變化，所以他需要一個敏捷的平臺，需要去連接各種各樣的OT設備，甚至往后走要連接到人工智能，所以C3這家公司的名字最開始叫C3，后來叫C3.iot變化了C3.AI。
我講一下整個美國市場對低代碼、無代碼看法的變化。我原來在美國甲骨文做研發，我15年當時我們有一個契機覺得應該要回來創業，把我們在甲骨文做的東西拿回來再做一遍，所以我們名字叫Cleak+PaaS。我們回來時跟美國專家談過，大家對這件事情看法有各種各樣的爭議。
第一個爭議覺得這件事情很難做出來，甲骨文花很大代價構建底層再投向市場，到底中國公司能不能做出來?這個是疑問。
第二個會不會被并購。
很有意思的是今年過年時，我在跟這幫原來美國同事聊的時候，大家看法完全變了，大家認為低代碼或者模型化驅動方式，一定是未來所有應用軟件這個領域的必然發展方向。
為什么?不單單因為疫情驅動。大家知道應用軟件市場里，軟件市場主要是應用軟件市場。美國分兩塊，中國也是一樣，另外是定制化應用，這兩塊市場在美國是一比一，美國標準化應用是SaaS化應用，這些公司已經發展很好了，而且SaaS在美國滲透率很高了，但中國的SaaS還很早。
反而在定制化市場里面，在美國沒有特別好的一堆公司或者一堆產品來解決定制化的問題。中國市場跟美國市場有同有異，同的地方是我們這些嘉賓談論的，中國中大型企業市場跟美國沒有什么區別。大家對于信息化的投入量、投入金額，我曾經做過對比，同樣一個項目在美國和在中國花多少錢，對比完發現幾乎是一樣的，沒有任何差別。反而中美之間在中小企業市場領域差別很大，這是第一個相同的點。
第二個不同點是中國行業化和個性化對比標準化應用比例遠高于美國，反過來也解釋了為什么SaaS在中國發展有些問題的原因，這個跟日本很像。我研究生在日本讀的，專門做企業應用的架構。日本市場也這樣，基本大的企業全部需要量體裁衣，大的企業自己對業務的理解遠高于軟件廠商，它一定是要通過量體裁衣的方式來做，這是背后大的變化。這也是我們15年回國做這件事情根本的動力。
市場分三個層級：
第一個層級是頭部市場，這些企業原來用甲骨文，用SAP構建其信息化1.0，今天有很多人講低代碼變成熱點繼中臺之后低代碼變成熱點。實際在當年，我們企業構建信息化1.0時，真正的中臺其實就是ERP，就是依托于甲骨文、SAP構建的ERP。
有一個有意思的現象，我15、16年前開始加入做這個開始，當時在美國服務中國的頭部企業。當時的中國頭部企業想法是跟國際接軌，第一個夢想就破滅了，希望能用歐盟對價業務實現，但是它的適配率很低，因為管理階段都不一樣。
第二個維度用上了，把甲骨文、SAP做底座，基于此做行業個性化的開發。80%以上的需求，都是二次開發出來的，甚至有些企業做到95%以上的需求是二次開發出來的。95%的功能用標準功能，為什么還用甲骨文、SAP?因為底座穩固、穩建，做起來很可靠。這個市場在中國已經足夠大了。
再往下把用友、金蝶客戶畫像過來，這個代表了腰部市場，這個市場跟美國同類型的企業本質來講沒什么區別。
這張圖我畫了一下，給大家解釋一下低代碼是怎么來的?任何一個行業一定會有演化的周期，演化的路徑。大家知道我當時在讀高中時，我們那時開始寫代碼，寫應用程序，寫程序時，你需要對硬件懂得，要知道硬件存儲邏輯，那時你不是程序員是數學家，但慢慢的應用開發的模式開始變得抽象，接近于真實世界，脫離于真實世界。到10年時，用pason語言去寫。在10年之前中國所有做應用科技的公司，基本遵循美國框架路徑，美國人干啥我們干啥，它引領了我們的方向，中間可能差五到十年。
10年之后有個分水嶺，10年時我們中國出現中臺，我那時在美國，我當時美國同事問我們到底什么是中臺?我當時說我也不知道中臺是什么。但當時整個方向，無論做業務中臺、數據中臺還是什么中臺，全部往這個方向走。但美國人沒有做這個事情的，美國人干什么?美國人10年之后方向，他認為應用軟件的核心價值并不在于代碼的形態，不在于用java還是用PHP寫，它的核心價值在于背后的業務模型、領域模型，背后的業務邏輯最關鍵。軟件工程理論上等同于建筑工程。
前段時間人社部發了一個公告，很有意思定位程序員屬于農民工一類，其實有這個異曲同工之妙。在建筑工程領域價值已經顯性了，真正聚焦價值部分是在前面設計部分，我的建筑師、設計院設計好了建筑性、結構性。最后施工時是交給哪家施工，本質差別沒那么大，大家都是相對規范完成的。
但是軟件工程不是這樣的，你去交給不同的人去做，而且你要交給一批P8級的農民工讓他去干，這些人的技能還有他的組合差異非常之大，最后呈現的結果差別也會非常大。
美國也發現同樣的事情，我在美國工作了15年，大家一定不要妄自菲薄，覺得美國一定在數字化方面多么先進。絕大多數行業，跟中國一樣都是傳統行業或者制造型行業，傳統行業在跟先進行業競爭人才時都處于劣勢，美國很多行業數字化轉型也痛苦，他希望找到好的途徑幫助他加速和變革。
我這張圖也解釋了一下我們在做這件事情的時候，15年回來的時候的思考。這個圖現在已經慢慢被驗證了，大家可以看到橫坐標表示的是你做這件事情是簡單場景還是復雜場景，這是一個分水嶺，一個維度。另外一個維度，你做這件事情的代價，你的代價是你要花很大代價還是花比較小的代價來做?
今天第一類的場景，比如說我們今天大家如果做一個網站或者說你做一個調研問卷，其實市面上已經有很多工具了，你已經不需要程序員，不需要寫代碼了，這個是單應用場景，它已經完全脫離應用代碼了。
第二個領域是當你做相對來說輕量化以協助為導向的，通過excel表方式可以實現多場景，但是它以協作為導向，以部門級以下的方式來做，這個在國內非常多，在美國也有很多這樣的公司來發展。但它很難做到企業關鍵和核心應用，真正在企業里能夠解決企業關鍵、核心應用還是那些傳統應用型軟件，不管它是本地部署還是走向了云原生化的模式。這些產品和方案遇到的問題，第一它構建時代價很高，第二當這些產品進入到比較大的企業里面時，最后一公里全代碼化的，沒有人完全用標準功能，一定會有大量的二開，這個二開代價又會變的非常高。
所以我們回國做這個事情非常難，第一我們要解決復雜業務建模，第二對技能門檻要求降低。
前段時間我跟美國同事在聊的時候，他們有一個很有意思的判斷，他覺得應用軟件市場經歷了三代的變化，大家知道應用軟件并不是上百年的市場，因為它原來就是IBM、甲骨文、SAP，就是七八年的時間，第一代軟件，老外叫大一統軟件，什么都有，用我的東西就行了。
第二代就走向云化、碎片化，每一個功能做碎化，通過連接方式構建應用。但有一個問題它解決不了核心應用的問題，在美國核心應用系統還是在用甲骨文、SAP來解決它的核心業務。
到了第三代老美認為他們進入到可組合式的平臺，它背后是四件事情構成的：領域建模，我這個平臺可以通過領域建模方式構建我的應用場景;AI，一定有AI人力在里幫助做預測和優化;當不能解決信息孤島時用RPA;事件驅動的模式，會把事件驅動的技術放在里面。我們當時做這件事情的時候也是按照這個思路往前走。
我這張圖給大家解釋了一下這個行業是怎么分割的。大家可以看到這個背后有三個臺階，其實這個市場就分三個臺階，從技術角度量化來看分三個臺階。
第一個臺階當我們做輕量化應用，通過表單級應用來做的時候，通常情況下它的復雜度，單級復雜度是5到10張表，相當于用excel表里的列簽是5到10個。第二類基于模塊化構建的產品，就像aPaaS，它背后的最小元素其實并不是表，它最小元素是業務對象，它是通過業務對象，有點像當年的c++對象編程方式來抽象這個世界。一個業務對象對應多張表，但是為了橫向比較當做一個東西，我們做的場景能做到500個左右的業務對象的復雜度。
我們看到這些頭部企業他們做的這些場景，依托于SAP、甲骨文，主要依托SAP，開發長單體應用復雜度可以5千到1萬張表。
表單級應用，它需要如果往上走就有難度了，結構導致它不太能往上走，所以需要單獨建產品線。
我們在過去兩年時，已經在頭部央企里還有包括金融機構里已經站住了，有機會給大家分享，我們怎么在金融機構里面站住。他們對我們的要求已經不是技術問題，它已經跨越技術問題，技術問題必須要解決，比如替換SAP這些場景。最關鍵的第二步也是隱性門檻特別大的，它的穩定性、可靠性、安全性、可控性包括信創，這樣的代價極高的，這是過往兩年我們跨越的事情。
我簡單講一下我們是怎么做的，用簡單的demo來講一下。模型驅動背后并不是一個新東西，老美在實踐開發領域實現30年的方法論，不單單SAP、甲骨文這么設計的，包括像SaaS公司都是這么設計的。它背后有幾個基本邏輯：
第一個邏輯要把領域模型畫出來。原來討論業務模型時拿出個白板寫成文檔交給程序員開發。現在白板里把業務模型畫出來，通過這樣的方式構建出第一步業務的領域模型。
有了這個東西之后再往下你要構建你的數據結構，相當于蓋房子一樣，跟建筑工程類似。第一要有建筑師設計房子的功能性，第二要交給設計院設計房子的結構性。數字結構交給設計人員把這個畫出來而非寫代碼寫出來。
這個是怎么做頁面，怎么做移動端，這些我們都做了。而且更多的是國內移動端它的要求比國外更高，大家現在都是用微方式啟用釘釘、飛書等，這些我們都做了。而且國內對AI要求比國外高，國內大量UI接受了開源的設計庫模式。
再往下就是流程的設計，你做完這個系統之后，會有流程設計。不單單有大的業務流程的設計，比如業務場景到了每一個節點都會控制點，但是每一個控制點之后，到了具體一個事項，一個事項背后系統干很多事情，同時要干四五件事情，原來的模式是通過BMP模式之后大量寫代碼，我們的設計模式或者老美的理論，在新的模式下也是通過圖形化的方式，通過條件是什么，操作是什么?
一條一條的把它羅列出來。這樣的好處在于它降低技能門檻，實現技能要求。第二因為現在系統大量迭代，你今天給業務部門看完要求改，過一段時間又要求改，換人接的時候很容易讀懂前面的人做了什么東西，把原來迭代的成本跟技能要求大幅降低了。
再往下是怎么解決集成的問題，你在企業里光做應用不夠，一定大量集成。這是一個真實案例，我們怎么跟SAP集成的，怎么同步，做物料的集成?我們的方式SAP有自己的巴比接口解析掉，相當于德語翻譯成英語。另外一個系統肯定有自己的API，API訂閱了自己的規范，我們把另外一端系統API解析掉，可能說日語的也翻譯成英語，翻譯完之后人需要干的就是你要做數據匹配，這邊叫訂單編碼那邊叫平臺ID，這個需要連起來，連起來之后就可以幫你把集成自動生成，后面就是集成的管理等配置化實現。
這樣的話，大大降低原來做這件事情的時間周期和要求。原來做主數據通常是程序員開發五天完成，現在可以在十分鐘之內就可以干了。
怎么擴展?任何一種方法論、工具、產品一定會有邊界，不可能沒邊界。但是我們服務的這些客戶，它必須得達到要求，所以當你在建模的情況下，建模的方式不能滿足客戶需求的時候，我們可以支持客戶來寫代碼。我們可以生成一個在線的開發環境，你再根據你自己喜好的方式、方法不管Java還是什么，寫完之后我們管理你的參數，我們按照規范進行管理，自動化測試要通過，通過之后就可以連到系統里。
我們做過很多像城商行系統，它的整個算法是黑盒的，通過代碼方式寫然后連進來，領域模型不能解決算法的問題。
后面是報表BI層，BI層不用多講了，這個很常見。我們有很多企業有自己的BI工具，可以把數據往外傳，有一些不愿意用第三方BI工具，自己來做非常方便。
后面是非常重要的一點是環境管理，美國非常重視這一點。無論是甲骨文還是SAP在IT環境監測領域，它做了很多工作。這件事情我們也拿來復制了一遍，我們可以做到有正式環境，正式環境之后我點一個按鈕，可以生成多個沙箱環境，然后在影子模式里做測試、開發，把你的新功能從沙箱環境發布到正式環境，發布過程中一旦有了問題，因為在環境管理時會有各種各樣的環境情況，我們可以做到你的整個版本回歸，保證你在版本發版時的安全。
現在的應用系統迭代非常快，它不像原來，原來我們做甲骨文、SAP的時候可能五年一個變化，今天可能是一個月一個變化，我們見到很多頭部企業兩周要升級一次，加新功能迭代，這個迭代是業務環境是導致的。高迭代、高版本發本的情況下對環境安全考慮也是重中之重。
這張圖講了我們做了什么事情?第一個是高性能PaaS，除了對于可控性要求之外，還有一點我們通過建模方式構建應用系統。你今天用匯編語言寫，你的效率一定比用C語言寫效率高，C語言效率比java語言效率高。當你的模型特別復雜的時候，要支撐運行，必須用高性能PaaS進行支撐，我們回國時就解決掉了這個問題。
基于這個之上，我們做了應用搭建的PaaS，我們怎么基于領域建模，把業務模型畫出來來構建業務系統。怎么通過建模的方式解決掉集成的方式。
我們在國內有產品級伙伴，我們被OEM，他們拿去被產品的，有很多變成SaaS公司，也基于信創公司，拿我們東西去服務銀行、服務機構。
這個市場里，美國有三類公司在做：第一類是mx公司，它蠻多年了過往幾年發展都比較快，他們原來都是在歐洲公司，在歐洲誕生美國快速發展。第二類是云巨頭公司，美國微軟15年時提出offcie+team，另外一類是金融、政務、醫療三大行業。
我們回國之后定位做大型企業、復雜場景，而且我們已經進入到了在央企核心場景里進行替換，我們是國內官方市場的。
我們在過往幾年服務了很多央企，幫他們出海，在海外幫他們做各種各樣的產品替換，還有服務的外資企業，我們已經服務了46個國家，15萬企業用戶，幫他們去做各種各樣的獨特系統，不是常見的標準化應用系統。
歡迎大家有什么問題歡迎找我們溝通，這個市場包括這個方式一定會是很大的變化，今天路上的時候我看了一下趙薇的事件，整個中國政治經濟包括社會在變革，軟件行業、技術行業都一樣，它有很多的技術變革點。模型化、可視化一定是未來很大的變革點，不管未來是什么樣的軟件形態，不管是做各種各樣的應用，一定會或多或少采用到低代碼或者模型化的技術。
謝謝各位!
京公網安備 11010502049343號