極簡風企業系統
企業的IT系統，一定要宛如龐然大物嗎？這麼做不僅勞民傷財，又不見得合用，甚至還會有僵化和過時的風險。因此，日本新生銀行另闢蹊徑，設計和建置新的企業系統，結果把原本會限制成長的IT，轉變為促進成長的利器。
要目精華
許多經理人認為，開發和推動大型資訊科技（IT）系統就像建造倉儲一樣，只要蓋好就算大功告成。但是，這種看法已經不再適用於IT了，一旦採行，就會造出代價昂貴、一啟用便過時的僵化系統。換句話說，目前企業需要的IT，不只要作為現有作業的平台，也要成為能夠提供新功能和新業務的利器。
如何挑選到可支援業務策略、提供競爭優勢並做為成長平台的IT系統，原本就是令人卻步的挑戰，如今的挑戰更加艱鉅。這是因為現在IT處理能力的成本降低、網路功能強大，再加上開發中國家的IT供應商高度發展，使企業面臨為數更多、變化更快、更複雜的選擇。
本文作者提出能因應重大IT挑戰的「路徑法」，那些IT挑戰包括：在專案開始前很難擬出所有需求，而且如此一來將所費不貲，因為人們通常無法事先確定所需的事項；系統一開始運作，總是會出現意料之外的需求；很難說服人們使用和「認可」新系統。
在作者進行研究的期間，日本新生銀行是唯一應用路徑法的公司。新生銀行設計、建置和推展系統，不只協調業務和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）
企業的IT系統，一定要宛如龐然大物嗎？這麼做不僅勞民傷財，又不見得合用，甚至還會有僵化和過時的風險。因此，日本新生銀行另闢蹊徑，設計和建置新的企業系統，結果把原本會限制成長的IT，轉變為促進成長的利器。
要目精華
許多經理人認為，開發和推動大型資訊科技（IT）系統就像建造倉儲一樣，只要蓋好就算大功告成。但是，這種看法已經不再適用於IT了，一旦採行，就會造出代價昂貴、一啟用便過時的僵化系統。換句話說，目前企業需要的IT，不只要作為現有作業的平台，也要成為能夠提供新功能和新業務的利器。
如何挑選到可支援業務策略、提供競爭優勢並做為成長平台的IT系統，原本就是令人卻步的挑戰，如今的挑戰更加艱鉅。這是因為現在IT處理能力的成本降低、網路功能強大，再加上開發中國家的IT供應商高度發展，使企業面臨為數更多、變化更快、更複雜的選擇。
本文作者提出能因應重大IT挑戰的「路徑法」，那些IT挑戰包括：在專案開始前很難擬出所有需求，而且如此一來將所費不貲，因為人們通常無法事先確定所需的事項；系統一開始運作，總是會出現意料之外的需求；很難說服人們使用和「認可」新系統。
在作者進行研究的期間，日本新生銀行是唯一應用路徑法的公司。新生銀行設計、建置和推展系統，不只協調業務和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）
全站熱搜
留言列表
