大部分傳統(tǒng)企業(yè)做數(shù)字化轉(zhuǎn)型不是在踩坑就是被坑，技術(shù)坑、管理坑、組織坑、能力坑一路隨行，感覺整個轉(zhuǎn)型過程都是在踩坑的路上，如果要細(xì)說下來，估計又得是萬字長文了，今天老楊就選一個最典型、最常見的場景來說說這個大坑。

眾所周知，企業(yè)的任何數(shù)字化建設(shè)項目一定是要基于某個場景，例如最簡單的進(jìn)銷存是基于倉儲管理場景，OA系統(tǒng)是基于企業(yè)跨部門協(xié)同場景，復(fù)雜的ERP是基于企業(yè)內(nèi)部資源整合場景等，看似一些簡單的工作場景又對企業(yè)的管理提出了要求，以流程為例，線下與線上實現(xiàn)是截然不同的場景，在線下的流程審批可能摻雜更多的是人的主觀意識的判斷，即使管理多么混亂、多么的不規(guī)范也可以實現(xiàn)流程的流轉(zhuǎn)讓工作得以繼續(xù)，但大部分企業(yè)實現(xiàn)流程在線化以后工作效率沒有提升，反而不如紙質(zhì)審批，為什么？最根本的原因就是企業(yè)未能實現(xiàn)場景的轉(zhuǎn)型只是轉(zhuǎn)換，即就是流程搬家，將在線下混亂不堪的流程直接照搬至線上，同時在系統(tǒng)內(nèi)組織結(jié)構(gòu)未確定、人員權(quán)限未明確、當(dāng)然流程也未梳理的模式下所做的工作就是將混亂的場景做復(fù)制操作，引發(fā)新的混亂。所以不難看出數(shù)字化的場景轉(zhuǎn)型并不等于場景復(fù)制。

在企業(yè)數(shù)字化轉(zhuǎn)型建設(shè)過程中經(jīng)常遇到的一個場景就是：究竟是先做標(biāo)準(zhǔn)化然后再做數(shù)字化，還是先做數(shù)字化然后再做標(biāo)準(zhǔn)化？

這是一個讓企業(yè)極為矛盾的問題，其實在老楊看來并無標(biāo)準(zhǔn)與正確的答案，每個企業(yè)情況不同，管理模式不同，業(yè)務(wù)場景也不同，因此適合自己的就是最好的。

那明知無答案但為什么要問此問題？

因為在企業(yè)數(shù)字化轉(zhuǎn)型建設(shè)過程中有這樣一個現(xiàn)象：在企業(yè)業(yè)務(wù)高速發(fā)展的時刻，業(yè)務(wù)場景極其不穩(wěn)定，但企業(yè)為了達(dá)到有效的管控，會給予數(shù)字化過高的期望，讓信息部門引進(jìn)或者研發(fā)配套的業(yè)務(wù)管理系統(tǒng)，此時問題來了，信息系統(tǒng)升級迭代的速度永遠(yuǎn)趕不上業(yè)務(wù)場景變化的速度，甚至系統(tǒng)還在開發(fā)期，業(yè)務(wù)場景就發(fā)生了改變，此時的矛盾就是：是系統(tǒng)適應(yīng)業(yè)務(wù)發(fā)展，還是業(yè)務(wù)適應(yīng)系統(tǒng)！

如果系統(tǒng)適應(yīng)業(yè)務(wù)，那么就要投入大量的人力、物力、財力還緊隨業(yè)務(wù)的步伐，同時還要面臨各種風(fēng)險，因為在業(yè)務(wù)高速發(fā)展期，特別是新興業(yè)務(wù)開拓期會面臨很多的不確定性，例如：

1. 人員的不穩(wěn)定：

特別是管理人員的更替直接影響的就是管理模式、場景、思路的轉(zhuǎn)變；所以我們經(jīng)?？吹竭@樣的場景：某主管領(lǐng)導(dǎo)在職期間引進(jìn)了某套業(yè)務(wù)管理系統(tǒng)，但系統(tǒng)還未上線，該領(lǐng)導(dǎo)突然離職了，繼任的領(lǐng)導(dǎo)有可能會推翻前任的所有成果，即使系統(tǒng)多匹配業(yè)務(wù)，也會遭遇下線的命運(yùn)，如果是企業(yè)信息部門自研的系統(tǒng)，那有可能會面臨重新開發(fā)的局面,這樣信息系統(tǒng)就在反復(fù)推翻、重復(fù)建設(shè)中，也就是說：一直在建設(shè)，從未上過線，這樣自然信息部門的價值也難以體現(xiàn)，最后還有可能背了能力不足的鍋；

2. 管理場景的不穩(wěn)定：

高速發(fā)展的新業(yè)務(wù)，帶來的是各種管理場景的不完善，各種場景都是在不斷摸索與試錯中，例如各種成本核算方式、物資的采購與分?jǐn)偣芾砟Ｊ?、人員薪資的核算模式等，此時面臨的問題就是業(yè)務(wù)數(shù)據(jù)量多、人員工作量大，管理人員會不約而同的想到用數(shù)字化的管理模式，但問題來了，市面上的標(biāo)準(zhǔn)軟件產(chǎn)品可能無法滿足企業(yè)個性化的業(yè)務(wù)需求，怎么辦?此時有兩個方案就是二次開發(fā)與訂制開發(fā)。無論選哪一種模式就會面臨以下同樣的問題：
需求不明確！業(yè)務(wù)部門不知道要什么或者什么功能都想要！

需求多變！朝定夕改！

所以我們就會看到這樣的場景：

信息部門在業(yè)務(wù)需求的場景里啊 ，每天挖呀挖，改呀改，最后成功的為自己挖了坑，沒看到所謂的正確的需求方向，明確的目標(biāo)，最后信息部門每天都是在被動挨打，不是被業(yè)務(wù)部門懟，就是被領(lǐng)導(dǎo)罵。

業(yè)務(wù)場景的多變性造成了數(shù)字化需求的不確定性，這對信息部門來說是非常頭痛的一件事，但只要信息部門合理引導(dǎo)，其實大部分的風(fēng)險還是可以避免的，但最怕的就是相關(guān)業(yè)務(wù)領(lǐng)導(dǎo)的“想當(dāng)然”，只考慮自己的工作場景的同時還要求其他部門必須遵守，還強(qiáng)勢的要求其他的部門必須按自己的要求來，例如我們最常見的財務(wù)與業(yè)務(wù)場景，老楊經(jīng)看到一些CIO在群內(nèi)吐槽：財務(wù)部門不經(jīng)業(yè)務(wù)部門同意自己搞了一套系統(tǒng)，在財務(wù)模塊方面應(yīng)用的非常好，但業(yè)務(wù)部門卻叫苦不迭，因為業(yè)務(wù)管理模塊完全不符合業(yè)務(wù)管理的場景與邏輯，最后在業(yè)務(wù)部門的吐槽及反對下，該系統(tǒng)只用了財務(wù)部門所需的模塊，而其他功能模塊浪費(fèi)了，業(yè)務(wù)部門又重新采購了新的業(yè)務(wù)管理系統(tǒng)，但又未實現(xiàn)與財務(wù)系統(tǒng)的數(shù)據(jù)打通，管理孤島與數(shù)據(jù)孤島隨即產(chǎn)生，又造成大量的數(shù)據(jù)重復(fù)錄入工作。

從以上我們不難看出，在企業(yè)數(shù)字化建設(shè)過程中，缺乏協(xié)同能力，是非?？膳碌模瑸槭裁从懈鞣N管理與數(shù)據(jù)孤島，其原因還是管理者的本位主義，缺乏同理心，缺乏對數(shù)字化技術(shù)與本質(zhì)的深刻理解，在一些企業(yè)領(lǐng)導(dǎo)眼里，認(rèn)為軟件開發(fā)是一件極其簡單的事情，特別是GPT推出以后，某些企業(yè)領(lǐng)導(dǎo)甚至想干掉信息部門讓GPT來搞軟件開發(fā)，未必也太天真了。

綜上所述，老楊認(rèn)為：場景未定，技術(shù)慎行，要學(xué)會合理避坑！管理場景是隨意的，軟件代碼是固化的，想要固化的程序去追趕不斷變化的管理場景，信息部門不是被累死，就是被懟死，毫無價值可言。因此，信息部門勿為了項目而做項目，要認(rèn)真分析相關(guān)業(yè)務(wù)場景及需求，合理安排信息系統(tǒng)的引進(jìn)及研發(fā)節(jié)奏，不要業(yè)務(wù)部門一提需求就打滿雞血的狀態(tài)什么都想做，以此來體現(xiàn)自身的技術(shù)能力，其實信息部門要知道的是在多變的業(yè)務(wù)場景下，需要的是冷靜的思維及明確的目標(biāo)，找準(zhǔn)一個切入點分步推進(jìn)才是上策。信息部門既要考慮如何體現(xiàn)數(shù)字化的價值，又要考慮在多變的場景下如何實現(xiàn)業(yè)務(wù)需求，這既是技術(shù)能力的體現(xiàn)，又是管理能力的展現(xiàn)，既不能踩坑，又要學(xué)會合理避坑！

文章來源于湘江數(shù)評 ，作者老楊