本文出自

和風知識經濟

和風知識經濟

2008年6月號

極簡風企業系統

Radically Simple IT
大衛.厄普頓 David M. Upton , 布萊德利.史泰茲 Bradley R. Staats
瀏覽人數:10287
  • 文章摘要
  • "極簡風企業系統"

  • 字放大
  • 多人授課購買
    購買〈極簡風企業系統〉文章
  • 個人收藏購買
    購買〈極簡風企業系統〉PDF檔
    下載點數 10
企業的IT系統,一定要宛如龐然大物嗎?這麼做不僅勞民傷財,又不見得合用,甚至還會有僵化和過時的風險。 因此,日本新生銀行另闢蹊徑,設計和建置新的企業系統,結果把原本會限制成長的IT,轉變為促進成長的利器。

企業資訊科技(IT)專案,無論是客製化系統還是適用於大部分企業的套裝系統,一直都很令企業領導人頭痛。根本問題在於這些系統的建構方式,程式設計師暨開放原始碼提倡者艾瑞克.雷蒙(Eric Raymond)稱這種建構方式為「大教堂式」(cathedral approach),因為這類企業IT專案就像歐洲中世紀巍峨的教堂一樣,造價高昂、耗時費事,而且等到專案完成之後才會產生價值。用這種方式設計出來的系統缺乏彈性,啟用之後,還會讓公司因受制於數年前的營運模式,而日益僵化。儘管近年來套裝軟體已較有彈性,但價格還是超高,而且公司很難修改系統來掌握新商機。

經理人不該再建置一啟用便「過時」的系統,應該開發上線一段時間後仍能快速且持續改進的系統。過去十年來,我們研究了企業IT系統的設計和導入,並協助許多公司進行這整個流程。我們從中找到可以降低公司成本,也能支援現有業務成長和拓展新業務的方法,稱為「路徑法」(path-based approach),因為企業不是在專案啟動前試圖定義系統的所有規格,而是把重點放在提供一條路徑,讓公司可以長期開發那套系統。我們發展出這個方法,是因為人們通常無法事先確定有哪些需求,因此若要在專案開始前就擬出所有需求,不但困難而且所費不貲。此外,系統啟用之後,往往會冒出意外的需求。若要等系統正式運作後,說服員工使用和「認可」新系統,說來容易做來難。

技術簡單,效果不簡單

我們研究了一些應用路徑法的公司,發現一個佼佼者,就是日本新生銀行(Shinsei Bank)。新生銀行投下5,500萬美元的成本,在一年內成功地開發和設置新的企業系統,所費的時間和成本,分別是安裝傳統套裝系統的25%和10%。新系統不僅是管理既有業務的低成本、高效率平台,同時也具備足夠的彈性,可以支援公司拓展新業務領域,包括零售金融、消費者融資,以及在日本銷售印度共同基金的合資事業。

新生銀行在設計、建置和推展這套新系統時採用的路徑法,足為其他公司的楷模:不只協調業務和IT策略,而且讓兩者整合在一起;運用最簡單的技術;使系統真正模組化;讓使用者自行熟悉體會新系統的好處;確保使用者未來能參與系統的改進。其中有些原則是修改傳統原則而來,但有些原則徹底改變了傳統觀念。

IT不更新,行動快不了

新生銀行前身為長期信用銀行(Long-Term Credit Bank),是日本政府在二次大戰後為重建日本產業而設立的。長期信用銀行經營情況日益惡化,累積近四百億美元呆帳後,於1998年宣布破產,由日本政府接管,隨後在2000年賣給美國私募基金利浦伍德控股公司(Ripplewood Holdings),並改名為「新生」,取其「浴火重生」之意。利浦伍德的高階主管說服日本花旗銀行(Citibank)已退休的董事長八城政基(Masamoto Yashiro)復出,擔任新生銀行董事長。八城政基上任後,決定重整既有的商業銀行業務,另外還擬定計畫,打算革新日本的零售金融業務,提出當時在日本獨一無二的價值主張:以便利、易使用和低價位為原則,提供優質的產品和服務。根據這項策略,新生銀行必須提供當時在日本尚屬罕見的服務,包括24小時免費使用的自動櫃員機(ATM)、網際網路銀行、線上外匯交易、線上雙語銀行,以及由即時資料庫一致化(也就是每完成一筆交易,便立即更新客戶帳戶)所支援的快速服務。

八城政基認為,新生銀行必須快速行動,以掌握零售金融業的商機。然而,該銀行既有的IT系統老舊,連原有的業務都無法充分支援。為了處理這些問題,八城政基聘請他以前的同事,也就是日本花旗銀行IT部門主管達南迦雅.杰.德維威帝(Dhananjaya "Jay" Dvivedi)擔任資訊長。德維威帝一上任,就網羅一群優秀人才組成核心團隊,其中許多人是他的舊屬。由於新生銀行投資經費有限,八城政基授權德維威帝改革IT設備,但也讓他了解,他的團隊執行任務時必須「快速」且「省錢」。八城政基和德維威帝都明瞭,他們無法充分了解零售業務未來的需求,因此兩人達成共識,認為目標應是建立可隨著銀行成長而不斷擴充、根據新商機而調整的系統。

技術問題小,人為問題大

若要建立主要的企業系統,過去通常有兩種選擇:一是「大爆炸(big bang)」式做法,以全新的系統和流程,一次取代既有系統;一是以漸進方式,逐步改善或取代既有系統。德維威帝跟他的團隊對「大爆炸」法持保留態度,認為新生銀行資金吃緊,而且他十分清楚這類專案有一些特有的問題,此舉風險太大。但漸進法可能需要花三到五年的時間,又失之太慢。因此,他們決定找出第三種方法,設立一套新的模組化架構,這套新系統一開始會與現有基礎架構平行運作,但最終會取而代之。以傳統的IT思維看來,這種做法愚不可及:他們勢必要開發許多連結新舊架構的軟體,這是相當浩大的工程。

但德維威帝根據先前的工作經驗,以及與其他資訊長的交談得知,IT新系統失敗從來都不是因為技術問題,而是人為問題。人們總是抗拒採用新系統,原因往往在於成本(花費的心力)超過好處。為解決這個問題,德維威帝使用簡單但創新的技術解決方案,以避免新系統上線造成令人痛苦的結果。例如,德維威帝和他的團隊讓新系統在外觀與操作上就跟舊系統一樣,至少如此維持一段時間,好讓人們迅速採用新系統。

儘管零售部門尚未確實轉虧為盈(因為建立這項新業務需要大筆支出,而且日本經濟情況不佳,法規也很嚴格),不過,新的企業IT系統能夠協助新生銀行快速成為日本零售金融市場的要角。2001年時,新生銀行的零售金融客戶僅限於富人階級,人數不到五萬,但到了2007年6月30日,零售金融客戶已經超過兩百萬名。《亞洲銀行家期刊》(The Asian Banker Journal)在2004和2005年時,評選新生銀行為日本最佳零售銀行,而《日本經濟新聞》(Nihon Keizai Shimbun)這份日本最具影響力的商業報紙之一,則於2004、2005 和2006年讚揚新生銀行在客戶滿意度上名列第一。

接下來,我們仔細看看新生銀行的路徑法。

業務與IT:

先了解再整合

一直以來,人們都認為業務策略和IT策略應該彼此協調配合,因此,業務部門的使用者應參與企業系統的設計。但事實證明,這樣做極為困難。原因很多,首先,IT領導人很難真正了解商業環境;此外,業務領導人也沒有花時間體會技術的威力和挑戰,而且往往將IT人員視為提供服務的次等人員。即使IT和業務兩方人員開會討論專案,也僅是偶一為之,並沒有持續開會、反覆討論。但不論你喜不喜歡,資訊系統在現今各行各業都是業務策略不可或缺的一環。如果業務領導人將IT人員視為次要角色而非合作伙伴,就會阻礙雙方人員之間的知識轉移,造成商機流失和績效下降。

使情況更複雜的是,企業採用標準套裝軟體時,往往到最後會調整業務的運作,以配合技術。例如有時候企業會放棄缺乏效率的流程,改採軟體內建的最佳實務。但經理人多半會犧牲系統可以提供的特殊強大功能,因為開發這些功能會使原本就很費錢耗時的專案,開銷更大、需時更久。

在這種情形下,企業應該採取什麼行動來整合IT和業務策略?在專案開始規畫前,高層主管要確定IT人員了解那項業務,並在組織中扮演核心角色。落實這點的一個方法是,讓IT主管向執行長或營運長報告(德維威帝在新生銀行就是如此),而不是像許多大公司一樣向財務長報告。如果人們都認為某件事很重要,那件事往往就會真的變得很重要。

業務經理人也要了解IT可以提供的功能。在新生銀行,八城政基跟他的接班人泰瑞.波提(Thierry Porte)花了許多時間了解IT。波提經常和德維威帝交談,每週至少與他正式開會一次;而且每個月至少視察公司的IT和營運中心一次。波提認為,身為執行長,「我必須能夠向客戶和員工解釋IT,才能滿足客戶的業務需求,持續提供價值。」

鎖定目標,非著眼現況

在專案發展過程中,第一步是把焦點集中在可預期達到的業務目標,而不是現有的環境。太多企業把時間全都花在思索現行系統如何執行任務,以及用來完成任務的現有流程。這如同在老舊的泥土路上鋪新路,於事無補。任何曾嘗試在令人混淆的波士頓或倫敦街上開車的人,都會了解這種方法的後果。

經理人在確定可預期達到的業務目標後,必須建立符合這些目標的IT策略;這應該是持續的行動,也就是說,針對業務目標和IT決策及限制,業務小組和IT小組間必須持續互動交流。雙方反覆討論,讓彼此意見漸趨一致。業務小組的使用者讓系統人員了解他們的需求,而IT人員將解決方案的雛型展現給業務人員看,如此一來,潛在的新解決方案就會浮現。

銀生銀行的IT小組和業務小組建立密切的關係,因此能夠善用技術,改善客戶到各分行辦事時的體驗和感受。例如,新生銀行櫃台服務人員配備了兩個螢幕,一個螢幕面對櫃台人員,一個面對客戶。面對客戶的螢幕和銀行網站上的畫面相同,而櫃台人員的螢幕畫面除了顯示銀行網站畫面之外,還顯示關於客戶的其他資訊。客戶到銀行辦事情時,櫃台人員會向客戶示範如何透過電腦自行進行交易(但不會告知客戶,這是要訓練他日後利用家中的電腦或是ATM,自行交易)。櫃台人員沒有現金,如果客戶想存錢或領錢,櫃台人員會和客戶一起走到ATM旁邊,與客戶一起執行交易。客戶絕不會被迫自行操作,但新生銀行透過IT系統和其他基礎架構(分行、ATM、櫃台人員),可以提高服務層次,並訓練和鼓勵客戶自行處理交易。

櫃台人員也能直接觀察到,哪些交易會令客戶感到麻煩,這提供了許多改進系統的構想。例如,客戶要進行開戶或轉帳等作業,必須先填寫書面表格,然後交給櫃台人員,櫃台人員再將資料輸入系統中。櫃台人員發現,客戶經常拿錯表格或填寫錯誤。新生銀行為修正這個問題而改變流程,讓櫃台人員直接為客戶輸入資料,然後客戶就會看到電腦產生的確認訊息,以便立即驗證。

夠簡單,才夠有力

中世紀哲學家奧坎的威廉(William of Ockham)說,理論應該愈簡單愈好。相同的原則也適用於企業IT系統:設計的標準(例如,網路通訊協定、作業系統和平台)應該愈少愈好,最好每一項只用一種標準。組織通常一開始只採用少數標準,一段時日後,由於收購其他公司,以及個別事業單位的提議,大多數組織會採納更多標準。此外,為符合特定需求而選擇或開發的技術愈簡單愈好,應該假設過程中會出現技術問題、備妥解決方案,而且要盡量能夠重複使用。

簡單法則1

標準,愈少愈好

路徑法的關鍵,是將一小組系統元件標準化。西南航空公司因為只飛波音737客機而獲益,同樣的,簡化IT基礎架構,讓企業得以減少複雜度、強化專業技術、重複使用系統元件,而這一切都會加速系統發展和降低維護成本。此外,元件標準化可讓組織減少維護品質的時間,把焦點放在建置新功能上。

的確,外部的「大爆炸」式軟體供應商提供給企業的最大附加價值之一,就是減少採用的標準,往往只以供應商自己的專利產品為標準。大部分IT管理者並沒有權限,也未受過長期訓練,無法把關限制標準的數目,這表示業務經理人必須理解技術,才能體認為何要作一些取捨,並協助避開可能會使IT系統分崩離析的例外狀況。

德維威帝在新生銀行強力推動標準化,他要相關人員提供意見,但不會等到大家達成共識後才採取行動。

他最大膽的一項決定是,淘汰新生銀行的大型主機系統(傳統的銀行IT主幹),改採內建英特爾(Intel)微處理器的伺服器。這是一大改變,因為日本銀行和全球大部分金融服務公司,多半採用能提供高速傳輸和可靠執行時間的大型主機。問題是,型主機系統價格昂貴,而且維護不易(一般大型主機每年的維護費用,高達原本採購價格的15%到20%);此外,舊式大型主機的軟體,通常是以晦澀難解的專用語言撰寫的,即使是熟悉這個程式碼的程式設計師也很難理解。新生銀行改採伺服器型平台之後,立刻就可以省下一年四千萬美元的開銷。德維威帝跟他的團隊除了選擇單一伺服器平台,還選擇戴爾(Dell)的個人電腦、微軟(Microsoft)的視窗(Windows)作業系統、網際網路、網路電話(IP phone),以及商業系統間的標準傳訊。

簡單法則2

解決方案,可重複使用

德維威帝不希望新生銀行(零售金融單位、商業及投資銀行部門)受到既有技術功能的限制,於是和他的團隊建立了一個架構,讓新生銀行能在業務一出現問題時就加以處理。他們固定採用一個明確的流程,一發現業務上出現問題,就會把這個問題細分成幾個部分,然後針對每個部分各自制定技術解決方案。他們的做法是,先研究一下公司的標準模組和元件,看看是否有現成的解決方案。如果公司內沒有解決方案,就向外尋找現成的解決方案。如果還是沒有,他們會從五、六個印度獨立的軟體服務合作伙伴中,找一家來開發所需的功能。

新生銀行全新ATM網路的開發和建置,是使用路徑法的範例。

2000年時,其他日本銀行不管顧客是使用自家ATM,還是使用同業的ATM,一律都要收費,而且只在分行營業時間內提供ATM服務。新生銀行了解,如果想要提供顧客全天候的免費服務,就不能建置類似其他家銀行的昂貴ATM網路。因此,業務和IT部門的專案團隊,明確指出必須提供的功能,然後盡量細分所有相關的問題,這樣一來,就能以更符合成本效益的新方式來解決問題。

例如,過去ATM都是透過昂貴的租用專線連接到銀行後端(back-end)系統。但團隊了解,網際網路可以提供與租用專線一樣的功能。問題是,網際網路連線的執行時間和可靠性比專線差,簡單的解決之道,就是安裝兩家不同供應商的兩條網際網路線,一旦發生故障,就可以因應。這樣做比租用專線的可靠性更高,而且成本只有十分之一。整體而言,這種新方式讓新生銀行只用少許成本,就能讓客戶隨時使用ATM,而且功能比其他同業使用的傳統網路ATM更多。

以精巧簡單的方案來解決問題,還有另一個例子,就是IT團隊對記憶體損耗(memory leak)引發故障所採取的對策。任何作業系統都很容易發生記憶體損耗的情況,若應用程式在完成一項作業後沒有釋出它所使用的記憶體,就會出現記憶體損耗,最後會造成作業系統記憶體不足,以及作業系統不穩定、甚至毀損。常見的解決之道,是設計複雜的記憶體管理和除錯工具,嘗試杜絕記憶體損耗的情況,但其實這類工具無法做到這一點。新生銀行決定,直接假設記憶體會在伺服器內損耗,並讓記憶體頻繁地固定交錯進行重新啟動;這個解決方案很簡略,但是成效良好且成本低。

不論德維威帝的團隊是在內部自行開發元件,或是請外部廠商供應,都必須讓元件盡可能在新生銀行的其他專案中重複使用。團隊為確保這一點,明確制訂元件必備的功能和標準介面,以確保它可以與任何現有或未來的模組相容。

例如,新生銀行的業務和IT人員很早就知道,銀行提供的許多服務中,檢查信用都是關鍵程序。因此,團隊開發了可重複使用的信用檢查模組,各項產品都可以使用。目前有超過90%的技術元件,可以在至少一項專案裡使用。

簡單法則3

尋求模組化,不只建立模組

一般認為,大型IT方案和系統應由模組組成,這並不是新觀念,但大多數人往往誤解了模組化的概念。即使軟體開發人員聲稱,他設計的應用程式裡的各部分都是模組,也不一定表示這真的就是模組化。真正的模組化應該要明確制定介面,讓開發作業能在任何一個模組內進行,而不會影響到其他模組;公司在開發企業系統時,通常會忽略這一點。

例如,我們知道某家汽車公司的一些團隊,正在開發新企業系統的多個模組,並聲稱採用模組化設計;但其中負責開發介面的小組,經常更改介面。每當這個小組變更介面時,所有其他開發小組都不得不花費大量時間重做原本已完成的工作。這家公司沒有採用模組化以限制變更介面帶來的衝擊,反而讓衝擊擴大!

真正模組化的架構,能讓設計人員針對某個部分的問題設計解決方案,而不致影響到整體系統。系統由許多小型的模組化元件組成,若是其中一個元件出問題,組織就可以採購現成解決方案,或是請企業內部或外部開發人員針對問題,迅速開發解決方案。採用模組化架構的系統開始運行後,模組內的技術升級也會更容易。

像這樣將問題分拆之後加以解決,不但快速,還有很多優點,例如可讓IT團隊集中心力,針對各個部分尋求成本最低的解決方案,而且因為問題被分拆了,所以能夠降低個別故障點造成的衝擊。明確訂出模組和介面的功能,就更容易建置能再運用於其他用途的模組。

若要執行新生銀行的策略,模組化方法是關鍵,如同德維威帝所說,新生銀行的策略是要「輕易擴增、並擴大進行新活動,能在組織逐漸茁壯的過程中隨時滿足需求……而且不會過早建立我們還不需要的功能。」以處理貸款的系統來說,專案團隊分幾個階段推出,理由有三:向管理階層證明,電腦系統會依預期運作;避免一次提供管理者和使用者太多自動化功能,讓他們疲於應付;技術問題出現時,迅速解決。因此,團隊一開始的目標,是讓系統正確核准少量的信用貸款案件(一天二十到三十筆);接著,再擴大功能到一天可完整處理兩百到三百筆貸款。隨著業務擴展,新生銀行取消人工作業,使得銀行一天可以處理六千筆貸款。

拜自動化系統的模組化結構之賜,新生銀行可在不影響其他部分的情況下,直接換掉系統的一部分,例如貸款申請或信用檢查的功能。此外,模組化讓新生銀行能在必要時或者適當時改變IT,而不會干擾到客戶。它可以在變更後端系統時,不改變客戶介面(例如網頁或ATM畫面的格式)。

建置階段:

適度尊重員工意願

許多大型IT專案失敗,主要是由於組織成員的抗拒(使用者破壞新系統),而非技術的效用不佳。有時候,問題出在公司想要強迫員工使用新系統,結果遭到員工反抗;更常見的情況是,員工根本不了解,為什麼要花工夫學習操作新系統。

一般而言,企業不應把新系統硬推銷給使用者,而應建置使用者願意接受的系統。這不是說,要讓組織裡的每個成員都積極採納每一種技術,但如果新系統上線很久之後,大家還是很排斥某個系統,公司可能就必須大幅改進那套系統,甚至廢除。

新生銀行推出新系統時,一開始會先提供類似舊系統的介面或畫面格式。

例如,開始使用新系統輸入貸款申請書的員工,可以進入酷似舊系統資料輸入畫面的頁面,但如果新貸款申請書要求填寫的資訊(比方說客戶的行動電話號碼)沒有包含在舊畫面中,員工就必須進入新畫面來輸入新資訊。使用者像這樣往返於新舊畫面,就會逐漸習慣新系統。等到絕大多數使用者轉換到新系統後,德維威帝的團隊才關閉舊資料輸入畫面。這種方式短期內會增加成本,但德維威帝認為,只要花這麼一點代價,就可以讓大家更快、更積極採用新系統,何樂而不為?

改進階段:借重使用者

德維威帝認為應該一開始就借重使用者的力量,而且在系統建置之後也應當如此,包括「持續改進」的階段。根本原則是,如果沒有使用者積極參與,任何持續改進的行動都會失敗。因此,新生銀行主動要求使用者提供改進企業系統的意見,讓他們參與平日的試驗,並盡量讓他們覺得自己的意見很寶貴。新生銀行了解,使用者如果覺得沒有人聽取他們的意見並快速回應,就不會繼續提供構想。

為此,德維威帝跟他的團隊建立了一個系統來處理客戶、業務單位使用者和技術使用者提出的意見和要求。近幾個月來,這類意見和要求平均一天有一百項左右。各種建議和系統的故障問題都會列入電子工作單(electronic work order),傳送給相關人員。如果問題遲遲未能解決,就會呈報到更高的層級;如果問題解決了,就會通知提出問題的人。

例如,意見回饋系統協助業務領導人發現抵押業務出差錯的地方。如果申請家庭貸款的客戶抱怨,他們已把規定的文件傳給新生銀行,但是系統仍顯示手續未完成,這時,系統會自動通知經理人這項問題,並指派業務和IT團隊找出癥結,加以解決。團隊研究之後發現真正的原因是:銀行已寄給客戶一份應繳交的文件清單,但客戶不確定那些文件是什麼(例如,不知道那些文件是什麼樣子),結果客戶提交的文件是錯誤的。團隊的補救之道是:讓IT系統自動確定每一位客戶應該繳交的文件有哪些,然後把那些文件的樣本寄給客戶。新生銀行確保客戶一開始就寄出正確的文件,因此縮短了雙方處理文件的時間,並提高客戶滿意度。這些聽來或許不像是重大突破,但這正是重點所在。當持續改進成為日常工作的一部分,就不必大費周章去製作激勵員工的醒目標語,或宣揚解決問題的英雄事蹟。

能持續改進,才有效能

企業目前花在IT上的費用,大約為營收的5%。各企業在這方面的費用高低差異很大,從IT得到的好處落差更大。

如何挑選可支援業務策略、提供競爭優勢並做為成長平台的IT系統,原本就是令人卻步的挑戰,如今的挑戰更加艱鉅。這是因為現在IT處理能力的成本降低、網路功能強大,再加上開發中國家的IT供應商高度發展,使企業面臨為數更多、變化更快、更複雜的選擇。

在這種環境中,企業必須將焦點放在建立能持續改進的IT系統上。這一點可能會讓傳統經理人焦慮,因為他們一向認為,建立大型IT系統就像建造倉儲設備,蓋完了就算大功告成。但這種看法已落伍,一旦採行,就會設計出成本高昂的僵化系統,而且在啟用時就已經過時了。企業如果採用路徑法,就能開發出靈活的系統,視需要而改變,並讓IT脫胎換骨,從既有作業的簡單平台,變成能提供新功能和全新業務的利器。

(林麗冠譯自“Radically Simple IT,” HBR, March 2008)



大衛.厄普頓 David M. Upton

(dupton@hbs.edu) 哈佛商學院企業管理講座教授。


布萊德利.史泰茲 Bradley R. Staats

(bstaats@hbs.edu) 哈佛商學院科技和營運管理組博士候選人。