Versions Compared

Old Version 11

changes.mady.by.user Tatiana Valekzhanina

Saved on

compared with

New Version Current

changes.mady.by.user Anastasia Suboch

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Problem Management Process

Problem Management is the process responsible for managing the lifecycle of all problems. The general purpose is to prevent incidents and to minimize the influence of those that you cannot prevent by identifying the unknown root cause of incidents as Known Errors. 

Within SimpleOne, the Problem Management solution allows users to perform the following types of process activities:

  • Identify and log problems.
  • Prioritize and categorize

Create a problem

Create Known Error

Add a new Time Card

Create a Problem Task

Create a Change Request

Create a problem

desciprtion...detection

Logging problem

Categorization and Prioritization.

Investigation and diagnosis

efedvdvdfvdvdv

Produce a workaround with creating a known error

dfbfbdf

Resolution and Closure

blablablablabalballba

SimpleOne Incident Management supports the incident management process. The system can:

  • log incidents;
    • classify
    • them by impact and urgency,
    categories
    • CIs and services
    ;
    • .
    assign them
    • Assign problems to appropriate persons
    or
    • and groups
    ;
    • .
    • Investigate and perform functional or hierarchical escalation if necessary
    ;
  • resolve incidents.

    • Here is a brief process description based on the state model.

    Incident Management State Model
    The states can be divided on the State Flow and Waiting statuses. The difference is that when the incident in the State Flow state (for example, In Progress), its SLA indicators are continuing to count down the time related to the incident processing. For example, it can be the time until the SLA breached (the Business Time Left indicator). But when the incident is moved to the Waiting status (for example, Information Needed), all SLA indicators related to the incident are stopping the countdown.
    • .
    • Produce workarounds to reduce problem affection and to keep system functionality running while searching for a resolution.
    • Resolve and Close problems with the objects related to them.

    Problem Identification and Categorization

    When detecting an issue, it is necessary to log and describe all the aspects of a problem. Create a Problem record for proper issue identification, and to log all activities and works on a problem.

    Categorize and prioritize a problem for a proper assessment of the impact on your system. These activities help to produce a sufficient resolution.

    Problem Investigation

    Use the Problem Management features to Investigate problems and objects related to them. Establish hierarchical and functional relationships with Incidents and Change Requests to identify the issue cause.

    Produce a workaround

    You can reduce or eliminate the impact of a problem that is impossible to resolve for any reason. Create a Known Error record to produce a workaround useful for the relevant problems and issues.

    Problem Resolution

    Initiate and produce the most appropriate Problem solution by the SimpleOne features. Create Change Requests and Problem Tasks that are necessary for problem resolution. 

    Problem Closure

    Verify completed problems to make sure that the issue has been eliminated and to Close the problems.

    Problem Management States

    Problem Management states allow users to monitor the problem processes, as well as control their investigation and resolution. Unlike Incidents, state values are available for every problem except the problems with the Closed state (it is impossible to reopen the closed problems). In other words, the Problem Management processes can be non-linear and require the ability to accept changes.

    State

    Description

    		Available Transitions
    RegisteredThe problem is detected and recorded but not yet categorized.
    • Assigned
    • In Progress
    AssignedThe problem

    State Flow

    ITIL Procedure

    Status

    Description

    LoggingRegisteredThe incident is recorded (via phone/email/Self-Service Portal) but not yet categorized.CategorizationAssignedThe incident
    is categorized and assigned to a relevant person or group.
    Resolution
    • Registered
    • In Progress
    • Postponed
    • Completed




    In Progress

    The person started working on the issue.

    • Registered
    • Assigned
    • Postponed
    • Completed
    Postponed

    The problem can be marked Postponed if the problem resolving should be postponed for a known period. If the problem affects business functions, then it must have at least a temporary workaround.

    Closure

    • Registered
    • Assigned
    • In Progress
    • Completed
    An incident is considered resolved when an
    Known Error

    An identified root cause of problems that have been analyzed but have not been resolved. An agent has come up with a temporary workaround

    or with

    of this cause as Known Error.

    Keep produced workarounds in the Known Error Database (Knowledge Base → KEDB) and apply them when related incidents occur.

    • Registered
    • Assigned
    • In Progress
    • Postponed
    • Completed
    CompletedA problem is considered resolved when an agent has come up with a permanent solution for this issue. In this case, he/she must change the
    status to Completed 
    state to Completed so that the caller could perform the tests. If the tests
    are successful
    are successful, then the
    incident
    problem should be marked
    as Closed; otherwise, it should be marked as Rejected by User
    as Closed. 
    • Registered
    • Assigned
    • In Progress
    • Postponed
    • Closed
    Closure
    Closed

    After

    the incident caller is satisfied with the incident solution, he/she

    completing a problem and verifying the issue elimination, an agent could close the

    incident

    problem (mark it as

     

    Closed

     and (optionally) evaluate the agent performance by grading "Agent Satisfaction" and "Service Satisfaction"). If the incident was not closed after it was marked as Completed, then it can be closed

    ). In case the agent hasn't closed the problem with the Completed mark, the system can close the problem automatically over an adjustable timeframe.

    Only the incident caller has the right to close the incidents; this is the best ITSM practice. But in SimpleOne, this rule does not affect infrastructure incidents. The incidents of this type can be closed only by the responsible person after performing the tests.

    Waiting Statuses

    ITIL Procedure

    Status

    Description

    Investigation and diagnosisInformation NeededIf the issue description is not clear enough, then the agent has to request additional information by changing the incident status to Information Needed. Once the information is received, the status has to be changed to the previous one.ResolutionPostponed

    The incident can be marked Postponed if the incident resolving should be postponed for a known period. If the incident moves to this status, then planned resolving date must be specified in the Resubmission field. But if the incident affects business functions, then it must have at least a temporary workaround.

    Functional escalationExternal ProcessingIf the incident solving requires 3rd party engaging, then, after referrals, the incident status must be changed to External Processing. And after this 3rd party engaging is over, the incident state and the assigned user should be changed to the previous one.ResolutionRejected by UserIf the caller is not satisfied with the agent work on the incident after completing it, then he can change the status to Rejected by User to address the defects.

    Info

    The Closed value is only available for selection in Problem records with the Completed state.




    toc
    Table of Contents
    maxLevel2
    classfixedPosition