問：購買ERP需要實施服務嗎？

回答：需要

問：購買Visual Studio需要實施服務嗎？

回答：不需要實施，但需要支持服務

問：購買低代碼平臺需要實施服務嗎？

回答：[黑線]

作者與不少企業(yè)CIO溝通過，他們往往在決定選購低代碼平臺的時候，非?？粗氐痛a廠商的實施團隊，甚至會要求本地而且原廠的實施團隊提供服務。要解答這個現(xiàn)象，要從兩個維度來拆解：

1、低代碼平臺自身的能力和定位。

2、甲方如何定位低代碼平臺。

一、低代碼平臺的定位

看到這標題，很多低代碼行業(yè)從業(yè)者都會脫口而出“aPaaS”、“中臺”、“數字化轉型”等等。這類概念輸出我們先拋開不談，作者認為低代碼按照其使用方式來分類，只有三類：

（1）加速開發(fā)的可視化IDE：這類低代碼平臺，對開發(fā)人員吸引力強，而且所能夠應用的復雜度高，代表廠商是Outsystems、Mendix（國內的很多廠商已經在Copy ing）。這類平臺私有化、SaaS模式均支持，可以實現(xiàn)專業(yè)開發(fā)團隊分工，內置的建模工具、界面設計、邏輯構建、部署工具、運維后臺均提供獨立的用戶界面，并具有斷點調試、版本管理、插件擴展等特性。

（2）快速建模的搭建工具：這里作者沒有寫平臺，而寫的是工具，這類低代碼平臺能夠快速地搭建表單、流程，并配有集成工具，但是由于其平臺自身局限性，無法構建復雜應用。對于甲方也確實能夠解決個性化的業(yè)務問題，并且在其框架流程內，應用搭建速度提升飛快。此類工具廠商會不斷地迭代增加其工具屬性，例如添加API組件。這類工具，經常以saas的形式對外售賣輸出，其特點是具有邏輯能力的非專業(yè)開發(fā)在也可以構建出不錯的應用出來。

*作者觀點：這類工具才是中國廠商的主戰(zhàn)場，因為我們更擅長“用戶體驗”以及模式創(chuàng)新，而對于專業(yè)開發(fā)工具的構建則底蘊不足。但，仍希望國產廠商努力加油，做出中國自己的開發(fā)工具出來。

（3）方便應用開發(fā)的腳手架：為什么說有些“低代碼平臺”只是腳手架？這類平臺往往具有快速進行表單、流程等模塊的快速構建能力，但是由于其往往對企業(yè)進行私有化輸出，所以往往會開放全部或者至少是用于二次開發(fā)的代碼，企業(yè)基于該腳手架，可以開發(fā)出更多的場景。但是，由于其二次開發(fā)特性，開發(fā)者往往不能遵循最佳時間進行應用服務構建，并且必然會面對平臺持續(xù)性升級的問題，特別是前端，由于前端工程性問題，無法實現(xiàn)類似于后端的插件式擴展構建。此類低代碼平臺，在無數次的迭代過程中，逐漸淪為腳手架或者是一個框架。

看到了嗎？不同類型的代碼，適用的人群和門檻完全不同。

二、甲方對低代碼平臺的定位

甲方該如何定位低代碼平臺呢，其實看到了低代碼的分類后，也就知道了甲方會如何購買（這里我們拋開預算不談）以及使用低代碼平臺。甲方應該根據實際的需要，實際的情況決定，到底應該購買哪一類低代碼平臺。

但實際上，作者在實際工作中也發(fā)現(xiàn)了眾多甲方甚至是乙方自身對于低代碼平臺理解的誤區(qū)：

（1）低代碼平臺既可以讓不懂代碼的人使用，也可以供專業(yè)開發(fā)者來進行復雜應用構建：這里作者冒昧地武斷一句，這種想法非常不切實際而且也不正確。供專業(yè)開發(fā)人員使用的低代碼平臺只有可能把其中的某幾個模塊暴露出來供非專業(yè)開發(fā)人員使用，比如UI界面設計，可以讓UI/UE來拖拽使用。如果一個低代碼平臺主打簡單、易用，那么其自身的開放性和擴展性是有很大限制的。

（2）低代碼平臺會讓開發(fā)人員失業(yè)：這個想法非常普遍，但實際上要辯證地來看這個問題，如果一個開發(fā)人員可以被低代碼平臺替換掉，其實更應該自省自己是不是每天都在重復的做CRUD。

（3）低代碼平臺可以做中臺、實現(xiàn)數字化轉型：低代碼平臺只是工具，要想轉型，要想優(yōu)化業(yè)務還是要靠人的腦子，靠咨詢公司。

再回到問題中來，低代碼平臺需要實施服務嗎？顯而易見，如果購買的是專業(yè)級別的IDE，那么你更應該考慮的是技術支持服務。對于其他的業(yè)務需求，或者是想要引入上述第二三種低代碼平臺，實施服務就看自己公司的實際需求吧。