圖片來源@視覺中國

文 | 新眸，作者｜鹿堯

當企業把數字化轉型提上日程時，最先意識到的往往是戰略需求，而不是業務要求。随着轉型由淺入深，速度和質量決定了生死，這時候才發現現有的開發工具與開發方式，管理水平及人才配備，其實很難勝任新的生産需求。

之前有數據統計，從轉型成功率上看，信息化程度較高的行業小于26％，而傳統行業隻在4％~11%區間。為了解決這個問題，行業裡常規的邏輯，企業如果要真的跨越周期，必須先使用合适的新工具，無論是雲計算、Serverless、各種Xaas，目的都是為了理想化的降本增效，低代碼也是同樣的道理。

Gartner認為，未來企業間互動、需要更多的設備接入，業務會更加分散，專業開發者的數量并不足以滿足企業IT需求。供需矛盾間，可視化 拖拉拽的低代碼平台能讓所謂的平民開發者，即普通的業務人員也能進行應用搭建，成為平台的最終用戶，寫更少的代碼，花更少的錢，幹更多的事，這看起來非常誘人，而且蘊含了巨大的商業前景。

2018年是一個有趣的節點，随着OutSystems成為超過10億美元的新晉獨角獸，低代碼概念也被大量曝光，國内低代碼賽道在近幾年也尤為火熱。

中國低代碼行業投融資事件彙總圖源前瞻産業研究院

之後，從2019年阿裡把内部産品宜搭正式對外商用，到兩年後發布低代碼開發聚合平台“釘釘搭”，騰訊上線微搭，華為有AppCube，百度有愛速搭，大廠之外，傳統ISV躬身入局，一大批創業型選手也紛紛湧現。相比國内，國外巨頭的布局更早，微軟、谷歌、亞馬遜都将低代碼看作未來，也都擁有自己的低代碼平台：PowerApps、Honeycode和Appsheet。

理想的狀态是，低代碼能将所有與應用開發相關的活動，都收斂到同一個平台，從而産生更多方面的聚合效應與規模收益，但事實的發展卻并不順利。

站在2022年這個節點上會發現，同為企業服務裡的細分賽道，雖然近年來跑出不少低代碼玩家，但既沒有産生像erp裡的用友、金蝶，更遑論crm領域的salesforce以及協同辦公裡的zoom。反而傳出的更多是被收購的消息，比如西門子收購Mendix和TimeSeries、Magic收購PowPow、字節收購黑帕雲。考古微軟2005年開始投入的webform，InfoPath等工具，也早被時代淘汰，現在一些寄生大廠生态的明星廠商，名聲并沒有如雷貫耳。

願景是美好的，不過現實中類似“低代碼是不是僞需求、是否能真的商業化”的質疑聲也一直不斷，盡管理論上降低了開發門檻，但怎樣讓客戶真正用起來，低代碼還是難以實現純粹的産品化推動。平台如果預設是代碼小白，犧牲上限換短期效率，不僅會限制平台成長，是否真的增效也不一定；如果提供給專業開發者，作用又難免雞肋，更不必說昂貴的變革成本。

為什麼低代碼裡至今沒有keyman，歸根結底，這并不僅是戰略層面拍腦袋能解決的問題，除了開發階段，還要考慮産品的全生命周期，如果将價值認定框在降本增效的标準裡，其實不太符合現實商業原則；數字化轉型的過程中，風很大，具體到産品、市場、業務、用戶、特定的應用場景，有太多的細節需要重新考慮。

01 廠商看技術，甲方看業務

模塊化、可視化的編程方法由來已久。20多年前，微軟的Visual Basic、Access以及Sybase PowerBuilder、Delphi Builder等編程工具風靡一時，都算作比較早期的低代碼工具，多年來熱度起起伏伏，很多人認為，如今不過是用“低代碼”這個新瓶，裝了表單、工作流、業務對象等舊酒，包裝成面向業務應用層的低代碼平台，本質仍是個OA自定義表單和自定義流程引擎而已。

到2020年左右，廣義上的低代碼開發平台包含低代碼與無代碼，前者面向程序員，後者提供給沒有編程基礎的業務人員，用友副總裁羅小江認為，“3-5年内可能低代碼平台主要還是針對專業開發者，混合開發模式能夠簡化一些基礎問題，程序員在此基礎上做複雜開發。”低代碼的成熟度，還停留在需要技術人員在一線業務員和開發商間做溝通的程度。

實際上，現在對于低代碼的各種技術界定、渲染的實際意義不大，它的核心是為了解放生産力，那麼業務邏輯比開發邏輯更重要。低代碼之所以受市場追捧，源于數字化轉型階段的業務與産品供需矛盾。

當深入到具體業務會發現，現在的商業鍊條很複雜，比如從供貨端、各種營銷渠道，到各個電商平台推廣賣貨，現有的進銷存軟件并不能整合管理從收集訂單、組織生産，到調派庫存發貨的不同平台訂單數據，也不能分析銷售情況進行客戶追蹤。

于是，有預算的企業想要自己開發軟件，但在需求、交付時間、質量都不可控的情況下，供需問題短期内很難解決。回到一開始，任何的企業軟件都隻是技術手段，技術最終要解決的是業務和管理的問題。所以，真正要讨論的就變成了低代碼是否真的好用，商業化落地是否可行。

比如在C端，消費者的需求千變萬化，供應商是很難靠賣純粹低代碼平台來賺錢，加上用戶的産品認知度不高，市場教育成本不容忽視；為了維持基礎能力，要兼顧定制的靈活性和運行的高性能，因為使用的人越多，邊際成本才越低，這些對一般初創廠商來說壓力山大。

如果在B端，考慮是否真的給企業客戶降低了成本，并且滿足個性化需求，這意味着企業結果導向。市面很多産品都是固定化流程設計，功能缺失或冗餘難以避免，比如當你買了一個進銷存系統，但當想統籌管理人員績效時，就得去買另一個，這種情況下的理想場景是，企業人員能夠按需自行設計多場景系統，聽起來似乎更實用。

大企業的業務流程、數據邏輯往往按照業務規範去做，低代碼平台加上成熟的解決方案，可以更快捷地搭建；但受限于服務能力邊界，低代碼有明顯的天花闆，它無法替代當下的中、高級開發工作需求。中小企業的使用意願也會被高估，即使用輕量化場景來，滿足這些業務邏輯更簡單的企業，除了搭建成本，還要因為業務不規範的“削履适足”，低代碼反而不容易應對。

現階段，不論在C端還是B端，在業務還沒有實現标準化，數據也沒建立标準時，低代碼平台都不可能滿足任意複雜度的業務，這也讓它的應用場景被局限在那些隻能被标準化的領域裡，完成業務的全面覆蓋更不現實，還會對企業的數據治理、信息安全産生隐患。

敏捷、普适、豐富的場景、性價比高，這是每一個低代碼廠商在宣傳自家産品時會用到的ppt話術，也是資本喜聞樂見的故事。不過作為入局者，釘釘、用友和簡道雲的相關負責人都曾表示，低代碼市場的宣傳是有些言過其實的，拓荒的過程很艱難，目前的滲透率極低，在所有的行業裡滲透率基本上都是個位數，甚至僅僅1%、2%。

中國低代碼市場滲透率低圖源洞見研報

在數字化浪潮中，RPA賽道的玩家們也正在經曆類似的事情。由于低代碼環境弱化編程需求，RPA市場邊際擴大，并被認為是全球增速最快的細分軟件市場，僅今年上半年，以達觀數據、影刀為代表的國内RPA廠商累計融資金額達20億，相關企業注冊量接近400家。

但相較國外各領域對RPA的應用已經成熟，比如UiPath雖然驗證了商業模式和落地場景的可行性，但國内的廠商仍在找試驗田，具體到哪些業務流程适用RPA機器人，産品應用範圍、邊界及周期怎麼定，市場還未實現規模化驗證。加上産品功能的單一同質等問題，以至于國産RPA廠商客戶年流失率平均在30%，遠高于國外。

低代碼和RPA的高開低走，其實不難理解，我們很多時候對于一個新興概念的熱捧，要遠高于産品彼時存在的實際價值，即使它被認為是發展潛力巨大的風口，但在早期階段，缺乏本土市場驗證的情況下，産品是沒有普适性的，更不是企業用來加速适應市場的“萬能藥”，與其忽視市場的複雜去盲目照抄，或者積極炒作甚至削足适履，都不如在适當的階段做恰當的事更合時宜。

02 從低代碼平台到生态

今年上半年，低代碼廠商黑帕雲正式停服，從被資本熱捧到被字節收購，黑帕雲是賽道熱潮中首個退出的玩家，這件事也被看作國内低代碼行業洗牌的開端。

低代碼廠商圖譜圖源艾瑞咨詢

在停服之前，有人評價黑帕雲是綜合能力最好用的輕量級數據協作工具。剛上手的時候可以直接當作Excel用，但它本身不僅比Excel更容易理解且支持協作，數據保存的完整性上也表現不錯；接着在使用過程中加深對業務理解進一步升級業務系統，也就是說，軟件本身并不是最重要，對業務和數據的理解、從而讓業務系統不斷生長的過程才是最重要的。

收購後不久關停，有人将原因歸為飛書的核心産品多維表格，後者功能與黑帕雲類似，雖然字節在低代碼領域行事低調，但多維表格本身也是低代碼的一個體現。飛書向來采取all in one 的策略，大客戶的需求大多由飛書自己來做，随着業務的深化，用低代碼去滿足海量需求可以算是布局未來。

互聯網巨頭都在低代碼領域加緊布局，像黑帕雲的例子并不鮮見，雖然小企業的品牌變現能力對于大廠來說并不誘人，但沉澱下來的核心技術、産品理念和經驗的确是有價值的。這也反映出，在本身沖突就很多的低代碼賽道，走中小客和PLG增長這一路線的小團隊，想要實現商業變現難上加難。

阿裡的思路不太一樣，在賽道之外，低代碼起着“連接”和“高效辦公”的作用。草蛇灰線，從2019年張勇首提“商業操作系統”，希望幫助企業實現品牌、商品、銷售、營銷、渠道管理、物流供應鍊等多環節的數字化；次年，釘釘升級為大釘釘事業部，并融入阿裡雲智能事業群，釘釘成了雲服務的平台。

釘釘推出的低代碼開發聚合平台”釘釘搭”，聚集了宜搭、簡道雲、氚雲、輕流在内的8款主流低代碼廠商，金蝶、用友、紛享銷客等也是釘釘生态一員。與其說是細分賽道裡的低代碼平台廠商，釘釘更像一款協作辦公平台，基于協同密度來建設應用生态，這樣一來，對原有的存量系統服務，面對複雜且分散的業務，釘釘起到連接器和整合的作用。

同一時期，用友完成ERP到BIP，從産品服務模式升維到平台服務模式。2020年發布的低代碼平台YonBuilder為用友自身、夥伴、客戶的應用開發提供統一開發輸出的能力，幫助用友BIP實現商業落地。YonBuilder的存在和後來加入的APICloud，完善了用友的服務鍊條，和釘釘主打平台及應用生态不同，用友側重開發者生态和低代碼産品。

在傳統軟件轉雲的廠商，和互聯網玩家紛紛進軍低代碼的情況下，構建生态成為共識，意味着現階段很難出現直接對标Airtable、Notion的獨立産品。這類似曾經國内爆火的BI賽道，随着大廠BI産品銷聲匿迹，大部分獨立BI廠商以被收購、退出市場或抱團取暖收尾。同樣作為一種輔助性工具，從狹隘的定位上，低代碼是否會重蹈覆轍還需觀望。

03 比起開發，說搭建更合适

如果打開知乎搜索低代碼，會發現很多人的字裡行間不乏抱怨。“别的不說，單就工作量是一點都沒有減少，反而平添了很多很多的麻煩，不用‘低代碼’平台分分鐘就能開發出來的功能，用了之後得花更多的時間。”

因為目前大部分低代碼平台都是高度封裝，高度耦合的開發模式，所有功能必須得按照平台既定的規則開發,假如隻是簡單的增删改查，導入導出，聘一堆薪資不高的外包去用低代碼寫重複度高的業務，那确實是沒有問題。一旦遇到客戶有類似五彩斑斓的黑的要求，平台現有的功能又無法滿足，很多人連Excel都不會用，更别提改代碼，最後隻能是做開發的人來返工。

雖然不論是Gartner還是IDG，市場都對低代碼的未來表現高度熱情，但局中人冷靜發言，“它既不是模式的問題，也不是資本問題，而是賽道問題。低代碼産品好像什麼需求都能做，但是好像每種需求又做不好。”簡道雲聯合創始人單蘭傑認為，低代碼最大的問題，是這種産品形态怎麼能夠持續地滿足客戶需求。

确實是這樣，低代碼可能會是程序員的一把工具，但不會成為颠覆行業的東西。正如前言，同為企業服務裡的細分賽道，低代碼這一支尤其分散，看似每一項業務都能适配，但實際的業務用途目前還是狹窄，大多限于簡單的行政類、人事類需求，例如工作流和表單流轉，大軟件的部分功能延伸，面向企業用戶的快速補充開發。企業的核心業務如生産、銷售、采購庫存等，還是要用傳統的erp，這些很難用低代碼去實現。

它的出發點是好的，我們傾向認為低代碼彌補中小企業開發人員數量上的不足，但開發是一回事，能用起來是另一回事。低代碼能力是否會變成一個與Office套件一樣普及的基本辦公職業技能，尚不可知；未來是繼續加功能，還是開放更多的接口，做交付動作滿足需求，還是産品保持簡潔，通過一些其他模塊，或應用市場的方式去解決問題，這些也不好回答。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部