E君是金融IT少數超級業務，上週他告訴我有些規模還不算太小的銀行(100分行左右)資訊主管告訴他他們銀行核心系統年預算約台幣5000萬(直接丶間接費用)，這聽在過去習慣與IBM大型主機銀行客戶打交道的我真是大吃一驚。
這數字與今年初我親自拜訪F丶H丶M丶T等大型IBM主機銀行客戶CIO告訴我的數字相較約10分之1到15分之1，如果與郵局相較更達20分之1。為什麼分行數丶帳戶數小2~3倍的銀支出卻少10~15倍的費用?探究其原因:1.這個銀行非IBM大型主機用戶－Infra費用較低2.上層抓IT費用抓得很緊能省就省-上面視IT是費用非成本。雖然如此這個銀行的核心系統功能與上述F等銀行的核心系統功能相較也不遑多讓，該有的商品與服務也都有。因此E君告訴我，該銀行CIO聽說在金額不要差距過大的前提下丶E君願意提供一個新的系統(功能經過該行使用者的認可)十分樂意接受E君的提案－參加E君所屬公司提供的-雲端核心銀行系統服務。這輿過去只要與CIO誒核心系統的委外，一定遭到CIO嚴厲指責的情況(過去在華僑丶寶華有這樣的經驗)有很大的不同，不知是要說觀念改變還是情勢逼人？本來以為只有這個銀行是特例，但是E君告訴我不僅這個銀行，他去拜訪其他2家銀行情況也是如此，因此可以想像現在的ClO在權丶錢漸失的情況下沈重的壓力迫使他們去思考其他可行的方案，而雲端型核心糸統可說是方案之一。然而要銀行願意將這樣重要的糸統(花錢但是不保証能賴此賺錢)的系統交出來，也必然有幾個前提要件。1.金融主管單位必須要同意(最近的公務人員心態保守必須加把勁) 2.雖說是雲端公眾型服務，但是個別銀行仍然保有差異化(系統架構有足夠的彈性及參數化解決) 3.成本與效益對潛在客戶有說服力(豐富的應用系統功能與維運能力 4.經營者的規模與承擔力。以上諸多條件如果能夠具體實現，我想依台灣將近40家銀行，2/3的銀行是應該慎重考慮放棄自營的核心系統，畢竟眼前就面臨一些問題 1.目前的核心系統有些年紀，應付使用者的要求有些力不從心 2.找個新核心系統転換費用不見得負擔的起，人力與責任更是難以承擔 3.開發過程冗長，結果也難以交待，上線后恐怕才是災難的開始。隨著時間過去，這些問題將會日趨複雜化,，也都是迫使銀行核心系統共同化的主要原因。我想E君所屬公司，規模夠大，後台也夠力，如果能下定決心投資妥善準備，我想市場是不成問題。
Comments
雲端笑話
唉 , 還在雲端系統.
1. 雲端系統若出現個資問題, 這要罰銀行還是罰系統商?
2. 全都放在雲端, 是不是一出問題就所有銀行都一起死了?
3. 雲端系統就比較穏, 比較有承受力? 不會吧?
只會COST DOWN, 腦子真的沒別的. 又要馬兒好, 又要馬兒不吃草.
觀念問題
1 誰洩露誰負責
2 當成一個超大型銀行來看(再大也比不過一個工商銀行大)
3 水庫一定比自家水塔堅固
觀念問題
1. 哪要改法規了, 將系統商當銀行在管? 再來, 系統在"雲端" 銀行要如 [何舉] 證是"雲端" 洩露出去的?
2. 哪要不要成立一家銀行就好, 何苦像台灣現在這麼多家呢. 一家郵局不就好了?
3. GOOGLE 當的次數, 跟我家的NB 差不了多少. RECOVER TIME 比我的NB 長.
AMAZON 的TPS 也才400 多. 工商銀有5000 了呢. 淘寶破萬了. 完全看不出"水庫一定比自家水塔堅固"
加一點吧. 錯帳(原因百百種), 銀行負責還是系統商負責? 誰投人力下去RECOVER? 誰負責驗證結果? 有銀, 賠錢誰負責賠? 延伸:若非銀行問題, 銀行要如何舉證?
註: FB 的問題一直都一堆, 以前就發生過VENDOR 可以透過API 未經授權而取得使用者的資料. 但我到現在還無法舉證呢.
依大大所言, 是不是金融系統都不適合共用?
依大大所言, 是不是金融系統都不適合共用? 那些已經共用的是怎麼辦到的? 問題都很多嗎? 獨立和共用一定是各有利弊的選擇吧. 有辦法克服種種上述的困難, 善於趨吉避凶的, 是不是就能勝出?
那些已經共用的是怎麼辦到的? 請舉例.
那些已經共用的是怎麼辦到的? 請舉例.
另外, 請回答我發的問題? 只需解決問題即可.
補充
這位 無名 先生(小姐)指的-那些已經共用的? 應是指在台灣已經經營超過20年的基層金融共用中心-北區農漁會會共用中心、中區農漁會會共用中心、南區農漁會會共用中心、桃園農會會共用中心、板橋農會會共用中心、全國信合社共用中心。
補充-
在台灣，除了基層金融參加核心系統共用外，並無銀行參加共用中心。但是在日本，除了3大銀行(瑞穗、東京三菱、三井住友)，108家地方銀行， 有91家銀行(有的銀行規模約300分行)，加入了共用中心。整理如后(詳情請上日本網站查詢)
說明-
NTT-DATA:STAR(7)、BeSTA(5)、MEJAR(4)、STELLA CUBE(8)、BeSTAcloud(2)、地銀共同利用中心(15)、SBK(6)
IBM:Chance Project(7)、TSUBASA(6)、じゅうだん会 (7)
日立:NEXTBASE(9)、NEXTSCOPE(3)
Unisys:BankVision(9)
NEC:BankingWeb21(3)
註1-廠商名:共用中心名(參加銀行數)
註2-BeSTAcloud(2)強調以雲端技術提供的共用中心
註3-近來有些規模較小(參加銀行教少)的共用中心，也計劃捨棄，加入較大技術較新的共用中心
共用中心的問題
http://www.ntifo.org.tw/page1.aspx?step=2&no=101091221075559262&forumno=...
各銀行之間的利基, 流程的差異, 要用一套系統來全包? 可能嗎?
當年我在做台灣的FORWARDER 的系統時給某大公司用, 公司想將它賣到中小型的FORWARDER, 要求人家流程轉成跟該大公司相同. 結果被人家當場吐糟.
除非是新銀行, 沒負擔的.
共用中心有很多種，加入的大多數是小銀行，大銀行很少
共用中心有很多種，加入的大多數是小銀行，大銀行很少（我要找一下那300分行是誰），其中 NTT-DATA 還有出白皮書介紹各種共用方式，非常詳細。
同樣的共用中心也有很多問題，想像你是跨國銀行的系統，不同國家有不同的法令等需要客製化，就知道難度有多高了，大多數都是用參數設定，改參數等於又發明一種語言，甚至比寫程式難度高（因為難除錯），想想SAP就知道了。而且出問題還要透過層層上報才能決定要不要解，以前是一個銀行說話，現在是一堆銀行說話，牽一髮動全身。
上面的分類與銀行的數目（我手邊的數據更多間共用）有點問題，不過這些系統都是共用的沒錯，只是有些不是核心系統，有些執行的很慘，甚至列入失敗案例探討。
可以透露嗎?
"上面的分類與銀行的數目（我手邊的數據更多間共用"--可以告訴還有哪些呢?
"只是有些不是核心系統" -- 哪些是核心，哪些非核心?
我自己回自己，太多人問問題我同時回答
我自己回自己，太多人問問題我同時回答，畢竟有那個自己上網查的先例在，我也不想一個個貼連結，而且我的專長也不是核心系統，大家自己google的到比較有成就感吧，
畢竟是日文可能沒那麼好找，所以我還是給個提示，貼個最重要的
http://ja.wikipedia.org/wiki/%E5%8B%98%E5%AE%9A%E7%B3%BB%E3%82%B7%E3%82%...
裡面有所有日本銀行共用系統（比上面列出的多很多），包括做一半放棄的銀行（回答到另外一個問題了），會找的人還可以找到有些銀行失敗案例的 case study，同樣也都可以 google 的到，特別註明的是就算是退回也是退回到前一個共用系統為多。
第二個提示是採用 NTT-Data 的系統多，裡面的資料也最豐富，可以從那邊下手。
第三，我前文不好，正確說這些都是核心系統，只是可能只是核心系統的一部分，畢竟一個銀行的核心系統有非常多個，我個人認為狹義的核心系統只retail core banking。
我上網看了一下＂勘定系システム
我上網看了一下＂勘定系システム＂應該翻譯成英文就是＂CORE BANKlNG SYSTEM＂, 所以不能説＂有些不是核心系統＂。
正確說這些都是核心系統
除了日本還有一些國家有銀行共用中心，怎麼做，架構如何，這些都由專長是核心系統的人來告訴大家吧。
第三點我已經說過了，正確說這些都是核心系統，只是可能只是核心系統的一部分，你有去查過每個系統嗎？我查過了，日本的資料非常豐富，甚至可以查到系統架構、成功失敗的原因。這些並不是都是單純 core retail 帳務的，核心系統有那麼多種，單純算總帳的是核心系統嗎？單純算匯率的算是嗎？call center算是嗎？票據交換的是嗎？都是。但是我第一篇寫的是專注在core retail 帳務，後來想想這些也算是帳務，所以才又回。
核心系統在我第一篇看到，比較像是台灣的銀行說要換主機系統
核心系統在我第一篇看到，比較像是台灣的銀行說要換主機系統，我會認為換的是台幣主機，要是說換清算系統不會特別說是換核心系統，所以我才說不都是核心系統，後來想想還是應該算。
我寫回應一般都會立刻貼出連結佐證，這次故意不放就是主文也是用自己上網查代表，所以我根本不想貼出連結，讓大家上網查。
我沒有否定共用系統甚至雲端主機，而且我手邊的資料有很多國家都有共用主機，甚至於NTT-Data自己也拿別的國家當例子用來證明共用的好處。
我的重點是那回應的數據似乎有點問題而已，而且大家都沒去仔細看那些所謂的共用的不同點，每個方案都有些許差異，差異點在哪邊，甚至有非常多都是使用同一個framework然後單純的租用主機而已也算是共用？就好像現在流行的AWS，一堆人都用R&R寫的，所以大家都是共用系統？
這裏面沒有要吵架的，多數人也相當有經驗
這裏面沒有要吵架的，多數人也相當有經驗，討論問題也非以訛傳䚹，倒是個人修為丶知識水平丶謙虛交流才是維持高水平論壇的基本条件。
看了討論才知道這邊都是對核心系統或是共用系統學有專長的人,
看了討論才知道這邊都是對核心系統或是共用系統學有專長的人, 怎麼我周遭核心系統的人問起來除了自己負責的東西都不知道, 甚至於自己使用的核心系統詳細架構都不清楚, 因為大家都不想知道而且很多事情這裡沒寫都沒人知道啊.
筆記 我也要在'個人修為丶知識水平丶謙虛交流'上面多多加強才是, 這才是增進知識的方法
上述列表的失敗退出的不少(采用撤回)，有些重複算的
上述列表的失敗退出的不少(采用撤回)，有些重複算的(庄内银行 由 地銀共同利用中心->BeSTAcloud)，而且幾乎都是地方銀行。
日本所謂地方銀行其實也是全國性銀行
日本所謂地方銀行其實也是全國性銀行，例如橫浜銀行丶京都銀行規模都比三商銀丶合庫規模還大，也都參加NTT-data的共用中心。還有丶樓上的説手上有明確資料為何不貼出呢？也可提高你的公信力。
好像上面的數字也沒貼連結，那我就隨便貼wiki的好了
好像上面的數字也沒貼連結，那我就隨便貼wiki的好了。
http://ja.wikipedia.org/wiki/BankingWeb21 上面的數據2使用, 2預定, 7使用後退回舊系統，怎麼算也不是3。
裡面就NTT-Data比較厲害，他的文件也有說明，有問題要先報到大銀行同意才能修改比如說 mejar 就是横浜銀行主導，所有客製化都要在參數設定檔內才行，而且使用新功能的參數當然要付費，也就是你要有自己的東西不大可能，文件連結我也要寫(詳情請上日本網站查詢)。
亞洲 100大 銀行排名
我也插個花 共襄盛舉 http://www.tppo.com.tw/mrt/top100_bank.htm
這排名很有趣，可能以名聲來排的吧。
就我所熟悉的幾個銀行來說，比如說某國家的銀行明顯是用分行數目與開戶人數排的，因為資產、利潤跟開戶人數正好反過來。另外一個國家似乎又是用營收來排的，分行數目反而不重要。又換一個國家的第一名無論分行數目、資產、利潤都是榜上最後一名，那國家我就看不出來排名因子了。
看來NTT-DATA 的確很多人用. 我不會日文,
看來NTT-DATA 的確很多人用. 我不會日文, 能看的有限.
但它一樣在2011,2012 年出現資料外洩問題. 然後訂個什麼ISO 的來作AUDIT, 另外加個MASK 哪樣作了結.
但WEB 的內容, 並無說明, 罰則, 或是, 若出現賬務問題, 由誰來買單.
當然, 9 成是BANK 吃下來囉.
日本, 這好像不是什麼大不了的事, 像SONY 的事件, 好像SONY也沒事.
感謝指正
這些資料係本人去年中在兆豐銀行資訊處演講資料(另外去年底也提供中國信託銀行日本事業處)，對於資訊未臻完善，致誤導諸位在此致上歉意。另外有關橫浜銀行規模，1988年本人在台灣富士通時有去參觀，規模的確很大，連線系統就用了M780三台相當3090/400三合，當時橫浜銀行是日本最大的地方銀行，也是富士通重要客戶。當時印象中橫浜銀行分行數約300，剛才上網查正確數字國內204海外4，應該記錯或是分行裁減。在此一併致謝來函指正。
除了NEC BankingWeb 21的貴出銀行外
除了NEC BankingWeb 21的貴出銀行外，其他還有哪些(采用退回)、重複計算的?
觀念、法令、制度、需求、系統、機制......
1. 雲端架構是趨勢，不是笑話。我不認為問題不可解，事在人為！
2. 提出問題是好事，因為問題會變成需求，有需求就會有解決方案，從觀念、法令、制度、系統、機制......各方面著手，最後就會有好的結果。
3. 有問題不是問題，真正的問題在於要不要去做(解決問題)。樓上的先進提到的問題任何系統都可能發生，但沒有因為這樣就把那些系統放棄了吧！因噎廢食是不可取的......
4. 企業願意選擇雲端作解決方案，絕不是隨便的決定，至少那些企業決策主管的頭腦不是漿糊，故意要把自身企業及客戶權益置於風險之下。
5. 我同意FIN"水庫比自家水塔堅固"的說法，當然，願意花大錢在自家建水庫當水塔那就另當別論啦！
我也認為是大勢所趨
我個人以為網際網路是基礎建設、雲端服務是觀念實踐開始、互連網是IT服務終極目標。銀行的核心系統現在已是IT公眾服務系統一環，隨著應用的大型化與複雜化，核心系統(帳務、交易處理)小規模經營可能會愈來愈辛苦。
我更認為凡事在人為
福斯汽車的成功戰略歸於-共同模組的最大化下，創造最多樣目的別的車種。通用汽車新CEO((Mary Barra)也採取了同樣戰略，成功挽救了通用。
車子, 是DEPENDS ON DESIGN,
車子, 是DEPENDS ON DESIGN, 車可以由公司決定各種規格, 然後每款"新"車, 就BASED ON 哪些零件, 再作DESIGN.
所以除非是"新"銀行. 這也就是我說的了.
個人原則，他人想法無從置喙
我設計核心系統一向追求構成程式模組(輸入編輯、交易檢查、共通處理、CIF處理、利息計算、手續費計算、日計記帳、檔案更新、輸出編輯...)的最大共用化，以應付規格(法令、需求)改變時，避免程式維護時牽一髮而動全身，新金融商品開發時，亦先評價原開發模組，決定新增模組或修改。認為做設計的工作都應秉持這樣的原則，無論設計IT系統、汽車機械、建築物，都應如此，除非做出來的東西不打算使用很久，否則追求長壽的系統、皆應如此。這是我個人原則，他人想法無從置喙。
MODULE 的觀念, 演變到OBJECT
MODULE 的觀念, 演變到OBJECT COMPONENT, 都講了兩百遍了, 也四五十年了.
但跟機械零件的差異在於, 車子可以按現有零件設計, 以降低成本.
電腦軟體系統則沒有這種情況.
需求的來源, 包括"人", 流程, 法條. 而且這種需求可是N 個人, N*N 個想法. 而且隨經辨, 主管在變.
跟車子設計不同, 就哪幾隻貓決定好. 頂多套個車殼.
其實是做的到的，問題是我做汽車零件系統的時候有幾十萬個零件
其實是做的到的，問題是我做汽車零件系統的時候有幾十萬個零件，所以軟體也該有幾十萬個component。
而且某在台灣暢銷主機系統可以用office寫程式可能不是很多人知道，讓user自己寫程式完全自動生成主機程式碼，但是沒人用，因為component數目不夠，而且改了一個問題介接問題等於必須要測試過所有可以接到這介面的元件。
從來就沒做到過, ERP 是很典型的系統, 每家都說模組化
從來就沒做到過, ERP 是很典型的系統, 每家都說模組化, 結果呢?
台灣的鼎新, 美國的SAP, ORACLE.
哪一家不是上線上到哇哇叫. 改來改去一大堆.
不是笑話, 是冷笑話而已
1. 不是笑話, 是冷笑話而已, 一個已經講了四五年了, 還在講的.
2. 觀念、法令、制度、系統、機制, 等完成了, 都百年後了.
3. 因噎廢食? 我怎麼看到是, 有人因雲端而雲端. 改自已的流程, 去適應別人的系統? 新銀行?
4. 漿糊腦全球都不缺, 德國就幹過交易所的系統用C# 來寫了.
5. 你同意就請舉例吧, 我舉出反例了.
而且, 我提的問題, 一件也沒答案. 光舉證, 就沒招了.
雲端核心銀行系統-政府政策己經往前邁進一步
1.金融主管單位必須要同意(最近的公務人員心態保守必須加把勁) -看樣子已經往前邁進一步了。
多數情況下,創新的服務皆是業者先偷跑提供，等到政宣佈后，市場很快就進入白熱化競爭。看起來時間不會太久了～
消金系統擬開放委外2014・1・5中央通訊社原文 http://www.cna.com.tw/news/afe/201401050149-1.aspx
Add new comment