[Company logo] Version 4.0. Problem Management Process. January [Company] [Link]

Transcription

1 Version 4.0 January 2017 [Company] [Link]

2 Document Control General Information Process Name: Process Number: PROC00004 Initial Effective Date: October 2 nd, 2015 Revised Effective Date: January 6 th, 2017 Process Owner: [Name] Current PEG Number: PEG (Title) [Company] Problem Manager Process Manager: [Name] (Title) [Company] ITSM Manager Process SMM Location: [Link] Approval Signature [Company] Approval: (Required signature) Date: 01/06/2017 (Title) [Name], [Company] Customer Relations Service Delivery Area Manager TxDOT Approval: (Required signature) Date: (Title) [Name], TxDOT Operations Process Owner Approval: (Required signature) Date: 01/06/2017 (Title) [Name], [Company] Problem Manager [Company] Page 2 of 33

3 Revision History The revision history identifies the version number, the date the change became effective, a brief description of the change, all sections impacted by the change, and the required review / approval. The revision history table (below) captures each change made to this document. [Company] Page 3 of 33

4 Version Effective Date Description of Change Affected Section(s) Prepared By Reviewed By Approved By /06/ /28/ /02/2016 Reviewed by QA and uploaded to SMM Wiki Update flow diagram step to remove CAP reference All [Name] [Name] [Name] PEG /Removed all reference of CAP Removed reference to activities around RCA s. Details are identified in the PROC00023_RCA process. All [Name] [Name] Reviewed by QA and uploaded to SMM Wiki All [Name] QA [Name] /02/2016 PEG /Modified the Process Owner and Process Manager Document Control Page [Name] QA /13/ /10/ /05/ /01/2016 PEG /Removed reference to the [Company] PL0004_Problen Mgmt. TxDOT Policies are the authoritative source and located on the IMD site PEG /Updated Policy links to reflect the new TxDOT IMD Policy Page location Approved by QA and PEG All [Name] QA, PEG Board /01/2016 QA Review All [Name] [Company] Page 4 of 33

5 Version Effective Date Description of Change Affected Section(s) Prepared By Reviewed By Approved By /27/2016 Response in response to QA Review PEG Updated for CR Transformation QA Review PEG Step updated narrative to include the TxDOTNow states - Step updated to include reference to updating vendor information if vendor is involved - Step updated to include reference to the Knowledge Articles - Section 4- updated to include the automated rules - PEG / Updated PROC00032_Known Error Process step to include the timing and use of the known error state needs to be clarified - when is it turned on and when changed. All [Name] [Name] /21/2016 QA Review All [Name] /15/2016 Submitted for QA Review PEG /Updated in response to QA Audit #5354: - Step updated narrative, step description and diagram activity box - Step duplicate sentence removed during Joint Review - Step link updated and verified that it works - Process revision table updated to include PEG All [Name] /11/2016 Submitted for TxDOT Feedback via DocuSign All [Name] [Name] /11/ /29/2016 Joint review/ Updates based on comments from review session as documented in the 02/29 /2016 and 03/11/2016 Meeting Notes All [Name] [Name] [Company] Page 5 of 33

6 Version Effective Date Description of Change Affected Section(s) Prepared By Reviewed By Approved By /20/2015 PEG _Updated document as per the PRC#C / Supplemental Work Order# X- M-197B Include adding new sections: SIPOC, Role Definitions, KPI s, Process Diagram Reponses to TxDOT content comments All [Name] [Name] [Company] Page 6 of 33

7 Version Effective Date Description of Change Affected Section(s) Prepared By Reviewed By Approved By /02/2015 PEG /Approved by QA/PEG Added link to the RCA/CAP section of the SMM Wiki. All [Name] PEG Board PEG Board /31/2015 Updated QA comments This is the version to be submitted as deliverable for ITIL project All [Name] /31/2015 QA Feedback [Name] /24/2015 Updated in response to QA comments Updated diagrams as per comments, added reference to RML (sec7), added reference to PL0004 Problem Mgmt. policy (sec8) All [Name] [Name] /23/2015 QA Review All [Name] PEG QA /08/2015 Ready for QA Review All [Name] /08/2015 Technical Writer review All [Name] [Name] /05/2015 Updated as per the Gap Assessment Immediate Actions All [Name] [Name] /23/2014 Updated based on further peer review All [Name] [Name] /10/2014 Updated as per peer review with Problem Management team All [Name] [Name] /07/2014 Updated based on new template guidelines All [Name] /20/2014 Updated as per internal review All [Name] /16/2014 Updated as per PEG Review Board All [Name] [Name] /14/2014 Initial Draft All [Name] [Company] Page 7 of 33

8 Table of Contents DOCUMENT CONTROL... 2 REVISION HISTORY PROCESS DEFINITION AND OBJECTIVE Major Problem PROCESS SCOPE PROCESS TRIGGERS PROCESS INPUTS/OUTPUTS PROCESS FLOW AND DESCRIPTION Problem Detection and Logging Problem Categorization and Prioritization Problem Investigation and Diagnosis Major Problem Review, Closure and Reporting RACI REPORTING AND METRICS POLICY KEY TERMS/ACRONYMS AND DEFINITIONS PROCESS(ES) IMPACTED APPENDIX [Company] Page 8 of 33

9 1 Process Definition and Objective It is the analysis of incidents, break/fix, issues, and anything that can be identified as a possible problem that result in the need to raise a problem record so that the underlying fault can be investigated further. The objectives of the problem management process are to: Prevent problems and resulting incidents from happening Eliminate recurring incidents Minimize the impact of incidents that cannot be prevented Diagnose the root cause of an incident or number of incidents Take corrective action in order to eliminate that root cause Reduce the impact when it is cost-justifiable to do so For Contractual Problem Management, please refer to the [Link] 1.1 Major Problem Major problem is a result of a P1 Incident which requires a Root Cause Analysis (RCA). As part of the, major problem reviews are conducted weekly. Major problem reviews are a source of input to proactive problem management through identification of underlying causes that may be discovered in the course of the review. The knowledge gained is reviewed at the Daily Ops meeting once a week with Service Delivery Managers to ensure the team is aware of the actions taken and the plans to prevent future major incidents from occurring. This helps to improve customer satisfaction and assures TxDOT that [Company] is handling major incidents responsibly and actively working to prevent their future recurrence. 2 Process Scope Problem management includes the activities required to diagnose the root cause of incidents and to determine the resolution to those problems. It is also responsible for ensuring that the resolution is implemented through the appropriate control procedures. Problem management will also maintain information about problems and the appropriate workarounds and resolutions, so that the organization is able to reduce the number and impact of incidents over time. [Company] Page 9 of 33

10 3 Process Triggers With reactive problem management, the vast majority of problem records will be triggered in reaction to one or more incidents, and many will be raised or initiated via Service Desk. Other problem records, and corresponding known error records, may be triggered in testing, particularly the latter stages of testing such as user acceptance testing/trials (UAT), if a decision is made to go ahead with a release even though some faults are known. Suppliers may trigger the need for some problem records through the notification of potential faults or known deficiencies in their products or services. Problem records can be requested and/or opened by any requester, including TxDOT and internal ITIL Users. Another trigger for problem management is an automated detection of an infrastructure or application fault, using event/alert tools automatically to raise an incident which may reveal the need for a problem record. With proactive problem management, problem records are triggered by identification of patterns and trends in incidents when reviewing historical incident records. TxDOTNow has the following automated rules in place: For EVERY P1 Incident Ticket, a P1 Problem Ticket is generated If 5 P2s Incidents are opened within 7 days (same CI), a P2 Problem Ticket is generated If 15 P3 Incidents are opened within 7 days (same CI), a P3 Problem Ticket is generated Regardless of their priority if 45 Incidents are opened within 30 days (same CI), a P4 Problem Ticket is generated 4 Process Inputs/Outputs Inputs Tools Outputs / Deliverables Incident Management Service Desk Event Management Proactive Problem Management Suppliers Reports TxDOTNow [Link] Problem Records Change Request (CR) Root Cause Analysis (RCA) form Known Errors Work-Around Knowledge Articles 5 Process Flow and Description The process of Problem Management is composed of the following sub-processes: Problem Detection and Logging Problem Categorization and Prioritization [Company] Page 10 of 33

11 Problem Investigation and Diagnosis Major Problem Review, Closure, and Reporting Overall Process Management Process Start Problem Detected 5.1 Problem Detection & Logging Overall Identify Impact & Urgency 5.2 Problem Categorization and Prioritization Investigate the Problem and determine its root cause 5.3 Problem Investigation and Diagnosis Perform Major Problem Review and Close 5.4 Major Problem Review, Closure, and Reporting End [Company] Page 11 of 33

12 5.1 Problem Detection and Logging Process Flow: Problem Detection and Logging [COMPANY] NTT DATA Incident Resolver Group(s)/Service Desk [COMPANY] NTT DATA Problem Manager Start Problem(s) detected Match findings with existing Problem Records Need to Create New Problem Record? Yes Create Problem Record Match Problem Record to past Incidents No End Proceed to Categorization and Prioritization Process Title Detection and Logging Process Owner Process Document Document No. PEG No. Problem Management ITSM > Problem Management PROC Drawn By Create Date Version Status Version# PAGE 1 Mariel Tulipano 06/05/2015 Final 1 PERSON REV. DESCRIPTION DATE BY 2 Reversed and 5.1.3/Included swim lanes for NTT [COMPANY] DATA Incident Resolver Groups/ Service Desk 03/27/2016 MT TMPL00013_REV(11/19/2014,v0.1) [Company] Page 12 of 33

13 Process Description: Problem Detection and Logging [Company] Page 13 of 33

14 Step Description Problem(s) detected There are multiple ways that Problems are detected: Major Incidents Reactive problem management is concerned with solving problems in response to one or more incidents Proactive problem management is concerned with identifying and solving problems and known errors before further incidents related to them can occur again. Proactive Problem Mgmt. includes: Information from other Process Owners Analysis of incident and problem data by the [Company] Incident Resolver Groups (Tier 2) Note: Suspicion or detection of a cause of one or more incidents by the Service Desk, resulting in a problem record being raised the desk may have resolved the incident but has not determined a definitive cause and suspects that it is likely to recur, so will raise a problem record to allow the underlying cause to be resolved. Alternatively, it may be immediately obvious from the outset that an incident, or incidents, has been caused by a major problem, so a problem record will be raised without delay Match findings with existing Problem Records Once the problem record is created in TxDOTNow, check if the problem can be attributed to already known Problems. If associated problem(s) exist, notify the initiator of the existing problem record Need to create new Problem Record? Determine if a new Problem Record needs to be created based on the review. If Yes, proceed to Create Problem Record If No, proceed to End [Company] Page 14 of 33

15 Step Description Create Problem Record Regardless of the detection method, all the relevant details of the problem must be recorded so that a full historic record exists. This must be date and time stamped to allow suitable control and escalation. It is difficult to be exact, as cases may vary, but typically this will include details such as: User details Service details Equipment details Date/time initially logged Initial Priority and categorization details Incident description Incident record numbers or other cross-reference Details of all diagnostic or attempted recovery actions taken IT Support (including Service Delivery Member with ITIL User access) has the capability to create a Problem Record in the TxDOTNow. All details updated in the TxDOTNow problem record fields Match Problem Record to past Incidents A cross-reference is made to the incident(s) which initiated the problem record and all relevant details are copied from the incident record(s) to the problem record. If applicable, in the Related Link section of TxDOTNow, select New button to include all Incidents attributable to the Problem. Proceed to Categorization and Prioritization End of Process [Company] Page 15 of 33

16 5.2 Problem Categorization and Prioritization Process Flow: Problem Categorization and Prioritization [COMPANY] NTT DATA Problem Manager [COMPANY] NTT DATA Incident Resolver Group(s) Service Desk Start Categorize Problem Prioritize Problem Assign Problem Record Does the Problem need an RCA? No Yes Proceed to Problem Investigation and Diagnosis Follow the RCA Process Process Title Categorization and Prioritization Process Owner Process Document Document No. PEG No. Problem Management Drawn By Mariel Tulipano PERSON ITSM > Problem Management Create Date 06/05/2015 Version Status Version# PAGE 1 REV. DESCRIPTION DATE BY 2 Renamed step to Categorize Problem/Included swim lane for NTT [COMPANY] DATA Incident Resolver Groups and Service Desk 03/11/2016 MT 3 Step Removed reference to CAP 01/06/2017 MT Final PROC TMPL00013_REV(11/19/2014,v0.1) [Company] Page 16 of 33

17 [ Process Description: Problem Categorization and Prioritization [Company] Page 17 of 33

18 [ Step Description Categorize Problem Problems are categorized by indicating the CI affected Prioritize Problem Currently, problem records reflect the prioritization within the associated Incident ticket. However; some problem records may not have an incident ticket, and the Problem Manager will then prioritize the ticket based on impact and urgency. Although problems are primarily prioritized based on incidents, review of the problem records may determine that the prioritization needs to be changed depending on the severity of the identified problems. Note: Refer to the Priority definitions located in the [Link] Assign Problem Record In TxDOTNow, review and analyze problem record(s) in order to assign record to the proper user or [Company] Incident Resolver Group. The record may be assigned to yourself, as well. The problem record is assigned to the [Company] Incident Resolver Group closely related to the issue at hand. When assigning a ticket to a [Company] Incident Resolver Group, validate the ticket state and change, if necessary. The states in TxDOTNow are as follows: New The initial state a ticket is in when a new ticket is created Work In Progress This state is used when a ticket is still active but not in a pending state. Pending Vendor State when the Resolver is waiting on action and/or information from the vendor. When using that state, be sure to enter any pertinent vendor information on the Vendor Information tab, i.e. Vendor Name, Vendor Ticket number, etc. Pending Business State when the Resolver is waiting on information from the business, including waiting for approval from TxDOT on the RCA submission Pending Change State when the Resolver is waiting on a change to occur Known Error This state identifies the problem cannot be resolved, because the issue has no fix, too costly or the fix is not warranted Cancelled State identifies a ticket that is no longer needed, Resolved This pertains to Problem tickets with RCAs. The problem has been fixed, but the RCA is still in the process of being finalized. Unknown errors will remain in resolved state until the known error is cleared, Closed Problem has been fixed and completed Does the Problem need an RCA? Determine if the Problem requires a Root Cause Analysis (RCA) to be completed. If Yes, proceed to Develop a draft RCA report If No, proceed to Problem Investigation and Diagnosis Note: Problem Manager is responsible for this step until the RCA Process has been approved. Refer to the [Link] to assist in determining whether an RCA is needed. The [Link] is located in the [Link] of the SMM Wiki on TxDOT O365. [Company] Page 18 of 33

19 [ Step Description Follow the RCA Process Follow the [Link] to draft a RCA report. Triggers of the [Company] TxDOT RCA are referenced in the [Link] Refer to the [Link] for details on submitting a RCA draft using the [Link] The [Link] is located in the template library of the SMM Wiki. The [Link] is located in the [Link] of the SMM Wiki on TxDOT O365. Proceed to Problem Investigation and Diagnosis End of Process [Company] Page 19 of 33

20 [ 5.3 Problem Investigation and Diagnosis Process Flow: Problem Investigation and Diagnosis [COMPANY] NTT DATA Incident Resolver Group(s) Service Desk Start Investigate the Problem and determine its root cause Follow the Change Management Process Yes Known Error record? No Identify possible resolutions for the Problem Will Problem be corrected? No Did Change Management correct issue? Yes Yes No Follow the Known Error Process Update the Problem Record Proceed to Major Problem Review, Closure and Reporting Confirm Problem resolved Yes Is Problem Resolved? No Process Title Investigation and Diagnosis Process Owner Process Document Document No. PEG No. Problem Management ITSM > Problem Management PROC Drawn By Mariel [COMPANY] Tulipano Create Date 06/05/2015 Version Status Final Version# 1 PAGE 1 REV. DESCRIPTION DATE BY 2 Step make activity box into a decision box/updated Swimlane role to NTT [COMPANY] DATA 03/11/2016 MT Incident Resolver Group(s) and Service Desk TMPL00013_REV(11/19/2014,v0.1) [Company] Page 20 of 33

21 [ Process Description: Problem Investigation and Diagnosis [Company] Page 21 of 33

22 [ Step Description Investigate the Problem and determine its root cause At this stage, an investigation should be conducted to try to diagnose the root cause of the problem the speed and nature of this investigation will vary depending upon the impact, severity and urgency of the problem but the appropriate level of resources and expertise should be applied to finding a resolution commensurate with the priority code allocated and the service target in place for that priority level. If appropriate, recreate the failure using a test-system to confirm that any assumptions made are correct Known Error record? During the incident investigation, determine if a new Known Error needs to be initiated. Note: A problem record is flagged as a Known Error if the incident cannot be resolved and a root cause and workaround needs to be documented. If Yes, proceed to Follow the Known Error Process If No, proceed to Identify possible resolutions for the Problem Follow the Known Error Process Follow the Known Error Process to document the root cause and a workaround. Known Errors help restore the failed services quicker. A workaround may be identified and added to the workaround field under the Closure Information tab to detect and help resolve any recurrences. When a workaround has been identified, review the record and determine if it needs to be reprioritized to ensure that the record receives appropriate priority. Update the Priority field in the TxDOTNow Problem Module. The [Link] is located in the [Link]of the SMM Wiki on TxDOT O365 Proceed to Update the Problem Record Identify possible resolutions for the Problem Research ways to solve the root cause of the Problem. Use appropriate tools to identify and diagnose the exact point of failure, including but not limited to: TxDOTNow Known Error Database (KEDB) (Located in the Problem Mgmt. module) TxDOTNow Knowledge Base Chronological analysis CMDB [Company] Page 22 of 33

23 [ Step Description Will Problem be corrected? Determine if the Problem will be corrected. If Yes, proceed to Follow the Change Management Process If No, proceed to Follow the Known Error Process Once a root cause has been found and a solution to remove it has been developed, it should be applied to resolve the problem. However, there may be some problems for which a business case for resolution cannot be justified (e.g. where the impact is limited but the cost of resolution would be extremely high). In those cases, ensure to document the problem record according with the related Known Error and / or Workaround Follow the Change Management Process If a change is required as part of the problem resolution, then invoke the [Link] to implement changes necessary for the incident resolution. The [Link] Process is located in the [Link] of the SMM Wiki on TxDOT O Did Change Management correct the issue? Update Problem Record If Yes, proceed to Update the Problem Record If No, proceed to Will Problem be corrected? Update the problem record with all relevant information and details, Also ensure that all other related documentation (RCA, CR) required has been completed. Include any information on the ticket that is relevant to the resolution of the problem. At this time, determine if other [Company] Incident Resolver Group(s) will benefit from a Knowledge Article. If so, check the Knowledge check-box in the Closure Information tab and add any pertinent information and follow the [Link]. The [Link] is located in the [Link] of the SMM Wiki on TxDOT O Is Problem Resolved? Once the record is updated, confirm that the problem is resolved Confirm Problem resolved If Yes, proceed to Confirm Problem resolved If No, proceed to Follow the Known Error Process Include any information on the ticket that is relevant to the resolution of the problem, including user confirmation. Proceed to Major Problem Review, Closure and Reporting. End of Process [Company] Page 23 of 33

24 [ 5.4 Major Problem Review, Closure and Reporting Process Flow: Major Problem Review, Closure, and Reporting NTT DATA Incident Resolver Group(s) [COMPANY] Close Problem Record Start Was the Problem a P1? No Yes NTT [COMPANY] DATA Problem Manager Perform Weekly Problem Management Reporting End Perform Major Problem Review Process Title Major Problem Review, Closure, and Reporting Process Owner Process Document Document No. PEG No. Problem Management Drawn By Mariel Tulipano ITSM > Problem Management Create Date Version Status 06/05/2015 Final PROC Version# 1 PAGE 1 REV. DESCRIPTION DATE BY TMPL00013_REV(11/19/2014,v0.1) [Company] Page 24 of 33

25 [ Process Description: Major Problem Review, Closure, and Reporting [Company] Page 25 of 33

26 [ Step Description Was the Problem a P1? If Yes, proceed to Perform Major Problem Review If No, proceed to Close the Problem Record Perform Major Problem Review Conduct formal review of RCA during weekly Problem Management meetings. Major Problem / RCA Review consists of: Verifying Problem was successfully solved Define and perform any required follow-up actions Assess what was done correctly or incorrectly Determine what could be done better in the future Determine how a recurrence of the Problem can be avoided Document any knowledge/lessons learned Check RCA for consistency, ensure that all Action Items are identified and Technical Team reports on lifecycle progress. The review team consists of the Service Delivery Managers, Operational Delivery Manager, and Technical Team(s). For further details on the completing the RCA, refer to the [Link] located in the [Link] of the SMM Wiki on TxDOT O Close Problem Record Check whether the record contains a full historical description of the activities required to solve the Problem. The Problem will then be ok to Close. When a final resolution has been applied, the problem record is formally closed. If a related incident record is found to be open, the Resolver will validate and close. A check is performed at this time to ensure that the record contains a full historical description of all events and if not, the record should be updated. Update the KEDB with any new details Perform Weekly Problem Management Reporting On a weekly basis gather data and provide the Problem Mgmt. Reports to [Company] and TxDOT Leadership teams during the Daily Ops meeting. The following reports are created: Problem Trending RCA List Problem Daily Data Upload completed Problem Mgmt. Reports to the [Link] Proceed to End [Company] Page 26 of 33

27 [ Step Description End of Process [Company] Page 27 of 33

28 6 RACI A RACI matrix, describes the participation by various roles in completing tasks or deliverables for a specific process. R - Responsible Those who do the work to achieve a task. There is typically one role with a participation type of Responsible. A - Accountable Those who are ultimately accountable for the correct and thorough completion of the deliverable or task, and the one to whom Responsible is accountable. Typically, the Process Owner is Accountable for a process, and there must be only one Accountable specified for each task or deliverable. C - Consulted Those who are not directly involved in a process but provide inputs and whose opinions are sought. I - Informed Those who receive outputs from a process or are kept up-to-date on progress, often only on completion of the task or deliverable. [Company] Page 28 of 33 (TMPL00002_REV(12/09/2014,v0.5)

29 Process Step Responsibility [Company] Problem Manager [Company] Incident Resolver Group Service Desk [Company] Contract Management 5.1 Detection and Logging Problem(s) detected A/R/C R/C/I R/C/I Match findings with existing Problem Records A R/I R/I Need to Create Problem Record? A R/I R/I Create Problem Record A R/I R/I Match Problem Record to past Incidents A/R R/I R/I 5.2 Categorization and Prioritization Categorize Problem A/R R/I R/I Prioritize Problem A/R R/I R/I Assign Problem Record A R R Does the Problem need an RCA? A R I/C Follow RCA Process A R I/C 5.3 Investigation and Diagnoses Investigate the Problem and determine root cause A R Known Error Record? A R I/R [Company] Page 29 of 33 (TMPL00002_REV(12/09/2014,v0.5)

30 Process Step Responsibility [Company] Problem Manager [Company] Incident Resolver Group Service Desk [Company] Contract Management Follow the Known Error Process A R I/R Identify possible resolutions for the Problem I A/R Will Problem be corrected? A/R R/C Follow the Change Management Process I A/R Did Change Management correct issue? I A/R Update the Problem Record A/R R Is Problem Resolved? A R I 5.4 Major Problem Review, Closure, and Reporting Was the Problem a P1? A R I/C Perform Major Problem Review A/R R I Close Problem Record A R/I I Perform Weekly Problem Management Reporting A/R I I [Company] Page 30 of 33 (TMPL00002_REV(12/09/2014,v0.5)

31 7 Reporting and Metrics Frequent and regular analysis of incident and problem data should be performed to identify any trends as they become discernible. The following reporting is currently available: Top Ten CI s The [Link] reports helps to identify the configuration items that have the most incidents open. This report is produced weekly and monthly. By identifying these top CI s we can identify the recurring incidents and its underlining causes. Reduce Age of Problem Tickets Report Problem Manager ensures that a weekly report is run by delivery team and by priority. The problem manager and Overall Delivery Manager review this report weekly. Metrics reports identified above are maintained on the [Link]. The [Link] is used to identify, log, and track the various Problem Management Reports. The [Link] is located on the [Link]. KPI s and reports as identified by the operations manager are reported during the Daily Ops meetings. The [Link] is used to identify, log and track the Problem Management KPI s with calculation details and is located in the [Link] in the [Link] Note: Through Continual Service Improvement (CSI), KPI s are subject to change as this process matures. 8 Policy All policies pertaining to this process are located on the [Link] 9 Key Terms/Acronyms and Definitions Term Known Error KEDB RCA Problem Incident Definition A Known Error is a problem that has a documented root cause and a workaround. Known errors are created and managed throughout their lifecycle by problem management. Known errors may also be identified by development or suppliers. Known Error Database is a database containing all known error records. This database is created by problem management and used by incident and problem management. The known error database is currently the TxDOTNow Problem Mgmt. module Root Cause Analysis is an activity that identifies the root cause of an incident or problem. Root cause analysis typically concentrates on IT infrastructure failures. A problem is a cause of one or more incidents, break/fix, or issues. The cause is not usually known at the time a problem record is created, and the problem management process is responsible for further investigation. An incident is an unplanned interruption to an IT service or reduction in the quality of an IT service. Failure of a configuration item that has not yet affected service is also an incident for example, failure of one disk from a mirror set. Refer to the [Link] for any related terms/acronyms and abbreviations [Company] Page 31 of 33

32 10 Process(es) Impacted Process Name [Link] Process is located in the [Link] of the SMM Wiki on TxDOT O365. [Link] is located in the [Link] of the SMM Wiki on TxDOT O365 [Link] is located in the [Link] of the SMM Wiki on TxDOT O365 [Link] Process is located in the [Link] of the SMM Wiki on TxDOT O365 [Link] Process is located in the [Link] of the SMM Wiki on TxDOT O365 Impact The Incident Management process restores normal service operations to users as quickly as possible while minimizing the adverse impact on business operations. This ensures that the best, possible levels of service quality and availability are maintained. If Problem management develops a work-around that addresses the incident without solving the root cause, then the incident becomes a Known Error. If Problem Management establishes the root cause and a resolution, they need to alert Incident Management so the Known Error tickets can benefit from the resolution and have their status shifted to closed once the corrective work is completed. TxDOT requires a consolidated RCA form with an [Company] process taking into the consideration the TxDOT process as noted in Section 4.1 Subsection G of the Master Services Agreement. Such process will also take into consideration the [Company] Problem Analysis responsibilities as stated in section 7.3 of the MSA. A Known Error is a problem that has a documented root cause and a workaround. Even if there is no workaround identified it can be recorded within the KEDB. This is used for informational purposes at the Service Desk. A Known Error record contains the status, root cause, workaround, and associated problem record along with the related incident records. Change Management oversees and manages the successful introduction of changes into the TxDOT IT system or environment. A change is anything that alters the status of a Configuration Item (CI). This typically includes anything that adds to, deletes from, or modifies the production IT environment. The definition of a change is the addition, modification, or removal of approved, supported, or baseline hardware, network, software or application. If a change is needed to correct the Known Error, a CR must be filed and handled through the Change Management. Once the change is completed, the Known Error is closed. The purpose of the Knowledge Management Process is to share perspectives, ideas, experience and information. This process also ensures that knowledge is available in the right place at the right time to enable informed decisions and improve efficiency. Knowledge management provides value to all stages of the service lifecycle by providing secure and controlled access to the knowledge, information and data that is needed to manage and deliver services. [Company] Page 32 of 33

33 11 Appendix N/A End of Document [Company] Page 33 of 33