什麼是低程式碼的窘境？

01 低程式碼的本質

經常有朋友問我：什麼是PaaS?什麼是低程式碼?什麼是無程式碼?

確實，由於新行業發展太快，各種新產品層出不窮，以至於衍生出很多讓人混淆的名詞。

從本質上來說，不管是PaaS，還是低程式碼、無程式碼，其實都是一種應用軟體的構建方式。只是，低程式碼更強調開發的簡易性(比如視覺化開發)，而無程式碼更強調自己壓根不需要開發(比如透過拖拉拽搭建表單)。PaaS則是一個更加綜合的概念，往往包含了低程式碼、無程式碼甚至全程式碼開發的能力。

雖然低程式碼公司和無程式碼公司都非常強調自身產品的獨特性，也有從業者呼籲嚴格區分“低程式碼”和“無程式碼”。但站在企業高層和直接使用者的角度來說，他們關心的其實是以下兩點：

1)我的需求能否得到滿足?

2)需求滿足的速度是否足夠快?

而至於滿足需求的方式，是透過low-code，還是no-code，客戶本質上是不關心的。

同時，當面對客戶個性化、複雜化、動態化的需求，單純的低程式碼或者無程式碼，也很容易遇到各自的瓶頸。

從這個角度來說，PaaS、低程式碼和無程式碼，未來不管是在功能上還是在概念上，都可能實現融合和統一。

也正是因為這個原因——雖然有不嚴謹之嫌——本文仍將把PaaS、低程式碼和無程式碼統稱為“低程式碼”。

02 低程式碼的窘境

我一直認為，一個好的商業模式，最先考慮的一定是客戶需要解決什麼問題，其次才是用什麼工具去滿足客戶需求。

從這個角度來說，偏通用工具屬性的低程式碼，必然會面臨以下挑戰。

第一，複雜需求的挑戰

在一定的技術條件下，靈活性和標準化是存在衝突的。雖然低程式碼透過標準化提高了開發效率，但同時也犧牲了一定的靈活性。

比如，在快消品行業，業務員在手機端錄入銷售訂單是一個非常高頻的操作。以“選擇商品並錄入銷售單位和數量”為例，一位業務員每天可能需要操作幾百行，涉及到幾千次的點選。

對於SaaS產品來說，可以針對這個場景進行非常精細化的設計，以最大化降低業務員的操作難度，並提高操作效率。

而某些低程式碼的功能頁面由於全部由標準化控制元件組裝而成，不能靈活定製，在精細度方面無法達到SaaS產品的水平，必然影響到企業的運營效率。

第二，諮詢需求的挑戰

B端軟體產品的本質，是業務流程的數字化。因此，在軟體上線之前，需要對業務流程進行梳理，並根據梳理的結果對軟體進行適度調整，對業務資料進行整理和匯入。我把這一類需求統稱為輕度諮詢需求。

SaaS產品由於按照特定行業或特定業務領域進行了定製，同時也有專門的人才和方案儲備，在滿足輕度諮詢需求的能力上，相對成熟一些。

而低程式碼產品由於沒有特定的行業與業務領域，或者說覆蓋了較多行業和業務領域，在滿足輕度諮詢需求的能力上，則相對缺乏一些。

當然，某些無程式碼廠商的目標使用者是業務人員，按道理他們應該具備梳理流程和資料的能力。但實際上，‘大部分’公司業務人員的主要精力都放在了業務目標上——除非是比較簡單的區域性需求——大部分業務人員暫時都無意、也沒有能力把流程梳理和資料整理等輕諮詢工作做好。

因此，即便低程式碼能較好的解決開發效率問題，仍然會面臨輕度諮詢能力的瓶頸，這就大大影響了低程式碼進一步擴大市場規模。

當然，任何一個新事物都會面臨各種問題。而低程式碼面臨的這些問題也並非無解。

比如，低程式碼也可以推出行業解決方案或業務解決方案，甚至提供針對具體行業或業務的定製化元件。而人才的問題，只要耐心培養和積累，或者與諮詢公司合作，也可以逐步得到解決。

但是，低程式碼面臨的窘境在於，SaaS公司一定會向下延伸到低程式碼領域，從而與低程式碼公司形成競爭關係。

比如，Salesforce於2008年推出的Force.com，北森於2020年開放給企業客戶的魯班平臺，其本質都是融合了無程式碼、低程式碼以及全程式碼的PaaS平臺。

在SaaS公司深耕的領域，SaaS的優勢非常明顯：

第一，對於核心場景和高頻場景，SaaS產品能夠更好的滿足客戶個性化、精細化需求。

第二，針對目標領域，SaaS公司的客戶成功能力更為突出，積累的資源更為充足。

第三，SaaS公司的注意力更聚焦，其低程式碼產品對目標客群的匹配度也更高。

那麼，面對SaaS公司的強勢競爭，低程式碼公司的機會又在哪裡呢?

03 低程式碼的解答

我一直認為，好的競爭戰略一定是發揮自己的優勢，攻擊對手的劣勢。相對於SaaS來說，低程式碼也有自己的優勢：

1)更通用的軟體搭建能力

大部分的SaaS公司專注於特定領域，這在提高其特定領域能力的同時，降低了跨領域的能力。

而企業是一個動態調整的過程，不斷有創新業務出現，也需要降低試錯的成本。在這種快速迭代的領域，低程式碼平臺無疑是一個成本更低的選擇。

2)更開放的平臺

雖然SaaS公司也可以建設自身的低程式碼平臺，但為了提高領域能力，大多數SaaS公司仍然把自己定位為“特定領域解決方案公司”。

但是，我始終相信，最大的創新力量在企業外部。這也是為什麼Salesforce要創立App Exchange、蘋果要創立App Store的初衷。本質上就是為了吸引更多創業者來為其客戶提供更加多樣化的服務。

B端管理軟體的本質是實現數字化的工具，這就從根本上決定了，數字化諮詢能力與軟體實現能力是不可分割的整體。相對於SaaS公司，低程式碼公司在定位上更加開放和中立，有希望吸引到更多具有諮詢能力和創新能力的創業者。

那麼，低程式碼公司應該如何發揮自己的優勢呢?

我一直認為，在雲端計算這個市場，單點的競爭力都是不足以構成堅固的護城河。

比如，低程式碼公司會認為自己的功能更貼近業務人員，或者認為自己的元件能提高開發效率。但是， SaaS公司的PaaS平臺同樣也可以具備這些功能特性。而且，隨著資金與人才的投入，同樣可以做得很好。

真正堅固的護城河，應該是來自於體系化的優勢。

比如，SaaS星球的一位創業者，是一家服務於某垂直行業的SaaS公司。但是，他並沒有停留在提供軟體的層面，而是親自下場做了一家行業公司，以提升自己對行業的理解和實踐能力。接下來，他又把實踐的成果透過培訓、帶教等形式，輸出給潛在客戶。這樣，一方面“SaaS軟體+行業實踐”的組合能力幫助他不斷擴充市場，另一方面與客戶的深入合作又給他帶來了更多的SaaS軟體創新和更豐富的實踐經驗。

當這個體系形成了正向的飛輪效應，那些試圖用低價策略進攻他的競爭對手，就會面對很堅固的護城河。

低程式碼公司同樣應該構建這樣的體系化優勢。

我常說，SaaS公司最大的競爭對手，其實是他們的客戶和諮詢合作伙伴。

對於客戶來說，SaaS公司不斷上漲的價格、遲緩的響應速度、封閉的功能和資料，都會迫使客戶不得不走上自研的道路。而此時，低程式碼將是SaaS公司很好的替代。

對於諮詢合作伙伴來說，SaaS公司與其存在天然的競爭關係。在SaaS專注的領域，SaaS公司不希望合作伙伴涉入太深。而在SaaS公司不專注的領域，對合作夥伴的支援又太少。

對於合作伙伴來說，與中立、開放的低程式碼公司將有更大合作的空間。

如果低程式碼公司能夠與客戶或者諮詢合作伙伴建立起賦能和互利的機制(而不僅僅是簡單的提供產品和培訓)，那麼形成的整體力量將成為低程式碼公司的體系化能力。

當然，成長的道路並非如想象中那般美好。比如，如何為客戶和諮詢合作伙伴賦能?如何建立起共生的互利關係?這將是一個長期的課題。

但我相信，在克服這個難題的過程中，真正的強者會脫穎而出。