BankingIT討論區

By tomhsi , 21 June 2010

銀行界一窩瘋的"慾"建大陸核心系統的同時 , 卻忽略了ECFA 簽訂的本意: " 需要保護的產業即為弱勢無競爭力之產業 "

ECFA 內容越多 , 內心擔憂越多 !! 翻開華一 銀行史 , 實在難以理解 台資銀行初期何以要投入如此巨大之資訊預算 , 畢竟對大陸來說 , 金融開放越多越好 , 因為有誰會拒絕錢來投資呢 ??

1997 華一銀行在上海浦東陸家嘴金融中心成立
2002 股本金由 5 千萬增至 1 億美元。
核準經營全面外匯業務及規定項下的人民幣業務
2003華一銀行上海虹橋支行正式開業
華一銀行蘇州分行獲准籌設
2004華一銀行上海徐匯支行正式開業
華一銀行深圳分行獲准籌設
2005 拿到中國保險監督管理委員會頒發的保險兼業代理許可證
2006 華一銀行上海嘉定支行正式開業
2007 增資至11億元人民幣
核准經營對除中國境內公民以外客戶的人民幣業務
核准開辦衍生產品交易業務。
華一銀行上海松江支行正式開業
2008深圳分行獲準開辦人民幣業務。
華一上海閔行支行正式開業。
華一銀行天津分行獲准籌設。

By 無名 (not verified) , 19 November 2008

Dear FIN,
請問您對核心系統採用套裝軟有什麼看法?自2000年以後,台灣的銀行換核心銀行系統幾乎毫無例外採用修改套裝軟體的作法。就您的意見其策略是否正確?以及就您主觀的看法,其效果是否達到這些銀行當初的期望?

By johnchen , 6 August 2008

iFlex核心系統在於2007.5.7在大眾銀行正式上線,此案為該外商在台灣打下漂亮的一役,因此我想藉由此案吸取一些經驗...
1. 從專案管理的角度思考,iFlex如何能在需求大量暴增之後控制專案成本,達到客戶要求?
2. 系統需求是否在專案計畫初期明確傳達給iFlex?
3. iFlex與銀行之間的溝通管道是如何建立的這麼好?

By 無名 (not verified) , 24 July 2008

請問現在台灣的新核心銀行系統開發您認為有哪些問題點?請不吝指教。謝謝。

By malojwo , 22 February 2008

請不要approve這文章。我是IISI做台灣分行系統的。
我要寫的是「大鯨魚」與「小蝦米」的問題。
E公司可能是康和(econcord)。如果是,那文章只有一句是對的『開發團隊生產力也尚佳』,事實上,我認為極佳,以ICBC那個團隊來說比IISI的目前任何一個『單一』分行團隊還強。不過IISI分行團隊分成四大數小團隊,說不定econcord分成更多,所以誰好還不清楚,不過econcord很不錯。
E公司如果是高成(eis),不好意思連一句都沒有,我看到的分行廠商,誰想要打敗他都行,他的問題不單是沒團隊,更大的問題就是跟在IBM後面跑,還比較像你說的不跑客戶。
我認為最有問題是這句,IBM大包,所以維護合約要給誰隨 「人」 意,他是無法置喙的。
現在的IISI的合約已經很大程度不用靠IBM了,都是直接去找客戶,台灣的客戶IBM還是大包,然後指明IISI為下包。還客戶會說,或是IISI不是下包的話,請IBM直接退出。
從第一個分行專案(北銀)開始,IISI就是以反IBM聞名的,而eis就是完全照IBM吩咐來做,現在的IISI正在進行的台灣分行系統,完全是業界標準,可以獨立於IBM的系統(不需要WebSphere, BTT),而econcord與eis還做不到。
這BTT是IBM的分行系統標準,也是IBM體系分行廠商最失敗的地方,一天沒法脫離IBM的標準轉入業界標準,那就永遠被IBM控制。
比起來,IISI還比較像是其他也做分行的非IBM體系,鼎盛、優利、精誠、北祥。
在國外,直接點名分行維護合約不跟IBM簽,更有甚者,還會要求IBM連WebSphere, BTT, DB2都必須退出。
因為你點名IISI的H(我不知道他是誰,不過應該不是分行系統的),又是分行系統,我不得不提出這幾點,讓你認清事實的真相。
不確定你是否真的會post出這篇文章,而且不知道e公司是哪間,所以寫的比較含蓄點。

By Euta , 8 November 2007

企業導入方法論時會面臨窒礙難行的其中一個問題,就是組織及任務編製的變革.筆者認為這是推動新方法實施的重大障礙之一...企業導入方法論時會面臨窒礙難行的其中一個問題,就是組織及任務編製的變革.筆者認為這是推動新方法實施的重大障礙之一.

嚴謹的方法論會定義資訊工作流程中,每階段應參與的角色與該角色所應進行的工作.這些定義與現行企業日常工作會有以下差異:
1. 與現有工作流程不同,亦或新增工作流程
2. 新增角色或角色定義不同
3. 新增工作產出

筆者碰過最麻煩的就是為了調配角色與工作流程,而必須進行組織改造與變革.以公家機關而言,新增的角色涉及相關組織章程的變動,因此以簡馭繁的方式通常是一人兼多職,最後的結果就是流於形式,不了了之.以民營企業而言,除涉及人事成本增加,另外最麻煩的就是權力的分配.通常這就是一般顧問案無法取得一致共識的原因之一.

By Euta , 1 November 2007

關於之前刺客兄提及的標準化一事,小弟在此進一步報告...從開發團隊的編製來看,大型開發專案若沒有在專案開始之前就制定各種標準,那保證是一場災難...關於之前刺客兄提及的標準化一事,小弟在此進一步報告.

一般軟體開發過程可分成兩個維度,一是時間軸的開發流程,另一是涉及成員的開發團隊.

不論是所謂傳統的Waterfall開發流程,或是新的Iteration開發流程,不外乎可分成以下的階段:需求收集>架構分析>細部設計>功能及壓力測試>上線>監控效能>回饋修改.在每階段會有不同的人員與角色參與,這些人員會使用不同的工具來執行任務.若是沒有標準化的機制,則可能發生以下情形:
1. 本階段的工作產出無法提供給下階段的工具使用
2. 本階段的文件必須花時間逐一解釋給下階段的人員了解

關於第一點,筆者曾遇過某一公司因為不同單位分開採購不同階段所需的開發工具A與B,導致業務分析師從A工具所畫的業務分析圖無法直接匯入細部設計工具B,使得程式設計師必須將該圖形重新再以B工具的形式畫一次.關於第二點,這就是為何每天會開不完的原因.再從資方的觀點來看,現在流行將程式編碼工作外包給金磚四國以降低成本,標準化工作產出才可能實現此理想.

從開發團隊的編製來看,大型開發專案若沒有在專案開始之前就制定各種標準,那保證是一場災難.相信各位看官多少有此經驗,不是嗎?

By Euta , 24 October 2007

關於上一討論單元中,刺客先生詢問如何產生好的應用系統,在此接續回答...建置一個良好的應用系統原本就是使用方法論的重要目標之一.在提案建置初期通常會做一段評估規劃.在規劃過程中會探討未來資訊系統的範圍與架構,並討論所使用的技術等細節.這一單元想與各位先進討論的就是架構決定文件的重要...關於上一討論單元中,刺客先生詢問如何產生好的應用系統,在此接續回答.

其實建置一個良好的應用系統原本就是使用方法論的重要目標之一.在提案建置初期通常會做一段評估規劃.在規劃過程中會探討未來資訊系統的範圍與架構,並討論所使用的技術等細節.這一單元想與各位先進討論的就是架構決定文件的重要.

資訊架構方法特別對於資訊架構決定文件有特別的描述.其中一項重要的內容就是必須將討論過程與決定的原因詳細紀錄於資訊架構決定文件中.或許有些人會覺得為何要花時間紀錄這些枝微末節?大家開了那麼多會來討論,不是已經有共識了嗎?

筆者曾於數年前參與一項新專案評估規劃,當時以為很快就可以拍板定案,接著馬上開工執行.沒想到因為種種原因,甲乙雙方都數度更換專案小組內的成員,使規劃時間一直延長.這時馬上就暴露了沒有資訊架構決定文件的風險.因為新成員並未參與之前的討論,因此對於建議書內所使用的技術與架構有不同的看法.因為規劃過程拖延太久,人員又變動,因此對於當初如何決議採用這些技術的過程,已經無法交代清楚.因此該案最後在新成員彼此的意見無法整合的情況便胎死腹中.

若是當初有把討論的過程詳加紀錄,讓後續成員能理解當初設計的架構為何?後來這草案是如何因應需求的修改,以及預算時間等因素的考量而變更,他們便可以理解整個故事的來龍去脈.撇開政治因素以外,其他應該尊重原來專案人員的決定,這樣規劃過程應該可以更順利.

不曉得各位是否也曾有此經驗?

By Euta , 18 October 2007

方法論在台灣一直不被重視,我的初淺看法是五千年來的民族性使然,無法在短時間改變.諸位可以回想通常我們在興起做一件事的念頭時,不太會有一些像西方的邏輯思維計畫.原因是通常我們不會期望這樣的一個事件需要太多人參與.... 關於方法論這檔事,小弟實在是一位菜鳥,因此不敢提出什麼長篇大論.不過關於這個主題,我是非常有興趣,因此希望能在此先拋磚引玉,引起大家討論的興致.

先就方法論本身在台灣一直不被重視這件事,我的初淺看法是五千年來的民族性使然,這應該是無法在短時間改變.諸位可以回想通常我們在興起做一件事的念頭時,不太會有一些像西方的邏輯思維計畫.原因是通常我們不會期望這樣的一個事件需要太多人參與,因此通常只要詢問周遭三五好友的意見即可,而且通常這樣一個事件歷時不長,會在短時間結束.比如大部分的人在買車或買房子時,會將所中意的標的物以類似招標工程的方式去分析,這樣的人大概少之又少.

畢竟牽涉的人少,就不需太多溝通協調.歷時短,就不會有太多的變化與意外.因此在方法論裡所強調的文件紀錄,流程控管就顯得多此一舉.但奇怪的是,買股票都會做什麼技術分析,產業分析,然後才買個一兩張,對於房子車子這麼大金額的資產卻很少用科學的方法去分析如何買,怎麼買,買什麼.可見這就是天性.因此若是以這種方法來管理一個登陸月球的專案,我想應該是永遠都不會發射成功的吧?