2005/07/28

銀行核心系統專題：送走仟禧蟲，迎接佰禧蟲！

IDC資深分析師：曹永暉

還記得1999.12.31午夜，全世界有數不清的企業當時都睜大眼睛盯著自家的電腦系統、應用程式是否能夠安然度過那一刻！在此之前，有多所企業花費無數人力修改了無數的程式就是為了應付這隻Millennium Bug(仟禧蟲)。現在到銀行領錢填取款單，應該會注意到日期的填寫格式是94年xx月xx日；可預期是的五年後台灣地區又會有一支佰禧蟲出現，因為幾乎大部分金融機構的核心系統(存款、提款、放款、匯款、外幣…等)都是採用民國日期格式。屆時，大家對付Y2K的情況又將重演，只是這次不是被全世界所注目，只發生在台灣。

目前超過8成的金融機構核心系統是由COBOL程式語言所撰寫，COBOL已有數十年的歷史，由於它並不是物件導向(Object-Oriented)，因此每一支程式幾乎都是一個獨立的個體。由程式開發的觀點，不管是對付仟禧蟲或佰禧蟲，程式修改並不複雜，然而複雜的是因為每家銀行的交易程式約從數百到上千支不等，因此更改這些老舊的銀行核心系統應用程式，可是非常大的工程：單從找出哪些與日期相關的程式，經過修改、測試、上線，至少也要耗費一年以上的時間。

老舊的銀行核心系統應用程式最為人所詬病即是資訊人員無法滿足業務單位推廣業務的時效性需求。目前大部分資訊人員對銀行新業務功能的程式開發大都採用 “複製、修改” 的方式，所謂複製修改方式即是複製一支 (可能是一批程式) 與此業務相關程式，經過修改成符合新業務需求後，放置於交易平台上線執行；如此它又是一支單獨全新的交易應用程式。可想而知，如果一個銀行的金融交易系統應用平台在用了10年或20年後，各式各樣的業務交易應用程式便層層地疊上，而這10年或20年間可能換了多少個程式開發人員，更使得留下的文件非常地有限；時至今日，這個銀行的金融交易系統應用平台將會有何等龐雜。銀行除了要不斷提昇主機CPU效能 (要越來越多的MIPS (Million Instructions Per Second) 、增加記憶體空間之外，更要耗費越來越多的人力來維護這些交易系統應用程式，而這些都將成為銀行的經營成本。

近年來，隨著金控的成立促使銀行的合併及各式金融業務的整合，也因此漸漸地帶動新一代銀行核心系統的需求，將朝向開放式架構、模組化的設計觀念，主要的目的即是讓銀行的資訊系統可以滿足越來越多樣化的銀行業務，同時還必須講求時效性。根據IDC報告指出，由於目前金融業務的複雜性，使得銀行替換核心系統，主要驅動力來自下列幾點：

1. 銀行核心業務成為新焦點
   隨著資本市場的毛利率降低，大部分銀行已回歸至銀行核心業務，因此相關業務之資訊系統也順勢成為焦點。
2. 降低操作風險
   傳統系統的維護風險將越來越高，且運作成本也將相對較高。銀行內部人員技術的傳承也是另一個問題。
3. 簡化銀行合併後的系統整合
   根據目前國內一些銀行合併的案例，都是採用某一方的系統進行整合，而結果通常只能短期地滿足客戶帳戶資料整合的需求；在某些金控案例中，並無法滿足所有金融業務的整合。採取新核心系統將可解決並簡化銀行合併後的業務及系統整合。
4. 強化並著重客戶服務
   以往的系統多是以產品導向為主，不能協助銀行整合客戶資料庫進行相關的行銷活動。新架構應能分析客戶導向，主動提供客戶更客製化的服務與資訊。
5. 增加業務涵蓋範圍
   銀行業務越來越多樣化，將越依賴相對應的資訊系統來輔助其業務自動化的需求，惟有透過新核心系統的架構，才能大幅擴展涵蓋的業務範圍，進而縮短未來銀行新產品業務的上市時間。
6. 迎合相關法令需求
   新核心系統應能提供更完整及更透明化的報表資訊，符合相關法令需求，如Basel II、金監會相關法令等。

最近隨著少數銀行的核心系統轉換成功 (也有失敗的案例)，越來越多的銀行(包括大型金控)也漸漸著手評估其新一代的核心系統。從系統的複雜度看來，金融交易核心系統應用平台已經不是可以用單純的”客製化”方式來建置完成，因此有越來越多的國外核心系統專業資訊廠商進駐台灣，期望藉由引進國外銀行成功建置的經驗，並與國內資訊服務廠商合作建置。此外，大部分的資訊廠商也開始大力的推動所謂SOA (Services Oriented Architecture) 服務導向架構，即是業務架構與資訊架構的整合。金融交易核心系統應用平台的建置就是需要從業務架構層面考量，再配合資訊架構的可行性進行整合規劃，才能達成整體執行目的。