一、低程式碼們發展的如何了？

一轉眼，距離釘釘6.0釋出會上提出“低程式碼開發”這一概念已經過去了 17個月時間。整個低程式碼市場的參與者，也由最初的少數競爭到現在的大廠相繼入局。使用者對於低程式碼的認知和接受程度也逐步提升。“低程式碼”這個概念，已經從“ 玩具”慢慢走向了“ 工具”。

“低程式碼”是一個舶來品，因為早在08年，一個叫做salesforce的產品就已經提出了快速開發應用的概念，在他們的平臺上誕生了 千萬個定製化的資訊化管理應用，salesforce也因此一躍成為全球最賺錢的軟體公司之一。

與此同時，國內一些廠商也看到低程式碼的前景，開始佈局“低程式碼”概念，但是直到2020年底的釘釘6.0釋出會，低程式碼才開始真正進入到大眾視野來。如今，就連 金蝶、泛微、藍凌這些老牌的資訊化系統廠商也紛紛加入到低程式碼的競爭中來，可見低程式碼即將成為下一個風口。

近年來，隨著產品成熟度的不斷提高，針對企業深度業務場景和綜合性需求的“ 企業級低程式碼”的概念應運而生。那麼什麼才是“企業級”低程式碼？為什麼說“企業級”會更好？接下來我們就來探個究竟。

大家在調研低程式碼的時候一般都會發現一個問題。看上去都叫做「低程式碼」的產品，但是實際上差異巨大。那麼低程式碼的廠商，到底分為幾類，各有什麼優勢呢？

（1）Excel類

此類產品主要是為了服務重度Excel使用者的，作為Excel的加強版本，主要著重在 使用者協同和資料流轉方面有了更深入的業務支援。並且搭載一定的擴充工具，例如賬務套打和資料收集功能。這一類產品，在一些特定流程和場景下面，的確有著更大的優勢，但是在於複雜業務系統的需求方面呢。就顯得有一些單薄了。

（2）IDE類

此類產品主要是由於國外在低程式碼市場上有一些新的探索，從開發者的角度來說，IDE類工具，可以節省程式設計師重複敲程式碼片段的時間。用 圖形化、配置化的方式，去構建一些程式碼片段和模組，會更加省力。但是這類產品在國內的市場並沒有很受歡迎，主要的原因還是在於，程式設計師對於IDE類低程式碼仍持觀望態度，而非程式設計師使用者受限於自身沒有程式設計基礎能力，也無法順利驅動產品來完成自己的需求。

（3）BPM類

BPM誕生的那個年代，可能還沒有“低程式碼”這個名詞，但是不可否認，BPM已經可以認為是最早的低程式碼級產品了。因為在企業的業務發展中，流程管理本來就是非常高頻出現的業務需求。對於定製化也有非常強烈的需求。BPM工具本身就深一個基於某個業務場景，進行了抽象的模型提煉，例如 節點、分支、使用者行為等，從而誕生的可以滿足不同行業的通用性工具。

由於大部分的企業目前對於資訊化的需求集中在OA辦公，所以BPM已經成為了企業必不可少的。但是隨著企業資訊化程度的進一步加深，BPM在非流程的需求領域，支援能力就逐漸減弱了。這也讓BPM廠商開始往更多的功能和模組的方式，去擴充自己的業務版圖。

（4）企業級低程式碼

為了不斷滿足企業使用者的各類場景需求，兼顧靈活配置、高效生產、功能豐富的“企業級”低程式碼平臺自然成為更好的選擇。

二、什麼是“企業級”低程式碼？

從企業的更多需求場景出發。企業的內部資訊化需求，往往集中在這幾個方面：

（1）流程管控。像企業日常OA辦公中，就存在大量的流程需求，例如，報銷、合同審批、入離職等等，但是由於各企業規章制度和管理辦法的不同，這些需求往往都存在個異性。所以在流程上，需要有更靈活的配置功能。

（2）資料處理。 提供企業級的高階特性，旨在更敏捷優雅的處理資料。

（3）業務需求。以前我們在談論軟體開發時，通常會想到由經驗豐富的IT技術人員來做應用程式的開發。現如今，低程式碼儼然已經有了引領全民開發者的新時代，它能深度連線業務與IT，填補了業務軟體的需求和開發人員短缺的缺口。即便是一個沒有經過軟體開發培訓的使用者，仍可以使用低程式碼平臺構建應用程式。

三、“企業級”低程式碼平臺應具備哪些能力？

對於低程式碼工具來說，如果能在這些需求上提供更強的能力支援，那麼他們必須要有足夠強的模型提煉能力和更細顆粒度的配置元素了。這往往取決於產品研發團隊的專案經驗和積累。因為如果沒有具體的系統開發實踐，在企業管理系統上的需求是很難憑空想象的。

我們用“低程式碼”的視角，分析了 400多個企業資訊化建設的專案，目前抽象出了以下5方面能力。

1、場景建模能力

資料模型是系統的基礎，豐富的場景建模能力。低程式碼平臺對於資料模型的支援決定了業務場景的覆蓋範圍。在資料層面來看，很多的欄位或者資料型別，並不是單一的。在業務場景的落地中，很多的資料欄位需要和業務流程、操作行為等進行高度的解耦，因此能否覆蓋更多場景的建模能力，會成為低程式碼平臺能力邊界的決定性因素。

2、介面開發能力

Excel表單在企業辦公過程中的作用和地位逐漸下降的原因，其實也是在於表單式的互動在很多場景中變得不那麼適用。例如庫房、工位或者一些非辦公室的場景，使用者可能更多的是手持裝置，需要有更加便捷的輸入方式。而不同的場景輸入方式又各有區別。所以對於低程式碼平臺而言，能否提供更多的互動方式或者介面開發能力。

3、系統對接能力

權威機構Forrester將API介面認定為企業級低程式碼開發平臺的重要標誌，通過內建的API介面功能，企業級應用便可整合或對接其它系統，打通資料連結，避免資訊孤島。

企業級低程式碼除了有內建常規的第三方API介面之外（對接企業微信、釘釘、公眾號等已有平臺，還能對接企業原有的OA、ERP、MES、EHR等系統），甚至還可以對接lot物聯網軟硬體裝置、BI資料大屏。而且API介面的開發是可以即改即生效的，所以系統對接能力也稱得上是企業級低程式碼的真正能力。

4、元件擴充能力

允許使用者自主擴充和定製元件，才能夠滿足其功能複用的需求，也能讓低程式碼的開發效率拉昇到更高的水平。對於長期迭代的業務而言，日常使用最頻繁的一定是業務元件，而不是通用的公共元件。這種情況下，若低程式碼平臺能支援使用者自主擴充元件，或與標準元件混用是企業級低程式碼平臺需要提供的能力之一。

5、資料處理及穩定性

這個能力其實在低程式碼平臺上並不好體現，其主要原因是低程式碼平臺目前的實踐場景中大多還是淺層次、輕量級的業務需求，對於大資料量、高併發的真實測試目前還不具備參考性。

但是既然作為企業長遠發展的必備工具之一，低程式碼在複雜極端環境的應對能力肯定是必須。特別對應大使用者、資料量的應用的多版本、多環境管理。能否像那些成熟的大型系統一樣，能夠從技術和解決方案上來保障業務的持續性開展，一定是每個低程式碼廠商都需要去思考的問題。

以上面這個能力標準，我們給當前的低程式碼廠商進行了一次分類。

在我心中，目前比較符合企業級低程式碼概念的廠商有： 織信Informat和 clickpaas。

四、低程式碼在企業數字化轉型中應該扮演什麼樣的角色？

“低程式碼”本質是工具！

由於低程式碼平臺不像市面上其他的成熟的資訊化系統，可以即裝即用，所以對於大多數企業來說並不能快速的搞清楚低程式碼平臺在企業中的定位，以及所能給到企業的幫助。從而對“低程式碼”產品望而卻步。

從本質上來說，低程式碼平臺還是一個技術性產品，是一個“工具”，企業成員可以用這個工具，在沒有技術人員支援的情況下，去“實現”一些複雜的資訊化需求。這個需求可以是流程審批、也可以是資訊收集，也可以是資料看板。

五、“低程式碼”對IT人員是否也有價值？

答案當然是有的，

公司的IT人員，往往會花費大量的時間，束縛在程式的優化、功能的反覆調整中。這些需求往往看上去簡單，調整起來工作量極大。但是有的變動實際上也只是業務在流程上的探索，並不一定產生實際價值。而低程式碼平臺，往往十分適合這些需求的開發和調整。甚至都用不到IT人員參與就可以完成。這樣一來，IT人員將會有更多的精力，投入到技術含量更高的程式開發中去。

低程式碼的平臺對於企業IT部門來說，極大程度的優化了技術資源配置。

六、低程式碼在企業數字化轉型中起到的作用

作為一款工具，低程式碼在企業發展的過程中，往往扮演的角色也不相同，一般會分為3個階段：

1、補齊短板

作為剛進入企業的低程式碼平臺，肯定不是大刀闊斧地對原有系統和流程進行替換和重建，一般建議通過發揮低程式碼靈活、快速上線的優勢，去補充當前資訊化環境下的業務短板。通過一些 輕應用、微服務的形式作為原有系統的補充和延伸。這樣以來也可以讓業務部門更快地適應和了解低程式碼平臺的能力邊界，為下一步建設獨立完整的業務系統做好準備。

2、獨立建設

隨著團隊對低程式碼的認識和使用程度加深，企業可以開始著手通過低程式碼平臺去構建一些獨立的應用系統，特別是那些新的業務線所需要的資訊化系統，低程式碼可以幫助企業管理者快速地落地整套資訊化流程，並且根據業務推進的情況及時進行調整，這極大的降低資訊化系統在新的業務領域的 試錯成本。這種需求在以前的業務模式下，往往都是直接被忽略的。

3、構建生態

低程式碼平臺具有先天的資料流動優勢，企業在低程式碼平臺上構建的應用越多，資料互通能力就越強，通過資料和許可權的配置即可輕鬆實現多個應用之間的資料關聯，實現業務鏈的全程溯源。通過低程式碼平臺就像是一個PaaS工具，企業可以通過在上面構建各類應用的方式，打造一套能夠相互聯通的 數字化生態體系。從而充分挖掘資料價值，為企業管理者提供更多的決策依據。

低程式碼目前依然還處於初期階段，還需要更多的廠商能夠通過與企業一起共建的形式，探索出一條更加高效、便捷的低程式碼數字化升級之路。打造出一套標準、可用的低程式碼數字化轉型方案。

本文內容屬於織信Informat自主原創，轉載請註明來源，謝謝！