Fri, 2008-05-16 09:40 — 加事伯
2007年中、兆豐銀行決定汰換原先以CT為平台的TABS分行系統(1993年開發)、原舊系統的提供者IBM這次與康和資訊聯合提案以BTT為平台的ETABS新分行系統、強調BTT的優越功能與開發便利性、兆豐銀資訊高層相信IBM說法、最後並順利取的合約。
康和過去雖承攬過IBM的分行系統包案、但實際上對BTT並沒有實際開發經驗、只因相信IBM的說辭、而認為應該可以履行合約。只不過當康和開始進行合約後、技術人員才發現並未如當初IBM所言:BTT是一功能強大易學易用的系統、反之是一個需大量客製化系統、己身更本無力履行、遂求助於已有豐富BTT開發經驗的宏瞻科技、冀望得到技術支援、甚至有想將合約轉包宏瞻的提案。當初宏瞻也有參予此標案、只因IBM決定與康和合作、雖曾告知客戶BTT並非如此簡單、非相當開發經驗、風險將很高云、但最後仍未獲IBM大力支持(決定權在業務而非技術)而敗北。如今康和求助、內部有贊成也有反對、最終告知康和自己並無承接意願、但願意推薦另一家公司-數位金流承接康和的轉包。數位金流過去大都承接基層金融的分行系統(NEC)、雖然過去也承攬過中聯、板信與板農的分行系統(IBM)、但是亦無BTT的使用經驗、因此希望宏瞻能承諾BTT技術支援、才願意承接康和的轉包。三方條件未明、總之最後宏瞻也同意了、因此康和順利將合約轉包給數位金流。事情原本告一段落應該順利、怎知道上月底(2008.4)數位金流決定發函康和、告知不願意做大包的意願、原因為開發風險太高恐無法驗收云…。事情等於回到原點、後續發展也不知如何、但值得關切、因為由此案可以得到一些只汰換端末不汰換核心系統的經驗與教訓。
消息佈告類別:
Comments
哈哈,這篇文章是大概
哈哈,這篇文章是大概是宏瞻寫的吧
基本原則
這篇文章是本人所寫，絕非假他人之手。作為專業人士，必需自負言責，這是基本原則。
兆豐分行系統案最新動向
據了解，最近IBM又再度遊說兆豐採用BTT 6.1。相較於BTT 5.0的臃腫肥大，6.1的功能宣稱已瘦身且專注於支援分行系統所必須的功能。只是有一個問題，如果兆豐接受6.1版，IBM是否應該退還兆豐一些錢?因為BTT 6.1比5.0便宜(因為客戶只需要付必要部份軟體費用)，否則兆豐豈不是要當冤大頭?另外，據聞康和已經開始接洽高成，後續是否會由高成接手尚不得而知，但從此看來不論IBM、康和、宏瞻、數位金流目前都在旁觀，結局只好讓時間來告訴我們。但前提是-諸位看官要活的夠久。
補充
1. 原本康和是以BTT 4.3為架構開發，後來經歷了一段慘痛的 migration 過 程，4.3 --> 5.1 --> 5.2，康和當初過於樂觀地認為4.3到5.x的migrate不會影響到專案時程與既有架構，低估了migration impact.
2. 『當康和開始進行合約後、技術人員才發現並未如當初IBM所言:BTT是一功能強大易學易用的系統、反之是一個需大量客製化系統、己身更本無力履行、遂求助於已有豐富BTT開發經驗的宏瞻科技、冀望得到技術支援、甚至有想將合約轉包宏瞻的提案』
當專案狀況出現後，康和後來的確在Rich Client 上求助於宏瞻，籍由導入宏瞻UI的產品，克服BTT在Rich Client上開發的困難。因此帶來下列2點問題：
(1)不同Client UI架構的整合 (BTT + 宏瞻 + 康和)
(2)已開發交易的改寫
(3)專案需求與產品功能間的落差
3.『康和過去雖承攬過IBM的分行系統包案、但實際上對BTT並沒有實際開發經驗』
一開始康和對BTT的能力也只是作一個BTT 4.3 Lab出來，於是就用這個Lab workspace加上之前分行系統的開發經驗來進行這個專案，並且一邊延攬具有經驗的人才。僅管BTT的功能相當豐富，但resource, support確實相當有限。先天後天均不足的狀況下，康和且戰且走的打爛仗策略，使得兩肇均為輸家
4.『由此案可以得到一些只汰換端末不汰換核心系統的經驗與教訓』--並非完全未汰換核心系統
5. 目前己2009年2月，新分行系統phase 1還未上線(一開始康和估"2007"年6月)。其實好戲還在後頭，phase 2的業務更多，phase1已是歹戲拖棚，phase2好戲才剛上演。
啞巴吃黃蓮
本人為當事人,不知有這樣的文章,五年後才看見這篇....
不知那位暱名作者為何人,對於這個專案如此關心及對於康和的瞭解的程度,令人感到好奇....
我來簡單的說明一下這事情...
1.專案原來由另一位同事,負責九個月後因病離職,才由本人接手(2006年5月)
2.本人接手後,發現專案內容@#$%^&*(,加上專案時間已經過了大半,所以採取一些必要的對策,本人在JFTS時,已經瞭解到JAVA的UI控制不是在短時間可以完成,且JAVA 1.4又在UI上做了大調整,加上BTT的UI太簡陋,無法滿足客戶需求,自行開發時間上來不及,所以找上宏瞻
3.因為本人在本專案之前,在IBM的JFTS及CBTF已經有與宏瞻的人合作過,所以知道他們有技術能力,但宏瞻整套的solution,是最早依FTS產出的,無法滿足TABS的需求,所以決定只導入宏瞻的UI,由於專案都尚未開始開發,所以沒有所謂的重新開發或改寫的問題,也沒有康和+BTT+宏瞻的問題,其實就是IBM BTT的底層,宏瞻的BTT UI及康和的BTT交易開發,對康和而言,事情回到最原始的focus,而導入宏瞻的UI並整合至原有的系統架構中,花了不到一個人月的時間,因為只是將原來BTT的UI換成宏瞻的
4.BTT 4.3 -> 5.1,IBM依最早承諾的,依照我們專案架構,寫了一個轉換到BTT 5.1的範例,所以轉換只是底層的調整,交易本身並沒有花費到太多時間,反而是因為開發工具的問題,才是最大的問題,由WASD 5 -> RAD6,這件事,客戶及我的長官們都無法理解,為何這事要花到一個月的時間,但這就是IBM RAD6的神奇,當然也加上我們配備的機器的問題.PR比較大的問題是在5.1導入了EJB,造成交易行為改變(當時並沒有太多人使用過EJB)造成PR控制交易概念上的問題
5.整個專案在2007年中完成了規格上的開發,也就是專案真正時間是花了一年完成開發(從我接手開始算,之前完成的只有部份規格),但專案真正上線卻是到2009年的年底,這其中的原因,就與技術無關了,我就不說明了....
澄清幾個問題:
1.當康和開始進行合約後、技術人員才發現並未如當初IBM所言:BTT是一功能強大易學易用的系統、反之是一個需大量客製化系統
==> 基本上我們並不是第一次使用IBM的產品,也不是沒看過BTT這產品,產品銷售的話術不用拿來這裡討論
2.求助於已有豐富BTT開發經驗的宏瞻科技、冀望得到技術支援、甚至有想將合約轉包宏瞻的提案。
==> 我找宏瞻只為了UI,我不認為宏瞻統包會比較好,在與宏瞻洽談過程中,以宏瞻提出來的解決方案,以及不願透露的技術細節,以當時宏瞻的solution,也是需要大量的客製化,不會如他們想像的那樣單純,我擔心他們會誤判狀況,把問題弄的更複雜,所以我極力反對由宏瞻統包,而只導入UI 長官們會這麼想,也是正常,但專案最大的問題不是技術問題...
3.康和順利將合約轉包給數位金流。事情原本告一段落應該順利、怎知道上月底(2008.4)數位金流決定發函康和、告知不願意做大包的意願、原因為開發風險太高恐無法驗收云
==> 數位金流這是Phase2的事情了,這家公司誠意十足,但可惜那個專案並非是他們的舞台,因為他們沒做過IBM的端末系統(不是指BTT),所以門檻太高了,因為規格就是TABS的程式,他們自然無法承接,原先與客戶談的是客戶願意重新整理規格,自然就沒問題,但客戶認知的規格,就是附上TABS的程式,這讓數位金流傻眼了,所以才有如此的事件.這件事一開始,我就不看好數位金流的狀況,我亦有告知長官及數位金流的負責人,但沒人理會,最終落得如此結果,也是意料中之事了
這件事的後續,是康和又找了高成做下包,負責交易開發,高成以較低的價格承接,我也告知對方,價格請他們考慮清楚,不要用以前的經驗來評估,最後仍是發生追加價錢,還說我們沒講清楚,真是!@#$%^&,做到最後,高成的分行端末團隊,目前應該是解散了吧??
4.因為由此案可以得到一些只汰換端末不汰換核心系統的經驗與教訓
==> 這件事,與核心系統汰不汰換,八竿子打不上,不知此結論從何而來????
5.最近IBM又再度遊說兆豐採用BTT 6.1
==> 這事客戶有找我們評估,我直接回答沒有汰換的必要,因為享受到6.1的好處,主機的程式也要改變.但不改也可,只是換了也是和目前的狀況一樣,再者6.1的好處,並不會提昇分行的工作效能,除非分行的分工及作業方式改變,不然並沒有任何好處,客戶也認同,所以最後形式上回覆了一個評估結果.公司有新產品,自然要推銷給現有的客戶,至於價錢的問題,是因為計價方式的不同,這和其他產品一樣,從user數改成by CPU計價一樣,計價的細節如果有興趣,可以直接找IBM詢問...
6.康和當初過於樂觀地認為4.3到5.x的migrate不會影響到專案時程與既有架構，低估了migration impact.
==> migrate有影響既有架構,但最大的impact卻是轉換開發工具(WASD->RAD6),這是誰都沒料到的事....
7.克服BTT在Rich Client上開發的困難。因此帶來下列2點問題：
(1)不同Client UI架構的整合 (BTT + 宏瞻 + 康和)
==> 只有一個Client UI,就是宏瞻的UI
(2)已開發交易的改寫
==> 不影響,因為還沒開始開發交易
(3)專案需求與產品功能間的落差
==> 這遠比自己從頭來快且穩多了
8.目前己2009年2月，新分行系統phase 1還未上線(一開始康和估"2007"年6月)。其實好戲還在後頭，phase 2的業務更多，phase1已是歹戲拖棚，phase2好戲才剛上演
==> phase1已是歹戲拖棚,不是技術問題
phase2業務雖多,但範圍及規格明確(就是TABS的程式),且已經有phase1的架構base,因為在Phase1的架構設計上,就是要讓TABS轉換容易,所以只要focus在交易開發
最後的結果
1.phase1:150支交易,執行了三年,在2009年底上線,專案價錢不到仟萬
2.phase2:600支交易,共執行了二年,在2011年開始上線,專案價錢超過三仟萬
phase1是由我接手因病離職的同事...
phase2是由原來因病離職的同事回來接手的...
相信大家都是明眼人,phase1及phase2的執行結果差異如此大,所以我由一個部門主管,變成一個到處打零工的PR,而回來的同事,依舊是部門主管...
這就是看事情表面
這個回覆,只是在說明,專案的過程如你們外表看到的,但實際的狀況,不是單純的一個原因造成的,康和技術不足,是不可否認,但仍不至於無法完成專案的狀況,到處尋找外包,支援,不是因為技術不足,考量的是成本及專案時程.這過程中,也許有些策略上的決定,比如找數位金流,並沒有期待他們可以完成這個專案,而只是讓客戶知道專案是進行中,你想看看,怎麼會有人放心下包給一家公司,那家公司資本額還不到專案的金額,而且沒有任何罰則??
這回應跟我所知道的狀況差不多，當然我金額不了解
這回應跟我所知道的狀況差不多，當然我金額不了解，大多數專案的問題都不是技術的問題。
基本上BTT從6.x開始就不推rich client，因為 UI 是他的弱點，所以不好開發正常，後來也 BTT 全面轉向 web client。
因為大多數專案都不是技術的問題，因為所有的技術問題都能解決，就算 BTT 原生 UI 再難搞，也是產出了不少系統。
鉄杵也能磨成綉花針，技術當然不是問題，問題是值不值得這樣作
鉄杵也能磨成綉花針，技術當然不是問題，問題是值不值得這樣作。
技術問題就是專案問題，舉例專案一年收費三千萬
技術問題就是專案問題，舉例專案一年收費三千萬，文章所舉的WSAD5->RAD6需要一個月，那就是大約三百萬丟水裡面了。
其實RAD6不神奇，只要電腦買當時頂級的大約就能以正常速度跑了，神奇的是同時期IBM的產品會需要RAD6來執行（實際上不用，可以有方法避過），標準的作法是只有一台電腦(Server)裝RAD6+BTT，其他電腦用eclipse，反正一般電腦也無法直接連上host，可以解決因為配備產生的問題。
我覺得配備問題公司必要解決，現在的新創公司包括我的專案，電腦一定是會提升到符合專案需求，甚至都用SSD，能用幾萬就能解決的問題，何必丟那三百萬到水裡，買頂級的配備給員工用其實是節省專案成本，而且以後每次開發還要額外的時間去編譯等（因為慢），那成本可能還要追加上去。
而且除非用盜版，不然一個專案都用RAD6，光license就吃垮專案，現在的RAD8比較便宜，一個固定使用者license大約是十五萬，不固定就是浮動可以換人用但是同時使用人數還是一人的是二十五萬，這也是為什麼我的專案只買一個license裝一台的因素（手邊的RAD5浮動的價格大約要四十萬一個，所以只買了一個），這專案估計二十人算固定的要三百萬，願意花三百萬買license的話，一百萬的電腦配備大約也不是啥問題。
頂級配備桌機大約五萬內可解決，以剛才的估計大約二十人也才一百萬，幾個月省下的編譯時間就高過了。當然如果閒置人力過多，跟國軍一樣什麼都沒就是有人，我的提議就可以取消了。
就算配備問題都解決了，學習曲線太長又是另外一個問題，BTT每次大改版全部重寫(4,5,6都是全部重寫)，會導致學習曲線陡峭，無痛轉移是說夢話，IBM會說你把所有的程式碼給北京團隊，他們會幫你們轉移後回來，不能測試盲改的東西能用嗎？
列一下RAD 美國售價參考，台灣價格要 call
列一下RAD 美國售價參考，台灣價格要 call sales ，一般來說銀行最少會買一個license，我的專案換成台幣買的比列表上面的還貴。
https://www-112.ibm.com/software/howtobuy/buyingtools/paexpress/Express?...
一個平台転換750支分行交易執行了5年
750支交易，執行了5年。重新開發(永豐丶國泰丶台新丶中國信託-新核心系統含分行系統)也沒這麽久。下次再換個平台，那不是沒完沒了?還不如打掉重作。
Add new comment