很多大型企業的IT部門開始導入ITIL,或者是運用ITIL所建議的諸多服務手法,其中,企業經常使用的IT服務就是Service Desk的設計。

但是,企業打造Service Desk通常會發生一件事。IT主管希望能知道,有多少IT部門的內部顧客提出服務請求、有哪些需求來自既有工作但沒有到位、或上一次服務沒做好的緣故等。如果我們相信人性,就有一件必然會發生的事:吃案。

我們經常會聽說警察吃案的說法。不管這有沒有真正發生,要是發生的話,一點都不意外:目前的報案方式就是會導致吃案的制度。對一個警察單位的主管而言,績效必然與轄區的治安情況有直接關連。當民眾到派出所報案時,報案的人越多,案子越多,表示這個轄區的治安不佳,就會影響警察的績效。所以,在結構上有問題,當然警察就會有蓋掉案子的莫大誘因。

雖然警察機關設有報案三聯單的機制,一旦填寫了報案三聯單,的確是無法再吃案。但是,換做是我的話,我要吃案,就會把來報案的民眾勸退,在填寫三聯單之前,就先把我的治安瑕疵消滅掉。

我的意思不在說警察的壞話,而是軟體部門和警察單位一樣會吃案。對軟體公司或IT部門而言,負責專案的人員直接接受顧客的抱怨和服務請求,他怕自己的績效不好,對上級報喜不報憂,吃案就自然會發生。

如果經常發生吃案,CIO就會失去能見度,不知道自己服務的使用者單位真正受到甚麼樣的服務。很可能使用者對網路品質抱怨連連,但部屬卻回報,網路使用一切順暢。

即使,部屬私下解決了當事人的問題,雖然沒有影響到使用者應享有的服務,但是,這樣的吃案會帶來更大的管理問題。從管理角度來看,使用者經常提出同類的服務請求,表示這是一件需要被重視的問題。但若發生吃案,問題被隱藏,CIO就無法判斷問題的嚴重程度,也就不會採取任何改善措施。其實,這些私下自了的服務會造成很嚴重的隱藏成本。

不僅如此,從人性的角度來看,Service Desk的作業人員,一定先從急件開始處理,可是急件不一定是主管認定的重要工作,例如網路速度變慢、電腦中毒、無法寄信這類問題。作業人員為避免影響績效,很容易隱瞞不報,自行私下解決。

不知情的主管以為部屬平時有時間執行那些重要卻不緊急的工作,其實,他們整天忙著處理緊急但不是最重要的事。有一天,當重要工作變成緊急任務時,就會來不及因應。

吃案問題和我們上一次提到的責任分工(Segregation of duties)有關。若接受抱怨的人,和提供服務的人,都是同一個人,吃案現象就無法避免。

因此,IT打造服務臺的時候,還需要打造一個分工體系。負責接受服務請求案的人,對於每項顧客請求都需要立案。接下來,再把案子分給相關的第一線服務人員(先前提過的IT服務前臺和後臺設計)。待服務結束後,還需要結案的處理。

另外,還需要考量服務模式的設計,如果第一線服務人員無法完成,如何將工作轉給更專業的第二線人員。這樣一個分工清楚的服務模式設計,才能避免吃案,才能有好的顧客服務,以及有效率的內部作業。如此一來,IT管理才能擁有能見度。口述⊙范錚強,整理⊙王宏仁

專欄作者

熱門新聞

Advertisement