如何利用基于ITIL的幫助臺軟件工具支持企業(yè)快速實施ITIL
事件管理之檢測、自助服務與記錄
聯(lián)合智業(yè)公司 王偉 2007/09/05
關(guān)鍵定義
必須了解請求的概況才能正確地瞄準自助服務解決方案。應該構(gòu)造一個類似如下的矩陣。
表 1 自助服務矩陣
請求類型 | 占總請求量的百分比 | 通過自助方式解決(層級 0) | 通過初始支持解決 | 由二級問題解決小組解決 | 由三級問題解決小組解決 |
密碼重置 | 30% | 0% | 25% | 5% | 0% |
“怎么辦?FAQ” | 18% | 0% | 9% | 8% | 1% |
進度更新 | 17% | 0% | 15% | 2% | 0% |
辦公套件問題 | 13% | 0% | 5% | 5% | 3% |
個人計算機問題 | 12% | 0% | 3% | 7% | 2% |
服務連接問題 | 5% | 0% | 0% | 2% | 3% |
其他 | 5% | 0% | 3% | 1% | 1% |
總計 | 100% | 0% | 60% | 30% | 10% |
從上面顯示的矩陣中可以觀察到,用于密碼重置、FAQ 和進度更新的自助解決方案是值得的投資。這樣允許初始支持資源有更多的時間嘗試解決當前正在傳遞給二級或三級問題解決小組的一些更復雜的事件。在實施和推廣新的自助服務功能之后,更新后的矩陣可能如下所示:
表 2 新的自助服務功能矩陣
請求類型 | 占總請求量的百分比 | 通過自助方式解決(層級 0) | 通過初始支持解決 | 由二級問題解決小組解決 | 由三級問題解決小組解決 |
密碼重置 | 30% | 0% | 2% | 5% | 0% |
“怎么辦?FAQ” | 18% | 10% | 7% | 1% | 0% |
進度更新 | 17% | 15% | 2% | 0% | 0% |
辦公套件問題 | 13% | 0% | 10% | 3% | 0% |
個人計算機問題 | 12% | 0% | 7% | 5% | 0% |
服務連接問題 | 5% | 0% | 1% | 3% | 1% |
其他 | 5% | 0% | 4% | 1% | 0% |
總計 | 100% | 53% | 33% | 13% | 1% |
該矩陣表明自助服務功能現(xiàn)在已經(jīng)從支持團隊那里取走了很大一部分請求。這樣允許每一層將更多的時間集中于以前由于缺乏資源而需要上報的更復雜的事件。注意由初始支持資源所解決的請求百分比降低了;這是因為他們現(xiàn)在處理比簡單的進度更新或密碼重置花更長時間的請求類型。將時間花在更復雜的事件上提高了團隊的工作滿足感,同時還降低了對更高層資源的日常影響。這樣允許團隊將精力集中在更戰(zhàn)略性的問題上。
有些類型的請求不適合自助服務方法。由于其性質(zhì),請求或者需要來自專家支持人員的響應,或者需要進行跟蹤并收集其指標。
高優(yōu)先級事件通常不應該通過自助服務機制進行報告,而是應該直接向服務臺分析員報告。這樣有助于確保正確地對所有高優(yōu)先級事件進行分類,并從事件發(fā)源地收集必要的詳細信息。
由于通過使用自助服務功能收集關(guān)于正在解決的請求的指標更加困難,因此在大多數(shù)情況下,這些指標的內(nèi)容應該針對回答“如何做”類型的請求而不是解決故障。
若要使自助服務解決方案取得成功,它必須易于使用,以便用戶有信心使用它,并相信它會提供一種通過其他途徑聯(lián)系服務臺的替代辦法。
不管客戶如何進入自助服務環(huán)境,他們的進入需要接受驗證并且需要收集相關(guān)指標。這包括進行的查詢的趨勢分析(同時包括成功和失。⑦M行的聯(lián)系的容量、自助服務環(huán)境的性能以及聯(lián)系方法方面的更改。該信息有助于識別服務方面的改進,但是也證明了服務的有效性,并提供關(guān)于投資回報的信息。
要收集的關(guān)鍵數(shù)據(jù)包括:
a)進入方法或模式
b)進入日期和時間
c)用戶身份
d)所提的問題和訪問的功能
取決于環(huán)境,可能需要進行各種授權(quán)檢查以確保請求者有權(quán)訪問功能和數(shù)據(jù)。對于支持許多客戶的外包組織尤其是如此,這些客戶不應該能夠查看彼此的支持請求。授權(quán)檢查可能涉及正確回答一個或多個安全問題(例如密碼或母親的娘家姓)。需要建立用于收集、安全地存儲然后維護該安全驗證信息的過程。
進入自助服務系統(tǒng)的模式確定了對查詢者可用的功能。如天匯幫助臺應提供標準 Web 界面和搜索引擎。
如果進入模式是電話樣式的鍵盤,則需要部署更明確和基于腳本的交互,并且可能需要語音識別技術(shù)。還需要考慮和適應其他進入模式,例如電子郵件,其中預定義的任務表格可能適合用于登記新的服務請求或請求進度更新。這種溝通方法對于提供動態(tài)幫助可能不太成功。
典型的高容量但是相對簡單的請求可能涉及密碼重置。使用基于腳本的自助服務解決方案,服務臺分析員不再需要卷入密碼重置。需要重置其密碼的員工可以訪問某個自助服務功能,回答若干身份驗證問題,并通過一個引導流程繼續(xù)重置他們自己的密碼。在執(zhí)行密碼更改時,向請求者發(fā)送咨詢電子郵件作為安全預防措施始終是明智的。
在天匯幫助臺系統(tǒng)中,通過其自助服務功能模塊進行的新請求可以在服務臺系統(tǒng)中捕獲,并像其他所有請求一樣被分配一個事件編號,以提供審核跟蹤和啟用后續(xù)的進度監(jiān)視。當自助服務允許請求者更改數(shù)據(jù)或密碼時,與服務臺的這種聯(lián)系尤為重要。然后它可以確保自動將自助服務包括在趨勢分析中。該數(shù)據(jù)的明確分析允許改進服務,并使趨勢分析盡可能全面。
可用的信息取決于查詢的樣式。如果查詢基于計算機或基于 Web,則對各種數(shù)據(jù)源的訪問是可能的,其中包括:
a)事件和問題跟蹤
b)轉(zhuǎn)發(fā)變更日程安排
c)供應商支持說明
d)培訓材料
e)軟件更新
f)FAQ 信息
g)服務目錄
h)價格列表
信息的內(nèi)容、準確性和和時間性需要謹慎管理。需要定義并一致同意清楚的角色和職責以確保沒有歧義。通過任何形式的自助服務功能可用的信息需要密切監(jiān)視和審核,以確保符合地區(qū)法規(guī)
— 尤其要注意數(shù)據(jù)保護和保密協(xié)定。
如果用戶選擇使用自助功能,應該為其提供快速查找答案的每個機會,并且盡可能具有最少的混淆。如果用戶發(fā)現(xiàn)該體驗并不愉快,他們今后就可能不會使用它。與其他任何產(chǎn)品一樣,用戶需要“喜歡”它,然后才會“購買”它。
自助系統(tǒng)通常是有用信息和經(jīng)驗的數(shù)據(jù)庫。用戶向該系統(tǒng)提供某個信息,希望能找到與他們的問題“匹配”的信息。該信息可以是錯誤代碼、錯誤消息或任意格式的問題描述。
如果找到匹配的信息,該信息通常以和最初的查詢相同的格式返回。但是,用戶也可能要求打印的響應。例如,用戶可能希望獲得某個 FAQ 的副本,因此可能需要提供包括向請求者發(fā)送自動化的電子郵件的響應選項。
一旦返回請求的信息,用戶需要有機會根據(jù)當前查詢優(yōu)化請求,以選擇附加菜單選項或開始新的請求。在設計腳本時,執(zhí)行完整測試以確保決不會使用戶無有效或適當?shù)倪x擇可做是至關(guān)重要的;其中包括在任何時候返回到非自助選項的能力。
如果用戶希望進行第二個請求,該流程應該為用戶提供輸入另一個查詢而不必再次注冊的機會。需要對這里可用的選項進行仔細評估,因為可能存在要考慮的安全問題。雖然自動化的系統(tǒng)一般可能受到更多的控制,因為必須準確滿足安全驗證,但是通過個人聯(lián)系處理對應用程序的增加的訪問請求也許更為可取。
如果用戶無法找到他們正在尋找的內(nèi)容,或者已到達可用選項的結(jié)尾,應該詢問他們是否希望聯(lián)系服務臺。與服務臺的聯(lián)系包括從簡單地留個話到針對所需信息的完整請求的范圍。需要考慮用于監(jiān)視和管理此類溝通的方法,但是記錄該請求已經(jīng)經(jīng)歷失敗的自助請求是必需的,以便能夠在可能的情況下對自助服務環(huán)境進行改進。
與事件和問題管理的緊密聯(lián)系在這里明顯是必需的,如果自助服務功能的重點是減少簡單的常見支持請求(例如更換打印機墨粉盒)的數(shù)量,則情況尤其是如此。主要重點應該放在提供高效的、面向客戶的查詢功能上,這樣的功能允許在不卷入服務臺的情況下得到處理。必需經(jīng)常檢查該信息以確保它準確并反映支持(服務)信息的當前狀態(tài)。
自助服務解決方案的可伸縮特性允許組織在遇到快速增長時實現(xiàn)非常靈活的響應。通常,可能要花數(shù)周時間招募和培訓服務臺團隊才能適應增加的要求,例如企業(yè)合并所產(chǎn)生的要求。但是,自助服務技術(shù)能夠滿足增加的服務的許多要求而沒有這樣的時間限制,但是所使用的系統(tǒng)能夠擴展以滿足未來要求是很重要的。
由于所需要的人員,基于電話接線員的服務是提供支持的最昂貴方法。技術(shù)和設備的安裝和維護也很昂貴,但是可能始終存在對基于電話接線員的服務的需要,以便處理例外而不是日常的支持請求。將自動化的響應作為主要響應方法需要重大的初始投資,但是也提供了快速和可實現(xiàn)的投資回報。當前的評估表明,設計良好的基于
Web 的自助服務的成本要比等效的傳統(tǒng)支持低 5%。
圖:天匯幫助臺的自助服務系統(tǒng)功能界面
大多數(shù)科學研究表明,人們寧愿與非人類的界面進行有限的交互(意味著很短的持續(xù)時間),而大多數(shù)人更喜歡人與人的接觸。但是,正確定位、設計和銷售的自助服務解決方案可能被客戶視為是有利的
— 銀行自動取款機 (ATM) 就是這樣的例子。ATM 成功的關(guān)鍵原因是它們方便和易于使用,通過全天候的可用性延長常規(guī)服務,并且通常比排隊等待人類出納員提供更快的替代方法。引入自助服務的組織應該從這個例子中學習,并旨在提供同樣方便和易于使用的解決方案,提供延長的服務,并且至少像等待與人接觸一樣快。
但是,隨著組織轉(zhuǎn)向自助服務,對復雜維護過程的需要將隨之出現(xiàn)。如果要采用自助服務,必須從一開始就做得很好。上圖為人性化的天匯幫助臺系統(tǒng)的自助服務功能界面設計。
3)記錄
所有檢測到的事件和服務請求都需要記錄,以便能夠跟蹤它們以確保沒有任何遺漏。記錄所有聯(lián)系還提供了開始操作和減少特定類型的請求所需要的信息。例如,服務臺可能發(fā)現(xiàn)很大比率的傳入請求都來自只是詢問電話號碼的人。調(diào)查可以發(fā)現(xiàn)內(nèi)部電話目錄本已經(jīng)嚴重過時。然后可以做出在
intranet 上公布內(nèi)部電話目錄的決定,在 intranet 上可以更容易地維護電話目錄。這種主動性不僅減少了針對服務臺的請求數(shù)量,而且通過允許職員容易地訪問最新信息提高了業(yè)務效率。如果沒有記錄電話號碼請求,則問題的規(guī)模就難于確定,并且可能無限期的繼續(xù)存在而未得到解決。
應該將事件詳細信息記錄在服務臺工具中的數(shù)據(jù)庫中。對于每個事件,應該使用下列信息填充事件記錄:
a)唯一參考號
b)記錄日期和時間
c)記錄事件的人員的身份
d)報告事件的人員的身份(包括姓名、部門、位置和聯(lián)系詳細信息)
e)聯(lián)系方法
f)受影響的配置項 (CI) 的詳細信息
g)癥狀描述和任何錯誤代碼
h)重現(xiàn)該問題所需要的步驟
對于服務請求,上面的許多基本信息仍然需要,不過應該將癥狀描述替換為所請求的服務的詳細信息。有些類型的服務請求可能有自己的用于記錄請求的工具(例如用于
RFC 的變更管理系統(tǒng)),而其他請求(例如唯一的批處理作業(yè)請求)不大可能有特定的存儲庫,因此應該作為事件記錄進行記錄以用于跟蹤目的。下圖為客戶通過天匯幫助臺的自助模塊填報采購申請:
圖:添加事件明細來記錄采取的服務支持動作
最新的記錄還允許任何被聯(lián)系的人員為請求發(fā)起者提供進度更新。讓客戶了解最新的進度情況是直接影響客戶滿意度的重要因素。更新應該定期提供,具體取決于事件的優(yōu)先級。例如,高優(yōu)先級事件可能需要每小時的更新,而中優(yōu)先級事件每日接收更新,低優(yōu)先級、長時間處理的事件需要每周甚至每兩周的更新。
在記錄流程之后,事件將經(jīng)過分類和初始支持流程,而服務請求則被傳遞到“服務請求處理”流程。
事件記錄應該在某個服務臺工具中記錄和跟蹤,該工具最好是作為集成的服務管理工具集的構(gòu)成部分。該工具應該在引發(fā)新的事件時提供最基本的事件記錄。比如為了幫助提高效率,當你在天匯幫助臺的用于記錄事件的事件窗口中輸入請求發(fā)起者的姓名時,利用客戶數(shù)據(jù)庫可以自動填充諸如位置、部門和聯(lián)系詳細信息等字段。天匯幫助臺還支持使用計算機電話集成
(CTI)技術(shù)來根據(jù)傳入的電話號碼自動填充字段。即使是在已經(jīng)使用這些技術(shù)的情況下,仍然應該在事件記錄期間與客戶核對諸如聯(lián)系號碼和位置等詳細信息這樣提供了對
CMBD 中保存的數(shù)據(jù)的例行審核,并給出了可能需要進一步調(diào)查或檢查的區(qū)域的指示。
圖:天匯幫助臺的事件記錄窗口
服務臺工具應該使用必填的字段或腳本確保引發(fā)新的事件記錄的人捕獲所有必需的基本詳細信息。
服務臺工具可能允許與網(wǎng)管系統(tǒng)等事件管理系統(tǒng)集成,以便能夠在生成警報時自動引發(fā)事件。這種自動化從支持團隊那里取走了手動填寫事件記錄的任務,從而提高效率。在警報之后手動或自動創(chuàng)建的事件記錄需要包含足夠的信息,以允許支持團隊識別生成該警報的事件。如果事件或警報具有唯一的參考
ID,則應該將它們與受影響的配置項 (CI) 的詳細信息一起包括在事件記錄中。
在事件的生存其中,服務臺工具可能根據(jù)事件優(yōu)先級和組織的更新策略,在客戶更新到達時自動向服務臺分析員發(fā)出警報。該警報可能具有多種形式:
a)查看事件隊列時事件旁邊的時鐘或感嘆號圖標。
b)查看隊列時事件以某種顏色(例如紅色)顯示。
c)彈出式對話框。
d)發(fā)送到指定的別名的消息或電子郵件。
e)定期(每天兩到三次)運行的報告的輸出。
CTI論壇編輯
NET平臺下開發(fā)HelpDesk應用前景分析 2008-06-18 |
確保自助服務成功的六大因素 2008-04-16 |
面壁ITIL之服務臺管理實戰(zhàn) 2007-06-19 |
“幫助臺”軟件概念、功能和市場分析 2007-05-31 |
Unisys演繹如何實踐ITIL 2006-08-01 |