You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 11 Next »
Create Known Error
Add a new Time Card
Create a Problem Task
Create a Change Request
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 and services;
- assign them to appropriate persons or groups;
- 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.
State Flow
ITIL Procedure | Status | Description |
|---|---|---|
| Logging | Registered | The incident is recorded (via phone/email/Self-Service Portal) but not yet categorized. |
| Categorization | Assigned | The incident is categorized and assigned to a relevant person or group. |
| Resolution | In Progress | The person started working on the issue. |
| Closure | Completed | An incident is considered resolved when an agent has come up with a temporary workaround or with a permanent solution for this issue. In this case, he/she must change the status to Completed so that the caller could perform the tests. If the tests are successful, then the incident should be marked as Closed; otherwise, it should be marked as Rejected by User. |
| Closure | Closed | After the incident caller is satisfied with the incident solution, he/she could close the incident (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 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 diagnosis | Information Needed | If 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. |
| Resolution | Postponed | 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 escalation | External Processing | If 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. |
| Resolution | Rejected by User | If 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. |
- No labels
