• 沒有找到結果。

一種快速應用系統發展模型建立服務目錄的方法

在 ITIL v2 的 Service Delivery 之中有提到,服務目錄應以清單型式列出所有目前已 提供服務之特性及詳細說明給使用者。為完成此一清單,甚至要採取一些必要的偵探/

偵察手法。本研究之目的即是以系統分析之方法論,建立一個產生符合 ITIL 建議及 ISO/IEC 20000 標準規定之服務目錄的建議模型樣版,並提供可擴充之界面,提供各企 業組織可依實際狀況,自行擴充服務目錄之內容。

因服務目錄是以一個資料庫或結構化文件的形態提供給資訊服務提供者和使用者溝 通的介面,本研究以設計一個服務目錄系統的觀念,利用快速應用系統發展(RAD)模型 (如圖 9 所示),提出組織盤點既有資訊服務建立服務目錄之方法步驟,其主要可分為六 大步驟,如下表:

表5. 應用快速應用系統發展(RAD)模型產生服務目錄步驟對照表

項次 步驟 產出

1 範疇界定 服務分類,建立服務樹(service tree) 2 參與者分工 建立資訊服務的 ARCI 矩陣

3 分析服務目錄內容屬性 服務目錄實體關聯圖(E-R-D) 4 服務目錄實作 服務目錄資料庫雛型

5 制訂管理流程 服務目錄管理程序建議書 6 符合性驗證 查核表及實際訪談記錄

3.3.1 範疇界定:服務分類,建立服務樹(Service Tree)

除少數軟體公司或 IT 服務整合公司之外,多數組織與企業的主要營業項目並非 IT 服務項目。資訊部門或服務提供者在組織與企業中的角色可能是其他業務執行部門的策 略夥伴或後勤支援單位。在建立服務目錄的盤點之前,資訊部門應先針對企業之使命、

願景及主要營業活動項目進行暸解,做為盤點服務項目之後的歸類依循。

一般在管理學上將企業之活動及管理範疇主要區分為「產銷人發財」等五項,說明 生產管理、行銷業務管理、人力資源管理、研發管理、財務管理等是企業普遍存在的主 要活動。而企業 e 化(或電腦化、資訊化)都是為了支援或支撐上述活動的進行。

近年來,有學者加上第六項:資訊管理,說明資訊科技與資訊服務對於企業愈來愈 重要。隨著企業成長,引進電腦或資訊化設備協助增進生產力或工作效率也是普遍之趨 勢。過去電腦是高科技產品,是一項專門技術,而鮮少有企業一開始就認定這是一項資 訊服務,在企業內普遍存在的現象是先有資訊設備與系統,才有資訊管理、資訊服務,

最後才會想到是否要導入資訊服務管理系統(ITSM)。

為符合資訊服務於企業內部扮演支援或支撐企業主要活動的角色,在盤點資訊服務 之前,資訊部門應先檢視企業組織之主要商業目標及行為,參考「產銷人發財資」之分 類,並依實際情形依階層加以細分,。建議做法是同一階層不超過 9 大類,至多不超過 四層[SGS, 2008]。分類完畢可以針對類別給予編號,以便節省將來系統化之間。此編號 系統可以視為一個決策樹,在盤點到實際的服務項目內容時,可將服務置放於正確適當 之位置,故又可稱為服務樹。以系統分析之資料庫關聯圖可繪製如下圖 3.1:

27 服務目錄資料表

PK 服務名稱 FK1 業務分類ID

業務分類表 PK 業務分類ID

業務分類別

圖10. 服務目錄資料表與服務樹(業務分類表)之資料庫關聯圖

3.3.2 參與者分工

團隊或組織要建立 ARCI 責任矩陣,基本上有以下 7 步驟可以供參考:

1. 確認關鍵性商業流程、功能、決定或活動,進一步分析這些流程與活動,視 需要再細分成細項工作。

2. 確認須介入的人員、職位或部門。列成ARCI矩陣中的上端水平欄目。

3. 建立中間區的角色與責任草圖。最初只與少數決策者進行,將A、R、C、I 分別排入矩陣之中間部分。

4. 召開ARCI會議,召集所有參與人員說明、溝通並解決矩陣圖中在流程、活動、

人員/職位角色,及ARCI責任分配中的問題與建議,全體成員達成共識。

5. 建檔已成立共識的ARCI矩陣責任圖。並將複本分送所有參與者及支援介面單 位,公告周知,亦可以利協同作業平台方便所有參與者存取。

6. 在後續會議中繼續溝通。強化ARCI責任圖及當責的價值觀。

7. 繼續追蹤,確保ARCI關係的正常運作。鼓勵參與人員遵守該有的角色,如有 需要,則在過程中重審角色與責任,重建責任矩陣圖。

因為在此一步驟需要確認關鍵性商業流程、功能、決定或活動,是屬於企業層級的 觀點,資訊部門雖然提供自動化或資訊化服務,但畢竟不見是該項業務工作流程的主導 者,例如:財務管理之流程與規定,必定是財務會計部門之專業,資訊部門謹守退居支 援者的角色,不宜越權。然而,資訊部門亦有部分主導性的工作,例如電腦環境設定、

電子郵件、網路服務等,應以使用者使用角度來思考,避免陷入技術迷思。

在分工部分,最基本之要求應釐清四個角色,分別為業務負責人、業務聯絡窗口、

IT 服務負責人及 IT 系統聯絡人。關係可以用下表 6 表示。

表6. 服務負責人 ARCI 分工原則

類別 角色 說明

業務面 業務負責人(Process Owner) 負責整理 business process 的成敗 有決定資訊服務系統規格權限 業務聯絡窗口 負責該項 business process 之諮詢窗口 IT 服務面 IT 服務負責人(IT Service Owner) 負責提供支援 business process 之 IT Service

IT 聯絡人 負責 IT Service 之實際維運操作等

隨著資訊科技的發展與分工,一項資訊服務已不再能由單一員工或單一功能部門提

28

供。在資訊部門裡參與提供資訊服務部門的人員可能有 IT 功能部門主管、軟體工程師、

系統工程師、網路管理工程師、客服窗口(Service Desk)等。隨著系統整合度愈來愈高,

針對資料服務應提供之功能內容、發生事故問題之責任歸屬,均要明確之規範,同時一 樣可參考 ARCI 之概念,建立對照表,如下表 7 之範例。

表7. ARCI model

IT 功能部門主管 軟體工程師 系統工程師 網路管理工程師 客服窗口

服務 1 A R1 R2 R3 R4

功能 1 C A,R5 R6 R7 I

功能 2 C R8 A,R9 R10 I

轉換為服務目錄之 ERD 時,責任分工 ARCI 與服務的關係可以以下圖 3.2 表示:

服務目錄資料表 PK 服務名稱

角色表

PK 角色ID

PK 服務ID

PK,FK1 員工編號 角色說明

員工資料表 PK 員工編號

員工姓名 辦公處所 連絡電話 單位部門

圖11. ARCI 分工之資料庫關聯圖,員工資料表可用企業內既有之資料表

3.3.3 分析服務目錄內容屬性

在 ITIL V3 理論中,為方便非資訊技術背景的使用者更了解服務目錄,此服務目錄 又稱為 Business Service Catalogue,應避去資訊專業用語及內容,以商業服務出發,讓 使用者了解他們所能享用的資訊服務範圍及內容。為方便使用者暸解目錄中各項資訊服 務的內容,建議於服務目錄列出下列資訊,輔以說明:

表8. 服務目錄基本欄位及說明

屬性 說明

服務 ID 服務編號,用以識別服務項目 服務分類 依企業活動屬性進行分類

服務名稱 服務或系統名稱

使用對象 服務可能的使用者

服務描述 簡介服務的內容

服務方式 服務的提供方式

服務時間 服務之可用時間,可訂成 7x24, 8x5 等標準化格式,以供選擇 費用 使用該項服務時之可能成本問題。

29

服務目錄(Service Catalogue)是一種資料庫或含有結構化資料的文件,提供所有 IT 服務及服務水準詳細描述,作為溝通使用者期望及 IT 能力的平台。尤其這份資料庫或 結構化文件是屬於 IT 服務部門使用的,結合資訊系統開發之專長項目,應將盤點完成 之資料以系統化之方式存放,供相關人員依需求存取。

一般來說與組態管理資料庫(Configuration Management DataBase, CMDB)整合是常 見之作法,此處之資料庫應是一個概念性的資料庫觀念,並非特定之資料庫產品。近年 來流行 N-tier 的資訊系統架構與網頁介面型式,對於多數的 IT 服務部門而言,這樣的 系統架構再熟悉不過了,因此建議將服務目錄資料存放於 CMDB 的實體資料庫上,再 由網頁程式(Web Applications)來進行資料的呈現、檢索。以保持服務目錄及所需資料的 彈性。

以表 3.5 所列之服務目錄內容格式為例,轉換至關聯式資料庫管理系統(RDBMS),

以可下列資料庫關聯圖圖表示各項欄位資料之關係。

30 服務目錄資料表1

PK 服務ID

PK,FK1 業務別ID 服務名稱 服務狀況之基準線(baseline)。欲導入 ITSM 或進行 ISO/IEC 20000 驗證之單位即以此為 基準進行持續性的服務改善計畫,處理發生的事件、事故、問題等等。

2. 變更(Change process)應依循變更管理的評估、核准、實施、檢視是否成功 等步驟

3. 服務目錄是與使用者息息相關的資訊,凡是Business service catelogue上之欄 位進行變更程序,在完成後即應進行發布程序(Release Prcess),以建立新版 本之基準線。

3.3.6 符合性驗證

3.3.6.1 檢驗服務目錄內容符合原設計規劃

本研究擬以下列三種方式構面,運用查核表及個案訪談的方式,來探討依前述方法 產生之服務目錄內容設計是否符合進行 ITSM 或準備 ISO/IEC 20000 驗證之原始目的:

1. 符合ITIL或ISO/IEC 20000之要求 2. 符合組織內部管理之要求

31

3. 服務目錄建立前後對於資訊部門績效管理上之差異

3.3.6.2 ITIL或ISO/IEC 20000之符合性要求

此部分為必須符合項目,尤其是準備進行 ISO/IEC 20000 驗證的單位或組織。主要 查核項目有下列範例:

表9. 標準符合性查核表

項次 查核項目 符合度 備註說明

1 內容記載全部資訊服務項目

2 可供事故及問題處理記錄分類使用 3 與新服務或變更服務之流程整合 4 可供預算編列及動支管理使用 5 與變更管理及組態管理流程之配合

3.3.6.3組織內部管理需求之符合

不論是 ITSM、ITIL 或是 ISO/IEC 20000 都是外在的範例與要求,組織內部對於資 訊服務的關注焦點才是導入服務管理且持續進行品質改善的核心。對於服務目錄的建立 與使用,IT 服務部門可能因面臨之問題,自行列出各式之問題,以了解目前情形,以便

不論是 ITSM、ITIL 或是 ISO/IEC 20000 都是外在的範例與要求,組織內部對於資 訊服務的關注焦點才是導入服務管理且持續進行品質改善的核心。對於服務目錄的建立 與使用,IT 服務部門可能因面臨之問題,自行列出各式之問題,以了解目前情形,以便