陳 暉 (1969-):女,湖南人,碩士,研究方向為管理信息系統、智能控制、最優控制等
摘要:基于ITIL的IT服務管理在IT基礎設施和ERP應用系統的實踐是有所區別的。本文就業務運作對ERP系統的要求,結合ITIL在跨國性公司中的應用實踐,在服務支持部分分析了IT服務管理在ERP系統中的應用特點,并提出了相應的解決方案。
關鍵詞:ITIL;IT服務管理;服務支持;事故管理;變更和發布管理;ERP應用系統
Abstract: The ITIL based IT service management has different practices in IT Infrastructure support and ERP application support. This paper analyzes the characteristics of IT service management in ERP system based on the business requirement of ERP system and the practices in international companies, the related solutions are provided as well. The scope is limited in service support only.
Key words: ITIL;IT service management;service support;incident management;change management;release management;ERP application system
1 基于ITIL的IT服務管理簡述
二十世紀八十年代末形成的IT Infrastructure Library (信息技術基礎架構庫, 簡稱ITIL )已經在全世界成為事實上的IT服務管理的最佳實踐和標準。它是一套針對各行業的IT系統服務管理標準庫,提供了一種流程處理的IT運營方案?;贗TIL的IT服務管理以流程為導向、以客戶服務為中心,它通過整合IT服務與公司業務流程,提升了企業IT運營效率和客戶對IT部門服務的滿意度。
基于ITIL的IT服務管理(IT Service Management ,簡稱ITSM)作為一種新的IT管理模式, 在歐洲和北美等國家和地區得到了廣泛的應用,近年來在我國也得到了越來越多的關注和應用。
提到基于ITIL的IT服務管理,人們更多地把它和IT 服務臺(Service Desk)或IT呼叫中心聯系在一起,通過IT服務臺向用戶提供IT基礎設施的服務,例如PC 維護、網絡、通訊、服務器、操作系統等方面的IT 服務。
事實上,基于ITIL 的IT服務管理在大型企業的ERP系統中也得到了廣泛的應用,但在不少企業,甚至包括一些大型跨國性企業,由于IT服務管理的實施往往先從IT基礎設施著手,然后再推廣到ERP應用系統中去,使得IT服務管理流程帶上了基礎設施的烙印,或多或少地忽略了ERP系統的特點,從而對ERP系統的IT服務支持的效率產生影響,降低了用戶滿意度。
ITIL服務管理主要由服務支持(Service Support)和服務交付(Service Delivery)組成,這兩者是整個ITIL框架的核心。ITIL服務支持主要論述客戶和用戶如何獲得恰當的服務來支持他們的活動和業務,以及這些服務怎樣得到支持。它主要由下列模塊組成:服務臺(Service Desk),事故管理(Incident Management),問題管理(Problem Management),配置管理(Configuration Management),變更管理(Change Management)和發布管理(Release Management)。
本文針對ERP應用系統的特點和相關業務對ERP系統要求的特殊性,根據大型跨國公司ERP服務部門的IT服務管理的經驗和實踐,就服務支持部分談談IT服務管理在ERP系統中的應用特點。
為敘述方便,文中將用到如下ITIL和業界通用術語:
(1) 一般用戶(End User):運用ERP系統進行業務操作的普通業務用戶。
(2) 關鍵用戶(Key User):對所分擔的業務有較深的專業知識和業務能力的用戶。這類用戶對ERP操作比較嫻熟,既能解決和業務相關的問題,也能在授權范圍內解決一般用戶碰到的ERP應用問題,故而在一定程度上減輕了IT部門的支持工作。
(3)事故單(Incident Ticket): 由關鍵用戶通過IT服務管理系統提出的事故解決請求記錄。
2 IT服務臺和事故管理在ERP系統中的應用特點
ERP系統從廣義上來說,它涵蓋了一個企業的整個運作周期,包括產品或服務需求預測、供應計劃、采購、生產、成品管理、銷售、物流、財務、庫存管理、倉儲管理、業務數據分析和決策支持、客戶關系管理、供應商關系管理、人力資源管理等業務領域。復雜而多變的業務運作,大量的來自各業務部門的ERP用戶,復雜而全面的ERP應用系統,決定了ERP系統的IT服務管理在流程上具有區別于基礎設施IT服務管理的特點,具體體現在IT服務臺和事故管理中的特點有:
(1)事故或問題的緊迫性和影響度需要IT支持部門作出快速反應。ERP系統中產生的事故或問題的緊迫性及影響度基本上是由相關業務的緊迫性和重要性決定的。有些事故或問題會直接影響業務運作,或影響公司的對外服務水平,或有法律上的風險。例如,對客戶承諾的送貨時間,價格主數據有誤,ERP系統宕機等等,這些事故或問題需要IT支持部門馬上做出支持,以便最大限度地降低對業務運作的影響。
(2)ERP系統事故或問題的解決需要和業務人員密切互動。ERP系統的IT服務支持和具體的業務流程及業務人員密切相關,同樣的業務流程可以產生不同的問題,ERP IT支持人員需要和提交事故/問題的用戶保持較多的溝通以便明確事故和問題所在,測試和確認解決方案。
ERP系統IT服務管理的這些特點決定了不能簡單照搬基于基礎設施的IT服務流程和方案,必須基于這些特點對IT服務流程進行相應的調整和完善。需要完善的地方是:
(1)對事故的第一反應必須快速有效,尤其是一些對業務運作產生大的影響的事故。有些事故也許只影響一個用戶的系統操作,但所影響的業務可能是重要和緊急的。
(2)在第一時間和用戶(即事故的提出者)溝通的支持人員必須具有ERP某個功能模塊的系統經驗和業務知識,所以必須減少從用戶到相關ERP支持人員的中間環節。
在一般的IT服務管理流程中,服務臺和事故管理是IT服務管理中最廣泛運用的一個功能。服務臺是直接面對用戶的單一聯系點,所有IT相關的服務請求均通過服務臺進行記錄、處理、回復或轉發到相關的二線IT支持部門進行處理。
但在ERP系統支持方面,這樣的傳統架構和流程卻往往會導致服務響應和解決的延遲,從而可能導致業務流程的延遲或中斷,對業務產生負面影響。
其原因正是由ERP應用系統的特點引起的。一般來說在服務臺工作的IT支持人員更多的偏向于IT基礎設施方面的支持,他們往往能對PC,Windows Office應用軟件,辦公設施等進行有效的支持,但對ERP系統一般缺乏了解,只能做很簡單的處理,例如重置用戶密碼等,對涉及業務流程的問題一般無法處理,更談不上進行有效的支持了。這是由ERP系統的復雜性決定的,無法要求在服務臺的一線支持人員是萬能的,實際上也不可能做到。他們所能做的只是:①根據用戶的電話述說或電子郵件在IT服務系統中開出事故單(Incident Ticket)。②根據記錄來判斷問題是否屬于ERP系統。③轉發事故單到ERP二線支持部門。
而在事實上,由于大型主流ERP系統涵蓋了整個公司所有或大部分的業務運作,所以二線ERP系統的支持部門一般也按業務分成多個功能支持組,譬如財務組,銷售分銷組等,要服務臺的支持人員準確地了解并把用戶的需求或問題轉發到具體的ERP功能支持組是有一定困難的。所以在現實中有些以這種IT服務流程模式運作的公司不得不在ERP二線支持中再設一個ERP服務臺,這個ERP服務臺對ERP各個模塊有一般的了解,其責任是:①解決一些常見的簡單的ERP事故,②準確地把和ERP相關的事故轉發到相關的功能支持組去。這套流程如圖1所示。
圖1一般IT服務管理在ERP事故處理中的流程
這種運作模式帶來兩個弊端:①延長了事故的第一響應時間和解決時間,從而影響服務級別協議(Service Level Alignment,簡稱SLA)。②導致機構設置的重復,服務臺和二線ERP服務臺的職能從ERP應用系統的角度來說是重疊的。
為消除這兩個弊端,提高IT服務的運作效率,提高客戶滿意度,在不少大型公司中,往往對ERP支持的流程做出一些改進,一般有兩種改進方法:
方法1:把二線ERP服務臺和二線ERP功能支持組合二為一,同時設立關鍵用戶,普通用戶向關鍵用戶聯系解決ERP事故,關鍵用戶解決不了的則直接在IT服務管理系統中登記一個事故單,并把它指派給二線ERP功能支持組去解決。當然普通用戶依然直接聯系服務臺解決非ERP相關的事故。其流程參見圖2(方法1)。
方法2:另一種方法是成立ERP服務臺,并同樣設立關鍵用戶。其流程是從普通用戶到關鍵用戶,再到ERP服務臺,然后到ERP功能模塊支持組。其大致流程見圖2(方法2)。
圖2 完善后的IT服務管理在ERP事故處理中的流程
這兩種方法的共同點是由關鍵用戶判斷所發生的事故是否屬于ERP范疇,這一點對關鍵用戶來說是比較容易判斷的,即便偶爾有誤判,ERP支持人員也可以幫助分發到相關部門或請關鍵用戶聯系IT服務臺去分發。
要注意的是關鍵用戶除緊急狀況外均不得直接聯系ERP功能模塊支持組的某個成員,而應該在IT服務管理系統中登記一個事故單,然后把它指派給某個ERP功能支持組(方法1),或指派給ERP服務臺(方法2)。
相對而言,筆者更贊同方法1,因為它更高效。
3 配置管理在ERP系統中的應用特點
配置管理是實施基于ITIL的服務管理的一大難點。在配置管理中,最基本的信息單元是配置項(Configuration Items,簡稱CI),所有軟件、硬件和各種文檔,比如變更請求、服務、服務器、環境、設備、網絡設施、臺式機、移動設備、應用系統、協議、電信服務等都可以被稱為配置項。這些信息不僅包括基礎設施中某個特定的配置項的詳細資料,還包括這些配置項與其他配置項之間的相互關系方面的信息。配置管理是進行有效的事故管理、問題管理、變更管理和發布管理的基礎。
在基礎設施相關的配置管理中,搜集所有硬件(包括數量,位置及購買價格等)及相互關系方面的信息是一個浩大的工作。所以在實踐中,基礎設施的配置管理是不盡如人意的。
而對于ERP系統來說,配置管理就相對容易得多。ERP系統是一個大型計算機軟件應用系統,例如SAP系統或Oracle系統,與之相關的服務器、操作系統和網絡等一般歸入基礎設施方面,因此ERP系統是一個“虛擬”系統,只需考慮它的業務功能模塊即可,下面是一個例子。
在該例中,ERP系統分為銷售與分銷(SD)、物料管理(MM)、 生產(PP)、 財務(FICO)、 計劃(APO)、客戶關系管理(CRM)、供應商關系管理(SRM)、人力資源管理(HR)、業務數據分析和決策支持(BW)等業務模塊。在每個模塊下,又可以分為若干子模塊。以業務運作在各公司大致相似的財務模塊為例,它又可分為總賬(GL)、應付帳(AP)、應收帳(AR)、 固定資產(AM)、 資金管理(Treasury)、成本中心(Cost Center)、利潤中心(Profit center)、接口(Interface)等等, 可以把配置項定義到子模塊這個層次上, 其子模塊和模塊間的關系如圖3所示。
圖3 ERP系統配置項與功能模塊及子模塊的關系
這樣ERP-FICO-GL、ERP-FICO-AR、ERP-FICO-AM……等等便是一個配置項。
另外,作為跨國公司,ERP支持一般按美洲(AM),歐洲(EU)和亞太(AP)三大地區來運作,構成5*24小時甚至7*24小時服務。因此為了區分問題發生在哪個地區,可以在配置項中加上地區,比如AP-ERP-FICO-GL、 EU-ERP-FICO-AR等。
在對一個事故或問題匹配配置項時,很容易通過事故或問題發生在哪個子模塊和哪個地區而快速找到配置項,從而為事故或問題的分析和報告以及系統的完善提供依據。
4 變更管理和發布管理在ERP系統中的應用特點
在大型ERP系統中,一般每隔一定周期要對ERP系統作一次系統發布,系統發布的目的是:①解決ERP運行中發現的問題;②根據業務需求增加新的功能或對已有的功能進行完善,包括在某個國家或地區實施ERP系統。這些變更是定期發布而不是隨時發布的,比如每月一次,否則會影響ERP系統的穩定運行,從而影響業務的運作。當然,為緊急事故或問題開發的變更,則需通過緊急變更和發布流程進行管理。但即便是緊急變更,也需要經過類似但快速的流程。
在IT服務管理實踐中,變更管理往往和發布管理融合在一起,對ERP系統管理來說同樣如此。一般大型跨國公司的ERP系統是一個復雜龐大、彼此緊密聯系并相互作用的系統,某一功能模塊的改變可能影響其它模塊的正常運作,或者某一國家要求的特殊功能變更和完善可能對另一國家的業務帶來負面影響。
因此在ERP變更和發布管理中,需要做徹底的測試,以保證:①所開發的變更符合業務需求或解決存在的問題;②對其它模塊功能不會產生負面影響;③其它國家或地區能正常使用同一功能模塊,也即該變更對不需要此變更的組織來說是透明的。在測試中若這三項要求中的任何一項產生事故,并且不能在計劃的發布窗口前解決事故,則該變更不能發布,需要重新完善。
由于ERP系統和業務的緊密結合,ERP的變更管理和發布管理需要業務部門的深度介入,例如需要業務部門在提出業務需求,測試解決方案,用戶培訓等環節發揮重要作用。而不象在基礎設施中那樣大多由IT部門獨立完成變更。 同時任何的變更在發布前,新開發或完善的功能需要由IT變更實施者對ERP IT支持人員進行技術和操作方面的知識交接,對業務部門的用戶進行操作方面的培訓。
這里只討論變更和發布管理在ERP系統中的應用特點,所以許多與基礎設施的變更管理類似的環節,例如變更的登記、評審、確定優先級、發布政策和計劃等等,在此不作論及。
一般ERP的變更發布流程根據測試變更的主體的不同有兩種:
方法1:由ERP IT支持人員和關鍵用戶先后測試ERP系統,并最終由關鍵用戶確認:①新的變更是否符合業務需求,②變更是否給系統本模塊功能或其它模塊功能帶來問題。該方法的主要流程如圖4所示。
圖4 變更發布流程—由關鍵用戶最終測試和確認變更
方法2 :由ERP IT支持人員測試ERP系統,并最終由ERP IT支持人員確認,主要流程見圖5。
圖5 變更發布流程—由ERP 支持人員最終測試和確認變更
最終負責確認變更通過測試與否的部門(如方法1中的關鍵用戶和方法2中的ERP IT支持人員)所作的測試內容應包括:①對變更本身的單位測試(Unit Test),這主要由提出此變更的所在國家或地區的業務部門去測試;②對重要業務流程的測試 - 稱之為回歸測試(Regression Test)?;貧w測試是一種基于重要流程的測試,它需要由所有用到該流程的國家或地區去測試。任何一個國家或地區在回歸測試中發現的問題,必須在發布前得到解決,否則某個相關的變更必須推遲發布。回歸測試的方法是對一個完整的業務流程作一個全面的測試,而不論變更中有沒有涉及到該業務流程,確保任何的變更不會對其他重要的流程產生影響。
需要指出的是,在開發部門做變更開發的環節中,單位測試環節不僅包括了IT開發人員作面向系統的單位測試,也包括了參與開發的業務人員做的面向業務的用戶接受測試(User Acceptance Test, 簡稱UAT),只是在這個環節作測試的往往不是關鍵用戶,而是和IT搭檔的業務專家(Business Expert)。所以無論方法1或方法2,均有業務人員參與測試。
不同的測試方法適用于不同的行業,方法1一般用在高度依賴ERP系統的行業,例如快銷品行業,這種行業的運作對時效性要求極高,無時無刻不用到ERP系統,尤其是銷售、物流和倉儲等和客戶服務相關的環節,必須時刻保證ERP系統的穩定性和可用性。當然代價是成本比較高。
實際上,在對ERP依賴度比較大并且IT管理比較嚴謹的公司,在變更發布完成后投入正常操作前,還需要在生產環境中作兩個測試:①ERP IT支持人員對發布后的ERP系統檢查重要的系統配置和與其它系統的接口,可能的話需要做一些對業務沒有影響的操作;②關鍵用戶需要對一些重要的流程作一遍實際操作,故需要保留一些真實的業務數據供這時使用。作這兩個測試目的是確保變更后的ERP系統能在投入使用后正常運作,避免事故或使事故的發生率和對業務的影響最小化。
方法2則適用于對業務運作的時效性要求較低的行業,其業務對時間的冗余度相對大一些,一般情況下容許ERP支持人員花費相對多一點的時間解決事故/問題。
5 問題管理在ERP系統中的應用
問題是指一個或一類事故重復發生時所對應的根本原因。問題管理的目標是消除事故背后的根本原因,從而使同類事故不再發生。
從ERP系統來說,問題的根本原因可能是:①應用程序的邏輯錯誤;②應用功能模塊程序沒有考慮到所有或特殊的業務場景;③支持ERP系統的IT基礎設施存在問題。
一般來說,一旦事故被確認為問題,則該事故單可以被關掉,同時在IT服務管理系統中登記相應的問題,并把該問題和事故聯系在一起,從問題管理的流程來說,ERP系統和其它系統是類似的,這里就不再詳述。
6 結束語
本文討論了ITIL的服務支持(Service Support)在ERP系統中服務管理流程的應用特點。這些特點是由業務部門運作對ERP系統的要求決定的。在ERP領域實施IT服務管理系統和支持流程時,必須考慮到業務運作的特點和對ERP系統的依賴程度,從而制定出適合業務對ERP系統需求的支持流程,尤其在事故管理、變更發布環節。
參考文獻
[1] Berkhout M, Harrow R, Johnson B, etc. Best Practice for Service Support[M]. London: The Stationery Office Limited, 2000.
[2] Bartlett J, Hinley D, Johnson B, etc. Best Practice for Service Delivery[M]. London: The Stationery Office
Limited, 2000.
[3] Jan van Bon主編,章斌翻譯. IT服務管理—基于ITIL的全球最佳實踐[M]. 北京: 清華大學出版社,2006.
[4] 左天祖,劉偉. 中國IT服務管理指南[M]. 北京:北京大學出版社, 2004.