客官們，大孫女沏的熱茶可還溫暖？

這院子裡的風雖然漸漸緊了，但手裡捧著這杯溫潤慢熬的琥珀熱茶，身上就暖和了起來。這晚霞餘暉映照著晚霞暮紫的天空，小孫女這會兒正玩累了，像隻黏人的小貓一樣依偎在阿公膝頭，而懂事的大孫女貼心地搬了張矮凳坐在阿公這張老藤椅旁，手裡還拿著先前我們聊過的合規開發手記。

阿公看著這張手記，不由得摸了摸頭上的白髮銀霜，慢條斯理地笑著對大孫女說：「乖孫女，今天阿公要給你們講的，是比寫程式更考驗智慧的學問——那叫做『人的管理』與『時間的藝術』。在我們做 LCR 系統的過程中，這叫做跨部門協同的時程管理。」

Day 9：跨部門協同的時程管理：LCR 資料提供與預測的排程架構

🚨 痛點場景 —— 遲到了一人，整條船的人都得在風雨中等候

以前啊，在還沒有這套 Web 系統的時候，每到月底要產出那份攸關銀行生死存亡的「月底 LCR 預估值」時，就跟我們鄉下要辦一場全村大拜拜一樣熱鬧。

這場大拜拜需要各個單位的鼎力相助：財務部、風管部、放款、存款等各個科室的兄弟姊妹，都得把自家的數據在規定的7/27 下午 2 點前交齊。

只要大家能按時把食材送來，我們就能在 7/28 準時開爐，產出精準的預估值，呈報給經理與管理決策層，看看我們手頭的現金夠不夠應付接下來的風雨。

許多剛入行的年輕人總覺得「催收資料」是小事，但跨部門協作最難管的就是「人心」與「時間」：

• 拖延成了家常便飯：財務部可能因為當天報表卡住，風管部可能因為人員請假，只要有一家單位拖延，沒能在 7/27 準時交齊，我們 7/28 的爐子就燒不熱，根本沒辦法產出準確的月底預估。
• 高層成了睜眼瞎子：流動性管理就像是踩鋼索。如果 7/28 的預估值因為某個單位遲交而開天窗，高層主管在最關鍵的時刻就沒有準確的數據做決策。萬一這時候市場上有風吹草動，高層無法及時介入流動性決策，那後果可是不堪設想，這也是風控最害怕的惡夢。

🛠️ 架構實作 —— 規矩立在鐵板上，用系統鎖定同一天

阿公那時候就想，既然人會遲到、會犯錯，那我們就用溫暖但堅定的系統，在背後當大家的「定海神針」。在我們的 LCR 控管系統中，我們設計了三層時程與完整性校驗架構：

1. 資料基準日（Data Reference Date）一致性校驗：
   這就像阿公規定大家：「今天我們做 115/7/24 基準日的預估，所有人帶來的食材，就必須是 115/7/24 那天採集的新鮮貨。」
   以前用 Excel 往返時，常常有人拿 7/20 的舊資料，改個檔名就寄過來。現在，系統後端在接收資料時，會進行嚴格的基準日檢核。只要系統發現資料庫裡 base_date 欄位與這次任務設定的 115/7/24 不符，連存檔都不給存，直接退回並判定為異常。
2. 自動時程排程與催收機制：
   我們在系統的期別任務表 T_PERIOD_TASK 中，將截止期限 DUE_DATETIME 鎖死在 7/27 下午 2 點。
   不用再派窗口一通通打電話催了，系統（透過排程器，像是 Quartz.NET 或者是 Supabase Cron）會在截止前 N 小時，自動掃描哪些科室還在 未提供 狀態，自動發送溫馨提醒郵件。一旦過了下午 2 點，還未提交的科室狀態會自動跳轉為 逾期，並自動向資料彙整窗口與其主管發出告警通知。
3. 異常檢核清單（Exception Checklist）：
   到了 7/28 計算當天早上，資料彙整窗口一登入系統，畫面上會自動整理出一份乾乾淨淨的「異常檢核清單」。清單上明明白白記錄著哪裡有缺漏、哪裡的基準日不對、哪裡的預估假設未標記。這確保了在 7/28 計算時，所有的數據都高完整度地落在同一個基準日上，彙整窗口再也不用花大半天去手動對帳與除錯了。

💡 避坑指南 —— 金合規系統的智慧：千萬別讓完美的規矩把活人卡死

不過啊，阿公活了這大半輩子，看過太多漂亮的系統，最後都因為設計得「太死板」而被使用者聯手廢棄。

你們想想，金融合規的戰場是千變萬化的。萬一到了 7/27 下午 1 點 59 分，某個重要單位的內網突然斷線，或者是資料庫批次卡住，他們真的拿不出 115/7/24 的數據。這時候，如果你系統後端設計得一板一眼，只要缺一筆資料就拒絕彙整、拋出錯誤，那完蛋了，我們 7/28 的流動性試算程序將會徹底卡死。彙整窗口急得像熱鍋上的螞蟻，高層主管拍桌子要數據，結果全卡在系統的「完美檢核」裡。

這就是阿公要給你們的避坑指引：必須設計「暫行替代方案」（Emergency Fallback）。

在系統的資料處理邏輯中，我們要留下一個安全的「兜底路徑」：

• 自動帶入上期數據：當截止時間到了，若發生部分非核心資料缺漏，且時間萬分火急時，系統必須支援「暫行替代方案」，允許彙整窗口一鍵啟用，讓系統自動抓取該科室上一期的歷史數據進行暫時帶入。
• 打上警示標籤（Warning Flag）：但這可不能悄悄帶入。系統會自動在資料庫與唯讀儀表板上，為這筆數據打上顯眼的「警示標籤（例如：使用上期數據替代）」，並隨時準備追蹤後續補正。

這樣設計有兩個天大的好處：

1. 試算程序不卡死：7/28 依然能夠順利跑出 LCR 月底預估值，讓大局能繼續往前走，不耽誤流動性控管的黃金時間。
2. 風險可視化：當經理或高層主管在唯讀儀表板審閱報告時，一眼就能看到那個顯眼的警示標籤，他們在做決策時，自然會知道這部分存在微幅偏差風險，在評估時會更加審慎。等後來單位的真實數據補齊、通過校驗後，彙整窗口一鍵重新更新覆蓋，系統便自動恢復最精準的狀態。

這就是「前端規矩、後端通達」的合規系統設計智慧。規矩是死的，但守護資金安全的心，必須是活的。