ITIL4之問題管理最佳實踐
目的和描述
問題管理實踐的目的是通過查明事件的實際和潛在原因,以及管理臨時解決方案和已知錯誤,減少事件發生的可能性及其影響。
沒有完美的服務。每個服務都存在可能導致事件的錯誤或缺陷。錯誤可能源于服務管理四維模型中的任何一個維度。例如,第三方合同中的錯誤與組件故障一樣可能導致事件。許多錯誤在服務上線之前就能被識別出來,然后在設計、開發或測試期間得到解決。但是,有一些仍未被發現,將存在生產環境中,它們可能會導致事件產生。為了管理生產環境中出現的錯誤,組織開發了問題管理實踐。該實踐旨在識別和分析組織產品中的錯誤,以最大程度地減少其對所提供服務的負面影響。
1.術語和概念
可能導致(或已經導致)事件的錯誤稱為問題。
定義:問題
一個或多個事件的原因或潛在原因。
問題管理實踐有三個不同的階段,如圖2.1中所示。
圖2.1 問題管理實踐的三個階段
1.1 問題識別
有兩種主要方法來識別問題。第一種方法是調查已經發生的事件的原因。這種方法先要了解癥狀,再了解原因。它目的是防止事件再次發生,也可能有助于解決處于解決中的事件。這稱為被動問題管理,因為它是對事件的被動反應。
第二種方法是在問題導致事件發生之前識別到它,評估相關風險,并優化響應,以最小化事件發生的可能性和/或影響。這稱為主動問題管理,基于有關問題的信息,尤其是在生產環境中可能存在的問題。這些信息來源可能包括:
供應商告知其產品中的漏洞
開發人員、設計人員或測試人員在使用下一版本時發現生產版本中的錯誤
用戶和專家社區分享其他組織的經驗
基礎設施的監控發現系統性能中的偏差,但這些偏差還不屬于事件
技術審計和其他評估
問題管理實踐總是被動的對問題作出反應:它不能防止問題的第一次出現。主動與被動的區別是指問題調查與事件之間的關系:
主動問題管理有助于預防事件第一次發生
被動問題管理有助于預防事件再次發生,并可能有助于解決進行中的事件
1.2 問題控制
問題識別使得問題被登記形成問題記錄。可能形成一系列待分析問題列表。已記錄的問題將根據其最初的分類和優先級進行分析。問題完成分析之后,問題初始分類很可能會發生改變,特別是基于事件(癥狀)信息登記的問題。
定義
任務優先級是一個任務相較于其他任務的重要性。具有更高優先級的任務應優先被處理。優先級基于待辦事項中所有任務的情況來定義。無法為待辦事項中所有的任務分配資源時,通過優先級排序選擇優先要處理的任務。
問題控制專注于問題的分析。在被動問題管理中,問題分析可使用關于產品架構和配置的信息來識別可能導致相關事件的配置項(CI)。分析不限于配置項,還包括其它因素,例如:用戶行為、人為錯誤和規程錯誤等。
主動問題管理通常從更好地掌握配置項和服務管理四維模型中所有維度開始,這些組件可能導致事件。例如,如果供應商將其軟件中的漏洞告知組織,則問題控制的任務將是掌握組織使用該軟件的情況,以便評估與漏洞相關的風險以及對所提供服務的潛在影響。
對問題完成分析后,將為其分配為“ 已知錯誤”狀態。
定義:已知錯誤
已經分析過但尚未解決的問題。
問題優先級
問題很多屬于低緊急度。服務團隊有一些更緊迫的任務需要完成,使得緊急度低的問題在待辦事項中總處于保持的狀況。但是,確保對識別到的問題進行分析和解決是非常重要的。從中長期的角度來看,問題既影響所提供的服務的質量,也影響服務提供者的工作量。
問題優先級劃分有許多簡單的準則:
評估問題的影響度和緊急度(以及調查和解決的時間限制),評估結果可用于確定優先級和其他重要的考慮因素,例如,預估完成工作所需的時間
只有存在資源沖突時才需要確定優先級。當有足夠的資源在有限的時間內處理每一項任務時,優先級排序不是必須的
應該使用包含其他任務(計劃內的和計劃外)的統一待辦事項來計劃問題處理
優先級排序是為團隊內部成員分配任務的一種工具。如果問題由多個團隊處理,則可根據每個團隊的資源可用性、目標完成時間以及預計處理時間來確定優先級。
資源可用性和預計處理時間由團隊定義。目標完成時間取決于問題的影響,當問題被確定并初步分類時,它可能被定義。隨著問題分析過程中發現新的信息,問題的影響,預計完成(解決)時間可能會發生變化
可視化工具(例如,看板和精益原則,限制進行中任務數量)有助于有效的優先級排序
這些規則適用于服務提供者的專業團隊執行的所有類型的工作(計劃的和計劃外的)。重要的是,在所有實踐中涉及組織服務管理活動的每個人都應該同意并遵循它們。
這些規則適用于服務提供商的專家團隊執行的所有類型的工作(計劃的和計劃外的)。重要的是,在所有實踐中,參與組織服務管理活動的每個人應達成一致,并遵循它們。
問題分析過程中可能會發現錯誤已經從組織的環境中消除,或者它們不會影響所提供的服務。根據上面的示例,組織可能未使用該軟件易受攻擊的版本,或者漏洞可能不會影響組織的服務。在這些情況下,問題記錄經過分析后可以設置為已關閉。在其他情況下,它可能保持處理狀態,并啟動錯誤控制。
問題控制其他的重要輸出可能是解決事件的建議。通常,了解導致事件的原因有助于,為處理事件提出更有效的解決方案,包括臨時解決方案。
定義:臨時解決方案
減少或消除尚未獲得永久解決方案的事件或問題的影響的解決方案。一些臨時解決方案可以降低事件發生的可能性。
請注意,從問題分析得出的臨時解決方案通常不會減少發生事件的可能性,而是,有助于在事件發生時,更快、更好地解決事件。有助于防止事件再次發生的臨時解決方案通常在錯誤控制階段被找到。
1.3 錯誤控制
對問題進行分析后(如,產品中的錯誤對組織自身服務的影響已經被評估),應該對其進行控制。僅當滿足以下條件之一時,問題記錄才可能關閉:
問題被解決:與問題相關事件的風險被移除,或降低到可接受的水平。
問題不再影響組織。
請注意,盡管“ 已知錯誤”是問題的狀態,但是某些組織更喜歡使用獨立的記錄來進行問題控制和錯誤控制。在這些情況下,當問題分析完成時,問題記錄可能被關閉,并且隨后的活動可能被登記到相關的已知錯誤記錄中。上述關閉條件適用于已知錯誤,無論它們是否是問題。
如果許多已知錯誤無法得到有效解決,并且它們會繼續影響服務,那么它們將長期處于未關閉狀態。在這些情況下,組織可能集中精力,最大程度地提高事件處理的效果和效率(有時達到完全自動檢測和解決的水平),但問題記錄應保持未關閉狀態,并定期進行審查。
如果解決問題的成本高于處理已知錯誤或有效事件管理的成本時,則上述錯誤控制方法是有效的。這通常用于與第三方組件相關的典型問題,尤其是在第三方無響應或組件不受支持的情況下。相反,如果組件可用于改進并可以進行改進時(特別是在組織自己控制下的軟件),則應迅速消除已知錯誤。
已知錯誤是組織技術債務的一部分,應在合理可行的情況下予以消除。
定義:技術債務
選擇臨時解決方案,而不是需要花費更長的時間的系統性解決方案。
錯誤控制確保組織擁有與其產品相關的已知錯誤有足夠的最新信息,包括它們的狀態及對服務的影響。
錯誤控制對問題解決方案進行了優化,使其成本、負面影響、正面影響相平衡。
定期檢查已知錯誤有助于識別環境中的變化(例如,業務影響、永久解決方案的可用性和相關成本,以及資源可用性等),這些變化可能會導致對錯誤的重新評估,并啟動錯誤的解決。
錯誤控制的關鍵輸出是改進措施和變更請求,它們啟動問題的解決。某些解決方案修復了配置項和其他產品組件中的錯誤。其他的可能會引入永久的變通方法:對產品配置的更改不會修復錯誤,但可以將事件發生的可能性降到最低,相關的問題記錄可能會被關閉。保持錯誤相關知識的可用性是很重要的,這些知識對于將來的服務設計以及規劃可能非常有價值。
永久性變通方法通常用于組織無法修復的組件(舊系統、第三方提供的工程基礎結構等)。但是,使用永久性變通方法來防止事件會增加組織的技術債務。因此,應盡可能避免使用。
總而言之,表2.1中列出了消減問題的可能類型。
表 2.1 問題消減的方法
1.4 問題模型
不同的問題來源和類型可能需要不同的方法來識別和控制問題。例如,以下類型問題中的一種或多種可能對問題管理實踐需要特殊的處理方法。這些問題包括以下方面:
軟件
硬件
程序
第三方組件
消費者的資源
數據
數據與敏感信息相關
高度規范的服務和系統
為了優化這些問題和其他類型問題的處理與解決,服務提供者通常定義問題模型。問題模型有助于有效地管理問題,由于應用程序相關的經過驗證和測試的方法,通常可以得到更好的結果。
定義模型
一種管理特定類型問題的可重復方法。
問題模型的創建和使用對于問題管理實踐中的活動很重要。它們將在第3節中進行介紹。
1.5 范圍
問題管理實踐的范圍包括:
問題的識別與分析,包括已知錯誤的分析與控制
啟動變更以消除或減少問題的影響
向干系人提供有關問題信息
監控錯誤和持續改進解決方法
有一些活動和責任范圍不包括在問題管理實踐中,盡管它們仍然與問題密切相關。表2.2中列出了這些內容,以及對可以找到它們的實踐的引用。重要的是要記住,ITIL實踐只是價值流的背景中使用的工具的集合,應根據情況需要將它們組合在一起。
表2.2 與其他實踐指南中描述的問題管理實踐相關的活動
實現價值 | 實踐指南 |
事件解決 | 事件管理 |
控制和實現為解決問題而啟動的變更 | 變更啟動部署管理 |
基礎設施和平臺管理發布管理 | |
軟件開發和管理 | |
其他做法 | |
風險評估和控制 | 風險管理 |
檢測和控制產品在部署到運行環境之前的錯誤 | 部署管理服務設計 |
服務驗證和測試 | |
軟件開發和管理 | |
溝通事件的解決方法給用戶 | 服務臺 |
2 實踐成功因素
定義:實踐成功因素
達成實踐目標所必須的一系列復雜功能組件
實踐成功因素(PSF)不僅是一個任務或活動,還包含所有服務管理思維模型組件。實踐中PSF的活動和資源的性質可能有所不同,但它們共同確保了實踐有效。
問題管理實踐包含以下成功因素(PSF):
識別并了解問題及其對服務的影響
優化問題解決和消解措施。
2.1 識別并理解問題及其對服務的影響
組織應該掌握其產品中的存在錯誤。因為,它們可能導致事件并影響服務質量和客戶滿意度。問題管理實踐確保問題被識別,從而有助于持續改進的產品和服務。如果是主動執行而不是被動執行,這將更加有效。
2.2 優化問題解決和消解措施
發現問題后,應有效和高效地進行處理。修復(消除)組織產品中的所有問題幾乎是不可能的,但是,對于組織及其客戶而言,沒有解決方案的問題識別,其價值就會大大降低。應該為問題消解定義一種平衡的方法,即一種考慮相關成本,風險和對服務質量的影響的方法。
3. 關鍵指標
ITIL實踐的績效應在每種實踐所貢獻的價值流的背景下進行評估。與任何工具的表現一樣,該實踐的表現只能在其應用范圍內評估。但是工具的設計和質量會有很大差異,這些差異定義了不同用途下的潛力或能力。有關度量、績效(KPI)和其他有助于實現這一目標的其他技術,請參見《度量和報告實踐指南》。
問題管理實踐的關鍵指標已映射到其PSF。 它們可以用作價值流中的KPI,以評估實踐對這些價值流的有效性和效率的貢獻。 表2.3中給出了一些關鍵指標的示例。
表2.3 實踐成功因素的關鍵指標示例
將度量指標正確匯總到復雜的指標中,才更易于將數據用于正在進行的價值流管理,更利于問題管理實踐的定期評估和持續改進。這并沒有單一的最佳解決方案。度量標準將基于組織的整體服務戰略和優先級,以及實踐貢獻的價值流的目標。
4. 價值流和流程
4.1 價值流貢獻
與任何其他ITIL 管理實踐一樣,問題管理實踐也有助于實現多個價值流。請謹記單一實踐不會形成價值流。問題管理實踐與其他實踐相結合,可以為消費者提供高質量服務。實踐貢獻的主要價值鏈活動是:
交付和支持
改進
問題管理實踐對服務價值鏈的貢獻如下圖片3.1 所示:
圖3.1 問題管理實踐對價值鏈的貢獻的熱圖活動
4.2 流程
每個實踐可能包含一個或多個流程和活動,它們對于實現該實踐的目的可能是必需的。
定義:流程
一組相互關聯或交互的活動,可將輸入轉化為輸出。一個流程接受一個或多個已定義的輸入并將其轉換為輸出。流程根據活動的順序與依賴性定義次序。
問題管理活動分為四個過程:
主動問題識別
被動式問題標識
問題控制
錯誤控制
4.2.1 主動問題識別
該流程包括表3.1中列出的活動,并將輸入轉換為輸出。
表3.1 主動問題標識流程的輸入活動和輸出
關鍵輸入 | 活動 | 關鍵輸出 |
來自供應商和供應商的錯誤信息 有關專家團隊提交的潛在錯誤的信息 | 評審的提交信息 問題登記 問題的初步分類和分派
| 問題記錄反饋給問題發起者 |
外部用戶和專業團體提交的有關潛在錯誤的信息 | ||
用戶提交的有關潛在錯誤的信息監控數據 | ||
服務配置數據 |
圖3.2 顯示了流程的工作流程圖。
圖3.2 主動問題識別流程的工作流程
主動問題用于識別到組織產品中存在的,來源于事件記錄以外的潛在錯誤。可以考慮將問題的主動標識和控制作為風險管理的一種形式執行,即重點關注組織產品中的漏洞,它包括對漏洞和相關風險的識別、評估和分析。
表3.2 中列出了組織產品相關錯誤可能的信息來源。
表3.2 主動識別問題的信息來源
主動的風險管理活動應盡可能的專注于對組織及其客戶具有最大潛在影響的關鍵系統和組件。
然而,其他系統中錯誤的跡象不應被忽視。在為提高可用性而設計的復雜技術環境中,導致事件可能有多種原因,這些原因通常是各類因素組合后產生的結果。非核心系統中,看似不重要的錯誤可能導致嚴重事件。主動問題識別應包括對已識別漏洞的發生概率和影響進行仔細評估。
表3.3提供了流程活動的示例。
表3.3 主動問題識別過程的活動
表3.3 主動問題識別過程的活動
誰可以登記問題?
有幾種方法可以分配問題登記的職責。一種方法是鼓勵每一位專家提出并登記問題。這將增加改進的數量,并提高組織產品中錯誤的可見性。
但是,這可能會顯著增加登記問題的數量,沒有人關注這些問題,或者這些問題被錯誤地分類了。為防止這種情況發生,一些組織更愿意讓一個或多個角色負責對潛在問題的初始篩選并進行登記。只要角色中的人員擁有所需的資源,并且可以使來自各種來源的流程信息一致且透明地進行,此方法就有效。
4.2.2 被動問題識別
該流程包括表3.4中列出的活動,并將輸入轉換為輸出。
表3.4 被動問題識別過程的輸入,活動和輸出
關鍵輸入 | 活動 | 關鍵輸出 |
有關持續事件的信息 事件記錄和報告監控數據 服務配置數據 服務級別協議(SLA) | 問題登記 問題初步分類與分派 | 問題記錄 |
被動問題識別過程的工作流程圖如下圖3.3所示:
被動問題識別使用過去或正在發生事件的相關信息來調查其原因。可能問題是在診斷分析發生中事件的性質遇到難題而觸發的。在這種情況下,問題識別和控制可能很緊急,事件管理和問題管理實踐在同一個價值流中,同時,它們需要相同(或重疊)的資源,包括團隊,工具和過程。
基于對過去事件的分析時,問題的識別可能包括:基于各種角度的統計分析、影響分析和趨勢分析。這是為了識別具有可能的共同原因或其他相關性的一組事件。
過程隨觸發點不同而略有差異。表3.5中說明了這些差異。
表3.5 被動問題識別過程的活動
活動 | 由進行中的事件觸發 | 由事件記錄分析觸發 |
問題登記 | 處理該事件的團隊確定需要進行問題調查。在某些情況下,問題記錄與一個或多個事件記錄相關聯,以便于跟蹤調查。當多個地點的多個事件由不同的團隊處理時,需要進行協同進行問題調查,或者由專門的團隊進行問題調查時,這一點可能尤為重要 在其他情況下,處理該事件的團隊可以繼續調查事件的原因,并在事件解決后記錄問題。這個問題可能仍然需要登記,特別是導致事件的原因在事件解決過程中沒有得到消除,可能導致新的事件發生 | 負責系統、服務或生產的專家團隊會定期檢查與其職責范圍相關的事件記錄。如果他們經過分析發現了問題,并進行問題記錄的登記。這些情況可能包括:
|
問題初步分類與分派 | 登記問題過程中,進行問題的初步分類。通常包括以下這些內容(如果已知或合理假設):
如果問題是在診斷分析之前進行登記,則問題將被分配給適當的專家組。 如果問題在診斷分析之后登記,則信息應用包括所做的步驟、結果和問題的當前狀態。如果在登記時問題還沒有得到解決,則將其分配給適當的組。
| 登記問題過程中,進行問題的初步分類。通常包括以下這些內容(如果已知或合理假設):
根據初步的分類,將問題分派到一個負責相關的配置、服務或產品的專家組
|
4.2.3 問題控制
該流程專注于問題的調查。它包括表3.6中所示的活動,并將輸入轉換為輸出。
表3.6 問題控制過程的輸入活動和輸出
關鍵輸入 | 活動 | 關鍵輸出 |
問題記錄 服務配置數據 配置項、產品和服務等技術信息 事件記錄 監控數據 | 問題調查 已知錯誤溝通 | 問題記錄 已知錯誤 事件解決方案 |
圖3.4顯示了問題控制流程的工作流程圖。
圖3.4 問題控制流程的工作流程
表3.7提供了流程活動的示例。
表3.7 問題控制流程的活動
組織使用各種分析技術進行問題調查。這些可能包括:
根本因分析技術,例如5 Whys分析法、K&F分析以及故障分析樹
影響分析技術,例如組件失效影響分析、業務影響分析
風險分析技術。
記住以下一點很重要。單一根源的情況在復雜的、不斷發展的環境中具有非常有限的適用性。事件常常是由不可預料的因素經過預料之外的組合后導致的。因此,對問題的調查(尤其是在被動問題管理中)不應僅限于確定事件的一項可能原因。問題調查應始終考慮整個服務管理四維模型。可以在補充ITIL出版物中找到有關使用特定技術進行問題調查的進一步指南。
4.2.4 錯誤控制
這一過程的重點是監測和控制已知錯誤(已分析但尚未解決的問題)的狀況及其解決方案。它有助于確保已知錯誤對服務的負面影響得以掌握并使其最小化;有關事件的解決方案是有效的;已知錯誤的緩解方法是有效的,可行且高效的。
該流程包括表3.8中所示的活動,并將輸入轉換為輸出。
表3.8 錯誤控制的輸入活動和輸出流程
關鍵輸入 | 活動 | 關鍵輸出 |
問題記錄 服務配置數據 配置項、產品和服務等技術信息 事件記錄 監控數據 知識管理數據 | 問題解決方案開發 問題解決啟動 已知錯誤監控和檢查 問題關閉 | 問題記錄 問題型號 變更請求 改進計劃 問題解決方案 |
圖3.5顯示了流程的工作流程圖。
圖3.5 錯誤控制的工作流程
表3.9提供了流程活動的示例。
表3.9 錯誤控制的活動流程
活動 | 描述 |
問題解決方案開發 | 團隊(根據問題調查進行分配或重新分配)尋找解決問題的方法。這包括定義消解方法(請參見表2.1)和所選方法中的實際解決方案開發。如果沒有針對問題的可行解決方案,則會記錄支持信息,并且定期評審錯誤。 |
啟動問題解決 | 在大多數情況下,問題需要通過變更解決。負責的團隊按照組織初始化和實現變更的程序,提交變更請求。 在其他情況下,所需的操作不歸類為變更,可以按照其他過程來啟動和執行。無論哪種方式,團隊都會啟動已定義(如果需要的話,已批準)問題解決所需的操作。可能需要以相關理由支持(包括財務、風險、合規性、技術和其他注意事項)。 |
已知錯誤監控和評審 | 如果已知錯誤的解決方案得到批準 使用預先商定的標準控制和確認解決方案的實施。這通常由發起解決方案的團隊,或其他預先約定的角色,如由問題經理來完成。 對于被動識別的問題,可以根據事件動態的變化(解決或預防相關事件)來完成。對于主動識別的問題,解決控制基于已發起變更是否成功,并可能包括一段時間來監控可能受到錯誤影響的服務。如果問題的解決方案沒有得到確認,團隊則返回到該過程的問題解決方案開發步驟。 如果找不到針對已知錯誤的可行解決方案 指定專家團隊對已知錯誤進行監控。這通常是負責與已知錯誤關聯的配置項、服務或產品的團隊。該團隊按照消解策略中定義的方式的監控已知錯誤的狀況。監控的參數可能包括:
團隊應定期進行問題審查(根據商定的消解方法),或基于監控結果進行問題審查。 如果評審確認消解方法有效且是最新的(問題存在,最新影響評估,事件解決方案有效,問題變通方案有效且沒有可行的問題修復程序方案可用),那么繼續進行已知錯誤的監控。 如果消解方法變得無效,則啟動問題解決方案開發活動來審查和重新定義消解方法。這可能包括開發和實現一個問題解決方案或更新相關事件的事件解決方案。 如果問題不再存在(例如,已通過計劃的軟件或硬件更新或通過停用受影響的配置項將其移出),則啟動問題關閉。 如果問題出現了一個新狀況,建議修改或創建問題模型,并將問題模型將作為問題評審活動的一部分進行記錄和交流。 基于監控數據更新問題記錄。 |
問題關閉 | 負責問題的團隊(或專家)記錄問題評審結果并正式關閉問題記錄。 如果確認解決,則團隊記錄解決控制結果并正式關閉問題記錄。已關閉問題記錄應作為組織的知識庫的一部分,尤其是如果有類似的 問題可能會再次發生。 |
問題管理活動由服務提供者執行,如表3.3、3.5、3.7和3.9中所述。他們可能涉及供應商和合作伙伴,甚至有時還涉及客戶和用戶。這些活動可以利用工具和技術支持開展(有時甚至是全自動化或很高程度的自動化)。這些將在以下部分中進行闡述。
5. 組織和人員
5.1 角色,能力和責任
實踐指南沒有描述實踐管理的角色,例如實踐負責人,實踐主管或實踐教練。相反,他們專注于每個實踐的專家角色。組織不同,每個角色的結構和命名也可能不同,因此ITIL中定義的任何角色都不應被視為強制性的,甚至不應被視為推薦性的。請記住角色不是職務。一個人可以擔任多個角色,一個角色也可以分配給多個人。
角色是關聯到流程和活動中來描述的。每個角色都具有基于表4.1中所示的模型的能力概況特征。
表4.1 能力代碼和描述
能力代碼 | 能力概況(活動和技能) |
L | 領導者 決策、授權、監督其他活動,激勵團隊,提供動力以及評估結果 |
A | 管理員 分配任務并確定優先級,保留記錄,持續報告并啟動基本的改進 |
C | 協調員/溝通者 多方協調,維護干系人之間的溝通,并負責有關認知的宣傳活動 |
M | 方法和技術專家 設計和實施技術工作,編織規范文檔,提供流程、工作分析和持續改進的咨詢 |
T | 技術專家 提供技術(IT)專業知識,并執行基于專業知識的任務 |
在組織中可以設定兩個實踐特定的角色:問題經理和問題協調人。這些角色通常在問題數量很多的組織中引入。在其他組織中,問題管理活動由負責與問題關聯配置項的服務或產品的個人或團隊協調。,可能是資源所有者,服務負責人或產品負責人。
5.1.1 問題經理角色
在定義專門的問題經理角色的情況下,通常將其分配給專家,這些專家結合了組織產品(架構,配置和相互依賴性)的豐富知識以及扎實的分析技能(協調團隊合作并提供出色風險管理的能力和權威)。該角色的能力概要是TMAC。角色通常負責管理和協調問題管理流程中的專家活動,包括:
根據提交的信息進行和協調問題登記
問題的初步分類
與負責事件解決和變更實施的團隊協調溝通
開發和交流問題模型(如適用)
協調已知錯誤監視和評審
問題規范的關閉
5.1.2 問題協調人角色
在較復雜的組織中,問題管理實踐的某些職責可以委托給問題協調人。問題協調人專注規范的問題管理,例如,對提交的關于可能出現的問題的信息評審、問題評審和問題關閉。
5.2 組織結構和團隊
盡管問題管理的角色有時與正式職稱相關聯,但問題管理實踐的專用組織結構卻很少見。這對于具有復雜官僚機構和大量需要管理的問題的組織來說是典型的。許多組織發現組建臨時團隊調查影響度高的問題和/或開發解決方案很有用。
在以產品為中心的組織中,通常不采用問題管理工作的頭銜和角色。相反,這種實踐被集成到產品開發和管理團隊的日常活動中。它在任何可能的地方都是自動化的。
若需要ITIL4問題管理完整實踐資料,請點擊右上角注冊賬號后向客服索取!
永服科技有限公司(簡稱“Servicehot”),運用ITIL、ISO20000、ITSS等最佳實踐方法,結合ServiceHot在國內外眾多行業客戶的IT服務管理、信息安全管理方面的成功實施經驗,協助客戶梳理并建設IT管理體系,推動企業數字化轉型,ServiceHot產品在數以百計的大型的國企、制造業、金融、IT互聯網等行業完成了實際的應用和推廣,主要案例包括:XX省農信、建信基金、中原銀行、國信證券、四川長虹、一汽啟明、中國移動、中國石化、華為、深信服、中航西飛、中航成飛、深圳航空、富力集團、華西醫院、西南民族大學、瀘州老窖、天原集團等。