還記得1999.12.31午夜吧!全世界有數不清的企業都當時睜大眼睛看著自家的電腦系統,應用程式是否能夠安然度過那一刻,在此之前,有多所企業花費無數人力修改了無數的程式就是為了應付這隻Millennium Bug(仟禧蟲).現在到銀行領錢填取款單,應該會注意到日期填的格式是94年xx月xx日.可預期的五年後台灣地區又會有一支佰禧蟲出現,因為幾乎大部分的金融機構的核心系統(存款,提款,放款,匯款,外幣…等)都是是採用民國日期格式.屆時,大家對付Y2K的情況又會重新演出,只是這次不是被全世界所注目,只發生在台灣...
還記得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)服務導向架構,即是業務架構與資訊架構的整合, 金融交易核心系統應用平台的建置就是需要從業務架構層面考量配合資訊架構的可行性進行整合規劃. 才能達成整體執行目的.
