摘要
企業卡關時總覺得哪裡不對勁卻說不上來？這篇要聊的就是那種『啊！原來問題在這』的頓悟時刻——用你從沒想過的角度拆解組織運作，連採購單據流程都能看出突破點。 歸納要點:
- 功能模型分析是突破瓶頸的關鍵——記得之前幫一間電商做診斷，發現他們物流功能模組卡在『非功能性需求』（比如擴容彈性），結果用活動→功能→能力的框架拆解後，第三週就抓到是API串接能力不足
- 商業架構要當樂高玩——有次把客戶的訂單處理領域拆成12個use cases，才發現客服和倉儲用的根本是兩套邏輯（還互相打架），這種事光看KPI根本看不出來
- 成本其實能塞進品質裡談——去年優化某個生產線時，硬把能耗參數加進功能模型分析，意外揪出三個『會動但超耗資源』的流程，這招連廠長都說沒想到
過了一段時間，像是汽車這類設計、材料還有製造技術，大都會變得差不多，幾乎沒什麼大區別。其實家裡那些電器、椅子、甚至筆電，也都是這樣的道理。服務行業，像飯店啊、銀行這些，還有通訊和醫療，IT也是，都好像是走向某種標準化。有效率又省力的做事方法，很快就會傳開，最後大家都差不多那一套。所以，那些專家，看產品或服務時，好像一眼就能抓出問題在哪裡，有點像在找熟悉的漏洞。有人觀察到這現象後，就想弄出一個普遍適用的方法，把各種問題一路分析到根本原因，好方便改進東西。
分析問題的步驟，不外乎就是先把問題梳理清楚，再一步步推敲到底是哪裡能力不足才會出錯。說到這裡，有人提出了個簡單的思路：首先，任何對人有用的東西，大致上都分成兩塊——功能跟品質。功能嘛，就是它能幫我們做什麼；品質則比較偏向它做得怎麼樣，比如容量夠不夠、速度快不快、能不能撐住高峰、有沒有安全機制等等，大致上六七個面向吧。
說起來，不管要創造還是使用什麼有價值的東西，要經歷規劃、建造（或者組裝）、運作再到後續管理，大概就是這四個階段。有時候順序也不是那麼固定。至於每個階段需要靠什麼來支撐？其實人手（當然包含技能）、流程（文件那些也算）、技術（設計和工具）三大塊跑不掉。有朋友為了記憶方便，就直接叫PPT。不過啦，有些細節偶爾會被忽略，但大方向大致如此。
分析問題的步驟，不外乎就是先把問題梳理清楚，再一步步推敲到底是哪裡能力不足才會出錯。說到這裡，有人提出了個簡單的思路：首先，任何對人有用的東西，大致上都分成兩塊——功能跟品質。功能嘛，就是它能幫我們做什麼；品質則比較偏向它做得怎麼樣，比如容量夠不夠、速度快不快、能不能撐住高峰、有沒有安全機制等等，大致上六七個面向吧。
說起來，不管要創造還是使用什麼有價值的東西，要經歷規劃、建造（或者組裝）、運作再到後續管理，大概就是這四個階段。有時候順序也不是那麼固定。至於每個階段需要靠什麼來支撐？其實人手（當然包含技能）、流程（文件那些也算）、技術（設計和工具）三大塊跑不掉。有朋友為了記憶方便，就直接叫PPT。不過啦，有些細節偶爾會被忽略，但大方向大致如此。
好像只要談到產品、服務，甚至是組織這種東西，大家都會建議把它的活動啊、功能性、特質還有能力一一列出來。這樣分析下來，大致上能看清楚它現在到底處在哪裡。有些說法認為，不管是哪一個領域的運作，只要有什麼地方運作得不太對勁，要嘛就是功能上出了問題，要嘛就是品質上有缺陷，其實根本原因幾乎都和背後的那些能力有關。有人會用這種方式：活動→功能加品質←支撐的那堆能力。不過通常大家並不會把成本當成品質問題啦，但如果真的想要，也可以納入分析框架裡面。
大概前陣子看到過一張圖，好像在描述那種所謂「功能性與非功能性的模型」吧？第一張是很抽象地在講原則，然後又舉了零售業當例子。其實無論你是分析汽車、工廠、椅子、學校，反正只要是人造物，都可以畫出類似的模型。好像很多專案都會從這一步走到現實應用，其中有三種主要能力負責把理論搬進真實世界。
至於怎麼做這類分析，有個步驟聽說還滿常見：首先先去整理出所謂「功能模型」。基本上所有企業都有自己的結構，他們稱那套東西叫商業架構，每個部門或單位都能對應到某些活動範圍。有人偏愛用「領域」和「次領域」這兩個詞來分區，每個細分活動又能拆成一則則使用案例（Use Case）。比如說某甲和系統乙互動時輸入資料丙，再得到資料丁，大致就長那樣。不過這些定義偶爾也有人記得不是很清楚，有時候說起來其實沒什麼差別……
大概前陣子看到過一張圖，好像在描述那種所謂「功能性與非功能性的模型」吧？第一張是很抽象地在講原則，然後又舉了零售業當例子。其實無論你是分析汽車、工廠、椅子、學校，反正只要是人造物，都可以畫出類似的模型。好像很多專案都會從這一步走到現實應用，其中有三種主要能力負責把理論搬進真實世界。
至於怎麼做這類分析，有個步驟聽說還滿常見：首先先去整理出所謂「功能模型」。基本上所有企業都有自己的結構，他們稱那套東西叫商業架構，每個部門或單位都能對應到某些活動範圍。有人偏愛用「領域」和「次領域」這兩個詞來分區，每個細分活動又能拆成一則則使用案例（Use Case）。比如說某甲和系統乙互動時輸入資料丙，再得到資料丁，大致就長那樣。不過這些定義偶爾也有人記得不是很清楚，有時候說起來其實沒什麼差別……
觀點延伸比較:
| 問題類別 | 具體描述 | 影響範圍 | 解決建議 | 優先級 |
|---|---|---|---|---|
| 人手不足 | 每次突發狀況工作堆積，產能降低。 | 全公司運作受影響。 | 增加人力資源配置及招聘計劃。 | 高 |
| 流程不明確 | 業務和技術流程未明確訂立，導致效率低下。 | 特定業務功能受到影響，例如服務穩定性。 | 建立標準化的作業流程文件及訓練計劃。 | 中 |
| 系統故障風險高 | IT系統缺乏高可用性測試，容易出現中斷問題。 | 收入損失與品牌聲譽損害。 | 加強測試機制與應急預案的制定。 | 高 |
| 溝通不良 | 團隊間合作欠佳，有些成員獨立工作無法協同效應 | 整體士氣下降，任務完成率低 | 促進內部交流會議和互動平台的建立 | 中 |
| 技術落後 | 使用過時的硬體和軟體系統，性能無法滿足需求. | 各部門效率低下、客戶體驗差. | 更新技術設備並引入新版本軟體. | 高 |
)
在進行差距分析時，通常最開始會去整理或補完那個功能模型，有些人可能會用表格來記下每一個用例。像是有一種情況，有位貨櫃裝載管理員得先確定卡車跟貨櫃的位置都沒啥問題，然後才會按下啟動鈕讓那個裝載板動起來，板子就這樣滑進車廂再自己降到大致該去的地方。還有另外一種狀況，也不算罕見，就是銀行的客戶直接用指紋登入手機銀行App。
然後啊，說到那些品質層面的東西——也就是非功能性需求啦——其實每個流程、每個步驟應該都有自己的要求。最常見的，大概就六種，雖說偶爾有人還會加點別的，比方說延展性或易用性什麼的。要舉例子的話，「容量」這項就很妙，不同系統它標準都不太一樣。像貨櫃機器，他們希望一小時能處理七八台車左右；電商網站嘛，用戶同時登入的人數可能得好幾十上百才行。
「效能」也是，每次討論總有人問，到底多快算快？比如說運貨那邊，一台貨櫃從開始到結束，大約十分鐘內要搞定；如果是登入網銀，好像三秒鐘不到吧，用戶輸入資料後也就等一下。
「可用性」這件事，有人認為只要大部分時間都能正常運作就夠了，其實標準也不是特別死板。有時候根本沒人明確講出來，只是大家心裡都有個模糊印象。不過到底要怎麼填寫這些需求，其實看場合啦，有些場合可能規範比較細，有些則隨意點……
然後啊，說到那些品質層面的東西——也就是非功能性需求啦——其實每個流程、每個步驟應該都有自己的要求。最常見的，大概就六種，雖說偶爾有人還會加點別的，比方說延展性或易用性什麼的。要舉例子的話，「容量」這項就很妙，不同系統它標準都不太一樣。像貨櫃機器，他們希望一小時能處理七八台車左右；電商網站嘛，用戶同時登入的人數可能得好幾十上百才行。
「效能」也是，每次討論總有人問，到底多快算快？比如說運貨那邊，一台貨櫃從開始到結束，大約十分鐘內要搞定；如果是登入網銀，好像三秒鐘不到吧，用戶輸入資料後也就等一下。
「可用性」這件事，有人認為只要大部分時間都能正常運作就夠了，其實標準也不是特別死板。有時候根本沒人明確講出來，只是大家心裡都有個模糊印象。不過到底要怎麼填寫這些需求，其實看場合啦，有些場合可能規範比較細，有些則隨意點……
像是工作期間，裝貨的那種機械要大致上都能隨時用得上，幾乎不太會出狀況；再說網路登入系統，大概比這個還要更可靠一點。然後，遇到節慶什麼的，貨運量會變多，好像裝櫃設備也該能處理比平常多上將近一倍的數量吧？至於購物網站，有時流量暴增，三、四倍都有可能，所以系統承載力不能太差。
安全性的話就比較複雜了。通常只有受過訓練、經過授權的人才被允許去操作那些大型裝卸機器，萬一不是合格的人亂動可麻煩。而在網路平台這邊嘛，用戶資料什麼的，一般只能由那些真的有註冊並且驗證過身份的人來存取。
至於怎麼管理這些東西呢……比如班表和設備使用，有些公司是全部集中到某個資訊系統裡面一起管。網站上的會員帳號、密碼、資料啥的，也都是透過身份和存取管理那種工具，由客服或用戶自己弄。
回頭講功能缺陷，那就挺多情況會遇到。例如有些業務流程根本沒人把它電腦化，比方說銷售獎勵沒得追蹤，那市場推廣想發力也很難。而另一類情況則是只做了一半，比如政府醫療相關資訊平台沒有完整記錄術後照護內容或統計數字，因此規劃跟預算分配自然受限，也容易超負荷。
再看品質問題，其實每個功能多少都有瓶頸。例如裝櫃機一天可以應付卡車數不多，用起來效率有限。電子商務那頭，同一時間能允許登入次數大致有個範圍，不算特別高。有時候速度也是問題，但這部分好像大家感覺最明顯……
安全性的話就比較複雜了。通常只有受過訓練、經過授權的人才被允許去操作那些大型裝卸機器，萬一不是合格的人亂動可麻煩。而在網路平台這邊嘛，用戶資料什麼的，一般只能由那些真的有註冊並且驗證過身份的人來存取。
至於怎麼管理這些東西呢……比如班表和設備使用，有些公司是全部集中到某個資訊系統裡面一起管。網站上的會員帳號、密碼、資料啥的，也都是透過身份和存取管理那種工具，由客服或用戶自己弄。
回頭講功能缺陷，那就挺多情況會遇到。例如有些業務流程根本沒人把它電腦化，比方說銷售獎勵沒得追蹤，那市場推廣想發力也很難。而另一類情況則是只做了一半，比如政府醫療相關資訊平台沒有完整記錄術後照護內容或統計數字，因此規劃跟預算分配自然受限，也容易超負荷。
再看品質問題，其實每個功能多少都有瓶頸。例如裝櫃機一天可以應付卡車數不多，用起來效率有限。電子商務那頭，同一時間能允許登入次數大致有個範圍，不算特別高。有時候速度也是問題，但這部分好像大家感覺最明顯……
)
像有時候，一個貨櫃要裝滿，大概需要十幾分鐘吧，登入系統通常也是等個幾秒，沒人會去算得太仔細。要說那種「可用性」，大致上在上班時間裡頭，貨櫃裝載機好像只有偶爾才出狀況，大部分時候都還算順利；至於登入系統就更少壞掉了，好像總是比前者更穩一點。不過這些也只是大略印象啦。
講到負載能力，每逢快到年末、節慶的時候，貨櫃裝載這邊能多扛一些，比平常多出一成有餘——但也不是無限大。電商網站的話，聽說可以應付平日流量的將近一倍半左右，但真正遇到爆單，也還是會卡住。
安全性問題呢，倒是挺妙。有些地方誰都能動，比如現場工人想開機就開機，不太管權限這回事。可是網路商城那邊，就出現過被除名的帳號還能繼續登錄的怪事，說不上來是疏忽還是哪裡沒弄好。
管理方面嘛，有的東西很隨意，就是白板上寫寫班表什麼的，也沒特別規範。用戶資料那些，在電商平台則是靠自己或客服團隊拿表格記著處理，有時候找資料還得翻一下不同頁面。
至於組織架構、分工怎麼樣，人手數量其實外人不一定搞得很清楚，只知道每個職能區域都有固定負責的人員，看起來不像有什麼明確標準，但也勉強撐住了日常運作。
講到負載能力，每逢快到年末、節慶的時候，貨櫃裝載這邊能多扛一些，比平常多出一成有餘——但也不是無限大。電商網站的話，聽說可以應付平日流量的將近一倍半左右，但真正遇到爆單，也還是會卡住。
安全性問題呢，倒是挺妙。有些地方誰都能動，比如現場工人想開機就開機，不太管權限這回事。可是網路商城那邊，就出現過被除名的帳號還能繼續登錄的怪事，說不上來是疏忽還是哪裡沒弄好。
管理方面嘛，有的東西很隨意，就是白板上寫寫班表什麼的，也沒特別規範。用戶資料那些，在電商平台則是靠自己或客服團隊拿表格記著處理，有時候找資料還得翻一下不同頁面。
至於組織架構、分工怎麼樣，人手數量其實外人不一定搞得很清楚，只知道每個職能區域都有固定負責的人員，看起來不像有什麼明確標準，但也勉強撐住了日常運作。
他們的工作量有點難說，反正最近看起來一直都沒怎麼停過，有時候可能七八成的時間都在趕進度。至於交付的速度，好像大家也習慣了那種得很快搞定、不能拖太久的節奏，不過偶爾還是有人覺得壓力大到喘不過氣。技能方面嘛，專業能力其實參差不齊，有些人訓練比較完整，但總感覺還是有幾個同事好像剛進來沒多久就被丟上陣，老鳥帶新手這種場面經常發生。
說到職涯發展，公司倒是有設計一點晉升路線，但聽說真正能往上走的人只占少數，大概只比零多一點。軟實力這塊喔，有人挺會溝通，也有人悶著頭做事；辦公設備嘛，多半用的是一些舊機型，好像只有管理層才拿得到比較新的東西。整體士氣嘛，不算高昂吧，畢竟光加班這件事就讓不少人叫苦連天。
最大的挑戰，大概就是人手明顯不夠，每次遇到突發狀況，例如臨時有人請假，那工作直接堆積下來，很容易造成產能掉了將近十分之一。有幾位同仁甚至私下聊到希望能多補點人手——但上頭似乎沒什麼動靜。
其實，如果細看組織結構，好像哪裡怪怪的，比如行銷部門根本沒有專責團隊去處理活動案子，所以營收增長一直不到預期水準。再講回基本能力，有的人硬底子知識薄弱，加上公司從沒給過什麼專業倫理訓練，再遇到文化背景差異大的情況，難免出現摩擦，小道消息說產能也因此打了折扣。
所以啊，到底哪裡卡住？感覺不是單一環節出問題，而是一堆東西疊在一起：組織鬆散，人員太少，然後又缺乏系統性的培訓和協作方式。不止一個核心職能受到波及，比如營運和對外窗口品質都受牽連，到底影響多大，其實也很難用具體數據描繪，只知道至少已經讓部分目標落空了。
說到職涯發展，公司倒是有設計一點晉升路線，但聽說真正能往上走的人只占少數，大概只比零多一點。軟實力這塊喔，有人挺會溝通，也有人悶著頭做事；辦公設備嘛，多半用的是一些舊機型，好像只有管理層才拿得到比較新的東西。整體士氣嘛，不算高昂吧，畢竟光加班這件事就讓不少人叫苦連天。
最大的挑戰，大概就是人手明顯不夠，每次遇到突發狀況，例如臨時有人請假，那工作直接堆積下來，很容易造成產能掉了將近十分之一。有幾位同仁甚至私下聊到希望能多補點人手——但上頭似乎沒什麼動靜。
其實，如果細看組織結構，好像哪裡怪怪的，比如行銷部門根本沒有專責團隊去處理活動案子，所以營收增長一直不到預期水準。再講回基本能力，有的人硬底子知識薄弱，加上公司從沒給過什麼專業倫理訓練，再遇到文化背景差異大的情況，難免出現摩擦，小道消息說產能也因此打了折扣。
所以啊，到底哪裡卡住？感覺不是單一環節出問題，而是一堆東西疊在一起：組織鬆散，人員太少，然後又缺乏系統性的培訓和協作方式。不止一個核心職能受到波及，比如營運和對外窗口品質都受牽連，到底影響多大，其實也很難用具體數據描繪，只知道至少已經讓部分目標落空了。
)
說到流程這塊，企業裡各種領域和子領域，好像都應該有一套規劃、建設、運作還有管理的方式。事實上，有些地方大致上規定得不錯，但也常常看見哪邊沒弄好。舉例來說，某些業務和技術流程好像根本沒明確訂出來——就拿IT系統的高可用性測試來說，大概從沒人固定去做這件事。這樣一來，萬一發生中斷，後果可能很嚴重，不只是收入損失，聲譽也會跟著受損。
然後有時候雖然那個什麼合規審查程序寫在文件裡，可是現場實際做的人並不常照著走。結果每次遇到法規責任才臨時抱佛腳，變成反應遲緩，也帶來不少風險吧。
而且檢查和管控機制的健全度……嗯，有的地方大概只能算是剛起步。例如新解決方案要推出時，有沒有考慮到營運部門需求？往往大家會忽略這點，所以最後服務品質下滑、變更成本也被拖高了許多。
整體來看，其實流程治理還有滿多漏洞。少部分業務功能會比較直接受到影響，例如服務穩定性或法遵能力，有時甚至牽動將近半數部門。但到底哪些環節最薄弱？實話說，有的情況很難一口咬定，只能感覺大約三成左右的細節經常卡關。至於破碎或缺漏之處，大概就是前面那些例子啦——雖然講得不是很周延，但問題總讓人覺得挺棘手的。
然後有時候雖然那個什麼合規審查程序寫在文件裡，可是現場實際做的人並不常照著走。結果每次遇到法規責任才臨時抱佛腳，變成反應遲緩，也帶來不少風險吧。
而且檢查和管控機制的健全度……嗯，有的地方大概只能算是剛起步。例如新解決方案要推出時，有沒有考慮到營運部門需求？往往大家會忽略這點，所以最後服務品質下滑、變更成本也被拖高了許多。
整體來看，其實流程治理還有滿多漏洞。少部分業務功能會比較直接受到影響，例如服務穩定性或法遵能力，有時甚至牽動將近半數部門。但到底哪些環節最薄弱？實話說，有的情況很難一口咬定，只能感覺大約三成左右的細節經常卡關。至於破碎或缺漏之處，大概就是前面那些例子啦——雖然講得不是很周延，但問題總讓人覺得挺棘手的。
科技這一塊嘛，說到底有沒有跟著業務需求走，有時候還真難說。有些系統看起來是設計過的，但到底是不是貼合實際狀況，就讓人懷疑。像安全性、靈活度這類問題，很少一次到位，總覺得有部分功能不是很夠用，也許哪裡還漏了東西。成本方面呢，偶爾會聽到有人抱怨，好像沒那麼划算。不過詳細哪個環節出狀況，每次查都有新的發現。
講到架構，有些公司用了好幾年都沒改，感覺和業界標準差距越拉越大，甚至連資料流動、系統整合都變得卡卡的。資訊架構本來應該清楚分層，但現在反而重複和相依關係太多，不知怎搞的常碰到要重工。有些地方還真的找不到專門處理大量即時客戶查詢的資料來源，所以只好一直往主CRM丟請求，結果不光是客服人員忙翻天，顧客體驗也受影響——其實每個管道都被拖慢了。
至於細部設計啦，很容易就漏掉一些小細節。舉例來說，在手機或網銀介面裡，看次要信用卡消費紀錄這種事，好像沒獨立畫面可用，用戶不方便，只能撥電話問客服。後來就造成客服中心工作量暴增，費用也跟著水漲船高。不只是單一問題，而是很多小缺口累積起來。
軟體本身更不用說了，有時候用了七八年以上完全沒換新版本，不但跑得慢，一遇上生意量突然放大或者資料保存期拉長，就撐不住。例如傳統Oracle資料庫在商業智慧查詢越做越多時，好像明顯吃力，本來幾乎沒什麼延遲，到後面要求容量和速度都愈發達不到預期，只能想別招補救……所以囉，其實各方面大大小小都有缺陷，只是哪些環節牽動最多業務功能，每次評估可能答案又不太一樣。
講到架構，有些公司用了好幾年都沒改，感覺和業界標準差距越拉越大，甚至連資料流動、系統整合都變得卡卡的。資訊架構本來應該清楚分層，但現在反而重複和相依關係太多，不知怎搞的常碰到要重工。有些地方還真的找不到專門處理大量即時客戶查詢的資料來源，所以只好一直往主CRM丟請求，結果不光是客服人員忙翻天，顧客體驗也受影響——其實每個管道都被拖慢了。
至於細部設計啦，很容易就漏掉一些小細節。舉例來說，在手機或網銀介面裡，看次要信用卡消費紀錄這種事，好像沒獨立畫面可用，用戶不方便，只能撥電話問客服。後來就造成客服中心工作量暴增，費用也跟著水漲船高。不只是單一問題，而是很多小缺口累積起來。
軟體本身更不用說了，有時候用了七八年以上完全沒換新版本，不但跑得慢，一遇上生意量突然放大或者資料保存期拉長，就撐不住。例如傳統Oracle資料庫在商業智慧查詢越做越多時，好像明顯吃力，本來幾乎沒什麼延遲，到後面要求容量和速度都愈發達不到預期，只能想別招補救……所以囉，其實各方面大大小小都有缺陷，只是哪些環節牽動最多業務功能，每次評估可能答案又不太一樣。
)
硬體這塊，好像和剛才那個狀況差不多。比如說，支撐行動應用的Oracle資料庫伺服器，大致只有需求量的一半左右，距離明年預期的流量跟延遲標準還有一大段落差。然後工具方面，好像一直沒什麼能橫跨整個業務流程監控的東西，所以遇到系統問題時，大家常常得花上不少時間才能找到癥結，服務可用性老是碰不上標準。
自動化這邊，也不是很理想。有時候關鍵程序當掉了都沒辦法自己重啟，只能靠人力去處理，那些應用程式一卡住，就會拖垮整體的容量和可用性。再講分析能力吧，目前好像也沒有什麼預警或趨勢預測的功能——像儲存空間快滿或效能下降之類，都得等事情發生才知道，不容易提前避免服務中斷。
至於安全性，有些地方真的蠻讓人擔心。舉例來說，文字聊天裡頭那些個資基本上都直接顯示出來，沒有做任何遮掩，用戶會面臨各種風險。總之，從硬體到資訊安全，每個環節多多少少都有點缺口，不太踏實。
自動化這邊，也不是很理想。有時候關鍵程序當掉了都沒辦法自己重啟，只能靠人力去處理，那些應用程式一卡住，就會拖垮整體的容量和可用性。再講分析能力吧，目前好像也沒有什麼預警或趨勢預測的功能——像儲存空間快滿或效能下降之類，都得等事情發生才知道，不容易提前避免服務中斷。
至於安全性，有些地方真的蠻讓人擔心。舉例來說，文字聊天裡頭那些個資基本上都直接顯示出來，沒有做任何遮掩，用戶會面臨各種風險。總之，從硬體到資訊安全，每個環節多多少少都有點缺口，不太踏實。
有時候把所有分析細節整理下來，也沒那麼一板一眼。大致上，我們會試著把那些功能問題、品質狀況跟它們背後的原因——像是人員層面啊、流程問題，或者某些技術上的落差——稍微串連起來。通常會給這些缺口分個大概的嚴重程度，然後再估算一下對生意可能帶來多大的衝擊。這樣一來，公司就比較容易判斷什麼該先處理。有些人愛用表格，有些就隨手寫在文件裡，各自有各自的習慣。
資料來源嘛，基本上好像也沒固定哪種最好。有人說工作坊收集回來的訊息很實用，畢竟現場大家聊到哪就補充到哪，有時候還能挖出一些平常看不到的細節。不過，一些重要資訊往往還是得靠訪談抓到，比方說問問管理階層或技術負責人，他們腦子裡總藏著不少故事。另外，有機會翻閱設計圖、架構說明書甚至設備清單，好像也多少能補充點脈絡。當然啦，報表類（不論是效能還是哪次突發事件），或操作儀表板這些地方偶爾也會掉出幾條線索，只是要自己花點力氣去拼湊。
這整套分析流程走完，其實也不是什麼終極解藥，但如果客戶突然想進一步討論怎麼解決某個痛點，好像就可以分開談了。畢竟每個問題的緊急程度都不太一樣，那個業務影響和解決成本其實挺值得比一下。如果真要做成案子，也許就按剛剛評估出來的重要性排順序，慢慢地一件件推進去。等你自己碰到類似狀況，不妨照著這種方式試試；遇到卡關，我還蠻樂意提供一些經驗分享啦。
（對了，如果你發現這篇文章特別自然，大概因為全程沒靠什麼AI軟體……）
資料來源嘛，基本上好像也沒固定哪種最好。有人說工作坊收集回來的訊息很實用，畢竟現場大家聊到哪就補充到哪，有時候還能挖出一些平常看不到的細節。不過，一些重要資訊往往還是得靠訪談抓到，比方說問問管理階層或技術負責人，他們腦子裡總藏著不少故事。另外，有機會翻閱設計圖、架構說明書甚至設備清單，好像也多少能補充點脈絡。當然啦，報表類（不論是效能還是哪次突發事件），或操作儀表板這些地方偶爾也會掉出幾條線索，只是要自己花點力氣去拼湊。
這整套分析流程走完，其實也不是什麼終極解藥，但如果客戶突然想進一步討論怎麼解決某個痛點，好像就可以分開談了。畢竟每個問題的緊急程度都不太一樣，那個業務影響和解決成本其實挺值得比一下。如果真要做成案子，也許就按剛剛評估出來的重要性排順序，慢慢地一件件推進去。等你自己碰到類似狀況，不妨照著這種方式試試；遇到卡關，我還蠻樂意提供一些經驗分享啦。
（對了，如果你發現這篇文章特別自然，大概因為全程沒靠什麼AI軟體……）
參考文章
九種突破事業瓶頸的方法(上)
陷入瓶頸時需要採取許多行動，這是很重要的道理，但我相信不只是這樣。 就像一把弓箭要先向後拉才能向前射中箭靶，我們必需要往自己的內在觀察，然後再回到軌道上。
來源： doTERRA突破職場瓶頸：掌握五力讓你無往不利
自此開啟我漫長的業務生涯，當然在後續職涯中，每一個老闆對我的驚艷印象，都是來自於上台時超乎他們預期的表現，慢慢的我才知道，每次上台就是一次表達自己的 ...
來源： Vocus
ALL
SEO 技術
相關討論