監(jiān)理公司管理系統(tǒng) | 工程企業(yè)管理系統(tǒng) | OA系統(tǒng) | ERP系統(tǒng) | 造價咨詢管理系統(tǒng) | 工程設計管理系統(tǒng) | 甲方項目管理系統(tǒng) | 簽約案例 | 客戶案例 | 在線試用
X 關(guān)閉

[原創(chuàng)]IT服務留單超標快速響應方案總結(jié)

申請免費試用、咨詢電話:400-8352-114

孫翊威

說明:這份方案總結(jié)是對一次應急方案啟動的事后評估,目的是為了改進應急方案。

1、信息傳遞

留單超標快速響應方案(以下簡稱“方案”)自開始啟動,至2007-09-24 16:00解除,歷時6天。×××部對方案的執(zhí)行過程做了一次跟蹤。此次跟蹤從信息傳遞、組織協(xié)調(diào)、流程規(guī)范、狀態(tài)控制、應對措施和資源調(diào)用等方面進行總結(jié)。

從留單響應方案來看,對于信息的傳遞雖有要求但是細致程度還不夠。比如,信息應該以何種方式進行傳遞并如何反饋等等。方案的描述上,信息傳遞多是單向的操作。在“方案”實際執(zhí)行過程中也產(chǎn)生了信息從一個崗位傳遞到另一個崗位沒有后續(xù)反饋帶來的溝通問題。

2、組織協(xié)調(diào)

缺少組織協(xié)調(diào)的另一個弊端是對“方案”規(guī)定的流程缺乏監(jiān)督。這一點在執(zhí)行5.5監(jiān)督階段條款時很突出地表現(xiàn)出來。“響應式任務管理在計劃實施過程中,每一小時向快速響應方案審批者進行狀態(tài)更新(每小時通報當前留單情況)”實際情況是無人按照條款執(zhí)行,也無人對此進行監(jiān)督。

應急事件的組織協(xié)調(diào)很可能會犧牲局部的快速及時,對此大家仍然存在不同的認識。究竟是片面強調(diào)快速反應,還是有計劃,有組織地有限快速進行風險控制?這需要事先的充分溝通才能夠達成行動上的一致。

3、流程規(guī)范

“方案”中并未明確具體的應對流程。雖有文字和流程圖的簡要描述,但流程的執(zhí)行缺少明確的指導。在執(zhí)行過程中相關(guān)人員還需要和“方案”的編制人進行再次確認。在流程這一塊的分析里,還發(fā)現(xiàn)部分流程沒有考慮到實際情況,教條要求留單超標一定要走計劃任務管理這個環(huán)節(jié),結(jié)果帶來的不僅是效率降低,而且計劃任務管理這個環(huán)節(jié)所做的計劃都是無用功。因為計劃任務管理目前不具備安排派單計劃的能力,其制定的計劃無法作為被動式任務管理派單的依據(jù),最后仍然依靠被動式任務管理的經(jīng)驗派單。

4、狀態(tài)控制

“方案”在討論會上確定了應急狀態(tài)的啟動和停止標志。但在實際執(zhí)行過程中發(fā)現(xiàn)應急狀態(tài)的停止標志存在弊端,而且對于停止的標準判斷存在兩條不同的說法“當日16:00時,留單量小于15單”和“當日工作結(jié)束后至次日工作開始前,留單量小于15單,×××部計劃審核者確認后,宣布快速響應期結(jié)束”。無論哪一個條款在實際工作中都會因為當日上午的正常留單積累造成“快速響應期”始終無法達到結(jié)束標準的可能。這也是此次快速響應期一直延續(xù)6天才得以解除的原因之一。同時也會影響因“快速響應期”而暫停的其他工作,如保養(yǎng)。

在實際執(zhí)行過程中無法區(qū)分正常留單和超標留單是“方案”的一個問題所在。因為“方案”對于留單超標這個風險的識別和控制都是基于一種假設情況:在當日某時的留單數(shù)量。過于簡單的識別和控制手段在面對復雜多變的留單情況顯得有些力不從心。

根據(jù)留單超標發(fā)生、發(fā)展和解除的周期分析,“方案”在不同的階段應該有不同的、動態(tài)變化的識別方式和應對措施。而不是采用單一的、固定不變的判斷標準。

5 應對措施

由于識別標志和控制手段的單一,因此“方案”對于留單超標發(fā)生后的應對措施也是略顯單薄。“方案”執(zhí)行中采用的應對措施依然和日常派單一致。對于庫存數(shù)量任務管理無法得到準確的數(shù)據(jù),工程師需要向資源準備和××倉庫兩個渠道領(lǐng)取資源等等。在人力資源出現(xiàn)急缺的情況下派單原則和日常派單沒有區(qū)別,沒有體現(xiàn)出應急方案和日常處理的不同。

綜合前面4點所提到的信息傳遞、組織協(xié)調(diào)、流程規(guī)范和狀態(tài)控制,留單超標的應急方案應該采用逐級對應的原則進行設計。不同的留單狀態(tài)應該有不同的應對措施。

6 資源調(diào)用

“方案”中對于資源的涉及,僅考慮到××××部的配件資源準備。對應急狀態(tài)下的人力資源考慮不足。在設計“方案”時沒有考慮到當工程師都外派之后出現(xiàn)應急狀態(tài)的情況應該如何處理。這次的“方案”演練就發(fā)生在此類情況之下。因此出現(xiàn)即使及時啟動了應急方案但是由于人力資源的短缺導致有單派不出的情況。

在分析了以上6點之外,大家對“方案”的認識也存在差異。具體執(zhí)行人員認為這次的應急啟動沒有體現(xiàn)出應急狀態(tài)和日常狀態(tài)的區(qū)別,反而在某些流程上比日常處理更加復雜。而在配件資源和人力資源存在的一些目前無法解決的問題也導致了應急方案在配件需求和人力需求方面無法做到快速及時,影響了執(zhí)行人員對此次“方案”最終作用的看法,進而產(chǎn)生沒有必要設計應急方案的認識。

另外,在解釋“方案”的執(zhí)行中發(fā)現(xiàn)仍有一些流程和操作需要向編制人咨詢,這從一個側(cè)面說明“方案”未能對應急方案做到完整、準確的描述。

綜上所述:“方案”的演練讓我們開始做到IT服務管理的有章可循。雖然在實際執(zhí)行過程中看到了種種不足,但是出現(xiàn)的問題為“方案”進一步改進提供了參考。

發(fā)布:2007-03-25 10:23    編輯:泛普軟件 · xiaona    [打印此頁]    [關(guān)閉]
相關(guān)文章: