為什麼許多數位轉型計畫,明明選對了技術,最後卻仍以失敗收場?根源通常不在工具,而在企業攬下了太大的範疇:一個為期兩年、把效益永遠擺在前方的專案。相反地,當你把整段旅程切成三段各 30 天、每一段都交出一個可衡量的成果,團隊既能維持動能,又能把一個大風險化為多個可控的小風險。在這篇文章裡,我們會一起走過一套具體的 90 天框架——連同那些會讓連短跑都趕不上進度的陷阱。
為什麼大範疇是無聲的殺手
一個專案愈大,出成果的那天就愈遠,主管的信心也愈容易冷卻。當所有效益都只在一個巨大的上線日之後才出現,途中每一次卡關都在磨損支持,而專案團隊還沒抵達終點就已精疲力竭。大範疇也會在一開始就把設計鎖死:等到系統上線,真實需求早已改變,你驗收的是一個解決十八個月前問題的東西。90 天框架不是一個專案管理的小技巧;它是一種逼組織排出優先順序、並及早交出一個真實成果的方式——早到足以在下更大賭注之前證明方向。
頭 30 天——一個單一真實來源
別想一次數位化所有東西。挑一個最痛的業務——對多數企業而言是庫存或銷售——把它搬上一個共用的資料層。這一段的具體目標是:30 天結束時,從倉庫到會計到銷售的每一個人,都看著同一個即時庫存數字,而不是三份彼此不一致的試算表。這是一個小而可驗證的終點,並為後面的一切打下地基。
接下來 30 天——整併相鄰的業務
當地基穩固之後,把碰觸到它的業務串起來,而不是另闢一條新戰線。採購讀取真實庫存以下對的量;財務讀取真實訂單以即時認列應收。一個明顯的例子:當庫存與採購共用一個數字,採購建議就會從再訂購點自動生成,而不是靠倉管的記憶;而每一個這樣的連結,都消去一個重複輸入的點,以及一場「到底誰的數字才對」的爭執。原則是沿著資料已經流動的路徑擴展,不要只因為某座新島嶼聽起來誘人就跳過去。
最後 30 天——優化與第一個 AI 任務
此時資料已乾淨且連貫,才值得加上高價值的一層:當庫存低於再訂購點時自動示警、用簽核流程取代來回的電子郵件,以及在真實資料上的一兩個窄任務 AI——例如解釋為什麼本週營收偏離計畫,並回溯到具體的訂單。這個順序很重要:在髒資料上做自動化,只會更快地放大錯誤,所以優化必須等資料基礎值得信任之後才來。
那些會讓 90 天仍然失敗的陷阱
把時間切小並不會自動拯救一個專案。最常見的四個陷阱:
- 沒有單一的負責人:當責任平均分給所有人,就沒有人在掌控節奏。
- 低估舊資料的清理——重複的編碼、虛庫存——任由它吃掉整個第一段。
- 挑容易的業務而非最痛的業務:在沒人在意的地方獲勝,改變不了信心。
- 把「完成」定義得含糊,以致段落結束時沒人敢斷言已經達成。
在按下碼表之前——以及如何開始
在第一段之前,先就三件事達成共識:哪個業務先上、哪個數字是成功的量尺,以及誰是負責人。這三個答案比任何冗長的計畫書都更有價值。風險最低的起步方式,是為最痛的業務跑一段恰好 30 天,並把它當成一個測試:如果它交出一個全公司都信的數字,你就有了繼續前進的證據;如果沒有,你也只損失一個月,而不是兩年。一個小而真實的成果,永遠勝過一個大而遙遠的承諾。
「90 天內的成果能守住信任；一個兩年的專案則會失去它。」