apaas市值（APA股價）

本篇文章給大家談談apaas市值，以及APA股價對應的知識點，希望對各位有所幫助，不要忘了收藏本站喔。 今天給各位分享apaas市值的知識，其中也會對APA股價進行解釋，如果能碰巧解決你現在面臨的問題，別忘了關注本站，現在開始吧！

本文目錄一覽：

• 1、傳字節跳動已購買，“黑帕云”
• 2、低代碼究竟是什么？
• 3、企業服務模式之爭
• 4、低代碼市場發展前景如何？
• 5、低代碼究竟是什么

傳字節跳動已購買，“黑帕云”

傳字節跳動已購買，“黑帕云”

傳字節跳動已購買“黑帕云”，有多個獨立信源表示，黑帕云團隊已被字節跳動收購，創始人陳金洲以及部分團隊成員已入職飛書，負責aPaaS產品“昆侖”，傳字節跳動已購買，“黑帕云”。

傳字節跳動已購買，“黑帕云”1

3月21日，初代低代碼廠商黑帕云宣布將于5月底停止服務，據業內人士透露，其創始人陳金洲將入職字節跳動，團隊現已解散。

根據黑帕云官網消息，其現有用戶可以在2022年5月31日前導出數據；3月31日前套餐未到期的客戶，可以在4月8日前申請退款，或者將業務遷移到其他低代碼廠商。黑帕云官方推薦了明道云、飛書多維表格、輕流、簡道云、易鯨云、維格表等同類型產品。

從6月1日0點開始，黑帕云會刪除包含業務數據、附件、評論等所有數據，關停所有服務器，之后用戶將無法訪問任何相關服務或者數據。

對于上述業內人士消息，界面新聞嘗試聯系陳金洲和字節跳動方面進行求證，但尚未得到回應。

黑帕云成立于2019年，是一款以協作表格為形式的低代碼產品，公司位于武漢。

其創始人陳金洲曾創立過另一款在線表單工具“金數據”，后被AdMaster在2015年全資收購。據公開資料，陳金洲曾在國際IT咨詢公司ThougtWorks擔任產品總監和首席咨詢師，金數據就是ThougtWorks內部孵化的項目。再之前，他曾在北京巨石空間科技有限公司及中國農業銀行從事技術工作。

一位知情人士表示，原黑帕云團隊基本解散，“高層都走得差不多了，產研團隊也早被同行‘瓜分’完了，還沒離職時就被預定了。”

據36氪今日報道，陳金洲在入職字節跳動后將負責aPaaS產品“昆侖”，主要面向大客戶，且職級較高，直接匯報給飛書CEO謝欣。

黑帕云與字節跳動關系匪淺。2021年7月，黑帕云曾獲得字節跳動數千萬元A輪融資，這也是其最近一輪融資。2019年7月以來黑帕云共獲4輪融資，包括種子輪、天使輪、pre-A及A輪，資方包含盈動資本、初心資本及字節跳動。但在2022年初，字節跳動相關資本從黑帕云股權結構中退出。

有投資圈人士對界面新聞表示，去年年底開始業內就傳言字節跳動將收購黑帕云。由于黑帕云所處的低代碼賽道曾勢頭火熱，當時不少業內人士認為，是因為黑帕云業績不行，資方才選擇退出做股權重構，下一步會進行收購。

據知情人士稱，黑帕云目前約有200家付費客戶，這些客戶可選擇退款或將業務遷移至明道云等同類產品。

去年，低代碼領域是科技圈為數不多的風口之一，初創公司融資熱從年初持續到年終，去年3月僅上半月，就有5起低代碼領域大額融資事件出現。相比之下，2018年至2020年三年內，低代碼領域全部投融資事件只有16起。知名公司如伙伴云、輕流、clickpass、摩爾元數連續獲得了頭部VC的多輪加碼。

資本熱捧之下，提倡“樂高積木”玩法的低代碼公司之間水平差距其實不大。相較而言，黑帕云某種程度上模仿的是Airtable在2018年之前的表格功能，面臨著騰訊文檔、石墨文檔、釘釘文檔、飛書表格這些云表格類巨頭，行業空間越來越小；

而新型廠商伙伴云、輕流、簡道云和明道云效法的是美國行業標桿Airtable在2018年之后主攻的解決方案方向，目前來看完成度和競爭力更高。

黑帕云如今的結局也標志著低代碼領域開始進入淘汰賽階段。

傳字節跳動已購買，“黑帕云”2

今日，無代碼廠商“黑帕云”宣布將停止服務和維護，用戶可以在2022年5月31日前導出數據。套餐未到期的客戶可以申請退款，或者將業務遷移到其合作伙伴明道云平臺上。

據36氪報道，有多個獨立信源表示，黑帕云團隊已被字節跳動收購，創始人陳金洲以及部分團隊成員已入職飛書，負責aPaaS產品“昆侖”，將主要面向大客戶。

天眼查App顯示，成都黑帕云公司成立于2019年4月，法定代表人為陳金洲，是一家數據協作管理平臺，曾獲字節跳動領投的數千萬元A輪融資。

該公司目前有3位股東，最大股東為陳金洲，持股56.44643%，股東還包括武漢茂彤科技合伙企業。

成都黑帕云信息技術有限公司成立于2019年，創始人陳金洲曾為在線表單設計及數據搜集工具金數據的創始人。2019年10月黑帕云正式上線內測，迄今為止，已為上萬家企業用戶提供數據協作管理產品及服務，支持業務人員擺脫陳舊僵化的固定軟件，解放生產力，提升企業數字化水平。

黑帕云的定位是企業業務信息系統，只是入口以表格的形式體現。企業業務主管可以運用黑帕云建立同符合自身業務的信息系統，并靈活設置數據維度、字段、邏輯等。輔以看板、表格等多種系統，企業可以為數據找到匹配的呈現方式。

當前，黑帕云在商業落地上處于自然增長狀態，當前用戶數已達數萬，單賬號一年收費240 - 480元左右。在客戶粘性上，付費用戶的使用頻率已到達每周4天。此外，黑帕云也有初步進行項目咨詢等的商業探索。

“對標美國市場，比如Smartsheet大概有7萬付費客戶，但是就撐起100億美金市值。中國的中小企業客戶正在快速成熟，未來的客戶價值將會不斷提高，黑帕云非?？春梦磥淼闹行∑髽I服務市場?！标惤鹬薇硎尽?/p>

“對于未來發展，隨著市場成熟，中小企業會是非常廣闊的市場，黑帕云希望專注做簡單易用的產品，以較低的服務成本，服務海量的'企業客戶。”

傳字節跳動已購買，“黑帕云”3

今日，無代碼廠商“黑帕云”宣布將停止服務和維護，對于公司的后續進展，有多個獨立信源對36氪表示，黑帕云團隊已被字節跳動收購，創始人陳金洲以及部分團隊成員已入職飛書，負責aPaaS產品“昆侖”，將主要面向大客戶。

“陳金洲入職字節的級別很高，直接向謝欣匯報?！倍辔伙w書內部人士對 36 氪說到。謝欣為字節跳動副總裁，分管飛書業務。

36 氪就收購一事對字節跳動與陳金洲尋求確認，截止發稿暫未得到回復。

在黑帕云本日的公告中，其團隊表示用戶可以在2022年5月31日前導出數據。套餐未到期的客戶可以申請退款，或者將業務遷移到其合作伙伴“明道云”平臺上。

“黑帕云”成立于2019年，創始人陳金洲為連續創業者，此前曾創辦“金數據”，定位在線表單設計及數據搜集工具，金數據于2015年被AdMaster全資收購。

黑帕云的變動已有預兆。2021年7月，黑帕云宣布獲得字節跳動數千萬元A輪融資。而今年年初，據工商信息，原股東武漢全盈科技合伙企業（有限合伙）、字節跳動子公司北京量子躍動科技有限公司等從黑帕云股權結構中退出。

一位相關人士對36氪表示，本次收購是由飛書業務團隊推動，飛書內部已有多維表格等類似產品，共同商量后，決定停止黑帕云相關業務。

國內低/無代碼投資熱潮集中在2019年后，簡道云、氚云、輕流、易鯨云等廠商都在近幾年陸續獲得大額融資。廠商們一般分兩種路線，一是走中大客市場，以項目制為主；二是瞄準中小企業市場，走產品路線，黑帕云更偏向于后者。

黑帕云的關停，也顯示出低/無代碼領域+中小客市場的艱難。一位行業人士對36氪表示，黑帕云團隊注重產研，產研團隊能力很強，但產品商業化暫時沒有跟上，且瞄準中小客市場，這是公司難以為繼的關鍵原因。

但事實上，不只是黑帕云，曾經火熱的“低/無代碼”風口，如今這類廠商的商業化正經歷艱難爬坡期。。

長久以來，低代碼“舊瓶裝新酒”、是否真正能商業化的聲音不絕于耳。盡管降低了開發門檻，但要讓客戶用起來，低代碼很難以純粹產品化的形式推動——對沒有IT基礎的用戶而言，低代碼還是需要廠商的一定服務；而專業 IT 人員又更傾向于自己上手開發。

另一方面，對比歐美市場，國內客戶的信息化程度還在比較初期，低/無代碼產品在客戶定位上較難。低代碼產品無論是產品研發還是實施，都是系統級工程，對人才要求較高。

因此，在商業化層面，低代碼領域做中小客這一路線會更為艱難。對創業公司而言，無論是資金還是人才，都是一筆不菲的成本。對低/無代碼產品這類新興產品而言，教育成本尤其高。

另一個變量則是互聯網巨頭的入局。

2020 年前后，諸如阿里、騰訊等大廠開始入局低代碼，加速了賽道洗牌。2021年初，阿里云將內部的低代碼開發平臺“宜搭”接入釘釘，而騰訊也推出了“微搭”低代碼開發平臺；到了2021年10月，釘釘低代碼聚合平臺“釘釘搭”還聯合了8家主流低代碼廠商，共同宣布成立低代碼聯盟。

一位行業人士對36氪表示，黑帕云關停，部分證偽了低代碼領域的中小客和PLG增長這一路線，國內現階段還很難出現直接對標Airtable、Notion之類的產品，低代碼領域還有很長一段路要走。

投資熱度陡增、大廠入局，能夠加速行業發展。但面對極其早期的市場，對創業公司而言，盡早摸準目標市場，是更重要的事。

低代碼究竟是什么？

簡介：?什么是低代碼？我們為什么需要低代碼？低代碼會讓程序員失業嗎？本文總結了低代碼領域的基本概念、核心價值與行業現狀，帶你全面了解低代碼。

什么是低代碼

“Low-Code”是什么？如果你是第一次聽說，沒準也會跟我當年從老板口中聽到這個詞后的內心戲一樣：啥？“Low-Code”？“Code”是指代碼我知道，但這個“Low”字是啥意思？不會是老板發現我最近趕工寫的代碼很丑很“Low”吧... 想多了，老板怎么可能親自review代碼呢。那難道是指，“Low-level programming”里的“Low”？老板終于發現讓我等編程奇才整天堆Java業務代碼太浪費，要派我去閉關寫一個高性能C語言網絡庫... 顯然也不是，老板哪能有這技術情懷呢。那到底是什么意思？作為一名搜商比情商還高的程序員，能問Google的絕不會問老板。于是我一頓操作后，不假思索地點開了第一條搜索結果：Low-code development platform。

Wikipedia定義

從Wiki的這段定義中，我們可以提煉出幾個關鍵信息：

? 低代碼開發平臺（LCDP）本身也是一種軟件，它為開發者提供了一個創建應用軟件的開發環境?？吹健伴_發環境”幾個字是不是很親切？對于程序員而言，低代碼開發平臺的性質與IDEA、VS等代碼IDE（集成開發環境）幾乎一樣，都是服務于開發者的生產力工具。

? 與傳統代碼IDE不同的是，低代碼開發平臺提供的是更高維和易用的可視化IDE。大多數情況下，開發者并不需要使用傳統的手寫代碼方式進行編程，而是可以通過圖形化拖拽、參數配置等更高效的方式完成開發工作。

Forrester定義

順著Wiki的描述還能發現，原來“Low-Code”一詞早在2014年就由Forrester提出了，它對低代碼開發平臺的始祖級定義是這樣的：

請點擊輸入圖片描述

相比Wiki的版本，這個定義更偏向于闡明低代碼所帶來的核心價值：

? 低代碼開發平臺能夠實現業務應用的快速交付。也就是說，不只是像傳統開發平臺一樣“能”開發應用而已，低代碼開發平臺的重點是開發應用更“快”。更重要的是，這個快的程度是顛覆性的：根據Forrester在2016年的調研，大部分公司反饋低代碼平臺幫助他們把開發效率提升了5-10倍。而且我們有理由相信，隨著低代碼技術、產品和行業的不斷成熟，這個提升倍數還能繼續上漲。

? 低代碼開發平臺能夠降低業務應用的開發成本。一方面，低代碼開發在軟件全生命周期流程上的投入都要更低（代碼編寫更少、環境設置和部署成本也更簡單）；另一方面，低代碼開發還顯著降低了開發人員的使用門檻，非專業開發者經過簡單的IT基礎培訓就能快速上崗，既能充分調動和利用企業現有的各方面人力資源，也能大幅降低對昂貴專業開發者資源的依賴。

低代碼核心能力

基于上述的定義和分析，不難總結出如下這3條低代碼開發平臺的核心能力：

請點擊輸入圖片描述

??全棧可視化編程：可視化包含兩層含義，一個是編輯時支持的點選、拖拽和配置操作，另一個是編輯完成后所及即所得（WYSIWYG）的預覽效果。傳統代碼IDE也支持部分可視化能力（如早年Visual Studio的MFC/WPF），但低代碼更強調的是全棧、端到端的可視化編程，覆蓋一個完整應用開發所涉及的各個技術層面（界面/數據/邏輯）。

??全生命周期管理：作為一站式的應用開發平臺，低代碼支持應用的完整生命周期管理，即從設計階段開始（有些平臺還支持更前置的項目與需求管理），歷經開發、構建、測試和部署，一直到上線后的各種運維（e.g. 監控報警、應用上下線）和運營（e.g. 數據報表、用戶反饋）。

??低代碼擴展能力：使用低代碼開發時，大部分情況下仍離不開代碼，因此平臺必須能支持在必要時通過少量的代碼對應用各層次進行靈活擴展，比如添加自定義組件、修改主題CSS樣式、定制邏輯流動作等。一些可能的需求場景包括：UI樣式定制、遺留代碼復用、專用的加密算法、非標系統集成。

不只是少寫代碼

回到最初那個直擊心靈的小白問題：Low-Code中的“Low”，到底是啥意思？答案已經顯而易見：既不是指抽象程度很低（相反，低代碼開發方式的抽象程度要比傳統編程語言高一個level），也不是指代碼很low（也相反，低代碼所生成的代碼一般都經過精心維護和反復測試，整體質量強于大部分手寫代碼），而是單純的“少寫代碼” —— 只在少數需要的情況下才手寫代碼，其他大部分時候都能用可視化等非代碼方式解決。

再往深一點兒看，低代碼不只是少寫代碼而已：代碼寫得少，bug也就越少（正所謂“少做少錯”），因此開發環節的兩大支柱性工作“趕需求”和“修bug”就都少了；要測的代碼少了，那么測試用例也可以少寫不少；除了開發階段以外，平臺還覆蓋了后續的應用構建、部署和管理，因此運維操作也更少了（Low-Code → Low-Ops）。

然而，少并不是最終目的：如果單純只是想達到少的效果，砍需求減人力、降低質量要求也是一樣的。低代碼背后的哲學，是少即是多（Less is More），或者更準確說是多快好省（Do More with Less） —— 能力更多、上線更快、質量更好，成本還更省，深刻踐行了阿里“既要，又要，還要”的價值觀精髓。

請點擊輸入圖片描述

平臺的職責與挑戰

上面說的是低代碼給開發者提供的能力與吸引力，那么作為服務的提供方與應用的承載者，低代碼開發平臺自身應該承擔怎樣的職責，其中又會遇到多大的挑戰？是否就一定要如阿里云所主張的那樣，“把復雜留給自己，把簡單留給別人”？雖然這句話聽起來很深明大義，但不知道大家有沒有想過，為什么我們一定要抱著復雜不放，平白無故給自己找事？就不能直接干掉復雜，也給咱阿里云自己的員工留點簡單嗎？是工作太容易就體現不出來KPI價值了，還是家里的飯菜不如公司的夜宵香？

冥思苦想許久后，我從熱力學第一定律中找到了答案：開發一個應用的總復雜度是恒定的，只能轉移而不可能憑空消失。要想讓開發者做的更少，安心享受簡單的快樂，那么平臺方就得做的更多，默默承擔盡可能多的復雜度。就像一個滿身腱子肉的雜技男演員，四平八穩地托舉著在高處旋轉與跳躍的女搭檔；上面的人顯得越輕盈越毫不費力，下面的人就得越穩重越用盡全力。當然，不是說上面的女演員就很輕松沒壓力，只是他們各自的分工不同，所承擔的復雜度也不一樣。

根據《人月神話》作者Fred Brooks的劃分，軟件開發的復雜度可以劃分為本質復雜度（Essential complexity ）和偶然復雜度（Accidental complexity）。前者是解決問題時固有的最小復雜度，跟你用什么樣的工具、經驗是否豐富、架構好不好等都無關，而后者就是除此之外在實際開發過程中引入的復雜度。通常來說，本質復雜度與業務要解決的特定問題域強相關，因此這里我把它稱為更好理解的“業務復雜度”；這部分復雜度不是任何開發方法或工具能解決的，包括低代碼。而偶然復雜度一般與開發階段的技術細節強相關，因此我也相應把它稱為“技術復雜度”；而這一部分復雜度，恰好就是低代碼所擅長且適合解決的。

為開發者盡可能屏蔽底層技術細節、減少不必要的技術復雜度，并支撐其更好地應對業務復雜度（滿足靈活通用的業務場景需求），這是身為一個低代碼開發平臺所應該盡到的核心職責。

請點擊輸入圖片描述

在盡到上述職責的同時，低代碼開發平臺作為一個面向開發者的產品，還需要致力于為開發者提供簡單直觀的極致開發體驗。這背后除了巨大的工作量，還得能在“強大”和“易用”這兩個很難兩全其美的矛盾點之間，努力找到一個符合自己產品定位與目標客戶需求的平衡點 —— 這也許是設計一個通用低代碼開發平臺所面臨的最大挑戰。

三、低代碼相關概念對比

純代碼（Pro-Code / Custom-Code）

“純代碼”可能算是我杜撰的一個詞，更常見的說法是-碼（Pro-Code）或定制代碼（Custom-Code）；但意思都一樣，就是指傳統的以代碼為中心（Code-Centric）的開發模式。之所以我選擇用“純代碼”，是因為如果用“-碼”會顯得似乎低代碼就不專業了一樣，而用“定制代碼”又容易讓人誤解成低代碼無法支持定制的自定義代碼。

當然，更準確的稱謂我認為是“高代碼”（與低代碼恰好對應，只是名字太難聽，被我嫌棄了...），因為即便是使用傳統的代碼IDE，有些開發工作也支持（甚至更適合）以非代碼方式完成，比如：iOS端開發時使用的SwiftUI界面設計器、服務端開發數據庫應用時使用的PowerDesigner建模工具。不過這部分可視化工作在傳統開發模式下只是起輔助作用，最后通常也是生成開發者可直接修改的代碼；開發者仍然是以代碼為中心來開展主要工作。

低代碼與純代碼之間的關系，其實跟視頻和文章之間很像：

低代碼就像是現代的“視頻”，大部分內容都由直觀易理解、表達能力強的圖片組成，因此更容易被大眾所接受。但與此同時，視頻也不是死板得只能有圖片，完全可以添加少量文字（如字幕、標注）來彌補圖片表達不夠精確的問題。BTW，關于“圖”和“文字”之間的辯證關系，可以進一步參考《架構制圖：工具與方法論》[1]這篇文章中的相關描述。

純代碼則更像是傳統的“文章”，雖然很久以來都一直是信息傳播的唯一媒介，但自從視頻技術誕生以及相應軟硬件基礎設施的普及以來，便逐漸開始被搶走了風頭。如今，視頻已成為大部分人獲取信息的主要渠道（從電視電影到B站抖音），而經常讀書讀文章的人卻越來越少。但不可否認的是，文章依然有它存在的意義和受眾（不然我也不會費這勁敲這么多字了），即使“市場份額”一直在被擠壓，但永遠會有它立足的空間。

請點擊輸入圖片描述

如果按上面這種類比關系推導，低代碼未來也會遵循與視頻類似的發展軌跡，超越純代碼成為主流開發模式。Gartner的預測也表達了相同的觀點：到2024年，所有應用程序開發活動當中的65%將通過低代碼的方式完成，同時75%的大型企業將使用至少四種低代碼開發工具進行應用開發。

但同樣地，就像是視頻永遠無法取代文章一樣，低代碼也永遠無法徹底取代純代碼開發方式。未來低代碼和純代碼方式將以互補的形態長期共存，各自在其所適合的業務場景中發光發熱。在后面的“低代碼業務場景”章節，會詳細列出哪些場景在現階段更適合用低代碼模式開發。

零代碼（Zero-Code / No-Code）

從分類的完備性角度來看，有“純代碼”自然也應該有完全相反的“零代碼”（也稱為“無代碼”）。零代碼就是完全不需要寫代碼的應用開發平臺，但這并不代表零代碼就比低代碼更高級和先進，它只是做了一個更極端的選擇而已：徹底擁抱簡單的圖形可視化，完全消滅復雜的文本代碼。選擇背后的原因是，零代碼開發平臺期望能盡可能降低應用開發門檻，讓人人都能成為開發者（注意：開發 ≠ 寫代碼），包括完全不懂代碼的業務分析師、用戶運營，甚至是產品經理（不懂裝懂可不算懂）。

即便是專業開發者，在技術分工越來越精細的趨勢下（前端/后端/算法/SRE/數據分析..），也很難招到一個能獨立開發和維護整套復雜應用的全棧工程師。但零代碼可以改變這一切：無論是Java和JavaScript傻傻分不清楚的技術小白，還是精通深度學習但沒時間學習Web開發的算法大牛，都可以通過零代碼實現自己的技術夢或全棧夢?！案淖兪澜绲膇dea已有，就差一個程序員了”，這句玩笑話或許真的可以成真；哦不，甚至都用不著程序員，有idea的人自己就能上。

請點擊輸入圖片描述

當然，所有選擇都要付出代價，零代碼也不例外。完全拋棄代碼的代價，就是平臺能力與靈活性受限：

? 一方面，可視化編輯器的表達能力遠不及圖靈完備的通用編程語言，不引入代碼根本沒法實現靈活的定制與擴展（當然，理論上也可以做成Scrach/Blockly那樣的圖形編程語言，但那樣不過是換一種形式在手寫代碼而已）。

? 另一方面，由于目標受眾是非專業開發人員，平臺能支持的操作會更趨于“傻瓜化”（e.g. 頁面只支持大塊業務組件的簡單堆疊，不支持細粒度原子組件和靈活的CSS布局定義），同時也只會透出相對“親民化”的模型和概念（e.g. 使用“表格”表示數據，而不是用“數據庫”），無法支撐強大專業的底層開發原語和編程理念。

請點擊輸入圖片描述

雖然零代碼與狹義上的低代碼有著上述明顯差異，但從廣義上來說，零代碼可以當作低代碼的一個子集。Gartner在其相關調研報告中，就是將“No Code”劃在了范圍更廣的低代碼應用平臺“LCAP”（Low-Code Application Platform）中。而當前市面上很多通用的低代碼開發平臺，也都兼具一定程度的零代碼能力；比如低代碼領域領頭羊Mendix，既提供了簡單易用的零代碼Web IDE - Mendix Studio，也包括一個功能更強大的低代碼桌面IDE - Mendix Studio Pro。

HpaPaaS（高生產力應用PaaS）

上文提到，“Low-Code”一詞是拜Forrester所賜。作為同樣是國際知名調研機構（a.k.a 造詞小能手）的Gartner，顯然不會輕易在這場可能決定低代碼領域江湖地位的新概念作詞大賽中認輸，于是也于2017年發明了“HpaPaaS”（High-productivity application Platform as a Service）這個聽上去更高大上的縮寫詞。

按照Gartner的定義，HpaPaaS是一種支持聲明式、模型驅動設計和一鍵部署的平臺，提供了云上的快速應用開發（RAD）、部署和運行特性；這顯然與低代碼的定義如出一轍。但事實證明，名字起得太專業并不見得是好事，“HpaPaas”最終還是敗給了起源更早、更接地氣也更順口的“Low-Code”：從2019年開始，Gartner在其相關調研報告中也開始全面采用“Low-Code”一詞（如LCAP），親手為“HpaPaaS”打上了 @deprecated 印記。

請點擊輸入圖片描述

圖源：What’s the difference between SaaS / IaaS / PaaS / aPaaS / HpaPaaS?

值得補充的是，“HpaPaaS“這個詞也并非橫空出世，而是傳承自更早之前Gartner提出的“aPaaS”，它倆之間的關系是：HpaPaaS只是aPaaS的一個子類；除了HpaPaaS這種通過低代碼實現的高生產力應用開發平臺以外，aPaaS還包括面向純代碼的傳統應用開發平臺（High-control aPaaS，即可控度更高的純代碼開發方式）。

不值得但就想八卦一下的是，“aPaaS”這個詞也非憑空捏造，而是與云計算的興起淵源頗深。相信各位云道中人都已猜到，aPaaS與IaaS/PaaS/SaaS這些云計算遠古概念是一脈相承的：aPaaS介于PaaS和SaaS之間，相比PaaS提供的服務更偏應用，但又不像SaaS一樣提供現成的軟件服務（更詳細的說明可參考配圖來源文章）。

四、為什么需要低代碼

低代碼是什么可能并沒那么重要，畢竟在這個信息爆炸的世界，永遠不缺少新奇而又短命的事物。大部分所謂的新技術都只是曇花一現：出現了，被看到了；大部分人“哦”了一聲，已閱但表示不感興趣；小部分人驚嘆于它的奇思妙想，激動地點了個贊后，回過頭來該用什么還是什么。真正決定新技術是否能轉化為新生產力的，永遠不是技術本身有多么優秀和華麗，而是它是否真的被需要，即：為什么需要低代碼？如果用不同的主語填充上面這個問句（冷知識：這叫做“延遲主語初始化”），可以更全面地看待這個問題：

為什么「市場」需要低代碼？

在這個大爺大媽都滿嘴“互聯網+”和“數字化轉型”的時代，企業越來越需要通過應用（App）來改善企業內部的信息流轉、強化與客戶之間的觸點連接。然而，誕生還不太久的IT信息時代，也正面臨著與我國社會主義初級階段類似的供需關系矛盾：落后的軟件開發生產力跟不上人民日益增長的業務需求。

請點擊輸入圖片描述

Gartner預測，到2021年應用開發需求的市場增長將至少超過企業IT交付能力的5倍。面對如此巨大的IT缺口，如果沒有一種革命性的“新生產力”體系，很難想象僅憑現有傳統技術體系的發展延續就能徹底解決問題。而低代碼技術正是帶著這樣的使命而降臨，期望通過以下幾個方面徹底革新應用開發生產力，拯救差一點就要邁入水深火熱的IT世界：

提效降本 質量保障

雖然軟件行業一直在高速發展，新的語言、框架和工具層出不窮，但作為從業者我們不得不承認：軟件開發仍處于手工作坊階段，效率低、人力成本高、質量不可控。項目延期交付已成為行業常態，而瓶頸幾乎總是開發人員（對機器能解決的問題都不是問題）；優秀的開發人才永遠是稀缺資源，還賊貴；軟件質量缺陷始終無法收斂，線上故障頻發資損不斷。

相比而言，傳統制造業經過幾百年工業革命的發展，大部分早已擺脫了對“人”的強依賴：從原料輸入到制品輸出，中間是各種精密儀器和自動化流水線的穩定支撐，真正實現生產的標準化和規?；?。雖然信息化號稱是人類的第三次工業革命，但以軟件行業目前的狀況，遠遠還沒到達成熟的“工業化”階段。

所以，親愛的程序員朋友，當你與前端聯調了一上午接口，又與產品撕逼了一下午需求，再與自己的bug抗爭了一整晚，好不容易遁入夢鄉又被一連串報警短信吵醒時，是否有抬頭對著星空憧憬過：“I have a dream... that one day，軟件開發也能像工業制品一樣，批量流水化生產，穩定高效沒煩惱?！?事到如今，不管你有沒有意識到，這個憧憬正在慢慢變成現實。

請點擊輸入圖片描述

是的，低代碼正在將應用軟件開發過程工業化：每個低代碼開發平臺都是一個技術密集型的應用工廠，所有項目相關人員都在同一條產線內緊密協作。開發主力不再是熟知for循環一百種寫法的技術Geek，而是一群心懷想法業務sense十足的應用Maker。借助應用工廠中各種成熟的基礎設施、現成的標準零件、自動化的裝配流水線，開發者只需要專注于最核心的業務價值即可。即便是碰到非標需求，也可以隨時自己動手，用最靈活的手工定制（代碼）方式來解決各種邊角問題。

擴大應用開發勞動力

通過讓大部分開發工作可以僅通過簡單的拖拽與配置完成，低代碼（包括零代碼）顯著降低了使用者門檻，讓企業能夠充分利用前面所提到的平民開發者資源。部分純零代碼需求場景下，低代碼還能讓業務人員實現自助式（self-service）應用交付，既解決了傳統IT交付模式下的任務堆積（backlog）問題，避免稀缺的專業開發資源被大量簡單、重復性的應用開發需求所侵占，也能讓業務人員真正按自己的想法去實現應用，擺脫交由他人開發時不可避免的桎梏。

請點擊輸入圖片描述

至此，應用開發能力不再是少數專業開發者的專利和特權，且今后所需要的技能門檻與擁有成本也會越來越低，真正實現所謂的“技術民主化”（democratization of technology）。

加強開發過程的溝通協作

多方調查結果顯示，軟件項目失敗的最主要原因之一就是缺乏溝通（poor communication）。傳統開發模式下，業務、產品、設計、開發、測試與運維人員各司其職，且各有一套領域內的工具和語言，長久以來很容易形成一個個“豎井”（silos），讓跨職能的溝通變得困難而低效。這也是為什么當前熱門的敏捷開發和DevOps都在強調溝通（前者是協同Biz與Dev，而后者是協同Dev和Ops），而經典的DDD領域驅動設計也主張通過“統一語言”來減少業務與技術人員之間的溝通不一致。

請點擊輸入圖片描述

有了低代碼后，這一狀況將得到根本改善：上述各角色都可以在同一個低代碼開發平臺上緊密協作（甚至可以是同一個人），這種全新的協作模式不僅打破了職能豎井，還能通過統一的可視化語言和單一的應用表示（頁面/數據/邏輯），輕松對齊項目各方對應用形態和項目進度的理解，實現更終極的敏捷開發模式，以及在傳統DevOps基礎之上更進一步的BizDevOps[2]。

統一開發平臺下的聚合效應

低代碼嘗試將所有與應用開發相關活動都收斂到同一個平臺（one platform）上后，將會產生更多方面的聚合效應與規模收益：

??人員聚合：除了上一點所提到的各職能角色緊密協作以外，人員聚合到統一的低代碼開發平臺進行作業后，還能促進整個項目流程的標準化、規范化和統一化。

??應用聚合：一方面，新應用的架構設計、資產復用、相互調用變得更容易；另一方面，各應用的數據都天然互通，同時平臺外數據也能通過集成能力進行打通，徹底消除企業的數據孤島問題。

??生態聚合：當低代碼開發平臺聚合了足夠多的開發者和應用后，將形成一個巨大的、連接一切、有無限想象力的生態體系，徹底放飛低代碼的價值。

企業服務模式之爭

企業服務模式之爭
當前的企業服務模式是三種模式并存，分別是：On-Premise、SaaS、Mixed。
在 8 家投資機構中，有一家投資機構非純 SaaS 不投，第一次聽到這種觀點的時候有點驚訝。目前，我們 SaaS 收入占整體收入的比例不超過 20%，而大部分收入來自于私有云部署。
目前，很少聽說一線大數據分析廠商是純 SaaS 模式。基于線上數據做大數據分析的廠商往往是 SaaS 模式，目前大部分收入來自于 SaaS 模式，少部分收入來自于定制化開發服務;基于線下數據做大數據分析的廠商往往是 Mixed 模式，在目前大部分收入來自于 On-Premise 模式，少部分收入來自于 SaaS 模式和定制化開發服務。
關于基于線下數據做大數據分析的廠商的生存狀態，我做了一個簡單的調查：選擇 Mixed 模式的 Qlik 和 Tableau 因為業務快速發展，在兩三次融資之后便完成了上市，且后者上市之后的年復合增長率長期保持在 80%以上。而選擇 SaaS 模式的 Birst 和 GoodData 融資到了 E 輪還沒有完成上市，業務規模較之前者也小了很多。
為什么會這樣呢?大數據分析的原料是大數據，而大多數企業目前的私有云數據遠大于公有云數據。數據已經成為成業的核心資產，企業級架構下的安全管控也成了重中之重。另外，如果企業選擇將數據傳輸到云端 SaaS 平臺進行分析，基于現有的互聯網基礎設施條件，數據傳輸又是個巨大的問題。簡單地舉個例子：如果上傳速度是 20Mbps，假設整個過程順利的話，將 1TB 數據上傳到云端大概需要 5 天。
在這樣的條件下，大多數企業的明智選擇是：大數據在哪里，大數據分析就在哪里。因而，對于有云端大數據分析需求的客戶，Yonghong、Qlik 和 Tableau 會引導客戶使用其云端 SaaS 平臺。這種 Mixed 模式是 On-Premise 和 SaaS 模式的升級版，即同時提供 On-Premise 和 SaaS 兩種服務，再通過技術手段打通 On-Premise 和 SaaS，連接線下數據和線上數據，以最大化數據的價值。
未來，有兩種力量會持續提升云端 SaaS 平臺的收入占比：
1. 公有云數據將持續增長，10年 以后云端數據也許會超過 50%。在那時候，大數據分析廠商的云端 SaaS 平臺的收入占比將隨之升高。
2. 互聯網基礎設施條件得以大幅改善，數據傳輸效率得以大幅提升，打造基于云端的純 SaaS 平臺成為一種可能。這時候企業將第一次有機會把企業級數據倉庫構建在公有云，但那時候公有云和私有云之間的邊界已經不存在，混合云成了企業級計算的新常態。
大數據分析公司 Palantir 的模式
大數據分析軟件公司 Palantir 是硅谷最具神秘氣質的初創企業巨頭，我們對其知之甚少，只知道其數據處理軟件可用于打擊恐怖分子和抓捕金融行業的犯罪分子。Palantir 的聯合創始人包括 Peter Thiel 以及風投機構 Formation 8 合伙人 Joe Lonsdale，其早期投資方還有美國中央情報局旗下的風投公司 In-Q-Tel。
通常，購買 Palantir 軟件的費用在 500 萬美元至 1000 萬美元之間，客戶被要求預先支付 20%的經費，剩余部分在客戶滿意后再支付，據說沒有一套軟件被退回。創始人 Alex Karp 聲稱公司是 “沒有公關，沒有銷售，沒有營銷”，這一切都是為了保證產品(延伸閱讀：金融大數據分析平臺 Palantir Metropolis 介紹)。
經過十多年的發展，Palantir 成為繼 Uber、小米、Airbnb 之后，全球估值第四高的創業公司。7月 底遞交給美國證券交易委員會(SEC)的文件顯示，Palantir 已經成功融資約 4.5 億美元，估值為 200 億美元左右。
Palantir 選取的模式是 On-Premise。
On-Premise 并未阻礙 Palantir 收入的快速增長，更未阻礙 Palatir 成為硅谷最性感的大數據分析公司，受到很多一線投資機構的追捧。
另外，個人堅定地認為 Palantir 內部一定有其云端計劃，這一云端計劃不會放棄 On-Premise，而是 Mixed 模式。
人力資源服務 Workday 的模式
在 10年 左右的時間里，從事人力資源服務的 Workday 在競爭激烈的行業中取得了不小的成功。如此新穎的模式和迅速的成長，讓行業巨頭也為之側目。但是，Workday 的發展道路上并非沒有風險。隨著公司多元化的發展，以及競爭對手的增多，Workday 還未能扭轉虧損的局面。
從技術角度看，Workday 最大的不同之處在于用 Metadata 來定義數據之間的關系。Workday 并沒有采用包含大量表的關系型數據庫，其對象型數據庫只有三張表：實例、屬性和索引。你很難從這個對象型數據庫本身了解其含義。
當 Workday 的系統啟動時，作為系統核心的對象管理服務器 (OMS) 會讀取存在三個主要表中的數據和定義，根據 Metadata 所規定的關系，將業務呈現給用戶。如果要變更產品，只需要修改 Metadata 以重新定義對象之間的關系，然后再重啟應用即可。Workday 很酷，連筆者都是他的粉絲，成功上市之后，Workday 的市值長期保持在 100 億美金左右，擁有大量熱愛 Workday 的股民。
Workday 選取的模式是 SaaS。
在很多人心目中，SaaS 就像水一樣，打開水龍頭能能用。有的云計算廠商的口宣傳語都是秒級調度計算資源，或者秒級開啟 SaaS 服務。大家猜猜如果一家企業采購了 Workday 的 SaaS HR 服務之后，需要等多久就能用上?不是一秒，不是一小時，不是一天，也不是一個月，甚至不是一個季度，一般是一年以上!基于 Workday 發明的面向未來的對象型數據庫，據說配置一套 Workday 只需要對各種對象進行拖拽式操作即可，但由于企業服務的邏輯復雜性，過去 Workday 的上線周期一般在一年以上，有的 Case 甚至超過兩年。
Gartner 關于企業服務 SaaS 模式的研究報告
Gartner 關于 SaaS 模式的研究報告能讓大家更加正確地認識 SaaS 模式。Gartner VP Robert DeSisto 表示，市場上對于 SaaS 模式充斥著許多假設性想法，其中有的想法是正確的，有的想法是錯誤的。他呼吁企業要謹慎檢視 SaaS 的真實面目，因為有許多客戶基于這些錯誤的假設，便決定部署 SaaS 方案。
在這份名為 “事實檢視：五個 SaaS 最常見的假設” 報告中，Gartner 提出了五個關于 SaaS 最常見的假設，供業界作為參考：
1. 關于 SaaS 較傳統就地部署 (On-Premise) 模式成本較低，Gartner 認為，因為不需要高額的資本投資來采購軟件或建置基礎架構，選用 SaaS 模式的前兩年的確成本較低。但就第三年以后的軟件擁有總成本來看，還是 On-Premise 模式較低。其中的原因之一是因為會計原則將 On-Premise 軟件視為固定資產，可折舊攤提。
2. Gartner 亦警告說，部署 SaaS 的速度也不一定較 On-Premise 更快。雖然軟件廠商報價說 30 天是標準的建置時間，但事實上，有些軟件可能花上數個月的時間。因為隨著企業流程與整合度的復雜性增加，部署 SaaS 與 On-Premise 軟件所需的時間差異會越來越小。
3. 若假設真的會以使用量來計費，那也是錯的。Gartner 表示，在大部分的情況下，企業還是會被要求簽署固定費用的先期合約。
4. 業界同時也低估了 SaaS 的功能性。一般都認為，SaaS 無法與 On-Premise 應用程序或數據源整合。但事實上，透過批次同步化的方式，先將數據加載 SaaS 應用程序中，然后再定期更新，或使用網絡服務進行實時更新，都是可行的方法。
5. SaaS 不是只能符合簡單、基本的需求。Gartner 表示，SaaS 應用程序在 Metadata 層級是高度客制化的，可透過應用程序平臺服務 (APaas) 的方式來實現，業界也有許多實際建置的范例。不過，對于復雜、端到端企業流程的管理功能來說，SaaS 還是有其限制。
當前的 On-Premise 采購大多被會計原則視為 “固定資產”， 而 SaaS 采購大多會被會計原則視為 “服務”。這種混淆技術模式與商業模式的方式，讓企業級客戶在做選型時很難有最優選。
我覺得，越來越多的大企業將會對 On-Premise 和 SaaS 形成統一的會計原則。這意味著在不久的將來，技術模式與商業模式將徹底分開。不管是公有云部署還是私有云部署，廠商都可以采用 SaaS 收費模式計價。
模式是手段而不是目的，應回歸商業本質。如果不考慮目的，單純地討論模式沒有意義。
還有一個普遍的觀點是，只要把客戶拉上船，數據在我這里，客戶就跑不了。有的廠商通過營銷手段讓客戶簽單，有的廠商通過免費讓客戶先上船后買票，都寄希望于用 “模式” 套牢客戶。
然而，大家似乎忘了最簡單最質樸的道理：商業的本質，是創造價值。

低代碼市場發展前景如何？

什么是低代碼開發？

「低代碼」（Low-Code）是最近很火的一個概念，類似的還有「無代碼」平臺。這類工具主張通過簡單的配置，特別是圖形化的設置，就能實現業務邏輯，從而形成自動化的生產力。

這種概念的優點在于，讓業務人員無需懂得專業的編程語言，什么Java、Python、SQL之類全都不用懂，只要知道業務流程，并且會手動配置就行了。

低代碼開發前景如何？

從市場規模來看，全球低代碼市場發展迅速，不過受疫情影響截至2025年GAGR將小于41%。然而中國市場的低代碼滲透率只有5%，遠低于全球滲透率33%，主要原因在于：

1、中國市場對低代碼的認知度不夠，普及教育方面仍有待提高；

2、低代碼平臺的生態組織數量不足，仍需等待渠道代理商和專業培訓商的大量加入。

不過，雖然我國低代碼滲透率僅僅只有5%，單從投融資情況來看，頭部企業投資的加入給低代碼行業注入了新的活力。尤其是近兩年來，低代碼行業投融資情況變得格外活躍。從2020年到2022年低代碼領域至少完成了20起投融資。

總的來說，低代碼行業未來可期。

大家都真的看好低代碼開發嗎？

從2022年目前的發展情況來看，低代碼行業的發展預期和現狀依舊是大家所關注的焦點，但當實際結果小于發展期望時，行業發展就會停滯在人人觀望的狀態，這是不利于行業的整體發展的，因此需要盡快落實問題點，重燃行業希望，吸引更多人的關注和加入。

下面來看一組低代碼行業調研數據：

1、根據相關數據表明，目前國內企業對低代碼的使用意愿還是比較高的，了解過低代碼的企業有80%愿意嘗試使用。但很多企業雖使用意愿較高，但實際行動去使用的卻很少。

2、低代碼行業總體技術成熟度是過關的，但仍存在個別單項技術問題，以及均衡不同技術的實力有待提高。

3、國內低代碼領域“年均開發產品”數量是5個，綜合可為企業節省工作量35%，從這兩項數據來看，低代碼在開發數量方面還是比較可觀的，但節省的實際工作量遠小于預期。

總的來說，低代碼的概念和優勢還是比較吸引企業的，但因為低代碼的發展目前還處于早期，普及和教育客戶方面仍有很大空間，如果低代碼廠商不教會客戶如何使用低代碼搭建應用，讓客戶自己瞎琢磨，在這個過程中必然會流失大量客戶。

低代碼究竟是什么

下面，我將從“低代碼是什么、起源、分類、能力、受眾人群、具體功能場景、市場趨勢、選型標準”等8個維度來進行講解。希望能夠幫助到大家。

重點在第六條?。?！感興趣的可直接點導航目錄查看。

一、什么是低代碼（Low Code）？

低代碼（Low Code）是一種可視化的應用開發方法，用較少的代碼、以較快的速度來交付應用程序，將程序員不想開發的代碼做到自動化，稱之為低代碼。

低代碼（Low Code）是一組數字技術工具平臺，基于自主配置的方式，實現快速構建、數據編排、連接生態、中臺服務。

從另外一個層面講，它也是一種軟件開發工具，可以減少手工編碼的過程，盡可能快的交付應用程序。當然，工具之間也會有所不同，與傳統代碼集成開發環境不同的是，低代碼開發平臺提供的是更高維和易用的可視化的集成開發環境。大多數情況下，開發者并不需要使用傳統的手寫代碼方式進行編程，而是可以通過圖形化拖拽、參數配置等更高效的方式完成開發工作。助力企業實現數字化轉型中的場景應用創新。

二、低代碼起源？

怎么說呢，其實早在很久之前，低代碼的概念就已經出現了，只不過它以前一直處于不溫不火的狀態。直到近兩年，大量IT巨頭和資本的加入，才引起了越來越多的人關注。

這個故事，還得從上世紀八十年代說起。1980年，IBM的快速應用程序開發工具（RAD）被冠以新的名稱——低代碼，由此，低代碼的概念首次面向大眾。低代碼是英文“Low Code”的翻譯，它意指一種快速開發的方式，使用最少的代碼、以最快的速度來交付應用程序。

具體可以看下低代碼起源歷程：

1、1980年：“第四代編程語言”

2、2000年：VPL（Visual Programming Language可視化編程語言）

3、2014年：Forrester提出低代碼/零代碼概念

4、2016年：國內獨立的低代碼平臺開始相繼發布

5、2018年：Gartner提出aPaaS和iPaaS的概念

6、2021年：中國市場逐漸形成完整的低代碼生態體系

三、低代碼分類

低代碼技術路徑的角度來區分，通常可分為：

1、表單驅動：

核心圍繞表單數據，通過系統中的業務流程來驅動表單，進而對業務表單數據進行分析和設計。數據層次關系簡單，類似于傳統的BPM軟件，應用場景相對有限，更適合輕量級應用。

2、表格驅動：

理論基礎上是圍繞著表格或關系數據庫的二維數據，通過工作流配合表格完成業務流轉，是一種面向業務人員的開發模式，大多面向類似Excel表格界面的企業信息應用程序。

3、數據模型：

核心圍繞業務數據定義，包括數據名稱、數據類型等，抽象表單展示與呈現業務流程，在實踐層面通過數據模型建立業務關系，通過表單、流程支持完善的業務模式靈活性高，能夠滿足企業復雜場景開發需求和整體系統開發的需求，適合中大型企業的核心業務創新場景進行個性化定制。

4、領域模型：

核心圍繞業務架構對軟件系統所涉及到的業務領域進行領域建模，從領域知識中提取和劃分不同子領域（核心子域，通用子域，支撐子域），并對子領域構建模型，再分解領域中的業務實體、屬性、特征、功能等，并將這些實體抽象成系統中的對象，建立對象與對象之間的層次結構和業務流程，最終在軟件系統中解決業務問題。

四、低代碼能力

低代碼的底層邏輯還是一個開發平臺，需要對個性化的需求開放實現途徑。

1、場景構建能力：

通過圖形可視化，拖拉拽方式就能快速構建運營管理所需的應用場景，敏捷響應需求變更的快速迭代，做到調研即開發，開發即部署。

2、數據編排能力：

通過可視化的業務規則編排，重新盤活散落在企業煙囪式系統中的數據，提供面向前端各類業務場景需要的數據服務和業務服務。

3、連接生態能力：

通過平臺的集成能力即可輕松連接企業上下游的組織與系統，擴大企業的業務鏈服務邊界，積累更多的數據資產，通過數據來反哺業務，實現更為精細化的業務場景運營；

4、業務中臺能力：

以數字化形式快速構建面向服務中心所需的各類創新微應用，將企業核心運營場景實現業務在線化。

五、誰需要低代碼？

1、市場需要

應用開發需求的市場增長與企業IT交付能力的差距，需要通過低代碼技術革新IT生產力體系，在確保質量的前提下，通過最新的低代碼技術實現提效降本。

2、專業開發者需要

低代碼重塑系統交付模式，低代碼技術抽象并封裝了許多軟件開發所需的編程知識。開發人員可以通過可視化拖拽與參數化配置實現快速開發，從可重用組件化、插件化、模板化的資產中進行選擇，而不必編寫單獨的代碼行，最大化應用資產復用，從而提高整體交付效率，能夠讓專業開發者更加專注于更具有價值和創新型的工作。

3、數字化轉型需要

隨著數字化浪潮的推進，企業商業模式創新促使企業從管理轉向運營、部門管理轉向場景化運營，商業生態重構讓未來企業運營模式也會更加關注從生產轉向服務，從分銷轉向用戶，突破企業管理邊界與上下游連通。企業需要新的數字技術工具把企業組織、管理、經營等行為由線下搬到線上，實現企業運營管理的業務在線。低代碼配置靈活和復用性高的特點，更貼合企業數字化轉型所需的快速開發和敏捷迭代的業務創新。

六、低代碼的功能場景（可實現的場景很多，這里先簡單例舉幾個）

1、OA協同辦公場景

低代碼平臺可以一站式搭建：車輛管理系統、食堂訂餐系統、員工入離職、辦公用品管理、資產管理、會議室預定、合同審批、費用申請報銷、員工績效考核、訪客管理、防疫調查、員工培訓、用章管理等等等等。

亮點：對接現有OA、ERP、CRM、MES等系統

具體場景如：車輛信息管理

車輛信息可以用來登記維護公司車輛信息數據，具體可以記錄每輛車的車牌號碼、車輛名稱、綁定駕駛員、車輛使用狀態等信息。

2、生產制造領域

低代碼平臺可以一站式搭建：生產訂單管理、工廠管理、銷售管理、人事管理、財務管理、采購管理、供應鏈管理、BOM管理、倉庫管理、出入庫管理、供應商管理、安全巡檢、設備管理系統、物資申請等等等等。

亮點：支持對接硬件、PLC、傳感器、掃碼槍等。

具體場景如：生產訂單管理

生產訂單管理系統可對生產訂單從下單、質檢、入庫和發貨全流程進行管控，根據入庫和出貨記錄自動統計產品庫存數量，可通過項目經理工作臺快速進行訂單審批和發貨審批，同時支持查看各訂單的進度及詳情。

3、項目協同領域

低代碼平臺可以一站式搭建：工程項目、科研項目、軟件研發、項目看板、甘特圖、立項、成本、質量、工作任務、招投標、人事管理、客戶管理、銷售管理、費用管控、wiki文件知識庫、項目設備物資等等等等。

亮點：支持對接企業微信、公眾號、釘釘、郵箱等。

具體場景如：項目任務管理

項目任務可分別設置責任人，責任人可以進行分解、分配、接受、拒絕等各項項目計劃的細化工作。項目經理根據實際工作下達任務，指定任務負責人，要求完成時間等。責任人可以繼續分解細化工作，分級顯示，可清楚看到父級任務和子級任務，接收人接收任務，完成后與下達人確認任務是否完成，最終統計完成率和各項匯總報表。

4、銷售業務管理

低代碼平臺可以一站式搭建：產品管理、運營管理、績效管理、人事管理、財務管理、生產管理、進銷存管理、物流管理、銷售訂單管理、門店業績上報、美容門店管理、會員充值消費、客戶滿意度調查、客戶拜訪與跟進、銷售管理系統等等等等。

亮點：支持對接企業微信、公眾號、釘釘、郵箱等。

具體場景如：銷售訂單管理

銷售訂單管理主要是訂單執行的管理，即對訂單的情況的記錄、跟蹤和控制，包括針對銷售合同的執行；控制訂貨價格、數量和客戶、業務員信用管理；隨時對訂單完成情況的跟蹤、控制訂單的實際執行；根據實際補貨情況實現追加執行訂單；進行比較并顯示訂單執行差異，并通過業務和分析報表進行訂單執行情況的反映。

5、新興行業領域（網紅、直播、OKR）

低代碼平臺可以一站式搭建：運營管理、主播管理、供應商管理、銷售數據管理、商品管理、直播管理、售后管理系統、網紅經紀管理、項目實施、OKR管理、維修工單管理、運營管理等等。

亮點：支持對接外部電商平臺、短視頻平臺。

具體場景如：網紅經紀管理

網紅經紀管理系統為網紅經紀公司提供圍繞“網紅主播”的銷售、直播、帶貨數據進行信息化、數據化的管理。支持多主播、多平臺管理。提供主播、商品數據看板，有助于運營團隊及時優化直播策略。

當然了，低代碼能實現的場景還有很多，有興趣的可自行體驗：

七、低代碼未來趨勢

目前低代碼的市場依舊火熱，國內外IT巨頭如：谷歌、微軟、阿里、騰訊、華為、百度、網易等企業也已陸續推出了自己的低代碼開發平臺，國內也有不少初創企業也在搶占低代碼時長，更有甚者，像以往那些保守和注重安全的行業和機構如：政府、醫療保健、采礦業銀行、保險、甚至國家安全都在轉向這方面技術。所以低代碼的趨勢依舊過強勁。

回顧之前，我們可以發現，從2017年開始，中國低代碼廠商尚處于產品研發或內部試用狀態，對外以平臺形式輸出的廠商不多，整體市場規模較低。但隨著技術的研發投入增加，以及不同行業需求的挖掘，低代碼相對傳統軟件開發的優勢逐漸被客戶認可，也因此越來越多的廠商開始加入戰局，導致2018年和2019年迎來行業爆發式增長，2年增速均在一倍以上。

而從2020年行業仍維持較高熱度，基于前兩年的快速增長及疫情影響，2020年低代碼行業市場規模為15.9億元，增速有所放緩至80.2%。

2021年中國低代碼市場達到28.5億元。

2022年中國低代碼市場規模預計達到42.6億元。

在未來五年，中國低代碼市場復合增長率為49.5%，預計在2025年將達到142.2億元。

而放眼全球市場，根據知名研究咨詢公司Gartnere預測，到2024年65%的應用開發將使用低代碼開發平臺進行、全球低碼開發平臺市場市值屆時將達到523億美元（約合3668億人民幣），作為全球信息化建設核心區域的中國，毫無疑問會迎來百億級甚至千億級的低代碼市場！

八、低代碼選型標準

話說，國內外低代碼平臺少說也有100+了，在眾多平臺中，他們各有優劣勢，定位也不盡相同，大家更重要的還是得根據自身需求來進行選擇。

建議的話，大家花一些時間精力，對市面上的低代碼平臺進行：多體驗，多溝通，多對比。? 除此之外，還建議大家從以下幾個方面入手：

（1）平臺架構先進性，一定要基于云原生，支持PaaS和SaaS化；

（2）平臺要輕量化，云上的應用越輕量越好；

（3）平臺功能完善，擴展性要高，不能封裝太死；

（4）客戶上手門檻要低，最好基于主流技術，基于互聯網就可以自學的那種；

（5）零代碼不能支持復雜應用，一定要有低代碼開發能力；

（6）最好支持軟硬件環境，這個未來是主流；

（7）基于平臺開發的應用不能有煙囪式，即要支持“1個平臺+N個應用”的架構模式；

（8）后端最好是java，而且要前后端分離，前端要采用vue、react等主流技術；

（9）要支持多種云平臺適配，不單單是SpringCloud，還有華為云、阿里云等商業云平臺也可適配，不能跟云底座技術耦合。

（10）必須是服務化架構，支持多種移動端、釘釘、企業微信等第三方移動化應用。

結語：

合理并且有效地運用低代碼，不僅可以讓我們工作高效地運行，還能最大程度保證團隊目標的達成。織信低代碼內置100+標準應用模板，覆蓋：OA辦公、進銷存、CRM客戶管理、MES生產管理、人事績效財務、企業服務、個人及組織等多個應用場景。還擁有在線搭建配置功能（上千種功能配置項）可根據企業需求實現自主配置。是幫助企業開啟數字化轉型的重要引擎。

關于apaas市值和APA股價的介紹到此就結束了，不知道你從中找到你需要的信息了嗎 ？如果你還想了解更多這方面的信息，記得收藏關注本站。 apaas市值的介紹就聊到這里吧，感謝你花時間閱讀本站內容，更多關于APA股價、apaas市值的信息別忘了在本站進行查找喔。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。