Synapse Software
Is your ITSM system service oriented or object oriented?
Transcript
We like to design in terms of objects. It’s why paradigms and practices like object oriented programming have become so popular. We start with things and then enumerate the ways they relate to each other, the things we can do with them, and the things they can do to each other.
In Cherwell, this is encapsulated in business objects, relationships, and various types of One-Steps. In fact, in most service management environments, we’re thinking about nouns so much that the common workflows are named after nouns: incident, problem, change.
By giving things names, we’re able to design processes around specific items, because it just makes sense to think about the stages a particular object goes through and the transitions it makes through the process — again, all nouns.
But when someone calls the help desk to report that a printer isn’t working, what is it that they want to have happen? I’ll give you a hint — they’re not looking to create an incident. The incident is simply a mechanism we have developed to store important information about an event that happened. Even if we suggest that the desired outcome is resolving an incident — emphasis on the verb — this is still an object-centric approach because we’re talking about performing an action on the incident.
Taking this even further, we could assume that the root cause is that the printer is broken and that therefore we need to fix the printer. Wrong again! This is still focused on a noun, the printer, which is represented in our ITSM platform as a Configuration Item. As a quick aside, we may still need to fix the printer, but that is a secondary objective.
Instead, we should be focusing on the service: what is the caller trying to do and how can we help them accomplish that? Given that they’re reporting an issue with a printer, we can safely assume that they’re trying to print something. They could alternatively be trying to copy or scan something on a multi-function device, but let’s say we know from experience that people reporting issues with scanning and copying typically report those issues as “scanner issues” or “copier issues”.
So now we’ve ascertained that the caller’s objective is to print something. Let’s think of some ways we can achieve that objective. Of course, we do still have the option of fixing the printer, but that probably will take a bit more time and let’s say for sake of argument that we would have to involve another team. Instead, we can have the caller try to print to another printer. They may have already done this, so let’s ask.
It looks like they haven’t tried another printer, so we might help them set up a printer just down the hallway, but in order to make sure we’re not trying the same printer, we might ask which printer they used initially. Note that even though we need this information to eventually populate the incident and likely create a problem for the other team to fix, that’s not the primary reason we’re asking this question. The primary reason is to provide service to the caller.
Another quick aside — what if the caller said they tried another printer and been successful? Now we know that the caller’s objective really was just to report a misbehaving printer, so it would be within the context of this objective to ask which printer in order to log the problem.
Now if service management is all about providing a service and therefore about verbs, why do we even bother with the nouns? We’ve already mentioned one reason — to contain information that will be relevant for later reporting or essentially to keep a log of events. But the other more important reason is that sometimes we need some additional context to perform certain actions. The key here being that we don’t start with the context and then perform the action, we start with the action and use the context as necessary to inform some of the steps we might perform to achieve the objective.
So, how do we accomplish this in Cherwell? In your Cherwell environment you likely have several different Business Objects that your workflows are centered around, whether you’re starting from an existing system you’ve been using for a while, Cherwell’s Out of the Box content, or from something PSO or a Cherwell Partner has built. You’ll even notice that most functionality you can build in Cherwell – Forms, Grids, Automation Processes – have to be associated with a Business Object. Even most One-Steps are associated with a particular Business Object.
This isn’t necessarily a bad thing, and as we get deeper into the implementation we’ll find that it actually makes a lot of sense, but for now we actually need to take a step back and think just about how we want to provide services and possibly the specific services we want to provide. You might notice that service could still be considered a noun – and in fact there is a Business Object called “service” in Cherwell – but in this specific situation I think it’s OK to use a list of Services as a way to focus on specific workflows one or two at a time to avoid biting off more than we can chew.
Let’s go back to our printer example and start at the very beginning. Let’s pretend we don’t have an ITSM system. How might someone experiencing a problem with a printer tell us? One option is that they might want to send an email. Another is that they might want to go to a web site designed specifically for reporting technical problems. Maybe they’d also want to call someone?
There might be more ways people would want to report an issue with a printer, but let’s stick with these three for now. Given the conversation we described before, we can easily develop a workflow.
Once we have a flowchart like this, we can start to think about what tools we can use to provide each step of the process. To allow customers to send reports via email, we might use the Email and Event Monitor. To allow customers to report issues via a purpose-built web site, this sounds like a job for the web Portal. To allow customers to call in to the help desk, all we need is a phone number that rings a technician who can then continue with the process.
Now, without getting too far into the weeds, we can see that each piece of the workflow might need to be triggered in a slightly different fashion or have a slightly different implementation, so we can design each independently while still making sure we’re providing the same service regardless of how the report came in. Slides showing each of these are linked in the description below.
At this point, we can start to think about nouns, like Incident, Problem, and Configuration Item. We can also start to think about other aspects of the process that influence how we’ll carry out the workflow, like Priority, which in this case indicates how soon we need to get back to the customer based on whether or not they have been able to get their document printed.
Finally, we’re at a good point where we can start to think about other related workflows and really start to go down the rabbit hole. In the interest of keeping this video relatively focused, however, I won’t get into that right now, but if that’s something you’d be interested in me covering in a future video, please leave a comment below.
If you found this video helpful, please click that thumbs-up button and subscribe to the channel for more videos like this. Thank you so much for watching and I hope to see you in the next one.