RMS System Administrator Guide

SCB ITIL Problem Management User Guide Ver 2.0

Issue / Amendment Record

Project ID

Project NameSCB ITIL Problem Management

Document StatusFinal - Release

VersionDateAuthorReviewerApproverVersion Summary

1.014 Mar 2007WiproSCB Project teamFinal Draft of the SCB ITIL Problem Management User Guide.

1.112 Apr 2007SCB draft comments while pending revision on 20 AprUpdate Preface to summarise enhancement

Replace screen print with text box to reduced size of document

1.209 May 2007WiproReplace content with simpler text. Change screenshots and information in accordance with the updated application.

1.2.123 May 2007Wipro ChandranSCB Project teamInclude the Luck Koong comments and modified the error messages.

2.016 JunLuck KoongAdd in Known Error status Approved Content on page 75

Release for publication

2.129 FebLuck KoongFeedback from users since rollout in end Jun 07. Clarification on the below:

Investigator drivers value

Status of problem record

Reason code for root cause not found- added value via REM-08-0003

TABLE OF CONTENTS

71.INTRODUCTION

71.1Objective of this Guide

71.2Purpose of Enhancement

81.3Enhancements Made An Overview

81.3.1Incident Management

91.3.2Problem Management

111.4Login Details

132.INCIDENT MANAGEMENT

142.1Incident Management Console

162.2Searches for Incident Ticket

172.3Incident Matching

172.4Ownership Table

182.5Recurring Incidents

192.6Email Notifications to User

213.INCIDENT MATCHING

243.1Shared Search Criteria

243.2Incident Search

253.3Problem Search

263.4Known Error Search

273.5View Incident/ Problem/Known Error

273.6Add Incident Problem Relationship

283.7Remove Incident Problem Relationship

283.8Create Problem Ticket

283.9Important Exceptions

334.PROBLEM MANAGEMENT

344.1Problem Management Console

354.2Recording a Problem

354.2.1Create Problem Ticket

384.2.2Modify Problem Ticket

404.2.2.1Root Cause Analysis (RCA) Tab

404.2.2.2Solutioning Tab

464.2.2.3Relationships Tab

494.2.2.4Important Exceptions

544.3Search Problem Ticket

554.4Problem Status

574.5Email Notifications to Users

655.KNOWN ERROR

655.1.Recording a Known Error

685.2.Approval of Known Error

685.2.1.Known Error Approval Console

695.3.Publishing Known Error

715.4.Retirement of Known Error

745.5.Important Exceptions

755.6.Known Error Status

775.7.Email Notifications to Users

775.7.1.Known Error Notifications For Publish

795.7.2.Known Error Notification for Retirement

805.7.3.Known Error Notification for Cancel

PREFACESCB ITIL Problem Management User Guide describes the enhancements in the new application. It is using the BMC Remedy Action Request System (AR System) as the development platform.

It enhances the process of Incident Management with the belowa) Rename of Module Name in Remedy and extent scope of usage

Problem Management -> Incident Management + new field to integrate to Problem module

RCA (Root Cause Analysis) -> Problem Management + extended scope of usage to support teams

a) Automated matching

Weekly identification of recurring incidents based on partial predefined criteria that ties in with owner group combination for impacted and security incidents.b) Automated notification acting as reminder

with escalation to line managers if no action after a weekc) Email sends to end user when Resumed? is having value Yes instead of when ticket is in Resolved status. If Resumed? is No, email will be sent when ticket is in Resolved statusd) Effective integration between Incident, Problem, Known error and Change ModulesIt enhances the process of Problem Management with the below:

b) Allowing the user to create a Problem Ticket.

c) Allowing the users to resolve & close Problem Tickets.

d) Ownership Repository

Allows Service/Component owner to configure threshold/parameters for identification of potential recurrence so as to facilitate auto-email notification

Define Owner group based on Service, Component, Domain and Affected Countrye) Known error - New sub-module in Problem management

Allowing the users to create Known Errors with approval process

Allowing the users to Approve, publish and retire a Known Error to integrate with KMR (Knowledge Management in Remedy) to improve management of KMR articles

f) Incident Matching

Online identification of potential recurring incidents with an extended scope which allow grouping of service request and non-impacted incidents

TARGET AUDIENCE

This guide is for the users of the SCB ITIL Problem Management application. They include:

a) Incident Management Team, who records Incidents, modifies Incidents, resolves and closes the Incidents.

b) Problem Management Team, who records Problems, modifies Problems, undertakes Problem Control (Root Cause Analysis) and Error Control (Provide solution) activities.

1. INTRODUCTION

This section provides overview of the SCB ITIL Problem Management. The following topics are discussed:

1. Objective of this guide2. Purpose of Enhancement3. Enhancements Made A Brief Overview1.1 Objective of this Guide

This guide explains the functions of the system in brief and focuses prominently on using the system from a users point of view. This guide explains actions that the user can perform during the lifecycle of Incident Management, Problem Management . That includes Known Error Approval, and Incident Matching modules. This system is an enhancement of the existing Problem Management and RCA (Root Cause Analysis) module. Note that this User Guide covers only the enhancements incorporated in the existing system. The Incident Management User Guide should be referred for existing features.1.2 Purpose of Enhancement

SCB felt the need to align their existing Problem Management and RCA modules with ITIL Best Practices Model. This was initiated to overcome the shortcomings in the existing system. Some of the challenges faced were:

The earlier system was used to log both Incident Tickets as well as Problem Management Tickets. The number of open tickets in Remedy has thus an imprecise meaning, since some tickets refer to a situation where service has not yet been resumed and others refer to problems waiting for a permanent fix. This mainly affects Sev 3 incidents and is the source of most complaint. There was a scope to streamline both these functionalities into two separate modules that were well integrated and compliant to ITIL framework.

The earlier system did not have clearly defined inter-relationships between Incident Management, Problem Management, and Change Management. Also there was no direct relationship between SCB Change Management and SCB Problem Management. This association was only possible if a Change Request was recorded under the Problem Management form. There was lack of a pro-active method for identifying potential Problem and recurring Incident Tickets.

SCBs RCA module was primarily used for post-mortems of SCB Problem Tickets.1.3 Enhancements Made An Overview

The new version consists of independent modules for Incident Management and Problem Management as per the ITIL framework. A brief explanation for Incident Management and Problem Management process is presented with flowcharts where the Roles within SCB are shown at the left-hand side of chart.

1.3.1 Incident Management

The Incident Management (IM) module is basically a modified version of Problem Management module of the earlier version. (Please refer incident management user guide for more information on the IM process)

Incident Management module is used for logging Incident Tickets and effectively finding out the related incidents for creation of a Problem Ticket.

The individual Incidents will be worked on separately to provide a resolution to recover each service to allow business to continue.

Goal of Incident Management is to restore the normal service operation as quickly as possible with minimum disruption to the business and thus ensuring that the best achievable levels of availability and service are maintained.

1.3.2 Problem Management

The Problem Management module is basically the modified version of RCA (Root Cause Analysis) module of the earlier version. The Problem Management module has been designed to undertake the task of Problem Control (Root Cause Analysis) and Error Control (Finding and Build Solution).

It is designed to identify potential recurring Incidents using Incident Matching. Incident Matching is grouping Incidents with similar parameters. It will help to track finding of permanent solution for problems where root causes are found. It will allow the Owner Group and ITSC Problem Management group to create a problem record(s) to undertake the RCA. It allows Problem Ticket to be associated with more than one Incident. A Known Error sub-module of the Problem Management module facilitates the capturing of the workaround details. A Known Error can be created after finding out the workaround details for the Problem record.

Error Control covers the processes involved in progressing Known Errors until they are eliminated by the successful implementation of a change under the control of the Change Management process. The objective of error control is to be aware of errors, finding of solution and to eliminate them when solution is feasible and cost-justifiable.

Goal of Problem Management is to minimize the adverse effect of incidents and problems caused by errors in the infrastructure on the business and to proactively prevent the occurrence of incidents, problems and errors.

Problem Management process is required:

To resolve problems quickly and effectively. To ensure resources are prioritized to resolve problems in the most appropriate order based on business need. To proactively identify and resolve problems and Known Errors thus minimizing incident occurrences. To improve the productivity of support staff. To provide relevant management information.Responsibilities of Problem Management process includes:

Problem Control: Problem control includes:

Problem identification & recording Problem classification Problem investigation & diagnosis Error Control: Error control includes: Error identification and recording Error assessment Recording error resolution Error closure Monitoring resolution progress

Assistance with the handling of major incidents Proactive prevention of problems, it includes:

Trend analysis Targeting support action Providing information to the organization Obtaining management information from problem data Completing major problem reviewsBenefits of Problem Management process are:

Improved IT services Incident volume reduction Permanent solutions Improved organizational learning Improved Service Desk first time fix rate1.4 Login DetailsLogin details can be found in Incident Management user guide.

If the User Name & Password combination is correct, the User will be logged in and taken to a Home Page that will have a link to go to Problem Management Console.

User can also access the Problem Management Console using the Object List. Click the [OPEN] button to open the Object List.

Figure 1.4.1 Search Object List

Go to the Find tab in the Object List. In the Search what keywords field type Problem Management Console. Refer Figure 1.4.1 Click on the [FIND] button. A list of objects will be displayed in the table. Select Problem Management Console record and click on OPEN button.

This will open the Problem Management Console as shown in Figure 4.1 on page 34Search Remedy Form:

User can access the forms by mentioning the alias name in the Search What Keyword field of the object list for the following forms listed in the table 1.1.

Search For Form (from Object List)Search For (in Search what Keyword? Field)Form Name in Earlier Version

Problem Management ConsoleProblem Management ConsoleRCA Console

Incident Management ConsoleIncident Management Console Problem Management

Problem Management Problem ManagementRCA Record form

Incident Management Incident ManagementSCB-ProblemManagement

Table 1.1: Details for Searching Forms from Object List2. INCIDENT MANAGEMENTThis section provides overview of the Incident Management Console. The following topics are discussed:

Incident Management Console Recording an Incident Search for Incident Ticket Incident Matching Ownership Table Incident Status Recurring Incidents Email Notifications to UserAn Incident is any event which is not part of the standard operation of a service which causes, or may cause, an interruption to, or a reduction in, the quality of that service. The primary goal of the Incident Management process is to restore normal service operation as quickly as possible and to minimize the adverse impact on business operations, thus ensuring that the best possible levels of service quality and availability are maintained.

Access Permission: Following Table 2.1 lists the users who can access the Incident Management Console to record an Incident, modify an Incident, searching for an Incident, accessing an Incident Matching form.

Form NameActionAccess Permission

Incident Management ConsoleUse Incident Management Console button given in the Problem Management Console.Same as present in the existing system.

e) For viewing by all support teams and default with tickets assigned to assigned group

Incident Management form (New Mode)Click on the Create Ticket button in Incident management console for creating an Incident Ticket.Same as present in the existing system.

Only Tier 1 Service Desk agent can create ticket.

Others can create ticket via Log a Problem in One-stop shop

Incident Management form (Modify Mode)Double click on the Incident records displayed in the table of Incident Management Console.Same as present in the existing system.

Incident management form (Search Mode)Click on the Search Ticket button for searching an Incident Ticket.Same as present in the existing system.

All Remedy users can do a search

Incident Matching FormClick on the Incident Matching button.All Remedy users can access the Incident Matching form.

Incident Matching > Add Relationship ButtonClick on the Add Relationship button in Incident Matching form for relating Incident - Problem Ticket.Users belonging to the Problem Management Team Tier 3 defined in Ownership Table can relate the Incident - Problem Ticket from Incident matching form. For Tier 3 support groups, only incident with value of Service, Component, Domain and Affected Country matching the combination defined in Ownership table can successfully create a problem

Incident Matching > Remove Relationship ButtonClick on the Remove Relationship button in Incident Matching form for removing a relationship between Incident - Problem Ticket.Users belonging to the Problem Management Team Tier 3 defined in Ownership Table can remove relationship of Incident from Problem Ticket from Incident matching form. For Tier 3 support group, only incident belonging to problem created by them can perform such function

Incident Matching form > Create a Problem Ticket Button.Click on the Create a Problem Record button in Incident Matching form for creating a problem Ticket.Users belonging to the Problem Management Team and Tier 3 defined in Ownership Table can access the Problem Management form for creating a problem Ticket from Incident matching form.

Table 2.1 Access Permission for Incident Management

2.1 Incident Management Console

The Incident Management console is previously known as Service Console. Please refer to Incident Management for existing functionalities. The additional functionalities provided to integrate with problem management are: A button to link to Incident Matching form. Option to see All Incident Tickets.

Figure 2.1 Modifying an Incident Ticket Resolution Details Tab

As a part of enhancement, following fields have been added in the Resolution Details tab of the Incident Management form. Refer Fig 2.1. This field is dependent on the Service+ and/or Component+ field values. The menu value can be defined in the Owner Group associated table.

As a part of enhancement, following fields have been added in the Resolution Details tab of the Incident Management form. Refer Fig 2.6

Root Cause Code - This field is used for populating value from Problem Management form Root Cause code Value.

Root Drill down One - This is field is used for populating value from Problem Management form Root Drill down One value. Root Drill down Two - This is field is used for populating value from Problem Management form Root Drill down Two value.

Failed Service - This is field is used for populating value from Problem Management form Failed Service value. Failed Component - This is field is used for populating value from Problem Management form Failed Component value.When the value for the fields mentioned above in the Problem Management form changes, the same value is entered in the corresponding fields of the Incident Management form. Incident ticket Suspension: Incident tickets can be suspended by clicking the Suspended button or selecting the Status value as suspended. Whenever incident ticket is suspended, Suspended Code field is enabled and user has to select the value from suspended code menu. As a part of enhancement, some of the existing values for Suspended Code field in Incident Management form have been removed and new field value, Hardware Delivery have been added as a Suspended Code. Following values have been removed from the Suspended Code field:

Waiting for vendor Waiting for IS

Temporary Solution Change2.2 Searches for Incident Ticket

To search for an Incident Ticket, the user needs to click Search Ticket button. This will open a Search Incident Management form as in figure 2.7. No functional changes.

Figure 2.2 Search mode of Incident ManagementThe user can enter required search criteria and click on Search button. This will open the Search Result window consists of two panes. First pane displays the Incident Ticket records are search results

Second pane displays the details of the selected Incident Ticket.The user can perform the Incident modification on the displayed record in this pane. The user can double click on the desired record to open the details in a new window.2.3 Incident Matching

The user can access the Incident Matching form from Incident Management form by clicking on the Incident Matching button. Refer figure 2.4. The user can create a Problem Ticket from Incident Matching module. For more details refer Chapter 3 Incident Matching.

2.4 Ownership Table

Owner group table is a new form to identify the incidents ownership based on the Service, Component, Domain and Affected country. Ownership form as shown in figure 2.5 helps the user to find the owner for incidents to create a potential Problem Management.

Figure 2.3 Owner Group formAccess Permission: Following table shows list of users who can access the Ownership form.

Form NameActionAccess Permission

Ownership FormAccess the form the Object list.Owner and Data Admin can access this form. Data Admin can create modify and delete the Ownership data where as Owner can only modify his own data like Threshold for Recurring incidents and Notification required, Owner Group email and Problem Type fields data.

Table 2.4 Access Permission for Ownership form

The Problem type field values can be obtained from the Ownership table which is based on the Service and Component of the particular owner group that will be used while creating the Incident Ticket from the Incident Management form. Adding a Problem Type is the responsibility of each Owner for their services and components.

2.5 Recurring Incidents

The Recurring Incident process is used to group the recurring incident every week based on the defined criteria that will be sent to the Owner group of the Incident Tickets. This process will help in identifying the potential Problem. Following are the two notifications that are sent to the Owner Group:

Notification 1

Notification Event: In this notification event, the recurring incidents are grouped together based on the defined criteria for all the status. An email is sent every week to the Owner Group.

Notification Message: Action to be performed: The user can double click on attachment that is sent along with the mail to open the Incident Matching details in the corresponding form. The user has to provide a valid user name and password to enter into the system and access the Incident Matching details. The user can search for the incident Tickets mentioned in the email to can create a Problem Ticket. Notification 2

Notification Event: In this notification event, the grouping of the incident Ticket is performed based on the Assignment Group for the Open status and an email will be send every week to the Assignment Group.

Notification Message:

Action to be performed: The user can double click on attachment that is sent along with the mail to open the Incident Matching details in the corresponding form. The user has to provide a valid user name and password to enter into the system and access the Incident Matching details. The user can search for the incident Tickets mentioned in the email to can create a Problem Ticket.2.6 Email Notifications to User

There are few notifications which get triggered, based on the conditions as mentioned below:

Notification 1

Notification Event: In this notification event, user is notified if the Suspended Date of the Incident Ticket passes the current date. An email is sent to the Assignment Group of the Incident Ticket on the weekly basis.

Notification Message:

Action to be performed: The user can double click on attachment that is sent along with the mail to open the Incident Matching details in the corresponding form. The user has to provide a valid user name and password to enter into the system and access the Incident Matching details. The user can search for the incident Tickets mentioned in the email. Notification 2

Notification Event: In this notification event, user is notified about the Incident Tickets suspension date. The notification is sent one day prior to the Suspended Date of the Incident Ticket. An email is sent to the Assignee, Copy to Group admin on daily (Non-Business hours) basis.

Notification Message:

Action to be performed: The user can double click on attachment that is sent along with the mail to open the Incident Matching details in the corresponding form. The user has to provide a valid user name and password to enter into the system and access the Incident Matching details. The user can search for the incident Tickets mentioned in the email. Notification 3

Notification Event: In this notification event, user will get notified if the Incident Ticket is not Resolved after the Suspended Date of the Incident Ticket passes the current date by one week. An email will be send automatically to the Superior of admin and ITSC Service Support on daily (Non business hours) basis. Notification Message:

Action to be performed: The user can double click on attachment that is sent along with the mail to open the Incident Matching details in the corresponding form. The user has to provide a valid user name and password to enter into the system and access the Incident Matching details. The user can search for the incident Tickets mentioned in the email. Notification 4 Notification Event: In this notification event, the affected user will be notified if the Incident Ticket Status is Resolved AND Resume field is selected as No. This notification is also sent when the Resume field is set as Yes irrespective of the status of the Incident Ticket. An email is sent to the affected user in either of the cases. Notification Message: Subject: Incident PNKL0000329180 Service Resumed

Dear Sir / Mdm,

We are pleased to inform you that your Service as reported in the following Incident Ticket has been Resumed:

Incident Ticket Number: PNKL00003291890

Description: Unable to send emails from MY Damansara branch

Handled by: MY-OSV-MESINIAGA S.B.

More details with regards to your incident are available at the ITSC One Stop Shop (OSS) for your reference.

Please provide your ONE CLICK feedback.

You are satisfied with the service you have received?(1) Strongly Agree (2) Agree (3) Disagree (4) Strongly Disagree *PLEASE DO NOT REPLY TO THIS SYSTEM GENERATED MAIL

3. INCIDENT MATCHINGThis section provides overview of the Incident Matching form. The following topics are discussed:

Shared Search (Combined Search for Incident, Problem and Known Error Tickets)

Incident Search Problem Search

Known Error Search

View Incident/Problem/Known Error Tickets

Add Incident - Problem Relationship

Remove Incident - Problem Relationship

Create a Problem Record

Important Exception HandlingThe Incident Matching form will serve as a great source for the support team member to search and identify any recurring incident/potential problem. From the Incident Matching form, it will provide the avenue for creating a problem record that warrant further investigation. Incident Matching form provides the sorting of incidents based on predefined sort order and user-defined relevant criteria for identifying the recurring incidents. The Incident Matching form can be accessed from:

Problem Management Console

Incident Management FormAccess Permission: Following table shows list of users who can access Incident Matching.

Form NameActionAccess Permission

Incident Matching FormClick on the Incident Matching button from Problem Management Console/Incident Management form.All the users present in the system can access the Incident Matching form.

Incident Matching Form > View Select the Incident/Problem/Known Error Ticket and click on View buttonAll the users present in the system can view the Incident Matching form.

Incident Matching > Add RelationshipClick on the Add Relationship button in Incident Matching form for relating Incident - Problem Ticket.Users belonging to the Problem Management Team and Tier 3 can relate the Incident - Problem Ticket from Incident matching form.

Incident Matching > Remove RelationshipClick on the Remove Relationship button in Incident Matching form for removing a relationship between Incidents - Problem Ticket.Users belonging to the Problem Management Team and Tier 3 can remove relationship between Incidents - Problem Ticket from Incident matching form.

Incident Matching form > Create a Problem Ticket.Click on the Create a Problem Record button in Incident Matching form for creating a problem Ticket.Users belonging to the Problem Management Team and Tier 3 can access the Problem Management form for creating a problem Ticket from Incident matching form.

Table 3.1 Access Permission for Incident Matching form

To match Incidents the user needs to click on the Incident Matching button, refer figure 2.6. It has two sections. Section in the top has tabs for Search functionalities while the section in the bottom has tabs that shows matching results. It has tabs for:

Figure 3.1 Incident Matching Shared Search Criteria Tab Incident Found Tab: It shows the details of all the Incidents, matching the specified search criteria. Also, the number of Incident Tickets that has been found is displayed in the Incident Found field.

Problem Found Tab: It shows the details of all the Problem Investigation, matching the specified search criteria. Also, the number of Problem Tickets that has been found is displayed in the Problem Found field.

Known Error Found Tab: It shows the details of all the Known Errors, matching the specified search criteria. Also, the number of Known Error Tickets that has been found is displayed in the Known Error Found field.

To perform search operation, the user needs to specify search criteria and select any checkbox and click on Search button. The result of the search is displayed in the tables in the tabs as discussed above. Clicking on Clear button will clear the fields. Details of Incident Matching tabs are discussed in the following section.3.1 Shared Search Criteria Shared Search Criteria is a default tab, which is displayed when the Incident Matching form is opened. It is meant for performing search operation in combination for Incident, Problem and Known Error Tickets.

In Shared Search Criteria tab, Component field is mandatory and Service field is mandatory only when Component field value is Application S/W for searching. The Shared Search should be performed in the following way:

User needs to define search criteria fields value provided in Shared Search tab Select the Start Occurrence Date, End Occurrence Date values from the Incident Search tab

Check the check boxes for Incident, Problem and/or Known Error as provided in Figure 3.1. Clicking on the Search button will perform the search operation. Incident Tickets are searched based on the specified date provided in start Occurrence Date and End Occurrence Date field. Based on the values provided by the user the search results are displayed in Incident Found, Problem Found and Known Error Found Tab.

3.2 Incident Search

After opening the Incident Matching form, the user needs to click on Incident Search tab. It is meant for performing search operation on recurring Incident Tickets. Start Occurrence Date and End Occurrence Date are the mandatory fields in the Incident Search tab. The Incident Search should be performed in the following way:

The user needs to define search criteria field values provided in Shared Search Criteria tab and Incident Search tab Check the checkbox for Incident only as shown in figure 3.2. Clicking on the Search button will perform the search operation. Based on the values provided by the user search results are displayed in Incident Found tab.

Figure 3.2 Incident Matching Incident Search Tab

Note:

Cancelled incident ticket is not considered for searching incidents. Duplicate Incident ticket is not considered for searching incidents.

Child Incident ticket is not considered for searching incidents.

3.3 Problem SearchAfter opening the Incident Matching form, the user needs to click on Problem Search tab. It is meant for performing search operation for potential problem Tickets. The Problem ticket can be searched as follows: The user needs to define search criteria fields value as provided in Shared Search Criteria tab and Problem Search tab Select the Problem checkbox. Click on the Search button. Results will be displayed based on the search criteria in the table under the Problem Found tab.

Figure 3.3 Incident Matching Problem Search Tab3.4 Known Error Search

After opening the Incident Matching form, the user needs to click on Known Error Search tab. It is meant for performing search operation for Known Error Tickets. The Known Error Search can be searched as follows: The user needs to define search criteria fields value provided in Shared Search Criteria tab and Known Error Search tab.

Check the checkbox for Known Error only as shown in figure 3.4. Clicking the Search button will perform the search operation. Based on the values provided by the user, search results are displayed in Known Error Found tab.3.5 View Incident/ Problem/Known Error

To view an Incident or a Problem or a Known Error Ticket, the user needs to select the required Ticket and click on View button. This will show the details for the selected record from the respective table.

Figure 3.4 Incident Matching Known Error Search Tab

3.6 Add Incident Problem Relationship

To relate an Incident to a Problem: Select one or more Incident tickets from the search result in the Incident Found tab by selecting the Select value in the selection column. Select a problem ticket from the search result displayed in Problem Found tab to be related to the selected Incident tickets. OR User can provide the problem number in the Selected Problem# field.

Click on Add Relationship button to add this Incident-Problem relationship. For details adding Incident- Problem relationship refer to flowchart in section 4.2.2.2. Solutioning Tab of chapter 4- Problem Management.3.7 Remove Incident Problem Relationship

To remove the relationship between Incidents and Problem:

Select the Incident ticket from the search result in the Incident Found tab for which the Incident-Problem relationship is to be removed. User can also select multiple incidents by selecting the value in Selection column for removing relationship

Click Remove Relationship button. This will remove the Incident-Problem relationship for the selected Incident ticket. 3.8 Create Problem Ticket

To create a problem ticket: Select one or more Incident tickets from the selection column for which new Problem ticket is to be created.

Click on Create Problem Record button. This will open the window for creating the new problem ticket. For details about creating a Problem Ticket, refer to the section 4.2.1. Create Problem Ticket of Chapter 4 Problem Management. The selected incident ticket will be related with the newly created problem Ticket.3.9 Important ExceptionsThere are some special cases where the user will be alerted error messages with reference to some invalid usage of the forms/modules in the system. These cases called exceptions have been discussed in the further sections.Every time an exception (or an error condition) occurs, a prompt window will be displayed that describes the nature of the error. Click on the OK button on the prompt window and proceed accordingly. Note on clicking the OK button the user will be returned to the original screen on which the error occurred. Exception 1 Component Field is BlankWhen searching for records in the Incident Matching form it is mandatory to select a value from the Component field drop-down list. An error message is displayed in a prompt window when the user clicks on Search button without selecting the value for Component field.

Exception 2 Service Field is BlankIf the selected Component value is Application S/W, the Service field will be highlighted in BOLD. This indicates that Service field is mandatory field. An error message is displayed in a prompt window when the user clicks on Search button without selecting the value for Service field.

Exception 3 Search Option Not SelectedAfter entering the mandatory search criteria, the user must select the Search Option from the checkboxes provided. If neither of these checkboxes is ticked and Search button is clicked, an error message is prompted informing the user to select Search Option.

Exception 4 Incident Ticket Already Related to a Problem TicketIf the Incident Ticket is already related to a Problem Ticket and the user tries to associate it again with the same Problem Ticket then exception is thrown and an error message is displayed in the prompt window.

Exception 5 Cannot Relate Incident Ticket to a Cancelled Problem TicketIf the Problem Ticket has Cancelled status then the user cannot relate an Incident Ticket with this Problem Ticket. If the user attempts to do so an error message is displayed in the prompt window.

Exception 6 Status From Value Not SelectedIt is mandatory to select a value from the Status From field before changing the status of a Ticket. The user should make sure that the Status From field has a relevant value selected before changing the Status To field. An error message is prompted if the above is not followed correctly.

Exception 7 Incorrect Hierarchy of Status From & Status To FieldsWhen changing the status of a Ticket make sure that the order of the Status From and Status To fields is correct. The system will prompt an error message if the status change of incorrect order is attempted. For e.g. the user cannot change the Status To field to Cancelled if the Status From field is Resolved. Exception 8 Empty Occurrence Date Fields An error is prompted when the user tries to search for Incident Matching records without specifying the Start Occurrence Date and End Occurrence Date.

Exception 9 Status From Field Not Selected During Problem SearchThis error message is displayed when user select the value for Status To field without specifying the value for Status From field while performing the Problem search.

Exception 10 Incorrect Order of Values in Status From & Status To FieldsWhen performing a Problem search it is important to specify the Status From and Status To fields in the correct order. An error message is displayed when user selects the value for Status From field which is greater than the value selected for Status To field.

Exception 11 Un-relating Non-Related Incident & Problem TicketsIt is not possible to un-relate an Incident Ticket with a Problem Ticket if they both are not related. In case this is attempted an error message is displayed in the prompt window.

Exception 12 Problem Ticket Related to a Single Incident Ticket ErrorIn some cases the Problem Ticket may be related to only a single Incident Ticket. It is not possible to un-relate such Problem and Incident Tickets. An error message is displayed when the user tries to un-relate the Problem Ticket, which is related to only one Incident Ticket.

Exception 13 Start Occurrence Date Greater than End Occurrence DateAn error is reported when the user specifies a Start Occurrence Date that is greater than the End Occurrence Date when performing an Incident search.

Exception 14 Assignment Group field contains invalid valueAn error is reported when the user enters invalid value in Assignment group field and press Search button

Exception 15 Service field contains invalid valueAn error is reported when the user enters invalid value in Service field and press Search button

Exception 16 Component field contains invalid valueAn error is reported when the user enters invalid value in Component field and press Search button

4. PROBLEM MANAGEMENT

This section provides overview of the Problem Management Console. The following topics are discussed:

Recording a Problem

Search for Problem Ticket

Known Error

Important Exception Handling

Problem Status Email Notifications to UserThe main goals of Problem Management are to minimize the adverse impact of Incidents and Problems on the business that is caused by errors within the IT infrastructure and to prevent recurrence of Incidents related to these errors. To achieve these goals, Problem Management seeks to get to the root cause of Incidents and initiate actions to improve or correct the problematic situation.

Access Permission: Following table shows list of users who can access the Problem Management Console to record a Problem, Modify a Problem, Search for Problem Tickets, access Incident Matching form. Only PM-PM# and PM-Tier3# level users are allowed access to this feature.Form NameActionAccess Permission

Problem Management ConsoleOpen the Problem Management Console from the Object List.Permission for accessing the Problem Management Console is same as present in the existing system.

Problem Management form (New)Click on the Create Ticket button for creating a problem Ticket.Users belonging to ITSC Problem Management group and Tier3- Global Support Staff can create a Problem Ticket.

Problem Management form (Modify)Double click on the Problem records displayed in the table of Problem Management Console.Problem Owner group members have rights to modify the problem ticket and other members can view the problem Ticket.

Problem Management form (Search)Click on the Search Ticket button for searching a Problem Ticket.In search mode login user can view the problem Ticket and able to modify his/her own group problem Ticket only.

Problem Management Console > Incident Matching buttonClick on the Incident Matching button given in the Problem Management Console.All the users present in the system can access the Incident Matching form.

Problem Management form > Known Error Creation buttonClick on the Known Error Creation button given in the Problem Management form for creating a Known ErrorThe problem owner can create a Known Error for the Problem.

Table 4.1 Access Permission for Problem Management form

4.1 Problem Management Console

The Problem Management process allows the user to:

Record Problems Modify Problem Ticket

Undertake Problem Control and Error Control activities.

After logging in the Problem Management console is opened as in figure 4.1.

Figure 4.1 Problem Management Console

The Problem Management console provides the following functionalities:

Creating a Problem Ticket

Modifying a Problem Ticket

Searching for a Problem Ticket

Provide information on all the Problem TicketsUsing the Problem Management Console

Most of the functionality will remain as it is in the existing System.

The new button Incident Matching will open the Incident Matching form. On this incident matching form, user can search Incident, Problem and known error records based on a set of selected fields ideal for incidents grouping. More are explained in detail in the later part of this user guide.

New Option All is included in Show tickets of field. When user selects this option, records for all users will be displayed in the tabled. In other words, tickets will not be filtered for specific user. It will show the tickets for all.

4.2 Recording a Problem

Problem Management Console has functionalities that allow the user to create and modify Problem Tickets.

4.2.1 Create Problem Ticket

To create a Problem Ticket the user needs to click on Create Ticket button on the top left panel of the Problem Management Console, as in figure 4.1. This will open a form, as in figure 4.2, to record the Problem details.The following flowchart will give a quick representation of the problem ticket creation using the Problem Management form.

Figure 4.2 Form for Creating a Problem Ticket

The user will need to specify value for all the mandatory fields (marked in BOLD) like Preventive Action and need to relate this Problem Ticket with an existing Incident Ticket.

Click on the Relationship tab as shown in figure 4.3. Specify the required details.

Enter the Incident number that this Ticket is to be related to in the Incident # field.

Click on View Incident Record (if required) button to view the details of Incident record.

To relate this Incident Ticket with the Problem Ticket, click on Add Relationship button.

Similarly, the user can click on the Remove Relationship button to delete the relationship between this Problem Ticket and an Incident. However, make sure the Incident record in the table is selected before clicking on the Remove Relationship button. The Remove Relationship button is enabled only when the Problem Ticket is related to more than one Incident Tickets.

After entering the required details for the Problem, click on Save button to create a Problem Ticket. Problem Ticket can also be created from the Incident Matching form. The process flowchart for the same is shown below:

Note:

There must be at least one Incident Ticket present in the Related Incident table. Incident with Status=Cancelled can not be related to the Problem

Duplicate Incidents can not be related to the Problem ticket

PM-PM# permission group users can create a problem ticket for all kinds of Incident Status Tickets (except Cancelled). PM-Tier3# group users can create a problem ticket for only those incidents, which belong to their Owner group

Owner group is determined using the combination of Incident tickets Service, Component, Domain and Affected country.

Users with PM-PM# permission can assign the Problem ticket to any assignment group Users with PM-Tier3# permission can the assign the problem ticket to members within their own group.

When user relates high severity incident to the problem, Investigation driver field defaults to High Incident impact and priority value is set to high on the Problem management form.

Users with PM-PM# permission can select Post mortem value in the Record type field.

Figure 4.3 Creating a Problem Ticket Relationship Tab

4.2.2 Modify Problem Ticket

Search for the required Problem Ticket.

Select Problem Ticket from the table in the Problem Management Console.

Double click on the selected Problem Ticket to open its details.

Modify the required fields and click on Save button to complete the modifications.

The user can select from the values Yes and No from the Root Cause field. If user selects the Root Cause field as Yes then the following fields will be displayed which are mandatory:

Root Cause Date: This field would hold the current system date value when Root Cause is Yes. This field is editable. This date can not be earlier then problem creation date. Root Cause Code: This field has the same menu attachment as with the Cause code field in IM module. It captures the agreed cause of failure after root cause analysis. Root Drill down One: This field has the same menu attachment as with the Drill down one in IM module. It captures the agreed failure location/further breakdown of component Root Drill down Two: This field has the same menu attachment as with the Drill down two in IM module. This is a further breakdown of Root Drill Down One.Root Drill down two field is not mandatory. However, it should be specified if the selected service and component combination have values define for itWhen the Root Cause field is set to No, the four fields mentioned above will be hidden and the Reason Code field is displayed which is mandatory. This field is a selection field and users will have following options to select for this fieldi. No Support : Vendor support lapse or software version no longer supportedii. No log : Insufficient or no log available for further analysisiii. Cannot Simulate : not able to simulateiv. Third party issue: Failure happens at regulator or customer end and root cause is beyond SCBs controlOther Important fields:

Owner group: Owner group is a character menu and enlist the assignment group of the logged in user. For user with PM-PM# permission this field will show all assignment groups. Owner: Owner is a character menu and enlists the list of user based on selected Owner group.

Failed Service: This field captures the Service which is the root cause of the failure. Value Generic Service is used if the failure is caused by a component used by many services. It has the same menu attachment as with Service+ field in IM module. Any Change in value to be populated to Known Error record if exists. Failed Component: This field captures the Component of an IT infrastructure or service which is the root cause of the failure. It has the same menu attachment as with Component+ field in IM module. Any Change in value to be populated to Known Error record if exists. Investigation Driver: This field defaults to High Incident Impact whenever high severity incident is related to the problem. Its default will be Recurring Incident if more than one low severity incidents are related together. Subsequent adding of incidents will require manual update of values. This field is a selection field and users will have following options to select for this field:i. High Incident Impact: Whenever high severity incident is related to the problem, the Investigation driver defaults to High Incident Impact. However user can also change the selection value manually.ii. Recurring Incidents: Whenever low severity incident and more than one are related to the problem, the Investigation driver defaults to Recurring Incidents. However user can also change the selection value manually.

iii. Non-Routine Incident: Whenever one low severity incident related to a problem, the Investigation driver defaults to Non-routine Incident. User can change this value manually. This can be applied in situation where a fix is required and team/end user is eager to track the progress.4.2.2.1 Root Cause Analysis (RCA) Tab

After opening a problem Ticket, the default tab is RCA tab. Figure 4.4 shows the window for this tab, where the user can modify RCA details of a Problem record.

Figure 4.4 Modifying Problem Ticket RCA Tab

The user can add details of the affected service by selecting its details and clicking Add button. To modify details of the affected service, the user needs to select the one the user needs to modify from the table, make the changes by reselecting the required details and then click Modify button. The user can select an affected service record and click Delete button to delete the record. Clicking Refresh button will refresh the table.

4.2.2.2 Solutioning Tab

After opening a Problem Ticket, the user can click on Solutioning tab as shown in figure 4.5, to modify solution details of a Problem record.

Figure 4.5 Modifying Problem Ticket Solutioning Tab

The following new fields are created in this tab Not Available Reason: When Permanent Fix Status is Not Available then field will be made visible and is mandatory. User will have following option to choose from Budget not approved: Permanent fix status is not available because of budget issue

Non-Compliance: Permanent is not available because it is not compliant with system or bank policy Technology Constraint: Permanent fix is not available because technology constraint

Business Constraint: Permanent fix is not available because business constraint Strategic Intent: Permanent fix is not available because some strategy is intended by the management which is suppose to get over on {Strategic Intent date} Strategic Intent Date: When Not Available Reason is Strategic Intent then field will be made visible and is mandatory. Based on this date value escalation will fire if Strategic intent date is passed and problem is not closed / resolved.The user can add an action item for the Problem Ticket by clicking on Add Action button, which will open the form for entering the Problem Action Information, as in figure 4.6.

Figure 4.6 Form for Problem Management Action Information

Important fields on Action Item dialog Target Fix Built Date: This holds the Action Item fixing date. The date entered in this field cannot be earlier than the Problem Management record Create Date

Revised Fix Built Date: If the action item date needs revising. The date entered in this field cannot be earlier than the Problem Management record Create Date

Actual Fix Built Date: When the action item has actual fixed. The date entered in this field cannot be earlier than the Problem Management record Create Date Target System Test Date: After fix the testing starting date need to capture. The date entered in this field cannot be earlier than Actual Fix Built Date

Revised System Test Date: Revising the test date. Cannot be earlier than Actual Fix Built Date

Actual System Test Date: When the actual test date is happened. Cannot be earlier than Actual Fix Built Date Is Date Validation Check Required? : This is a selection field. If value Yes is selected for this field then validations are performed for above 6 date fields while saving/modifying the Action Item. If this field value is not checked, no validation will be performed. Pending code: Pending Code field will be visible when Action Item status is Pending. This is selection field and user can select following values for this field.

Fix from Vendor: Select this value, if fix is pending from outside vendor Find fix: If fix is found and awaiting development then select this value Business response: Pending because this requires business response Build Fix: Fix is developed and yet to be tested System Test: Undergoing system test. This excludes User Acceptance Test and Operation Acceptance Test which is part of Change/Release Management Rebuild fix: Pending because, previous build fail its system test Change Implementation: Pending because, the fix is awaiting Implementation via Change management Fix code: If Permanent Fix is Yes then field will be available for the user selection. This will help to identify type of fix given if the Permanent Fix = Yes. The possible values are:

System patch: Depicts that patch is released to provide permanent fix for the action item. Re-configuration: Depicts that Re-configuration has been done to provide permanent fix for the action

System fix: Depicts that system fix has been provided to provide permanent fix for the action item Permission: Permission granted to provide permanent fix for the action item Hardware replace: Hardware to be replaced in order to provide permanent fix Procedures: some procedures are required to provide permanent fix for the action item. Code Fix: Code fix is required to provide the permanent fix for the action item Fix Counter: This field will help user to identify how many time action items changes pending code from System Test to Rebuild. Once counter is increased, Revised Fix Date & Revised Test Date to be nullified. Create Change Record: If the action Item is change related then user can created change record from here. Also the respective change related information Change no and Implementation End Date fields need to be populated back when the change is created and modified. The below flowchart depicts the change management and action item integration process. Change No: This field will become mandatory whenever pending code is Change Implementation or Change Related is Yes. This field stores the associated Change Request Id.

Action Item Change Management integrationTransaction History: This will allow the user to see each action item status movement and pending code movements with timestamp.Important Points to remember The user can create a Change Request from Problem Action Information form by selecting the status as Pending. This will enable the Pending Code field. Selecting the Pending Code field value as Change Implementation will enable the Create Change button. Click on Create Change button to create a change request. This will open the form for creating the new Change Request as shown in figure 4.7.

Enter the required details and click on Save button. After creating the Change Request the Change Number will be displayed in Change No field of Problem Action Information form. User can also relate a change request to Problem Action Information by setting the Change Related field to Yes. This action will enable Change Number field, where the user can enter the Change Request Id in that field.

After entering the required details in the form of figure 4.6, click on Save button to save the details of action information. This action information will be reflected in the Actions table of figure 4.5.

Click on Refresh button to refresh the table if the data is not shown in the table.

The user can also select a predefined action for the Problem by clicking Select Predefined Action button.

The user can cancel an action by selecting the action from the table and clicking the Cancel Action button, refer figure 4.5.

Figure 4.7 Form for Change Management

The user can create a Known Error record for the Problem Ticket by clicking on Known Error Creation button as shown in figure 4.5. Known Error Creation button will be enabled when the Recommended Work Around is available and the field updated with value in the Problem record. Specify details in Recommended Workaround field, and select Failed Service and Failed Component values from the menu. Click on Known Error Creation button. This will open the Known Error form for creating a Known Error as shown in figure 4.13. For more details refer Chapter 4 Problem Management - 4.4 Known Error After creating the Known Error for the Problem, Known Error Details will be available for modification. Click on the View Known Error button on the Solutioning tab. When the user changes the status of Known Error to Cancelled then relationship between Known Error and the Problem Ticket will be removed and the user can create a new Known Error record for the Problem in similar manner.4.2.2.3 Relationships Tab

After opening a Problem Ticket, the user can click on Relationship tab as shown in figure 4.8, to modify relationship details of a Problem record.

Figure 4.8 Modifying Problem Ticket Relationship Tab

The user can add or remove a relationship between this Problem Ticket and an Incident, as discussed in section 4.2.1 Creating Problem Ticket. Also below flowchart depicts the process whenever PM-Tier3# and PM-PM# users perform Add Relationship between incident and problem. The user can also add another Problem Ticket as a duplicate by specifying the Problem Ticket in the Problem Identification field and clicking on the Add button. The user can modify the Problem Identification record by selecting a record from Problem Identification table and clicking Modify button. Also, the user can delete Problem Identification record by selecting the record from the table and clicking the Delete button.

Note: All other tabs like Timeliness, Business Impact, Audit are same as in the older version of RCA Module and thus are not being discussed here

PM-Tier3# Add relationship process

PM-PM# Add Relationship process4.2.2.4 Important Exceptions

Following are some of the Error Messages displayed by system while modifying an Incident record:

Exception 1 Root Cause Code Not SelectedThis error message is displayed when user tries to save the record without selecting the value for Root Cause Code field when Root cause is set to Yes.AR System User Error

Invalid value for Root Cause Code. Please choose appropriate value from pull-down (ARER1000)

Exception 2 Root Drill Down One Value Not SelectedThis error message is displayed when user tries to save the record without selecting the value for Root Drill down One field when Root cause is set to Yes.AR System User Error

Invalid value for Root Drill Down One. Please choose appropriate value from pull-down (ARER1000)

Exception 3 Root Drill Down Two Value Not Selected This error message is displayed when user tries to save the record without selecting the value for Root Drill down Two even if its available for selected failed service and failed component combination when Root cause is set to Yes.AR System User Error

Invalid value for Root Drill down two. The value OTHERS doesn't exists. Please select correct value. (ARER1000)

Exception 4 Cause By Value Not SelectedThis error message is displayed when user tries to save the record without selecting the value for Cause By field.AR System User Error

Please choose appropriate value from pull-down for Caused By (ARER1000)

Exception 5 Cancelling Problem Ticket ErrorIn Problem Management form, this error is displayed when user try to cancel the Problem Ticket without cancelling all the Action Item.AR System User Error

Please cancel all action items for RCAKL0000002439 before problem record can be cancelled. (ARER1000)

Exception 6 Root Cause Details Not SpecifiedThis error message is displayed when user tries to save the record without selecting the value for Root Cause Details.AR System User Error

Please fill in value for Root Cause Details (ARER1000)

Exception 7 Changing Root Cause of Problem with Known ErrorThis error message is displayed when user tries to change the Root Cause from yes to no having published Known Error associated with that Problem.AR System User Error

Known error KE0001200 is published for this problem. An email will be sent to ITSC Service Desk to retire the KMR article should you choose to proceed. (ARER1000)

Exception 8 Root Cause Date Lesser Than Problem Creation DateThis error message is displayed when Root Cause date is less than the Create date of the Problem.AR System User Error

Root Cause Date cannot be earlier than Create Date. (ARER1000)

Exception 9 Not Available Reason Set to NullThis error message is displayed when user selects the value of Permanent Fix Status field as Not Available and Not Available Reason field is set to NULL.AR System User Error

Please fill in the value for Not Available Reason. (ARER1000)

Exception 10 Strategic Intent Date Set to NullThis error message is displayed when user selects the value of Not Available Reason field as Strategic Intent and Strategic Intent Date field is set to NULL.AR System User Error

Please fill in the value for Strategic Intent Date. (ARER1000)

Exception 11 Closing a Problem Ticket without Closing all ActionsThis error message is displayed when user changes the status of the Problem Ticket to Resolved or Closed without closing all the action defined for that Problem Ticket.AR System User Error

Cannot resolve/close the problem as some action items is not in status Closed/Ongoing/Immediate effect. Please check. (ARER1000)

Exception 12 Relating Incident Tickets Again to Same ProblemThis error message is displayed when user tries to relate the Incident Tickets which is already related to that Problem.AR System User Error

PNKL000032453 is already related to the problem. Please check. (ARER1000)

Exception 13 Relating Incident Ticket with Cancelled StatusThis error message is displayed when user tries to relate the Incident Ticket with cancelled status.AR System User Error

Sorry cannot relate cancelled incident ticket! (ARER1000)

Exception 14 Non Owner of the Problem Relating the IncidentThis error message is displayed when the user (PM-Tier3) who doesnt own the Problem Ticket try to relate the Incident.AR System User Error

Sorry! You can not relate this Incident as you are not the member of Owner group (ARER1000)

Exception 15 Relating Already Related Incident TicketsThis error message is displayed when user tries to relate already related Incident Tickets.AR System User Error

PNXX0000XXXXX is already related to a problem or PNXX0000XXXXX is not a valid Incident Record # . (ARER1000)

Exception 16 Adding Problem Details without Problem# ValueThis error message is displayed when user clicks on the Add button without specifying the Problem# in Problem Identification field.AR System User Error

Please specify the problem number in Problem Identification. (ARER1000)

Exception 17 Relating Already Related Problem TicketsThis Error message is displayed when user tries to relate the same Problem which is already related.AR System User Error

This problem is already linked to problem RCAXXNNNNNNNN (ARER1000)

Exception 18 Relating a Problem With ItselfThis error message is displayed when user tries to relate the same Problem with itself.AR System User Error

A problem cannot be related to itself. (ARER1000)

Exception 19 Relating an Open ProblemThis error message is displayed when user tries to relate the Problem which is not Closed or Create not earlier than the current Problem create date.AR System User Error

The problem RCAKL0000001503 is not closed

OR

Create date of the problem RCAKL0000001503 is not earlier than RCAKL0000001554 create date

Exception 20 Reason Code Not SpecifiedThis error message is displayed when user tries to save the record without selecting the Reason Code when Root cause is set to No.AR System User Error

Reason code is mandatory when Root Cause is No. (ARER1000)

Exception 21 Pending Code Not SpecifiedThis error message is displayed when user tries to save the Action Item record without selecting the Pending Code field when Status is set to Pending.AR System User Error

Pending code is mandatory when Status is Pending (ARER1000)

Exception 22 Expected System Test End Date Not SpecifiedThis error message is displayed when user tries to save the Action Item record without specifying the Expected System Test End Date when Status is set to Pending and Pending Code is System Test.AR System User Error

Expected System Test End Date is mandatory when Pending Code is System Test (ARER1000)

Exception 23 Change No. Not SpecifiedThis error message is displayed when user tries to save the Action Item record without specifying the Change No. when Status is set to Pending and Pending Code is Change Implementation.AR System User Error

Change No. is mandatory when Change Related is Yes. (ARER1000)

Exception 24 Revised Fix Delivery Date Not SpecifiedThis error message is displayed when user tries to save the Action Item record without specifying the Revised Fix Built Date when Status is set to Pending and Pending Code is Rebuild Fix.

AR System User Error

Revised Fix Built date is mandatory when Pending Code is Rebuild Fix. (ARER1000)

4.3 Search Problem Ticket

To search for a Problem Ticket, the user needs to click Search Ticket button. This will open a Search Problem Management form as in figure 4.9.

Figure 4.9 Search for a Problem Ticket

The user can enter required search criteria and click on Search button. This will open the Search Result window as in figure 4.10.

The window in the figure 4.10 consists of two panes. First pane displays the search result while the second pane displays the form consisting of the details of the selected Problem Ticket. The user can perform the Problem modification on the displayed record in this pane. Alternatively, if the user wants to view the Problem records in a separate window, the user can do so by double clicking on the Problem in the result pane. Problem Owner can modify the problem Ticket where as other users can be able to view the problem Ticket only.

4.4 Problem Status

Any Problem goes through a life cycle covering different phases, each of which is defined by Problems Status in the application. The status of the Problem is changed when it moves from one phase to another. The phases or status of a Problem are:

New This is the status of a Problem when it is created.

Under Investigation This is the status of a Problem when it is under investigation for root cause(s).

Pending This is the status of a Problem when it is pending for action item to be completed.

Known Error This is the status of a Problem when it has been successfully diagnosed and workaround has been established. When Permanent Fix Status has value Not Available, the system will set Problem status to Known Error Resolved This is the status of a Problem when findings are concluded but there are action items to be completed Cancelled This is the status of a Problem when it has been cancelled. When problem ticket is closed all the associated incidents are removed. The below flowchart depicts the process whenever problem ticket is cancelled.

Closed This is the status of a Problem when all action items are completed(action status:Ongoing/Immediate/Completed). When ever problem ticket is moved to status closed, the associated incident tickets status not in Resolved status will have its status set to Resolved. If known error for the problem record exists, the known error status is changed to Retired if Permanent Fix Status is having value Completed. The below flowchart depicts the process whenever problem ticket is Closed.

Note: All action items related to the Problem record should in status cancel or closed before closing/cancelling the problem record

User can not cancel the problem request, if the known error associated with the problem ticket is published. All associated incidents are removed from the relationship table when user cancels the Problem request.

4.5 Email Notifications to Users

There are few notifications which get triggered, based on the conditions as mentioned below:

Notification 1

Notification Event: In this notification event, ITSC Problem Management will get notified if the PM-Tier3# user creates a Problem Ticket for high severity Incident Ticket.

Notification Message: Known Error buttonClick on the Known Error Creation button given in the Problem Management form for creating a Known Error.Problem Owner group members can create a Known Error for the Problem.

Known Error Form (Modify)Click on the View Known Error button given in the Problem Management form.Problem Owner, Group Leader of problem owner and ITSC SD can modify a Known Error for the Problem.

Known Error Approval ConsoleThe user can access this form from the Object List.Group Leader and ITSC Service desk members will be able to see Known Error request assigned to them for approval.

Table 5.1 Access Permission for Known Error form

5.1. Recording a Known Error

Open a Problem Ticket for which Known Error is to be created, refer figure 5.1. Initially, Known Error Creation button is disabled. Enter all the mandatory details required for RCA.

Enter the values for Failed Service, Failed Component Enter details for the Recommended Workaround on the Solutioning tab Save the record. The Known Error Creation button will get enabled after all the mentioned details in problem record are saved.Note: Also, the user is required to ensure that the Service Class and Resolution Code are available for the incident(s) which are related to a problem record.

The process for creation of a known error can be depicted with the following flow diagram.

Figure 5.1 Creating Known Error

To create a Known Error:

Click on Known Error Creation button. A form for creating Known Error, as in figure 5.2 will be displayed.

Figure 5.2 Form for Creating Known Error

The values for most of the fields (in form shown in fig 5.2) will be obtained from Problem Ticket and its associated Incident Ticket. Enter all required details.

If you dont want to send the known error for the approval, you can press Save as Draft button. You can modify the known error request in future.

If you want to send the known Error for approval, Submit for Approval button to create the Known Error. Once a Known Error is successfully created, an email will be sent to the Group Leader for approval. If you want to view Problem Ticket details for this Known Error, click on View button.

The Known Error form and open Problem Ticket identified by Related Problem# field. Clicking on Close button will close the form. After creating or modifying the Known Error Tickets the following fields like: Workaround, Resolution Details, Preventive Action field details are reflected back to the Problem Management form.

The Known Error form is available for modification/view from the following forms:

Incident Matching Form

Known Error Approval Console

User tools Object list

5.2. Approval of Known Error

Known Error has to undergo two levels of approval cycle before it is published. These two levels of approval are done by Group Admin and ITSC SD. (having permission of KMSAC-Tier1_Admin).

Group Leader is the first level approver.

If Group Leader information is not available, Primary approver of the group becomes the first level approver

Group leader can approve/reject/modify the known error request.

ITSC service desk members are the second level approvers. ITSC Service desk can publish/reject/retire/modify the known error request.

Request approved by Group leader are sent to the ITSC service desk members for approval via weekly notification.

Note: Problem record for which root cause has been identified will be sent to the ITSC service desk for the approval

5.2.1. Known Error Approval Console

When a Known Error is created and submitted for approval, a mail is sent to the Group leader for approval. This mail contains an attachment which the approver can double click to open the Known Error Approval Console, as in figure 5.3. Alternatively, the user can open the Object List and perform search on Known Error Approval, double click on the result exactly matching Known Error Approval to open the Known Error Approval Console.

Figure 5.3 Known Error Approval Console (Group Admin)

The table in the centre of the form provides the list of Known Errors pending for approval from the Group Lead and ITSC Service desk. The user can select and view the record that is to be approved or rejected. Clicking on View button will open the Known Error details for the selected record.

To approve the Known Error the user needs to select and view the record. Known Error details will open for the selected record. Click on Approve button to approve the known error request.To reject the Known Error the user needs to select and view the record. The user needs specify the reject reason for rejecting the Known Error Request. After entering the reject reason click on Reject button, a mail will be sent to the owner of the Known Error that it has been rejected. Once a Known Error request is rejected by group lead, Owner can again resubmit it for approval by modifying the Known Error request.5.3. Publishing Known Error

ITSC Service desk members having rights to publish the articles in the KMS can publish the Known Error article. To publish the known Error article:

Select the record from the form in figure 5.3 and click view button. On the Known Error form that opens, click on the Approve & Publish button. Following message box will appear as shown in figure 5.4 will appear.

Figure 5.4Click on the publish button as shown in figure 5.5.

Figure 5.5 Known Error Publish

To complete the known error publish process click on Publish Article button as shown is figure 5.6

Figure 5.6 Known Error Publish5.4. Retirement of Known Error

Known Error Retirement process is triggered from Problem Management form.

CASE 1: Problem Status moves to Closed and Known Error Article is published:

When user closes the problem ticket, and known error associated with the problem is in the status published, then request for retiring the Known error article is sent to the ITSC service desk. ITSC service desk can retire the known error request by viewing the Known error request from the Known Error Approval console and clicking on Approve Retirement button on the known error form as shown is figure 5.7.

Figure 5.7 Known Error RetirementThe known error article is opened. Press Retire button that known error article as shown in figure 5.8

Figure 5.8 Known Error RetirementOnce you press Retire button as shown is figure 5.8, the following message will appear as shown in figure 5.9

Figure 5.9 Known Error RetirementTo complete the retirement process, click on Retire Article button as shown in figure 5.10.

Figure 5.10 Known Error RetirementCASE 2: Problem Status moves to Closed and Known Error article is not published:When user closes the problem ticket, and known error associated with the problem is not in the status published, the Known error status is moved to the status Retired and notification will be sent to the group leader/ITSC service desk informing the retirement of the known error article.5.5. Important Exceptions

Following are some of the error messages displayed by system while modifying an Incident record.

Exception 1 Mandatory Fields Are EmptyThis error message is displayed when user clicks on the Submit for Approval button without specifying the values for mandatory fields.AR System User Error

The mandatory fields in highlighted in bold need to have value before Submit for Approval is possible. (ARER1000)

5.6. Known Error Status

Any Known Error goes through a life cycle covering different phases, each of which is defined by Known Errors status in the application. The status of the Known Error is changed when it moves from one phase to another. The phases or status of a Known Error are:

Draft This is the status of a Known Error request when user saves the Known Error request as draft. When the user creates the Known error, the status will be Draft. In this status no approval email is sent. After the confirmation or final modification, user can send the known error request for approval by clicking Submit for approval button Approved-content- This is the status of a known error when group lead approves the known error request and problem root cause is not known. Pending for Publish This is the status of a Known Error request when the known error request is pending for approval (for publish) with Group Leader or ITSC Service desk. In this status, owner group cannot update the known error request as its pending for approval. Once group leader approves/reject the known error request, owner group will be able to update the known error request and resubmit it for the approval Rejected This is the status of a Known Error request when known error request is rejected by group lead or ITSC service desk. Owner group can modify and resubmit the known error request for approval once it is rejected. Published This is a status of a Known Error request when the known article is published in KMS. Once known error article is published, user can not update the known error request. Also respective fields in problem record become read only. Pending for Retirement This is the status of a Known Error request when the known error request is pending for approval (for retirement) with Group Leader or ITSC Service desk

Retired This is the status of a Known Error when the Known Error article is retired from KMS.

Cancelled This is the status of a Known Error when it is cancelled. When known error is cancelled, the relationship between problem ticket and known error is removed. A new known error can be created for the Problem record where it is being detached from. Owner group can cancel the Known error request before the known error article is published. Once Known error article is published, user can not cancel the known errorNote: If user try to change the respective Known error fields (Root cause details, Failed component, Failed Service...etc) in Problem management record, Known Error status change to DraftThe below flowchart will give better idea of status transition in Known Error.

Known Error Status Transition while Publishing

Known Error Status Transition while Retiring

5.7. Email Notifications to Users

There are few notifications which get triggered, based on the conditions as mentioned below:

5.7.1. Known Error Notifications For Publish

Notification 1:

Notification Event: In this notification event, Group Leader (Group Leader of Owner Group) will get notified if the Known Error is created. An email will be send automatically to the Group Leader with attachment. This attachment contains shortcut to Known Error Approval Console.

Notification Message: Subject: Known Error KEKL0000000342 for your approval

Dear Sir/Madam,

The Known Error KEKL00000000342 created by DEMO USER needs your approval.

It is regarding

Please review and approve/reject where appropriate.

This link will bring you to the system for update

Action to be performed: A shortcut for the Known Error Approval console form is provided as an attachment in the email. Group Leader need to double click on the attachment to open the Approval console in the User tool. Group Leader has to provide his/her User ID and password to login into the system. After authentication system will allow Group Leader to login into the system. Known Error approval console is displayed where Tickets assigned to the Logged in user (Group Lead) are displayed in the table.

Notification 2:

Notification Event: In this notification event, ITSC Service desk (ITSC user with KMSAC-tier1_Admin permission) will get notified weekly for known error request which are approved by Group lead. An email will be send automatically to the ITSC Service Desk with attachment. This attachment contains shortcut to ITSC Known Error Approval Console.

Notification Message: Subject: Known Error KEKL0000000342 for your publishing

Dear Sir/Madam,

Following are the known errors/workarounds extracted as at pending for your approval on clarity and understanding before publishing

KECH00000000481 KECH00000000482 KECH00000000483 KECH00000000481 KECH00000000482 KECH00000000483

Please review and approved/reject where appropriate.

This link will bring you to the system for update

Action to be performed: A shortcut for the Known Error Approval console form is provided as an attachment in the email. ITSC Service desk person need to double click on the attachment to open the Approval console in the User tool. ITSC Service desk person has to provide his/her User ID and password to login into the system. ITSC Known Error approval console is displayed where Tickets assigned to the Logged in user (ITSC Service desk person) are displayed in the table.

Notification 3:

Notification Event: In this notification event, owner will get notified if the Group Leader approves the Known Error request. An email will be send automatically to the owner.

Notification Message: Subject: Known Error KEKL0000000342 is approved

Dear Sir/Madam,

The Known Error KEKL00000000342 created by DEMO USER has been approved by your group leader.

It is regarding

Please do not reply to this email as it is system generated

Notification 4:

Notification Event: In this notification event, owner will get notified if the Group Leader rejects the Known Error request. An email will be send automatically to the owner. Notification Message: Subject: Known Error KEKL0000000342 is rejected

Dear Sir/Madam,

The Known Error KEKL00000000342 created by DEMO USER has been rejected by your group leader. Please check Rejection reason in system for further action.

It is regarding

This link will bring you to the system for updates.

Notification 5:

Notification Event: In this notification event, Owner and Group Leader will get notified if the ITSC SD approves the Known Error request. An email will be send automatically to the Owner and Group Leader. Notification Message: Subject: Known Error KEKL0000000342 is published

Dear Sir/Madam,

The Known Error KEKL00000000342 created by DEMO USER has been published.

It is regarding

Please do not reply to this email as it is system generated

Notification 6:

Notification Event: In this notification event, Owner and Group Leader will get notified if the ITSC SD rejects the Known Error request for publication. An email will be send automatically to the Owner and Group Leader. Notification Message: Subject: Known Error KEKL0000000342 is rejected for publication

Dear Sir/Madam,

The Known Error KEKL00000000342 created by DEMO USER has been rejected by for publication. Please check Rejection reason in system for further action.

It is regarding

This link will bring you to the system for updates.

5.7.2. Known Error Notification for Retirement

Notification 7:

Notification Event: In this notification event, Known Error Owner will get notified if a Problem is closed. An email will be send automatically to the Owner group with link to KMR for retirement of article.

Notification Message: Subject: Known Error KEKL0000000342 is ready to be retired

Dear Sir/Madam,

The Known Error KEKL00000000342 created by XYZ had permanent solution provided on and the KMR article can be retired so as to keep search space lean for KMR.

It is regarding

This link will bring you to the system for updates.

Action to be performed: A shortcut for the Known Error Approval console form is provided as an attachment in the email. ITSC Service desk person need to double click on the attachment to open the Approval console in the User tool. ITSC Service desk person has to provide his/her User ID and password to login into the system. ITSC Known Error approval console is displayed where Tickets assigned to the Logged in user (ITSC Service desk person) are displayed in the table.

5.7.3. Known Error Notification for Cancel

Notification 8:

Notification Event: In this notification event, Group Leader will get notified (If Known Error request is pending for approval with Group Lead) if the Owner cancels (Status=Cancelled) the Known Error request. An email will be send automatically to the Group Leader. Notification Message:

Note: Owner can cancel the Known Error request only before it is published in KMS.Subject: Known Error KEKL0000000342 cancelled by creator

Dear Sir/Madam,

The Known Error KEKL00000000342 created by DEMO USER for your approval has been cancelled. Please ignore earlier request for approval. Sorry for any inconvenience.

It is regarding

Please do not reply to this email as it is system generated

Notification 9:

Notification Event: In this notification event ITSC Service Desk and Group Leader (If Known Error request is pending for approval with ITSC Service Desk) will get notified if the Owner cancels (Status=Cancelled) the Known Error request. An email will be send automatically to the ITSC Service Desk and CC to Owner. Notification Message: Subject: Known Error KEKL0000000342 cancelled by creator

Dear Sir/Madam,

The Known Error KEKL00000000342 created by DEMO USER for your publication has been cancelled. Please ignore earlier request for publication. Sorry for any inconvenience.

It is regarding

Please do not reply to this email as it is system generated

Note: Owner can cancel the Known Error request only before it is published in KMS.ITIL PROBLEM MANAGEMENT

USER GUIDE VER. 2.1

Subject: Weekly Reminder to Resolve Open Incidents identification

The following open incidents for TW-TSS-CTRY SYSTEMS SUPPORT should be resumed/recovered by now such that user can continue with their daily work. Please help to update resolution detail tab with the Resume Time updated appropriately.

The attachment will bring you to the system for updating.

Note: For better view please copy the below details into Notepad.

Incident# Service Component Domain Problem type Assignee Name

==============================================================================================

PNKL00003586595 | RADIA | WORKSTATIONS | DESKTOP | | |

.

AR System User Error

Please select the value for Service field. (ARER1000)

Subject: Weekly Identification of Potential Recurring Incidents

The following potential recurring incidents criteria for the period of 02/17/07 to 05/18/07

The attachment will bring you to the system for updating.

Note: For better view please copy the below content into Notepad

Service Component Domain Problem type Affected Country Site Cause code Resolution code Count if records

======================================================================================

ADI | APPLICATION S/W | APPLICATION | Server | INDIA | | | 3

ADI | APPLICATION S/W | APPLICATION | | INDIA | | | 5

ADI | APPLICATION S/W | APPLICATION | Server | INDIA | | | 3

ADI | APPLICATION S/W | APPLICATION | | INDIA | | | 5

This link will bring you to the system for update.

AR System User Error

Please select the value for Component field (ARER1000)

Subject: Incidents passed its Suspended Date

Dear Sir/Madam,

The below 2 incidents have passed its suspended date.

Incident Ticket#: PNKL0000091890 , PNKL0000091290

Please revise date or action where needed.

This link will bring you to the system for update

Subject: Following Suspended Incidents are to be due tomorrow