Problem Workflow

The following figure shows the high-level Problem process workflow in the OOTB system.

Problem Workflow

1	Creator enters a Title, Detailed Description, Categorization, and Priority. When saved, the Problem is displayed on the Problem Management Dashboard to notify the Problem Management team of its existence.
2	Owner uses the Publish Known Error to Customer Portal Action. A One-Step Action posts the Diagnosis Field contents in the Known Errors section of the Portal.
3	Owner provides details of the Diagnosis and Workaround by submitting a Knowledge Article (KA), publishing in Portal, and/or emailing Customers. A One-Step Action creates a new KA using text from multiple Problem Fields. Text from the Workaround field is posted in the Top Issues section of the Portal. A One-Step Action sends a notification email to the Customers of linked Incidents.
4	A One-Step Action changes the status to Pending Change and creates a new Change Request record.
5	A One-Step Action makes the current User the owner, changes the Problem status to Resolved, and notifies Customers of linked Incidents.
6	A One-Step Action changes the Problem status to Resolved and sends an email to Incident owners (linked to the Problem) to notify them of the solution.

CSM uses several features to manage the Problem workflow (example: the Problem Form helps create and manage Problems, One-Step Actions help move the Problem through its workflow, Automation Processes notify stakeholders via emails, a Problem Dashboard notifies stakeholders and tracks metrics, etc.).

Contributors

A Problem typically involves the following contributors:

Creator: User who first logs the Problem. This is typically a member of the Problem Management Team.
Owner: User who manages the Problem. This is typically an IT manager who is a member of the Problem Management Team.

Phases:

The Problem workflow is divided into the following phases:

Classify: Creator logs a new Problem. Then, the creator identifies and classifies the Problem (Description, Service, Category, and Priority). The creator updates Customers via Twitter and links related Incidents to the record.
Investigate: Ownership is assigned. The owner begins work, investigates and analyzes the Problem, and then records a diagnosis. The owner updates Customers by publishing the Problem to the Portal, and then links Configuration Items (CIs).
Known Error: Owner develops and records the workaround. Then, the owner can update Users (by submitting a Knowledge Article to Knowledge Base) and Customers (by publishing a known error to Customer Portal, post to Twitter, or send email).
Resolve: Owner records resolution details and cause code. Then, the owner can escalate the Problem and/or log a Change Request required to solve the Problem (if necessary). The owner then resolves attached Incidents before resolving the Problem.
Closed: Owner closes the Problem.

Statuses

A Problem progressing through the workflow encounters the following statuses:

New: Problem is being logged, identified, and classified.
Assigned: Problem has been assigned to an owner.
Work in Progress: Problem is being diagnosed, investigated, and analyzed.
Pending Change: Problem process is on hold until a Change Request is implemented.
Resolved: Problem is resolved.
Closed: Problem is closed.
Problem statuses do not align with Problem phases.