Welcome back! Hopefully you all had some great team discussions and made some decisions around your foundation data we talked about in Part 1 of the “Welcome to Remedyforce” Blog series. Remember as well in part 1 that we discussed a common pattern where a lot of customers begin their Remedyforce experience with Incident Management. So let’s go there!
From an Incident Management process perspective, remember the goal of this Service Operation process. The first goal of the incident management process is to restore a normal service operation as quickly as possible and to minimize the impact on business operations, thus ensuring that the best possible levels of service quality and availability are maintained. 'Normal service operation' is defined here as service operation within your service-level agreement (SLA). So keeping this in mind, let’s discuss how you are you going to design one of the key inputs of your process – the incident form!
Let’s first take a look at what the Remedyforce Onboarding Team has designed as a good starting place to help guide you in your configuration decisions.
Each section of the incident form is called a “field set” (denoted in this screenshot example by the orange bar). Field sets are configurable based on what type of information you would like to capture – and be sure you know what you want to do with the data you are capturing – are you reporting on it for example? If you're not, why are you going to the trouble of asking people to fill it out?
Let’s begin with the client details section of the incident form – what type of information about your clients do you want to capture?
Don’t forget to think about where your existing people data lives today and what your tactics are for importing that information into Remedyforce. There is some great information in the Remedyforce Wiki for importing user data into Remedyforce as well as a BMC Onboarding Team whitepaper that also provides guidance on authentication.
Now let’s dig into the incident details section - in other words, let get into what incident management is all about - what's going wrong that is causing you from being able to be productive?
You’ll notice category field is here (which hopefully you worked out during your foundation data discussions!). Obviously we’ll want a section to describe the incident details so Description field is a place for this but in this example, you will notice the red bar. This denotes a “required field”. It’s important to decide which of the fields on the incident form you are going to want to be required forcing your folks to populate those fields. Do you have an idea of frequently raised incidents that you perhaps want to design a Template for? Incident templates can be applied to help speed creation and next steps for an incident. What other pieces of information do you want to capture within the incident details field set? In this smart practices example, you’ll see Affected Application and Affected Hardware fields. Pause here to think about if you have services defined and if you have services decomposed to the configuration item level that will help you decide if you want fields such as these on your form as well as the form section called “Service and CI Details”. So even if you’re using some onboarding services, hopefully you’re starting to get the idea that it’s a good idea to have some dialogue with the stakeholders to have input into what type of information you want to collect from an incident management perspective. Let’s keep building on the form.
Once we collect the relevant information in the incident details section of the form, what else do we want to capture to help us meet the goals of incident management?
Well we know from part 1, we needed our foundation data element Queues hashed out and along with queues, you would have determined which staff members belong to what queues. Great stuff! And keeping in line with our foundation data, we know we have our impact and urgency matrix set up that determines the prioritization of our incidents. Moving right along now!
So let’s talk about status. Statuses are based on a state of “open” or a state of “closed” in Remedyforce. Open state statues might include:
- In progress
- Waiting for…
While Closed state statues might include:
- Closed/No Contact
I recommend you spend a little bit of time here because the use of statuses are important because they are used to determine how/when you want your agents to select/change the status to manage the lifecycle of the incident and are factors within the design of your SLAs.
Let’s take a look here at some smart practices content suggestions for statuses:
So to close the loop on the process goal (restoration of normal service as soon as possible) let’s end with the “Resolution section” of the incident form. This is important because you’re going to want to report on things like First Call Resolution (FCR) and perhaps Resolution Codes.
Have a discussion around the OOTB field called Closure Category as well do you want to add another field to capture perhaps a resolution code with things like “unplanned change” or “network outage (planned or un-planned” or “user enablement”, etc. etc.
I almost forgot! Don’t forget about the related lists section of the incident form located when you click on “Record Details” button. There are some other areas that you might want to consider from a configuration perspective.
So I hope you have found this blog informative and helpful as you work on incident management and going live with incident management. You can apply the same principles that I’ve outlined here for the other modules within Remedyforce such as Problem and Change Management: in a nutshell, the key themes are requirements within your teams, process design to drive your configuration decisions and strive to not over-complicate it!
Don’t forget you’ll want to be prepared to train your users on how to use Remedyforce once you’re ready to go with your design and configuration decisions. Check out another of my blogs that contains a template for a user training guide framework that you can use.
As always, the Remedyforce team welcomes your feedback. If you'd like to see this three-part blog series and want to include other blogs on other modules leave suggestions in the comments below.