數位轉型讓IT計畫有效對焦營收與流程，預防風險提升回報

大多數數位轉型專案，說真的，從一開始那一刻基本就註定會踩雷。這不是危言聳聽 - 你只要去翻翻身邊案例，其實就很難否認。有的企業搞出什麼「為期五年的策略規劃」，表面看來冠冕堂皇，但往往只是滿紙荒唐；那些印製精美、分頁紛雜，最後堆高如山的投影片劇本，更像是演給董事會看的橋段，仿佛在秀自己有多「專業」 - 但有用嗎？坦白講，大部分組織是把鉅額資金倒進看似創新的科技方案裡，然後假裝在解決一些理論上的問題。

「數位轉型」跟「雲端採用」這類詞彙很夯啊，每年預算動輒天價，可管理流程基本隨性到好笑。我想，有時候還不如幼童拿著蠟筆在牆上亂畫來得真誠。有些公司項目做到後來也挺慘的 - 不上不下。既沒徹底完成，也說不上正式終止，每個月只是在悄悄燒錢而已。嗯…根本癥結其實很老掉牙，就是：董事會（他們總是豪言壯語）和資訊單位現場環境之間鴻溝巨大、牛頭不對馬嘴。

這種事光靠開幾場全員會議啦，再添購新生產力軟體，是絕對救不回來的。有沒有辦法？還是有啦，只是很少被台面上的顧問或熱血演講者重視。其實，有種工具反而正中要害，就是商業情境分析（Business Scenario）。名字乍聽超級無聊，甚至讓人懶得了解，好像在填某份稅務表格…但說真的，它才是真能提前攔住失敗浪潮的一道防線。不花俏，卻夠兇猛，用起來直接拷問每一個推專案的人：「你究竟想幹嘛？服務誰？成功該怎麼判斷？」企業最怕被問穿心話。

比起那些充滿泡影感的「協同效應」啦、「顛覆式創新」等神秘口號，我覺得比較關鍵的是弄清楚：我們寫下去的每一行程式碼，到底是不是都在為盈利加分，一條直線拉到底。很多公司的所謂策略，都停留在天花亂墜的理想層次，離真正落地遠如天涯 - 這點常見到令人發笑吧。

「成為市場上客戶體驗的領導者」這種話，嗯……坦白說，它根本算不上什麼策略啦。這比較像一個醒目的標語，頂多印在馬克杯、T恤那種員工禮品上 - 誰拿到都能解讀出自己想要的意思。講真的，你問業務主管，他大概會覺得公司就是應該買一套全新的CRM系統才對；而行銷單位眼裡，那可能是開發什麼元宇宙商店才算跟得上時代。再來CTO嘛，又堅持徹底換掉技術架構，要把一切搞成微服務，不轉型就等著被落下。他們的每個提議，其實都好像有點道理，而且都已經準備啟動高達七位數字的預算計畫。不誇張啦，每人各吹各調。

好啦，就是在這樣亂七八糟狀態下，「業務場景」（Business Scenario）才變得真有意義。有別於那些虛無飄渺的大口號，業務場景是種比較規範的寫法，內容從抽象目標一路細分到實際流程、組織裡誰參與哪些環節、甚至連用到什麼技術細節都包進去了。一份好的場景記錄會幫你把涉入角色從C-suite高層，到前線客服專員，再一路往下追溯到連接後台金流API這些環節通通補齊，而且它強制你別玩虛招，而是真正定義具體硬指標 - 比如既定時間內必須完成哪些數據、哪項成效才能過關。

比如說，「提升線上銷售」，這類看起來很帥氣但空洞模糊的講法，被真正拆解之後，就會明明白白地變成「12個月內，我要靠部署個人化推薦引擎，使自家網店營收增長20%」。中間差異真的不只在語言表現的細膩度；它是一步步構築出那些可追蹤、問責到底的小型任務，把所謂企業願景活生生掰碎裝箱，換成資訊部門每天要拆帳做進度的需求藍圖。也有人說吧，這就是財報績效跟IT投資之間最實在的一座橋樑。如果沒有搭好，它不是少了一筆績效獎金，而是所有花出去投資像石沉大海，公司最後只能乾瞪著IT燒錢卻死活等不到結果。

### 主動（Offense） 與 防禦（Defense）
其實哈，大部分企業卡住不前，都逃不掉那種消極防守的心態。挺多人推新科技，坦白說只是為了收拾昨天遺留下來問題 - 光想著先補漏洞就沒力去嘗試未來路怎麼走。

「我們的資料全都散落成孤島，好像彼此間說不上幾句話。」「結帳流程卡得讓人心浮氣躁，有點受不了。」「客訴案件越積越多，看了頭皮發麻。」這些問題聽起來確實讓人焦慮，可是講穿了，都只是在拼命往船艙裡補洞 - 感覺只是拖延那艘已經在下沉的船走向沈沒而已，說嚴格一點，就是維持現狀、止血而非真正在成長。我有時會想：企業層級常陷在「避免出包」裡打轉，但鮮少問：「怎麼突破或開創？」其實，所謂有力量的業務情境（Business Scenario），它真正厲害之處，是要逼所有相關的人別光顧著記錄瑕疵，而是真的去尋找機會，把原本「我們搞砸什麼？」的檢討，換成「我們能開創哪些新東西？」，欸，就這樣子的腦筋急轉彎，其實暗中決定了公司到底只能微調修正一下小細節，還是有機會弄出截然不同的新價值鏈。

你如果一直聚焦在為報表跑不快吭哧苦惱，只會固步自封；可是試想轉個念，把重心改放到如何建立即時分析平台、去支撐更精密的預測型庫存管理，那畫面就完全不同嘛 - 整個組織將朝下一個世代推進。嚴格講，這種模式強制大家梳理自己家的商業營運模式，而且不能亂畫餅，你得具體把規劃中的技術方案和公司賴以生存、賺錢那些重要活動連結起來。不對核心價值鏈動刀、不聚焦於某個關鍵環節的項目，老實說，不太值得搞，就很簡單。一旦這層紀律徹底拉開，相信我，那些雞肋般黏人的「寵物專案」，還有不少只是取悅高階主管腦袋的小玩意，全都會被攤在陽光下，很難再混過市場考驗。

### 責任契約

其實 Business Scenario 的底層邏輯，本質就是一紙責任契約，是企業部門與技術端彼此立下明文承諾的一場協商。業務方必須清楚答應要交付的是什麼 - 不是大略帶過，而是要列得清清楚楚、量化可驗證那種才算數。

技術落地說穿了，就是交付承諾所必須具備的內功啊。這些全都有文件存檔，未來每回抉擇、定奪走到十字路口，都得先翻出來參照。不管你是在決定該挑哪個供應商，還是頭大於預算分多少錢，它就是底本。講句實話，市場有風吹草動的時候，公司其實也不可能整套規劃砍掉重練。怎麼辦？只好再三盤點狀況：彼此心態是否還統一、盼望達標的結果會不會變味、現下這批工具跟架構用起來過氣沒？唉呦，其實這種調整喬東喬西、拉鋸折衝，都在讓企業像活生生、有彈性的東西 - 不是掛牆上的那張動不了的大餅啦。

能玩轉這種流程的公司資源運用效率都很高，不會天天在那邊苦思雲端換哪家或語言該選啥。他們從場景端就先把需求釘死，再由需求拉出解答，做什麼都指向真問題而非花拳繡腿。有反例耶，有些企業根本懶理這一套，一搞下去經常陷泥淖 - 說什麼策略演化，其實是技術園區裡堆了一房間沒完成品和荒廢設想。弄得像座活歷史展館般—失敗方案層層疊墊底，只剩迷失路線圖。一條路子靠自身發育撐上去，另一條可能到頭成併購魚肉或...直接招手申請破產，好吧。

### 堅不可摧理念的剖析

很多專案搞砸看似千奇百怪，但細追根源常是一樣爛梗：最開始就是目標含混、怎畫都霧濛濛。然後範圍越捏越大、不設限滑出去；更尷尬的是，大夥兒思想意見通通對不上頻道…嗯，很常見啦。拿一份仔細打造且精雕細琢的業務情境說吧，它遠遠不是僅僅「一紙陳述」就講完（事實上一段好案例甚至影響多年！）。

有些想法在你還沒掏出第一塊錢之前，就需要好好折騰一番。說它是壓力測試工具也行吧，反正這整組場景就像齒輪咬合著驅動一部奇特機器。這裡頭的每個要素，其實都在推動著一輪盤算，而不是哪種繁文縟節的檢查表 - 如果你以為只是官樣文章，那可真搞錯了。倒不如把它看作一次情報大蒐集好了。

主要任務之一，就是摸透自己涉及哪些業務流程、應用環境，到底是敵陣地圖還是本營範圍要弄清楚 - 這很難不讓人神經緊繃啊。必須厘清會被牽動的系統、即將被顛覆的工作方法，分辨那些資產平台與悄然成形的風險負債。搞懂業務脈絡跟技術背景，其實是在預判氣候變化，萬一天災降臨（嗯…比喻啦），得知道撐得住嗎？

譬如說：你現在是不是剛好卡在什麼高強度監管產業？競爭者那邊又傳來他們偷偷上新平台的小道消息？至於自己的基礎設施吧……究竟稱得上可靠堡壘，還是一灘攤黏糊技術債泥淖？我老實說吧 - 這整套過程對某些管理層而言可不是普通焦慮，深挖現場總令人極不舒坦。不過你若還拿什麼協同大平臺一類浮誇字眼胡混，不如直接把話挑明：我家訂單處理系統嘛，其實五組殘舊程式再配三段手作小繞路勉強湊起來，好吧。我覺得，如果無法回歸問題現場認真面對，要談解方根本免談。

### SMART武器庫

講真的，「SMART目標」近幾年被企業玩爛掉，本來還能當點指引，如今反倒像陳腔濫調互相轉傳。有趣的是，在搭建商業情境時，這東西突然像利刃一般，被拿來精準切分專案成功條件 - 到底怎樣叫「贏」就界定得死死的。

粗略意願，也會強行拆成具體（Specific）、可衡量（Measurable）、能執行（Actionable）、其實辦得到（Realistic）與限期內完成（Time-bound） - 而且這些絕對不是什麼僅供參考的小建議。原則若浮皮潦草混過去，那後面全線都危險，大概只有外行才會想靠運氣唬弄過關吧。

所謂明確的參與條件，就是一點模糊都不給你留，真的無路可退啦。例如「提升顧客留存率」這種說法，坦白講，只能算是心理安慰，跟朋友許個心願差不多；但像「在六個月內，將我們頂級訂閱方案的流失率從4%降低至2%」，嗯，這才是真刀真槍要人執行。這種目標就是不能狡辯也沒藉口閃躲。

再來，「可衡量」 - 唔，就是一定得讓數字講話。說真的，你不能單靠某次反饋或誰一句稱讚就宣告大功告成吧？有指標才能看出到底前進了沒有。事先預設那些要追蹤的KPI（關鍵績效指標），算是一道防護網，不然專案成功只會落入各自表述裡面，有點好笑。

嗯，再說一下什麼叫做「可行性」跟「現實性」...基本上，是強迫所有計畫必須面對很硬核、無情甚至可能有點掃興的現實考驗，例如預算多少？公司技術行不行得通？組織整合能力過不過關？說穿了，夢想很美好，但被資源掐住脖子的時候，人只能苦笑一下。不過也只有勇敢碰這些門檻，項目才有那麼一點機會活下來。

另外就是時間限定喔。欸，其實只要沒截止日，一切變得可拖延了。沒有終點線，就像嗜好活動、散步似的玩票，不痛不癢。有時覺得—咦？規劃完全沒有時程安排，其實只是在寫白日夢耶（笑）。

回頭想想吧 - 全部綁在一起後，那股壓力混雜紀律又逼自己正視困難，各式散亂主意，被硬生生套上一條聚焦的戰鬥繩索。別誤會，它不是約束發展，而是打怪升級必須裝備的方法論而已。

### 痛點武器化

多數公司遇到壞消息都本能搖頭，要嘛假裝沒看到，要嘛拚命維持表面上的平靜。但，有趣的是，在商業場景規劃裡啊，把痛處、潛藏風險都攤開講明白其實是一份本職學能 - 甚至是不露聲色地避免踩雷的核心技能。直白來講，只要你敢承認問題存在，就等於擁有提前部署警報系統的優勢。

為什麼效率低落老是在公司裡蔓延？欸，大概外部競爭者盯著你的漏洞，都準備偷渡了啦。例如：資料放東放西查不到、流程卡死全靠人工腦補、不然就系統陳舊如活化石，每一樣都可能變致命破口，很煩是真的。如果願意認真用數據把每種風險估出量級，我不是鼓吹整天悲觀喔...純粹是讓大家眼光向前，多練策略分工應變罷了。一句話，其用意早不是詛咒未來，而是嘗試為後面每一步鋪下保護墊，就這樣。（呼～今天總算摸魚完畢。）

「整合複雜性」這件事，唉說真的，它根本就是個甩都甩不掉的風險點。真正有sense的人，其實不只會條列什麼有危機 - 人家是連評分都一起下了。例如直接一句：「跟舊版ERP系統結合，失敗率高得嚇死人，而且時程勢必被拖累。」像這類狠話講出來，就等於把相關團隊推到不得不面對、立即討論後路的位置。有沒有可能非得拉middleware來解？開發工程師要不要額外編列？又或者，應不應該乾脆讓介面設計更陽春一點才對？嗯...當問題經過拆解以後，那層模糊恐慌反而會開始退散，原本鬼打牆的「未知」就換成系列能商量的挑戰，看似扯爛麻的風險也多半能安排進預防措施裡。反過來，那些忽略上述步驟的大公司，其實天天陷在突如其來的小火災：明明該想到的意外全都沒提前備案，只好不斷補救應急。坦白說，被動收拾殘局跟領先規劃，是完全兩種處世邏輯。搞懂怎麼超前部署的人，基本上活得比人輕鬆啦。

### 執行引擎

老實講，在企業世界裡面，每隔幾年一定就有人吵架：到底Waterfall還是Agile比較厲害、Scrum和Kanban誰才能坐正宗寶座？說句重話吧 - 與其顧著分教派，其實大家真正卡關的並不是用哪套流程名詞，而是做事情的方法總無法徹底落地，輸出價值還是接不起來。如果你稍微翻閱TOGAF裡面的Architecture Development Method（ADM），乍看下去那個圖密密麻麻又折騰，但換種思考方式也許舒服些，不妨想像它其實是一條工業流水線好了。在這裡，「業務情境」（Business Scenarios）頂多就是最高品質料件，一切後續運轉都繞著它展開。不這樣弄，本質上流程再複雜也只是花樣炫技而已罷了。

沒有那些元素的話，說實話，工廠根本只能生產出堆積如山的廢棄物。欸，先撇開細節，流程起點就是那個Phase A，也叫什麼Architecture Vision（架構願景）。很妙的是，在這裡所謂Scenario（情境）有一種靈魂級的重要性，它不單單只是「畫個範圍線」這麼無聊 - 更像是在寫自己的行動宣言吧。明確而又獲得高層首肯的Scenario，其實就像正式把大家的意志釘在牆上；它支撐著團隊能不能得到推進變革所必需的政治背書與戰略正當性。有趣的是，只要能把「為什麼」這回事講得清楚、徹底，那Scenario其實就像整件工程都繞著它打轉。

但常被人挑剔：有些玩敏捷開發的會認為Scenario是不是一堆冗文？事實也不是啦，一份靠譜又利落的Scenario才不需要寫成長篇巨卷，大概幾頁條列重點，就已經夠讓方向清楚。說穿了，它是用來劃定戰略界線與下行號令，把那些具體如何達成目標、怎樣跨部門協作、天天磨合優化什麼，都可以再留給之後靠Agile拆解。反而有了Scenario，整組敏捷小組才能不會莫名往歪路上猛衝。

後續怎麼走？坦白講，即使流程跑進ADM下一步時 - 那就是Phase B（Business Architecture，業務架構） - Scenario還是和影子一樣一路跟到底。用來檢查現狀和理想間到底差多遠。例如公司想推「即時庫存追蹤」，偏偏系統老是卡著一天只更新一次，嗯…這就是兩者能力上的裂縫嘛，而恰好架構設計本來就該拿來補齊這塊。而且Gap Analysis（落差分析）結果沒別的地方可去，就是直接導進Phase E（Opportunities and Solutions，機會與解決方案）。也因為如此，每一步選擇哪條解法路線靠不靠譜，都免不了得回頭照顧到最初訂好的Scenario - 繞了一大圈，又回到本源問題哩！

在要決定「建置新系統」、「買SaaS產品」或是乾脆把舊應用打掉重練時，嗯……這真的說不上只是個純技術選擇。坦白講，背後其實全靠那個獨特的現場狀況 - 你眼下有什麼目的、卡在哪裡、有什麼風險，每一樣都是考慮點。有點像是，那個情境直接拿來當檢查表，所有備案好像都得根據它打分數吧。哎呀，一步一步推回來看，其實會變成一條很清楚的主軸 - 企業真正想完成啥？然後就拉出那些做不到、還欠缺的能力欄目；這些缺口再往下逼，才生出一堆解法給你比拼試選。最後，不論你選哪一道菜，效果都最好能被拉回到情境KPI對帳。不多嘴，閉環搞定才能叫作一個像樣且可追溯的技術體系咩，它核心就是誰該負責找得到人抓包。

### 策略終局

坦率說，大部分公司視科技就是個業務開工道具，有點理所當然。但世上有那麼極少幾間怪傑型組織啊，人家反而抓著科技，把自己城牆壘得滴水不漏。他們做專案不是只求交差，而是真的開始悶頭打造自己的策略性武器庫。不騙你，到這種層級，「商業情境」（Business Scenario）根本不是單次計畫小玩意兒了，而會化身成那種支撐彈性與抗擊崩壞的鎮社之寶。不諱言啦，他們玩的是傳說中以能力為主線（capability-based planning）去謀略 - 從此焦點轉移，再也不是那種只能活一次的小方案，而要弄出既能多次派上用場，又可協助不同部門運作起來的大規模「業務能力」。欸，比方說，以前大家搶著替某個嶄新行動APP拚命寫支付功能，辛苦半天，下次又得重寫。但他們不跟，只花力氣打一套共通「支付服務」（Payment Services），整家公司 - 甚至各子公司，都能共享運用。這類框架玩法，是每個商業情境都事先攤牌明確需求，再讓專門小組負責規劃長線且可拉伸、變形自如的關鍵資產。細細品味，兩者距離真不只一步棋啦，你可以說象棋大師和跳棋初學仔，本質已完全不同了。

在棋盤上，誰能卡住正中央，就是下場氣勢贏過半。嗯…如果要用來比喻企業經營，那組一套完整的商業能力，好像就是把主導權抓在手心吧。不囉唆 - 只要有這樣的組合，公司遇上突發狀況時（比如說忽然冒出個新競爭者），直接調派現成的底牌，不用什麼都重新規劃，速度快到讓人措手不及。掌控局勢，其實沒那麼遙不可及。

### 未來情境兵棋推演

講到底，最極端的玩法，是提前沙盤推演未來各種可能路線。有些企業架構團隊，不再只是無聊地紀錄現狀，而是主動針對不同未來劇本下手，比如主要供應商搞失蹤、新法規咻咻落地、最大對手突然被併購……欸，想得到或想不到的變化，全都預先列成各式「商業情境」。就這樣，每種潛在事件不再只有被動觀望，公司能依照劇本調整策略，搶在問題爆開前找到活路。所以啊，一紙框架從負擔跳級升格成核心競爭資產；公司不是被未來追著跑，而是真的坐下來自選想抵達的人生階段 - 你要的是哪條結局？

老實說啦，要做到這種程度超難。真正具有紀律、目光遠大的領導者本就鳳毛麟角。而且還必須願意把力氣和心血花在打底子上，不只是眼前績效衝衝衝，那種掩耳盜鈴只拼財報的作風，到最後恐怕也就刷存在而已。在現在如此詭譎多變的大環境裡，那些早早部署、肯耕耘長線機會的公司，大抵更容易突圍；反之，只靠短利撐場面的人，很容易連註解資格都沒有。其實企業架構嘛，看似隱蔽，但根本藏著足以翻桌的大武器。

假如你還有興趣研究怎麼建立自己的IT架構腦袋，或者也許單純愛看別人踩過哪些坑，都歡迎到我的網站晃晃：https://itbookhub.com