ServiceNow Webinar Insights on Incident Management

Okay, right. Good morning, good afternoon, good evening, wherever you are in the world. Thanks for joining today's Live on ServiceNow webinar, where we're going to be talking about incident management and its relationship with CSDM, hoping to give you some tips on how to optimize your implementation when it comes to incident management and get the most out of the power of CSDM through the ServiceNow platform. So just to get started, a couple of things just to be aware of. So the first thing is that... We may cover some forward-looking statements on behalf of the ServiceNow product today. And just to let you know, anything that's not on our current GA release, anything we show that may be future capabilities are subject to change. So this is part of a series of live on ServiceNow webinars. They're an interactive event series covering lots of different great pieces of information, lots of great speakers from ServiceNow, from our trusted partner organizations and more. The schedule link will be shared in today's chat. So if you want to attend more sessions or learn a bit more about the catalogue of events we have coming up in the next couple of months, please click on that link and it will take you to a location where you can find all that information. So just a couple of things before we get started today. So there will be plenty of time at the end of the session for Q&A. Please use the Q&A section within the chat if you want to ask a question rather than the chat function. We'll be monitoring. the Q&A specifically for questions. So if you want us to pick that up live or afterwards, please make sure it's in the right section. We're going to share this presentation and it'll be available on the ServiceNow community. So if you have to step out for a moment or you've got someone you want to share it with, we'll make all the links for that available after the session. And feedback is a real gift for us and we'd love to hear how you feel about the session so we can make sure the next one's even better than this one. So you will be asked to fill out a short survey at the end. Please don't ignore it. please fill it in because the feedback is hugely vital to us to make sure we're providing the best experience on these sessions. So I'm going to introduce who will be speaking today. So if you haven't guessed already from the pictures there, I'm the one in the middle. My name is Scott Gamble and I'm a principal. I work within our leading practices organization within ServiceNow. I've done a lot of stuff within ServiceNow, a lot of IT operations management, and my job is to help maximize success when it comes to implementation. I'm joined by my esteemed colleague, Chris Shakespeare, who is veteran of ServiceNow, 13 plus years of experience. And we both share the same mission to make implementation for customers, partners and our whole ecosystem as smooth and efficient as possible. We both specialize in IT service management. And I'm delighted to be joined as well by Ryan Deuce at Flyform, one of our trusted partners. Ryan is a colleague of mine that we've known for quite a long time now. And we've been working together with customers, a number of different challenges within the ServiceNow space. And Ryan's a great asset to have on our team. So thanks very much for joining us today, Ryan. It's great to have you on the call. So this is what we're going to cover today. So we've done the intro. That's covered off already. I'm going to dive in a little bit into the basic definitions and terms that we're going to use today. Many of you will be very experienced in your CSDM journey. Many of you will be just starting out. So this is a level set to make sure that everyone who's on the call kind of understands what we're talking about as we dig in deeper throughout the session. My colleague Chris is going to cover some great information on data driven decision making to help you make the incident logging process and incident management process intertwine well with CSDM. Ryan's going to take over at this point to do a demo to show you what this looks like inside the platform. And then at the end, we'll have our Q&A and we'll have plenty of time to also discuss takeaways and information that we want you to leave with today. So by the end of today, hopefully we're going to give you a good overview of the leading practices around integrating incidents with incident management, the CSDM, laying the foundations for service portfolio management, digital portfolio management, CNBB, all that great stuff. And also we want to specifically hone in on the use case of first-line agents, people in service desks, customer support teams, how they capture and record incidents so they align with CSDM first and foremostly, but also reducing your data entry time, maximizing the capabilities of that kind of single control tower platform that we have. Ultimately, practical terms will show you how to configure your incident process to align with CSDM practices and principles. So touching on the basic definitions, I'm going to cover a few things here in kind of a high level view. Let me know if there's any questions in the chat as we go through. We'll pick those up towards the end. So. Let's start by looking at what service is and how we define that. So for us, service is a means of delivering value to customers, and that's by facilitating the outcomes customers want to achieve without the ownership of specific costs and risks. So when we think about a service, we're thinking about something that a customer might understand in their language, something that they might refer to. I've got some examples in a minute to kind of dig into that a bit further. A service offering is... a unique service commitment that sits underneath the service. So for example, if you're a service provider, you might have a platinum, gold, silver, bronze level of service where you get a certain resolution time or a certain response time. This might be the same core service that you provide as a customer, but those offerings differ depending on what level of customer is paying, what kind of perks they get, et cetera, et cetera. So it's a really good way to subdivide a service. into distinct offerings with different service commitments, SLAs, etc. And the CI is the Lego block right at the bottom of that, right? So the CI is the computers, the devices, the software, all of those items, both logical and physical, that sit inside your CMDB and normally form the foundation of those service offerings and services. So it's a good way to look at it from service on the left being the biggest scope all the way down to those individual configuration items on the right-hand side. So within services, there are three core different categories when we talk about services. And this is probably, and I think Chris and Ryan, you'll probably share my thoughts on this, probably one of the most common questions that we get asked as ServiceNow implementation experts is, what's the difference between all these services? I must admit, when I started on my journey, I found this confusing. So I've tried to put it in the clearest possible way I can, the way I got it, and hopefully it will help you too. So starting off with a technical service. A technical service is published out to service owners, people who own the overall services, and it underpins that business or application service, which we're going to touch in as we go down. So if you think about something that has operational CIs and something you potentially use as an impact registration for incidents and maybe something you'd approve for a change. So the way I've described this is something like a mail server. You might have 10 of those in your estate. You might have 100 of them. all running a mail server application. An application service is a logical representation of a deployed system or an application stack. So what we mean by that is that it usually consists of one or more operational CIs, so like multiple mail servers for example, and the applications and hosts configured to offer a particular service. This is as we're transitioning from the kind of bare metal, the core components, through to a service value adding piece of equipment. Microsoft Exchange is a really good example of that. So you have a number of mail servers that form the Microsoft Exchange task. Now, you know, not everybody who works for an organization would know what Microsoft Exchange means. So that application layer is very specifically for people within an organization who are technically operating or operating particular services, normally the people that sit within IT. And then finally, we have a business service. That's the service, the front end service that's available to. business users or customers. And that underpins one or more business capabilities. So when we think about capabilities, I'd give you an example of maybe communication, right? How do you communicate across a business? But you need the capability to communicate with your customers, with other departments. And one of the methods we do that is through email. And email is a business service that runs on Microsoft Exchange as an application, which then is backed up by technical services, such as mail service. So a business service is published to business users and it's user or customer focused. So it's going to be in terms they understand. And quite often we see organizations adopt business service terms. You know, Outlook is a good example of a mail application, right? But, you know, how often do people say my email application? They will use a brand name like Outlook or Teams or Slack, etc. So we're not always in charge of what the business calls a business services. So when we talk about creating incidents and the specific context of the use cases we're covering today, we're talking about three distinct personas. So we're talking about the user persona, so that would be someone who is a customer or a user logging into a portal, ringing up your service desk who wants to log an incident or an outage with a piece of equipment that they have. You then have IT. As an analyst, as an engineer, as a help desk member, how am I using the incident management process and how am I integrating with that? And then finally, you've got the system area. So how are systems communicating with each other? What's happening in the background as we log incidents and relate them to the relevant services and other things that exist in our business's ecosystem? Alignment with CSDM simplifies the process for all of these personas. So your system-to-system, your IT-to-user, all that stuff becomes simplified when you have a handle on the data through your CSDM. So it's time for me to take a break. I'm going to hand over to my colleague, Chris, who's going to take you through the data-driven decision-making process with incident management. So over to you, Chris. Thanks, Scott. And I'll just swap screens and pull up the presentation. So we should be... There. Okay. Right. All good. So thanks to Scott. I mean, there's a lot of definitions thrown at you, and there's a lot of materials out there from ServiceNow that talk to CSDM, CMDB, the various services available, technical application, business services. A lot of that material is out there on. Now Create. So if you haven't been out onto Now Create, please have a look. Obviously, deeper dives than we can go into in the session today. But really what we wanted to do in this section of the webinar is take you through data-driven decision making and really look at how we can enhance the incident management process to consume the data, those services that Scott was talking about and also simplify the life of the agents. Because I think, you know, out-of-the-box service now gives you lots of opportunities to enter data, but also that also gives opportunities to make errors. So some of this is really just to streamline the work that those agents do and make it easier for them. And, you know, ultimately... hopefully give you a path where you can start automating some of this so that you're not having to manually enter that data but rather the system can start driving some of that work for you. So what's that look like a little bit more? Well we have really five recommendations we're going to drill into each one through this section of where we feel that that whole process can be streamlined. So starting out with service offerings and linking those to services and making sure it's consistent with CSDM is for us one of the most important steps. Now, I think that in itself can be potentially daunting. And we usually say to customers is you can really looking at your business services. There are probably five or six key services within your company that. you would want to represent. And those are the starting points. It's not to build out a huge business service catalogue. It's what's the critical items for that. And we'll dig into perhaps how they feed into incident management later on. Scott touched on the personas. And really, there are three key personas that we're calling out today who raise incidents. There's the agents themselves, those... those people working on the service desk, IT staff, so people out in the field who need to raise an incident, and ultimately machine to machine, those system generated ones. It's important whenever you think about incident creation that you cater for all those three bodies. Those are the main ones and obviously there's nuances. Underneath that, if we take system generated, that can be from event alert systems. It can be from other areas as well as we dig in. Out of the box, we mentioned that the incident form itself allows for lots of data entry. There's an example on the screen at the moment. So if you get all that right, it gives you a very rich environment to... work on the incident but also yeah anything you have to fill in is potentially time consuming and potential for error as well so if we can streamline some of that then reduces time reduces error incidents on the incident itself so we're going to look at what that would look like in terms of the incident form to reduce those opportunities and and a lot of that revolves around repopulating the service offering first and deriving information from that such as the the service so that again you're reducing the elements that you're entering and also you're being contextually relevant especially to the agent so the more likely for example to to have an idea what the service offering is and working from that route So let's dig in and see a little bit more of what this looks like in practice. So we mentioned about getting started with CSDM and especially around the service offerings and services. And, you know, even within the basic ITSM for ServiceNow is you've got. service portfolio management. So you've got a lot of capabilities sitting in there to be able to build out those services. And later on, you know, things like digital portfolio management really allow you to extend not just within the ITSM space, but into things like SPM with application portfolio management and others. But starting small, getting your arms around those key services is the... place to go. There isn't one single model that suits all. And I can see, you know, in the chat that was happening, there's a lot of discussion around technical services, application services, where to start. So it's hard to be totally prescriptive of the right place to start. But I think, you know, starting at that top level, starting at those key business services. and then deriving service offerings from those generally suits majority of the customers to get them going and moving forwards. And that allows you to then start extending beyond there ultimately into service owners, service performance metrics, and the other things which come from having that mindset and approach. Obviously, if you've got... The other side of the coin is the CIs that incident management is dependent on. You don't want to be manually discovering those and entering data from spreadsheets. You really want to be having a tool like discovery or federated data from a discovery tool that's going to help populate that CMDB so you can consume that data within your. incident management process and relate it to those services and one of the things that we do recommend is out the box there are no principal CIs designated so you can pick anything in the CI field and that you know can be pretty daunting and also with the scale potentially the data set is again it's time consuming and potentially error bound. because it's time consuming, you're looking for something. So we recommend starting out by designating a set of principal CIs, which essentially down filters the available data for the incident management. And so we always recommend, you know, reducing it and the type of recommendations around application services, servers, computers, you know, the main infrastructure items rather than perhaps end user. compute a lot more detail in the CMDB process guide on Nocreate, which is one of our top downloads, unsurprisingly. So a lot more detail in there. And ultimately, this really helps because what we're saying is we're looking at the service offering. links into the service, the application services. It's often the CI, and we've seen some chat around there. And you can also derive the assignment group. It's either the support group for the service or it's the support group for the CI. And we'll see a little bit more of what that means in a moment. So we talked about the three use cases. And this is a sort of raised up version of the standard form today. And this is what you get to sort of fill in is service, service offering, the CI, the assignment group. And so having the data available is really going to simplify the. population of this and again reduce the level of error and where we want to go with this and the recommendation is the service should be derived from the service offering the CI should be down filtered and appropriate for the service offering that you're raising essentially instant for and the assignment group should be again either from the CI record if you have a CI and not all cases you'll have a CI And we've got some examples which demonstrate why that might not be the case. Or the service offering itself has a support group. And if you haven't got a CI record, then the assignment group will be derived from that service offering. So moving on is we would recommend that. the instant form itself is configured so that essentially the service field becomes read only. The service offering is the main field that you would fill in and that the service then is derived from the service offering and we add in the CI classes and Ryan will show you what this looks like in practice. in a demo that we're going to show shortly. And ultimately is if you do all that, when you get a form which looks a bit like this, this is the UI 16 form. We're very keen that people adopt Workspace because it provides a very rich environment. But the principles here that we're talking about in terms of the... the form you see in front also apply to the service operations workspace and the same same changes apply so and basically you you end up with the service offering driving the service configuration item all the service offering driving the assignment group for that and all this ultimately is still within the framework that CSDM provides. And this is very much a cut down view of CSDM, but this is with a lens of how to make incident management more efficient. And you can see here, we've talked a lot about the business service and the business service offering. And ultimately, that's linking through to the application services it's got uh it's got mentioned and they're linking through to the cis obviously the white paper is much more comprehensive but in terms of moving forwards and trying to cut this down into something that's consumable within the itsm space we feel that this can do that for you And this holds true, as we mentioned before, is very much about the agent fills out the service offering, but populates the services filled out on the basis of the service offering, etc. And you can see that we're still respecting the hierarchy that's within CSDM. And... That's a 30 on the instant form. And that's important that we, although we're modifying the form, we're staying consistent with the overall framework that ServiceNow is recommending for its data in CSDM. It's really about improving the efficiency of the consumption of that data for a particular process rather than changing the data to suit the process. So we're underpinning our process. by data that's scalable, not just into incident management, but also, as we mentioned, ultimately into more service-orientated business. So when you get into things like application portfolio management and other areas like DPM is you've still got that consistent approach and you're not having to change other applications to meet. the changes you've done in the data structure itself. So staying consistent with CSDM is a key principle of this. It's a streamlining of that consumption in instant is really one of the key things that... um we want a takeaway from this so auto populating the service i mentioned that not everything has a ci so if we take you know and then use a computer and i mentioned that you know probably not the place to start with the um in terms of cmdb but you know it can be something that's appropriate for your business in this case you see example where Just imagine the caller has phoned up about Adobe Acrobat, in this case, on their device. So that's end-user services, and the configuration item is their own end-user compute device. In this case, it's a laptop that they've got allocated to them. A slightly more common, well, not common, but... Different is probably a better word. In this case, Salesforce is, again, it's end user service. But because it's a cloud native application, you don't really have visibility into CIs. So the CI is going to provide limited value for that. So in this, you're heavily orientated around using the service offering and the service to help you with the incident and ultimately resolving the service issue that comes. from there so in those cases you wouldn't necessarily have the CI and in that case the assignment group would be populated from the service offerings support group rather than the CI's support group because you haven't populated and finally you know something that's quite common on a service desk is you might know the service which is at fault in this case and we've got a problem with the service offering ground inventory management But at the starting point is you don't know what CI is at fault. And, you know, it's potentially a long list of candidates at that point in time, unless perhaps you've got an event management system that has flagged it up and said, you know, maybe the server's overheating, running out of space or something like that. So often you'll start out with the CI unpopulated. Later on, you will be a population of the CI. once you've done some triage and diagnosis around that incident. And in those cases, you may well be raising a child incident because you're addressing the issues with a technical service offering and you want that group who are responsible for a technical service offering to be looking into that, and you've still got ownership on the desk of the overall incident that's related. to there. So that's very much trying to use data to drive the incident management process to minimize where possible the amount of manual entry into the incident form and by doing so try to remove potential error in that process. So ultimately you can take a step forwards from this as well. So this is almost the traditional, the classical view of managing the data. But you can also then, if you have that data available, is just a touch on how you then can drive some of those fields that you are manually populating, like the service CI, the assignment groups. We talked about how perhaps the agent was entering it or it'd be generated by a machine is If you've got good data and you've got confidence in terms of the relationships between services, service offerings and the group supporting them, you can extend that data orientation and the use of the data inherent in the system for things like task intelligence, really taking that data set and removing the manual intervention that you were previously doing for it. So you can start out with making sure you've got those services and those critical services when the business identified. You've got healthy CIs available. You've got your support groups. You minimize the manual entry for your agents or the system to populate. But ultimately, you can extend beyond that by having that data by driving the... the organization through that data inherent in the system. You can even remove some of those steps later on by... taking capabilities such as task intelligence and really getting that to drive from there. So it doesn't stop. It's a level of where you are and what maturity you have for that. So I'm going to hand over to Ryan now, who's going to show you what this looks like in practice. I've seen a lot of PowerPoint and I'll let Ryan. but bring it to life from an agent's interaction perspective. Perfect. Thank you, Chris. So let me take over the screen share. Hopefully it'll be a nice, smooth transition. And hopefully you can see the service operations workspace on screen. So I'd like to take you through the simplified way that an agent might raise. an incident using the methods that we've seen so far. So if I go up to create my new incident from the top of the screen, I get my service operations workspace form here. So I'm just going to say something like my laptop is broken. I'm going to enter my caller. So my caller is And then down here you can see that in my assignment section I've got my services read only. So we're only asking our agent to select a service offering. And you can see down here we've got these service offerings aren't necessarily understood by the end user. They may be understood by the agent but the end user won't necessarily know what these mean. So if I start typing in employee laptop. Then if I select this offering, then I immediately see that we're using relationships in the CSDM to populate other things on the instant form. So we know that the parent service is end user computing, so we can populate that for the agent. That's one fewer click the agent is doing on the instant form, and you think if they're raising 30, 40 incidents a day. every click saved is quicker, mean time to resolution and happier customers and fewer errors as well. That's also worth bearing in mind. And then we also know that the employee laptop is a service offering that's being supported by the hardware group. So that is listed as the support group on the service offering. So if we've defined our services and we've defined the groups that support those services, and we've done that. at an organizational level, then we should really be helping the agent populate the fields that they need on the instant form with that service portfolio that we've built up. It's meaning that the actual effort we put into to get that data into the system and get owners for all of these service layer CIs does actually go towards making those data-driven decisions that Chris talked about. making the agent's life easier. And then I'm going to look at my configuration items. And if I select that the computer is my configuration item, that's the actual exact thing that's gone wrong, you can see that the assignment group hasn't actually changed because the support group on the configuration item is the same as the service offering. but this is the most specific item of this stack that we're selecting. So if there's a support group on the configuration item then we want that to be the support group that is assigned to the incident. And so that's a little bit of a preview of how you can use data-driven decisions on the incident form. What I'd also like to show you is what that might look like. from the user perspective. So a user, often you'll see on instant forms that are exposed through the employee center that you've got about 10 different fields that the service desk might want to know and that is all supposed to help the agent to triage the ticket once it hits the service desk. But often you're asking the user questions they just won't know the answer to. If I give you an example of what a laptop problem might look like from the employee centre, so I've not re-impersonated anybody, but just imagine that I'm Joe Employee now instead of... system administrator. And if I search for my laptop problem in the employee center, then ideally we'd have something ready made to service that common request that people might have from the employee center. So if I click that, then we have our laptop problem instant report pop up. And you can see we're actually keeping it very simple for the user. So they don't need to know about the service layer CIs, they don't need to know about the service offering in the background, that's associated to the catalog item. So if we go and say, my laptop is broken, fill in some brief details. So it's overheating, I'm going to choose my affected device from the devices that are assigned to me. And then if I submit that, So we've got our incident that's raised. So that's four clicks for an end user to raise an incident to the service desk. And you're not asking the user any questions they're not going to know. But then if we go and have a look at the incident as it's been raised in the back end, and this is where that aim to help the agent do their job better really comes to life by search for the incident. So we get all of this extra information. So the first thing we see is that it's found the relevant service. It's found, it's obviously populated the configuration item that we selected. We've got all of our affected CIs. We've got our related impacted services. And we've got the, on the details page, we've got all of this populated based on the fact that the service offering was associated to the catalogue item. So. with the bare minimum of configuration, you've got that catalog item being routed to exactly the right team that can resolve it. You've got your service information and your offering information. This is really, really useful for reporting and getting that high quality task intelligence data into the system that helps drive that future intelligent routing to teams. And when an agent comes to this form, they've got all the information they need to resolve the incident without putting the onus of that onto the user that's requesting it. So having a small amount of effort organising your services and offerings in the background and assigning them to groups and organising them into your service portfolio can really make that whole process a lot quicker. And that's it. Excellent. Thanks, Ryan. Great work. And it's always really good to be able to see this directly in the platform, right, to see what's happening. So that's really useful. I'm going to take over the screen now and just talk about a few bits of wrap up. Before I do so, you know, keen to cover just there's so much chat activity going on, trying to keep up with the questions. There are so many questions. I think the thing with this whole concept is we want you to be able to walk away with tips on how to get better at defining that data and making it more useful for you. There's a lot of different ways you can slice up the definitions that we're talking about today. And having spoken to hundreds of customers across the three of us that are on this session today hosting, there are so many different interpretations of the way that we approach this. I think there are some golden rules that we can stick with that move away from more what each canonical item is and the definition of that. And the bigger picture, which is getting better quality data, being able to slice up your incident information more effectively so you can see quicker where the hot spots are and where the need for is for improvement. So first off, it's really good to get a good idea of basic definitions across your teams. Just talking. about all of the activity and chat and all the stuff we're talking about just in this session with with all of you on board makes it clear that this discussion needs to be had in organizations right and it's important to have for your less experienced team members maybe that haven't been doing this for very long to have your set of definitions of an org of what you consider these things to be there's loads of great historical best practice information we're thinking ITIL we're thinking our own practice information stuff from COVID and ISO, and all of that kind of provides information. But as an organization, make sure you have a clear definition of where you want everything to be and how you want to define everything. And the shape of your organization and the way that your enterprise works will shape those definitions. Again, the kind of real key point here is aim to simplify the logging experience for an agent. So whether or not it's, you know, having CIs assigned to an incident, whether or not it's using business services, application services, service offerings, think strategically about what combination of those for your organization will help give your agents and your teams the experience they need to know what to do next to root that incident. You might do some of that automatically, but you might rely on some evidence and some information from those fields in order to help a service desk analyst make a decision, for example. And the kind of key here is that bringing all of the information together and using it in combination will make it more powerful. And finally, take away some of the things that we talked about within the basics of data driven decision making, what kind of particular elements you want to add to your. to your journey what you want to configure what you want to populate within your cndb in order to increase the accuracy and intelligence that comes from logging incidents we've got a load of other resources that we've got to help this will answer some of the questions that we're seeing in the chat as well as providing you with some takeaway stuff to take back to your teams and to kind of reinforce some of the messages we've talked about today this will all be available and emailed after the session if you've been an attendee you'll get an email with the information And we'd love to connect with you. We'd love to talk to you about this further. I could see a lot of passion in the chat here and in the Q&A, a lot of great experiences. And we love that knowledge and we want to benefit from it. If you if you like what we said, if you don't like what we said, we want to hear from you either way. So please take some time to connect with us. And, you know, we'd love to talk to you more and shape this for the future. But that being said, I think we've kind of come to the end of our slides. Great. OK, I think we're coming nicely up to the end of our hour's worth of time here. I think I just want to say thanks very much to everyone for attending the session. We've had over 200 people attend this session and some great involvement. So that's really great. Like we said, there'll be an email after this, which will cover all of the additional materials, etc. But I think all that really remains to say is thank you very much to Chris and Ryan for joining me today in this session. It's great to meet you all and talk to you all and we hope to see you on the next one.

So the first thing is that... We may cover some forward-looking statements on behalf of the ServiceNow product today. And just to let you know, anything that's not on our current GA release, anything we show that may be future capabilities are subject to change.

So this is part of a series of live on ServiceNow webinars. They're an interactive event series covering lots of different great pieces of information, lots of great speakers from ServiceNow, from our trusted partner organizations and more. The schedule link will be shared in today's chat.

So if you want to attend more sessions or learn a bit more about the catalogue of events we have coming up in the next couple of months, please click on that link and it will take you to a location where you can find all that information. So just a couple of things before we get started today. So there will be plenty of time at the end of the session for Q&A.

Please use the Q&A section within the chat if you want to ask a question rather than the chat function. We'll be monitoring. the Q&A specifically for questions. So if you want us to pick that up live or afterwards, please make sure it's in the right section. We're going to share this presentation and it'll be available on the ServiceNow community.

So if you have to step out for a moment or you've got someone you want to share it with, we'll make all the links for that available after the session. And feedback is a real gift for us and we'd love to hear how you feel about the session so we can make sure the next one's even better than this one. So you will be asked to fill out a short survey at the end.

Please don't ignore it. please fill it in because the feedback is hugely vital to us to make sure we're providing the best experience on these sessions. So I'm going to introduce who will be speaking today. So if you haven't guessed already from the pictures there, I'm the one in the middle.

My name is Scott Gamble and I'm a principal. I work within our leading practices organization within ServiceNow. I've done a lot of stuff within ServiceNow, a lot of IT operations management, and my job is to help maximize success when it comes to implementation.

I'm joined by my esteemed colleague, Chris Shakespeare, who is veteran of ServiceNow, 13 plus years of experience. And we both share the same mission to make implementation for customers, partners and our whole ecosystem as smooth and efficient as possible. We both specialize in IT service management.

And I'm delighted to be joined as well by Ryan Deuce at Flyform, one of our trusted partners. Ryan is a colleague of mine that we've known for quite a long time now. And we've been working together with customers, a number of different challenges within the ServiceNow space.

And Ryan's a great asset to have on our team. So thanks very much for joining us today, Ryan. It's great to have you on the call.

So this is what we're going to cover today. So we've done the intro. That's covered off already. I'm going to dive in a little bit into the basic definitions and terms that we're going to use today. Many of you will be very experienced in your CSDM journey.

Many of you will be just starting out. So this is a level set to make sure that everyone who's on the call kind of understands what we're talking about as we dig in deeper throughout the session. My colleague Chris is going to cover some great information on data driven decision making to help you make the incident logging process and incident management process intertwine well with CSDM.

Ryan's going to take over at this point to do a demo to show you what this looks like inside the platform. And then at the end, we'll have our Q&A and we'll have plenty of time to also discuss takeaways and information that we want you to leave with today. So by the end of today, hopefully we're going to give you a good overview of the leading practices around integrating incidents with incident management, the CSDM, laying the foundations for service portfolio management, digital portfolio management, CNBB, all that great stuff.

And also we want to specifically hone in on the use case of first-line agents, people in service desks, customer support teams, how they capture and record incidents so they align with CSDM first and foremostly, but also reducing your data entry time, maximizing the capabilities of that kind of single control tower platform that we have. Ultimately, practical terms will show you how to configure your incident process to align with CSDM practices and principles. So touching on the basic definitions, I'm going to cover a few things here in kind of a high level view. Let me know if there's any questions in the chat as we go through. We'll pick those up towards the end.

So. Let's start by looking at what service is and how we define that. So for us, service is a means of delivering value to customers, and that's by facilitating the outcomes customers want to achieve without the ownership of specific costs and risks.

So when we think about a service, we're thinking about something that a customer might understand in their language, something that they might refer to. I've got some examples in a minute to kind of dig into that a bit further. A service offering is... a unique service commitment that sits underneath the service. So for example, if you're a service provider, you might have a platinum, gold, silver, bronze level of service where you get a certain resolution time or a certain response time.

This might be the same core service that you provide as a customer, but those offerings differ depending on what level of customer is paying, what kind of perks they get, et cetera, et cetera. So it's a really good way to subdivide a service. into distinct offerings with different service commitments, SLAs, etc.

And the CI is the Lego block right at the bottom of that, right? So the CI is the computers, the devices, the software, all of those items, both logical and physical, that sit inside your CMDB and normally form the foundation of those service offerings and services. So it's a good way to look at it from service on the left being the biggest scope all the way down to those individual configuration items on the right-hand side.

So within services, there are three core different categories when we talk about services. And this is probably, and I think Chris and Ryan, you'll probably share my thoughts on this, probably one of the most common questions that we get asked as ServiceNow implementation experts is, what's the difference between all these services? I must admit, when I started on my journey, I found this confusing. So I've tried to put it in the clearest possible way I can, the way I got it, and hopefully it will help you too. So starting off with a technical service.

A technical service is published out to service owners, people who own the overall services, and it underpins that business or application service, which we're going to touch in as we go down. So if you think about something that has operational CIs and something you potentially use as an impact registration for incidents and maybe something you'd approve for a change. So the way I've described this is something like a mail server. You might have 10 of those in your estate.

You might have 100 of them. all running a mail server application. An application service is a logical representation of a deployed system or an application stack.

So what we mean by that is that it usually consists of one or more operational CIs, so like multiple mail servers for example, and the applications and hosts configured to offer a particular service. This is as we're transitioning from the kind of bare metal, the core components, through to a service value adding piece of equipment. Microsoft Exchange is a really good example of that. So you have a number of mail servers that form the Microsoft Exchange task. Now, you know, not everybody who works for an organization would know what Microsoft Exchange means.

So that application layer is very specifically for people within an organization who are technically operating or operating particular services, normally the people that sit within IT. And then finally, we have a business service. That's the service, the front end service that's available to. business users or customers.

And that underpins one or more business capabilities. So when we think about capabilities, I'd give you an example of maybe communication, right? How do you communicate across a business? But you need the capability to communicate with your customers, with other departments.

And one of the methods we do that is through email. And email is a business service that runs on Microsoft Exchange as an application, which then is backed up by technical services, such as mail service. So a business service is published to business users and it's user or customer focused. So it's going to be in terms they understand. And quite often we see organizations adopt business service terms.

You know, Outlook is a good example of a mail application, right? But, you know, how often do people say my email application? They will use a brand name like Outlook or Teams or Slack, etc.

So we're not always in charge of what the business calls a business services. So when we talk about creating incidents and the specific context of the use cases we're covering today, we're talking about three distinct personas. So we're talking about the user persona, so that would be someone who is a customer or a user logging into a portal, ringing up your service desk who wants to log an incident or an outage with a piece of equipment that they have.

You then have IT. As an analyst, as an engineer, as a help desk member, how am I using the incident management process and how am I integrating with that? And then finally, you've got the system area. So how are systems communicating with each other?

What's happening in the background as we log incidents and relate them to the relevant services and other things that exist in our business's ecosystem? Alignment with CSDM simplifies the process for all of these personas. So your system-to-system, your IT-to-user, all that stuff becomes simplified when you have a handle on the data through your CSDM.

So it's time for me to take a break. I'm going to hand over to my colleague, Chris, who's going to take you through the data-driven decision-making process with incident management. So over to you, Chris. Thanks, Scott.

And I'll just swap screens and pull up the presentation. So we should be... There. Okay. Right.

All good. So thanks to Scott. I mean, there's a lot of definitions thrown at you, and there's a lot of materials out there from ServiceNow that talk to CSDM, CMDB, the various services available, technical application, business services. A lot of that material is out there on.

Now Create. So if you haven't been out onto Now Create, please have a look. Obviously, deeper dives than we can go into in the session today. But really what we wanted to do in this section of the webinar is take you through data-driven decision making and really look at how we can enhance the incident management process to consume the data, those services that Scott was talking about and also simplify the life of the agents. Because I think, you know, out-of-the-box service now gives you lots of opportunities to enter data, but also that also gives opportunities to make errors.

So some of this is really just to streamline the work that those agents do and make it easier for them. And, you know, ultimately... hopefully give you a path where you can start automating some of this so that you're not having to manually enter that data but rather the system can start driving some of that work for you. So what's that look like a little bit more?

Well we have really five recommendations we're going to drill into each one through this section of where we feel that that whole process can be streamlined. So starting out with service offerings and linking those to services and making sure it's consistent with CSDM is for us one of the most important steps. Now, I think that in itself can be potentially daunting.

And we usually say to customers is you can really looking at your business services. There are probably five or six key services within your company that. you would want to represent.

And those are the starting points. It's not to build out a huge business service catalogue. It's what's the critical items for that.

And we'll dig into perhaps how they feed into incident management later on. Scott touched on the personas. And really, there are three key personas that we're calling out today who raise incidents.

There's the agents themselves, those... those people working on the service desk, IT staff, so people out in the field who need to raise an incident, and ultimately machine to machine, those system generated ones. It's important whenever you think about incident creation that you cater for all those three bodies. Those are the main ones and obviously there's nuances.

Underneath that, if we take system generated, that can be from event alert systems. It can be from other areas as well as we dig in. Out of the box, we mentioned that the incident form itself allows for lots of data entry.

There's an example on the screen at the moment. So if you get all that right, it gives you a very rich environment to... work on the incident but also yeah anything you have to fill in is potentially time consuming and potential for error as well so if we can streamline some of that then reduces time reduces error incidents on the incident itself so we're going to look at what that would look like in terms of the incident form to reduce those opportunities and and a lot of that revolves around repopulating the service offering first and deriving information from that such as the the service so that again you're reducing the elements that you're entering and also you're being contextually relevant especially to the agent so the more likely for example to to have an idea what the service offering is and working from that route So let's dig in and see a little bit more of what this looks like in practice. So we mentioned about getting started with CSDM and especially around the service offerings and services. And, you know, even within the basic ITSM for ServiceNow is you've got.

service portfolio management. So you've got a lot of capabilities sitting in there to be able to build out those services. And later on, you know, things like digital portfolio management really allow you to extend not just within the ITSM space, but into things like SPM with application portfolio management and others.

But starting small, getting your arms around those key services is the... place to go. There isn't one single model that suits all.

And I can see, you know, in the chat that was happening, there's a lot of discussion around technical services, application services, where to start. So it's hard to be totally prescriptive of the right place to start. But I think, you know, starting at that top level, starting at those key business services.

and then deriving service offerings from those generally suits majority of the customers to get them going and moving forwards. And that allows you to then start extending beyond there ultimately into service owners, service performance metrics, and the other things which come from having that mindset and approach. Obviously, if you've got...

The other side of the coin is the CIs that incident management is dependent on. You don't want to be manually discovering those and entering data from spreadsheets. You really want to be having a tool like discovery or federated data from a discovery tool that's going to help populate that CMDB so you can consume that data within your.

incident management process and relate it to those services and one of the things that we do recommend is out the box there are no principal CIs designated so you can pick anything in the CI field and that you know can be pretty daunting and also with the scale potentially the data set is again it's time consuming and potentially error bound. because it's time consuming, you're looking for something. So we recommend starting out by designating a set of principal CIs, which essentially down filters the available data for the incident management. And so we always recommend, you know, reducing it and the type of recommendations around application services, servers, computers, you know, the main infrastructure items rather than perhaps end user. compute a lot more detail in the CMDB process guide on Nocreate, which is one of our top downloads, unsurprisingly.

So a lot more detail in there. And ultimately, this really helps because what we're saying is we're looking at the service offering. links into the service, the application services. It's often the CI, and we've seen some chat around there. And you can also derive the assignment group.

It's either the support group for the service or it's the support group for the CI. And we'll see a little bit more of what that means in a moment. So we talked about the three use cases. And this is a sort of raised up version of the standard form today. And this is what you get to sort of fill in is service, service offering, the CI, the assignment group.

And so having the data available is really going to simplify the. population of this and again reduce the level of error and where we want to go with this and the recommendation is the service should be derived from the service offering the CI should be down filtered and appropriate for the service offering that you're raising essentially instant for and the assignment group should be again either from the CI record if you have a CI and not all cases you'll have a CI And we've got some examples which demonstrate why that might not be the case. Or the service offering itself has a support group.

And if you haven't got a CI record, then the assignment group will be derived from that service offering. So moving on is we would recommend that. the instant form itself is configured so that essentially the service field becomes read only. The service offering is the main field that you would fill in and that the service then is derived from the service offering and we add in the CI classes and Ryan will show you what this looks like in practice. in a demo that we're going to show shortly.

And ultimately is if you do all that, when you get a form which looks a bit like this, this is the UI 16 form. We're very keen that people adopt Workspace because it provides a very rich environment. But the principles here that we're talking about in terms of the... the form you see in front also apply to the service operations workspace and the same same changes apply so and basically you you end up with the service offering driving the service configuration item all the service offering driving the assignment group for that and all this ultimately is still within the framework that CSDM provides.

And this is very much a cut down view of CSDM, but this is with a lens of how to make incident management more efficient. And you can see here, we've talked a lot about the business service and the business service offering. And ultimately, that's linking through to the application services it's got uh it's got mentioned and they're linking through to the cis obviously the white paper is much more comprehensive but in terms of moving forwards and trying to cut this down into something that's consumable within the itsm space we feel that this can do that for you And this holds true, as we mentioned before, is very much about the agent fills out the service offering, but populates the services filled out on the basis of the service offering, etc. And you can see that we're still respecting the hierarchy that's within CSDM. And...

That's a 30 on the instant form. And that's important that we, although we're modifying the form, we're staying consistent with the overall framework that ServiceNow is recommending for its data in CSDM. It's really about improving the efficiency of the consumption of that data for a particular process rather than changing the data to suit the process.

So we're underpinning our process. by data that's scalable, not just into incident management, but also, as we mentioned, ultimately into more service-orientated business. So when you get into things like application portfolio management and other areas like DPM is you've still got that consistent approach and you're not having to change other applications to meet.

the changes you've done in the data structure itself. So staying consistent with CSDM is a key principle of this. It's a streamlining of that consumption in instant is really one of the key things that...

um we want a takeaway from this so auto populating the service i mentioned that not everything has a ci so if we take you know and then use a computer and i mentioned that you know probably not the place to start with the um in terms of cmdb but you know it can be something that's appropriate for your business in this case you see example where Just imagine the caller has phoned up about Adobe Acrobat, in this case, on their device. So that's end-user services, and the configuration item is their own end-user compute device. In this case, it's a laptop that they've got allocated to them. A slightly more common, well, not common, but...

Different is probably a better word. In this case, Salesforce is, again, it's end user service. But because it's a cloud native application, you don't really have visibility into CIs. So the CI is going to provide limited value for that.

So in this, you're heavily orientated around using the service offering and the service to help you with the incident and ultimately resolving the service issue that comes. from there so in those cases you wouldn't necessarily have the CI and in that case the assignment group would be populated from the service offerings support group rather than the CI's support group because you haven't populated and finally you know something that's quite common on a service desk is you might know the service which is at fault in this case and we've got a problem with the service offering ground inventory management But at the starting point is you don't know what CI is at fault. And, you know, it's potentially a long list of candidates at that point in time, unless perhaps you've got an event management system that has flagged it up and said, you know, maybe the server's overheating, running out of space or something like that. So often you'll start out with the CI unpopulated.

Later on, you will be a population of the CI. once you've done some triage and diagnosis around that incident. And in those cases, you may well be raising a child incident because you're addressing the issues with a technical service offering and you want that group who are responsible for a technical service offering to be looking into that, and you've still got ownership on the desk of the overall incident that's related. to there.

So that's very much trying to use data to drive the incident management process to minimize where possible the amount of manual entry into the incident form and by doing so try to remove potential error in that process. So ultimately you can take a step forwards from this as well. So this is almost the traditional, the classical view of managing the data. But you can also then, if you have that data available, is just a touch on how you then can drive some of those fields that you are manually populating, like the service CI, the assignment groups.

We talked about how perhaps the agent was entering it or it'd be generated by a machine is If you've got good data and you've got confidence in terms of the relationships between services, service offerings and the group supporting them, you can extend that data orientation and the use of the data inherent in the system for things like task intelligence, really taking that data set and removing the manual intervention that you were previously doing for it. So you can start out with making sure you've got those services and those critical services when the business identified. You've got healthy CIs available.

You've got your support groups. You minimize the manual entry for your agents or the system to populate. But ultimately, you can extend beyond that by having that data by driving the...

the organization through that data inherent in the system. You can even remove some of those steps later on by... taking capabilities such as task intelligence and really getting that to drive from there.

So it doesn't stop. It's a level of where you are and what maturity you have for that. So I'm going to hand over to Ryan now, who's going to show you what this looks like in practice. I've seen a lot of PowerPoint and I'll let Ryan. but bring it to life from an agent's interaction perspective.

Perfect. Thank you, Chris. So let me take over the screen share. Hopefully it'll be a nice, smooth transition. And hopefully you can see the service operations workspace on screen.

So I'd like to take you through the simplified way that an agent might raise. an incident using the methods that we've seen so far. So if I go up to create my new incident from the top of the screen, I get my service operations workspace form here.

So I'm just going to say something like my laptop is broken. I'm going to enter my caller. So my caller is And then down here you can see that in my assignment section I've got my services read only.

So we're only asking our agent to select a service offering. And you can see down here we've got these service offerings aren't necessarily understood by the end user. They may be understood by the agent but the end user won't necessarily know what these mean. So if I start typing in employee laptop. Then if I select this offering, then I immediately see that we're using relationships in the CSDM to populate other things on the instant form.

So we know that the parent service is end user computing, so we can populate that for the agent. That's one fewer click the agent is doing on the instant form, and you think if they're raising 30, 40 incidents a day. every click saved is quicker, mean time to resolution and happier customers and fewer errors as well.

That's also worth bearing in mind. And then we also know that the employee laptop is a service offering that's being supported by the hardware group. So that is listed as the support group on the service offering.

So if we've defined our services and we've defined the groups that support those services, and we've done that. at an organizational level, then we should really be helping the agent populate the fields that they need on the instant form with that service portfolio that we've built up. It's meaning that the actual effort we put into to get that data into the system and get owners for all of these service layer CIs does actually go towards making those data-driven decisions that Chris talked about.

making the agent's life easier. And then I'm going to look at my configuration items. And if I select that the computer is my configuration item, that's the actual exact thing that's gone wrong, you can see that the assignment group hasn't actually changed because the support group on the configuration item is the same as the service offering.

but this is the most specific item of this stack that we're selecting. So if there's a support group on the configuration item then we want that to be the support group that is assigned to the incident. And so that's a little bit of a preview of how you can use data-driven decisions on the incident form. What I'd also like to show you is what that might look like. from the user perspective.

So a user, often you'll see on instant forms that are exposed through the employee center that you've got about 10 different fields that the service desk might want to know and that is all supposed to help the agent to triage the ticket once it hits the service desk. But often you're asking the user questions they just won't know the answer to. If I give you an example of what a laptop problem might look like from the employee centre, so I've not re-impersonated anybody, but just imagine that I'm Joe Employee now instead of...

system administrator. And if I search for my laptop problem in the employee center, then ideally we'd have something ready made to service that common request that people might have from the employee center. So if I click that, then we have our laptop problem instant report pop up. And you can see we're actually keeping it very simple for the user.

So they don't need to know about the service layer CIs, they don't need to know about the service offering in the background, that's associated to the catalog item. So if we go and say, my laptop is broken, fill in some brief details. So it's overheating, I'm going to choose my affected device from the devices that are assigned to me.

And then if I submit that, So we've got our incident that's raised. So that's four clicks for an end user to raise an incident to the service desk. And you're not asking the user any questions they're not going to know.

But then if we go and have a look at the incident as it's been raised in the back end, and this is where that aim to help the agent do their job better really comes to life by search for the incident. So we get all of this extra information. So the first thing we see is that it's found the relevant service.

It's found, it's obviously populated the configuration item that we selected. We've got all of our affected CIs. We've got our related impacted services. And we've got the, on the details page, we've got all of this populated based on the fact that the service offering was associated to the catalogue item. So.

with the bare minimum of configuration, you've got that catalog item being routed to exactly the right team that can resolve it. You've got your service information and your offering information. This is really, really useful for reporting and getting that high quality task intelligence data into the system that helps drive that future intelligent routing to teams. And when an agent comes to this form, they've got all the information they need to resolve the incident without putting the onus of that onto the user that's requesting it.

So having a small amount of effort organising your services and offerings in the background and assigning them to groups and organising them into your service portfolio can really make that whole process a lot quicker. And that's it. Excellent.

Thanks, Ryan. Great work. And it's always really good to be able to see this directly in the platform, right, to see what's happening.

So that's really useful. I'm going to take over the screen now and just talk about a few bits of wrap up. Before I do so, you know, keen to cover just there's so much chat activity going on, trying to keep up with the questions.

There are so many questions. I think the thing with this whole concept is we want you to be able to walk away with tips on how to get better at defining that data and making it more useful for you. There's a lot of different ways you can slice up the definitions that we're talking about today. And having spoken to hundreds of customers across the three of us that are on this session today hosting, there are so many different interpretations of the way that we approach this.

I think there are some golden rules that we can stick with that move away from more what each canonical item is and the definition of that. And the bigger picture, which is getting better quality data, being able to slice up your incident information more effectively so you can see quicker where the hot spots are and where the need for is for improvement. So first off, it's really good to get a good idea of basic definitions across your teams.

Just talking. about all of the activity and chat and all the stuff we're talking about just in this session with with all of you on board makes it clear that this discussion needs to be had in organizations right and it's important to have for your less experienced team members maybe that haven't been doing this for very long to have your set of definitions of an org of what you consider these things to be there's loads of great historical best practice information we're thinking ITIL we're thinking our own practice information stuff from COVID and ISO, and all of that kind of provides information. But as an organization, make sure you have a clear definition of where you want everything to be and how you want to define everything.

And the shape of your organization and the way that your enterprise works will shape those definitions. Again, the kind of real key point here is aim to simplify the logging experience for an agent. So whether or not it's, you know, having CIs assigned to an incident, whether or not it's using business services, application services, service offerings, think strategically about what combination of those for your organization will help give your agents and your teams the experience they need to know what to do next to root that incident.

You might do some of that automatically, but you might rely on some evidence and some information from those fields in order to help a service desk analyst make a decision, for example. And the kind of key here is that bringing all of the information together and using it in combination will make it more powerful. And finally, take away some of the things that we talked about within the basics of data driven decision making, what kind of particular elements you want to add to your. to your journey what you want to configure what you want to populate within your cndb in order to increase the accuracy and intelligence that comes from logging incidents we've got a load of other resources that we've got to help this will answer some of the questions that we're seeing in the chat as well as providing you with some takeaway stuff to take back to your teams and to kind of reinforce some of the messages we've talked about today this will all be available and emailed after the session if you've been an attendee you'll get an email with the information And we'd love to connect with you. We'd love to talk to you about this further.

I could see a lot of passion in the chat here and in the Q&A, a lot of great experiences. And we love that knowledge and we want to benefit from it. If you if you like what we said, if you don't like what we said, we want to hear from you either way. So please take some time to connect with us.

And, you know, we'd love to talk to you more and shape this for the future. But that being said, I think we've kind of come to the end of our slides. Great. OK, I think we're coming nicely up to the end of our hour's worth of time here.

I think I just want to say thanks very much to everyone for attending the session. We've had over 200 people attend this session and some great involvement. So that's really great.

Like we said, there'll be an email after this, which will cover all of the additional materials, etc. But I think all that really remains to say is thank you very much to Chris and Ryan for joining me today in this session. It's great to meet you all and talk to you all and we hope to see you on the next one.

Transcript for:ServiceNow Webinar Insights on Incident Management

Transcript for:
ServiceNow Webinar Insights on Incident Management