...
When scheduling the change request implementing, it is notably recommended to avoid time overlaps, to not affect multiple services or CI's at a time. It is a good practice to follow the rule: "One timeframe - one change request."
...
| Option | Description |
|---|---|
| Implemented | This state displays that the change request was fully implemented. |
| Partially Implemented | This state displays that the change request was implemented with some exclusions that do not affect the critical functionality of the service. |
| Not Implemented | This state displays that the change request was not implemented. |
| Cancelled | This state displays that the change request was cancelled because of authorization failed or cancelled by the caller. |
| Backout | This state displays that the change request implementation was not successful, and the previous state of service (or CI) was restored. |
Priority Management
The priority of the Change Request can be figured out based on its impact and urgency using a priority matrix.
The impact of a change indicates the
...
potential damage (in case of emergency changes) or effect (in case of standard or normal changes) that will be caused to the business user or service or CI.
In SimpleOne, the impact can be categorized as:
- Low;
- Medium;
- High;
- Very High.
The urgency of a change indicates the measure of time
...
in the following cases:
- Until a change has an impact on the business
...
- - in case of emergency changes;
- Until change lack of implementing will impact the business services or CI- in case of standard or normal changes.
In SimpleOne, the urgency can be categorized as:
- Low;
- Medium;
- High.
Based on the priority, changes can be categorized as:
- Low;
- Moderate;
- High;
- Critical.
The priority matrix
Impact / Urgency | Very High | High | Medium | Low |
High | Critical | Critical | High | Moderate |
Medium | Critical | High | Moderate | Low |
Low | Critical | Moderate | Low | Low |
Change Template
...