GSS 特別企劃

Special Coverage

「34號公報」放款及應收款減損評估系統建置經驗談

撰稿 | 叡揚資訊 金融業服務一部 經理 凃凃涂里俐

話說34號公報第三版¬修正案，於今（100）年

1月1日正式上路，國內金融單位不管是由內

部自行開發系統或者委外由廠商負責開發建置，此

專案都是屬於相當具有挑戰性的專案，再加上實務

面臨的各種繁雜事項與充滿未定案卻箭在弦上的情

境，如何在種種不友善於專案管理的因素環境下，

仍能克服萬難，以確保透過系統及時產製減損評估

結果，確實是非常需要參與的各方團隊運用智慧和

充分合作。

本篇經驗分享擬以本專案較為特殊的幾點面向

來談談相關注意事項，再以專案時間軸配上相關組

織來看看本案各種值得記憶的軌跡。

1.時程壓力：

來自內部外部單位對於專案上線使用的時程壓力，

迫使各階段之工作時間不夠，除了需要在已明確的

情況下排妥工作加緊趕工之外，如何在有限的工作

期間內達成有效且正確的決議，更是影響成果的重

要關鍵。

2.整合性專案挑戰性高：

面臨的業管單位與使用者人數繁多，專案主辦單位

與負責人需要跨部門協調與處理事務眾多，除了需

要溝通協調能力與專案管理技巧外，需要主管給予

授權和最大的支持。

3.系統資料來源廣泛品質要求高：

本案需要資料來源用以進行減損評估（例如減損評

估和利息收入認列）與計算各項歷史樣本機率（例

如逾期發生率與歷史回收率），涵蓋眾多金融商品

與業務，主要在於放款與債權相關業務資料源之提

供，牽涉各個不同系統之當期與歷史資料蒐集，連

動需要不同業務負責人員之全力配合，因此，非常

需要強有力且有實務經驗的單位人員統籌資料源的

內容與掌握其品質，方能確保所提供之資料足以符

合公報之規範定義和系統計算所需，並在實際執行

傳檔時點和檔案內容之掌握度和穩定度良好，不至

於延誤傳檔後相關計算步驟之系統執行步驟與人為

管控覆核等作業，才能確保減損計算之運算與報表

產製時效。

4.顧問方法論之引進和知識傳承：

引進顧問公司之方法論和相關諮詢意見後，如何藉

由專案期間和顧問的互動討論過程中，將方法論以

及相關內容和細節等知識，在組織內部相關權責單

位與人員(或更多更多)留下記憶並培養專家與傳承

寶貴知識。

起案規劃期

若以建置案的企業方而言，本專案屬於整合性

專案，牽涉業務與管理單位較多，在銀行業比如法

金、個金、信用卡業務單位，總行單位如財務部或

會計部、債權管理部、風險管理部等處部單位，在

保險業比如放款部與保服單位，尤其是主要資料源

提供之資訊單位，雖然涉及業務範圍廣及相關權責

單位多，卻更需要授權與責成由某個主要單位負全

責並統籌主辦本案，以利協調相關單位與迅速達成

決策以利專案推展和時程掌控。

若內部已確定本專案委外由顧問與資訊廠商建

置，首要重點工作會是選擇優秀且可靠的顧問公司

與資訊系統商，定案後將組成多方共同攜手合作之

34

1

專案組織以爭取時效，共同建構系統。

專案與系統建置初期

專案初期的重點往往會鎖定在如何讓專案之相

關建置項目符合34號公報之精神與規範，這部分非

常需要顧問公司與顧問人士提供公報的與規範和處

理原則等諮詢，更需要有經驗的顧問直接對於客戶

面臨的各類實務情境會同相關業管單位諮商並提出

解決方案建議，並依據此共同確認之方法論建構減

損評估資訊系統。

此外，委由顧問公司或顧問人士制訂的方法

論，如何和財務會計單位及簽證會計師將34號公報

有關的會計處理原則相互取得共識，在專案進行初

期亦需兼顧上下游關聯以免後續各項方法論和系統

處理方式已定案卻未獲得會計師與會計單位之認同

而衍生變動因素。

減損評估資訊系統之核心在於各項減損計算，

搭配顧問之理論基礎和方法，需要客戶方提供每月

減損評估基準月份之當期資料源以及計算回收率發

生率之歷史樣本資料，這些應提供資料的內容欄位

和更關鍵的資料定義，都需要在建置初期共同確認

定案，以便資料提供單位（資訊單位或前端系統相

關廠商），提早因應與準備相關程式之開發測試。

此外，當然也涵蓋了一般資訊系統建置所需的

系統功能需求規格之討論和確認等相關工作。

專案與系統建置中期

系統建置開發期間，除了資訊廠商的系統開發

過程之進度回報與掌控，本系統的源頭來自於各相

關系統的資料內容，主要包括放款和應收款明細及

歷史資料的提供，資料源涉及業務之廣泛比如說授

信放款業務法金/個金、會計帳務、催收債協系統，

除了當期資料還有歷史樣本資料亦需要從各種管道

(例如資料倉儲，彙總性分析資料庫，甚至倒回歷史

資料磁帶重新執行後產生所需要的歷史資料。這些

相關單位人員之搭配和進展，也需費神地掌握。

透過進度回報與專案會議確實掌握相關單位之

系統與程式開發進度，系統與程式發展後之初期單

元測試當然由各開發單位自行管控，需要注意的是

上下游的串連介接，例如交換資料之細部格式與初

期驗測，搭配測試之環境準備等等。

專案與系統建置後期（測試驗證上線）

本案最終成果在於減損計算結果與利息收

入認列攤銷，計算成果之正確性驗證方法和過程

尤其重要，並且優先程度明顯高於相關的系統操作

畫面之驗測。當然，系統全部資料與案例繁多，資

料驗證這部份就需要顧問提供有效的驗證方法和程

序，及搭配系統運算資訊佐證說明和數值實際驗

算，也需要反覆使用多期資訊進行實際試跑和執行

（例如2~3個月之資料進行實測和平行作業）。

這段驗證過程中，往往需要在驗證資料時面

臨從計算結果往回頭追查的步驟，方能釐清驗證資

料所碰到的疑問是屬於計算程式問題、規則定義問

題、或者追查至資料源頭的內容問題，從前頭資料

提供至計算結果後頭，來來回回轉檔計算查驗結果

反覆數次，進而逐一釐清所有資料驗證階段之狀

況，這個過程也正考驗整體專案團隊之耐心和毅

力。而也正因為如此不容易與繁瑣，每當確認驗證

結果無誤，都能讓整個團隊人員大大鬆口氣，並鼓

掌歡呼。

其他如系統操作功能之使用者驗測和教育訓練

等相關工作，就如一般應用系統專案之管理過程。

未來維運與展望

系統上線後維運，除了定期作業之正常運

作（例如每月計算、每季報表），如何逐步從顧問

及資訊系統商順暢接手維運，如何將相關定義和規

則等重點內容留下記憶，以作為後續業務與規範變

動時之因應，也都是重要課題。此外，已有減損評

估系統，相信將是未來與IFRS接軌的重要基礎甚至

成為計算平台，借由本系統之良好基礎而能更順利

擴充。

34

34

34

34

2