How Finning International set up for success with ServiceNow

So a little bit of an introduction. Finning are a caterpillar data, the world's largest. So we sell the big yellow machinery. We are not a, a technical company as such, but we're, we're moving into that, that world. As we go into analytics and performance of our, our equipment myself, I'm not an expert in sretch on identity, access management or governance, but I do know I TSM and I do have experience of implementing service now.

So over the last, probably three years or so, that has been one of my biggest focuses in the company and over the next 15 minutes or so, I'm gonna share some of my tips for success and try and put a little bit of a SL on IM as well. So I talk about my credentials about why I'm talking about this really. So we launched service now in finning in may last year, across three continents, across seven countries, about 12,000 employees, we using the it TSM module.

And we're looking to expand that into operations management, customer service management, and several of the other modules over time as well. The reason we went with service now is that we are a global it function, but we were working in regional silos. So we had localized tool sets, localized applications, localized processes, and it was really difficult to collaborate with one another and really get the sort of compare apples to apples in terms of performance and, and the data we were using.

It, it was hindering our ability to truly work globally as an organization. And more importantly, it made it difficult to measure how we were working for users, whether we were giving a consistent performance across all of our services and all of our regions, and it made it complicated for the users to working across multiple systems. So we wanted to consolidate that one platform and we chose service now for that. So what happened was a success, which I guess is why I'm here talking to you today, where our metrics all improved. We've got good CSAT.

And as I say, we're looking to expand upon our ServiceNow platform into other modules. So how did we set ourselves off success? I'm gonna touch on these four points that you can see on the slide. Now I'm gonna touch on some lessons, learned, some will be best practice that was shared with us as we went through our journey by either our implementation partner or by service now themselves. But really this is things that I wish I'd have considered at the start of the project or had known at the start of the project. So that to do first point, identify your systems of record.

So one of the first design sessions we had when we were implementing ServiceNow was around our integrations and where do we get our user information from for now? How do people get access? How are they identifiable? Now in this design session, I went in with some, some misconceptions about our architecture and, and importantly, our, our systems records and our systems truth. So I put the, the definitions on there, but I don't want to, to teach you what to eggs. So I won't go through those.

But basically I understood, I understood our systems record and our truth to be different to what they actually were. So the conversation kind of went like this in these design meetings, we asked the question of our it stakeholders across the business. Do we have a single source of truth for this, this, this bit of data I was sitting there thinking, yeah, of course we do. It's this. And everyone else turned around and said, no, it's this, this, this, and this and that, that really took me aback initially.

So we, we delved in scratched the surface on that. We delved into a little bit more detail. We touched on the different systems where data was held. So it's things like our HR system in Workday sale points, our identity governance system. And then we said, okay, so, so what are our systems record?

And again, I was thinking, right, well, Workday user information sale point is gonna be our, our access management. And again, I was surprised because different stakeholders around the table went in with different responses and it generated a really good discussion in the company about the, the data architecture and where, where our source of truth were. And this is so important with service now in terms of getting this information right, and making sure that you're collecting the right information from the right place to make sure that you are working with truthful data and the correct data.

There's nothing. If, if you're putting bad data into a system, particularly any system, but ServiceNow in particular, when we're talking in this context, you're setting yourself up for a failure. You can't work with bad data. You need to make sure everybody understood, understands, and agrees and aligns to these a certain system of record and certain systems of truth. And that's where you need to focus your integrations on ServiceNow.

So the lesson here is don't go into it with preconceptions or assumptions, go into it with an open mind, make sure you've got the stakeholders at the table when you're going into these design sessions. Okay. So that takes onto the second point. So talking about all these integrations, keep your service now, system up to date and everything else as well. So most of you'll be aware of the service now upgrade cycle. They do two releases a year. I've got the, the release roadmap on the right there on slide.

New customers tend to get signed up to agreements where you are obliged to stay on N minus one. So you have to stay on a fairly recent version. Some of the older customers, they don't have that and they they're can stay into support and earlier versions. And what that's the reason they moved away from that is because they're, they're, they're too difficult to upgrade. If you get too far behind in the cycle, you can't then catch up and get up to the latest and greatest version. And that means you're missing out on features.

You're missing out on security, you're missing out on functionality so that you're obliged now to stay on the latest version. But what that also means is that you are also tied into that with your integrations as well. So your upstream and downstream integrations. So think about what we talked about, the last slide. So we've got Workday, we've got sale point. We need to make sure that they're also on a version that supports service now. So you need align those two roadmaps. If you not yet implemented service.

Now think about what, what version you're going to develop in, in service now, is that gonna take you past the next upgrade cycle, then think about your applications that you want to integrate. Are they, are they supported by service now today? Are they gonna be supported on the virtual going live in? Are they supported on the next version of service? Do you need to consider upgrading those in advance of going live? And if you've already got ServiceNow in place, think about you should still be thinking about this.

You should still be putting this roadmap together because you dunno what risk or, or disasters lurking around the corner. In terms of these integrations, you could be outta support on, on the key integration piece that will damage an important workflow you've got in the system. So I guess the, the takeaway here is that putting the plan together is fairly straightforward. It's not difficult to do as long as you know, all the players that you're working with, these integration pieces. The important thing is to actually have that plan in the first place and put the time into doing that. Okay.

So one of the things that has helped us to keep up to date so far, we've gone through one and half upgrades. We just started go. Our second set of upgrades now was one of our guiding principles when we implemented service now, and that was to configure, not customize the platform. So this is going to, this is going to, to shock any, anyone from my organization, that's watching. And also some of you as well, but very few of us are different. We are not special. 99% of businesses out there operate similar backend workflows.

So in, I TSM people do it in the same way. There's no reason why you need to deviate from best practice or from the, the sort of out box functionality. The service now provided, which is based on the best practice. So our guiding principle was that we were, we were building it best practice. I TSM processes using out box configuration of service now. And what that does is that it makes, it makes not only the implementation and starting service now easier. It also makes the downstream feeding and watering of the system easier as well.

So when it comes to upgrades, you're talking, it makes it easier, faster, cheaper to upgrade. You're not spending as much time and effort in building customized testing plans. You're not spending time working on small customizations that you've made for one team here or another team over there. You can spend your time instead on getting through that upgrade as quickly as possible, those benefits, actual users, excuse me.

And it, it really, it pays dividends throughout. So you're paying for ServiceNow is a premium product. Isn't the Gartner magic quadrant for a lot of these modules. I think we said earlier that it's, it's expanded into HR and that's one of their most popular modules.

Now's, it's growing at a huge rate. And why would you pay that premium product and get that premium service and then go and customize it. You really don't need to, it gives you 90 cents functionality you need. And for the most, for the rest of the rest of the functionality, ask yourself the question. Do we really need it?

Or are we, are we trying to overcomplicate what should be quite a simple system, simple process. So, yeah. And the other thing to bear in mind is that when you do, when you do the service now upgrades, just because a feature is available and, and something has changed in the system, you don't need to enable it. So just turn it off. If you're not ready for it, if your, your users aren't ready, if you don't have the staff to support it, turn it off, you don't have to use it, but at least by using the configuration, not customization mantra, at least then you're still able to have that option.

You're not closing that door to yourself. Okay.

So the, the fourth piece of advice, and it's, it's something that Afghani seen on previous presentations. So Paul and a tiller, I know, mentioned it in one earlier on the user perspective for ServiceNow and any system that you're implementing of this size of this scale of this magnitude is so important. Design it from the user's point of view, particularly now in the world that we're living in today, our user expectations have shifted. We're all working from home.

We're used to sort of immediate delivery, immediate response, the Amazon esque experience, if you like, and in our, in our consumer world, our customer effort for, for our willingness to do things is really low. We want the quickest, easiest, most straightforward way of doing things. And that's the same in, in a professional world as well, in an it sense from in ServiceNow, most of our users won't care about how complex of the wise of how something is done. They just won't get from a to B as clear as easily, and with as little effort as possible.

Now, whether that's time or clicks, each company will measure that differently. But the key is to when you're designing a new process, and when you're setting up and configuring service now to think about your own users and their different, their different ways of working, take the complexity out, make it as consistent as possible. So a user user a works in the same way as user B, who's operating a different path in a completely different role in a different language, keep it simple, make it consistent and make it easier to comply than to try and circumvent the system.

Some of the speech bubbles that you can see on the screen, there are things that users have I've heard. And I've seen said on our forums in the business and it's people will, if you don't make things easy, people will try and work around it. So make them simple by design, consider everything from the user's perspective. And with that in mind, if, if you're setting up service now or you're implementing a new set, new set of processes or modules, you shouldn't need to train your users necessarily. If you need to train your users, it's probably too complicated. Think about, again, your Amazons.

You don't need to be trained on how to use Amazon. It's the same experience it's consistent. You it's intuitive. You just know where to go. And if you dunno where to go, there's an easy way to find help by using the search bar or an option at the top. So again, from a wherever possible, as well, try to make it a single pain experience for users. So if you're doing these integrations that we mentioned before to your identity system or your governance system, or your HR system, try and keep it all within a single pain.

So if you, if you have to, if you have to integrate, make it seamless for the users, don't take them to a hyperlink, to a new system, keep it in that one pan of glass for them. And the other bullet point that I've gone on the screen is there that service now becomes synonymous with it. So people don't talk about it anymore.

As a, as a department in our business, they talk about service. Now, ServiceNow told me to this, haven't from service now, or isn't ServiceNow great.

It that's, that's common language, and it it's likely to be common language in your system as well, or whatever branding you put on your ServiceNow environment. So bear that in mind, as you're designing this, anything new, anything changing in service. Now it's gonna reflect on your department on, and as your business as a whole, I think again, Paul and mentioned earlier on that you may need to, with other departments to, to do this properly as well. So it's to looking at end to end process, try it as simple as possible business is a team.

So take that, take that into account when you're designing and building out this system, right. I've, I've come pretty much the end of my time now, I think so I will draw a line under it. There.