Accelerating ITSM incident response with better data coupled with automation

Service Management teams receive far too many incidents with inadequate information, delaying effective response. In fact, if we really think about it, IT in general spends more time investigating and running down information than actually resolving issues. As part of our coverage of Cherwell's Global Conference (CGC16), let's take a moment to explore how this might be ameliorated. 

Let's think about a typical incident's lifecycle for a moment. It all begins when a user reports an incident, "I can't run my report in SAP." With only this information available, troubleshooting logically starts at the user's desktop, verifying they have network access, and that the local application is loading and logging in. After several hours the desktop is eliminated as our source of problems, and we move on to SAP itself. Six hours later, and after pulling over a dozen IT operators from their current tasks to aid in troubleshooting, we finally isolate the real issue; a batch job didn't run successfully, causing the report to return zero records. Remediation takes only a few seconds. In the meantime, an entire business unit has been unproductive for at least a day, and multiple critical projects are delayed because people were pulled away to work the problem.

 

Now, let's see what this same incident looks like with the combination of FireScope Stratis and Cherwell Service Management.  Hours before the user reported the issue, FireScope Stratis executes a periodic User Experience Check (UEC) that follows this user's workflow. One of the attributes being analyzed in this UEC is the size of the report output page, which returns far lower than is typically returned. A policy defined to look for user-impacting events that occur at the same time as downstream technical events (in this case, the status of the batch job) is now triggered, which causes FireScope Stratis to make a web service call to Cherwell to generate an incident. Included with this incident are the names of the two events that caused the policy to trigger, as well as key attribute data captured at the time of the event. The ITSM team now knows that a business impacting issue has occurred, they know the source of the incident, and it has already been routed by CSM to the SAP team to resolve. By the time the analyst in the first scenario has arrived for work, the issue has already been resolved and the work day proceeds without event knowing that an issue occurred.

 

In FireScope Statis' latest release, we've made some really interesting enhancements to this integration, bringing fully customizable field mapping for incidents. This enables you to have FireScope Stratis automatically populate any field – including custom fields – in your CSM incident. This is especially powerful when you consider the possibilities for workflow automation in CSM once it receives these fully enriched incidents, as well as what could be achieved via an mApp leveraging this data. 

Would you like to know more? Schedule a demo and we'd be happy to walk you through how it all works and just how quickly we can start delivering value!

Are you attending CGC16?

Be sure and drop by the Connect room at 2:45 today to see Eric Cook present "Improve CMDB Outcomes and Service Performance Management." Or, drop by our booth in the exhibitor area!