- BDQ FAQ -
What is ITSM?
A practical example using Jira Service Management.
Ever wondered what ITSM is? Or what it might look like in practice, rather than theory?
Well, take a look at our video below, have a read through the transcript and hopefully, using our expert knowledge and Atlassian's Jira Service Management, we'll answer all of your questions.
There are also some Helpful Links at the bottom of the page that you may find useful.
And if you still have questions after, feel free to get in touch →
Our Cloud Burst videos are designed to give you a lot of information in a short space of time.
To help you absorb it all, we've also provided you with a transcript below the video.
Introduction
Ever wondered what ITSM is or what it might look like in practice rather than in theory? Well, stay tuned - we're going to go through it. We're going to show you what ITSM looks like in practice inside JIRA service management.
My name's Chris bland. I'm a certified Atlassian Master with BDQ, an Atlassian solution partner in the UK. And today we're going to talk about ITSM and Jira Service Management.
So, what is ITSM? ITSM stands for IT service management, and it's an approach that was developed really by an organization called ITIL. And it's all about giving IT teams a more structured approach for delivering IT services to their customer. Back in the day, it may be just be that you had a shared email box and the requests simply poured into that box. And then people have to sort of deal with them as they came in. IT service management, as the name implies, brings structure to this. And it recognizes the fact that actually there's different types of things that an IT organization might have to do. And the scope is quite broad, but we're going to talk about four key things here and how JIRA service management deals with them.
So the four key areas, sort of categorizes if you like what an IT team often has to do:
-
Service requests which are sort of run of the mill things, such as, you know, getting somebody in new phone
-
Incidents which is basically when something has gone wrong or is unplanned and it has to be dealt with.
-
Change requests (change management, if you like,) when somebody wants to change something and that needs to be approved and maybe go through a sort of more strict process.
-
Problems and a problem really represents, some sort of underlying issue. So for example, if you constantly had a series of WIFI incidents, it may point to a bigger problem with your WIFI architecture for example, which needs resolving.
But by trying to categorize these areas, if you like, it can make the whole process of managing IT, and delivering your services more straightforward.
Now, inside JIRA Service Management, these concepts are usually represented as particular issue types with their own workflows. On top of that, you also have the concept of your request types. Which is just really a way of presenting information in a slightly easier fashion to customers using the actual web portal.
So for example, you might have a request type for a new phone or a request type for a new PC. But underlying it all, it's a general category of service request, right? But it makes it easier for the end users to actually find what they want. And you can sort of select the fields and so forth to make life easier.
So we're going to take a look at some of this in the demo that's coming up and you'll also see how categorizing things in this way makes it easier to basically report and manage on the process. Let's head over to the PC to take a look.
Demo
Okay. Let's have a look at how Jira Service Management helps to implement ITSM. This is going to be very, very high level.
We're going to really just talk about how service requests, problems, incidents, change management - how that's actually implemented within JSM, how it gets exposed to our customer, how agents see it and how it can help you categorize your work to make to make your life much, much easier when trying to basically do IT service management.
So what we've got right here is the customer portal. This is the view the customer gets, and right now we can already receive, see, as far as the customer is concerned, there are some basic request types that they can fill in on the screen. Now whole purpose of this is your customers shouldn't need to know about ITSM, it should be as easy to use as possible.
So I don't need to know about ITSM, I'm just going to say actually I just want a new account, um, for testing. I'm going to choose the system I want to on the I'm going to put on AD (Active Directory) and send. There we go. I've now got my request in the portal. I'll get an email, letting me know of any updates to do with it.
Let's go and see what the agents see. Let's have a look. There we go, we've got a new open ticket - our user has asked for a new account. That of course was us just now. So already, if we have a look here, I've got the idea of some preset queues for me. You can put your own in, this can be configured however you want, but it comes out the tin if you're using ITSM - service requests, incidents, problems, changes. It's very nice, it even has a change calendar, as well it’s a new feature. We'll cover that in another video. So those are some of the four key things of ITSM.
So your user didn't have to know about ITSM, they just asked for a new account, but if I actually go and have a look of this issue, we can see that this request, the type that they made is actually in fact, a service request.
And it's in a particular state at the moment. So I could now start doing some work on it. I could say, yep - I'm going to pop in “Progress”, I'm going to assign it to me and say, I just need some more details.
And the we’re starting to do all our usual sort of service desk type activity, but this is all about ITSM. Okay? So, what we can see right now is as an agent, I'm dealing with a queue and I'm dealing with a service request issue type, and that service request has actually got statuses that are of use, and have been tuned for particularly use in the ITSM service request workflow. Again, this can be changed, as per your requirements.
Let’s have a look at actually how this looks. So we can see that under this ITSM demo, there are a whole bunch of different service requests, and these are the things that your user will see on the actual portal. So it just makes life easier for them to sort of, you know, create requests. And you should really, really think about what your users need when you configure the service desk. It's no good having it completely at odds with what they might want to do, because they're going to find it difficult to use. And that's no help to anyone. So what we're doing is we're just making it easy to do ITSM here!
As we can see, we've got some core issue types, just “service requests”, and then we got “service requested with approvals”. And I've actually got “Incidents”, “problems”, “changes” - all good ITSM things. And actually what we're saying here with these request types is these are how they're actually exposed to users on the portal.
So this particular case I've got “fix an account problem”, “get a guest wifi account” where they're all types of different service requests, nice and straightforward, easy to understand, easy to manage. Now let's have a look in a little bit more detail about how that’s actually set up within the system.
So I'm actually looking at the underlying issue types being used here to implement ITSM -change, incident, problem, service requests. Now you might think, well, okay (And we do cover this by the way, in another video about Change) there's things like “standard”, “normal” emergency change. You could do those as types of changes, but instead we've actually opted to do them as a particular workflow all within the overall change issue type.
Let's have a look to see what we mean about that. Well, if we look at the change management workflow, for the change issue type, I can see it's got lots of stuff in here that looked really specifically to do with changes. So, if I'm looking at reports, I'll be able to see what's in “planning”, what's waiting for authorization, what's awaiting implementation and so forth. Whereas actually, if I have a look at the workflow for “incidents”, we can see - completely different! And this one is tuned for incident management. Now, we can add our own statuses and our own transitions, depending on how it is you want things configured for your organization. Furthermore, we can actually decide who's able to do these transitions. For example, it may only be that a manager can authorize or approve something. Everything is also captured in audit trails, but that's getting into a bit more of the detail of it.
Suffice to say that JIRA Service Desk or JIRA Service Management is now called, has within it out of the box, the four main types of activity for ITSM, Service request, Incident, Problems Changes
As in - [Service Requests] regular things people want to do. Incidents - well these are things we've got to deal with straight away, usually something that's happened or unplanned. Problems - I can indicate a long running problem, such as maybe if we have a whole bunch of incidents regarding WIF coverage, it may actually point to an underlying problem with our WIFI architecture, for example. And then Changes - whereas we actually want to do change management to the system.
And how this is actually implemented or how it works in JIRA Service Management is that we have these associated issue types with these various types of ITSM category. And then to make it easy for our users to use, we have additional request types that sit over the top of those in the portal.
So if somebody (one of our users) are entering in, as I just showed you, a request for VPN, for example, it already gets pre-categorized for us and therefore, it’s easier to work with.
There is of course, a whole ton of reporting around this as well. For example, things that have been “created”, “resolved”, how long things taken to fix, whether the SLAs have been met, so on and so forth, these are configurable, as you might expect.
Summary
Anyway, let's just round off.
Key thing to remember here is that JIRA Service Management will help you implement ITSM. We can see right in front of you very simply here are the core ITSM constructs. Your team can see them very simply. You can see what's being worked on where, by whom and it's easy for your customers to enter them via the portal.
Well, I hope you enjoyed that demo and I hope that short overview gives you an idea of what ITSM is, how it differs from the old shared mailbox and more importantly, how JIRA Service Management can actually help you implement it and make it a reality.
If you want to ask any further questions on how it works or anything that's come up as a result of you seeing this video, please get in touch.