簡介《企業(yè)數(shù)字化轉(zhuǎn)型的基石》是一份基于思科數(shù)字化網(wǎng)絡(luò)架構(gòu)DNA的企業(yè)IT基礎(chǔ)架構(gòu)轉(zhuǎn)型指南由思科大中華區(qū)副總裁侯勝利撰寫適合企業(yè)IT決策者、解決方案架構(gòu)師及網(wǎng)絡(luò)工程師學(xué)習(xí)。資源包僅含1個PDF文件大小3.54MB內(nèi)容精煉聚焦業(yè)務(wù)體驗、效率提升、快速擴展、運維成本與風(fēng)險控制五大維度。文檔詳細解析了DNA架構(gòu)中的網(wǎng)絡(luò)虛擬化、自動化、安全控制與業(yè)務(wù)智能學(xué)習(xí)并通過運營管理中心DNAC實現(xiàn)服務(wù)自動化同時結(jié)合通富微電子采用IWAN智能廣域網(wǎng)的成功案例展示了關(guān)鍵應(yīng)用可靠性提升100%、IT預(yù)算下降50%的實效。此外內(nèi)容延伸至工業(yè)互聯(lián)網(wǎng)互聯(lián)工廠架構(gòu)CPwE與霧計算幫助讀者建立從數(shù)據(jù)中心到邊緣的全局數(shù)字化視野。目前已有57人學(xué)習(xí)下載適合正在規(guī)劃或?qū)嵤┢髽I(yè)數(shù)字化轉(zhuǎn)型的技術(shù)團隊參考。1. 為什么你的轉(zhuǎn)型方案缺的不是技術(shù)而是一塊壓艙石《企業(yè)數(shù)字化轉(zhuǎn)型的基石》是這兩年談轉(zhuǎn)型時經(jīng)常被提到的一份參考名字里的 PDF 后綴看起來像文檔但它討論的其實是比系統(tǒng)選型更靠前的問題。一家年營收幾個億的制造企業(yè)上了 ERP、MES、BI報表卻還是靠人手工合并月底關(guān)賬照樣加班到凌晨。你第一反應(yīng)多半是系統(tǒng)沒選好其實問題不在系統(tǒng)而在系統(tǒng)下面的那塊地——數(shù)據(jù)不統(tǒng)一、流程有斷點、部門各說各話。這份參考真正想回答的是數(shù)字化轉(zhuǎn)型的地基到底是什么怎么判斷企業(yè)現(xiàn)在的土質(zhì)再一層層往下打。這篇筆記把它拆成能照著做的診斷框架和施工路線適合正要啟動轉(zhuǎn)型卻不知道第一步落在哪的決策者也適合系統(tǒng)已上線、正被數(shù)據(jù)對不齊折磨的落地團隊。2. 先把地基畫對從信息化補課到數(shù)字化重構(gòu)你的差距在哪里2.1 基石不是中臺也不是大屏用四層地基判斷企業(yè)卡在哪層太多企業(yè)一說轉(zhuǎn)型第一反應(yīng)就是建中臺、上大屏、買低代碼平臺。技術(shù)廠商也樂得給你講平臺故事。但我跟過的項目里真正讓轉(zhuǎn)型翻車的九成不是平臺選錯而是平臺下面的地基本來就是松的。中臺也好、大屏也好都是地基之上的建筑土不實樓蓋得越好看塌得越快。我把基石拆成四層從上往下看是技術(shù)從下往上打才是施工順序。最底下是數(shù)據(jù)——統(tǒng)一編碼、統(tǒng)一口徑、統(tǒng)一所有權(quán)往上是流程——從訂單到回款的端到端鏈路能不能不靠人肉接力再往上是組織——每個數(shù)據(jù)和每段流程有沒有明確的主人有沒有人愿意為結(jié)果負責(zé)最上面才是技術(shù)——系統(tǒng)、接口、報表工具。很多企業(yè)把這個順序倒過來先買技術(shù)再指望技術(shù)自動長出數(shù)據(jù)標準和組織協(xié)同結(jié)果就是花大錢買了一個更大的麻煩。想快速判斷企業(yè)卡在哪一層不用做大調(diào)研問三個問題就夠了。第一財務(wù)盤點庫存時倉庫的物料編碼和采購的供應(yīng)商編碼能不能直接對上還是要靠 Excel 轉(zhuǎn)兩遍第二一張訂單從銷售接單到財務(wù)回款合同、計劃、生產(chǎn)、發(fā)貨之間有沒有一段要靠電話和微信確認第三把銷售額毛利率準時交付率這幾個指標的定義講給新來的員工聽他能不能一遍就聽明白三個問題只要有一個是否定答案對應(yīng)的那層地基就還沒打完。我把這四層整理成了一個自查表平時給企業(yè)做診斷時也會直接用地基層次核心問題健康信號危險信號數(shù)據(jù)核心數(shù)據(jù)對象有沒有統(tǒng)一編碼和唯一 Owner月末盤點不用手工合并口徑一致同一客戶在三個系統(tǒng)里叫三個名字流程跨部門端到端流程能否自助流轉(zhuǎn)訂單異常能找到確定的責(zé)任人和升級路徑每個部門有自己的 Excel靠微信群接力組織數(shù)據(jù)和流程的權(quán)責(zé)是否寫入崗位職責(zé)新員工能按文檔接手工作數(shù)據(jù)出了問題找了一圈沒人認技術(shù)系統(tǒng)是支撐業(yè)務(wù)還是業(yè)務(wù)遷就系統(tǒng)系統(tǒng)改動有業(yè)務(wù)負責(zé)人參與評估上線后沒人用業(yè)務(wù)繞開系統(tǒng)干活注意上面說的健康信號不是滿分標準是最低可用的及格線。我的判斷標準很簡單企業(yè)能在這四個問題上給出能、通、有人認、有用的答案再談中臺和大屏才不算打水漂。2.2 對照成熟度模型給企業(yè)現(xiàn)狀打分的六個維度像《企業(yè)數(shù)字化轉(zhuǎn)型的基石》這類文檔市面上版本很多但框架收斂下來基本是一致的躲不開戰(zhàn)略、數(shù)據(jù)、流程、組織、技術(shù)、運營這六個維度。這套模型的價值不在打分本身而在于逼著企業(yè)把轉(zhuǎn)型從一個口號拆成可比較的現(xiàn)狀。沒有這把尺子各部門對我們現(xiàn)在行不行的爭論永遠停留在感覺層面。我的常見做法是找 5 到 7 個人組成臨時評估組成員必須跨部門——分管副總、IT 負責(zé)人、財務(wù)、運營、銷售各一個。每個人按六個維度獨立打 1 到 5 分然后當場匯總。1 分是完全空白5 分是內(nèi)部公認做得扎實。不需要搞復(fù)雜的加權(quán)算法把評分表擺在同一張白板上差異最大的那個維度就是你要最先補的地基。維度1 分錨點3 分錨點5 分錨點戰(zhàn)略口號式轉(zhuǎn)型無預(yù)算無負責(zé)人有年度目標但沒拆到部門目標與預(yù)算、考核綁定有止損線數(shù)據(jù)核心編碼靠 Excel 維護主數(shù)據(jù)有標準但執(zhí)行率不到 80%數(shù)據(jù) Owner 明確質(zhì)量有月度考核流程跨部門依賴電話協(xié)調(diào)核心流程線上化但仍有斷點端到端流程有監(jiān)控和升級機制組織業(yè)務(wù)認為轉(zhuǎn)型是 IT 的事有數(shù)字化專員但話語權(quán)弱業(yè)務(wù)骨干在項目里全職投入技術(shù)系統(tǒng)林立、接口靠人肉核心鏈路打通但報表靠手工系統(tǒng)支撐業(yè)務(wù)改動有評估機制運營上線即結(jié)束無復(fù)盤每月看指標但只看不動指標驅(qū)動改進有持續(xù)迭代節(jié)奏評分時要注意一種很常見的干擾IT 和業(yè)務(wù)給同一維度打分經(jīng)常差出兩三分。比如 IT 覺得數(shù)據(jù)平臺都搭好了數(shù)據(jù)基礎(chǔ)至少 4 分業(yè)務(wù)卻說銷售臺賬和管理層報表還是兩套 Excel應(yīng)該只有 1 分。兩邊都沒錯但這恰恰說明數(shù)據(jù)這個地基沒有達成共識——沒有共識的那一層就是最大的隱患。這種分歧不用急著調(diào)和把它記錄下來作為后續(xù)治理工作的啟動理由。2.3 從評估到路線圖用三階段推進別搞一刀切評估做完最怕兩件事一是報告寫完放抽屜二是老板看完決定全面鋪開。正確做法是把評估結(jié)果壓成一張三階段路線圖每個階段都能獨立產(chǎn)生業(yè)務(wù)價值不讓業(yè)務(wù)等太久。數(shù)字化轉(zhuǎn)型最忌諱憋大招一搞就是一年的全面改造業(yè)務(wù)等不起預(yù)算也撐不住。第一階段1 到 3 個月的目標是補標準。選定一個最痛的主數(shù)據(jù)對象——通常是客戶或物料——把編碼規(guī)則、字段標準、數(shù)據(jù) Owner 定下來同時清理存量數(shù)據(jù)里的臟數(shù)據(jù)。這個階段不追求跑通多少系統(tǒng)要讓業(yè)務(wù)看見月底對賬少花了兩個晚上這個感受比任何宣講都好用。第二階段3 到 6 個月的目標是通流程。挑一條跨部門的高頻鏈路把現(xiàn)狀圖、斷點、責(zé)任矩陣畫出來按目標流程改造。常見的選擇是從訂單到收款因為它的業(yè)務(wù)價值直接反映在交付周期和資金回籠上老板看得見。第三階段6 到 12 個月才是上工具、建指標、做迭代。前面兩個階段沒有站穩(wěn)第三階段的系統(tǒng)實施一定會返工反過來地基只要穩(wěn)這一階段反而最快。這個順序本身不新鮮但真正執(zhí)行時很容易被供應(yīng)商帶偏——他們恨不得你第一周就簽下平臺合同。階段核心任務(wù)成功標準典型交付物第一階段·補標準統(tǒng)一編碼與口徑指定數(shù)據(jù) Owner核心數(shù)據(jù)無需人工合并數(shù)據(jù)字典、編碼規(guī)則、存量數(shù)據(jù)清洗報告第二階段·通流程打通一條端到端流程明確權(quán)責(zé)流程斷點可追蹤例外有升級路徑現(xiàn)狀/目標流程圖、RACI 矩陣、試運行復(fù)盤第三階段·建指標上線支撐系統(tǒng)建立運營指標指標自動生成有改進動作指標字典、系統(tǒng)配置方案、月度運營報告這里要特別提醒一個反常識的地方三階段不是嚴格的瀑布。第一階段做出來的標準第二階段只在選定的流程里試用不必等全部子公司同步。常見做法是先選一個試點單元跑跑出經(jīng)驗再橫向復(fù)制。否則統(tǒng)一標準這種事在面上討論半年都收不了口試點里用數(shù)據(jù)說話反而三天就能定下來。3. 把基座落到組織里數(shù)據(jù)治理、流程標準與考核指標怎么同步改評估做完真正難的是把地基從紙面落進組織。這一章講三件事數(shù)據(jù)治理的推進順序、流程標準化的實操方法以及考核指標怎么定。這三樣必須同步動缺一個就容易翻車——只做數(shù)據(jù)不碰流程數(shù)據(jù)會失真只做流程不碰考核沒人愿意接考核定錯了前面全白干。3.1 數(shù)據(jù)治理不是建數(shù)倉先定標準、再定權(quán)責(zé)、后上工具我見過的最貴的數(shù)據(jù)治理失敗案例是花幾百萬先買了一套數(shù)據(jù)平臺然后發(fā)現(xiàn)各系統(tǒng)的數(shù)據(jù)源根本沒統(tǒng)一。銷售系統(tǒng)里的客戶叫華東某某公司財務(wù)系統(tǒng)里同一個客戶叫某某華東有限公司法人主體還掛在另一個代碼下面。平臺再厲害也分不清這三條記錄是同一個客戶。所以數(shù)據(jù)治理的施工順序永遠是先定標準、再定權(quán)責(zé)、后上工具這個順序不能反。第一步盤點核心數(shù)據(jù)對象。不要貪多一般制造企業(yè)從客戶、物料成品/半成品/原材料、供應(yīng)商、組織、人員這五類主數(shù)據(jù)入手就夠了。對每一類明確唯一編碼規(guī)則。比如物料編碼建議用大類 材質(zhì) 規(guī)格 流水號的組合。但注意編碼規(guī)則一旦發(fā)布就不要攜帶會變化的屬性——采購部門能把供應(yīng)商代碼編進物料碼但價格談判導(dǎo)致供應(yīng)商切換時物料就不得不多出一條新記錄反而制造臟數(shù)據(jù)。第二步為每個數(shù)據(jù)對象指定 Owner。Owner 必須是業(yè)務(wù)部門不是 IT。客戶數(shù)據(jù)的 Owner 通常是銷售運營物料數(shù)據(jù)的 Owner 通常是供應(yīng)鏈或研發(fā) BOM 管理部門。所有權(quán)包含兩件事定義清楚什么算一條合格的數(shù)據(jù)以及數(shù)據(jù)錯了找誰改、多久改完。這一步往往會遇到部門互相推常見做法是讓分管領(lǐng)導(dǎo)在評審會上直接點名把 Owner 寫進會議紀要別指望大家自覺認領(lǐng)。第三步再選工具。工具的選擇要服務(wù)于前兩步優(yōu)先選那些能在現(xiàn)有系統(tǒng)里無縫集成的方案而不是買一個大而全的新平臺。數(shù)據(jù)質(zhì)量規(guī)則可以先做成簡單的定時檢查腳本——每天跑一遍編碼規(guī)則校驗、必填字段校驗結(jié)果發(fā)給 Owner。數(shù)據(jù)治理不需要一開始就建設(shè)一個龐大的數(shù)據(jù)資產(chǎn)目錄先把一個對象的覆蓋率做到 95% 以上再擴展。數(shù)據(jù)對象統(tǒng)一編碼規(guī)則示例Owner首個驗收目標建議周期客戶客戶簡稱 地區(qū)碼 流水號銷售運營部CRM 與財務(wù)系統(tǒng)客戶映射率 100%6 周物料大類 材質(zhì) 規(guī)格 流水號供應(yīng)鏈/BOM 管理ERP 與 MES 物料編碼一致率 100%8 周供應(yīng)商分類 統(tǒng)一社會信用代碼后 6 位采購部采購與財務(wù)供應(yīng)商主檔一致率 95%4 周有一道心理關(guān)要過數(shù)據(jù)治理一定會把歷史爛賬翻出來不能想著一次全部清理干凈。我的做法是設(shè)豁免期——按標準核對存量數(shù)據(jù)時只標記不追責(zé)給業(yè)務(wù)三到六個月的過渡期過渡期后再產(chǎn)生新的臟數(shù)據(jù)才按流程整改。沒有這個豁免期業(yè)務(wù)部門會為了保護自己的 Excel 臺賬拒絕把真實數(shù)據(jù)吐到系統(tǒng)里項目就在最關(guān)鍵的階段啞火。3.2 流程標準化把隱性經(jīng)驗變成顯性流程流程標準化的目標不是把每個操作都釘死而是把只有老員工知道怎么辦的隱性經(jīng)驗轉(zhuǎn)變成新人照文檔也能走通的顯性流程。實現(xiàn)這條路我一般分四步走每一步都要有業(yè)務(wù)人員在場不能由顧問代筆。顧問畫出來的流程圖再漂亮也畫不出業(yè)務(wù)心里的真實路徑。第一步選一條端到端流程。最值得先做的是高頻、高價值的流程比如從訂單到收款OTC它橫跨銷售、計劃、生產(chǎn)、倉儲、財務(wù)五個部門幾乎每個環(huán)節(jié)都有斷點。第二步讓流程涉及的每個崗位派一個人花半天時間在墻上貼現(xiàn)狀圖從接單到回款每一步輸入是什么、輸出是什么、花了多長時間、中間等待了多久。你會發(fā)現(xiàn)大量時間不是花在執(zhí)行而是花在等——等合同評審、等領(lǐng)導(dǎo)簽字、等計劃員回復(fù)。第三步識別斷點并用目標流程替代。斷點通常有三種重復(fù)錄入——同一訂單在 CRM、ERP、財務(wù)系統(tǒng)各錄一遍冗余審批——一個評審讓五個部門會簽其中兩個部門從不提意見責(zé)任真空——訂單逾期了銷售說是計劃的錯計劃說是生產(chǎn)的錯沒有一個人對端到端結(jié)果負責(zé)。針對每一個斷點寫一條改進動作并用責(zé)任矩陣固定下來。斷點原因?qū)Σ哓?zé)任人訂單信息在 CRM 和 ERP 重復(fù)錄入常不一致系統(tǒng)未接口銷售與商務(wù)各管一段以 CRM 為源頭打通接口ERP 只讀訂單主檔IT 銷售運營合同評審需五個部門會簽平均耗時 3 天低風(fēng)險合同也存在冗余審批按金額與新客戶規(guī)則分流低風(fēng)險自動通過高風(fēng)險才會簽銷售管理部訂單逾期無升級機制沒有人對端到端交付周期負責(zé)設(shè)訂單交付 Owner超期按 SLA 自動升級到分管副總供應(yīng)鏈總監(jiān)第四步試運行并保留例外通道。流程標準化最容易犯的錯是矯枉過正把流程做成剛性流水線出現(xiàn)異常時業(yè)務(wù)只能先斬后奏。我一般會在目標流程里顯式定義例外規(guī)則訂單超出常規(guī)交期、非標定制、緊急插單走單獨的評審線路。例外通道不是為了制造后門是為了讓系統(tǒng)承認現(xiàn)實世界有特殊情況否則業(yè)務(wù)會自動繞開正道走野路你的流程圖就會變成一紙空文。3.3 考核指標把上線了幾個系統(tǒng)換成北極星指標數(shù)字化轉(zhuǎn)型項目考核錯了執(zhí)行就會跟著錯。最常見的錯誤考核是上線了幾個模塊、建了多少張報表、完成了多少個接口這些指標只會讓團隊追求數(shù)量不追求業(yè)務(wù)結(jié)果。在組織層面我建議只設(shè) 3 到 5 個北極星指標并且全部圍繞業(yè)務(wù)結(jié)果來定。指標名稱計算方法數(shù)據(jù)來源負責(zé)人訂單準時交付率OTD準時交付訂單數(shù) / 總訂單數(shù)ERP 發(fā)貨記錄 物流簽收供應(yīng)鏈總監(jiān)財務(wù)月結(jié)關(guān)賬時間月結(jié)日到出具管理層報表的實際天數(shù)財務(wù)系統(tǒng)日志財務(wù)負責(zé)人核心主數(shù)據(jù)合格率通過校驗的記錄數(shù) / 記錄總數(shù)數(shù)據(jù)質(zhì)量檢查腳本各數(shù)據(jù) Owner流程例外處理平均時長例外單據(jù)從提交到關(guān)閉的平均小時數(shù)流程平臺工單流程 Owner這組指標設(shè)計上有兩個講究。第一每個指標都有明確的負責(zé)人和數(shù)據(jù)來源避免考核落空。第二指標之間互相咬合主數(shù)據(jù)合格率上不去訂單準時交付率一定上不去這樣業(yè)務(wù)部門不會覺得數(shù)據(jù)治理是 IT 的事。還有一個低調(diào)但很有用的做法指標要允許暫時難看。數(shù)字化轉(zhuǎn)型起步階段數(shù)據(jù)合格率很可能只有 60%這時候要讓老板接受先把真實數(shù)據(jù)亮出來再逐月提升而不是讓業(yè)務(wù)部門報一個漂亮的假數(shù)。虛假的高分比真實的低分傷地基傷得更狠這條路走不得。4. 用最小可用單元驗證地基一家制造企業(yè) 4 個月落地方案拆解前面講的都是框架這一章落回真實的施工方案。我以一個中型制造企業(yè)為例說明怎么用 4 個月時間在一個試點單元內(nèi)把數(shù)據(jù)、流程、組織、技術(shù)這四層地基完整打一遍。不是所有企業(yè)都要照抄這 4 個月但節(jié)奏和取舍可以復(fù)用。關(guān)鍵是別想一口吃成胖子用最小可用單元把地基驗證扎實。4.1 試點單元的三條選擇標準痛、順、認選試點單元是決定成敗的第一件事。太多項目死在試點選擇上選最容易的部門做完了沒有說服力選最難的部門做了一半推不動選老板指定的部門業(yè)務(wù)只是陪跑。我一般用三個條件篩。第一業(yè)務(wù)痛感最強。痛點不是老板認為的痛點而是業(yè)務(wù)部門天天被折磨、已經(jīng)有改變意愿的那個點。比如銷售天天被客戶催貨、生產(chǎn)天天被銷售催單那訂單交付就是好試點。第二數(shù)據(jù)基礎(chǔ)相對較好。選一個雖然不完美、但至少不用從零開始清理的領(lǐng)域。如果某個產(chǎn)品線的物料編碼已經(jīng)有 80% 一致率就優(yōu)先選它不要選編碼混亂到連盤點都做不了的老工廠。第三負責(zé)人愿意吃虧——愿意為長期數(shù)據(jù)質(zhì)量承擔(dān)短期責(zé)任愿意派業(yè)務(wù)骨干全職參與。這一點比前兩點更重要也是典型翻車點業(yè)務(wù)負責(zé)人嘴上支持心里覺得是 IT 項目試點就注定失敗。候選單元業(yè)務(wù)痛點數(shù)據(jù)現(xiàn)狀負責(zé)人配合度結(jié)論華東事業(yè)部訂單交付延誤嚴重高物料編碼一致率 85%好總經(jīng)理主動要求參與強優(yōu)先試點華北工廠庫存不準中編碼體系剛重建中認為是 IT 的事弱暫緩先做數(shù)據(jù)盤點4.2 四個月里程碑什么時候該交付什么一眼就能看出地基穩(wěn)不穩(wěn)選好試點后我習(xí)慣把 4 個月拆成四個里程碑每個里程碑都有明確的交付物和驗收標準。這里的時間不是絕對的小型企業(yè)可以壓縮到 3 個月集團型往往要放到 6 個月但里程碑的結(jié)構(gòu)不變。第一個月現(xiàn)狀評估與標準草案。完整畫出試點流程的現(xiàn)狀圖輸出數(shù)據(jù)字典草案和編碼規(guī)則草案同時完成存量數(shù)據(jù)的首次摸底。驗收標準很簡單業(yè)務(wù)副總看完現(xiàn)狀圖承認對我們就是這么亂而不是說你畫得不對。這一步的價值是讓所有人對問題達成共識后面做任何整改才有根基。第二個月流程改造與數(shù)據(jù)清洗。按目標流程重新劃分崗位職責(zé)發(fā)布 RACI 矩陣按第一月定下的標準清洗存量主數(shù)據(jù)清洗結(jié)果要拿到業(yè)務(wù)面前逐條確認。驗收標準試點范圍內(nèi)的核心數(shù)據(jù)一致率達到 95% 以上跨部門流程中不再需要微信確認訂單狀態(tài)。第三個月系統(tǒng)配置與接口打通。這里的工作量取決于現(xiàn)有系統(tǒng)的底子如果舊系統(tǒng)還能支撐試點流程優(yōu)先做最小改造而不是推倒重來如果必須上新模塊也要控制在試點范圍內(nèi)不要順手擴到全公司。驗收標準是端到端流程在系統(tǒng)里能跑通每一環(huán)節(jié)都有系統(tǒng)記錄。第四個月試運行與復(fù)盤。全員按新流程工作收集例外情況每周復(fù)盤一次每月輸出一份地基驗證報告。驗收標準不是零異常而是異常都能走明確通道不靠個人刷臉。階段關(guān)鍵交付物驗收標準第 1 月·定標準現(xiàn)狀流程圖、數(shù)據(jù)字典草案、編碼規(guī)則草案業(yè)務(wù)管理層認可現(xiàn)狀圖不質(zhì)疑數(shù)據(jù)問題第 2 月·改流程目標流程圖、RACI 責(zé)任矩陣、清洗后主數(shù)據(jù)核心數(shù)據(jù)一致率 ≥95%跨部門無需微信催單第 3 月·通系統(tǒng)接口配置、系統(tǒng)試運行記錄端到端流程在系統(tǒng)內(nèi)閉環(huán)每個環(huán)節(jié)可追溯第 4 月·做復(fù)盤試運行報告、例外清單、推廣建議異常有升級通道數(shù)據(jù)有人認領(lǐng)4.3 從試點到推廣先橫再縱別一條線同時鋪開試點跑通后最容易犯的錯誤是馬上把方案推廣到全公司。以我自己的血淚經(jīng)驗來說推廣的次序比推廣的速度重要得多。我的原則是先橫再縱先把同一條標準流程橫向復(fù)制到其他產(chǎn)品線、其他工廠讓流程和數(shù)據(jù)的通用性得到驗證再在試點基礎(chǔ)上縱向增加更多數(shù)據(jù)維度——比如從訂單交付延伸到成本核算、客戶盈利分析。橫向復(fù)制用的是同一套規(guī)則阻力小、見效快縱向深入會更難所以必須放在證明流程能復(fù)制之后。推廣階段還有一個容易被低估的工作培養(yǎng)種子用戶。每推廣一個部門先讓該部門的一名業(yè)務(wù)骨干在試點部門浸泡一到兩周跟著走一遍完整流程而不是直接讓 IT 去給全部門開培訓(xùn)會。種子用戶回到本部門后能用自己的話解釋新流程的好處這比任何項目宣貫材料都有效。部門之間的不信任是流程推行的最大阻力而種子用戶正是打破信任壁壘的人。5. 地基施工的四個經(jīng)典坑位現(xiàn)象、原因、排查清單干活多了就會發(fā)現(xiàn)數(shù)字化轉(zhuǎn)型的坑其實就那幾樣換著花樣反復(fù)出現(xiàn)。這一章把最常見的四個坑按現(xiàn)象、原因、解決寫清楚最后附一張排查清單方便你拿著問題對號入座。這四條我都在不同項目里親眼見過每一條都是用真金白銀填出來的經(jīng)驗。5.1 現(xiàn)象系統(tǒng)上線了業(yè)務(wù)就是不用現(xiàn)象花了大力氣上線的系統(tǒng)登陸人數(shù)越來越少業(yè)務(wù)私下還是用 Excel 和微信傳數(shù)據(jù)項目組統(tǒng)計出來的活躍率全靠月底補錄撐場面。這種情況最常見于銷售部和倉庫——他們覺得系統(tǒng)是給管理層看的對自己干活沒什么幫助。原因業(yè)務(wù)用系統(tǒng)的收益小于成本。要么是系統(tǒng)流程比原來更繁瑣要么是數(shù)據(jù)錄進去之后沒有任何反饋——業(yè)務(wù)錄了單看不到審批進度也不知道后續(xù)環(huán)節(jié)發(fā)生了什么。系統(tǒng)對業(yè)務(wù)是額外負擔(dān)自然會被繞開。解決把系統(tǒng)內(nèi)流程對業(yè)務(wù)的價值做出來。最有效的做法是讓業(yè)務(wù)在系統(tǒng)里能實時看到訂單走到哪一步、預(yù)計什么時候交付、有沒有超期風(fēng)險。哪怕只是把流程狀態(tài)做成可查詢的看板業(yè)務(wù)都會更愿意在系統(tǒng)里干活。其次把手工路徑堵一部分——比如停止接受微信群里的訂單變更所有變更必須在系統(tǒng)里提單這樣才能保住線上數(shù)據(jù)的真實性。注意堵手工路徑要提前通知給一周過渡期不能突然硬切否則業(yè)務(wù)會直接用罷工來抗議。5.2 現(xiàn)象數(shù)據(jù)看板有了口徑卻對不上現(xiàn)象管理層看到經(jīng)營看板很興奮但銷售總監(jiān)說里面的銷售額和財務(wù)口徑差了兩千萬。兩個部門各自核對發(fā)現(xiàn)一個含稅、一個不含稅一個按簽單時間、一個按開票時間?？趶綄Σ簧峡窗寰统闪藬[設(shè)很快沒人再看。原因指標定義沒有在數(shù)據(jù)治理階段定清楚。做看板的人通常直接取各系統(tǒng)的字段但各系統(tǒng)對同一個業(yè)務(wù)概念的定義從來就不一樣最后只能挑一個系統(tǒng)作為數(shù)據(jù)源而它和財務(wù)口徑天然不一致。這個問題最像玄學(xué)——每個部門單獨看都對放一起就對不上。解決在數(shù)據(jù)治理階段就把指標字典當作正式交付物而不只是系統(tǒng)需求文檔。每個指標寫清楚業(yè)務(wù)定義、計算公式、數(shù)據(jù)來源、統(tǒng)計時點并由業(yè)務(wù)負責(zé)人簽字確認?？窗迳系拿總€指標要能追溯到指標字典里的對應(yīng)條目。沒有指標字典就上線看板等于讓不同部門繼續(xù)各說各話出了分歧連吵都不知道從哪里吵起。5.3 現(xiàn)象轉(zhuǎn)型項目做成了 IT 項目業(yè)務(wù)全程旁觀現(xiàn)象項目例會全是 IT 在匯報業(yè)務(wù)部門只派一個接口人列席需求評審時業(yè)務(wù)不提真實痛點和約束等到上線前才說這個不能用。最后項目延期業(yè)務(wù)還會補一句早就知道這么做不行。這個場景在太多公司上演過幾乎成了轉(zhuǎn)型失敗的標配。原因管理層把數(shù)字化轉(zhuǎn)型當成 IT 部門的事沒有把業(yè)務(wù)部門的參與寫進績效考核。業(yè)務(wù)加班加點沒有激勵配合 IT 做需求反而被說不務(wù)正業(yè)自然能躲就躲。IT 部門推動業(yè)務(wù)變革本來就名不正言不順。解決在項目立項時就把關(guān)鍵業(yè)務(wù)人員的投入比例寫清楚并納入他們的績效目標。常見做法是讓業(yè)務(wù)負責(zé)人擔(dān)任項目副組長的角色對流程成果負責(zé)每個試點部門指定一名全職的種子用戶至少在關(guān)鍵的兩個月里每天一半以上的時間泡在項目里。同時把業(yè)務(wù)參與度設(shè)計到項目進度里每個月評估一次業(yè)務(wù)側(cè)是否兌現(xiàn)了投入承諾而不是等到季度末才發(fā)現(xiàn)人根本不來。轉(zhuǎn)型項目最怕的不是技術(shù)延期而是業(yè)務(wù)缺席。5.4 現(xiàn)象工具越上越多流程反而更慢現(xiàn)象為了推進轉(zhuǎn)型公司接二連三上了低代碼平臺、流程審批系統(tǒng)、在線協(xié)同工具結(jié)果一張請假單要在三個系統(tǒng)各走一遍業(yè)務(wù)抱怨工作效率不升反降。老板看到的是工具很多、轉(zhuǎn)型很熱鬧員工看到的是每天要在不同系統(tǒng)里重復(fù)填單據(jù)。原因工具先行、流程未理。是用一堆新工具把原來在兩個部門之間傳輸?shù)男畔⒉鸪闪嗽谖鍌€系統(tǒng)之間的輸入輸出。每個工具都有自己的規(guī)則部門對著工具改習(xí)慣流程自然越改越碎。工具把斷點變得更隱蔽并沒有真正消掉斷點。解決以流程為綱、以工具為目。先把端到端流程改善方案定下來再決定哪些系統(tǒng)需要改造、哪些系統(tǒng)可以直接廢棄。一個成熟的判斷標準是任何跨系統(tǒng)的數(shù)據(jù)流轉(zhuǎn)都應(yīng)該有唯一的系統(tǒng)來源其余系統(tǒng)只做讀取不允許重復(fù)錄入。如果一個新增工具不能消減已有系統(tǒng)的錄入量就不要上。流程標準化不能靠堆工具解決反而會被工具固化得越來越僵。5.5 一張表排查遇到問題先看是哪層地基松了癥狀可能松的地基層建議先查什么系統(tǒng)上線沒人用組織層 技術(shù)層先查業(yè)務(wù)錄單后能否獲得反饋再查流程是否增加了業(yè)務(wù)負擔(dān)報表口徑對不上數(shù)據(jù)層先查指標字典是否存在業(yè)務(wù)是否簽字確認項目會沒有業(yè)務(wù)聲音組織層先查業(yè)務(wù)骨干投入占比再查考核里有沒有納入項目目標流程越來越多、效率降低流程層 技術(shù)層先查冗余審批和重復(fù)錄入再查系統(tǒng)間是否有唯一數(shù)據(jù)源試點成功但推廣困難組織層先查種子用戶是否到位再查推廣部門是否有專人承接這張排查表我經(jīng)常直接貼在項目組的白板上。遇到問題先別急著怪某個系統(tǒng)對號入座找到松掉的地基層整改方向才不會跑偏。拿不準的時候先補組織層和數(shù)據(jù)層因為這兩個是最便宜也最容易被忽略的。6. 拿什么證明你打的是基石三個壓力測試動作地基打得穩(wěn)不穩(wěn)不能用匯報 PPT 來證明要用壓力測試來驗證。我有三個固定的驗證動作成本很低但每次都能把真正的問題逼出來。如果這三個動作都過了再往上蓋樓心里才踏實。第一個動作是數(shù)據(jù)血緣測試隨便挑一張管理層報表里的指標往上游追問三層——這個數(shù)來自哪張表、哪個系統(tǒng)、哪條原始記錄每層對應(yīng)的負責(zé)人是誰。如果項目組能在一個小時內(nèi)講清楚數(shù)據(jù)地基就是實的如果問到第二層就開始應(yīng)該是從某系統(tǒng)導(dǎo)出的這種含糊其辭那一層就得返工。我一般會專挑那些看著很順的指標去問越順越要問到底。第二個動作是流程斷點掃描找一個剛?cè)肼毜膶嵙?xí)生讓他完全照標準流程文件走一遍實際業(yè)務(wù)不允許他打電話問老同事。記錄他卡在哪一步、需要問誰、最后有沒有走通。新人不靠人情、不認潛規(guī)則他走不動的地方就是流程里真正斷掉的地方。這個動作比任何流程審計都真實因為流程審計查的是紙面這個查的是實際。第三個動作是交接班測試讓一個核心崗位的骨干休一周假看他每天處理的常規(guī)事務(wù)能不能被文檔和系統(tǒng)接住。能接住說明能力已經(jīng)沉淀到組織里接不住說明組織還在依賴個人黑匣子。地基是組織的不是某個能人的這個測試能把人治和制度治的區(qū)別直接曬出來。我做過的判斷里只要這三個測試有兩個不過后面上再漂亮的系統(tǒng)都會晃這是很實在的一條規(guī)律。之前跟過一個項目數(shù)據(jù)看板做得非常漂亮管理層一度相當滿意結(jié)果到按區(qū)域拆解利潤時底層數(shù)據(jù)根本拆不出來整個項目返工了三個多月。那次之后我學(xué)乖了——凡是說底子很好的企業(yè)我先拿這三個動作試一遍測不過的地基寧可往后放一放也不要急著蓋高樓。希望幫到你。本文還有配套的精品資源點擊獲取