Transcript 下載/瀏覽
管理資訊系統 主題:極簡風企業系統 企業資訊科技（IT）專案，無論是客製化系統還是適用於大部分企業的套裝系 統，一直都很令企業領導人頭痛。問題在於這些系統的建構方式，程式設計 師開放原始碼建構方式為「大教堂式」，因為這類企業IT專案造價高昂、耗時 費事，而且等到專案完成之後才會產生價值。用這種方式設計出來的系統缺 乏彈性，啟用後，還會讓公司因受制於數年前的營運模式，而日益僵化。儘 管近年來套裝軟體已較有彈性，但價格還是很高，而且公司很難修改系統來 掌握新商機。 經理人不該再建置一啟用便「過時」的系統，應該開發上線一段時間後仍能 快速且持續改進的系統。過去十年來，我們研究了企業IT系統的設計和導入， 並協助許多公司進行這整個流程。我們從中找到可以降低公司成本，也能支 援現有業務成長和拓展新業務的方法，稱為「路徑法」，因為企業不是在專 案啟動前試圖定義系統的所有規格，而是把重點放在提供一條路徑，讓公司 可以長期開發那套系統。我們發展出這個方法，是因為人們通常無法事先確 定有哪些需求，因此若要在專案開始前就擬出所有需求，不但困難而且所費 不貲。此外，系統啟用之後，往往會冒出意外的需求。若要等系統正式運作 後，說服員工使用和「認可」新系統，說來容易做來難。 技術簡單，效果不簡單 不只協調業務和IT策略，且讓兩者整合；運用最簡單的技術；使系統模組化； 讓使用者熟悉體會新系統的好處；確保使用者未來能參與系統的改進。 IT不更新，行動快不了 以便利、易使用和低價位為原則，提供優質的產品和服務。新生銀行提供當 時在日本罕見的服務，包括24小時免費使用的自動櫃員機（ATM）、網際網 路銀行、線上外匯交易、線上雙語銀行，以及即時資料庫一致化所支援的快 速服務。他們無法充分了解零售業務未來的需求，因此認為目標應是建立可 隨著銀行成長而不斷擴充、根據新商機而調整的系統。 技術問題小，人為問題大 若要建立主要的企業系統，通常有兩種選擇：一是「大爆炸」式做法，以全 新的系統和流程，一次取代既有系統；一是以漸進方式，逐步改善或取代既 有系統。後來找出第三種方法，就是設立一套新的模組化架構，一開始會與 現有基礎架構平行運作，但最終會取而代之。以傳統的IT思維看來，這種做法 愚不可及：他們勢必要開發許多連結新舊架構的軟體，這是相當浩大的工程。 IT新系統失敗從來都不是因為技術問題，而是人為問題。人們總是抗拒採用新 系統，原因往往在於成本超過好處。為解決這個問題，使用簡單但創新的技 術解決方案，以避免新系統上線造成令人痛苦的結果。 業務與IT： 先了解再整合 一直以來，人們都認為業務策略和IT策略應該彼此協調配合，但事實證明，這樣做極 為困難，IT領導人很難真正了解商業環境，業務領導人也沒有花時間體會技術的威力 和挑戰，往往將IT人員視為提供服務的次等人員。如果業務領導人將IT人員視為次要 角色而非合作伙伴，就會阻礙雙方人員之間的知識轉移，造成商機流失和績效下降。 企業採用標準套裝軟體時，往往到最後會調整業務的運作，以配合技術。在專案開始 規畫前，高層主管要確定IT人員了解那項業務，並在組織中扮演核心角色。 鎖定目標，非著眼現況 在專案發展過程中，第一步是把焦點集中在可預期達到的業務目標，而不是現有的環 境。太多企業把時間都花在系統如何執行任務，以及用來完成任務的流程。經理人在 確定可預期達到的業務目標後，必須建立符合這些目標的IT策略；這應該是持續的行 動，針對業務目標和IT決策及限制，業務和IT間必須持續互動交流、反覆討論，讓彼 此意見一致。業務小組的使用者讓系統人員了解他們的需求，而IT人員將解決方案的 雛型展現給業務人員看，如此一來，潛在的新解決方案就會浮現。 夠簡單，才夠有力 相同的原則也適用於企業IT系統：設計的標準應該愈少愈好，最好每一項只用一種標 準。組織通常一開始只採用少數標準，一段時日後，由於收購其他公司，以及個別事 業單位的提議，大多數組織會採納更多標準。為符合特定需求而選擇或開發的技術愈 簡單愈好，應該假設過程中會出現技術問題、備妥解決方案，而且要盡量能夠重複使 用。 簡單法則1 標準，愈少愈好 路徑法的關鍵，是將一小組系統元件標準化。簡化IT基礎架構， 讓企業減少複雜度、強化專業技術、重複使用系統元件，這一切 都會加速系統發展和降低維護成本。元件標準化可讓組織減少維 護品質的時間，把焦點放在建置新功能上。 外部的「大爆炸」式軟體供應商提供給企業的最大附加價值之一， 就是減少採用的標準，往往只以供應商自己的專利產品為標準。 大部分IT管理者並沒有權限，也未受過長期訓練，無法把關限制 標準的數目，這表示業務經理人必須理解技術，才能體認為何要 作一些取捨，並協助避開可能會使IT系統分崩離析的例外狀況。 簡單法則2 解決方案，可重複使用 固定採用一個明確的流程，一發現業務上出現問題，就 會把這個問題細分成幾個部分，然後針對每個部分各自 制定技術解決方案。先研究一下公司的標準模組和元件， 看看是否有現成的解決方案。如果公司內沒有解決方案， 就向外尋找現成的解決方案。業務和IT部門的專案團隊， 明確指出必須提供的功能，然後盡量細分所有相關的問 題，這樣一來，就能以更符合成本效益的新方式來解決 問題。以精巧簡單的方案來解決問題，就是IT團隊對記 憶體損耗引發故障所採取的對策。任何作業系統都很容 易發生記憶體損耗的情況，若應用程式在完成一項作業 後沒有釋出它所使用的記憶體，就會出現記憶體損耗， 最後會造成作業系統記憶體不足，以及作業系統不穩定、 甚至毀損。常見的解決之道，是設計複雜的記憶體管理 和除錯工具，嘗試杜絕記憶體損耗的情況，但其實這類 工具無法做到這一點。 簡單法則3 尋求模組化，不只建立模組 一般認為，大型IT方案和系統應由模組組成，這並不是新觀念， 但大多數人往往誤解了模組化的概念。即使軟體開發人員聲稱， 他設計的應用程式裡的各部分都是模組，也不一定表示這真的就 是模組化。真正的模組化應該要明確制定介面，讓開發作業能在 任何一個模組內進行，而不會影響到其他模組；公司在開發企業 系統時，通常會忽略這一點。真正模組化的架構，能讓設計人員 針對某個部分的問題設計解決方案，而不致影響到整體系統。 系統由許多小型的模組化元件組成，若是其中一個元件出問題， 組織就可以採購現成解決方案，或是請企業內部或外部開發人員 針對問題，迅速開發解決方案。採用模組化架構的系統開始運行 後，模組內的技術升級也會更容易。 像這樣將問題分拆之後加以解決，不但快速，還有很多優點，例 如可讓IT團隊集中心力，針對各個部分尋求成本最低的解決方案， 而且因為問題被分拆了，所以能夠降低個別故障點造成的衝擊。 明確訂出模組和介面的功能，就更容易建置能再運用於其他用途 的模組。 建置階段： 適度尊重員工意願 許多大型IT專案失敗，主要是由於組織成員的抗 拒，而非技術的效用不佳。有時候，問題出在公 司想要強迫員工使用新系統，結果遭到員工反抗； 更常見的情況是，員工根本不了解，為什麼要花 工夫學習操作新系統。 一般而言，企業不應把新系統硬推銷給使用者， 而應建置使用者願意接受的系統。這不是說，要 讓組織裡的每個成員都積極採納每一種技術，但 如果新系統上線很久之後，大家還是很排斥某個 系統，公司可能就必須大幅改進那套系統，甚至 廢除。 改進階段： 借重使用者 如果沒有使用者積極參與，任何持續改 進的行動都會失敗。必須主動要求使用者 提供改進企業系統的意見，讓他們參與平 日的試驗，並盡量讓他們覺得自己的意見 很寶貴。 能持續改進，才有效能 企業目前花在IT上的費用，大約為營收的5％。各企業在這方面 的費用高低差異很大，從IT得到的好處落差更大。 如何挑選可支援業務策略、提供競爭優勢並做為成長平台的IT系 統，原本就是令人卻步的挑戰，如今的挑戰更加艱鉅。這是因為 現在IT處理能力的成本降低、網路功能強大，再加上開發中國家 的IT供應商高度發展，使企業面臨為數更多、變化更快、更複雜 的選擇。 在這種環境中，企業必須將焦點放在建立能持續改進的IT系統上。 這一點可能會讓傳統經理人焦慮，因為他們一向認為，建立大型 IT系統就像建造倉儲設備，蓋完了就算大功告成。但這種看法已 落伍，一旦採行，就會設計出成本高昂的僵化系統，而且在啟用 時就已經過時了。企業如果採用路徑法，就能開發出靈活的系統， 視需要而改變，並讓IT脫胎換骨，從既有作業的簡單平台，變成 能提供新功能和全新業務的利器。