I recently had a client who had a very forward-thinking vision for how they wanted to handle outages at their organization. ServiceNow does have an outage table OOB, but it is just begging to be taken to the next level. Building this solution was a lot of fun and brought out some of my favorite abilities of ServiceNow. In this post I will show you some of the creative enhancements we made, how we tied it to Incident and Change, and explain how organizations can benefit from implementing outage into their ServiceNow instance.
Improve your Incident Management Process
The first major improvement we made to outage was make the “Create Outage” UI Action a popup window instead of redirecting the ServiceDesk Analyst to a new window, losing the incident they were working on. The goal was to have the analyst quickly and effectively report an outage. We automatically pulled in the CI, Task Number, Begin Time and Short Description with “Outage:” as a prefix.
Communicating an Outage
Now that we have created an active outage, how are we going to communicate that to our other helpdesk analysts, IT staff, and end users? Well, we did it a couple of different ways.
1. To alert the ServiceDesk analyst in the incident form or an end user submitting an incident via self-service, if they choose a CI that has an active outage associated with it, we display the alert below. We also make the CI field red if the incident form loads with an affected CI populated in the Configuration Item field.
2. To notify our end users that we have an outage, we automatically create a knowledge article with the category of “News”. That way the scrolling “news” gauge on the homepage is automatically updated with this article. The knowledge article is also automatically ‘retired’ when the outage is closed.
3. To notify ‘stakeholders’ we added a notification to automatically send to the owner and support group of the CI if the outage was not planned.
Leveraging ServiceNow’s Automation Capabilities
If you haven’t been able to tell yet, I am a big fan of automating process wherever possible. Another automation we implemented was automatically closing the outage when the originating incident is closed.
Improve your Change Management Process change
Similar to our Incident outage process, we have implemented an outage popup window invoked by a UI action. However, we have some customizations tailored to change management. First difference is the type of outage being ‘planned’. We also pull in the Begin and End time from the ‘planned start’ and ‘planned end date’ from the change form. Now in this case, we are creating a planned outage for a month from now. The outage is not yet “active” because it is scheduled to begin on 3-19-2014. Now when the day and time comes that this outage is in fact “active” we do not want to rely on a ‘human’ to mark this outage as ‘active’. We want it automated! How do we achieve this? A scheduled job! We created a scheduled job that is constantly checking the outage table to see if the current time falls in between the begin and end dates of any outages. Now our SD analysts and self-service users will be alerted if there is currently an active outage on a CI they try to open an incident for!