Avoiding unplanned outages during Change implementations
EdWhitehead 060000K9FR Visits (1455)
Unplanned outages are expensive and can lead to service level agreement breaches. Wouldn’t it be nice if you could know which Changes will cause an unplanned outage before they cause the outage? SmartCloud Control Desk can do just that.
SmartCloud Control Desk runs analytics every day and identifies any Change whose implementation schedule has a schedule conflict. Three types of schedule conflicts are detected. First, whether any affected CI will have an outage outside of its Change Window. Second, whether any Blackout Period will be violated. And lastly, whether multiple Change implementations will be affecting the same CI at the same time.
When analyzing Change schedules, the analytics takes into account not only the configuration items (CIs) which will be modified by the Change (the target CIs), but also any CI which will have a service outage during the implementation (impacted CIs). Why is this important? Take the case where a Change implementation will take a computer system offline. What if there is a database server running on that computer system which is needed by a critical business application? It may not be obvious that a service running on that computer system is needed by an application running elsewhere. As a result, the Change Window of that critical business application wasn’t taken into account when the implementation schedule was proposed. No need to worry, because the schedule conflict analytics will see the dependency and report the Change Window conflict.
Similarly, what if a Change to upgrade the database server running on the computer system was scheduled to be done at a time when the computer system will be offline due to another Change implementation? Clearly, that software will not be available to be upgraded, so that Change implementation will either be postponed until the computer system comes back up (thus potentially slipping outside of the Change Window), or have to be rescheduled (thus causing extra work for the change advisory board to discuss and authorize it again). Again, the schedule conflict analytics can identify this issue as soon as schedule dates are entered on the Change records, so the conflict can be resolved before it happens.
Occasionally, these schedule conflicts are intentional. For example, making several updates to a computer system while it is down. In these cases, schedule conflicts can be marked as approved. Once a conflict is marked approved, it will be ignored by future executions of the analytics.
There are several ways to view the results of the schedule conflicts analytics. There is an IT Changes with Schedule Conflicts report. As with any report, it can be scheduled to run automatically and be delivered in email. Another way to view the analytics results is in the Schedule Conflicts section on the Schedule tab of the Changes application. The section lists any identified conflicts, has a button to execute the analytics on demand, and is also where a schedule conflict can be marked approved. Lastly, any Change with a schedule conflict will be displayed in red in the Change Schedule application.