前一個 Section ，我們談論了轉型在實作時應該要有的各種面相有哪些，
藉由每個面向的堆疊，才能確保團隊的產出、才能確保在進行轉型時，不會把系統越轉越壞。

今天我們要來談很重要的議題「金流」，這也是團隊當時第一個進行的挑戰，
就讓我們來看看有關金流這個大項目在當時的組織有什麼狀況吧~

Situation

數位轉型前，金流每月定期作業有大量的半自動、手動、測試型作業（就是跑跑看，有出來就算賺到）及紙本作業，資料的驗證靠人工加上Excel（還有實體放大鏡，我沒開玩笑），就是沒有靠程式進行自動化程序，基本邏輯是，電腦出資料，剩下靠人工，跟數轉後的邏輯，電腦負責出資料、檢查，異常時人工才介入處理的作業模式剛好是顛倒的，以下是狀況說明。

1. 雖然有系統，但破碎化的系統現況導致自動化程序涵蓋率為0%。
2. 沒有標準作業程序及文件確保每月金流彙整程序的正確率，完全依賴人工經驗，程序錯誤率超過25%(每年12次有3次以上錯誤)。
3. 高度依賴人工作業及高度錯帳率的現況，現況解決模式是不斷地增加人力，用人力協助人力以期改善現況，但又因前述沒有標準作業程序及文件的關係，導致錯誤率沒有改善，反倒節節升高的惡性循環。
4. 年度系統需處理金額約為30億，各個捐款管道（超過20種），因人工作業高度客製化（缺乏系統外，各個流程除了起點跟彙整的終點，中間缺乏階段性彙整及驗證的節點），導致每月各部門彙整方式已經高度錯亂，手動異動報表資料已是常態，因手動異動資料錯誤，需要錯帳矯正程序介入調整也變成常態，每月會整程序已經從過去的須在三工作天內完成，到超過一週才能完成，錯誤率超過25%(前述每年12次有3次以上錯誤)，因高度錯誤率，導致需要建立新的錯帳矯正程序協助處理，新的惡性循環導致低效流程再度惡化，同時間，也造成某些員工因為有處理異常的經驗，所以他的工作也被調整，影響到原先的作業程序，進一步的惡性循環。
5. 因系統設計問題，每月需要彙整的資料越來越大（資料無預先處理，無效資料拖累系統），超過系統預設設計限制（檔案及記憶體大小限制），導致系統程序無法完成，需要手動介入處理進行暫時性調整，暫時性讓資料可以產出（無正確率保證），但同時又因缺乏系統冪等性設計(Idempotency Design)，預設每次跑都會成功，沒考慮需要重跑的狀況，不管是在單次處理的 error handling，或是整道程序的 error handling，都沒有進行必要的處理，所以人工處理的介入已經是常態需求。
6. 如前幾篇所述，原生的工程團隊不具備軟體工程基礎知識，導致無內部開發能力，也無系統設計能力，就算進行外包，也無有效評估、簽約、外包、協作、驗收及後續維運的工程專業，導致系統品質低劣，遇到異常也無能力處理，連基本判斷都無法做到，只能變成外包商（外包傷）的提款機。
7. 外包商（外包傷）的品質問題，台灣本土外包商人員異動頻繁，同因上述無有效系統驗收、文件及互動協作模式（如：Ticket tracking），導致系統問題無法有效解決（挖東墻補西牆，改這次的問題，上次的問題又跑出來），極度仰賴人工處理（廠商人工介入要收費，又導致額外的成本發生）。
8. 外包商（外包傷）的品質問題，國際外包商也同因人員異動頻繁，導致系統維運支援合約形同虛設，從無法進行系統功能開發，到緊急事件處理（前述因資料過大無法處理的問題）無法在合約討論的時效內完成（8小時 workaround，24小時 root cause fixed），到事件處理錯誤導致更大的問題發生（誤刪加密金鑰導致程序失效，進一步擴大問題），到年度維運無法提供報表說明所需的系統更新及調整程序是否已經完成有效處理，每年150萬的維護合約形同虛設。
9. 對應的系統平台，也同因原先的工程團隊缺乏對應的工程知識，外包商品質問題，有高度數位營運韌性及資安風險（高度尊重Windows原創性，系統沒有進行維運及資安評估進行必要的更新及升級超過15年），系統也無法確保重開機可以重回正確運行狀態（外包商也不敢保證）。
10. 軟硬體資產盤點失效，無法確保系統運作正確所需的資源，可以在正確的時間點，進行正確的系統支援，產生正確的數據產出。

Tasks

本案採取的問題分析模型預設以組織，部門及資訊單位角度切入(目標，指標)：

1. 組織面的預期產出及風險考量（ex.每月收入報表、提供正確的捐款互動資料、避免資安風險）。
2. 部門面，每個月資料流各個節點產出的deadline確保，讓整體工作流程順利遂行，各部門擁有支援各自環節程序遂行的知識及文件，並確保其有效性及效率（不要10個人做2個人就可以做到的事情，照經驗這樣不會比較好，只會比較差）。
3. 資訊單位，確保支援程序遂行所需的軟硬體運作正常，有問題時可以在規劃的時間內完成必要的矯正程序，並進行有效迭代，改善系統，以智能化自動程序取代人工作業。

除問題分析模型預設角度，系統瓶頸分析將同步帶入角色、流程及工具考量（改善節點）：

1. 組織面
   • 該流程的總責單位為何，如何進行時效內產出及驗收結果確保 。
     • 報表的正確性到底是客服部門負責還是財務部門負責？這報表程式是跑到客服部門定義的即可，還是要串到財務部都正確才是正確的？最後產出報表的結果解釋跟正確性應該是誰來解釋？這程序如果是發生異常或需要異動是要客服單位還是財務部負責？
     • 每個月互推都沒有結果不覺得累嗎？這也是呼應之前為什麼要進行工程定錨（Version One 到底是指什麼？），這東西沒有定義，每次有問題都會吵一次，然後沒結論就下班，有空再吵，但是沒有人要當責解決問題（就算到最大那個也是打回去要他們給答案，無窮迴圈，可是資料有時間性，所以工程若不想老是背鍋，請一定要定義好你現在的服務範圍跟版本）。
2. 部門面
   • 部門內階段流程的負責人為何，如何進行時效內產出及驗收結果確保。
     • 目前報表定義的是客服部門當責，但當責的經理對內容不熟，流程不熟，該角色失效，對要做什麼跟怎麼做都不知道，對應的單位主管也不清楚，只好上報到副總，請副總協調處理，不然每月定義都不一樣，工程只是背鍋。
     • 當責業務部門沒有對應專業知識，有問題最後只是推給資訊單位系統，問要怎麼修正符合該部門預期都說不出來，這個部門及主管的角色功能是什麼？需進一步釐清。
3. 資訊單位
   • 各流程支援所需的軟硬體環境負責人為何，如何進行系統環境預確認，產出程序正確執行及故障排除，及相關的產出結果驗收確保。
     • 無所需對應支援知識的工程師（原先工程單位沒有工程師，都是人形立牌），需另外定義安排。
   • 如何進行對應的常態性查核及優化程序。
     • 無所需對應支援知識的工程師（原先工程單位沒有工程師，都是臨演），需另外定義安排。