وزارة العدل · Web viewThis document has been formulated to accommodate an “Integrated...

Ministry of JusticeDeputyship of Digital

Transformation

Problem Management Policy, Process and

Procedure

Version 1.2

Release

Document1.2Version

InfrastructureProcess Owner Date

Table of Contents

DOCUMENT INFORMATION.......................................................................REVISION DETAILS...................................................................................DOCUMENT VERSION HISTORY................................................................DEFINITIONS & ABBREVIATIONS..............................................................EXECUTIVE SUMMARY..............................................................................PROBLEM MANAGEMENT SCOPE..............................................................PROBLEM MANAGEMENT PURPOSE AND OBJECTIVES..............................PROBLEM MANAGEMENT VALUE TO MOJ..................................................PROBLEM MANAGEMENT POLICIES..........................................................PROBLEM MANAGEMENT INPUTS & OUTPUTS..........................................PROBLEM MANAGEMENT PROCESS WORKFLOW....................................ROLES & RESPONSIBILITIES...................................................................CRITICAL SUCCESS FACTORS (CSF) & KEY PERFORMANCE

INDICATORS (KPI)..............................................................................PROBLEM MANAGEMENT GENERAL GOVERNANCE CONSIDERATIONS

..........................................................................................................PROBLEM MANAGEMENT IMPLEMENTATION CONSIDERATIONS.............REFERENCES..........................................................................................PROBLEM MANAGEMENT FORM SAMPLE................................................

Document Information

Problem Management ProcessCopyright © MOJ. All rights reserved. Unauthorized copy or use of this document is strictly prohibited. Printed version of this document is only valid as long as the revision number and issue date correspond with the relevant information on the MOJ Intranet Portal/file system.MOJ does not warrant that this document is error-free.Printed version of this document will be treated as an uncontrolled copy.

of 22

Document1.2Version

InfrastructureProcess Owner Date

Document Title:

Problem Management Process

Document Number:

Document Status:

Process Owner

Infrastructure Department Release Date

Document Owner

Governance Team

Document Type

Internal Review Interval Annually

Revision Details

Version

Particulars Name Title Signature

1.0 Author & Reviewer

Governance Team Governance Team

Checked by Governance Manager

Reviewed by Infrastructure Manager

Approved by Deputy Minister-DT

Document Version History

Version Number

Version Date

Published By

Description


of 22

Document1.2Version

InfrastructureProcess OwnerDate

Definitions & Abbreviations


of 22

ITEM DESCRIPTIONMOJ Ministry of Justice

CI Configuration Item.

CSF Critical Success Factor.KPI Key Performance Indicator.

SLA Service Level Agreement.

OLA Operational Level Agreement.

UC Underpinning Contract.

CAB Change Advisory Board.

RFC Request for Change.

CMS Configuration Management System.

RCA Root Cause AnalysisITIL Information Technology Infrastructure LibraryMEA Monitor, Evaluate and Asses

Service DeskSingle point of contact to report incidents and track incidents.

KEDBKnown Error Database (stores previous knowledge of incidents, problems,workarounds, and permanent solutions).

Workaround Temporary solution to overcome a service interruption.

PIR Post Implementation Review

IncidentAn unplanned interruption or a reduction to the normal operation of a DT

Problem Underlying cause of one or more incidents

Document1.2Version


Executive Summary

MOJ has established Problem Management document to provide comprehensive process aspects of Problem Management, which will enable MOJ to achieve the objectives with respect to this process. This document has been formulated to accommodate an “Integrated Digital Delivery Framework” and hence, Enterprise Architecture, Digital, COBIT 5.0, ISO27001 and ITIL V3.0 related applicable processes and underpinning base practices have been mapped together in this process document.

Problem Management OverviewProblem Management is a part of Service Operations phase of ITIL lifecycle. This process is mapped to DSS 03 Manage Problems (Deliver, Service and Support) base practice of COBIT 5.0 along with Enterprise Architecture process. By implementing Problem Management, MOJ intends to:

• Prevent problems and resulting incidents from happening.• Eliminate recurring incidents.• Minimize the impact of incidents that cannot be prevented.• Resolve IT problems so they do not reoccur.

Problem Management Scope

The Problem Management policy and associated procedures cover all production services, applications and system assets, network infrastructure assets, all other supported DT assets (physical or virtual) and non-production assets and all requesters of services provided by MOJ.

Problem Management Purpose and Objectives

The purpose of Problem Management is to proactively prevent the re-occurrence of Problem Management ProcessCopyright © MOJ. All rights reserved. Unauthorized copy or use of this document is strictly prohibited. Printed version of this document is only valid as long as the revision number and issue date correspond with the relevant information on the MOJ Intranet Portal/file system.MOJ does not warrant that this document is error-free.Printed version of this document will be treated as an uncontrolled copy.

of 22

Document1.2Version


incidents and to minimize the impact of incidents that cannot be prevented. This scope covers all MOJ-DT services and DT assets as well.The objective of the Problem Management process is:

• To assess and deal with problems to stop incidents from recurring. • To minimize the overall impact of incidents that cannot be prevented. • Where possible, problems will be actively prevented by continually improving

service processes • To ensure that impact analysis of any services changes is rigorously

undertaken.

NOTE: Problem management can be reactive or proactive. Reactive problem management aims at finding and eliminating the root-cause of known incidents, while the pro-active problem management aims to detecting and preventing future problems/incidents (it is initiated in service operation, but generally driven as part of Continual Service Improvement) and a known error sub-process allows quicker diagnosis and resolution if further incidents do occur.Problem Management Value to MOJ

Problem Management works together with Incident Management, Change Management, and Configuration Management to ensure that DT services’ availability and quality are increased. When incidents are resolved, information about the resolution is recorded. Over time, this information is used to reduce the resolution time and identify permanent solutions, reducing the number of recurring incidents. This results in reducing downtime and disruption to the MOJ’s critical systems.The following benefits are realized from adopting Problem Management:

Risk Reduction Problem Management reduces incidents which leads to more reliable and higher

quality DT services for users internally and externally.


of 22

Document1.2Version


Cost Reduction Reduction in the number of incidents leads to more efficient use of staff time as

well as decreased downtime experienced by end-users.

Service Quality Improvement Problem Management helps the MOJ-DT agency to meet customer expectations for

services and achieve customer satisfaction. By understanding existing problems, known errors and corrective actions, the MOJ

Service Desk team has an enhanced ability to address incidents at the first point of contact.

Problem Management Policies

The Problem Management process owner has the responsibility and the authority to execute the defined and established problem management process within the following policies:

A single problem management process that is separate from the incident management and change management processes shall be used throughout MOJ-DT agency.

Clear criteria shall be established to define what constitutes a problem and how problems will be prioritized.

All problems, known errors, relevant progress, and resolution information shall be recorded in a common repository that is linkable to incident and change management records.

A known error shall be raised as soon as useful knowledge is available, even before a permanent resolution is found.

Known deficiencies in an implemented change shall be logged as known errors.

Problem investigation & diagnosis shall employ standard analysis techniques & methodologies leveraging industry best practices.


of 22

Document1.2Version


Problem owners must fulfil their roles and responsibilities as defined in this problem management process.

Also Refer to Incident management policies for Information security incident management clauses that mentions ISO 27001 information security clauses.

Problem Management Inputs & Outputs

PROCESS MAIN INPUTS PROCESS MAIN OUTPUTSIncidents Problem ReportEvent Log Known ErrorCMS Workarounds

Permanent SolutionsRoot Cause ReportKEDBPerformance/ Management ReportsPIR Report

Process Main InputsIncidentsRecording the details of any incident that occurred, via ticketing tools like HP Service Manager.

Event logLogs containing event information, the affected CI(s), time of event occurrence, type of event, and all other information.

CMSThe CMS is a set of tools and databases that are used to manage DT services configuration data including collecting, storing, updating, and presenting data about all Configuration Items and their relationships. The CMS is maintained by configuration Problem Management ProcessCopyright © MOJ. All rights reserved. Unauthorized copy or use of this document is strictly prohibited. Printed version of this document is only valid as long as the revision number and issue date correspond with the relevant information on the MOJ Intranet Portal/file system.MOJ does not warrant that this document is error-free.Printed version of this document will be treated as an uncontrolled copy.

of 22

Document1.2Version


management process and is used by all IT Service Management processes. The CMS also includes information about Incidents, problems, known errors, changes and releases; and may contain data about employees, suppliers, locations, business units, customers and users. The CMS assists incident and problem management process by:

Providing valuable information about how much of the DT infrastructure is affected.

Providing up-to-date information about customers, owners and status of CIs.

Assisting with the identification of incidents of similar CI type.

Process Main OutputsKnown ErrorA fault in a Configuration Item (CI) identified by the successful diagnosis of a problem and for which a temporary work-around or a permanent solution has been identified.

Known Error DatabaseA Known Error Database is a repository of all established root causes. A KEDB record will have details of the incident when the outage happened and what was done to resolve it.

Problem ReportA record containing the details of a Problem. Each problem record documents the lifecycle of a single problem. The problem is defined as a cause of one or more incidents, whose cause is usually not known at that time. The service desk staff can report problem to problem management process team to do the required investigation and find permanent solutions.

WorkaroundThe workaround is a temporary way to restore service failures to a usable level. Workarounds are used for reducing or eliminating the Impact of an Incident for which Problem Management ProcessCopyright © MOJ. All rights reserved. Unauthorized copy or use of this document is strictly prohibited. Printed version of this document is only valid as long as the revision number and issue date correspond with the relevant information on the MOJ Intranet Portal/file system.MOJ does not warrant that this document is error-free.Printed version of this document will be treated as an uncontrolled copy.

of 22

Document1.2Version


a full Resolution is not yet available.

Permanent SolutionsAction(s) taken to repair the Root Cause of an Incident or a Problem.

Root Cause ReportA report containing results of Root Cause Analysis (RCA) activities that identify the root cause of an Incident or a Problem. RCA typically concentrates on DT Infrastructure failures.

Performance/Management ReportsThe process owner is usually asked to generate “process reports” that ensure that the process itself is running as per the agreed level. Most of the reports are based on the CSF and KPI.

Post Implementation Review (PIR)A Review that takes place after a Change or a Project has been implemented. A PIR determines if the Change or the Project was successful and identifies opportunities for improvement.

Problem Management Process Workflow


of 22

Document1.2Version


Detect the need for a problem analysis


of 22

Document1.2Version


Problem Management process can get a trigger from several sources. Some of them are:

Incident Management: A problem can be identified and reported in one of the following ways (based on the settings of the management tool):

Incident management reports of repeated incidents Pro-active problem investigation by the problem manager c.) Operational

risk/internal audit investigation Event management process Incident analysis by technical team or suppliers Senior DT management

Update the existing ticket with additional informationThe problem manager will check if a Problem ticket already exists for the same issue. If yes, then update the existing problem ticket with the additional details.

Record problem ticketOnce a problem is identified, it should be recorded in a central database, which is usually embedded with management tool.Identified problems should be assigned to unique reference numbers (done automatically by the management tool), and the following details should be recorded against each problem:

Urgency Impact Priority Reported by Reference number Date and time Description


of 22

Document1.2Version


Customer impact Identified workaround Details of diagnosis or attempted recovery Related incidents

Classify and prioritize problemsProblem Manager should classify the problem by category (e.g. Applications, Network, and database), impact (effect on business), urgency (how soon must it be resolved), priority (combination of urgency and impact), and status (open, under investigation, workaround found, etc.).

Note: The problem classification should be aligned with the incident classification to easily trace and report problems. (Refer to Incident Management process documents). More details on how MOJ can determine the priority index for problems mentioned in “Problem Management Implementation Considerations “section. The problem prioritization should take into consideration the severity of the problem, business impact, financial impact, and operational risk.

Note: In some cases, the problem manager may need to consult the technical and business teams to classify a problem.

Investigate underlying issueProblem Manager should escalate the problem to the right technical or specialist group for investigation and diagnosis. Technical/specialists groups should diagnose the root cause of the problem and identify a possible permanent fix.

Conduct in-depth RCAThe Problem manager conducts an in-depth and detailed root cause analysis. All available problem analysis and diagnostic techniques should be used to investigate


of 22

Document1.2Version


and diagnose the problem; for example, Ishikawa, Pareto, 5 whys and brainstorming.

Ishikawa: a cause and effect method used to identify where the problem is. Pareto: method of trying to separate 20% important causes from 80% non-

important causes. 5 Whys: is an iterative question-asking technique used to explore the cause-

and-effect relationships underlying a problem. Brainstorming: a group of people generating ideas about solving problem.

The following parameters are used in conducting an RCA: Source of the Problem Symptoms Impact details Any dependencies

The root cause analysis (RCA) may reveal more than one possible solution.

Identify workaroundA technical/specialist group should investigate and try to find the root cause of the problem; if the root cause cannot be found immediately, a workaround solution should be provided.Priority and impact should determine the level of resources that should be used to solve the problem (resources including the technical staff as well).Note: A workaround solution should be identified and implemented (even if it means it is a manual workaround) while a permanent solution is being developed.If the internal technical/specialist groups cannot solve the problem, the problem should be transferred to the supplier/vendor for root cause analysis and a permanent solution (based on the MOJ contracts).

Update KEDBAs soon as the solution is found, the workaround or permanent solution should be Problem Management ProcessCopyright © MOJ. All rights reserved. Unauthorized copy or use of this document is strictly prohibited. Printed version of this document is only valid as long as the revision number and issue date correspond with the relevant information on the MOJ Intranet Portal/file system.MOJ does not warrant that this document is error-free.Printed version of this document will be treated as an uncontrolled copy.

of 22

Document1.2Version


recorded against the problem and KEDB should be communicated to the service desk/incident management team.Note: In some cases, the KEDB should be updated to assist service desk agents to efficiently identify and resolve incidents even if the diagnosis is not complete.

Change needed?In some cases, a workaround may require a change in the DT infrastructure. An RFC should be created when this occurs.

Implement solutionsThe process owner (Problem Manager), the technical/specialist groups and key stakeholders, should decide whether a permanent fix is required.Note: The time, cost, business impacts and technical risks need to be considered when deciding if a permanent fix is required. If a permanent fix is not required, the problem status should be changed to

“resolved”. This may happen when the impact is low, but the cost is high, and the frequency of occurrence is low.

If a permanent solution is required, the technical/specialist group should investigate the most effective and efficient solution.

As soon as a permanent solution is identified, a RFC should be raised, and the solution should be tested and implemented.

Software Development Lifecycle (SDLC) and change management procedures should be followed to ensure that the fix does not have an adverse impact on existing business operations.

If the problem has a high impact and high urgency, an emergency CAB meeting should be called to discuss and implement a solution.

The decision on the significance and what actions need to be taken to deal with the Problems based on business rules is determined as a part of correlation.


of 22

Document1.2Version


Correlation will consider previous occurrences of the similar or related Problems, the CIs involved, component involvement in the Problem to arrive at the decision.

Conduct post implementation reviews Problem Manager should participate in the post implementation review of all major

problem fixes. Note: Usually the change management process will initiate a PIR for all major changes to the production environment.

The PIR report should be produced and communicated to all key stakeholders. The PIR report should contain:a.) Lessons learnedb.) Technical point of view concerning how this type of problem can be avoidedc.) Feedback from other processes (testing, quality, change and release process) d.) Suggested improvements

Major incident process (recording, classification, escalation, resolution, and closure) should be defined and communicated to all stakeholders.

Major incidents should be clearly defined and documented to avoid any confusion.Note: Definition of major incident can be based on financial impact, reputational impact, number of users, customer affected or (and) disruption to critical business services.

Major incidents should take priority over all other incidents. Service desk agents should follow up on major incidents status and keep the users,

business, and senior DT management informed. Service desk agents should raise an RFC if changes are needed to resolve the

incident.

Send periodic reportsProblem Manager should produce periodic management reports and communicate to all stakeholders. Following are some management reports that can be produced: Number of problems


of 22

Document1.2Version


Number and percentage of major problems Problems by category Number of problems by status (new, open, closed)

Close the Problem Problem Manager should update the problem record (problem log/database) and

KEDB with all related details. Problem Manager should then close the problem ticket. Problem Manager should monitor the implementation to ensure that the solution

(fix) permanently resolves the problem and that related incidents will not occur.Roles & Responsibilities

ROLE RESPONSIBILITIES

Problem Manager (Process Owner)

• Defines and maintains the problem management procedure.

• Periodically reviews effectiveness and efficiency of the problem management process.

• Continuously improves the problem management process.• Coordinates with various support teams to identify the

root-cause of a problem and finds a workaround or solution.

• Ensures that the right resources are available to investigate, identify, and resolve the root cause of a problem.

Service Desk (Tool Owner)

• Ensures that service desk tool is configured and customized reflecting the problem management process aspects.

• Documents all relevant incident(s) details, setting categorization and prioritization codes.

• Utilizes the known error database in the diagnosis of Problem Management ProcessCopyright © MOJ. All rights reserved. Unauthorized copy or use of this document is strictly prohibited. Printed version of this document is only valid as long as the revision number and issue date correspond with the relevant information on the MOJ Intranet Portal/file system.MOJ does not warrant that this document is error-free.Printed version of this document will be treated as an uncontrolled copy.

of 22

Document1.2Version


incident(s)/repeated problem.• Escalates problem to suitable problem

coordinator/analysts.• Closes all resolved related incidents after solving the

problem.• Updates incident/problem management records with

accurate incident/problem details and history in a common repository that is linkable to Problem and Change Management. - Provides updates to the known error database as necessary

• Communicates with users, keeping them informed of problem progress.

Problem Solving Group (including all technical departments)

• Investigates a problem’s root cause and provides a workaround or a permanent solution

Problem Analyst• Assists the Problem Manager in data analysis to identify

suspected problems.• Assists in identifying required participants from other

groups to the Problem Owner and/or Problem Manager.• Under the direction of the Problem Owner, requests

information from supporting technical teams to facilitate the identification and validationof the root cause.

• Facilitates development of workarounds and short-term corrective actions for known errors.

• Facilitates development and testing of permanent solution.

• Records and updates problem and known error records Problem Management ProcessCopyright © MOJ. All rights reserved. Unauthorized copy or use of this document is strictly prohibited. Printed version of this document is only valid as long as the revision number and issue date correspond with the relevant information on the MOJ Intranet Portal/file system.MOJ does not warrant that this document is error-free.Printed version of this document will be treated as an uncontrolled copy.

of 22

Document1.2Version


with appropriate information.• Assists the Problem Manager in validating that the root

cause has been eliminated upon the implementation of the recommended solution.

Note: Responsibilities may be delegated or overlapped.

Critical Success Factors (CSF) & Key Performance Indicators (KPI)

The purpose of collecting, analysing problem measurements is to ensure that MOJ- DT services more effective and efficient. In addition, the reports are used to be summarized in a non-technical language and to show where improvements could be made. Keeping in mind the following measurements:a.) Total numbers of problems breakdown by week, month, yearb.) Breakdown of problems at each stage (e.g. logged, work in progress, closed etc.)c.) Size of current problem backlog, breakdown by day, month, year d.) Average time taken to solve aprobleme.) Number and percentage of problems reopenedf.) Number and percentage of problems that involved vendorsThe detailed reports will cover the main problems management process objectives (ref. to “Problem Management Objectives” section). So, the process owner may generate a report for each process objective to ensure that process is running as agreed and designed. The following recommended list of reports cover each CSF and its KPIs.Note: above reports details will be captured from the ITSM tool.

CSF

Key Performance Indicator Description (Equation) Note

Avoiding repeated incidents1 Number of repeated incidents = Total number of problems

logged in a period (Weekly, monthly, quarterly, bi-


of 22

Document1.2Version


annually or annually)2 Average number of existing

problems = Number of problems logged (per x) / Total number of problem tickets

X= (Type, category, Priority, impact, urgency or Service, person, …etc.)

Minimizing impact of problems4 Average time for

diagnosis of Problems ART = Total time taken to resolve (per x) / Total number of problem ticketsART =Average Resolution TimeX= (Type, category, Priority, impact, urgency or Service)

5 Average time for resolution of Known Errors

ART = Total time taken to resolve the known error/ Total number of problem tickets

6 Average number of Known Errors

= Total number of problems with known resolutions / Total number of problem tickets

7 Average number of repeatedProblems

Number of repeated problems / Total number of problem tickets logged

8 Average number of Problemsresolved by Known Errors (KE)

Number of problems based on known errors/ Total number of problem tickets logged

9 The percentage of chargeable Problem.

% CP = Number of chargeable problems / Total


of 22

Document1.2Version


number of problem tickets logged X 100CP – Chargeable problems

10 Average Number of problem closed Number of problems

closed / Total number of problem tickets logged

11 Percentage of problems resolved within the required time

Number of problems closed within SLA / Total number of problem tickets logged X 100

Service level should be implemented

12 Percentage of problems that missed target resolution time

Number of problems that missed SLA / Total number of problem tickets logged X 100

Service level should be implemented

13 Percentage of problems with available workaround

Number of open problems with available workaround / Total number of problem tickets logged X 100

14 Problem backlog Number of open problems for more than 30 days / Total number of problem tickets logged

Problem Management General Governance Considerations

The process owner should take the following IT Governance aspects into consideration while developing the problem management policy, these aspects may include (not limited to): Define problem escalation rules and procedures including technical problem-

solving teams especially for major incidents and repeated problems. Identify and describe relevant symptoms to establish the most probable causes, of

the incidents. Reference available knowledge resources (including known errors and problems) to identify possible problem resolutions (temporary workarounds


of 22

Document1.2Version


and/or permanent solutions). If a related problem or known error does not already exist and if the incident

satisfies the agreed-on criteria for problem registration, log a new problem. Prioritize service problems based on SLA service definition of the business impact

and urgency. Even if the problems that are not solved because either the impact is very low, or

the solution cost is expensive, the process owner should document them. Assigning problems to the technical solving group/team is needed, and engaging

the appropriate level of management, where and if needed. Selecting the best problem solving technical is the responsibility of the problem-

solving team and may vary from one problem to the other. Record whether workarounds were used for problem resolution. Document problem resolution and assess if the resolution can be used as a future

knowledge source.

Problem Management Implementation Considerations

The process owner should work with technical implementation team to produce the right service desk configuration and customization, the following implementation considerations will keep the implementation process smooth and cope with MOJ-DT problem management process, these considerations may include (not limited to):

Prepare to implement problem management. Define clear objectives and deliverables Involve and consult with DT staff Decide how problem management will interface with the service desk Decide who will take on the responsibility of problem management Decide how the service desk staff is structured, who will act as first line

support, who for second line … etc. Set the problem categorization and prioritization code for each problem


of 22

Document1.2Version


type.- The Impact may be determined by how many resources are affected

by the outage, on the other hand the process owner and service desk tool owner will decide eventually what the categories are:1. Critical – All users of a specific service. Employees from most

departments are affected and this has serious consequence on MOJ and need urgent restoration

2. Major– Multiple personnel in one physical location. Service is degraded and still functional but not operating within SLA.

3. Average– Up to ten employees. 4. Low – User himself.Impact – Urgency matrix

Priority Impact

LowAvera

ge MajorCritical

LowIssue not prevents the 4 3 3 2user from performing aportion of their duties.

AverageIssue prevents the user 3 3 2 2from performing a

Urg

enc

y

portion of their duties.

MajorIssue prevents the user 3 2 2 1from performing critical


of 22

Document1.2Version


time sensitive functions

CriticalService or major portion 2 2 1 1of a service is unavailable

Set SLA (time to response and time to solve) for each problem category. Decide what to measure and report, when and how.

References

• ITIL V3 Service Operations - Problem Management.• COBIT 5.0 – DSS 01 Manage Operation• ISO 27001: A16 Information security incident management

Problem Management Form SampleThe incident record should contain but not limited to the following fields:

Field name Field Description Info. to be filled by Type of Field

Record ID The ID of the record System String/NumberDate Date while ticket is logged User/

automatically

Date format

Time Time while ticket is logged User/automatically

Time format

Closure Time Time while ticket status is changed to "closed"

MOJ SD operator *

Time format


of 22

Document1.2Version


Total Time Closure Time – Time logged Automatically

Time format

Owner Name of MOJ service desk operator

MOJ SD operator *

Drop down list

Online Customer Name of employee who is logging in the ticket

MOJ User ** Drop down list

New Ticket Yes/No MOJ User ** Radio button

Ticket# if "Yes" in above field --- auto generate if "No" enter ticket no.

MOJ User ** Auto generate -

Logging Method Select one of (Phone Call | Automatically | email | Web portal | walk in)

MOJ SD operator *

Drop down list

Service impacted

Name of MOJ-DT service List of MOJ-DT services impacted

Service Number/ name

Refer Service Catalogue *** MOJ SD operator *

Drop down list (Service catalogue)

DetailsIncident details and symptoms

MOJ SD operator * Text box

UrgencySelect one of predefined category

User: refer to Urgency Chart Drop down list

Group Technical/Function group to which owner belongs to

Drop down list

Matching KE link to KE MOJ SD operator *

Drop down list (KEDB)

Matching PDB link to PDB MOJ SD operator *

Drop down list (PDB)

Status Status of incident life cycleMOJ SD operator *

Drop down list (Status)

Attachment Any supporting documents MOJ User **browse/attachment

*MOJ SD operator (MOJ Service desk operator) ** MOJ User (whether internal or external customer)

Note: This is a sample form and must be changed (or portion thereof) by process owner as per MOJ business needs.


of 22

وزارة العدل · Web viewThis document has been formulated to accommodate an “Integrated...

Documents

Transcript of وزارة العدل · Web viewThis document has been formulated to accommodate an “Integrated...