現在的銀行IT主管真是難做,一方面現在銀行業務需求多樣且善變(銀行彼此競爭之故)應付這些需求已忙的焦頭爛額,另一方面又面臨第一代核心系統老舊必需汰換的問題.雖說表面上核心銀行每天還是照三餐的伺候客戶,也沒令外面的客戶太多不滿,但是面對內部的客戶可就不同了,許多產品與服務的需求都直接間接牽動到核心系統,在每次的主管會議上,業務單位(內部客戶)諸多的不滿直接對IT單位而發,IT主管的解釋最後也歸咎於老舊的核心系統.確實一個老舊的核心系統平常能平順的運轉已經是萬幸,任誰也不敢亂動,即便萬不得已需要修改追加時,也是功能外掛疊床架屋.久而久之誰也不知道裡面到底在做些甚麼,偶有修改也是戰戰競競深怕把系統搞垮.如此狀況下從上到下大家對換核心系統也有共識.只不過共識並不代表立即可以進行.更換核心系統豈有如此簡單?畢竟核心系統更換攸關銀行IT百年大計,從架構,技術面來看都是影響往後10-20年(甚至更久)銀行IT整體運用良窳(彈性與多樣)的系統(難怪堪稱核心系統),做這樣的決策其時並不容易,然而對決策者這還不是最困難的,最困難還是在風險的考慮,這些風險上的考慮筆者認為涵蓋1.從技術面看,到底保守一點繼續走熟悉的主機系統,還是應該積極勇敢去擁抱開放系統?從投資金額與技術發展趨勢似乎容易判斷,但是從革命是否能順利成功,小心駛的萬年船觀點,決定就錯綜複雜多了.2.從應用面看,世界級的套裝軟體,人家累積了多年經驗,Know-How絕對不差,又既然敢稱世界級,產品使用的開發技術絕對先進,實在沒理由不用?只是世界級的套裝軟體並未涵蓋台灣本地或本行的"特殊"需求,既然人家比較先進斷然沒理由要世界級套裝軟體修改程式配合我們的作業規章,而是我們的作業規章應修改去配合才對.然而真實環境豈是如此?退而求其次,願意大力配合修改的合作伙伴,即便不是數一數二,至少雙方合作上不會出甚麼大問題,否則萬一這些世界級的套裝軟體大廠不屑配合修改那可就麻煩大了.但是這情況就像結婚一樣,如果對象不是唯一,只是現實的考慮求其次,難免事後無盡的感嘆.3.從政治面看,核心系統更換金融龐大,對IT廠商而言這種商機豈可輕易放過?因此彼此競爭激烈,加上決策時間長,廠商投入資源都相當龐大,作為決策者之一的IT主管因為負責第一線的接觸,稍有不慎,很容易落人口實,如果抗壓性不足,中途倦勤或遭撤換也是常事.除此之外尚有內部不同意見整合,龐大開發經費解釋,準時完成壓力等等都在考驗IT主管判斷與決斷力.筆者身為乙方,亦曾歷經十幾次經驗,上述所言,雖然程度不一,但是情境雷同,且有愈來愈難"搞"之嘆,很多決策最後皆由最"大"廠商取得,其原因心知肚明也不需多作說明了.
Comments
台灣金融資訊系統的墮落
最近幾年,國內很多銀行「購買銀行軟體進行系統轉換」,其實是一種不合理又不正常的現象.而銀行IT主管因為無法應付需求而歸咎於核心系統的老舊,更是一種外行又不負責任的說法.事實真相是,銀行高層多不瞭解IT,而倚重的IT主管或資訊長又多為IT行政人員(歡迎對號入坐),缺乏IT技術發展經驗,無法有效掌握資訊系統的管理與維護工作,於是產生所謂系統疊床架屋或違章建築的問題,甚至於修改追加功能也戰戰競競沒法得心應手,現實情況是IT主管最怕被說成不懂系統,他們強調重點是管理.不須具備技術細節,為了擺脫因不瞭解系統技術導致管理不善的包袱,最方便的方法就是歸咎於核心系統的老舊,希望藉由購買新軟體減低責任壓力.另一方面,資訊廠商或管理顧問公司也樂於配合,以「生意」的角度,把「換系統」說成「換車子」或「換房子」一樣,每隔一般時間,廠商總會炒作一些新題材譬如 “客戶導向”,“服務導向”, “參數導向”, “物件導向”, “第二代銀行系統”,讓銀行高層有此錯覺,如不轉換系統就是落後,就是不知改革,很多銀行就是在這種情況下投入大筆資金購買新軟體.這些軟體如BENEFIT,FNS,TPE2等雖然只用三四年,很快的又被現在的資訊廠商批評為舊技術舊系統,圖謀再引進另外新軟體創造新商機.廠商和顧問公司的立場可以理解,但是銀行盲目跟隨起舞就非常不智.老實說,銀行應用系統的發展維護工作或許煩雜,但不涉及高深理論或學問,只要務實面對,銀行的資訊工作人員絕對有能力解決系統發展維護問題.
國內發展金融資訊系統也有三十年歷史,至今如果還在「購買銀行應用軟體」實在是一件墮落而丟臉的事.
「延壽」VS「汰換」
親愛的洛克兄弟,
我非常贊同你的某些觀點,譬如說IT主管確實需要相當的技術背景與豐富的實戰經驗.任何應用系統首重維護(特別是核心銀行系統),只有維護到一定程度到不符經濟效益,才是到認真思考怎麼汰換階段.當然前題是必需真正內行的才知道怎麼讓核心系統延壽,而不是因自己的無知把一個好不容易達到成熟而穩定的系統換掉.同時,把「核心系統」比喻成「車子」也不恰當,比喻成「房子」更代表無知.至少應該比喻成「飛機」比較恰當,車子壞了你敢隨便找一個保養場修理看看,飛機壞了你敢嗎?飛機汰換看哩程,平常則靠嚴謹的保養,你聽過有飛機因不會維修保養導致使用年限未到而換嗎?系統又何嘗不是如此?筆者曾撰文板信商銀7年不到就換核心系統,你相信板信需求(哩程)有累積這麼快,短短7年就把使用年限耗盡了嗎?還是說原來買錯了,要一架小客機結果當初錯買了一架大客機?筆者認為真正的問題是這個系統從上線後就沒有一個夠「格」的維護團隊,如此新系統與原系統又有甚麼差別呢?又何必花費一大筆錢又搞得人仰馬翻換一個如此短命的系統呢?所以關鍵還是建立一個夠水準的維護團隊比換系統本身的意義更重要.而建立與領導一個合格的維護團隊又是誰的責任呢?當然是IT主管.但是那一個IT主管會承認自己這方面的無知與無能呢?誰來評價合格的IT主管呢?也許站在廠商的立場上,能力太好的IT主管反而不是一件好事,但是這也是不夠水準的IT廠商的短見,真正夠水準的廠商應該是希望客戶是可敬的對手.
銀行應用系統的版本問題
就某種程度,我認為資訊系統是「活的」,因為隨著環境改變及技術更新,資訊系統可以不斷的成長,資訊系統會變老變舊,唯一的原因是沒有適當的維護.俯拾可見的例子如Microsoft Window,從3.0, 95, 98, 2000, XP, 到Vista , 又如IBM CICS,從1.6,2.1,4.1, 到TS1.3, 2.1.每一次版本提昇代表系統的成長,功能的增加.如果資訊廠商提供的系統軟體以版本來顯示系統成長發展的現況,為什麼國內銀行應用系統沒有版本顯示問題?銀行高層和IT主管真能確實掌握應用系統的維護情形?國內每家銀行資訊系統維護人員,少則百人,多則四五百人,經過幾年的應用系統維護,相信應用系統的內容有相當程度的改變,但是我們如何說明這些改變?如何評鑑系統功能成長情形?如何彰顯維護人員的努力與能力?或許國內銀行應用系統沒有版本顯示問題是因為對「維護」有不同的理解,有些銀行的應用系統直接於廠商提供的控制軟體下開發,「維護」的意義就只有應用程式的修改開發,系統名稱只能冠以「存款系統」「外匯系統」「放款系統」等,甚至沒有自己特別的系統名稱,因此不知如何設立版本標準.另外幾家銀行的應用系統雖然有特別的應用系統名稱如CAP. BENEFIT. FNS. 但是受制於廠商合約授權限制,不得修改核心控制軟體,所以「維護」的意義也只能停在修改應用程式的層次,設立版本標準也有困難.其餘的銀行擁有自己的核心控制軟體,可以有較大的空間發展系統功能,顯然這些銀行對應用系統的掌控比較有「自主性」,有機會建立自己系統品牌,但是過去不重視控制軟體的維護,或「功力」不足,無意於建立系統維護版本.
以上問題,確有實務上困難,也十足反映國內金融資訊發展不振的現狀.無論如何,我認為銀行應用系統的維護發展是銀行業者的責任,實不該寄望或委託廠商代為解決,因為業務應用的Know How 是銀行的本業.過去就是因為銀行應用系統的維護沒有適當規範可評量,使各銀行失去「主導」應用系統發展意願.如果各銀行建立應用系統的版本標準,初期難免有客觀上的爭議,但經過一段時間後,可適度彰顯各銀行的「資訊力」,進而有效提昇銀行應用系統的維護品質.
控制程式維護責任在廠商,但前題是-廠商要建立產品標準維護程序!
親愛的洛克兄弟,
核心銀行控制軟體或稱核心控制程式(以下稱CP),如CAP,SAIL(IBM),NBX(NEC),SUP(Fujitsu),SYSTEM-F(Unisys),ESCORT(Hitachi)這些日本開發的產品除了SAIL,SUP之外,在台灣都有使用者.在日本,主要銀行(都市,地方)的核心系統應用程式(以下稱AP),也都建置其上,銀行IT維護人員也因此可以專注在應用系統業務邏輯處理.因為CP介於OLAP(如CICS,IMS,VIS,OSIVF4,MCP,VOS)與AP(如存款系統)之間,系統硬體,軟體版本的提升(例如Parallel Sysplex),或者AP新的功能需求(如連動,24*365)基本上都會牽動CP版本的更新(如CAP,CAP-I,CAP-A).在日本,廠商會定期與主要銀行(東京三菱-IBM,瑞穗-Fujitsu,三井住友-NEC)檢討,對於大銀行客戶的需求會以開發系統產品的嚴謹態度對應(例如IMS/DB的MSDB,FASTPATH都是因應銀行客戶要求開發,而牽動CAP,SAIL的DBI功能更新開發),基本上銀行是沒能力也沒必要自己維護CP的.然而在台灣,除了CAP,NBX是由日本原廠維護,尚有定期版本更新外,其餘廣泛使用的UCP,BENEFIT因為未建立標準維護程序(開發廠商的責任),客戶只要有原始碼都可以任意修改(破壞CP與AP原先的標準介面),幾年下來雖然號稱使用相同CP實質已大不相同(不然你叫資策會開發UCP的下一版給現有UCP的用戶使用,而不需重寫AP,看他做不做得到?),碰到夠水準的SE雖然改的不是那麼理想,至少不致拖垮AP,如果不幸碰到不夠水準的SE修改CP,那還不如不要CP免得站在OLAP與AP中間,沒幫上甚麼忙反而對AP而言是一個擋在中間的一顆大石頭.
應用控制程式的維護責任
親愛的加事伯先生:
我非常不認同「控制程式維護責任在廠商」的看法,但是我同意資策會沒有辦法繼續維護或開發新一代UCP.其實這兩種說法指的是同一件事情,資策會沒有辦法繼續維護UCP並不完全是能力或技術問題,主要的原因是廠商(資策會)沒有任何直接管道接觸銀行業務的應用實務,很難真正瞭解銀行業務單位的想法和需求,而經濟金融環境變化快速,業務需求也隨時改變,如果要求廠商(資策會)配合需求來維護控制程式是很為難的,資訊技術與業務需求溝通方面的困難,即使是銀行內部的資訊部門都即待改進,更不要說外部廠商了,這是結構上問題, 廠商想做這筆生意都很勉強.另外的例子, BENEFIT 是IBM引進的銀行控制軟體,我不相信IBM有辦法繼續維護或開發新一代BENEFIT.道理是一樣的.再者,最為明顯的事實是, IBM貴為資訊業界的龍頭大廠,多年來卻未曾開發一套自己品牌的銀行應用系統控制軟體,想必是認為銀行資訊部門開發維護控制程式比較適當合理吧,否則這麼一大塊市場怎捨得放棄. 台灣IBM很勤奮的到處引進推薦其他軟體公司的銀行控制軟體,美其名為系統整合(SI)業務,其實純粹是為了市場業績考量,從來不去思考輔導協助使用者自行開發維護應用控制軟體,這是短視近利的做法,因為客戶對應用軟體的不滿遲早會怪到IBM頭上, IBM站在中介角色,無法提供直接的應用系統維護服務,對IBM長期的信譽會是一種傷害.我認為「控制程式維護責任在銀行資訊部門」的另一個理由是,控制程式依附於廠商作業系統及OLTP環境下開發,複雜和困難的部份已經由廠商解決,應用控制程式本身並不難理解,完全不牽涉任何高深的學問,實在沒有委託廠商維護的必要,況且銀行資訊部門的人力資源比一般軟體公司更為豐沛,撥出少數人員加以培養訓練,自行維護開發控制程式,不但可掌握及主導系統發展作業,相信更可以替銀行節省大筆經費.近年來銀行可掌握的事情愈來愈少,讓廠商或管理顧問公司予取予求,銀行業者應辦法改變.
喝牛奶並不一定自己養乳牛
親愛的洛克兄弟,
首先要告訴您的SAIL,CAP,BENEFIT都是日本IBM開發的控制程式,開發與維護上述的任何一個產品都需要看到相當大的潛在市場規模,日本IBM才會投入龐大的經費去開發(以SAIL約US100M,BENEFIT則US$7M)後續尚有超過100人在維護(行銷+技術)該類產品,依日本IBM對SAIL+CAP一年MLC約US$20-25M(2005)加上系統硬軟體部門支持,所以有辦法建立產品維護體制,才能後續版本提供銀行客戶.但是BENEFIT在日本僅剩2個VSE客戶,所以日本IBM已經停止BENEFIT後續的維護.IBM台灣雖然是台灣銀行IT的龍頭老大,但是全體台灣IBM銀行用戶的產值仍然相當於東京三菱銀行一個客戶.所以就IBM台灣的觀點是引進日本IBM開發的產品是較合算的(開發與維護成本較划算),所以台灣CAP的用戶使用的版本與日本用戶能夠同步,但是BENEFIT因日本停止推新版本台灣也無力單獨負擔維護成本所以當客戶有需要時就以SI的方式維護,而非以產品標準維護程續維護.或許台灣IBM是可以考慮自己開發一套專屬台灣銀行的控制程式產品,但我個人認為除非有相當多的銀行願意與IBM台灣共襄盛舉,否則又會回到雞生蛋,蛋生雞的投資與回收問題,最終還是無解.台灣有機會自行開發連線控制程式的時機是UCP開發的那個時代,當時大家都需要,看得到隨後衍生商機,如今百花齊放,台灣本身全體經濟規模也不大,又無法約束銀行共襄盛舉,即便銀行IT市場佔用率約55-60%的台灣IBM要做這樣的投資決策是相當困難的,然而如果是以兩岸三地的整體市場觀點則又不同了,但這則須有高瞻遠矚的有遠見之士登高一呼或有機會,然是否仍可以由台灣主導,大有疑問,如此與引進日本IBM的CAP又有甚麼不同?至於您提到銀行應該自行維護控制程式這個問題,因為"開發與維護成本"相當龐大(就如前述CAP,SAIL例),日本銀行站在喝牛奶並不一定自己養乳牛的關點,另外確實技術上仍與IBM有一段距離(即便日本IBM本身有些功能仍需仰賴LAB),可以說沒有銀行自己維護連線控制程式.銀行用戶如果自行維護,產品壽命恐怕不樂觀.
廠商的標準官式說法
親愛的加事伯先生:
喝牛奶並不一定自己養乳牛的觀點,應該是廠商的標準官式說法,沒有日本銀行自己維護連線控制程式也讓人存疑.OS+IMS或OS+CICS由IBM維護是合理的,但是應用控制程式仍由IBM維護則沒有道理,除非使用這應用控制程式的所有日本銀行都有同樣的需求,或是不能有特殊的要求,否則如何維護個別銀行不同的應用控制程式版本.我相信日本各銀行(稍為中型)資訊技術人員至少有二三百人,由其中五至十人負責維護應用控制程式,應該更有效率也較符合經濟利益.我強調應用控制程式實在沒有那麼困難,又必須隨時應付多變的業務需求,銀行自己維護比較適當合理.再說,銀行資訊技術人員如果不能掌握應用控制程式的維護,遑論所謂發展金融資訊系統,以「採購」代替「研發」實在不是好點子.另外,市場規模大小也沒有絕對的關聯,我也可以告訴你,二十五年前台灣已經出口銀行控制程式產品到東南亞,當時的資訊環境不比今日,市場,經濟,資訊知識普及率,國民所得等都不如現在,但是前輩們曾經努力,也成功開發很好的銀行應用控制軟體,如今國內各項資源充足,資訊人才技術也很優秀,反而後繼無力,市場上廠商引進印度,澳洲,韓國的軟體產品.這情況讓人扼腕.三十年前可以,現在反而不可以,到底是出了什麼問題使國內的金融資訊系統發展低迷不振?如果資訊人才技術不是問題,或許銀行的資訊策略有問題,主事者的見識不足,經驗缺乏,導致長期忽視應用控制程式的維護開發.最近幾年銀行界談改革,談組織改造,或許應該也認真的談談資訊策略改革──想喝牛奶不妨先去養一頭乳牛.
應該要利用廠商的長處,而不是被廠商抓住短處
親愛的洛克兄弟,
確實如你所言20(1986-87)幾年前UCP確實是經由九州(印尼力寶集團子公司資策會也是有投資,夏起中,王剛先後擔任總經理),販售到印尼力寶集團旗下中亞銀行(Lippo Group),當時UCP在台灣如日中天,有人才,技術,也看到東南亞市場,但是不過幾年光景,九州公司就因市場,資金不繼就結束營業,可見當時台灣是有這個機會但是並沒有把握.我個人主觀看法沒有成功的原因是UCP本身產品化不足(沒有建立一套標準產品維護體制-經費,組織,技術文件等等)難免賣相略差,這點也是我強調沒有經濟規模則無法搞出一個像樣的產品,勉強去作也無法作出世界級產品,除非我們的目標市場是放大到中國甚至到全世界否則結果還是一樣.至於日本的銀行就如同所言,的確大部份的銀行(特別是大銀行,很奇怪吧?)都採用廠商開發的控制程式,版本也都由廠商繼續維護提供,控制程式本身不會限制到個別銀行差異的應用程式,也就是說控制程式的規格是涵蓋全體銀行所需的共通功能規格,如果某些銀行提出新需求,廠商也會承諾在一定的期限內提供新版本,這也是CAP,SAIL未提出以前(1987前)銀行的控制程式都仰賴自己開發維護,但自從CAP,SAIL提出以後(1987後),日本銀行紛紛放棄自己開發的控制程式.日本一個都市銀行IT人員動輒數千人尚皆放棄自己開發維護控制程式,台灣銀行規模普遍不大,除非要的是一個較簡單的控制程式,否則應該負擔不起也作不出來(5-10人可以做出UCP,但是絕對作不出SAIL,除非日本IBM,東京三菱(BoTM),瑞穗(MIZUHO)都是笨蛋,但不要忘記當初UCP也是請日本人來技術指導).我這裏有一份日本IBM CAP,SAIL的用戶清單(注意東京三菱-BoTM,瑞穗-MIZUHO都是SAIL用戶)提供你參考.
產品
版本
銀行名
CAP
CAP-A V2
CHUGOKU BK
CAP
CAP-A V2
CHUGOKU BK
CAP
CAP-A V2
IBARAGIKEN NOKYO DENSA
CAP
DSE-CAP
MIZUHO BK MIZUHO JYUNB
CAP
CAP FOR ADVANC
SMBC LEASING SMBC YMT
CAP
CAP FOR ADVANC
SAITAMA SHINREN
CAP
CAP FOR ADVANC
ASAHI BK KASAISYSTEM
CAP
CAP FOR ADVANC
ASAHI BK SOGO SYS CENT
CAP
CAP FOR ADVANC
ASAHI BK TOKYO JIMU C
CAP
CAP FOR ADVANC
SHIKOKU BK SHIN CTR
CAP
CAP FOR ADVANC
GUNMA NOKYO DENSAN CTR
CAP
CAP FOR ADVANC
SURUGA BK
產品
版本
銀行名
SAIL
SAIL/ESA V2
MIZUHO TR BANK
SAIL
SAIL/ESA V2
MBISHI TR BK TAMACENTE
SAIL
SAIL/ESA V2
TOSHINREN DP CENTER
SAIL
SAIL/ESA V2
TOKYO JYOHO CENTER
SAIL
SAIL/ESA V2
CHUO TR BK CHOUFU CENT
SAIL
SAIL/ESA V2
MITSUI TR BK OSAKA B/C
SAIL
SAIL/ESA V2
Z38
SAIL
SAIL/ESA V2
AKITA KENSHINREN
SAIL
SAIL/ESA V2
STOMO TR BK FUCHU UNEI
SAIL
SAIL/ESA V2
U-FIT NAGOYA SYSTEMKAN
SAIL
SAIL/ESA V2
MIZUHO BK TOKYO CENTER
SAIL
SAIL/ESA V2
114 B/K
SAIL
SAIL/ESA V2
CHIBA BANK CENTER
SAIL
SAIL/ESA V2
TOKYO MBISHI BK TAMA
SAIL
SAIL/ESA V2
TOKYO MBISHI BK
SAIL
SAIL/ESA V2
JRI SYS OUTSOURCING
SAIL
SAIL/ESA V2
NOMURA SEC HIYOSHI CTR
SAIL
SAIL/ESA V2
NRI&NCC PMS
SAIL
SAIL/ESA V2
MIYAGI KENSHINREN
SAIL
SAIL/ESA V2
TAKEFUJI HQ 9672 #1
SAIL
SAIL/ESA V2
TAKEFUJI HQ 9672 #2
SAIL
SAIL/ESA V2
IYO BANK
SAIL
SAIL/ESA V2
IWATE NOKYO JYOHO DEN
SAIL
SAIL/ESA V2
SHIZUOKA BK Z
SAIL
SAIL/ESA V2
AKITA NOKYO DENSAN CTR
碰到這種情況,銀行真的就要自求多福了
親愛的洛克兄弟,
當然我的論點的前題是-廠商要熟悉銀行IT的需要(共通功能),對核心業務也要相當熟悉了解(直接能對應應用系統設計開發人員),且把核心銀行控制程式當作系統產品高規格維護,這種情況下銀行才可以依賴廠商,否則你說的論點我是十分同意的.我想目前台灣UCP,BENEFIT的情況,開發者沒有後續版本的提供,維護者程度參差不齊,我就經常聽F金控副總抱怨廠商維護者將BENEFIT搞的亂七八糟也沒對USER作技術移轉,只想藉此掐住客戶,出問題不找他不行,找了也頭痛醫頭腳痛醫腳,滿肚子烏龍氣,要不是核心系統更換不易,否則早就不用了,最近終於下定決心,決定開始進行新核心系統的更換計劃.這種情況大概在台灣也很普遍,難怪你有求人不如自立自強之嘆.
Add new comment