點(diǎn)擊上圖，查看往期優(yōu)秀營(yíng)銷數(shù)字化案例

來(lái)源：湘江數(shù)評(píng) ID：xiangjiangshupingLY 作者：老楊

···編者按···

數(shù)字化轉(zhuǎn)型的本質(zhì)是一場(chǎng)管理革命，而非單純的技術(shù)升級(jí)。當(dāng)?shù)痛a從"萬(wàn)能解藥"的神壇跌落，暴露出的不僅是技術(shù)工具的局限性，更是企業(yè)戰(zhàn)略思維的深層困境。

本文揭示的三大矛盾極具警示意義：技術(shù)廠商過(guò)度承諾與落地能力的鴻溝、業(yè)務(wù)部門技術(shù)依賴與數(shù)字化部門話語(yǔ)權(quán)的博弈、局部效率提升與全局系統(tǒng)孤島的悖論，本質(zhì)上折射出數(shù)字化轉(zhuǎn)型中的認(rèn)知迷局。許多企業(yè)將數(shù)字化等同于工具堆砌，卻忽視了組織架構(gòu)重塑、流程再造與文化轉(zhuǎn)型的同步推進(jìn)。就像文章指出的，CIO的戰(zhàn)略定位至關(guān)重要——既不能淪為技術(shù)采購(gòu)經(jīng)理，也不能異化為業(yè)務(wù)部門的傳聲筒，而應(yīng)成為數(shù)字化轉(zhuǎn)型的頂層設(shè)計(jì)師。

在"小步快跑"與"系統(tǒng)重構(gòu)"的策略選擇中，企業(yè)更需要把握好節(jié)奏。與其盲目追求平臺(tái)化、智能化的宏大敘事，不如回歸業(yè)務(wù)本質(zhì)，從解決核心痛點(diǎn)切入，在實(shí)踐中構(gòu)建動(dòng)態(tài)演進(jìn)的數(shù)字化能力矩陣。畢竟，數(shù)字化轉(zhuǎn)型的終極目標(biāo)不是打造完美的系統(tǒng)，而是培育持續(xù)適應(yīng)市場(chǎng)變化的組織韌性。這或許正是作者反復(fù)強(qiáng)調(diào)的：技術(shù)從未背叛我們，真正需要警惕的是用昨天的思維管理明天的變革。

···正文···

近日某粉絲朋友看到老楊發(fā)布的關(guān)于如何用好低代碼的視頻后，特意就軟件系統(tǒng)的應(yīng)用落地問(wèn)題與老楊微信語(yǔ)音聊了很久，也談了很多的應(yīng)用案例，發(fā)現(xiàn)一個(gè)共性問(wèn)題：很多企業(yè)把系統(tǒng)用不好要么歸咎于軟件 “不好用”，要么就說(shuō)軟件公司實(shí)施能力不足，或者干脆甩鍋給信息部門，企業(yè)極少反思自身的管理問(wèn)題。那么為什么企業(yè)數(shù)字化轉(zhuǎn)型建設(shè)做了這么多年，市面上鮮有成功且可復(fù)制的案例？老楊認(rèn)為這是一個(gè)復(fù)雜的系統(tǒng)工程，有必要深度剖析一下，那么今天就以低代碼系統(tǒng)的落地為例，深入剖析其中的關(guān)鍵癥結(jié)。

低代碼系統(tǒng)為什么用不好？

第一，低代碼系統(tǒng)本身的問(wèn)題

那么這些問(wèn)題就包括低代碼本身的技術(shù)問(wèn)題、功能問(wèn)題、適配問(wèn)題、實(shí)施能力問(wèn)題、服務(wù)問(wèn)題等。

與其他新興技術(shù)一樣，低代碼技術(shù)在發(fā)展初期也存在諸多不成熟之處，但這并不妨礙在輿論宣傳上將其描繪成萬(wàn)能良藥，用看似完美的PPT方案來(lái)掩蓋其技術(shù)缺陷與適用邊界。當(dāng)然這都是以犧牲用戶體驗(yàn)為代價(jià)的，同時(shí)也加劇了用戶對(duì)低代碼技術(shù)的不信任感。雖然隨著技術(shù)的發(fā)展，低代碼平臺(tái)的穩(wěn)定性與擴(kuò)展性已逐步提升，但其局限性依然存在，尤其在復(fù)雜業(yè)務(wù)場(chǎng)景下難以靈活適配。低代碼雖然一直在方案演示中向企業(yè)客戶強(qiáng)調(diào)其“拖拉拽”即可構(gòu)建應(yīng)用的便捷性，但實(shí)際落地時(shí)卻忽視了客戶的需求復(fù)雜性，這就需要大量定制開發(fā)來(lái)彌補(bǔ)功能短板，但問(wèn)題恰恰就在于企業(yè)用戶數(shù)字化能力低，大部分企業(yè)都無(wú)軟件開發(fā)人員難以獨(dú)立完成個(gè)性化功能開發(fā)與維護(hù)；即使有技術(shù)實(shí)力的公司，一些低代碼平臺(tái)的技術(shù)封閉性也導(dǎo)致企業(yè)難以憑自身技術(shù)能力突破平臺(tái)限制，最終仍需依賴原廠技術(shù)支撐，雖然軟件公司雖然可以提供技術(shù)支持，但較高的服務(wù)成本與響應(yīng)延遲又讓企業(yè)望而卻步，最終讓企業(yè)覺得被技術(shù)綁架，失去了自主可控的主動(dòng)權(quán)。企業(yè)原本希望通過(guò)低代碼實(shí)現(xiàn)敏捷響應(yīng)業(yè)務(wù)變化，結(jié)果卻陷入新的技術(shù)依賴?yán)Ь�，系統(tǒng)越用越僵化，需求響應(yīng)反而更慢。這種“看似提效實(shí)則添堵”的落差，進(jìn)一步加劇了管理層對(duì)數(shù)字化投入的懷疑與動(dòng)搖，最終導(dǎo)致項(xiàng)目停滯或廢棄，形成惡性循環(huán)。

所以從以上我們不難看出，低代碼本身的技術(shù)問(wèn)題不解決，其“敏捷交付”的承諾便成空中樓閣。售前商務(wù)不負(fù)責(zé)任的夸大宣傳與實(shí)施落地間的巨大落差，使得企業(yè)在項(xiàng)目啟動(dòng)后才逐步意識(shí)到技術(shù)邊界與能力缺口，此時(shí)沉沒(méi)成本已高，進(jìn)退兩難。這種“畫餅式”營(yíng)銷透支了企業(yè)客戶對(duì)低代碼平臺(tái)的信任，也讓后期的市場(chǎng)拓展愈發(fā)艱難。

第二，企業(yè)本身的管理問(wèn)題

企業(yè)本身的管理問(wèn)題同樣不容忽視。這些問(wèn)題包括認(rèn)知問(wèn)題、規(guī)劃問(wèn)題、推進(jìn)策略問(wèn)題、運(yùn)營(yíng)管理問(wèn)題等。

為什么一些技術(shù)實(shí)力強(qiáng)的企業(yè)引進(jìn)了低代碼平臺(tái)后仍難以見效？根源還是在于內(nèi)部的管理機(jī)制問(wèn)題，比如一些企業(yè)引進(jìn)低代碼平臺(tái)，原意為提升業(yè)務(wù)部門的技術(shù)融合能力，提升需求實(shí)現(xiàn)響應(yīng)的敏捷度，但實(shí)際上引入后業(yè)務(wù)部門卻以“技術(shù)太復(fù)雜”為由拒絕使用，反而還是依賴于信息部門的支持來(lái)提需求、改系統(tǒng)，導(dǎo)致低代碼平臺(tái)淪為信息部門的專屬工具，業(yè)務(wù)與技術(shù)之間的協(xié)同壁壘依然存在。還比如一些企業(yè)引入低代碼平臺(tái)的初衷是為了彌補(bǔ)原生開發(fā)的短板，加快業(yè)務(wù)需求的實(shí)現(xiàn)響應(yīng)速度，但問(wèn)題就在于軟件開發(fā)人員卻因擔(dān)心低代碼會(huì)削弱自身技術(shù)話語(yǔ)權(quán)而抵觸，甚至暗中抵制低代碼平臺(tái)的推廣，導(dǎo)致原生與低代碼兩種技術(shù)形成對(duì)立，不僅未能實(shí)現(xiàn)互補(bǔ)協(xié)同，反而造成資源內(nèi)耗。

這樣做的后果就是造成企業(yè)內(nèi)部技術(shù)路線的分裂與資源浪費(fèi)，低代碼平臺(tái)無(wú)法發(fā)揮應(yīng)有的敏捷優(yōu)勢(shì)，反而加劇了部門間的摩擦與不信任。原本應(yīng)作為提效工具的平臺(tái)，最后變成了內(nèi)部權(quán)力博弈的焦點(diǎn)，導(dǎo)致項(xiàng)目推進(jìn)緩慢、成本攀升。

第三，企業(yè)數(shù)字化推進(jìn)策略的問(wèn)題

企業(yè)數(shù)字化在不同的發(fā)展階段其推進(jìn)策略是不同的，在數(shù)字化建設(shè)初期由于業(yè)務(wù)需求較為集中且系統(tǒng)架構(gòu)相對(duì)簡(jiǎn)單，企業(yè)往往能通過(guò)局部試點(diǎn)快速見效，此時(shí)低代碼平臺(tái)的應(yīng)用可有效支撐敏捷迭代。但隨著數(shù)字化建設(shè)的深入，業(yè)務(wù)場(chǎng)景日益復(fù)雜，系統(tǒng)間集成需求激增，若仍局限于單點(diǎn)應(yīng)用思維，低代碼平臺(tái)便會(huì)因缺乏統(tǒng)一規(guī)劃而陷入“碎片化”困局。同時(shí)如果管控不到位，各業(yè)務(wù)部門各自為戰(zhàn)，最后的結(jié)果就是開發(fā)出大量孤島式應(yīng)用，反而會(huì)加劇系統(tǒng)集成難度，推高運(yùn)維成本，最終制約整體數(shù)字化轉(zhuǎn)型進(jìn)程。而一些企業(yè)數(shù)字化建設(shè)已經(jīng)歷經(jīng)多年，在內(nèi)部系統(tǒng)與數(shù)據(jù)孤島林立的情況下妄圖用低代碼平臺(tái)強(qiáng)行打通，卻忽視了底層數(shù)據(jù)治理與流程重構(gòu)的重要性，結(jié)果只能是治標(biāo)不治本，低代碼平臺(tái)會(huì)因此背了黑鍋。

因此企業(yè)引進(jìn)低代碼或者其他軟件系統(tǒng)還是應(yīng)以系統(tǒng)性思維統(tǒng)籌規(guī)劃，結(jié)合組織架構(gòu)、業(yè)務(wù)流程與技術(shù)體系協(xié)同推進(jìn)。這一過(guò)程中企業(yè)CIO的推進(jìn)策略尤為重要，需明確低代碼平臺(tái)在企業(yè)技術(shù)生態(tài)中的定位，既要避免將其視為簡(jiǎn)單的開發(fā)工具，更要防止陷入“技術(shù)萬(wàn)能論”的誤區(qū)。

數(shù)字化推進(jìn)策略的重要性

在企業(yè)的數(shù)字化建設(shè)過(guò)程中，推進(jìn)策略是決定技術(shù)能否真正賦能業(yè)務(wù)的關(guān)鍵。為什么一些企業(yè)引進(jìn)了各種數(shù)字化系統(tǒng)反而都用的不倫不類，根源往往在于忽視了業(yè)務(wù)本質(zhì)需求而盲目追求技術(shù)先進(jìn)性與項(xiàng)目規(guī)模，企業(yè)領(lǐng)導(dǎo)認(rèn)為既然做數(shù)字化一定要規(guī)模做大，最好能一次性能實(shí)現(xiàn)平臺(tái)化、數(shù)據(jù)化、智能化，而一些CIO更希望所經(jīng)手的數(shù)字化項(xiàng)目規(guī)模越大越好，以彰顯個(gè)人能力和政績(jī)。這種自上而下的“大而全”推進(jìn)策略，往往是開頭有多風(fēng)光結(jié)尾就有多慘淡，所以老楊認(rèn)為做任何數(shù)字化項(xiàng)目需要一個(gè)務(wù)實(shí)的推進(jìn)策略，從業(yè)務(wù)痛點(diǎn)找切入點(diǎn)，以小切口推動(dòng)大變革，勿貪大求全。

老楊始終認(rèn)為，應(yīng)用成熟的第三方系統(tǒng)也好，自研的軟件也罷，無(wú)非都是一種實(shí)現(xiàn)手段而非目的，關(guān)鍵還是在于如何認(rèn)知、如何應(yīng)用、如何讓其真正服務(wù)于業(yè)務(wù)產(chǎn)出價(jià)值。影響數(shù)字化系統(tǒng)產(chǎn)生價(jià)值的原因既有技術(shù)問(wèn)題、實(shí)施問(wèn)題、服務(wù)問(wèn)題，更有企業(yè)對(duì)數(shù)字化的認(rèn)知問(wèn)題、推進(jìn)策略以及運(yùn)營(yíng)管理問(wèn)題。任何問(wèn)題都是系統(tǒng)化的，不能僅靠單一技術(shù)或工具解決。不能讓技術(shù)背了管理的鍋，也不能讓無(wú)知浪費(fèi)了有限的資源。

點(diǎn)擊下方關(guān)鍵字，查看原創(chuàng)熱文

行業(yè)案例：| | | | | | |

業(yè)務(wù)場(chǎng)景：| | | | | | | | | | |

系統(tǒng)應(yīng)用：| | | | | |

數(shù)智科普：| | | |

米多是國(guó)內(nèi)領(lǐng)先的營(yíng)銷數(shù)字化整體解決方案提供商，為企業(yè)提供頂層設(shè)計(jì)（營(yíng)銷數(shù)字化藍(lán)圖/架構(gòu)/體系等）、系統(tǒng)規(guī)劃（一物一碼/智能營(yíng)銷/渠道管理）及運(yùn)營(yíng)落地（掃碼發(fā)紅包/一元換購(gòu)/五碼合一等）提供服務(wù)，用數(shù)字化驅(qū)動(dòng)業(yè)務(wù)增長(zhǎng)。