低程式碼開發服務計畫：購買者指南
低程式碼開發服務計畫是一種購買應用程式交付的結構化方式，捆綁了可視化平台、專業服務以及大約四種參與模式的持續支援：人員擴充、固定範圍專案交付、託管應用程式服務以及平台加支援合作夥伴關係。 Gartner 在 2014 年創造了「低程式碼」一詞，此後市場已分為不同的服務類別，這些服務類別在成本、控制和鎖定方面表現截然不同。
低程式碼開發服務計畫捆綁了傳統 IT 中通常單獨出售的三樣東西：可視化開發平台、基於該平台構建的專業服務以及保持最終應用程式運行的持續支援。了解捆綁銷售的買家可以獨立協商每一層——這就是贏得或失去大部分價值的地方。
平台層是工具：拖放表單建構器、資料模型設計器、工作流程引擎、API 連接器和部署管道。指定的範例包括 、OutSystems、Mendix、Appian、Retool、Budibase，以及（對於已經投資於 4D 生態系統的團隊）4D 自己的表單、方法和資料模型工具。服務層是人類的工作：發現研討會、資料建模、整合、測試和移交。支援層是上線後發生的事情：監控、變更請求、版本升級和使用者培訓。
低程式碼開發服務計劃在一個重要方面不同於一次性專案：它假設重複交付。買方不是委託單一應用程序，而是建立一個常備功能（治理模型、可重用元件庫和交付節奏），因此第二個應用程式的成本遠低於第一個應用程式。重用經濟學是「計劃」框架的全部理由。
四種服務模式的比較
低程式碼開發服務的形式適合不同的組織。下表是大多數買家在與任何供應商交談之前需要的決策協助。
| 模式 | 典型買家 | 控制 | 成本概況 | 主要風險 |
|---|---|---|---|---|
| 人員擴充 | IT 團隊存在平台技能差距 | 高－你指揮工作 | 按小時或按月收費 | 知識隨承包商離開 |
| 固定範圍項目 | 擁有一個已定義應用程式的部門 | 建置期間低 | 每個應用程式的固定價格 | 變更請求單獨計費 |
| 託管應用程式服務 | 運行即時應用程式的營運團隊 | 低到中 | 經常性預付費用 | 對新要求反應遲緩 |
| 平台+啟用合作夥伴關係 | 組織建立內部能力 | 中等，隨時間成長 | 混合：平台、培訓、建構 | 需要內部員工時間吸收 |
人員擴充適合已經擁有平台標準和積壓工作的團隊。固定範圍的專案適合具有穩定需求的單一高價值工作流程。託管服務適合受監管的環境，在這些環境中，正常運行時間和審計追蹤比速度更重要。支援合作夥伴關係適合打算建立數十個應用程式並希望內部擁有該功能的組織。
相關： — 長期運行的關係資料庫平台，適用於需要透過單一文件在桌面、Web 和行動裝置上自訂應用程式的團隊。.
一條實用規則：如果買家無法說出十八個月內擁有該應用程式的人的姓名，則該程式的購買理由是錯誤的。低程式碼開發服務程序失敗通常不是因為平台錯誤，而是因為沒有分配內部所有者。
低程式碼和無程式碼服務在實務上有何不同
低程式碼和無程式碼開發服務經常作為一類進行銷售，但這兩部分對服務參與施加了不同的約束。無程式碼工具針對的是無需編寫邏輯即可配置應用程式的業務使用者；低程式碼工具假設當視覺化建構器耗盡時，開發人員將使用程式碼擴展平台。
這種區別改變了服務合約。無程式碼參與主要是配置、培訓和治理—供應商的工作是讓公民開發人員保持在安全範圍內。低程式碼參與增加了整合工程、自訂組件、效能調整和 CI/CD 設置，因為應用程式預計涉及生產系統和規模。
我們的選擇： — 位於真實關係資料庫之上的電子表格簡單介面，具有自動化、視圖和可共享介面。.
大多數企業計劃最終都是混合型的。無程式碼層處理部門追蹤器、審批流程和資料收集。低程式碼開發服務計畫層處理寫入核心系統、執行複雜業務規則或需要審計追蹤的任何內容。僅銷售一層的供應商會將所有需求推入該層，這在範圍界定過程中值得關注。
真正的參與是什麼樣的，分階段進行
低程式碼開發服務交付遵循可識別的弧線，了解各個階段可以讓買家發現跳過昂貴階段的供應商。
**發現和資料建模。 ** 供應商對應業務流程，識別實體和關係，並決定哪些內容存在於低程式碼平台中，哪些內容保留在記錄系統中。資料建模是大多數返工的根源；基於錯誤實體模型建立的表單會被重建，而不是修補。
**原型和驗證。 ** 工作原型將在最初幾週內呈現給真實用戶。低程式碼平台使其具有成本效益，而無法快速創建可點擊原型的供應商就無法利用該平台的主要優勢。
**建置和整合。 ** 組裝畫面、工作流程、值清單和 API 連線。在任何誠實的估計中，整合通常是最大的項目，因為身份驗證、錯誤處理和資料同步從來都不像演示所暗示的那麼簡單。
**測試和強化。 ** 檢查基於角色的存取、輸入驗證、並發行為以及實際資料量下的效能。低程式碼平台隱藏了複雜性，這意味著效能問題通常會很晚才顯現出來。
**部署和移交。 ** 應用程式轉移到生產環境，最重要的是，文件、管理培訓和變更請求流程轉移到內部團隊。
**操作和迭代。 ** 低程式碼開發服務計畫繼續進行積壓、發布節奏和定期平台升級。平台供應商按照自己的時間表發布新版本，並且必須有人吸收這些變化。
真正預測成功的選擇標準
僅根據品牌認知度來評估低程式碼開發服務供應商會產生代價高昂的錯誤。以下標準是與第二年存活下來的低程式碼開發服務專案相關的標準。
- **平台退出成本。 ** 詢問如果參與結束，應用程式會發生什麼情況。資料可以以可用的格式匯出嗎？邏輯別人能讀懂嗎？專有的視覺邏輯是這個市場中最大的單一鎖定風險。
- **整合追蹤記錄。 ** 請求涉及您需要連接的同一類系統的兩個參考資料 - ERP、CRM、舊資料庫或本機目錄。
- **指定團隊，而不是能力簡報。 **詢問誰將實際完成這項工作以及這些人是員工還是分包商。
- **治理工件。 ** 一個正式的計畫會產生環境策略、存取控制模型和命名約定。將這些視為可選的供應商正在累積未來的維護債務。
- **移交承諾。 ** 合約應指定文件、管理培訓和規定的啟動後支援期限。
- **定價透明度。 ** 按應用程式、按使用者、按小時和保留定價都存在。模型並不重要，重要的是供應商是否會向您展示該數字是如何建構的。
對於平台級盡職調查，Gartner 和 Forrester 等公司發布的分析師研究是一個合理的起點，低程式碼開發平台的維基百科條目 對該類別的歷史和定義給出了中立的概述。受監管行業的買家還應根據 NIST 網路安全框架 檢查供應商的態度，許多企業採購團隊現在將其用作安全問題的通用詞彙。
低程式碼計畫在哪些地方能真正獲得回報——以及在哪些地方不能
低程式碼開發服務計劃可以為數量眾多、相似且短暫的應用程式帶來最豐厚的回報。內部申請表、審批工作流程、檢查清單、庫存追蹤器和部門儀表板都符合這種模式：每一個都很小，每一個都與其兄弟共享組件，否則每一個都會在 IT 積壓中積壓數月。
當應用程式非常複雜時，程式就會陷入困境。大容量事務系統、具有複雜並發要求的應用程式以及任何需要大量即時運算的應用程式通常更適合採用傳統開發方式，或採用低程式碼層處理介面、傳統服務處理核心邏輯的混合開發方式。
第二種失敗模式是試點計畫被遺棄。組織經常成功地進行概念驗證，然後因為沒有人為治理層提供資金而陷入停滯。試點證明該平台有效；它並不能證明該程式有效。為無聊的部分（環境管理、安全審查、培訓和支援）制定預算是將試點轉變為計劃的關鍵。
第三種模式是陰影蔓延。當公民開發人員在沒有元件庫或審查流程的情況下自由建構時，組織最終可能會擁有數百個近乎重複的應用程序，並且沒有現有應用程式的清單。服務計劃從第一天起就應包括應用程式登記冊。
建構與購買：當內部程式擊敗外部程式時
具有現有開發能力的組織有時會問他們是否需要外部低程式碼開發服務。誠實的答案取決於三個變數：計劃有多少應用程式、整合要求有多不尋常以及平台是否已經標準化。
當組織致力於一個平台、規劃多個應用程式並且可以指定至少一名經驗豐富的開發人員負責平台所有權時，內部計畫就有意義。然後，外部供應商的角色縮小到最初的支援和偶爾的專業工作。
當平台決策仍然開放時，當第一個應用程式涉及不熟悉的整合時，或者當內部員工根本無法擺脫現有的承諾時，外部計劃就有意義。在這種情況下，合約中應該寫有明確的退出坡道（內部團隊接管的點），而不是開放式保留。
基於 4D 建置的團隊通常處於中間位置。內部開發人員已經熟悉資料模型、形式和方法，因此外部服務對於整合工作、部署架構和現代化舊二進位結構最有價值。這是一個比完整計劃更窄的參與，並且應該相應地定價。
資料來源與進一步閱讀
- 低程式碼開發平台 - 維基百科：低程式碼開發平台 (LCDP) 提供軟體開發環境 - 通常是圖形使用者介面 (GUI) - 涉及很少或根本不需要編寫…
常見問題
什麼是低程式碼開發服務計畫？
低程式碼開發服務計畫是一種常設安排，供應商提供低程式碼平台和在其上建置、部署和維護應用程式的專業服務。它與單一專案不同，因為它假設重複交付、共享組件和持續的治理模型。買家通常會在人員擴充、固定範圍專案、託管服務和支援合作夥伴關係之間進行選擇。
低程式碼開發服務的費用是多少？
對於一個可靠的數字來說，定價差異太大，因為它取決於平台授權、參與模型和整合的複雜性。供應商按小時、每個應用程式、每個使用者或按月保留報價，平台許可通常與服務分開計費。最有用的比較是跨多應用程式路線圖的每個交付應用程式的總成本，而不是總體成本。
低程式碼開發適合企業應用程式嗎？
低程式碼適合數量眾多、工作流程驅動且整合度高的企業應用程式—審批系統、追蹤器、入口網站和部門工具。它不太適合大容量事務核心、即時計算和具有異常並發需求的系統。許多企業採用混合方式：介面和工作流程層使用低程式碼，核心邏輯使用常規程式碼。
低程式碼和無程式碼開發服務有什麼不同？
無程式碼服務專注於配置和治理，因此業務用戶無需編程即可安全建置。低程式碼服務增加了整合工程、自訂元件、效能調整和部署管道，因為應用程式預計會接觸生產系統。大多數企業程式都運行兩個層，將簡單的應用程式路由到無程式碼，將複雜的應用程式路由到低程式碼。
透過低程式碼服務程式交付應用程式需要多長時間？
原型通常可以在最初幾週內展示，而簡單的部門應用程式通常在幾個月而不是幾個季度內即可投入生產。當整合複雜、安全審查繁重或需求在建置過程中發生變化時，時間軸就會延長。一旦組件和治理就位，該計畫的真正速度優勢就會出現在第二個和第三個應用程式上。
低程式碼服務合約應包括哪些內容？
合約應指定指定的交付團隊、平台和授權責任、整合範圍、文件和管理培訓、定義的發布後支援期以及買方可以在內部開展工作的條款。資料導出權和自訂邏輯的可讀性應在合約中明確規定，因為它們決定了以後離開供應商的成本有多大。
常見問題
什麼是低程式碼開發服務計劃？
低程式碼開發服務計畫是一種常設安排，供應商提供低程式碼平台和在其上建置、部署和維護應用程式的專業服務。它與單一專案不同，因為它假設重複交付、共享組件和持續的治理模型。買家通常會在人員擴充、固定範圍專案、託管服務和支援合作夥伴關係之間進行選擇。
低程式碼開發服務的費用是多少？
對於一個可靠的數字來說，定價差異太大，因為它取決於平台授權、參與模型和整合的複雜性。供應商按小時、每個應用程式、每個使用者或按月保留報價，平台許可通常與服務分開計費。最有用的比較是跨多應用程式路線圖的每個交付應用程式的總成本，而不是總體成本。
低程式碼開發適合企業應用嗎？
低程式碼適合數量眾多、工作流程驅動且整合度高的企業應用程式—審批系統、追蹤器、入口網站和部門工具。它不太適合大容量事務核心、即時計算和具有異常並發需求的系統。許多企業採用混合方式：介面和工作流程層使用低程式碼，核心邏輯使用常規程式碼。
低程式碼和無程式碼開發服務有什麼區別？
無程式碼服務專注於配置和治理，因此業務用戶無需編程即可安全建置。低程式碼服務增加了整合工程、自訂元件、效能調整和部署管道，因為應用程式預計會接觸生產系統。大多數企業程式都運行兩個層，將簡單的應用程式路由到無程式碼，將複雜的應用程式路由到低程式碼。
透過低程式碼服務程式交付應用程式需要多長時間？
原型通常可以在最初幾週內展示，而簡單的部門應用程式通常在幾個月而不是幾個季度內即可投入生產。當整合複雜、安全審查繁重或需求在建置過程中發生變化時，時間軸就會延長。一旦組件和治理就位，該程式的真正速度優勢就會出現在第二個和第三個應用程式上。
低程式碼服務合約應包括哪些內容？
合約應指定指定的交付團隊、平台和許可責任、整合範圍、文件和管理培訓、定義的發布後支援期以及買方可以在內部開展工作的條款。資料導出權和自訂邏輯的可讀性值得明確的語言，因為它們決定了以後離開供應商的成本有多大。
使用您的工作帳戶免費試用 Power Apps
企業級低程式碼應用程式開發連接到 Microsoft 365、Dataverse 和 Power Automate。