魚骨圖、因果圖與問題解決思考流程

魚骨圖（Fishbone Diagram）有許多不同稱謂。有人稱他為石川圖（Ishikawa Diagram），因為這方法是日本品管大師石川馨（Kaoru Ishikawa）所創。也有人稱為因果圖（Cause-and-Effect Diagram），因為魚骨圖的魚頭通常表示某一特定結果（或問題），而組成此魚身的大骨，即是造成此結果之主要原因。其他也可稱為樹狀圖（Tree Diagram），因為魚骨形狀與樹狀結構接近。然而，不論稱謂為何，魚骨圖都與問題解決思考流程脫不了關係，並且是一個簡單呈現結果與成因圖形表示法。

魚骨圖的使用很簡單，並且通常搭配腦力激盪法（Brain Storming）進行。首先在魚頭紀錄或寫下待解決之問題（例如不良率增加是一個問題），或是某一表徵觀測現象（例如公司營收下降）。之後，召開會議，並透過團體腦力激盪寫下大家認為造成此結果之主要原因。實際操作上，會議主持人可要求與會成員，每人先憑空想像3個原因，之後再經由小組成員系統化的分類這些原因。將相關原因歸納後之主原因即是大骨、子原因即是中骨、孫因素即是小骨。需要注意，魚骨圖繪製過程需將麥肯錫MECE原則牢記在心，見【麥肯錫的MECE與代數正交基底】，也就是說，各原因之間需要彼此獨立，且互無遺漏。

為了要將”原因”有系統的整理與分類，管理或是品質管理學上所應用的技巧可套入此架構，當成是思考與分類之基礎（亦即基底），包括Wikipedia建議之6M、8P與4S原則：

The 6 M's：Machine, Method, Materials, Measurement, Man and Mother Nature (Environment) （應用於製造業）

The 8 P's：Price, Promotion, People, Processes, Place / Plant, Policies, Procedures & Product (or Service) （應用於行政管理與服務業）

The 4 S's：Surroundings, Suppliers, Systems, Skills（應用於服務業）

當然，先前不同文章所提到分類法，包括4M（見【工程問題規劃與解決的訣竅 - 4M問題分析法】）、PEST或STEEPLE（見【SWOT、PEST與五力分析】）、專案管理的五大流程與九大知識領域（見【專案管理與專案生命週期】）、市場行銷4C與4P（見【行銷策略與行銷組合（中）】）、6管（包括產、銷、人、發、財、資）等亦可應用於”原因”（Cause）的建構（Construction）與分解（Decomposition）。

有魚骨圖表達原因與結果關係，便可產生反魚骨圖來表達問題解決步驟與模式，如圖二所示。

舉例來說，若生產線發現之結果為”A產品不良率太高”，如圖三所示，則分析與歸納後可得到之原因為1.人員素質低落（人）；2.設備可靠度低（機）；3.材料品管不確實（料）；4.製程方法老舊（法）。則反轉魚骨所得到”降低A產品不良率”之方法，分別為1.為加強教育訓練（人）；2.增加設備維護保養頻率（機）；3.尋找替代供應商（料）；4.創新研發新工法（法）等。換言之，問題根本原因若可嚴謹分解，則解決途徑幾乎也算完成一半了。

比較魚骨圖與金字塔原理（見【金字塔原理與倒金字塔模型分析架構介紹】），可以發現，其實魚骨架構與金字塔架構模式一致，分類架構也相似，不同點僅在於金字塔架構以最終結果為焦點，而魚骨圖以問題解決為核心。最後，從魚骨圖與金字塔原理應用我們也可以發現，一個清晰邏輯加上好的問題挖掘與分類方式，就算無法讓問題不再發生，至少也可避免問題的蔓延與擴大，並加速現有問題解決。 (圖3)

時機歹歹 有什麼專案可耗資百萬甚至千萬？

ZDNet 蔡宜秀

經濟真的很不景氣嗎？為何還是聽到不少企業參考資訊基礎架構庫（ITIL）重整資訊服務管理流程（ITSM）、甚至不排除進行ISO 20000認證？如優易資訊、中華電信、資策會、宏瞻資訊、台電、水利署、聯合醫院、群益證券、第一銀行、安泰人壽、緯創、英業達、神達電腦及華碩電腦…等

只因上述公司在金融風暴發生前就決定這麼做？沒錯，上述企業多半都是金融危機發生之前（2008年Q3前）就決定這麼做，不過，這可不代表參考ITIL重整資訊服務管理流程（ITSM）對企業來說，沒有任何效益，讓我們一起來看看ITIL之於企業的意義吧！

誰買單─ITIL效益何在？

持平而論，參考ITIL微調或重整資訊服務管理流程的企業雖然很多（畢竟ITIL這個架構講的內容即是IT人員的日常工作），但願意公開、或者是進行ISO 20000認證的企業則不是這麼的多，因此，我將從解析那些參考ITIL重整資訊服務管理流程，並進行ISO 20000認證的企業案例，釐清促使企業借鏡ITIL、甚至是進行ISO 20000認證的原因。

系統服務供應商欲藉ITIL彰顯服務品質。根據英國的資訊科技服務管理論壇（itSMF）官方網站，截至2008年底，台灣共有中山科學院、台灣IBM、環保署、宏碁eDC、KPMG、工研院、精融網路、科學工業園區管理局、遠傳電信及異術科技等10個單位取得ISO 20000證照，若進一步細究上述公司屬性，可發現，系統服務供應商佔六成。

這意味著，系統服務供應商為強調自己的專業度、吸引企業客戶青睞，除積極於強化自己的服務品質，如ITIL有助於標準化資訊服務流程，還會透過取得第三方機構認證彰顯服務品質，如ISO 20000與ISO 27001等。

除了系統服務供應商欲藉ISO 20000標準化作業流程與彰顯服務品質，服務導向企業也需要ISO 20000統一內部作業流程與`變員工作業習慣，對那些資訊系統工具與資訊服務品質優劣將決定其所提供的產品或服務好壞的企業來說，尤甚如此，如中山科學院、KPMG、科學工業園區管理局與遠傳電信等。

除了上述企業，根據宏碁eDC副總張善政與台灣惠普專案經理杜明智於日前發表的言論，業已有不少製造業透過ITIL重整資訊服務管理流程、提升服務品質，進而向國外顧客宣示服務能力。

從ITIL到ISO 20000的原因？

「會參考ITIL重整資訊服務管理流程的企業，不一定會進行ISO 20000認證。」張善政表示，企業之所以會決定參考ITIL重整服務流程，是因為，每個企業或多或少的都已經落實了ITIL規範（建議）的作業流程，舉例來說，每個企業資訊部都有所謂的事件管理與問題管理等作業機制，差別只在於成熟度不一，在這樣的狀況下，若ITIL強調的「最佳化」恰好有助於其改善問題，企業在改善資訊服務管理流程時，多半會願意借鏡ITIL的最佳實務，但這不代表其願意進行ISO 20000認證，這除與ISO 20000認證不易取得有關，如得整理出許多驗證文件資料，另外一個理由是，取得ISO 20000之於企業，無立即可見的效益。

但這不代表所有企業都不願意進行ISO 20000認證，根據歐美亞等地的案例來看，仍有不少企業基於法規規定（如沙賓法案）、客戶要求（如印度的軟體公司），進行ISO 20000認證，當然，純粹因為認同而進行認證的企業，也不在少數。

真實效益在哪裡？

ITIL有助遠傳電信提升服務動能。遠傳電信資訊科技事業部策略暨品質管理部經理邱志威表示，參考ITIL重整遠傳電信的資訊服務管理流程（ITSM），不僅有助轉換資訊人員的服務態度與行為，亦可提升資通訊服務品質、員工對資訊服務的滿意度、顧客滿意度以及營收獲利。

「安泰人壽自2006年底參考ITIL重新規劃與部署資訊服務管理機制至今，除成功的管控資訊服務品質外，亦大幅提昇了員工對資訊服務的滿意度，以及降低資訊投資成本，」身負以以資訊服務提昇營運效率與效能等重責的安泰人壽（ING）行政支援部副總經理褚秋群指出，安泰人壽除將使用者（指員工）對資訊服務的滿意度拉升至94.39％，業已成功降低24.5％的資訊投資成本。

而以IBM的MRO、CMDB與TBSM等系統，部署事件管理、問題管理、變更管理、上線管理與組態管理等服務支援（Service Support）機制的中華電信總公司資訊處處長陳明仕表示，對中華電信來說，借鏡ITIL的效益有四，分別是將稽核要點內化成員工的日常工作事項、透明化帳務處理流程、資訊人力資源最大化及累積知識文件等。

陳明仕舉例道，透過擬定與帳務相關的標準作業程序，北區與南區帳務中心的同仁得以一致的作業準則行事，而不是先各做各的，最後再進行整合。

落實ITIL的撇步

從遠傳電信、安泰人壽與中華電信等企業的現身說法，可發現，ITIL之於企業的效益挺多，諸如一致的資訊服務模式與高員工滿意度等，對欲將資訊部從原先的支援導向轉型成服務導向的企業來說，ITIL確實有其參考的價值…但因上述效益多半不易量化，且上述效益多無助於立即提升營收獲利，企業資訊主管甚難一定得花大筆銀兩才能嗎？這倒是未必。

認定ITIL確實有助於提昇企業營運績效並決定參考後，建議企業先進行ITIL健檢，健檢項目包括資訊系統架構的複雜度、現行資訊服務流程、員工對ITIL的認知程度及欲優化的資訊服務為何等，理由是，透過ITIL健診機制，企業不僅可以了解「as is」與「to be」，亦可大致掌握該以自動化工具或人工作業的方式，落實ITIL的規範…

那麼，健診工作由誰做？企業可以自己作也可以委外，若要自己進行，建議先培訓一至兩名了解ITIL的人員。

怎麼培訓人員？建議企業可以透過派員至itSMF官網或itSMF台灣分會官網下載ITIL白皮書，以及參加以ITIL為主題的研討會等方式，釐清ITIL為何…上述方法雖較為陽春，但確實有助企業大致摸清ITIL，但因該種方式較不全面，而且企業可能在陸續蒐集相關資料得同時對ITIL產生誤解，如以為ITIL有告知怎麼最佳化資訊服務管理流程，因此，若是企業手上還有點經費，建議派員至補教單位聽課，並由其負責對內宣導。

在改善資訊服務作業流程這點，建議企業資訊人員先以熟悉的資訊服務為範圍，如事件管理等，試著依照ITIL（v2或v3皆可）的規範事項，以人為作業或自動化工具等方式重整作業程序，確定掌握ITIL的精髓後，在視需求逐步擴大管理範疇。

總的來說，企業不一定得投資數百或千萬聘僱諮詢顧問、外購軟體工具才能規劃出符合ITIL規範的資訊服務管理機制，除非，企業的資訊系統架構複雜到一個極致、資訊人員無時間自行開發所需工具等。

ITIL的誕生與演進

陳光楷

2007年五月底正式發佈的ITIL v3，再度攫獲了巿場對ITIL的注意力。由於資訊技術（IT）的生命週期愈來愈短、管理環境愈趨複雜與變化速度愈來愈快，連帶地，相關的規範與最佳範例就必須再做強化及更新，ITIL v3的出現亦然。
由來

ITIL（Information Technology Infrastructure Library）最早出現在1980年代，主要是英國政府希望藉由業界最佳實務，以結構化的作法來提升IT部門的服務品質，因而編寫出一套描述作業流程與最佳實務的叢書。

發展迄今，ITIL已被視為落實IT服務管理的要件。也正因為如此，當IT組織尋求IT服務管理的改善之道時，幾乎都會採用及實踐ITIL所建議的流程與實務。

IT服務管理風潮

然而，1980年代就已發佈第一版的ITIL，為何直到近幾年來備受重視，甚至捲起一陣ITIL風潮？關鍵就在於IT組織當前所面臨的壓力及挑戰日益倍增。

IT已經深入企業的運作脈絡之中，成為不可或缺的營運要件，企業對IT的期望及要求也愈來愈高，一方面要提升運作效率及支援效益，另一方面又要控管成本及提升投資報酬率。

分析IT組織主要面臨的挑戰，大致可歸類為4C，也就是變動（Change）、法規（Compliance）、複雜度（Complexity）與成本（Cost）。這四個C相互影響，環環相扣，但傳統的IT環境以技術為導向，造就了許多互不相通的壁壘與區塊，缺乏整體縱觀的觀點與全面整合的作法。

ITIL正是為上述困局解套的關鍵。許多人眼中的ITIL，是服務管理的同義詞，事實上，ITIL v2的內容遠多於此。在ITIL v2的叢書裡，涵蓋了業務目標、IT服務管理、應用程式管理、軟體資產管理、安全管理、ICT基礎架構管理。但巿場公認，ITILv2最精華的內容當推IT服務管理(IT Service Management) ，ITIL裡的IT服務管理由服務供應、服務支援兩大區塊所組成，服務支援偏向運作面，以日常作業內容為重；服務供應則偏戰術面，主要在訂定策略計畫，以管理日常作業內容。這也是為什麼一提到ITIL，就會直接聯想到IT服務管理的原因。

ITIL新舊版本與其他標準規範的相輔相成

有人認為，ITIL v3的出現等於是取代ITIL v2，其實不然。ITIL就像是一套愈來愈完整的百科全書，這套百科全書是由v1、v2、及v3共同組成，每個版本都有各自的叢書內容，v3是在增修及補充v2的不足之處，例如；

1.v2較缺乏導入所需明確的指導方針(how-to guidelines)
2.v2部份流程重疊並且不明確(Change與Release Management)
3.v2缺乏IT治理的相關流程並僅涵蓋部份IT管理的流程


ITIL V3 VS ITIL V2

ITIL v2與ITIL v3最大的差異在於，ITIL v2是以作業流程為導向並著重於流程執行所需的最佳典範(Best Practice)，ITIL v3則採用生命週期的觀念，強化IT與業務面的對應，同時增加了更多實作方法，主要內容包括(Five Core Books)從服務策略的制定以符合企業的需求、服務設計、服務轉換、服務運行，以及持續改善服務。

異曲同工

值得注意的是，除了ITIL之外，業界還有許多作業標準規範與專業認證，內容與ITIL或有重疊及互補之處，業界流程相關標準規範與專業認證目標差異如下圖:

流程相關標準規範與專業認證 目標
CMMI (Capability Maturity Model Integration) 改善專案相關流程
COBIT (Control Objectives for Information and related Technology) version 4.1 IT 治理
ISO 17799 評量資訊安全管理導入成效
ISO 20000 評量IT服務管理導入成效
ITIL (Information Technology 提供IT管理流程最佳典範
Infrastructure Library)
Six Sigma 提供持續流程品質改善的方法

以ISO 20000為例，它在2006年正式成為IT服務管理的國際標準規範，內容可與ITIL相輔相成。但最大差別在於ISO 20000會評量企業的實踐成果並授與認證證書，ITILv2的實踐則並未搭配任何認證制度。ITIL v.2的導入可透過ISO20000的標準來評量企業的流程是否已經到達IT管理成熟的階段。但v.3超過ISO 20000的標準，企業要評估的是需不需要導入超過那些標準的投資(ROI)。

也正因為如此，歐美國家偏重導入ITIL並以改善自我管理流程為目標，亞洲國家則獨鍾透過ISO 20000導入以取得認證以驗證ITIL導入的成效。

另一個常被提及的標準規範則是COBIT。ISACA（國際電腦稽核協會）在1996年首度提出COBIT（Control Objectives for Information and related Technology），它的性質偏重在策略規劃，以及控管點查核，因此，最用來稽核IT治理或法規遵循的控管目標，ITIL則可視為落實這些控管目標的框架，所以，ISACA在去年也發佈了一份名為「Aligning COBIT, ISO17799 and ITIL」的文件。

不同的標準規範各有訴求重點，而IT服務管理應該從使用者的角度，來決定採行的標準，例如若企業IT服務重點在營運面的改善(Operational Improvement)， ITIL的導入與ISO20000的落實驗證便很適合；若是治理或規劃的需求，則與COBIT（Control Objectives for Information and related Technology，資訊與相關技術控制目標）成為最佳搭檔。因此，根據企業需求的輕重緩急，選擇最合適的標準規範與作業實務，才是最佳的解決之道。

作者為台灣IBM IT服務管理資深顧問暨ITIL認證服務管理經理

落實ITIL的四加四法則

陳光楷

ITIL已經成為落實IT服務管理的公認選擇，但在現實世界裡，質疑的聲浪或失敗的實例仍層出不窮，到底原因何在？

Forrester Research就指出，ITIL導入的成功或失敗，其實都有清楚的模式可循。因此，Forrester Research建議，千萬別想要一步登天，畢其功於一役，而是要以階段式作法來落實ITIL。

循序漸進四階段

ITIL的導入必須採取階段式作法，才能確保成功。 IBM以參與ITIL內容制訂及增修的經驗，結合長期累積的客戶實務，提出了ITSMDD（ITSM Detailed Design）方法論，將導入ITSM的四個階段依序劃分為評估及規劃、高階設計、導入解決方案、及服務上線。

四加四法則
在第一階段的評估及規劃裡，必須儘可能地完成全面性的成熟度評估，接著才擬定策略，並從中選擇優先次序以制定ITIL的導入藍圖與應有的效益分析。以整體專案的資源與時程來看，評估及規劃階段所占的時間與成本應約占全ITIL導入所占的時間與成本10%至15%。

完成評估及規劃階段之後，接下來就是依據導入的藍圖進入高階設計的第二階段，其主要目標就是建立ITSM導入所需的框架。最關鍵的就是全盤考慮四大要件，也就是流程、組織、技術與資訊。

而在第三階段導入解決方案，對應於高階設計的成果，對於工具的需求及條件制訂以決定如何設定與調適系統管理工具，並且完成所有的細項設計工作，並實際將測試環境架設起來，檢驗其成果是否能達到預期之目標，同時，決定推廣與安裝計畫。

第四階段才是真正開始提供服務，上線之後，除了確保順暢運作之外，同時也要對服務供應進行管理並依據PDCA (Plan-Do-Check-Act) 機制對流程或服務管理作持續不斷的改善。

值得注意的是，企業為求快速導入或被巿場訊息誤導，常會認為採用工具就等於導入ITIL，這種作法等於是跳過第一及第二階段，直接進入第三階段，還沒畫出施工圖，就直接要蓋房子，結果就是「欲速則不達」。Gartner Group就有研究指出，企業未能事先訂定明確的整體目標與導入藍圖、對投資報酬率抱有不切實際的期望，以及誤以為單純投資工具就能直接套用流程的想法，正是失敗的主因。

全面考量四大要件

想要成功導入及落實ITIL，從第一階段的評估及規劃到第四階段的提供服務必須同時考量ITIL成功導入的四大要件：流程、組織、技術、資訊，缺一不可。必須注意的是，組織（人員）正是串連其他三大要件的主軸。

從流程面 (Process)來看，評估現行流程並明訂流程目標與指導原則、制定標準流程與活動、明訂流程與流程的關連性、標準流程與活動的文件化、明訂流程持續改善的機制。

而在組織面 (Organization)，則要明確指定流程負責人（Process Owner）、制定標準流程活動所需的角色與職掌、制定標準流程活動的角色應有的技能、成立資訊管理委員會以確保IT提供的服務符合業務面的需求、人員的溝通與教育訓練。

至於資訊面 (Information)，必須制定符合OLA（Operation Level Agreement）的流程CSF（Critical Success Factor）與KPI（Key Performance Index），以落實SLA（Service Level Agreement）的要求；此外，更必須依KPI制定相關管理表。

另在技術面 (Technology)，最主要的工作內容就是導入流程管理工具，必須考量的關鍵則在如何與既有的管理工具進行整合。

Meta Group曾指出，外聘專家往往是導入ITIL的成功關鍵。根據分析，由於缺乏經驗所導致的事倍功半，企業自行導入ITIL最佳實務的成本將高出55%，來自專家經驗的建議，也有助於避免投資報酬率被稀釋等常見問題發生。因此，適時地引進外力於導入的各階段來提供支援，將有助於ITIL的導入。

最後企業也必須體認到，ITIL並非萬靈丹，無法在一夕之間改善IT管理的效率與效益，也不能一體適用於所有企業。換言之，ITIL提供的是一套可供參考的架構框架，導入時企業必須根據實務現況及需求來做調整。

作者為台灣IBM IT服務管理資深顧問暨ITIL認證服務管理經理

ITIL導入效益難衡量？

ZDNet 記者鍾翠玲／台北報導

人人ITIL漸漸增溫，不過如果企業主想看到立即而明顯的效益的話，可能要失望了。

近兩年來國內企業界興起ITIL的學習與考證照風氣、甚至可望在明後年引燃IT投資熱潮。不過分析師與廠商都提醒，ITIL專案並不能與傳統IT技術導入的專案等同視之，它也不會像導入其他IT系統一樣可以產出、甚至可以衡量明顯的投資報酬率。

ITIL (IT Information Library) 是將企業IT視為服務公司業務使用者的部門，ITIL提供一套框架說明企業IT營運，包括基礎流程如服務台(Service Desk)、意外、問題管理、組態、變更、上線等等以及較進階的問題，如服務層級、容量、服務永續、可用性等作業之管理方式。在框架中，基礎與進階流程管理，兩部分可分別歸納為服務支援（service support）與服務傳遞（service delivery）。ITIL源自英國英國，目前已有澳洲、南非、韓國等政府相繼訂出ITIL相關標準。

國內IT界吹起ITIL風。過去兩年以來，相繼有包括IBM、HP、昇陽等廠商，到宏碁等企業派人取得ITIL最高層，即ITIL Server Manager之證照，而取得ITIL 基礎認證者更不在話下。根據IDC報告指出，今年上半年以ITIL為主軸的系統管理專案導入是大型企業推動IT治理(IT governance)的重點執行項目之一；ITIL觀念的推廣已經由軟體業者的推廣，進入到企業內部自行對資訊運作管理的一環。

不過ITIL顧問廠商精誠資深顧問吳傑表示，ITIL作為一種理論，宗旨在藉由人與技術相關流程的改善，達到「IT能量(capacity)」最佳化之目的。「如果企業主想看到立即的效益，那不一定看得到，」他說。

他以消防隊出動救火為例，「因為完整的ITIL就在企業的日常營運流程中，不是像導入IT系統可以半年、一年間結束，並看到明顯的ROI（Return on Investment）。」

分析師也有同樣觀點。IDC分析師陳志杰指出，不像導入客戶關係管理(CRM)可協助拓展客源，它是將IT涵括在業務策略目標下的管理行為，很難去衡量KPI。

「ITIL專案是將IT視為一種資產做IT投資組合(portfolio)管理，以便達成商業適應性(business adaptivity)的目標，」他說。「也就是說，企業必須先要清楚自己要做什麼、目標在哪，否則依賴產品導入或廠商顧問，你很難看到什麼效果。」

例如，企業為了提升回應時間，在此目標之下訂出流程及IT的自動化的目標，必須導入IT資產的清查。

除了內在動力之外，企業也可能受到外在競爭因素而導入ITIL。吳傑也指出，像是PC ODM廠商為了接單，則可能在國際客戶要求下，實行ITIL來改善與供應商聯繫的管道。

雖然不易看到立即效果，但不代表無法估量。陳志杰指出，企業還是可以訂出大致的KPI，像是系統回應時間、網路斷線時間、IT工作負擔是否因為自動化下降等。

吳傑則建議小贏策略，也就是從特定IT服務做起。例如將即使是5個人的IT部門分成一線與二線服務台(help desk)，由一線服務台接聽所有公司使用者IT問題的求援電話，如此就可以計算一線服務台每月接聽的電話是否因為支援效率提升而減少。

「正因為它與流程息息相關，企業要長時間來感受到改變，但你不做最後就完全沒有效益可言。」吳傑指出。

ITIL第三版 增服務生命週期概念

記者馬培治／台北報導
IT服務管理架構ITIL第三版(ITIL v3) 2007年五月底發佈，不但新增服務生命週期概念，亦強調業務(business)在IT架構中扮演的角色。

美國IT服務管理論壇(itSMF USA)宣傳部主席、ITIL v3審閱人之一的Robert Stroud昨(10)起應CA(組合國際)邀請，來台介紹新版ITIL的特色以及與舊版本的差異。ITIL v3除了內容更精簡，文件份量由v2的10本書減少為5本，更採用了服務生命週期的循環、而非流程的線性概念，希望能藉此增加ITIL架構的彈性。

ITIL (Information Technology Infrastructure Library, IT基礎建設集成)是一套方法論，由英國政府商務部(OGC)在1980年代推動的政府計劃開始，並陸續在90年代推出第一版、2000年推出第二版，第三版則是於今年5月30出版，專司推廣ITIL的國際性非營利組織IT服務管理論壇(itSMF)，並陸續向全球各地推廣新版本。

ITIL v3共包括了服務策略(Service Strategy)、服務設計(Service Design)、服務變遷(Service Transition)、服務運作(Service Operation)以及持續服務提升(Continual Service Improvement)共五大領域，各有一本專書提供理論基礎與部署方法論。

ITIL v3是以同心圓的結構來框架上述五大領域。Stroud表示，以服務策略做為圓心，即一切IT服務的基礎，第二層則由服務設計、服務變遷與服務運作三者的循環運作包覆核心，象徵服務由策略發想到設計、變化與上線運作組合成一個服務的「生命週期」。至於最外層，則是持續服務提升，使企業在面臨變革的情況下，IT服務亦能快速反應。

「商業服務會隨著客戶要求與組織目標的改變而改變，」Stroud解釋道，由於企業經營充滿變數，IT服務的框架亦必須能滿足變動的需要，他認為，過去以商業服務流程(business service process)的觀點來看IT服務，已不足以應付企業實際經營環境中，可能經常變動的業務目標，也因此新版ITIL改採生命週期的觀點視之，而非是線性的流程。

雖然強調改變觀點，但ITIL專書由第一版的40多本，一路縮減到如今的5本，也容易讓人懷疑是否ITIL的視野也跟著縮小。對此，Stroud表示，書的數量並非重點，內容是否精要更為關鍵。

他解釋，v3的5本書僅是「核心讀本(core books)」，包含ITIL核心理論與實作方法，對於不同產業別或企業規模，則另有補充讀本(complementary publications)，以及未來將新增的網路支援服務(Web support Services)來補足。

「例如中小企業專屬的ITIL，」Stroud表示，目前已有提供規模較小的中小企業專用ITIL方法論專書「ITIL Small Scale Implementation」，僅挑選核心的元素，例如變更管理、事件管理等必要項目。

不過Stroud強調，雖然該書乃針對小規模需求特別編寫，但仍將未來的擴充性考慮在內。Stroud表示，中小型規模ITIL方法論在提供一套規模比較小的ITIL作法之外，更注重中小企業在未來持續發展過程中，能否因應組織目標改變的可能性，「類似演化的觀點，讓架構可以隨著企業發展階段而調整」，他說。

新版國際標準審核中
至於配合ITIL v3的新版ISO認證，Stroud表示已由國際標準組織的工作小組審查中，但推出時間尚難估計。

Stroud表示，ITIL對應的的國際標準為ISO 20000，但採行的是ITIL v2的內容，配合v3的發行，亦已同步進行標準審查作業，但他說，由於v3才剛發行，且標準審核通常曠日費時，「新版國際標準最遲可能還得再等三到五年，」Stroud說。

IBM： ITIL不是IT服務管理的唯一聖經

記者馬培治／台北報導

面對近來相當熱門的ITIL話題，藍色巨人IBM認為，要做好完善的IT服務管理，除了ITIL，CMMI、COBIT等標準也應納入考慮。

近日來由於itSMF（IT服務管理論壇）台灣分會成立，加上ITIL(IT Infrastructure Library, IT基礎架構集成)第三版的推出，ITIL一時之間成為廠商與企業間的熱門話題，CA、BMC與HP上個(7)月以來更相繼舉辦關於ITIL的活動，總共吸引逾千位企業代表出席。不過，按兵不動的IBM認為，ITIL登上話題熱潮固然有助於市場推廣，但更強調「做好IT服務管理，CMMI與COBIT等標準也應納入考慮，」IBM高層表示。

「企業應該評估目前需要提升的IT服務管理領域，選擇適合的標準遵行，」IBM架構服務與IT策略執行顧問Michael Shallcross表示，IT服務管理應該從使用者的角度，來決定採行的標準。他解釋道，若企業IT服務重點在營運面(operational)，ITIL便很適合；但若企業IT的主要使用者是開發，則應採CMMI（Capability Maturity Model- Integrated，能力成熟度整合模式）；若是治理或規劃，則為COBIT（Control Objectives for Information and related Technology，資訊與相關技術控制目標）。

IBM全球IT服務事業部顧問經理陳俊昌則說，IBM自1983年以來便已自行發展一套專屬的ITSM架構與方法論，此外也參與ITIL相關標準的制定與出版品編寫，「ITIL只是ITSM的一環，企業可以依據自身發展狀況與需求，同時採用諸多標準的精華，」他說。

ITSM(IT Service Management, IT服務管理)為1980年代英國商務部(OGC)提出的概念，是在將IT視為服務的前提下，透過管理的手段，來提升、確保IT服務的品質。OGC與並據此發展出ITIL架構，欲以流程與方法論協助企業達到良好ITSM的目標。也因為ITIL是針對ITSM所制定而成，使得一般企業一聽到ITSM，便會自然想到ITIL。

不過由於IT服務定義廣泛，軟體開發、IT治理等亦會影響IT服務品質的內容，也因此被認為應納入ITSM的範圍，這也是為什麼IBM認為CMMI與COBIT的應與ITIL一併列入ITSM範圍的理由。
研究機構IDC企業應用研究經理曹永暉回應IBM的說法表示，ITIL是達到良好ITSM的途徑之一，但不是全部。

「但國內企業偏好採用既存的標準，因此一提到ITSM，企業往往會先想到ITIL，」曹永暉認為，ITIL雖以最佳實務(Best Practice)的觀點提供企業提升ITSM的準則，但畢竟沒有兩家企業是完全相同，他認為，與其追隨單一標準，企業不妨以ITIL架構為基礎，發展自有的IT服務管理流程。

其它業者亦認同ITIL不是絕對，但確是進行ITSM很好的參考準則。CA資深技術顧問江禎義便說，要做到良好的ITSM，ITIL當然不是惟一的途徑，但他認為，對於沒有資源自行開發管理流程的企業來說，「有現成的標準可參考，會比較容易，」他說。

不過，對IBM提出CMMI與COBIT等標準亦應納入企業ITSM規劃，曹永暉認為，其他廠商未必不知道ITSM包含範圍不止ITIL，而是市場行銷的考量問題。他認為，IBM同時提出ITIL、COBIT與CMMI，有利於產品的整合銷售，「不是每家推廣ITIL的廠商，產品都像IBM一樣完整，」曹永暉說。

專家：ITIL不是萬靈丹

記者馬培治／台北報導

ITIL議題正熱，但專家卻發出了不同聲音，指ITIL並非能解決所有問題、適用所有組織的萬靈丹。

推動ITIL的國際組織IT服務管理論壇(itSMF)創始人之一、CA ITIL實踐經理兼榮譽副總裁Brian Johnson今(22)日表示，ITIL(IT Infrastructure Library, IT基礎架構集成)只是企業IT流程設計的參考框架，非但不是放諸四海皆準的標準(standard)，更不是可套用在任何組織的通用架構(One size fits all)。「若你的組織適合ITIL，便拿去用；若不適合，不如不用，」Johnson說。

ITIL是英國商務部在1980年代為提升IT服務管理水準，主導研發的一套IT服務框架與方法，並出版一系列參考書籍，至今已發展到第三個版本。一般而言，採用ITIL框架有助於提升企業IT服務品質與效率、減低IT維運成本與意外發生之可能性，並進而反映到業務品質與積效的提升。

「ITIL的真正核心在於企業的需求，而且真的願意且需要改變，」Johnson表示，ITIL本身是一套框架與方法，用來協助企業打造好的IT流程，使IT服務能和企業的業務目標結合，「企業本身流程若已經運作良好，未必需要再改採ITIL的框架，」他說。

顧問業者則更直指ITIL並非關鍵所在。 「關鍵是改變 ，而非ITIL，」顧問業者Quint顧問黃以任便說，企業必須先體認到既有流程有改變的需要，再來評估後續步驟，「至於是不是用ITIL，那並不是重點，」她說。 分析師亦對其看法表示認同。IDC（國際數據資訊）企業應用研究經理曹永暉便說，實務面來看，ITIL的確有可能提高企業的IT服務乃至業務水準，「但若企業的文化不適合，硬是採行ITIL的結果可能會是一場災難，」他說。

曹永暉引用美國某跨民生消費品與工業原料的製造業大廠導入6 Sigma的例子解釋，該公司本是一家很有創新能力的企業，導入6 Sigma後卻反而不如從前，「企業要採行任何標準、框架或方法時，都需要確認是不是真的適用於自身的人員、組織特性與文化，否則不但可能收不到預期效果，還會有負面影響，」曹永暉說。

其他業者亦有類似看法。IBM日前便曾提出，企業若要做好IT服務管理，除了ITIL，CMMI與COBIT都應納入考量。

HP軟體事業處資深顧問王秉慎亦說，導入ITIL前的評估作業相當重要，要先確認企業目前哪些流程是否已能滿足需求，「若企業已發展了不錯的流程或管理制度，未必要對ITIL照章全收，」他說。

除了強調ITIL不是萬靈丹，Johnson亦提醒有意採行ITIL或任何新流程的企業，必需設置有實質權力（例如充份獲CIO授權）的IT服務設計團隊來專責執行，一方面要有能力以商業語言和業務單位溝通需求，另一方面，也能協調、整合IT部門的資源，才能確實推動新流程的落實。

他亦提醒企業，ITIL的價值在於IT服務流程的制定是依據企業策略而來，採用哪種軟體或工具來進行管理反而是其次。

「工具可以幫助達成流程自動化，讓大家的日子好過一點，但工具沒辦法幫企業制定策略，那是人的工作，不可能被取代，」Johnson說。

ITIL or not ITIL? That is not the question

ZDNet 鍾翠玲

ITIL反對論
「ITIL原本應該是一種練功的工夫，個人修為比教你心法更是成功關鍵，」黃以任以武功為比喻指出，有的人適合練輕功，有人適合金鐘罩鐵布衫，而且沒有好或不好的絕對值，只有同產業領導公司的經驗可以比較。也就是說，ITIL本來就沒有要"冒充"標準的意思。

v3相較之前版本，已有所改進。ITIL v3包括的planning, designing, delivering, operating and improving，已帶入服務生命周期概念，不像v2那樣只強調流程。由於更考慮使用者、策略因素以及對業務、財務面的衝擊（即風險），v3也更要求IT能力具備專案管理及服務組合管理的能力。此外，在某些部份，例如request fufillment、CMDB等也解釋的比較清楚，減少因人有各種詮釋的造成的差異。同時，比v2也更強調做的必要性。

但有些人認為，正因為缺乏嚴格規範，因此萬萬不可行。由於缺乏BS 7799或ISO 120000 的明確的控制項目 ，很多細項單憑詮釋執行結果就不同，少了完善內稽內控，也很難確保今天和明天的事件管理都可以嚴格執行；ITILv3依舊未明確說出該做到什麼程度才算對、什麼事應該怎麼做。
此外， ITIL所謂的best practice也被許多人質疑，因為沒有最好的，只有在組織成員共識基礎之上，最適合某個組織的管理作法。然而服務生命周期的概念, 雖然比較接近真實世界的情況，不過也不能稱之為"best practice"。

ITIL不提供標準化的績效測量方法也是致命傷之一，因為各種專屬的測量方法，像是顧問公司Pink Elephant及Lucid之間無法比較熟好熟劣，以變更管理而言，各家公司做來不同，當然也難以提供彼此比較的基準。許多人士認為，為此，ITIL最好結合如ISO 17799, ISO20000等認證 (當然取得標準認證的成本、組織改造作業及文件準備工作，又是另一回事了。)

許多較溫和的反對論者認為，ITIL是較過去已有改進，只是對企業而言，未來版本還有許多可以期待。

唯一不變的是「變」的文化

事實上，就連提供ITIL導入的顧問也指出，改變才是重點，而不是用什麼工具或方法，包括ITIL；形塑一個「變」的文化才是成功提升作業效率的要素，要是員工無法認識改變的必要性，就可能會因為流程改變造成的不適性或生產力降低而質疑、甚至抗拒任何新制度帶來的變動。

HP軟體事業處資深顧問王秉慎建議，企業可結合ITIL執行與人事績效，增加改變的成功率。他以Service Desk為例解釋，若一般員工不願配合已改變的IT報修流程，例如不先查詢自行修復FAQ，或撥打IT部門報修專線，還是習慣自己把筆記型電腦搬到IT部門，則加以紀錄作為績效考核參考。「若未搭配人事績效評估，則就算流程設計再好，較難發揮強制力，」他說。

所有專家都指出，CIO是導入變的文化過程中的靈魂人物。由CIO領導的跨部門小組，將在專案過程中扮演各部門溝通協調，並帶動確實的執行過程。CIO也必須相當清楚導入的目的，並且知道自己在做什麼，IBM全球IT服務事業部顧問經理陳俊昌解釋，數據化的KPI固然能夠清楚衡量績效，但ITIL和導入工具、一般IT產品有很大不同，不會立即見效。「ITIL比較像蓋小學、文化營造，效果與改變有時是逐漸累積。」

陳俊昌表示，因為ITIL牽涉到組織行事流程、文化的改變，具體的效果可能要導入後兩、三年才會真正反映出來。因此「CIO心中的藍圖必須非常清楚，否則可能一開始訂定KPI時即出現偏差、過於理想化，導致後續表現不如預期，或是一直看不到成效，影響整個計劃執行的信心，甚至失敗，」他說。

不過，雖然ITIL固然需要強有力的執行意志，但仍然必須取得員工的了解與同意。如果總是採取強制的作法，只會更激發人員的抗拒，終究會失敗，Johnson指出。CIO應該站在使用者立場解釋ITIL的好處，訂出大家都能同意的目標，同時給予一定的訓練降低改變的挫折感。

這也是為什麼許多較有錢的企業為了加速改變力道(克服內部障礙)，乃引進IBM/PwCC、Quint、Pink Elephant或是KPMG、E&Y等顧問公司，就是顧問負責「扮黑臉」。

同時，結合ISO標準認證，或是六個標準差，正有如考試客觀評判同時發揮敦促效果。

該選ITILv2、v3、還是ISO認證？
然而，既然ITIL不一定足夠，這也意謂著企業IT部門必須在有限的金錢、時間，決定如何增進自我功力。第三版的問世，對已經取得第二版認證的企業來說，可能面臨是否要多考一道試—以及多花一筆錢；對沒有拿的企業，則可能擔心該選擇哪一種。他們也可能想問，該不該拿到ISO認證？ 唯一不變的是「變」的文化 。Quint顧問黃以任指出，改變才是重點，不是用什麼工具或方法。

亞洲國家的企業似乎擔心更多一些，這和本區域和歐美企業看待ITIL的態度有關。雖然ITIL起於英國，美國也自2005年起開始風行，但取得ISO20000認證的歐美企業數並不那麼多。根據itSMF的數據，2007年8月為止，英國通過ISO/IEC 20000認證的企業家數最多，共43家，但去年才13家的印度，今年則新增24家。其餘則為韓的24家及日本的19家。台灣則為4家，宏碁、IBM台灣、環保署及中科院等公私機構。歐美取得ISO 2000認證（以英國而言，目前有40多家。）原因是他們「認為沒認證事情一樣可以做得好，認證只是花大錢，」黃以任指出。

反之，在某些亞洲國家，ITIL卻反而需要靠取得ISO 20000認證來帶動企業的意願。「客戶也不諱言，他們就是要一紙認證，」黃以任說，尤其是服務供應商，取得認證意謂著能力的保證，也較容易因此取得客戶的信任。　

反之，IBM作為一個全球以IT管理與利用著稱的企業，自己甚且要提供顧問服務，是不是需要ISO 20000來為其能力背書，就在該公司內部引起過一定爭論。

「最重要的知道你公司需求何在。」黃以任說，不論你的目的是提升員工效率、使IT人力及資源獲得更妥善利用、降低停機損失、提升客戶滿意度、符合法令規定，還是那張認證，她以ITIL而言，V2著重IT基礎架構的運行效率，v3處理的是專案溝通部份，ISO則證明你有此能力看哪個能解決公司的問題就是最好的方法。

如果公司正在進行提升或確保IT服務的專案，或是已有這樣的機制，應該持續原有步伐。已經或正在導入ITIL v2的企業應維持原來計畫，v2與v3因為兩種認證處理的是不同需求，如果你取得ITIL v2認證，也用不著急著去取得最新的v3認證，未來一定會有銜接方案。

回歸需求面
Bottom Line: 視需求而定
和該取得哪個版本一樣，面對眼前—以及未來陸續問世的--如此多的選擇，最終的答案在於你適不適合？
Brian Johnson強調不是每家企業都需要ITIL，而選擇哪一個版本，也是視需求而定。

黃以任指出，不是每家公司都需要ITIL。組織流程很簡單，可能需求就不大。而且每個組織改善的情況也因原有體質差異有所不同。對一個原有服務管理沒有基礎的組織，導入全新ITIL，可見明顯成效，而QMS做得好，距離拿到ISO20000的水準其實只有一步之隔，她說。

另一個原因則是企業組織自行評估後的決定。

ITIL範疇之深之廣，成本過大，讓南亞科技也必須評估導入是不是「是不是該投入80分的力氣去做到剩下的20分」。南亞科技資訊部處長張武煌說，南亞科技也沒有計畫取得ISO 20000的認證，因為「實務效用才是我們重視的。」

像CA的Johnson明白指出，企業仍是最終答案的決定者。「ITIL只是一種指導方針，不是法律…它甚至要求企業必須確認自己的需求，」企業必須知道自己問題在哪，才能找出適合產品及方案，甚至選擇該導入哪個版本的ITIL。「說不定你公司根本也用不著ITIL，」他說。

如果你清楚知道重點暫不在此，就先別做。例如彰化銀行目前正為取得ISO 27001 (BS7799的國際標準版)而積極準備中；目前已有五個系統取得認證，明年七月之前可望全系統獲得認證。彰銀資訊長曾芳明就指出，「事有輕重緩急，對我們而言，資訊安全是目前的當務之急。」

日月光CIO盛敏成則強調ITIL必須以需求為基礎加以客製化。他指出，日月光當初為了做好基礎架構管理而買入ITIL的產品，「事實上，我們也是後來才知道，自己做的是ITIL。」他因此強調流程客製化的重要性，基於對公司需求、流程及資源的了解，日月光是導入「ASE(日月光)版本的ITIL」。

日月光並未取得ITIL認證，也不打算通過ISO認證，他認為，只要透過內部管理就能確保切實執行，無需一紙證照。

結語
ITIL反映新的IT思維--以IT支援商業需求--這種新的思維在技術廠商間則興起SOA（服務導向架構）的風潮。儘管二十年來批評不斷，許多採取折衷立場的人認為，但並非毫無可取，同時隨著版本的更新它也更朝這理想前進。但它畢竟還是"框架" ，它仍舊沒有提出明確的執行方法論，對企業導入的指引有限，他們還是得親自走過一切過程，而不能完全仰賴之，雖然ITIL人士也一再鼓勵企業得先了解自己的需求所在。

面對要不要導入ITIL，一個較保險的作法是，如果你是IT部門，你該自問三點：導入ITIL 1. 對現有訓練的影響；2. 對現有IT專案的影響，及3. 對已買昂貴軟體的影響。如果貴公司正在進行提升或確保IT服務的專案，或是已有這樣的機制，請持續原有步伐。如果你已取得ITIL v2認證，也用不著急著去取得最新的v3認證，未來一定會有銜接方案。

企業老闆也好，CIO也罷，該謹記的是：IT 服務--而非ITIL--才是思考重點。如同IDC研究經理曹永暉表示，不論是ITIL或是COBIT、BS7799，這些都是外來的典範，但不一定完全適合企業，外來的顧問也不一定能告訴你適不適合。一切都要回到實際需求，他說，「最了解需求及作業的，還是公司內部的IT部門。」

中華電信提升服務品質與顧客滿意度的訣竅 — 導入 ITIL，優化帳務系統服務管理

客戶:中華電信
行業: Telecommunications
發表國家:Taiwan

概觀
中華電信近年來積極耕耘 IT 加值服務市場，亦積極且持續優化內部資訊作業流程，來強化IT服務管理品質, 於 2007年底開始導入資訊技術基礎架構庫〈Information Technology Infrastructure Library；ITIL〉方法，強化若干重要資訊系統，如帳務系統服務管理等行動方案，希望倚重資訊服務管理平台和帳務系統的整合，提升資訊資產使用率，降低營運成本，提高客戶與使用者滿意度與符合公司治理內控稽核需求。

業務需求:
如何優化內部營運效能，強化 IT 服務管理品質，進而滿足SOX法案所要求的公司治理目標 (因中華電信已是美國ADR上市之國際級公司)。「為了與公司的 Business Value 接軌，滿足 IT Governance 之要求，並提高客戶的服務品質，降低總體資訊投入的 Cost，資訊體系一直積極於提升資訊系統之營運效能。

解決方案:
中華電信在正式導入 IBM 的資產管理軟體 MRO、組態管理資料庫（Configuration Management Database，CMDB）及業務服務管理（Tivoli Business Service Manager，TBSM）等三套系統前，約莫花費半年的時間與 IBM 進行概念性驗證〈Proof of Concepts，POC〉，釐清能否從固網帳務系統著手，以及上述的三個軟體產品可否無礙連結，來建置成完整”服務管理平台”解決方案。

利益:
第一，將稽核要點內化成系統營運同仁的日常工作事項
第二，建立e化系統服務管理並統一處理流程
第三，達資訊人力資源最佳化
第四，持續累積知識文件
第五，提高IT資源的可用度與可靠性

成功案例
中華電信近年來積極耕耘 IT 加值服務市場，亦積極且持續優化內部資訊作業流程，來強化 IT 服務管理品質, 於 2007年底開始導入資訊技術基礎架構庫〈Information Technology Infrastructure Library；ITIL〉方法，強化若干重要資訊系統，如帳務系統服務管理等行動方案，希望倚重資訊服務管理平台和帳務系統的整合，提升資訊資產使用率，降低營運成本，提高客戶與使用者滿意度與符合公司治理內控稽核需求。

如何優化內部營運效能，強化 IT 服務管理品質，進而滿足 SOX 法案所要求的公司治理目標 (因中華電信已是美國 ADR 上市之國際級公司)。「為了與公司的 Business Value 接軌，滿足 IT Governance 之要求，並提高客戶的服務品質，降低總體資訊投入的 Cost，資訊體系一直積極於提升資訊系統之營運效能。經過一番評估之後，其中一項重要的措施就是導入 ITIL 來強化既有的資訊服務管理機制」，中華電信總公司資訊處處長陳明仕博士表示。

確定方向後，接下來得思考的問題是，從何處著手。資訊處陳憲昇科長指出，會決定從帳務著手，因為帳務系統是中華電信營運核心系統之一，也是外部稽核單位的關鍵稽核項目。「對中華電信來說，參考 ITIL 來強化帳務系統營運管理，不僅在實務上建立作業標準流程及管理機制以確保系統正常維運，亦可符合稽核項目要求標準。」

中華電信在正式導入IBM的資產管理軟體 MRO、組態管理資料庫（Configuration Management Database，CMDB）及業務服務管理（Tivoli Business Service Manager，TBSM）等三套系統前，約莫花費半年的時間與 IBM 進行概念性驗證〈Proof of Concepts，POC〉，釐清能否從固網帳務系統著手，以及上述的三個軟體產品可否無礙連結，來建置成完整”服務管理平台”解決方案。

中華電信之所以會參考 ITIL 來強化固網帳務系統營運管理，電研所計畫經理林昭陽博士表示，主要是基於下列兩項考量：

第一，提升使用者滿意度。
帳務系統提供給中華電信內部使用者帳務作業資訊處理服務，並視公司業務變動與使用者需求，更新資訊服務內容外，另外一個作法是優化內部資訊系統作業流程，以及監管各項資訊系統服務狀況，提高使用者滿意度。
導入 ITIL，強化固網帳務相關的資訊服務作業流程，得以在使用者提出抱怨前，服務管理平台即已監測與進行異常的事件處理，亦可確保營運帳務系統部門員工是以一致的規範在執行各項活動。

舉例來說，為確保系統營運人員可以提供一致的服務，由公司相關資訊系統研發單位、營運單位與使用單位同仁一起討論、擬定與書面化各項業務服務的標準作業流程，如此一來，系統營運人員將可以在最短時間內，找到參考依據，提供一致的服務品質。

第二，提升協同作業績效。
由於中華電信的帳務系統營運工作分別在各分公司執行，為確保帳務整合服務的品質，及各分公司系統營運同仁是不是以一致的作業流程處理各項工作，將會影響處理帳務整合作業之時效與正確性。另為提升同仁們的工作效率與效能，中華電信除書面化相關的業務服務的標準作業流程外，亦可透過服務管理平台的監控功能，確認各分公司帳務資訊系統的協同作業流程無誤。

確認專案的範疇與目標後，中華電信大約再花半年的時間，循序導入 IBM 的軟體產品，逐步提升固網帳務的資訊服務品質。中華電信透過 IBM MRO、CMDB 與 TBSM 等系統，落實事件管理、問題管理、變更管理與組態管理等服務支援機制後，已可看到下列五點成效：

第一，將稽核要點內化成系統營運同仁的日常工作事項：由於中華電信的員工必須透過上述系統工具執行與帳務系統相關的業務工作，讓相關員工都是依照公司規範行事，有助於將外部稽核要點，內化成員工的日常作業模式，有助員工縮減花費在業務稽核的事前準備工作的時間與落實工作確實度，達到 IT Governance 的目標，符合外部與內控稽核的要求。

第二，建立e化系統服務管理並統一處理流程：雖然原先中華電信已建置相關帳務系統營運管理作業，但因各地特性與歷來作業原則，無法以單一作業流程運作。藉由擬定各項業務服務的標準作業程序並 e 化，讓相關單位的同仁都可依照一致的準則行事，並將處理流程的資料都統整於資訊營運管理系統中，讓營運管理更有效率。

第三，達資訊人力資源最佳化：透過擬定與帳務資訊系統相關的業務服務的標準作業程序所建置的服務管理平台，各分公司帳務中心的同仁將可以依循一致的作業準則行事，並且達成資訊同步，一起解決問題，發揮協同作業的最大效益，如南才北用、或北才南用。

第四，持續累積知識文件：服務管理平台提供知識庫功能，類似事件第一次發生後，可以將成功的處理經驗記錄在管理平台中，再次發生時，使用人員可查詢到相關的處理記錄，不需要再重新提出要求，就可獲得解決方案，減少處理時間，不僅讓資訊人員與使用人員不用擔心新進人員遇到狀況會無所適從，亦可縮短其執行各項業務服務的時間，以及逐步提升服務品質。

第五，提高 IT 資源的可用度與可靠性：藉由服務管理平台整合現有各類監控功能，不但能主動通報系統障礙與異常，並且自動於服務管理平台開立事件單，使系統人員能夠及時處理狀況。在處理過程中，系統人員可經由組態管理及業務服務管理系統，得知系統效能及組態變更資訊，不但提高判斷問題的能力，也縮減處理時間，IT 資源的可用度與可靠性也因此而提高。

展望未來，中華電信總公司資訊處處長陳明仕博士表示，中華電信目前僅部分系統導入 ITIL 架構，端視其使用成效，再逐步深入 ITIL 的應用層面與系統的廣泛度。冀透過 ITIL 等運作機制不斷提升 IT 整體的服務水準，朝更高的營運績效與顧客滿意度邁進。

此成功案例中使用的 IBM 產品和服務
軟體:IBM Service Request Manager , Tivoli Business Service Manager

台灣高鐵以 IBM Tivoli Maximo 建構維修資訊管理系統

客戶:台灣高鐵
行業:Travel & Transportation
發表國家:Taiwan

概觀
2007年1月5日通車營運的台灣高鐵，大幅地改變了台灣的交通版圖與生活旅遊形態，南下北上每日高達數百車次的運行量，更是對營運能力的嚴格考驗。由IBM Maximo所建構的台灣高鐵維修資訊管理系統（MMIS；Maintenance Management Information System）則在其中擔負了後勤支援和維運管理的關鍵角色。

業務需求:
2007 年1月 5日通車營運的台灣高鐵，大幅地改變了台灣的交通版圖與生活旅遊形態，南下北上每日高達數百車次的運行量，更是對營運能力的嚴格考驗。

解決方案:
MMIS 採用了 IBM Maximo 的標準模組，包括資產管理、工單管理、計畫管理、庫存管理、資源管理、採購管理與應用程式介接。

利益:
台灣高鐵維修資訊管理系統經理李明德表示：「IBM Maximo 極為靈活，可因應業務需求擴充應用的深度及廣度，至於其為 MMIS 帶來的效益，則包括整體效率的提升、維修資料的整合，以及單一的知識資料庫。」

成功案例
2007年 1月 5日通車營運的台灣高鐵，大幅地改變了台灣的交通版圖與生活旅遊形態，南下北上每日高達數百車次的運行量，更是對營運能力的嚴格考驗。由 IBM Maximo 所建構的台灣高鐵維修資訊管理系統（MMIS；Maintenance Management Information System）則在其中擔負了後勤支援和維運管理的關鍵角色。

MMIS 採用了 IBM Maximo 的標準模組，包括資產管理、工單管理、計畫管理、庫存管理、資源管理、採購管理與應用程式介接。台灣高鐵維修資訊管理系統經理李明德表示：「IBM Maximo 極為靈活，可因應業務需求擴充應用的深度及廣度，至於其為 MMIS 帶來的效益，則包括整體效率的提升、維修資料的整合，以及單一的知識資料庫。」

即時記錄完整資產資訊透過 IBM Maximo 資產管理模組，MMIS 登錄了台灣高鐵的所有資產，例如：通訊系統、駕駛模擬機、車輛、軌道系統、號誌等，總計超過三十萬個項目，採取設備與地點的一對一關係模式來登載相關資訊。

台灣高鐵採用層級式資料結構，目前由上而下區分為八層；同時，資訊管理模組裡還有故障樹（Failure Tree）的詳細定義，包括問題、原因與修復方法，現有 1,500多個分類。值得注意的是，由於部分資產是以操作或運行次數來決定維修週期如大型變電廠，因此，這些相關資訊也會一併登載於資產管理模組裡。

庫存管理則可視為與資產管理相互呼應的應用模組。「存貨管理」將存貨項目區分為一般耗材、可修件與固定資產等三種類型。目前台灣高鐵的物料主檔總計有 55,000多筆資料。而庫存管理中的「庫房管理」功能可有效協助台灣高鐵優化後勤支援，提升維修效率。由於台灣高鐵由北至南有多個庫房，如何就近支援維修人員、用最有效率的方式來放置及運送物料，正是庫房管理的工作重點。

完備工單管理，展現維修效率
工單管理則被台灣高鐵視為 IBM Maximo 的應用系統核心，主要項目涵蓋工單、人力工時報告、物料使用與工作流程核可作業。

IBM Maximo 提供三種預設的基本工單類型，分別為預防性檢修、矯正性維修與緊急修復，台灣高鐵則參考日本新幹線與香港地鐵的經驗，以三大類型為基礎再向下細分出二十多種工單，為日後導入 ABC（Activity-Based Cost）預作準備。

每張工單都會帶出工作計畫，詳細記錄如何進行這件工作，包括作業步驟與檢查細項等。另一個重要的工單功能則是排程資訊，也就是在工單預先規劃工作，以台灣高鐵的運作現況來看，已經可以推演未來一年的工作內容，藉此平衡高峰期的人力與物料調度。

李明德經理說明：「保護客戶安全是我們的最高指導原則，因此，我們必須按期完成所有必要的工作，預先將工作輸入排程資訊裡，除了可做好事前規劃，也可避免遺漏工作項目。」

IBM Maximo 在工單管理模組內建的工作流程功能，亦是協助台灣高鐵提升維修效率的利器。以矯正性維修的工單流程為例，完成流程設計後，除了列出維修工作的流程之外，系統更會自動顯示所有工單最即時的詳細資訊，包括現有進度、問題根源、責任歸屬，甚至可用來計算完成率、工作進度等。

跨部門、跨系統效益
根據台灣高鐵的數據，過去三個月裡，平均每個月都有超過一萬張工單，95% 以上的維修活動工時都回報至 MMIS 系統，系統的同時上線使用人數平均都在80人以上，而且，除了維修部門以外，庫房、採購、財務與人資等部門，皆需借重 MMIS 的運作與資訊來完成職掌工作。

同樣地，MMIS 也必須與其他系統介接，才能確保資訊的即時正確，例如：營運資料、營運故障記錄、各班列車目前資訊等，皆需經過篩選及格式轉換，再匯入MMIS，讓維修部門可在第一時間掌握車輛現況，甚至在車輛尚未進廠維修之前，就已得知車輛的問題與狀況。

李明德經理表示，以 IBM Maximo 建構的MMIS大幅提升了整體效率，包括強化預算及決算控管、掌握人力使用率、記錄工單狀況、計算庫存週率、預測資源需求，以及提升資產使用效率與採購效率。

台灣高鐵也計畫持續升級 IBM Maximo 至最新版本，以善用技術進展來開發更多便捷好用的先進功能，同時，也持續評估商業智慧工具，強化 MMIS 的分析能力與決策支援，以強大可靠的後勤維修支援，讓台灣高鐵能持續以高速在台灣順暢運行。

此成功案例中使用的 IBM 產品和服務
軟體:
Maximo for Service Providers, Maximo for Transportation

IBM Tivoli Maximo 成功引領台灣志氯化學 資產管理應用發酵

客戶:台灣志氯化學
行業:Industrial Products
發表國家:Taiwan

概觀
IBM Maximo 成功引領台灣志氯化學 資產管理應用發酵.導入 IT 管理能力，已經成為許多企業提升競爭力的不二法門，以使用 IBM Maximo 資產管理解決方案為例，不但可以有效提高效益及降低成本，更可以做為企業未來制定策略的重要依據，讓企業達到永續經營的目標。

業務需求:
對成立超過 20年的台灣志氯化學而言，IT 管理更是重要。台灣志氯化學副理許榮焜表示，回想導入 Maximo 的經驗，在 1997年之前，包括維修管理及採購，台灣志氯化學都是採用書面作業，倉儲管理採用簡易 DB3 管理；為了方便管理、保存及搜尋追蹤資料等需求，發覺有數位化的必要，於是在維修部門及母公司美國 PPG 的推薦下，得知 Maximo 提供的模組功能相當完整，正符合台灣志氯化學的需求，因此決定著手導入。

解決方案:
許榮焜表示，為降低使用者的反彈，首先成立了專案小組，說明公司的作業流程，及資料流程的需求，讓所有流程的作業人員都看見自己的位置及自己得到的好處和 對下游流程的幫助。並根據 Maximo 的功能，配合公司架構做好分工，並依據現有工作流程做局部修正，儘量保持軟體系統的好處，訂定導入目標，完成各模組的定義及作業流程。

利益:
當 Maximo 穩定使用後，就可以針對企業需求，定義各項績效指標（KPI），作為改善各個部門效率之用。許榮焜表示，以前是因為沒有適當的工具，現在有了 Maximo 的資料庫功能，就可以做好各種資料的蒐集及使用，以及長期的追蹤。

成功案例
導入 IT 管理能力，已經成為許多企業提升競爭力的不二法門，以使用 IBM Maximo 資產管理解決方案為例，不但可以有效提高效益及降低成本，更可以做為企業未來制定策略的重要依據，讓企業達到永續經營的目標。

對成立超過 20年的台灣志氯化學而言，IT 管理更是重要。台灣志氯化學副理許榮焜表示，回想導入 Maximo 的經驗，在 1997年之前，包括維修管理及採購，台灣志氯化學都是採用書面作業，倉儲管理採用簡易 DB3 管理；為了方便管理、保存及搜尋追蹤資料等需求，發覺有數位化的必要，於是在維修部門及母公司美國 PPG 的推薦下，得知 Maximo 提供的模組功能相當完整，正符合台灣志氯化學的需求，因此決定著手導入。

有趣的是，台灣志氯化學當時根本沒有 IT 部門，而且當時的 IT 使用者，應用能力並不強；比方說，用書面作業開一個工作單，只要一兩分鐘，用電腦卻要花超過五分鐘，導入的困難度相對更高。

許榮焜表示，為降低使用者的反彈，首先成立了專案小組，說明公司的作業流程，及資料流程的需求，讓所有流程的作業人員都看見自己的位置及自己得到的好處和對下游流程的幫助。並根據 Maximo 的功能，配合公司架構做好分工，並依據現有工作流程做局部修正，儘量保持軟體系統的好處，訂定導入目標，完成各模組的定義及作業流程：

Maintenance： Equipment、PM、Work Order、Job Plan
Warehouse： Inventory、Issues & Receipts
Accounting： Charge Code、Invoice Matching
Purchasing： PR、PO、Vendors

在導入的同時，強調後端的資料庫儲存及管理的價值，希望大家能夠忍受前端輸入的短期不便，並針對特殊需求，開發外掛小程式，例如讓工單也可以匯出成 Excel 格式，方便一些比較熟悉 Excel 工具的員工使用，取得公司內部控管原則與 Maximo 平衡，在 1998年 4月 Maximo 正式在台灣志氯化學上線啟用。

做好規劃 導入才會成功
目前台灣志氯化學使用的 Maximo 版本為 4.0.1版，使用的單位包括修護、製造、採購及財務。管理的資產設備總數方面，全廠製程設備有 1,900個物件，倉庫項目則有1萬多項。使用的功能模組包括 Work Order、Purchasing、Inventory、Equipment，每年工單數量方面，母單 1,100件，子單 2,700件。

導入 Maximo 至今，許榮焜表示，Maximo 幫助建立許多物料的使用及準備過程，不但方便技術員準備及維修，也可以做好成本預估。目前倉管功能也已可直接找到進料及出料的歷史資料，維修管理也正在添增類似的功能。

此外，物料單的紀錄一旦建立起來，未來需要做甚麼計畫，也可以很快地訂定出來，不需要花太多時間先把物料找好，也可以利用資料庫輸出各種工作表，以便瀏覽、管理或追蹤工作成果。

許 榮焜進一步解釋，物料需求的頻率，也可以透過 Maximo 直接做分析，甚至可依據此判斷設備的故障率，顯示適不適合目前的使用環境，必要時就可以做出改善或更換的決定，例如公司有多台同樣容量、同樣形態的設備， 但如果哪一台設備常出問題，就可以從紀錄發現，調用其他設備來應變。

Maximo 成為企業策略緊密的一環
在導入的經驗方面，許榮焜特別強調，因為每個人的工作有不同的需求，因此在導入時，要先將工作流程講清楚，像流程中要設置哪些控制點等。正式上線之後，還要 不斷地尋求使用者的回饋，是否碰到任何問題？系統哪些功能還不夠完整等？ 能夠解決就當場解決，不能解決就找原廠或 IT 管理者詢問，並召開會議討論如何解決問題，並不斷增加應用，讓使用者方便使用。

換句話說，導入時要做到全員參與，也就是使用相關單位必須積極參與，才能讓系統及流程符合公司作業需求。

當 Maximo 穩定使用後，就可以針對企業需求，定義各項績效指標 （KPI），作為改善各個部門效率之用。許榮焜表示，以前是因為沒有適當的工具，現在有了 Maximo 的資料庫功能，就可以做好各種資料的蒐集及使用，以及長期的追蹤。

目前 Maximo 已經成為台灣志氯化學企業策略的一環，像是可以參考 Maximo 統計的資料，進行安全庫存標準的參考標準。許榮焜期盼，Maximo 的新功能可以減少開發外掛程式、並提高資料分析的使用效率，未來也會持續進行 IT 投資，以達成企業追求高效益、低成本及永續經營的目標。

此成功案例中使用的 IBM 產品和服務
軟體:Maximo for Oil and Gas

台證證券導入 IBM Tivoli Monitoring 整體解決方案

24小時系統監控零誤差

客戶:台證證券

行業:Financial

發表國家:Taiwan

概觀
台證證券導入 IBM Tivoli Monitoring 整體解決方案 24小時系統監控零誤差

業務需求:
隨著網路應用的普及，網路下單逐漸成為各證券商的核心業務，而下單系統連線的穩定和安全是影響使用者是否滿意的關鍵。成立於 1988年的台證證券是國內領先的證券商之一，目前除了有股票交易經紀業務、股務代理業務之外，也代銷國內投信與境外基金，各國債券商品等業務。

解決方案:
台證導入 Tivoli 上線至今，運作十分順利，一切運作都由工具 24小時遠端監控，系統只要測知可能出現問題的地方，就能立刻預警各部門、即時修復、或立即有效調配流量和資料庫空間；若有發生服務中斷情形，也能自動重新啟動機制並告知，確保營運不中斷，線上交易正常運作。如今台證只需要資訊部一名人力，就可以監控全台各點所有資訊系統，讓寶貴的人力可以去從事其他更重要的業務！

利益:
台證資訊部表示， IBM 的產品幫他們做了許多預防措施，在問題發生前就提出預警，讓台證減少許多損失，程式穩定度佳，資源分配也更有效率，讓公司業務能 7*24小時服務不間斷，讓 IT 部門同仁能專注於主要業務，提供客戶更好的服務。在資訊服務的連續性、可用性達成後，未來的擴充上，台證也計畫，導入更多模組，加強系統績效，提升線上交易效率。

成功案例
隨著網路應用的普及，網路下單逐漸成為各證券商的核心業務，而下單系統連線的穩定和安全是影響使用者是否滿意的關鍵。成立於 1988年的台證證券是國內領先的證券商之一，目前除了有股票交易經紀業務、股務代理業務之外，也代銷國內投信與境外基金，各國債券商品等業務。

過去台證各部門都自行開發軟硬體資訊系統，系統複雜度高，並由資訊部的人力來監控系統穩定性，不但非常耗費人力，也因人力有限無法一一兼顧而疲於奔命。為了提升整體運作效率，台證在 2007年決定引進監控管理系統的整體解決方案，來控管各部門軟硬體和複雜的作業系統和資料庫，包含監控作業系統、資料庫以及應用程式。

完整 IBM Tivoli 家族　易上手好管理
採購解決方案之前，台證邀請了 IBM 等幾家系統監控軟體公司，針對其需求來報告解決方案，並進行實際到點測試。經過評比後，決定採用 IBM 的 Tivoli IT Service Management（ITSM）解決方案，台証主要考量在於，產品功能、擴充性、後續服務、價格等各方面， IBM Tivoli 都優於其他對手。

另外， Tivoli 可以跨平台、跨作業系統（Widows、Unix、Linux、AS 400）、跨各種中介軟體（middleware）、群組軟體和資料庫，因此廣為金融機構採用，在客戶的 best practice上，可參考之實務經驗和案例也比同業更廣，這些在在都是 Tivoli 獲得台證青睞的原因。

由於 ITSM 監控的平台使用對象涵蓋各部門，牽涉的系統、平台和應用程式複雜，導入前，台證也一一針對各部門做了詳細的訪談，了解各部門的需求和業務，更開發不同的警示方式，包括電子郵件、簡訊，甚至MSN等訊息傳遞媒介，由監控系統主動且即時告知系統管理者，取代過去由人員守在系統旁待命。

Tivoli 擴充性佳，採取階層式架構，因應企業規模都能進行客製化，客戶很容易上手。；此外， Tivoli 的硬體需求不大，如台證後端有數十部 IBM AS/400 系統運作，使用 PC Server 就可以輕鬆管理。

導入後穩定性高　高效率分配資源
台證導入 Tivoli 上線至今，運作十分順利，一切運作都由工具 24小時遠端監控，系統只要測知可能出現問題的地方，就能立刻預警各部門、即時修復、或立即有效調配流量和資料庫空間；若有發生服務中斷情形，也能自動重新啟動機制並告知，確保營運不中斷，線上交易正常運作。如今台證只需要資訊部一名人力，就可以監控全台各點所有資訊系統，讓寶貴的人力可以去從事其他更重要的業務！

台證資訊部表示， IBM 的產品幫他們做了許多預防措施，在問題發生前就提出預警，讓台證減少許多損失，程式穩定度佳，資源分配也更有效率，讓公司業務能 7*24小時服務不間斷，讓 IT 部門同仁能專注於主要業務，提供客戶更好的服務。在資訊服務的連續性、可用性達成後，未來的擴充上，台證也計畫，導入更多模組，加強系統績效，提升線上交易效率。

此成功案例中使用的 IBM 產品和服務
軟體:IBM Tivoli Monitoring , ITCAM for RTT

自主掌控 成就無憂業務——工銀瑞信實現IT綜合服務管理

自主掌控 成就無憂業務——工銀瑞信實現IT綜合服務管理

“一招不慎，滿盤皆輸”的道理在IT時代正得到淋漓盡致的演繹：IT系統運行在一個複雜的環境中，周遭的物理環境，CPU和存儲設備等IT資源的狀況，乃至IT系統自身各個功能模組的操作和運行，任何一個細微環節的異常都會導致整個IT系統的功能無法正常發揮，最終迫使企業的核心業務蒙受巨大損失……

專案背景：“一招不慎”的危機防不勝防

工銀瑞信基金管理有限公司（以下簡稱“工銀瑞信”）是我國第一家由銀行直接發起設立、並控股的合資基金管理公司，憑藉強大的股東背景、穩健的經營理念、資深的管理團隊和便捷的客戶服務，工銀瑞信立足專業化、國際化，並以穩健的投資管理，為客戶提供卓越的理財服務。目前，公司旗下管理4只開放式基金——工銀瑞信核心價值股票型基金、工銀瑞信貨幣市場基金、工銀瑞信精選平衡混合型基金和工銀瑞信穩健成長股票型基金。 截至2006年末，公司管理的資產規模近300億元，躋身中國基金業10強。

工銀瑞信很清楚，公司的壯大與專業的服務能力密不可分。對於時間和資訊即意味著滾滾財源的金融業，服務品質又是與服務管道的便利性和服務提供的可持續性息息相關。正因為此，短短幾年內，工銀瑞信迅速開發了包括語音電話、電子郵件、短信服務、網站服務、投訴服務等在內的多個服務系統。

然而，服務系統的壯大，必然給公司IT系統的運維帶來嚴峻的挑戰——威脅服務系統的因素越來越多，也越來越難以預料，而任何一個環節的故障都會導致整個服務體系的癱瘓。這些危機集中表現在這樣幾個方面：

缺乏對業務系統故障的預測和監控能力 防患於未然是IT運維工作的基本原則，但前提是具備對故障的預測和監控能力，否則只能是“水中按葫蘆”——此伏彼起。工銀瑞信龐大的服務系統牽涉更多的事物，這讓對整個業務系統運行故障的預測和監控工作變得極為艱難。

IT系統的運維成本居高不下 因為運維工作不能有計劃地進行，IT人員只能充當“救火隊員”的角色，整天忙得焦頭爛額，消耗大量的人力資源；此外，運維工作都是從故障發生後才開始，這使故障恢復的費用陡增。

業務得不到IT最有力的支援 業務系統不可預料地發生故障，致使面向客戶的服務時斷時續。

方案選擇：讓業務系統盡在掌控中

雖然擁有強大的服務系統，但卻不能有效地掌控它，更不能讓它為公司的業務提供可持續性支援，這讓工銀瑞信苦惱不堪。

IT正在與基金業務發生千絲萬縷的聯繫——不僅涉及業務層面，也涉及決策支持層面，而且對即時性的要求也極高。所以，工銀瑞信必須改變公司業務系統運維的現狀，對IT服務進行有計劃性的管理，以使IT服務滿足公司業務的需求。

其實，早在2005年公司成立時，中銀瑞信就已經選擇了IBM的主機、存儲和存儲管理系統，IBM領先的技術、豐富的行業經驗、專業的服務團隊和穩妥的品質保障已經深入人心。所以，在中銀瑞信尋求IT綜合服務管理解決方案時，就很自然地選擇了IBM提供的基於IBM Tivoli Monitoring的解決方案。

專案實施：“平台”與“實施”的珠聯璧合

規範的IT服務管理必須以科學的管理流程為導向，此外，服務系統的精密性在於它對運行的物理環境提出了極其嚴格的要求，二者的有機結合，才能使IT綜合服務管理水準達到最佳，這也正是中銀瑞信IT綜合服務管理專案的重點和難點。

IBM Tivoli Monitoring是業界領先的系統監控軟體，它將基於最佳實踐的服務管理流程有機地融於其中，能對支援業務系統運行的資源狀況（主機運行狀態、資料庫、應用的運行狀況等）、操作方式等因素進行即時監控；萬申環境監控系統是精密機房運營所必須的監控工具，能有效地監控業務系統的週邊環境（包括機房溫濕度，空調、UPS、供配電的運行狀況，氣體消防報警狀況，門禁狀態，空調漏水狀況等）。

項目受益：成就無憂業務
如果說以前中銀瑞信的IT運維工作是摸著石頭過河，那麼在IT綜合服務系統上線後，一切都在悄悄地發生改變。

IT運維層面：迎取效率與成本的雙贏
對於中銀瑞信的IT人員而言，整天如同驚弓之鳥的工作狀態不再是必然。公司的IT綜合服務管理系統在即時監控各個業務系統運行狀況的基礎上，檢測系統瓶頸和潛在問題，自主生成各項指數的分析報告，並將這些內容直觀地顯示在公司業務系統的拓撲圖上，讓IT人員對影響系統運行的潛在危機了然於胸，從而可以在問題尚未發生時做好防禦措施，而不是被動地採取補救。即使問題發生了，系統也會通過郵件、手機短信等方式第一時間通知IT人員，以便IT人員能在第一時間趕到問題發生現場，並在短時間內解決問題，讓系統儘快恢復。

此外，在授權的情況下，系統支援IT人員遠端登錄、查看業務系統的性能狀況、性能分析、故障分析等功能，這讓IT人員在享受更多自由的基礎上，有更高的效率。

在有效控制故障發生的前提下，系統運維成本也大幅削減，加上人力資源的有效利用，這些使整個的IT成本得到有效控制。

業務層面：IT與業務“骨肉相連”

長期以來，在IT的應用中流傳著“兩張皮”的說法，意思是IT與企業的核心業務各為其主，不能有機地融合在一起，因而IT也不能為核心業務提供做有效的支援。

中銀瑞信的IT綜合服務管理系統上線後，各種系統運行故障得到有效控制，從而讓公司的核心業務系統能7x24小時不間斷地運行。這表明，公司的IT系統已經找到了真正的軸心——面向基金客戶的服務。

性能測試規劃建議書

1. 回應時間

我把“回應時間”的概念確定為“對請求作出回應所需要的時間”，把回應時間作`為用戶視角的軟體性能的主要體現。回應時間劃分為“呈現時間”和“系統回應時間”兩個部分。

其中“呈現時間”取決於資料在被用戶端收到回應資料後呈現頁面所消耗的時間、而“回應時間”指J2EE應用伺服器從請求發出開始到用戶端接受到資料所消耗的時間。性能測試一般不關注“呈現時間”，因為呈現時間很大程度上取決於用戶端的表現。在這裏我們沒有使用很多性能測試定義中的概念——“系統回應時間”定義為“應用系統從請求發出開始到用戶端接收到最後一個位元組資料所消耗的時間”，沒有使用這種標準的原因是，可以使用一些編程技巧在資料尚未完全接收完成時進行呈現來減少用戶感受到的回應時間，對於HNDLZCGLXT的這個項目中，我們針對C/S系統採用前者標準，對於B/S我們依然採用後一種標準。

2. 併發用戶數

我把“併發用戶數”與“同時線上數”進行區別對待，我的“併發用戶數”的標準是：併發用戶數取決於測試物件的目標業務場景，因此，在確定這個“併發用戶數”前，必須（必要）先對用戶的業務進行分解、分析出典型的業務場景（也就是用戶最常使用、最關注的業務操作），然後基於場景採用某些方法（有多種計算併發用戶數的數學模型與公式）獲得“併發用戶數”。

這樣做的原因是：假設一個應用系統、最高峰有500人同時線上、但這500人卻不是併發用戶數、因為假設在一個時間點上、有50%的人在填寫複雜的表格（填寫表格動作對伺服器沒有任何負擔、只有在“提交”動作的時候才會對伺服器系統構成壓力）、有40%的人在不停的從一個頁面跳轉到另外一個頁面（不停發出請求與回應、產生伺服器壓力）、還有10%的人掛線上上，沒有任何操作在發呆：）（沒有對伺服器構成壓力的動作）。因此只有那40%的人真正對伺服器產生了壓力，從這裏例子可以看出、併發用戶數關心的是不但是業務併發用戶數、還取決於業務邏輯、業務場景。因此我們需要本文第六部分性能測試文檔4、5、6。

3. 吞吐量

我把吞吐量定義為“單位時間內系統處理的客戶請求的數量”，直接體現軟體系統的性能承載能力，對於互動式應用系統來說、吞吐量反映的是伺服器承受的壓力、在容量規劃的測試中、吞吐量是一個重要指標、它不但反映在中間件、資料庫上、更加體現在硬體上。我們在以下方面利用這個指標：

（1） 用來協助設計性能測試場景，衡量性能測試是否達到了預計的設計目標、比如J2EE應用系統的連接池、資料庫事務發生頻率、事務發生次數。
（2） 用來協助分析性能瓶頸、參照本文第二部分總的RBI方法。

4. 性能計數器

性能計數器式描述伺服器或作業系統性能的一些資料指標、例如對WINDOWS來說使用記憶體數、CPU使用率、進程時間等都是常見的計數器。

對於性能計數器這個指標來說、需要考慮到的不但有硬體計數器、web伺服器計數器、Weblogic伺服器計數器、Servlet性能計數器、EJB2的性能計數器、JSF性能計數器、JMS性能計數器。找到這些指標是使用性能計數器的第一步、關鍵是找到性能瓶頸、確定系統閥值、提供優化建議才是性能計數器使用的關鍵。性能計數器複雜而繁多、與代碼上下文環境、系統配置情況、系統架構、開發方式、使用到的規範實現、工具、類庫版本都有緊密的聯繫、在此不作贅述。

5. 思考時間

我把思考時間確定為“休眠時間”。從業務系統的角度來說，這個時間指的是用戶在驚醒操作時、每個請求之間的時間間隔、從自動化測試的角度來說、要真實的測試模擬用戶操作、就必須在測試腳本中讓各個操作之間等待一段時間、體現在腳本上就是在操作之間放置一個Think的函數，體現為腳本中兩個請求語句之間的間隔時間、不同的測試工具提供了不同的函數或方法來實現思考時間、比如HP LoadRuner和IBM Rational Performance Tester的方式就完全不同。

性能測試方法論

1. SEI負載測試計畫過程
目標：產生一個清晰、好理解、可驗證的負載測試計畫
內容：關注6個區域：目標、用戶、用例、生產環境、測試環境、測試場景
工具：IBM、HP、OpenSource工具都支援。需有文檔配合

2. RBI方法

目標：快速識別性能瓶頸
內容：重點測試“吞吐量”指標，因為RBI認定80%的系統性能瓶頸由吞吐量造成。

按照網路、硬體、資料庫、應用伺服器、代碼的順序自上而下分析性能

工具：IBM、HP、OpenSource工具都支援。需使用分析模組、根據Weblogic、Oracle區別有專門的工具實現RBI。

3. 性能下降曲線分析法

目標：性能隨著用戶數的增加而出現下降趨勢的曲線分析、查看性能下降的環境點與上下文。確定性能閥值。
內容：通過單用戶區域、性能平坦區域、壓力區域、性能拐點進行監控和分析。
工具：IBM、HP、OpenSource工具都支援。IBM報表功能更強。

4. HP（LoadRuner）性能分析法

特點：側重于該廠商的性能分析方法、主要體現在需求收集、VU腳本。
缺點：沒有對測試計畫階段、測試設計階段的具體行為、方法、目的進行描述。方法局限於LoadRuner產品的特性上。不能通用。

5. IBM（Rational UP）軟體測試方法

特點：軟體產品生命週期RUP的實現、側重於迭代測試、寬廣的方法論。可適合任意測試環境及方法、工具。
缺點：需要根據測試環境進行剪裁、難以掌握、但掌握後非常成熟、高品質。
工具：涉及到IBM Rational 測試環境的所有軟體、功能強大。

6. PTGM性能測試模型

內容：一個非常適合行業用戶（電力、金融、政務、製造）的性能測試過程模型。規範化的測試模型、每個環節都做到迭代測試、每一個過程的工作產品明顯可察、測試流程、測試上下文方面很優秀。包括以下環節：前期準備、工具引入、測試計畫、測試設計與開發、測試執行與管理、測試分析。

工具：可以使用任意商業工具全新部署測試流程、不限於任何廠商工具的局限、也可以使用部分工具即可完成整個流程、或結合自己需要基於OpenSource工具進行定制。個人傾向使用多個產品的整合、綜合使用、揚長避短。

性能測試方法

1. 性能測試

性能測試方法通過類比生產運行的業務壓力量和使用場景組合測試性能是否能夠滿足需要。具備三個特點：

（1） 這種方法的目的是驗證系統是否具有系統宣稱具有的能力。
（2） 這種方法需要事先瞭解被測試系統典型場景、並確定性能目標。
（3） 這種方法要求在已確定的環境下運行

使用IBM Rational Performance Tester、HP Mercury LoadRuner、OpenSTA、Apache ab、Jmeter、QALoad 、TagUnit、Java Test Runner。

2. 負載測試

負載測試用來測定系統飽和狀態、確定閥值。其特點有：

（1） 這種方法的目的是找到系統處理能力的極限；通過“檢測、加壓、閥值”手段找到如“回應時間不超過10秒”，“伺服器平均CPU利用率低於65%”等指標。
（2） 這種性能測試方法需要在給定的測試環境下進行，通常也需要考慮被測系統的業務壓力量和典型場景、另外HP Mercury LoadRuner在使用該方法進行“加壓”的時候必須選擇典型場景。
（3） 這種性能測試方法一般用來瞭解系統的性能容量，或者是配合性能調優的時候來使用。特別是該專案的Weblogic Server和Oracle資料庫的性能調優。

3. 壓力測試

壓力測試方法測試目標系統在一定飽和狀態下，例如CPU、記憶體等在飽和狀態下、系統能夠處理的session的能力，以及系統是否會出現錯誤。該方法需要在系統cache調優與pool優化方面著手。該方法具備以下特點：

（1） 該方法的目的是檢查系統處於壓力情況下的，應用的表現。如增加VU數量、節點數量、併發用戶數量等使應用系統的資源使用保持一定的水準，這種方法的主要目的是檢驗此時的應用表現，重點在於有無錯誤資訊產生，系統對應用的回應時間等。
（2） 該方法通過類比負載在實現壓力。這種類比需要考慮的層面很多、首先、模擬必須是有效的，我的經驗是需要結合業務系統和軟體架構來定制類比指標、我測試過一些國內生產的壓力測試工具、他們使用通用的指標來考量、造成很多資訊回饋有很大的水分。需要考慮的層面如：Oracle I/O、JVM GC、Conn Pool等。
（3） 該方法還可以測試系統的穩定性。這裏的技巧在於“什麼樣的平台定義一個多長的壓力測試時間讓其穩定運行才是科學的？”

4. 配置測試

配置測試方式是指在測試前、測試中、測試後三個時間段通過對被測系統的軟體/硬體環境的調整，瞭解各個不同環境對系統性能影響的程度，從而找到系統各個資源的最優分配原則。它具備以下特點：

（1） 該方法的目的是瞭解各個不同的因素對系統性能影響的程度、從而判斷出最值得進行的調優操作。該方法不同於與“功能測試”中涉及到的“配置測試”。
（2） 該方法存在很大的靈活性、可以在測試環節的各個時間進行、但是什麼時候開始、什麼時候暫停、什麼時候結束才是運用這個方法的關鍵。同時也是HNDLZCGLXT考量性能測試服務供應商的關鍵。

5. 併發測試

該方法通過模擬用戶的併發訪問，測試多用戶環境併發訪問同一個應用、同一個模組或者資料記錄時系統是否存在鎖死或者其他性能問題。該方法特點是：

（1） 可以發現應用系統的全局性性能問題。
（2） 該方法可以在開發工作的各個環節使用可以使用多個工具的配合。如：Compuware公司的DevPartner工具、EJ-Technologie公司的J Profile工具，QUEST公司的J Probe工具等。
（3） 併發測試一般關注的問題是：

6. 可靠性測試

這裏說的“可靠性測試”並不等同於“獲得軟體的可靠性”，軟體的可靠性是一個很大的命題，這裏指的可靠性測試是通過給系統載入一定的業務壓力（例如：資源在80%~90%的使用率），讓應用系統運行一段時間、測試系統是否穩定運行。這裏有三點需要注意：

（1） 在使用該測試前需要目的系統的資源使用率已經達到70%~90%。即在這樣的苛刻環境下運行該應用系統。
（2） 應用系統運行起來後，載入業務壓力使應用系統資源達到90%。比如：該J2EE系統中設置的JDBC資料庫連接池定義為30，那麼載入業務壓力使連接達到27。
（3） 應用系統運行起來後結合業務情況來設定一個運行時間。比如：電力資產系統要求MTBF（平均無故障時間）達到10000小時、那麼我們可以認定該系統的運行時間至少需要達到三年重新啟動一次。超過這個數字我們就可以認為“不可靠”。一般情況下對於這個要求、我們讓J2EE系統在資源使用率90%~100%狀態連續穩定的運行3天左右沒有錯誤就可以認定該MTBF指標已經達到。

7. 失效恢復測試

該方法是針對有HACMP等冗餘備份和Edge Server for LB等負載均衡的J2EE系統設計的。該方法考量系統失效恢復的時間、用戶受到多大程度、多大範圍的影響，並將其量化。該方法有以下特點：

（1） 一般的關鍵業務都會採用雙機熱備或負載均衡方式來實現。
（2） 該方法回答兩個問題：當問題發生的時候“能支持多少用戶訪問”，“有多少功能不能使用”
（3） 需要說明的是，對於HNDLZCGLXT的這個專案來說，負載均衡需要仔細考慮其實現方式，這影響到性能的調優。可以考慮使用F5等硬體技術方式、也可以考慮使用 IBM WebSphere Edge Server等商業版本的軟體技術方式。否則單純對EJB 容器Weblgoic Server作集群沒有意義。

性能測試分析方法

該部分著重於PTGM方法論

1. 能力驗證

能力驗證一般採用這樣的描述：“該系統是否能在A條件下具備B能力？”。這裏強調以下內容：

（1） 充分準備以下內容：硬體設備、軟體環境、網路條件、基礎資料
（2） 充分準備測試場景、典型的場景包括操作序列、併發用戶數量條件、用例。
該部分包括使用到上述測試方法：性能測試方法、可靠性測試、壓力測試、失效恢復測試

2. 規劃性能

該分析方法關心的是“應該如何才能使系統具有我們要求的性能能力”，“應該如何調整系統配置，使系統能夠滿足增長的用戶數的需要”等問題。這個部分常常使用到的測試方法是：負載測試、配置測試、壓力測試。

3. 性能調優

一個標準的性能調優過程是：
（1） 確定基準環境、基準負載和基準性能指標。
（2） 調整系統運行環境和實現方法，執行測試。
（3） 記錄測試結果、進行分析

在J2EE性能測試中有很多常見的錯誤，比如：對於某些建立在J2EE/EJB技術上的應用，在服務啟動的時候，沒有注意到測試之前首先進行一段時間的預熱。這是因為JAVA語言的hot-spot技術特性決定的，這種技術允許weblogic第一次運行應用的時候將位元組碼編譯為本地代碼並執行，這樣在後續的執行過程中執行過程會大大加快，但第一次由於存在一個編譯過程會比較慢。如果使用這個時間來作為基準那麼就容易得出錯誤的結論。

我對第2個過程比較擅長、具體下來包括硬體環境的調優、Weblogic調優、Oracle調優。這個過程中也是使用工具最多的測試環節。

4. 發現缺陷

這個環節中是交付給用戶的主要工作成果。需要多和開發人員作溝通、多次迭代發現問題、根據用戶的需求定義與缺陷的涉及範圍、制定一個解決缺陷的優先順序。由於軟體永遠有BUG這一真理，所以發現缺陷不是一次就能結束的工作。比較適合作為服務外包。持續進行。

性能測試文檔

以下作為我對性能測試完整內容的建議，表格範本不作贅述
1. 《性能測試成員職責技能描述表》
2. 《性能測試工具需求規劃表》
3. 《性能測試環境調查表》
4. 《典型業務邏輯列表》
5. 《業務用例描述表》
6. 《測試場景列表》
7. 《測試計畫》
8. 《測試環境檢查表》
9. 《測試執行記錄日誌》
10. 《性能測試分析報告》