【前言 - 解決對的問題遠比解決問題重要】
工作總是永無止盡，時間卻總是稍縱即逝嗎？ ⏰ 解決問題其實很容易，但是解決對的問題很困難，尤其是找到痛點對症下藥。今年，當我正在規劃我下半年的專案和目標時，我採取了這五個步驟來幫助我理清邏輯：
首先，問對「為什麼」，搞清楚問題的本質，你才不會走錯方向
接著從解決「什麼」問題開始思考，搞清楚問題比一頭熱的解決問題重要
第三，找出「如何」解決的方法，方法百百種，選擇有效的方式來加速你達成目標
想清楚「何時」完成，專案不可能遙遙無期，有了時間的壓力才能有始有終
最後，想好「誰」會參與這個進程，掌握利害關係人，排除那些執行上的障礙
如果你也覺得每每工作讓你感到無力 🤦♂️，好像都在瞎忙，不如退一步思考，先想清楚你想解決「什麼」，再來考慮「如何」解決。慢慢想，比較快。
【正文 - 五個步驟定義並解決對的問題】
所以到底問題是什麼？
「所以到底問題是什麼？」我的主管又再問了一次。又到了一年一度的規劃季節，當我們正在如火如荼的規劃下半年度的策略時，主管在策略規劃的最後一天再次確認大家了解問題的方向。我想起了去年我是如何從無經驗到現在學會如何做策略規劃。我覺得在規劃專案的時候最困難的是找出那些最值得解決的問題，對症下藥。因為很多時候我們可能一頭熱想解決問題，可是卻沒有想過這個問題解決後是否能等帶來回報。後來我歸納了五個步驟，來幫我釐清商業思維，迅速並準確的找出流程上的痛點建立我的 OKR（Objective & key result）。
首先，問對為什麼
在上班的時候你可能會常常覺得，這個流程好像怪怪的，為什麼特別慢？為什麼這個不可以這樣做？為什麼用其他方法會造成影響？為什麼大家習慣這種做法？
這些細微的觀察和不經意的感覺其實都是引導你去找出問題。所以第一步永遠是問清楚為什麼，進而得出那個可能造成公司影響的假設，不管今天你觀察到的是價格、營運、團隊或是流程的問題。
舉例來說，公司的顧客滿意度好像比上個月還低，到底是為什麼呢？這背後可能有無數的原因，但是只要透過 5 問的方式（5 Why），你可以用階梯式的思考方法來抵達那個可能的問題假設。
a）我們的顧客滿意度比上個月低，為什麼？
b）我們發現自動化功能的顧客滿意度比人工回答的滿意度還低，為什麼？
c）原來自動化功能的某項回覆不符合我們的 SOP，為什麼？
d）在設計自動化迴路的時候工程部門並沒有討論到這個細節，為什麼？
e）因為產品規格是由工程部門設計，但是並沒有在早期設計時納入真人客服考量
接著，從解決什麼問題開始思考
當你觀察到了痛點之後，你可以很清楚的知道問題是什麼（What），那便是在產品設計的初期我們並未涵蓋全面的產品探討，只單一從某個角度切入用戶體驗，所以沒有包含到邏輯上可能會和非自動化功能衝突。這邊的 What 必須要向外延伸出商業上的價值或損失，這樣我們才能夠量化這個解決的問題能夠帶來什麼好處。
因為沒有在早期設計時納入真人客服考量，導致自動化功能推出時顧客不能理解為什麼自動化功能給出來的答案和真人給的答案不同，進而造成了顧客滿意度下降 30%，並且造成客人流失率增加了 1%。
所以如果能夠在產品設計初期就互相討論好這樣的產品可能對一線客服人員帶來什麼影響，那麼我們就可以透過改善顧客體驗，挽救流失的客人。
[⚠️小技巧] 找出那個因果關係很重要，並且用「因為 → 所以 → 造成什麼影響」的思考流程慢慢找出你要解決什麼問題。一個線性並且有因果關係的思考模式才能夠幫助你對症下藥。
第三步，找出如何解決問題的辦法
當我們找出要解決的問題後便可以著手去思考解決辦法。這邊值得注意的是通常定義出來的問題都是既定的事實，是經過驗證且客觀的。而解決辦法不一定有標準答案，可以是有創意的，可以是主觀的。
舉例來說，客觀的事實指出因為自動化功能迴路設定上的不一致導致顧客滿意度下降 30%。主觀的解決辦法可以是：
a）我們透過更動人工客訴處理的 SOP 來和自動化功能接軌
b）我們也可以修改自動化功能的設計然後和人工處理流程接軌
c）或者，我們可以直接關閉自動化的功能，讓研發部門重新設計直到準備好再重啟功能
這邊我們會發現，其實不同的方法都可以帶來想要的結果（贏回顧客滿意度），可是所需要的資源和預算可能不同。所以如何權衡利益做出好的決定就是一種藝術。
最後我們可能會選定那個最划算的方案，透過改動人工客服的處理方式和自動化功能接軌，讓顧客慢慢習慣自動化客服的模式，來提升滿意度。
記得要回頭去驗證一下你的 How 有沒有辦法解決一開始假設的 What，透過環環相扣的邏輯來想清楚這個真的是解決辦法嗎？所以整合問題和解決辦法之後我們可以得出以下結論：
為什麼我們的顧客滿意度下降（Why）
因為產品規格是由工程部門設計，但是並沒有在早期設計時納入真人客服考量，導致了顧客滿意度下降 30%，並且造成客人流失率增加了 1%（What）
為了改善問題，我們透過更動人工客訴處理的 SOP 來和自動化功能接軌（How）
[⚠️小技巧] 愈是複雜的問題愈需要時間和規劃才能解決，如果問題沒辦法即時解決，建議把他拆解成小項目。想要改善 SOP 的不一致，我們可以把他拆解成 a）找出不一致的地方 b）優化流程 c）執行更動，包含清理檔案、員工教育等等
想清楚何時完成
在資源和時間有限的情況下，如何有效率的解決問題更顯得重要。所以在想出問題和解決辦法的時候，我們就必須先考慮到有始有終，什麼時候開始執行以及什麼時候結束。最重要的是把每個大目標拆解成小項目，變成階段性的里程碑，這樣你才能確保進度有推進然後可以不斷檢視階段性的成果是否有達標。
延續上一個步驟所提到的如何解決問題（How），我們把他拆解成三個里程碑去慢慢達標：
找出目前 SOP 不一致、邏輯互斥的地方，假設我的 SOP 檔案有 40 頁，而審視完的成果（deliverable）可能就是找出前三名邏輯互斥的地方
優化那個最常見的流程，把他修改成使用者經驗和自動化系統是一致的，並且有驗證過結果，所以成果就是被品質檢查（quality audit）過新版本的 SOP
最後把新版的 SOP 更新到所有的內部檔案，改動相關的回覆訊息，以及教育第一線的客服人員來完成這次的專案
每一個項目的工作再依序安排需要多少時間消化，進而排出甘特圖。讓專案項目呈現瀑布式的安排以列出哪邊執行上可能會有相依性（不執行會導致下一個項目卡關），這樣就能推估專案可能需要執行兩個月。
最後，想好誰會參與
多數的時候我們不可能單槍匹馬，在職場上一定會需要團隊合作。專案通常會必須要和其他部門協作。所以，如何知道你的利害關係人是誰，知道這個專案對他們有什麼影響，甚至知道他們會負責什麼項目決定專案的成敗。
舉上面的例子，假設我們斷定整個專案必須要：
a）找出 SOP 不一致的地方
b）優化常見流程
c）QA 重新設計過的流程
d）管理 SOP 歸檔
e）員工訓練
f）回測結果
然後需要參與的部門包含：
a）工程部門
b）營運部門
c）客服部門
這樣我們就可以把他呈現成一個 7 x 3 的表格，並且透過 RACI 模組來判斷誰應該作為哪個項目的負責人、執行該項目的細節、誰需要被諮詢以及誰應該被知會（如下圖）。
（RACI 分工架構，R - 執行者；A - 負責人；C - 諮詢；I - 知會）
這樣你就可以很清楚的知道工程部門應該在重新設計 SOP 時被諮詢，負責 QA。而營運部門可能會在乎 SOP 設計的客戶體驗，然後會想知道回測結果如何。
[⚠️小技巧] 通常你在乎的 KPI 不代表別人也在乎。如果你能找出雙贏的局面，便能夠輕鬆達成共識。例如，我改善顧客滿意度的同時營運部門贏回顧客留存率，這樣才能有共通語言。
【結語 - 所以我們解決對的問題了嗎？】
現在我們從頭來檢視一開始找出來的問題以及我們所決定的解決辦法，用 5W1H 來看：
Why - 為什麼顧客滿意度下降？因為產品規格雖然由工程部門設計，但是並沒有在早期設計時納入真人客服考量。
What & where - 導致自動化功能推出時顧客不能理解為什麼自動化功能給出來的答案和真人客服不同，進而造成了顧客滿意度下降 30%。
How - 為了改善問題，我們透過更動人工客訴處理的 SOP 來和自動化功能接軌。
When - 如果要優化流程、員工訓練前前後後專案可能需要執行兩個月。
Who - 整個專案會涵蓋工程部門，營運部門以及客服部門的分工合作
簡單來說，為了解決客訴回覆不一致而下降的顧客滿意度（Problem），我們決定優化一線客服 SOP 和自動化接軌（Objective），期望的結果是一致的顧客體驗，改善顧客滿意度（Key result）。
[⛔ 千萬不要這樣做] 很多人被常常會被主管問的一個問題是「所以我們怎麼定義成功，如何測量？KPI 是什麼？」所以會下意識的從想要追蹤的 KPI 來開始思考流程。
*請不要從 KPI 開始想問題和解決辦法！
*請不要從 KPI 開始想問題和解決辦法！
*請不要從 KPI 開始想問題和解決辦法！
因為很重要，所以講三次。這種先射箭後畫靶的心態會限縮你的想法，讓你看不到問題的全貌，最後沒辦法用有邏輯的方式呈現問題。而且因為有太多問題會引導到該 KPI 的結果，搞到後來全部都是問題，不知道該從何著手。
總結來說，想要解決問題很容易，只要有那個預算和時間，誰都可以解決問題。可是想要解決對的問題很困難，因為你必須先想清楚問題的本質，驗證問題的癥結點，然後想出來最佳的解決辦法。如果你總是覺得為什麼做完的專案都沒有成果，好像都沒辦法達成目標。不如退一步思考，想清楚你的問題是什麼（What）再去想怎麼解決問題（How），這樣你可以比較輕易的找出痛點然後釐清 OKR，好讓你有效率的解決對的問題。點擊此連結免費下載「手把手一頁式專案章程教學」幫你定義、解決問題。
Comments