資訊科技基礎架構庫應用在資訊科技服務管理之研究

全文

(1)國立交通大學管理學院(資訊管理學程)碩士班碩. 士. 論. 文. 資訊科技基礎架構庫應用在資訊科技服務管理之研究 Application of Information Technology Infrastructure Library on Information Technology Service Management. 研究生：張煥旗指導教授：陳瑞順博士. 中華民國九十六年六月.

(2) 資訊科技基礎架構庫應用在資訊科技服務管理之研究 Application of Information Technology Infrastructure Library on Information Technology Service Management. 研究生：張煥旗. Student: Huan-Chi Chang. 指導教授：陳瑞順博士. Advisor: Dr. Ruey-Shun Chen. 國立交通大學管理學院（資訊管理學程）碩士班碩士論文. A Thesis Submitted to Institute of Information Management College of Management National Chiao Tung University in Partial Fulfillment of the Requirements for the Degree of Master of Science in Information Management June 2007 Hsinchu, Taiwan, the Republic of China. 中華民國九十六年六月.

(3) 資訊科技基礎架構庫應用在資訊科技服務管理之研究研究生：張煥旗. 指導教授：陳瑞順博士. 國立交通大學管理學院（資訊管理學程）碩士班. 摘. 要. 隨著企業對資訊科技的依存度日益升高，資訊科技無疑已成為許多商業流程不可或缺的部分，甚至是某些商業流程賴以運作的基礎。因此，資訊管理人員應該更深入的瞭解如何建立一套管理辦法，用以解決每天的資訊管理問題，以及建立公司的資訊服務管理標準流程。本研究應用資訊科技基礎架構庫之理論，提出一個可應用於資訊管理部門的資訊科技服務管理系統。本系統架構是以資訊科技基礎架構庫的服務支援和服務傳遞等二大主要領域為基礎，研究重點著重於針對資訊服務提供者對使用者提供資訊服務時，以長期的觀點來探求如何提昇資訊服務品質所應有的工作程序。同時，也針對每日系統的運作提供支援與維護，讓使用者可順利取得資訊服務提供者的相關資訊服務所應有的工作程序。本研究之目的在於應用資訊科技基礎架構庫的標準，建立公司的資訊服務管理標準，透過最佳方法的實做與流程的建立，以滿足對使用者的服務等級標準。本研究的結果確實能夠以資訊科技基礎架構庫為基礎，結合人員、流程、科技等資訊科技資源，發展出一套具有共通性與實用性的資訊科技服務管理方法，讓資訊科技資源發揮最大效能。本研究將該系統應用於資訊部門的管理實務上，根據實驗分析得知，本研究所提出的系統架構，能再造資訊科技服務管理流程，提升資訊科技服務的品質與效率，降低提供資訊服務的長期成本。. 關鍵字：資訊科技基礎架構庫、資訊科技服務管理、軟體工程。. I.

(4) Application of Information Technology Infrastructure Library on Information Technology Service Management Student：Huan-Chi Chang. Advisor：Dr. Ruey-Shun Chen. Institute of Information Management National Chiao Tung University Hsinchu, Taiwan, Republic of China. Abstract Enterprises have increased their dependence on information technology (IT). No doubt IT has been essential to business process. Therefore, IT department should understand how to establish rules and regulations in order to solve daily IT problems and establish the standard procedure of IT service. This study applied information technology infrastructure library (ITIL) and proposed the information technology service management (ITSM) system being suitable for IT department. The proposed framework is based on the service support and service delivery of ITIL. This study focused on how to enhance the quality of information service. The purpose of this study was to apply ITIL to establish the standard of IT service and the necessary service level agreement for users. The results of this study should integrate people, process, and technology, to develop the methodology of IT service based on ITIL. According to the analysis of this experiment, the proposed system should reengineer the business process of IT service, enhance the quality and efficiency of IT service, and reduce the cost of IT service.. Keyword: Information Technology Infrastructure Library, Information Technology Service Management, Software Engineering.. II.

(5) 誌. 謝. 本論文之完成，首先要感謝指導教授陳瑞順博士，在研究方向之設定，內容架構之建立及理論觀念之釐清等方面，都給予適切的指導與匡正。老師治學嚴謹及教學認真，令學生們印象深刻，追隨老師在資訊管理領域的學習，真是收穫良多。同時，要感謝交通大學資管所提供了優良的學習環境，讓本人在從事工作之餘能重返校園。在學習期間，感謝諸位師長不但學有專精，課堂之際更是如沐春風，而同學們來自四面八方，亦各有所長，晨昏切磋，感謝同學們令本人獲益匪淺。最後，對於家人的支持與鼓勵，致上最深的謝意。. III.

(6) 目. 錄. 中文摘要……………………………………………………………………….. I. 英文摘要……………………………………………………………………….. II. 誌謝…………………………………………………………………………….. III. 目錄…………………………………………………………………………….. IV. 表目錄………………………………………………………………………….. VI. 圖目錄………………………………………………………………………….. VII. 第一章緒論………………………………………………………………….... 1. 1.1 研究背景………………………………………………………………. 1. 1.2 研究動機………………………………………………………………. 2. 1.3 研究目的………………………………………………………………. 3. 1.4 研究步驟………………………………………………………………. 4. 第二章文獻探討…………………………………………………………….... 6. 2.1 資訊科技基礎架構庫…………………………………………………. 6. 2.2 資訊科技服務管理……………………………………………………. 10. 2.3 國際軟體工程標準……………………………………………………. 12. 第三章研究方法與問題探討……………………............................................ 24. 3.1 研究方法………………………………………………………………. 24. 3.2 問題探討………………………………………………………………. 26. 第四章資訊科技服務管理之分析與設計………………………………….... 27. 4.1 資訊循環內部控制制度之設計………………………………………. 27. 4.2 資訊系統控制機制之設計…………………………………................. 33. 4.3 組態管理之設計…………………………………................................. 35. 4.4 服務平台與問題管理之設計…………………………......................... 40. 第五章資訊科技服務管理之實作與分析………………………………........ 44. 5.1 個案公司簡介…………………………………………………………. 44. 5.2 組態管理之實作雛型…………………………………………………. 46. IV.

(7) 5.3 服務平台與問題管理之實作雛型……………………………………. 52. 5.4 效益分析………………………………………………………………. 60. 第六章結論與未來研究方向……………………………………………….... 62. 6.1 結論……………………………………………………………………. 62. 6.2 未來研究方向…………………………………………………………. 62. 參考文獻……………………………………………………………………….. 64. V.

(8) 表目錄表 1 服務品質的意義…………………………………………………………. 10 表 2 ISO/IEC 12207 三種型態的軟體開發流程…………………………….. 16 表 3 資訊系統控制機制………………………………………………………. 34. VI.

(9) 圖目錄圖 1 研究步驟…………………………………………………………………. 5 圖 2 資訊科技基礎架構庫之基本架構………………………………………. 7 圖 3 CMM 相關之家族體系…………………………………………………….. 23 圖 4 組態管理可提供之資訊…………………………………………………. 37 圖 5 使用者服務模型…………………………………………………………. 41 圖 6 服務平台與問題管理之系統架構………………………………………. 43 圖 7 網路管理之建置架構……………………………………………………. 48 圖 8 圖形化使用者介面………………………………………………………. 49 圖 9 事件子系統………………………………………………………………. 50 圖 10 網路拓樸圖………………………………………………....................... 51 圖 11 報表功能…………………………........................................................... 52 圖 12 報修處理流程…………………………………………………............... 53. VII.

(10) 第一章緒論 1.1 研究背景起源於 1980 年代的資訊科技基礎架構庫 (Information Technology Infrastructure Library, ITIL)，是當時英國政府為擬定一套標準化的 IT 管理流程，指派國家電腦局(CCTA)為專責單位，統整當時各政府機關已使用的管理知識，另外融入業界的 IT 管理實務，成為一套通用國際的管理標準。這套公開的 IT 基礎架構管理準則，全球已有無數企業與組織驗證其概念，並依其流程成功改善 IT 服務效率與品質。ITIL 國際認證在歐美地區素有資訊科技(IT)產業 MBA 之稱，儼然已成為跨國公司資訊主管的必修課程。它在歐美發達國家已經實施很長時間，近來才在我國金融、電信、製造業等資訊化程度高的行業興起[1,2]。 ITIL 把整體 IT 管理劃分為服務支援流程(support)和服務提供流程(delivery) 兩個面向，以支援中心(help desk)做為切入點，搭配十個 IT 最佳管理規範流程。服務支援(service support)流程根據服務協定以合理的成本提供服務，而服務提供 (service delivery)流程則制定服務等級協定、監督協定的執行，並評量最終結果─ ─整個過程的焦點不僅僅是 IT 部門是否提供了適當的服務，更重要的是他們提供的服務品質是否獲得用戶的肯定[3,4]。 ITIL 包含一系列模組，目的在因應 IT 服務管理面臨的課題，這些模組為 IT 服務管理提供最佳實作準則的規範；IT 部門可藉此增進 IT 服務管理的品質、提升效率，並能強化成效且降低風險[3]。企業根據 ITIL 進行 IT 管理，一方面讓業務部門可以根據一套用業務語言描述的量化評量指標與 IT 部門溝通，另一方面則讓 IT 部門提高服務品質，降低服務成本，學習處理與業務部門的關係[2]。. 1.

(11) 1.2 研究動機 ITIL 提供了一套 IT 服務管理的實務典範，以流程化的方式，進行 IT 服務管理(Information Technology Service Management, ITSM)。ITIL 一般被劃分成二主要區域：服務支持(Service Support)和服務交付(Service Delivery)。其中，服務交付裡的服務水準管理(Service Level Management; SLM)為確保顧客滿意所進行溝通互動達成共識的過程來建立機制信守承諾，以提供高品質的 IT 服務，提昇企業的競爭優勢是一重要課題。在 ITIL 所定義服務水準管理及協議的部分，經由 SLM 的管理作業過程中，以服務水準協議(Service Level Agreement; SLA)界定服務內涵及雙方應遵守的互動方式（例如，如有服務異常，立即得到通報），以便得以客觀研判 IT 組織績效[8,9]。綜觀這些 ITIL 的本質與企業所面臨的競爭環境，本研究的動機說明如下： (1) 複雜的資訊科技管理一向就是中大型企業 IT 人員最頭痛的問題。而隨著企業應用和設備環境愈趨複雜，掌控愈來愈困難，加上 IT 支出減少對軟硬體採購造成限制，於是包含軟體資產、網路及硬體設備、甚至是 IT 服務流程的 IT 管理議題，便日漸受到重視。 (2) 如何以支援企業營運為範疇，並在一定的成本考量下，進行協商、監督、設定衡量指標，建立服務水準基準值並建立自動監控與預警系統，加強故障排除能力及早解決問題，恢復正常運作以及報告服務成果、服務達成現況、檢討規劃待改善服務項目等，以維護 IT 服務品質，並從而改善客戶關係，提昇客戶滿意度。 (3) 當整個商業環境變化愈來愈快時，企業面臨高度的競爭壓力，必須投入更多的資訊建設，用以取得最快最新的訊息，做出正確的反應，如 ERP(Enterprise Resource Planning) ， SCM(Supply Chain Management) ， CRM(Customer Relationship Management)，KM(Knowledge Management)等等的系統，用來滿足客戶的要求及提高競爭力。. 2.

(12) (4) 在愈來愈多的系統被應用後，資訊科技服務管理的問題逐步浮現，資訊管理人員面臨的問題，已經不僅僅是個別軟體或硬體的搭配問題，還必須要能兼顧企業的商業維運，因此，資訊管理人員應該更深入的瞭解如何建立一套管理辦法，解決每天的資訊管理問題，以及建立公司的資訊服務管理標準流程。. 1.3 研究目的隨著企業對資訊科技的依存度日益升高，IT 無疑已成為許多商業流程不可或缺的部分，甚至是某些商業流程賴以運作的基礎。這種對 IT 角色的重視意味著 IT 要承擔更大的責任──提高商業的運作效率，同時降低業務流程的運作成本。但在現實環境卻是大部分的 IT 服務在這兩個要求上都不盡理想，探究其因不外是 IT 部門往往從技術層面而非商業角度來考量問題，或是在發現問題時缺乏適當的方法和工具[19,20,21]。資訊技術服務管理(IT Service Management; ITSM)是以 ITIL 為基礎，結合 People、Processes、Technology 等 IT 資源所發展出的一套具有共通性與實用性的 IT 管理方法，能讓 IT 資源發揮最大效能[13]。因此，本研究之目的在於： (1) 應用 ITIL 的標準，建立資訊科技服務管理標準，透過最佳方法實做，流程的建立，滿足企業對客戶的服務等級標準(Service Level Agreement, SLA)。 (2) 導入由流程驅動的作法，再造資訊科技服務管理流程。 (3) 增進 IT 服務的品質。 (4) 加強使用者與 IT 之間的溝通效率。 (5) 讓 IT 能對應目前與未來的業務需求。 (6) 降低提供資訊服務的長期成本。. 3.

(13) 1.4 研究步驟本論文是參考相關歷史文獻所提出的方法與架構，並參酌 ITIL 顧問服務廠商所提之最佳方法典範，依此架構來設計與建構整個資訊科技服務管理。同時在建構的過程中，隨時注意 ITIL 等相關標準的最新發展趨勢、以及最新應用狀況，以使本研究提出的架構，更能符合未來的趨勢與需求。本研究進行之主要步驟共分為七大步驟，歸納如圖 1 所示。詳細的步驟說明如下： (1). 研究相關的歷史文獻資料：蒐集並研究相關歷史文獻，包含顧問服務廠商的服務內容、資訊科技基礎架構庫的知識、資訊科技服務管理的知識等。 (2). 參酌 ITIL 顧問服務廠商的實務做法：參酌 ITIL 顧問服務廠商實務上的做法以及分析個案資料，將資訊科技基礎架構庫應用在實際的資訊科技服務管理上，並以所得到的回饋資訊，做為修改整個架構之參考。 (3). 分析與設計資訊科技服務管理：首先定義資訊科技服務管理的需求內容，再根據需求來定義資訊科技服務管理所應採用的技術與具備的功能。當完成這些前置作業時，就可以設計與建構一個簡單的資訊科技服務管理。 (4). 確定論文的整體架構：依據相關文獻、個案資料及資訊科技服務管理的測試及改良，確定最後完成的整體架構。 (5). 資訊科技服務管理之實作：實作資訊科技服務管理，並作完整的測試。 (6). 成果分析與比較：分析最後產生的成果，並與事前期望的結果作一個比較，以找出差異之處與原因。 (7). 未來研究方向及撰寫論文：探討目前資訊科技服務管理不足的地方，並擬定未來可以繼續研究的方向，以及完成論文報告。. 本研究之架構共包括六個章節，分別說明如下： (1). 第一章緒論：主要是說明研究背景、研究動機、研究目的、以及研究步驟。 (2). 第二章文獻探討：以本研究相關之文獻知識作為探討之主題，其內容包括資訊科技基礎架構庫、資訊科技服務管理、國際軟體工程標準等。 (3). 第三章研究方法與問題探討：本章以本研究所採用的研究方法為討論重 4.

(14) 點，並討論目前資訊部門所面臨的問題與挑戰。 (4). 第四章資訊科技服務管理之分析與設計：首先說明資訊循環內部控制制度之設計，接著說明資訊系統控制機制之設計、組態管理之設計、服務平台與問題管理之設計等。 (5). 第五章資訊科技服務管理之實作與分析：本章首先說明實作之個案公司簡介，接著則是說明組態管理之實作雛型範例，以及服務平台與問題管理之實作雛型範例，並對該資訊科技服務管理之效益進行說明。 (6). 第六章結論與未來研究方向：主要說明本研究所獲得的成果，及未來的研究方向。. 1. 研究相關的歷史文獻資料. 2. 參酌 ITIL 顧問服務廠商的實務做法. 3. 分析與設計資訊科技服務管理. 4. 確定論文的整體架構. 5. 資訊科技服務管理之實作. 6. 成果分析與比較. 7. 未來研究方向及撰寫論文圖 1 研究步驟. 5.

(15) 第二章文獻探討 2.1 資訊科技基礎架構庫 2.1.1 資訊科技基礎架構庫的意義資訊科技基礎架構庫(Information Technology Infrastructure Library, ITIL)源起於 1980 年被英國政府 CCTA（Central Computing Telecommunications Agency）製訂出來的，當時主要目的在於確保資訊服務與資源的善用；後來隨著資訊與科技的發展，再加上 ITIL 逐漸受到全球的重視與使用，ITIL 已成為資訊服務管理領域之中，最廣為應用的最佳實務[8]。資訊科技基礎架構庫為資訊服務提供一個完善的管理體制，使服務提供者可以控管內部服務資源並提供高品質及有成本效益的服務。資訊科技基礎架構庫主要適用於資訊服務管理領域，為一套可確保企業在提供資訊服務時，達到組織所要求之水準的最佳實務準則與相關流程。在設計上，ITIL 是根據實務的資訊營運服務規劃與交付的經驗而衍生出來的一套實務的基礎架構，並非純理論上的方法學，因此 ITIL 可適用於任何產業與規模；更好的優點是，企業採用 ITIL 時，不需要支付任何相關的證照費用，這也是大部分企業想躍躍一試的主要因素之一 [1,2]。資訊科技基礎架構庫的雛型自 80 年代成型至今，歷經十數年來的調整與實務驗證，終於在 2000 年由 OGC (英國商務部)，BSi(英國標準協會)與 itSMF(資訊服務管理論壇)等機構正式發布以 ITIL 為基準的 BS15000 制度[3,10]。 ITIL 涵蓋的領域很廣，主要區分為六大部份：Service Support、Service Delivery 、 Planning to Implement Service Management 、 ICT Infrastructure Management、Application Management、The Business Perspective，如圖 2 所示[9]。資訊科技服務管理（IT Service Management, ITSM）則是以 ITIL 為基礎，結合 People、Processes、Technology 等 IT 資源所發展出的一套具有共通性與實用 6.

(16) 性的 IT 管理方法，能讓 IT 資源發揮最大效能[4,12]。. 圖 2 資訊科技基礎架構庫之基本架構. 2.1.2 資訊科技基礎架構庫的核心內容在資訊科技基礎架構庫的六大範圍裡，又以 Service Delivery 與 Service Support 為資訊服務管理為主軸的核心內容，其內容說明如下[11,13]： 1.服務傳遞（Service Delivery）服務傳遞主要為針對資訊服務提供者對客戶提供資訊服務時，以長期的觀點來探求如何提昇資訊服務品質所應有的工作程序，其程序包含： (1) 服務層級管理（Service Level Management）：指在可接受的服務成本之下，讓服務提供者與客戶之間達成一個彼此皆認同的最佳服務協定；同時，透過一個連續週期的協議、監控、報告來維護並促進資訊服務的品質，以達成資訊服務的傳遞並同時消除低劣的服務品質。 (2) 資訊服務的財務管理（Financial Management for IT Services）：指在服務提供者供應服務時，提供給客戶一個俱有成本效益的資訊資產、該資產相關管理 7.

(17) 作業及相關之財務資訊以達到價格與服務品質的最佳化。 (3) 產能管理（Capability Management）：為確保在任何狀況之下，資訊服務提供者均有足夠的能力，如技術、人力、處理能力等，提供並滿足企業目前甚至於未來所需的資訊服務。換言之，就是服務提供者能確保在對的時間、對的地點，以適當的成本，提供客戶對的資源。 (4) 資訊服務持續性管理（IT Service Continuity Management）：為支援所有商業持續性管理的流程，以確保客戶所需要的資訊服務及服務的設備可於既定的時程之內回復正常的運作；另外，此管理也協助企業在重大事件發生時，盡其所能地降低企業核心營運中斷的機率以減少企業的損失。 (5) 可用性管理（Availability Management）：指資訊服務供應商在善用資源、方法與技術的前提之下，保障客戶資訊服務的可使用性；可用性管理主要在探討哪些資源與衡量是維持客戶營運的最佳狀態所必備的，讓資源達到最有效的運用。. 2.服務支援（Service Support）服務支援主要針對每日系統的運作提供支援與維護，其服務支援對象為設備的使用者，主要目的是讓使用者可順利取得資訊服務提供者的相關資訊服務。其主要的工作流程包含： (1) 服務平台（Service Desk）：為一個讓資訊使用者與服務供應商接洽和反應的服務平台機制，提供對使用者的服務窗口，主要負責協助客戶儘快恢復營運的服務，例如提供使用的指導與修正，或針對某一意外事件做相關補救措施。 (2) 事件管理流程（Incident Management）：主要為確保資訊使用者所有的服務需求與服務異常時，服務提供者處理的事件流程管理。事件管理流程是一個反應性的工作，為當對意外事件的發生，藉由資訊服務來減少與降低可能對客戶所產生的衝擊，以確保使用者儘速地恢復正常工作。這個流程主要重點在於將事件儘快的解決而不去探索造成事件真正的原因。 8.

(18) (3) 問題管理流程（Problem Management）：這個流程主要針對可能造成服務的中斷與異常等相關問題進行鑑別及分析，讓客戶所造成的影響減至最低的管理流程；主要的目的在於為事件真正肇因的探求與管理，已避免未來類似的情況再度發生。 (4) 組態管理（ Configuration Management ）：定義所有服務的組成元件（components），並對其元件加以控管以確保相關資訊之準確性的管理。對於公司資訊資源的掌握是做好資訊服務最基本的環節，所以建立 CMDB （Configuration Management Database）也是該流程最重要的步驟，確實管理資訊資源並提供組態項目的相關報表(如版本資訊或變動記錄等)，才能確實讓資訊服務的發展建立良好的基礎。 (5) 異動管理流程（Change Management）：指服務提供者透過評估、核可、實施與審查等機制，對所有的變更及異動作業進行有效控管之管理。換言之，異動管理流程主要在於管理資訊架構之下所有異動的需求，包含異動需求的受理、執行與記錄；由於異動可能對客戶帶來的衝擊，所以相關的成本、優缺點及風險的評估也是異動管理流程中相當重要的一環；而異動過程中的管理與協調，以及之後的監控及報告、定期複察等，都需將資訊回饋至 CMDB 做一個妥善的管理，形成資訊流得一個正向循環。 (6) 版本管理流程（Release Management）：所有變更或異動後的相關服務資源或服務元件（components）正式上線前所需的執行管理流程；服務提供者透過服務平台所提供的資訊服務(如電腦設定、軟體安裝等)，經由版本管理的流程，已確保將最新的服務內容提供給資訊使用者時，維持議定的服務品質。. 9.

(19) 2.2 資訊科技服務管理 2.2.1 服務與服務品質之意義服務是無形的、具有不可觸摸性、不可分割等性質，根據 Kolter 的說法，服務(service)有下列特性[17]： (1) 不可觸摸性(intangibility)：服務是無形的，在購買之前，服務是無法看見、品嚐、感覺、聽見及嗅聞到的。 (2) 不可分割性(Inseparability)：服務的產出與消費是同時發生。 (3) 可變性(Variability)：服務具有高度的可變性。 (4) 易逝性(Perishability)：服務是無法儲存的。. 針對服務品質的意義，本研究彙集相關學者對服務品質的論點，如表 1 所示。這些學者對服務品質的觀點，主要是以“消費者對服務的期望與認知”為基礎，而非以“服務提供者”的觀點，因此在衡量服務品質時，應以消費者對服務的認知與期望，作為衡量的基礎。因此本研究認為服務品質的定義，即「服務品質 =實際感受服務品質-期望的服務品質」[18,19]。. 表 1 服務品質的意義提出者. 服務品質的意義. Garvin(1983). 是一種主觀認知的品質，而非客觀的認知。. Sasser(1978). 認為服務水準是指提供服務對顧客所帶來的利益，可分為期望服務水準與知覺服務水準。. Gronroos(1982). 是顧客對服務的期望與接受服務後的知覺間的比較而得。. Cronin(1992). 主張服務品質應由服務執行績效來衡量，不須再與期望服務水準來比較(服務品質=實際感受服務品質)。 10.

(20) Parasuraman(1985). 認為對服務的好壞，可用服務品質來評估，而評估服務品質最適當的方法，就是本身對服務的期望，以及顧客接受服務後實際感受到服務成果的知覺，二者比較後而得(服務品質=實際感受服務品質-期望的服務品質)。. 2.2.2 服務水準協議近年來，資訊服務的品質逐漸受到重視，在國外，一些網路服務或通訊業者如 UUNET 等，對其客戶提出服務水準的保證，或與客戶簽訂服務水準協議 (Service Level Agreement, SLA)，保證其所提供的服務品質能夠保持一定的水準，以維繫客戶的忠誠度。某些組織，如英國 University of Leeds 、美國 University of Michigan 等，也要求其委外資訊服務廠商訂定服務水準協議，這些現象顯示，資訊服務的使用者已不能滿足於「量」的供給，同時並要求「質」的提昇[17]。在 ITIL 所定義服務水準管理及協議的部分，經由 SLM 的管理作業過程中，以服務水準協議界定服務內涵及雙方應遵守的互動方式（例如，如有服務異常，立即得到通報），以便得以客觀研判 IT 組織績效。因此，服務水準協議是定義供應商提供使用者服務品質責任，並補充與結合契約，其包含更正活動、懲罰條款、未履行條款、偏誤總數、修正程序、回報政策、終止準則、智慧資產條款、紛爭解決程序等。而服務水準協議則包含下列四項重點[20,21]： (1) 可用性(Availability) (2) 安全性(Security) (3) 效能性(Performance) (4) 客戶服務(Customer Service). 2.2.3 BS15000 與 ISO20000 在 ITIL 廣泛被各國企業所採用後，企業如何衡量導入 ITIL 之效益？為了對 11.

(21) ITIL 的導入效益作有效的評估， OGC 、英國標準協會（ British Standards Institution，簡稱 BSI）及相關團體，共同制定了以 ITIL 為核心的國際標準： BS15000，於 2000 年在全球最大的 ITIL 推動機構 - IT 服務管理論壇（IT Service Management Forum，簡稱 itSMF）正式發布，並於 2002 年被提交給國際標準化組織（ISO），申請成為 IT 服務管理的國際標準，再於 2005 年 12 月正式通過成為 ISO20000 國際標準[14,15,16]。目前世界上有越來越多的企業開始採用 ISO20000 這一套綜合標準，由於它凝聚了大量實踐經驗，企業可藉由此標準來建立適合自己的「IT 服務管理」流程與方法，除可確保其所提供的服務符合客戶企業之需求，亦可確保在有限的預算下，提昇系統及其服務的可靠性及可用性，並且符合國際規範。根據 Gartner 之分析，由於組織對 IT 服務成本及效益（ROI）日趨重視，ISO20000 / BS15000 之導入將會成為組織將來挑選 IT 服務供應商之重要參考依據[14,15,16]。. 2.3 國際軟體工程標準根據統計目前世界上至少有 315 個以上的軟體工程標準、指引、手冊、與技術報告正被 46 個以上的專業、地區、國家、和國際標準組織所維護。舉例來說，美國電機及電子學工程師聯合會(IEEE)在 1981 年時才只制定一種軟體工程標準，而到 1997 年底，標準總數已成長到 40 種之多。軟體工程領域中，五種較為常見之標準方法，包括：IEEE Software Engineering Standards、ISO/IEC/IEEE/EIA 12207、SEL Recommended Approach、SSDM Standards and Procedures、ISO 9001 (包含 ISO 9000-3)、軟體能力成熟度模式等[5,6]。. 2.3.1 IEEE Software Engineering Standards 12.

(22) IEEE 對於軟體工程標準(Software Engineering Standards)的制定早在 1976 年即已開始，透過軟體工程技術委員會 (Technical Committee on Software Engineering, TCSE) 之下的軟體工程標準工作小組 ( 簡稱軟標小組 ,Software Engineering Standards Subcommittee, SESS)積極研擬，歷經三年軟標小組即首度提出 IEEE 的軟體工程標準之試用版，到了 1984 年，總共已有如下之五種軟體工程的標準了[22]： (1) IEEE Std 730-1981, IEEE Standard for Software Quality Assurance Plans (2) IEEE Std 729-1983, IEEE Standard Glossary of Software Engineering Terminology (3) IEEE Std 828-1983, IEEE Standard for Software Configuration Management Plans (4) IEEE Std 829-1983, IEEE Standard for Software Test Documentation (5) IEEE Std 830-1984, IEEE Recommended Practice for Software Requirements Specifications. 在 IEEE 發行的軟體工程標準彙編中，它將所有的標準依物件導向的觀念分成四大類，而且假設軟體工程的工作執行都是透過專案的方式完成，即：每一個專案都會與"顧客"互動，它也會耗用某些"資源"以執行某些"流程"，而交付特定的"產品"。根據這種理念，軟體工程標準彙編便環繞在顧客標準、資源標準、流程標準、及產品標準等四種物件上，而每一種標準之下又再細分為需求標準 (standards)、建議慣例(recommended practices)、及指引(guides)[22]。整個標準彙編並不是針對某一種單獨的使用對象，所有 40 個的標準都各有不同的設定對象，包括：專案經理、系統工程師、軟體開發人員、測試人員、型態管理人員、品保人員、系統委辦人員等等，而將整個標準彙編區分為四大冊，主要是考慮某一類的使用對象其相關標準的整合而已[22]。這些標準也沒有單一的應用領域。以下列舉其應用領域[22]： 13.

(23) 1.第一冊(顧客與專門術語之標準, Customer and Terminology Standards)中的若干應用領域 (1) 軟體獲得(software acquisition) (2) 軟體安全(software safety) (3) 軟體需求(system requirements) (4) 軟體開發流程(software life cycle processes, IEEE/EIA 12207). 2.第二冊(流程標準, Process Standards)的若干應用領域 (1) 軟體品質保證(software quality assurance) (2) 軟體型態管理(software configuration management) (3) 軟體單元測試(software unit testing) (4) 軟體驗證與確認(software verification and validation) (5) 軟體維護(software maintenance) (6) 軟體專案管理(software project management) (7) 軟體開發流程(software life cycle processes). 3.第三冊(產品標準, Product Standards)的若干應用領域 (1) 可靠度軟體之量度(measures to produce reliable software) (2) 軟體品質因子(software quality metrics) (3) 軟體使用文件(software user documentation). 4.第四冊(資源與技術標準, Resource and Technique Standards)的若干應用領域 (1) 軟體測試文件(software test documentation) (2) 軟體需求規格(software requirements specifications) (3) 軟體設計描述(software design descriptions) (4) 中界再用庫之操作概念(concept of operations for interoperating reuse libraries) 14.

(24) (5) 輔助工具之評估與選擇(evaluation and selection of CASE Tools). 2.3.2 ISO/IEC/IEEE/EIA 12207 International. Organization. for. Standardization. (ISO) 和. International. Electrotechnical Commission (IEC)共同合作制定一個國際標準，ISO 和 IEC 都是由技術性的國際個體組成，分別致力於不同工作領域的標準制定；而在資訊科技方面，ISO 與 IEC 共同組成一個聯合科技委員會稱為 ISO/IEC Joint Technical Committee 1 (JTC1)，此 JTC1 再擴充許多不同的次委員會專門負責不同種類的資訊技術制定相關標準，其中專門負責軟體工程標準的次委員會則被取名為 Subcommittee 7 (ISO/IEC JTC1/SC7)。在 1990 年早期，SC7 即已決定為軟體開發流程制定一套國際標準，而且也於 1995 年發表編號 ISO/IEC 12207：1995 的標準，真正的內容名稱為"資訊技術--軟體開發流程(Information technology- Software life cycle processes)"。因為在參與 SC7 的國際個體組織中，有很多單位期望這套國際標準也能涵蓋合約導向的環境，所以 ISO/IEC 12207 也很注重供應商與採購商(supplier/acquirer)之間的關係，它不但指出一般軟體開發單位所需要執行的工作之外，也列出其他準備採購軟體單位所需的工作項目[22,23]。基本上，ISO/IEC 12207 可應用於採購諸如系統、軟體產品、及服務等項目，而針對供應商，它也適用於軟體產品之開發、運作、以及維護等作業；甚至它也可應用於韌體產品的部分。換言之，它對系統的定義實質上包括軟體產品及相關服務項目，但在軟體開發流程期間所使用的流程則與系統生命週期期間所使用的流程互相對應兼容[22,23]。基本上， ISO/IEC 12207 主要是在定義一個軟體開發流程的整體架構 (framework)。它透過一個層次化的結構方式，來表示在軟體開發、供應、獲得、運作、和維護等各階段中所需的流程(processes)、活動(activities)、及工作(tasks) 之關係；它分為軟體開發和獲得兩階段，更同時兼顧技術和管理方面的問題。 ISO/IEC 12207 共包括了三種型態的軟體開發流程：主要、輔助、組織，其分類 15.

(25) 層次如表 2 所示[22,23]。. 表 2 ISO/IEC 12207 三種型態的軟體開發流程流程分類主要流程. 流程內容 (1)獲得(acquisition) (2)供應(supply) (3)開發(development) (4)運作(operation) (5)維護(maintenance). 輔助流程. (1)文件(documentation) (2)型態管理(configuration management) (3)品質保證(quality assurance) (4)驗證(verification) (5)確認(validation) (6)共同審查(joint review) (7)稽查(audit). 組織流程. (1)管理(management) (2)基礎建設(infrastructure) (3)改善(improvement) (4)訓練(training). 2.3.3 SEL Recommended Approach 到目前為止，美國 NASA 哥達德太空飛行中心(Goddard Space Flight Center, GSFC) 下之軟體工程實驗室 (SEL) 已出版了 SEL 的推薦方法 (Recommended Approach)三個版本如下：SEL-81-105 (1982 年 5 月)、SEL-81-205 (1983 年 4 月)、. 16.

(26) SEL-81-305 (1992 年 6 月)。此份文件標準主要是專門針對飛行動力學領域的軟體專案而設計的，因此文件中第 3 頁特別有這樣的警告：由於本標準僅適用於飛行動力學的專業應用，若某些環境的性質有顯著差異時，讀者需注意本文件所介紹的原則可能不適用[22]。基本上，SEL Recommended Approach 涵蓋：需求定義、需求分析、初步設計、細部設計、系統實作、系統測試和接收測試等七個軟體生命週期階段；然而，維護和系統運作並不在 1992 年修訂的文件標準版本之內，不過在文件的第 10 頁它也列出 SEL 在軟體維護方面的一些論文參考資料。根據 1992 年修訂版的引言，這份文件主要在提供一套軟體開發方面的經驗準則，它是專為軟體專案經理，以及如軟體工程師、分析師、和程式員等技術人員而設計的；然而，它並不是一種技術手冊，也不是一本諮詢指南。簡單地說，它推薦提供每一個生命週期階段所需的軟體方法和使用工具，目的在開發一套易管理、高可靠度、合乎成本效益的軟體產品[22]。. 2.3.4 SSDM Standards and Procedures GSFC Mission Operations and Data System Directorate (MO&DSD)從 1987 年 11 月到 1997 年 9 月期間，選擇 CSC 作為系統、工程、和分析支援(Systems, Engineering, and Analysis Support, SEAS)專案的主要承包單位，專門開發軟體系統。在 1989 年 7 月，CSC 首先出版 SEAS 系統發展方法(System Development Methodology, SSDM)，作為系統發展方法的標準。SSDM 是以七十年代後期的 CSC 專屬軟體發展方法為基礎，並配合 MO&DSD 之目的和文化而修正，此外，它也深受 SEL 推薦方法和 CSC 對於傳統軟體發展方法的影響[22]。以 SSDM 為基礎的方法和技術發展而成 SSDM 之標準和作業程序(SSDM Standards and Procedures, SSDM S&Ps)是在 1990 年 6 月首次出版，某些標準提供特定文件格式和內容的樣板，與軍方之資料項描述(DIDs)非常類似，而某些標準則提供表格的樣板格式，甚至描述如何執行像系統需求複查之類的事件；換言 17.

(27) 之，它明確定義一個流程之進行步驟，例如應如何檢查和驗證某一個單元之設計。在 SSDM 的序言中已載明：SSDM 主要是在提供系統發展方面的全方位指引，無論是硬體或軟體的系統，從系統的概念形成、發展、安裝，到驗收等各個階段都涵蓋。簡單地說，SSDM 包羅了專案管理、系統工程、和系統生命週期發展等領域知織。值得一提的，因為 SSDM 是從當初只針對軟體開發的 DSDM 遞變而來，因此，它仍保留深度的軟體開發細節；不過它也另闢有關於硬體發展的一個章節，而 SSDM S&Ps 則包含有硬體製造方面的三項標準[22]。基本上，通常採用如 SSDM 之類的標準化方法之原因是為了降低在系統發展過程中可能遭遇的風險，而這些風險更可能進一步會影響到專案的時程、預算、功能性、以及整體之性能表現。這些問題在 SEAS 專案中便經常地發生；但是，現在它們不僅不常出現並且即使發生，其結果也不像過去那樣嚴重，這是因為 SSDM 和它相關的標準與作業程序已在實際發展系統時證明非常有效而成功。SSDM S&Ps 總共分為七大類如下，括號中的數字表示每一個章節所包含標準和程序的數目[22]： (1) 專案管理 (33) (2) 系統工程 (3) (3) 硬體發展 (3) (4) 軟體發展 (24) (5) 系統測試與評估 (3) (6) 文件 (32) (7) 標準和程序之建立 (3). 2.3.5 ISO 9000 Suite 在 1987 年，主要任務在提昇品質之 ISO 第 176 號技術委員會，出版了品質標準方面的第一個版本 ISO 9000 套組(從 ISO 9000 到 9004)，之後修訂版是在 1994 年出版，而第二個修訂版也已完成並在 2000 年 12 月 15 日正式頒布[23]。 18.

(28) 幾乎在 ISO 9000 標準文件首次出版之同一時期，ISO 軟體委員會即開始與相關品質委員會討論，尋求發展一套將 ISO 9001 應用於軟體環境之指導方針。接著 ISO 便在 1990 年公佈 ISO 9000-3 的第一個草案，針對軟體的開發、供應及維護等作業，提供應用 ISO 9001 的指引。然而遺憾地，因這個草案未與 ISO 9001 一致，使得要在 ISO 9001 的說明中，找到對應軟體專屬的指導原則卻相當困難；因此，ISO 在 1997 年再出版一套與 ISO 9001：1994 一致的 9000-3 更新版，而另一個修訂版也巳在 2000 年底完成[23]。最初 ISO 9001 提出 20 種品質需求，包括管理責任、品質系統、設計控制、教育訓練、統計技術等方面，其中 ISO 9000-3 則是專為軟體開發環境而設的；後來修訂版的範圍更大為擴充，其組織內容詳如後列[23]。整體來說，ISO 9001 是一個標準套組，專用來建構、運作一套品質管理系統，並輔助編輯其文件說明。更確切地說，ISO 9001 是一套適用於產品各生命週期如設計、開發、生產、安裝、服務等階段的品質標準，而 ISO 9000-3 則是將 ISO 9001 應用到軟體系統的一種指南[23]。結構上，ISO 9001:1994 分為下面 20 種需求，而 ISO 9000-3:1997 也具有相同的組織架構[23]： (1) 管理責任(management responsibility) (2) 品質系統(quality system) (3) 合約審查(contract review) (4) 設計管制(design control) (5) 文件及資料之管制(document and data control) (6) 採購(purchasing) (7) 客戶供應品之管制(control of customer-supplied product) (8) 產品鑑別與追溯性(product identification and traceability) (9) 製程管制(process control) (10) .檢驗與測試(inspection and testing) 19.

(29) (11) 檢驗、量測與測試設備之管制(control of inspection, measuring and test equipment) (12) 檢驗與測試狀況(inspection and test status) (13) 不合格品之管制(control of nonconforming product) (14) 矯正及預防措施(corrective and preventive action) (15) 搬運、儲存、包裝、保存與交貨(handling, storage, packaging, preservation and delivery) (16) 品質紀錄之管制(control of quality records) (17) 內部品質稽核(internal quality audits) (18) 教育訓練(training) (19) 服務(Servicing) (20) 統計技術(Statistical techniques). ISO 9000 標準套組普遍受歡迎並廣為採用的原因之一，是它不為任何專門應用領域而設計的；而且這些標準目前更在各式各樣的應用領域如：製造、醫學、財政、通訊、和軟體等等，被用來驗證一個專案產品或單位機構的品質水準[23]。. 2.3.6 軟體能力成熟度模式軟體能力成熟度模式（Capability Maturity Model for software; SW-CMM 或 CMM）係以軟體流程為基礎所建立的一套用來評估軟體開發機構的內部管理流程改善能力，以及提昇軟體品質的架構指引[24]。由於美國政府於 80 年代經常外包專案給不同的軟體公司，發現影響軟體公司的研發能力與產品品質的關鍵因素在於其軟體開發流程是否能有效管理，故美國國防部於 1986 年 11 月委託卡內基美隆大學（Carnegie Mellon University）的軟體工程學會（Software Engineering Institute; SEI），開始進行軟體流程改善之量. 20.

(30) 化研究。於 1987 年 9 月首度發表軟體流程成熟度架構的研究成果，提出「軟體過程評估」和「軟體能力評價」兩種評估方法和軟體成熟度提問單。其後經過不斷的研究改進，1991 年正式發表「軟體能力成熟度模式（Capability Maturity Model for Software; SW-CMM 或 CMM）」V1.0 版。並在 1992 年 4 月辦理 CMM 研討會，在彙整眾多軟體專家意見後，終於在 1993 年發表 CMM V1.1 的修訂版。CMM 陸續衍生出軟體工程、系統工程以及軟體採購等模型，已是目前國際間所普遍認同的軟體研發過程標準[24]。然而，SEI 對於修訂 CMM 版本的工作仍持續進行中。原定 1997 年底完成的 CMM V2.0 版，由於 1997 年 10 月美國國防部要求 SEI 設法將現有與未來將發展的各種能力成熟度模式整合為一種整體架構，故 2000 年底發表了整合軟體工程（SW）、系統工程（SE）、整合產品發展（IPD）的「軟體能力成熟度整合模式（Capability Maturity Model Integration; CMMI）」。此後，CMMI 即與 CMM 畫上等號[24]。 CMM 的理論基礎即是戴明(W. Edwards Deming)和裘蘭（Joseph M. Juran）所修正與推廣的全面品質管理技術（Total Quality Management; TQM）。由於 IBM 公司的羅帝斯（Ron Radice）及哈弗雷（Watts Humphrey）兩位軟體工程師率先將 TQM 的理念應用到軟體領域，因此，當哈弗雷先生 1986 年自 IBM 公司退休後加入 SEI，其全面軟體品質管理(TSQM, Total Software Quality Management)的概念便成為 SEI 於 1987 年所發表 CMM 的主要立論基礎[24]。圖 3 係表示與 CMM 相關之家族體系，並於下文中簡要描述各模式的內容 [24]。 (1) 軟體能力成熟度整合模式（CMM Integration; CMMI）：軟體能力成熟度整合模式(CMMI)是 SEI 自 1997 年以來持續進行的一項計畫，目的在整合前述不同的成熟度模式，整體性地考量組織之作業流程與成熟度，以提升產品或相關服務之開發、獲得及維護等管理作業的能力水準。 (2) 軟體能力成熟度模式（CMM for Software; SW-CMM 或 CMM）：軟體能力成 21.

(31) 熟度模式（SW-CMM）是將 TQM 應用到軟體領域的軟體開發與維護作業上，目的是提升軟體開發能力來達成高生產力、高品質產品等專案目標。意即，SW-CMM 係一種工作指引，主要在指導軟體開發機構如何有效控制以及改善其軟體開發與維護之流程，而成為一卓越之軟體開發機構。此外， SW-CMM 也可作為軟體成熟度鑑定（Appraisal）時之參考模式。通常 SW-CMM 都被簡稱為 CMM。 (3) 系統工程能力成熟度模式（Systems Engineering CMM; SE-CMM）：系統工程能力成熟度模式（SE-CMM）係針對工業界系統工程領域的實際需求，主要在描述要建立一套良好系統工程流程的組織所須具備的要件。總言之，它並不針對某特殊流程，而是屬於一般性的指引架構，包括：從需求面探討模式應具備的條件、從執行面提供建議原則等。 (4) 整合產品發展能力成熟度模式（ Integrated Product Development CMM; IPD-CMM）：整合產品發展能力成熟度模式（IPD-CMM）係提供軟體機構一個指引架構，用以協助其開發整合性產品之相關作業，例如設計、發展、鑑定與改善等活動。IPD-CMM 本質上是一套產品發展的系統化方法，其基本作法即從功能面出發，整合各種所需的流程，以有效生產具效益的產品。 (5) 人力資源能力成熟度模式（People CMM; P-CMM）：SEI 發展人力資源能力成熟度模式（P-CMM）用來描繪人力資源的消長變化。1995 年 9 月正式公布之 P-CMM 1.0 模式，係針對一個軟體發展機構的人力資源，探討如何持續改善其人力開發與管理等作業活動，並希望藉由所提出度量準則的指引，協助該軟體機構根據其人力資源成熟度的特性，建立一套人力開發計畫，設定活動改善之優先順序，並循序地進行招募、培養、激勵等工作，甚至營造一種優良的組織文化，進而提升軟體組織開發能力的成熟度。 (6) 軟體籌獲能力成熟度模式（Software Acquisition CMM; SA-CMM）：軟體籌獲能力成熟度模式（SA-CMM）係組織取得或採購軟體相關系統之成熟度模式，用以評估與改善軟體籌獲流程。公司根據以往成功獲得軟體系統和產品 22.

(32) 的流程與經驗為基礎而建立的 SA-CMM，主要描述軟體獲得管理與改善流程作業方面的關鍵要件。. 軟體能力成熟度模式整合. 人力資源能力成熟度模式系統工程能力成熟度模式軟體籌獲能力成熟度模式整合產品發展能力成熟度模式. 圖 3 CMM 相關之家族體系. 23. 能力成熟度整合模式.

(33) 第三章研究方法與問題探討 3.1 研究方法本論文之研究方法，乃是依據個案研究（Case Study）之理論為基礎，來作為本論文之整體的研究方法。「個案」一般指某一事物的實例或發生。這「事物」可能是一個特殊的事件，一個獨特的例子，一種疾病等等。R. E. Stake 對個案所下的定義為：「是一個有界限的系統（a bounded system）。個案研究是一種對於各種重要個體，無論是個人、群體、社區、組織機構，運用觀察、蒐集、分析、解釋，以解決其情境中的難題，改善其適應的一種研究方法。換言之，即以有效完整之資料，對某一個體單位的特殊問題，探求其真相，診斷其導因，研究矯治的方法。因此，個案研究是指所研究的是現時的現象，發生在真實的生活裡，且現象與情境（背景）往往無法清楚分割或界定。在進行實地研究之前，有個理論命題指引研究所要觀察的範圍，藉著各種資料蒐集及分析的方式，對有界限的系統，如個人、團體、事件、機構等作深入詳實的描述、詮釋與分析[7]。個案研究法的目標，乃在於了解接受研究的單位，重複發生的生活事象（life cycle），或該事象的重要部分，進行深入探究與分析，以解釋現狀，或描述探索足以影響變遷及成長諸因素的互動情形，因此，個案研究應屬於縱貫式的研究途徑，揭示某期間的發展現象[7]。個案研究的特徵，包括：(1).注重個體的研究。(2).以多元方法蒐集個案資料。 (3).對個案進行深入分析研究。(4).研究問題不只限於異常行為。個案研究的目的，則為(1).找出問題的原因。(2).提出解決問題的方法。(3).提供預防措施。(4). 協助個案潛能充分發展。(5).提升組織機構的績效[7]。個案研究的類型，已逐漸形成二種類型：(1).以量化研究為導向，而發展形成「個案實驗法」。(2).以「質」的分析為典範，運用深度詮釋方法或參與觀察。 24.

(34) S. B. Merriam 則將個案研究的類型分類為三種類型[7]： (1) 描述性(descriptive)個案研究：主要在描述研究對象，常用在創新和獨特的情境，因此，詳盡地描述可提供資料做為未來研究比較、假設及建立理論的基礎。 (2) 解釋性(interpretive)個案研究：又稱為分析性的研究，歸納資料去分析、解釋和發展理論。 (3) 評鑑性(evaluative)個案研究：包含描述、解釋和評價，評價是最後一個階段，因此前述的步驟也都包含在內。. 個案研究法的特色︰(1).只研究少數學習個體，甚至只以一個個體為研究對象。(2).是一種細膩且全人觀察的研究法。(3).在學習者的學習環境觀察，而非隔離式的實驗室研究，所以可稱為自然式的研究法。(4).屬於縱向而且深入的研究，因為費時，而且收集的資料不侷限於學習者的學習成果。(5).沒有預設立場，在研究過程中，不斷修改提出的問題或假設。(6).研究報告，主要是描述性的，除了描繪研究對象的學習現象，並對於學習環境及文化背景做詮釋，所以整個研究報告，讀起來猶如一篇故事[7]。個案研究的研究步驟：(1).研究者根據自己的經驗或某個理論，提出問題(假設)。(2).定義研究範圍(bounded system，又稱 boundaries)，可能範圍包括個體的背景及觀念、學習經驗、行為模式、學習環境、個體與學習環境的互動等等。(3). 設計研究計畫，列出指標，以便從事研究活動。(4).收集研究範圍的相關資料。 (5).修正假設，有必要的話，重複步驟 2-4。(6).分析資料[7]。個案研究的資料收集法，可採取誘導式技巧(elitation techniques)︰亦即資料來源，是經由研究者誘導而收集到的。方法有(1).訪談（interviewing），先設計好問卷，再根據研究專題的性質，決定要採取高度結構化的晤談，或是半結構、無結構式的晤談。所謂高度結構化的訪談法，即訪談前，要設計好訪談指標，在晤談的過程中，嚴謹地遵守訪談指標，例如，明確建議如何做開場白，如何結束晤 25.

(35) 談，問問題時該怎麼問等等。收集訪談資料時，切記和受訪者建立互信及良好的互動，並敏銳地針對重要議題做進一步的探索。(2).反省或思考報告（verbal reports)--請研究對象做學習反應、反省方面的報告，或者請他及時敘述學習過程中的思考活動（think aloudmethods）[7]。. 3.2 問題探討複雜的資訊科技(IT)管理一向就是中大型企業 IT 人員最頭痛的問題。而隨著企業應用和設備環境愈趨複雜，掌控愈來愈困難，加上 IT 支出減少對軟硬體採購造成限制，於是包含軟體資產、網路及硬體設備、甚至是 IT 服務流程的 IT 管理議題，便日漸受到重視。隨著企業對資訊科技的依存度日益升高，IT 無疑已成為許多商業流程不可或缺的部分，甚至是某些商業流程賴以運作的基礎。這種對 IT 角色的重視意味著 IT 要承擔更大的責任─提高商業的運作效率，同時降低業務流程的運作成本。但在現實環境卻是大部分的 IT 服務在這兩個要求上都不盡理想，探究其因不外是 IT 部門往往從技術層面而非商業角度來考量問題，或是在發現問題時缺乏適當的方法和工具。根據調查，現今資訊部門主管面臨的挑戰，不外乎時時更新的軟硬體產品、永不滿足的用戶、IT 投資與業務需求始終難以平衡、決定何時採用創新技術總是難以抉擇、如何提升管理效率、不夠安全的資訊安全、錢到用時方恨少的 IT 預算、如何提升員工的 IT 水準，以及增強與合作夥伴的資訊共用等。然而，儘管這些問題一直存在，資訊部門主管們，卻始終找不到方法解決上述挑戰。歸咎原因，正是因為企業缺乏統一而有效的 IT 管理，也才一直擺脫不了上述難題。. 26.

(36) 第四章資訊科技服務管理之分析與設計 4.1 資訊循環內部控制制度之設計本研究所設計之資訊循環內部控制制度，共分為十項控制作業，包括：1. 資訊處理部門之功能及職責劃分。2.系統開發及程式修改之控制。3.編製系統文書之控制。4.程式及資料之存取控制。5.資料輸出入之控制。6.資料處理之控制。 7.檔案及設備之安全控制。8.硬體及系統軟體之購置、使用及維護之控制。9.系統復原計畫制度及測試程序之控制。10.資通安全檢查之控制。這些資訊循環內部控制制度之作業程序，茲分別說明於下述章節。. 4.1.1 資訊處理部門之功能及職責劃分 1.為因應業務發展實際需要，建立辦公室自動化電腦系統，並將「企業管理」與「電腦應用」相結合，以規劃整體性之管理資訊系統。 2.確定軟、硬體規劃標準政策，以確保公司之短、中、長期發展及電子資料處理之一致性。 3.系統管理人員除依使用單位提出之需求作應用系統開發、維護工作外，應規劃評估新的電腦技術和應用以提昇資訊系統之效率。 4.配合公司年度預算作業，對公司整體電腦化規劃，列入年度預算中。 5.資訊部門之功能及職責劃分說明如下： 5.1 資訊單位主管 5.1.1 負責發展電腦作業之長短程計劃及審核推行系統。 5.1.2 向決策階層提供作業自動化的議案。 5.1.3 根據公司的作業目標與方針，規劃其業務及控制預算。 5.1.4 規劃及管理電子資料處理(EDP)之有關業務。 5.1.5 檢討與評核各項作業之進度與效果。 27.

(37) 5.2 網管工程師 5.2.1 電腦網路安全控制與管理。 5.2.2 相關作業系統、OA 應用系統、資料檔案管理與維護。 5.2.3 硬體設備之維護保養。 5.2.4 使用單位之問題排除及軟硬體技術支援。 5.2.5 相關電腦資源之維護管理。 5.3 系統工程師 5.3.1 應用系統程式之開發、管理與維護。 5.3.2 系統文件、操作手冊之編製、管理與維護。 5.3.3 使用單位之系統相關問題排除及軟硬體技術支援。. 4.1.2 系統開發及程式修改之控制 1.系統開發可行性評估： 1.1 由申請部門依業務需求，使用資訊支援申請單提出新系統支援作業，經資訊部門主管初步分析系統開發之可行性，並視需要知會有關部門開會討論後呈核，若不可行時，應註明意見銷案後，交由申請部門存查。 1.2 判定可行時，應指派適任之專案負責人員與相關部門人員討論作業現況、新系統需求及收集相關資料，並委由專案負責人追蹤作業進度。 1.3 若經評估決定對外購買套裝軟體或外包開發新系統時，應會同相關部門遴選軟體廠商，並經開會討論適當之軟體廠商呈准後，依系統購置與測試驗收作業有關規定執行請購、測試及驗收作業。 2.系統分析、設計： 2.1 應設置獨立之系統發展及測試環境或配合支援廠商進行測試作業。 2.2 資訊人員依據作業現況、需求及有關資料進行系統分析工作，將分析結果填製系統流程圖，並據以進行資料結構分析事宜，就資料處理過程中輸出. 28.

(38) 入之資料設計最適合之資料格式。 2.3 檔案若有新增或變更時，應於系統說明文件中記錄更動日期及使用人員，確保資料完整，有軌跡可查。資訊人員於完成處理設計工作後，應彙集系統開發過程中編製之有關資料，覆核是否有疏漏、不明確之處，經覆核無誤後，據以進行程式撰寫工作。 3.系統測試： 3.1 系統完成後，就個別程式進行測試工作，將測試結果留下記錄；當測試結果顯示有問題存在時，資訊部門應著手偵錯工作，並予以更正。 3.2 資訊部門依排定時程會同使用人員進行測試，經反覆測試、修改無誤後，將測試報告交使用部門驗收確認並送呈部門主管簽核。 4 程式修改： 4.1 使用者因系統功能不符需求或須新增功能時，使用部門應填妥“資訊支援申請單＂經核決權限主管簽准後，送交資訊部門主管評估並指定程式修改人員。 4.2 程式修改完成時，應會同使用部門共同進行線上測試，測試無誤後填具「系統與程式測試狀況表」及相關文件、報表經使用者簽名後經資訊主管簽核，送呈權責主管覆核後上線。 5.經評估無法由資訊部門自行開發，或修改時或委外較有效益時，由資訊部門主管提出申請，經權責主管核准後，委外開發或修改。. 4.1.3 編製系統文書之控制 1.資訊單位所有文書或檔案應指派專人保管存檔。 2.所有系統文書之保管人於離職前，應依公司人事管理辦法完成離職手續後，方可離職。 3.資訊單位於處理作業變更時，應對相關業務人員詳加解說。相關之操作文書或. 29.

(39) 手冊應隨即印製抽換，並於文書或手冊內頁註明更換記錄及日期。. 4.1.4 程式及資料之存取控制 1.各部門權限異動由各使用者填具“支援申請單＂經主管審核後，向資訊單位提出經核准後設定執行。 2.新進員工如需使用資料設備時，由部門主管代為申請，並標示使用權限。 3.非資訊人員禁止擅自利用資訊單位之系統設備。 4.資訊單位應依照系統的需求賦予每一使用者一個使用密碼。 5.人員離職時資訊單位應將所有權限移除。. 4.1.5 資料輸出入之控制 1.資料輸入之控制 1.1 使用者輸入資料發生錯誤如須請資訊部門協助更正時，須填寫“資訊支援申請單＂經部門主管核准，由系統管理員執行修改後送交資訊部門主管覆核，並由使用者驗收。 1.2 已登錄資料之修改或輸入錯誤之更正應經適當核准、即時追蹤解決，並再經核准。 1.3 資訊管理系統應建立適當之自動檢測控制，以避免人為輸入資料之錯誤。 2.資料輸出之控制 2.1 資訊管理人員應對系統應產生之資料檔案結轉之異常及例外報表定期追蹤並報告主管覆核。 2.2 重要或敏感性之報表列印應有適當之權限設定，輸出資料應先確認處理項目、部門無誤後再行分送，若分送資料為報表或媒體時，應經權責主管核准後，方可分送相關部門。 2.3 原始單據與審計軌跡報告應適當核對、覆核及保存並符合主管機關規定。 30.

(40) 4.1.6 資料處理之控制 1.各項電腦操作程序皆依操作手冊執行。 2.各項系統維護由資訊管理人員專人維護。 3.資料鍵入後或結轉後，應定期作資料備份處理。 4.資料處理執行時，因做一般檢核控制，以避免人為錯誤。 5.資料處理過程中，因錯誤或不可抗拒之因素導致需重新處理時，應即時復原，以確保資料處理之正確性。. 4.1.7 檔案及設備之安全控制 1.電腦機房應有適當的消防設備以免造成損害並應保持適當的溫度及濕度控制。 2.機房應配置電力設備如不斷電系統以確保電路穩定及供作緊急之用。 3.機房應記錄機器運轉狀況，對機器停止原因、修理次數、更換零件均應詳細記錄以利追蹤。 4.應嚴格限制員工使用非法軟體，以降低病毒侵入破壞系，或因侵權而造成公司損失。 5.PC、SERVER、NOTEBOOK 皆應有防毒軟體以免檔案遭受損害。 6.除資訊作業人員外，未經資訊主管之同意，不得進入電腦機房；若外來維修人員得由資訊人員陪同進入。 7.機房內器材物品，非經資訊主管同意不得攜出，非屬機房內之器材，不得攜入機房。 8.機房內嚴禁吸煙、飲食、喧嘩、放置什物或私人物品，並應定時維護、保持整潔。 9.總務相關單位若事前接獲電力公司通知停電，或因廠內電力設備維修需中斷正常電源之供應時，應於事前通知資訊單位，以便資訊單位安排相關事宜。 31.

(41) 4.1.8 硬體及系統軟體之購置、使用及維護之控制 1.硬體之購置，由使用單位提出硬體採購需求，資訊單位評估及硬體購置，並作好硬體設備之使用及維護。 2.系統軟體之請購，由資訊單位應考量現有主機設備，及其系統操作方式，選擇成本效益符合公司需求之系統軟體，以發揮主設備最大功能。 3.電腦硬體設備，統一由資訊管理人員維護，如需外部廠商維修者，由使用單位填寫『固定資產異動單』並會簽資訊管理單位，交予管理單位連絡廠商處理。. 4.1.9 系統復原計畫制度及測試程序之控制 1.確保企業資訊系統遭受不可抗力之災害或其他人員破壞時，能再最短時間內復原至正常企業營運。 2.電腦中心應評估重要之電腦作業系統、電腦資源及各類可能之災變，並由使用者部門評估可能之影響及人工作業替代程序，共同訂定「系統緊急復原計劃」。 3.使用部門因系統遭受不可抗力之災害事故、檔案毀損或機器故障時，應立即呈報部門主管，並通知電腦中心處理。 4.電腦中心於事故發生時應立即呈報管理階層，並分析檔案及資料受損情形及對企業營運之影響，按其重要性排定資訊管理系統復原順序及規劃應執行之資料復原程序與資料處理範圍，處理之情形及方式應提報書面文件予管理階層。. 4.1.10 資通安全檢查之控制 1.資料經由電子郵件傳送或接收時，應於電腦系統設置防火牆及防毒軟體，以防止駭客或電腦病毒之侵害。 2.員工應避免透過公司網路收發或下載與業務無關之郵件或軟體，以避免佔用公司之網路資源，及增加電腦病毒感染機會。 32.

(42) 3.公司員工非經權責主管授權，禁止將公司相關資訊經由電子郵件對外傳送。 4.重要之軟體及檔案應予加密處理，並定期更新密碼，以避免遭挪用或剽竊。. 4.2 資訊系統控制機制之設計資訊系統經過了數十年來的進展，已經由整合企業的各個功能，到整合相關組織間的運作。為了生存與競爭，電子商務整合企業資源規劃的資訊架構，已成為企業資訊系統開發的新趨勢，所以資訊系統就是支援企業組織整體活動之整合性資訊系統。資訊系統已變為企業作業流程與營運管理的核心，其已經與企業的脈動結合在一起。企業活動主要是為達成組織所定之各種目標，為了達成目標就必須要有各類之內部控制機制；而資訊系統既已成為企業營運活動的核心，取代原本大部份人工的作業與管理活動；因此，為了達成組織之目標，也就必須將原本人工的作業與管理控制機制導入到資訊系統裡，以維護企業營運之正常，並確保企業活動過程中所需資訊之品質。企業組織有營運效益及效率、財務報導、遵行法規與保護資產等四項目標，為了達成這些目標，就必須在資訊系統裡建置有關的內部控制機制，以便在企業營運活動的過程中，各階層的人員能取得為達成目標所需控制之資訊。表 3 即在說明各種企業目標可能需要導入資訊系統之控制機制。為了達成「營運效益及效率」之企業目標，資訊系統應導入營運與安全控制；為了達成「財務報導可靠性」之企業目標，資訊系統應導入應用、交易與安全控制；為了達成「遵行法令」之企業目標，資訊系統應導入應用、交易與安全控制；而為了達成「保護資產安全」之企業目標，資訊系統應導入營運、應用、交易與安全控制。企業組織之資訊系統應導入何種控制機制，完全視組織為資訊系統所定的目標及. 33.

(43) 其資訊技術應用的層次來決定。資訊系統的目標與資訊技術應用的層次之間有很密切的關係，當一個企業組織使用了高資訊技術應用，則其資訊系統必也肩負更多目標與使命。. 表 3 資訊系統控制機制企業目標. 資訊系統控制機制. 營運效益及效率. 營運控制、安全控制. 財務報導可靠性. 應用控制、交易控制、安全控制. 遵行法令. 應用控制、交易控制、安全控制. 保護資產安全. 營運控制、應用控制、交易控制、安全控制. 網路化資訊系統是未來的發展趨勢，由於其支援大部份組織之營運與管理活動，所以其內部控制機制必須要能涵蓋整個資訊系統的安全與其所支援之組織運作。據此，本研究提出網路化資訊系統內部控制架構，其控制機制涵括安全控制 (Security Controls)、應用控制(Application Controls)、營運控制(Operation Controls) 與交易控制(Transaction Controls)等四個構面。在此內部控制架構下，資訊系統始能全面協助達成組織運作之目標，並確保其產出資訊之品質。 (1) 安全控制：是指為維護資訊系統運作安全所施行的資訊系統控制機制，此與 AICPA 之審計準則第三號公報之一般控制有所差別，一般控制是指資訊環境的安全控制，而本文之安全控制係指可以導入資訊系統本身之安全控制措施。資訊系統有交易身份認證、非法使用者侵入、合法使用者非法使用其它未被授權之功能、合法使用者在授權的範圍內從事非法之工作及資訊傳輸時遭到竊取與篡改等之安全問題。不同的安全問題需要有不同的安全控制機制。 (2) 應用控制：是指將交易活動之規則與資料處理流程之控制導入應用軟體之控. 34.

(44) 制機制，其應包含輸入控制、處理控制與輸出控制等三項，其內容與 AICPA 第三號公報之應用控制大同小異；但本研究所指的應用控制祇限於程式之自動化控制，而 AICPA 之應用控制則除了程式控制外，亦包含其它方式之人工輔助控制。 (3) 營運控制：在於控制組織營運活動之效益與效率，其係依據管理階層所欲達成之目標，實行營運相關的控制措施，以確保企業營運之效益及效率。 (4) 交易控制：是為了強化在資訊化環境下交易作業之內部控制。由於企業流程改造之施行與資訊科技之導入，而使得原本交易活動的職能分工(Job of Segregation)架構被破壞殆盡。不但交易活動不相容的職能單元被合併，而且交易活動的許多職能單元也由資訊系統來執行。因此，必須利用職能分工的原理來重新設計交易作業之控制機制，然後將其導入到支援交易活動的資訊系統裡，以防止舞弊與錯誤之發生。. 4.3 組態管理之設計許多人都應該有雷同的經驗，如果組織內部的資訊系統發生了問題。一般只要請組織內有經驗的 IT 人員或工程師協助，大部分的問題都可在最短的時間迎刃而解。這些有經驗的 IT 人員及工程師可能都具備下列的特質: 熟悉使用者所使用的服務、工作性質及其使用之系統的特性。但組織如果發生了業務持續的擴增，IT 人員/ 工程師的異動、系統的複雜度或數量逐漸的增加等議題，此種服務模式的有效性就可能會遭遇到挑戰(如問題處理之即時性、新 IT 人員不熟悉系統等)。實務上來說導入 IT 服務的組織都會建立一個統一問題的處理窗口，如：服務台(Service Desk)。服務台所扮演的角色與大家平常較常接觸到的”客服中心”、”Help Desk”或”Hotline”等雷同。如果服務台的機制運作得當的話，大部分. 35.