昨天我們談論金流自動化的 Situation & Task，了解到既有組織在處理金流當時的情況

而團隊為了要解這個很重要的題目，整理出從組織面、部門面、資訊單位三個面向，在金流自動化中所要擔負的角色與責任

今天就來看看，團隊在實務上的作為與帶來的結果

Actions

數位轉型案中最重要的實作核心就是流程再造，走舊路不會到到新地方，新的價值呈現，只會在新的流程中發生，在這邊提供筆者團隊之前在數轉作業單位，所進行的流程再造施作方法給大家參考。
背景說明，因舊有組織各團隊嚴重缺乏管理經驗，也無現有企業願景、階段性任務、年度目標、共識 … 等相關作業流程，極度尊重傳統，現有流程已延續超過20年不變，不願意也極度抗拒轉變，更遑論創新。換個角度說，案例中的組織連現代化的結構都沒有，往正面的方向想，當下不管做什麼，都可以算開始轉了，這樣不知道是喜是悲呀... anyway，既然舊有的團隊只是靠慣性做事，那討論的方式可能需要適當的引導，新的流程才有機會發生。
以下案例中運作的方式，是因為特殊案例背景所需，原本並非應該由資訊單位人員所執行，但因為以上因素，所以在這個案例中，是由資訊單位協助各單位從日常會議，或工作坊式的討論，協助討論發生，特此說明。

1. 關鍵字收集作業

• 從各式常規會議及討論中，找出近似關鍵字歸類彙整。
• 從各級轉型專案會議中，找出關鍵字

2. 關鍵字定義對齊及重要性對焦及排序作業

• 對齊整合在程序作業中，如常規會議的進度說明，各類計劃、預算、工作排序的討論。
• 形成跨部門及跨層級概念認知的一致化，各名詞概念的定義跟假設統一，建立組織整體對話的基石。

3. 流程彙整討論

• 基於之前工程定錨定義的第一版服務功能定義，進行以下討論收斂。
• 定義主次流程（金流、捐款、支助及其他作業程序），數據資料的定義、假設跟各式數據組合的邏輯，流程定義一定要串到數據變化，不然後續討論很高機率會脫鉤。
• 定義主流程起訖邊界（Main Story boundary），各個節點（ex. Stakeholder），價值產出（ex. Report），流程結構化。
• 細分定義串起主流程的各個 User Story，釐清各種定義及假設，嘗試建立模組化作業程序。
• 盤點釐清可以進行資訊化、程序化進而自動化的 Story，必要時對現存既有流程或節點進行調整作業（ex. 所以需要配套上述客服部門主管的調整）
• 形成專案模型，進行專案所需資源評估作業，解決方案的設計（Cloud, Framework, Compliance），再進一步反覆調整，直到得出第一版可行性高的版本（開始迭代）。

4. 專案啟動

• 組織面的目標、時程、影響評估討論，獲得需要的核准跟支援，如預算，其他專案期程的調整。
• 跨部門的協調，確保因新專業影響到的日常維運作業有進行對應的處理。
• 資訊部門內部的對應調整程序。
• 因為之前有進行專案盤點，這邊會有些資料可以讓專案有明確的討論跟優先順序的聚焦。
  • 該組織年度捐款約有48%來自信用卡定期扣款。
  • 該組織年度捐款約有6%來自線上網站（上下浮動端看該年有多少需要幫助的案件發生）。
  • 各式定期捐款（Bar Code and Bank Code）約有 28%。
  • 需要手動從各單位後台下載會入，但格式相對穩定的（如：Line_Pay），約3%。
  • 以上 85% 主要是因為格式跟流程處理程序可預期，所以列入第一階段自動化效益比較大的工程改善重點。
  • 餘15%列入下一階段討論（不在 Version One scope 中）。
• 如上所述，答案不是零跟一，我們定義整理了整個流程，約有85%完成自動化，客服單位因電子化作業程序及此金流自動化作業，組織對應減少了約10個人力（以當時他們的成本分析，這樣一年省了800多萬，加上 Legacy CRM 那邊的一年維運服務費用 150 萬，這兩個案子每年省了一千多萬的營運成本，同時間也解決上述的問題，將原先季度或月週期解決才可以解決的問題，改善到每週狀況盤點控制，資金風險調控的穩定性大大提升）。

在前面定義好專案目標、資源、價值影響範圍跟時程後，以下進行解決方案模組化設計（哪些是全自動化，哪些是半自動化，這兩項的定義，跟模組設計的邏輯要定義清楚）。

• 全自動化流程
  • 整合第三方交易解決方案，將日常線上匯款的彙整週期從月報改善到日報。
  • 全自動化流程對應的監控大幅改善原先人工對帳程序的效率，將每月約7%錯帳率降低到年度錯帳率1%以下。
  • 跟外部金融單位的資料交換作業，自動化後大幅改善穩定度，讓每年都會發生的人為失誤造成的資料延誤事件降到零。
• 半自動化流程
  • 系統自動完成相關程序，但因各個金融單位系統支援程度的關係，有部分資料交換需從後台下載匯入，這部分輔以系統定期自動查核（上傳的資料格式，上傳的資料對比過去是否有異常的風險），提醒作業（如時間到，貓主子要提醒貓奴備餐了，員工該去查資料是否需要下載處理了），服務正常性監控程序(ex. 每月該匯入的金額是否有發生)，以確保將人工部分降到最低，並確保配套流程有正常發生。
• 人工作業流程
  • 將人工作業輔以服務正常性監控程序，以確保人工配套流程有正確施行。
• 數據清洗及標準化作業
  • 在上述異動進行時，同步加上數據資料的正確性檢查。
• 數據資安解決方案施作
  • 資料加密、資料遮罩、資料調用標準作業程序（如資料不落地，所以不提供全數據後台下載功能，防止數據不當使用，一次查詢不可超過20筆，批次作業應歸屬在另外批次作業程序中而非日常操作的功能集）。

在上述的金流自動化專案中，該模組也是更大系統的子系統，是整個網站再造的一部分，在這次的數位轉型專案中，筆者團隊的做法是希望能做到開飛機換引擎，前置作業除了定錨中說的，定義版本，配套的監控跟備份可以上線，另外也可以讓後續要 revamp 的整體解決方案，可以有從子系統抽換，收斂，一步步把整個網站換掉的機會，不然一次性把所有東西換掉的風險太大了，該組織連既有的流程都說不清，一次到位可能不太實際，系統大型異動如果造成數據資料出錯，那處理起來的麻煩度就不是只是服務受影響而已。

所以在專案的盤點、定義、跟假設釐清後，會先對工程的作業流程先進行第一步的處理，讓後續的改造可以一步步落地。

Result

後續的驗收，如前述所言，很多角色在老舊組織內是不存在的，如專案經理（Project Manager）還有產品經理（Product manager），角色不存在通常代表的就是這個組織同時間並不具備對應的能力，產品思維的缺乏，也可以得知在目前這個數位時代，這個組織沒有連結線上線下的節點。所以服務上架驗收的部分，也是以引導的方式，同步完成以下程序，完成驗收程序，並建立起新服務迭代的基礎

1. 一方面新服務開發時，以 Agile/Scrum/Sprint 的框架，在每個 sprint review meeting 時，同步引導使用者對焦需求，定義功能，確認產出，以確保服務有完成專案定義的價值產出，可以順利以新流程取代舊有流程，這也是整個組織流程再造(process re-engineering)計畫的一部分。

2. 一方面持續提供教育訓練，形成新的組織肌肉記憶，完成概念置換，否則舊有組織因為慣性，不管新系統、服務、功能多有效率，老舊組織的既得利益者，是怎麼看都不會順眼的，也就沒有所謂順利驗收，服務上線這件事了。

3. 有個很重要的提醒，IT 是實作單位，上述的每一個步驟都需要導向業務單位自己測試、驗收，然後針對測試結果與驗收都要畫押，不是只有 IT 自己認為可以就可以。不然很奇妙的是往往最後只有 IT 還記得做什麼，業務單位否認當時提的需求的狀況也不少見。所以如果業務單位有在 Ticket 從需求、測試、驗收都有畫押，至少吵起架 IT 還是有底氣的 XD。但是後續是不是沒事，大家要自我評估喔，就像近日三宅一生之一袋超人事件，超人能不能全身而退都不知道說）