Panel - Best Practices for Managing Digital Workflows on ServiceNow

Maybe we, we start quickly with, so David already had his talk and did an introduction. So maybe L you wanna start with a quick introduction of yourself. Yeah.

Thank you, Martin. That is great to be here and thank you for in invite. So my name is LA I'm at limping partners and, and we are one of the IM solution providers for the ServiceNow platform. And we are, other than that, we also have been past 10 years, we joined with the ServiceNow. So consulting, building application, manage services and so on.

So, and as I said, or you said that I'm responsible for the business operations and mainly for the IM business on our organization, and you were pretty close with my last name, so let's stick it out. So, Okay. So let's get started in the topic about, or in this, this broad topic about best practices. Maybe we start with question, which is both was simple and very complex to answer.

I know, but what would be the, the number one best practice, maybe as a starter, from your perspective, what would be the number one recommendation? I think we start with David because he already gave some and he probably just needs to pick one of the four means he had to do, but, so if you would say this is really number one of all the recommendations, the best practices, which one is it? David? I would say it's the, the configured don't customize that's.

That was by far the, the biggest, most important guiding principle when we were implementing service now, not just because of the implications when you first, when you're first implementing it and it making it more straightforward, keeping it, making sure everything support to do, but going forwards as well.

When you're trying to, to maintain a system, particularly something like service now with the breadth that it has, you need to make sure that it's, it's simple to maintain by adding in the complexity, by adding customizations into the system and scripts and strange off, off processes here and there. It just means it's. It means it becomes really cumbersome to manage and look after, and you end up having to increase staff levels to look after it. You end up increasing the complexity and the risk and likelihood of things to go wrong in the system.

So, yeah, I, I think configured, customized. Yeah. And it gives you probably, if you customize too much, it gives you a great chance to end up where a couple of organizations and it obviously lots notes, domino implementations, where, where they say, oh, I have 3000 applications here, databases, but I don't know which ones are used and what they are for. And so I like that.

Laurie, your number one best practice. I, I think I agree with David. So basically if we think about the service as a platform, there's lot of good stuff built in it, so don't customize too much. So of course the Porwal you can modify that's, that's what you can do.

And, but don't start messing with the, kind of the scripts that service now has built, because that will affect all the, kind of how to upgrade coming to the service now and how the, for example, our application and how that works within the application. So you have a lot of customization and you miss up something basically I've heard for example, is that no, I have actually seen that, that somebody did change and then we couldn't modify workflow with service now anymore. So that's an example for that. Yeah. And you know, I like that because 24 can confirm later on when she's closing the UN.

So on the other side of the fence, so to speak, when I look at our own internal Salesforce deployment, the first thing I did before we started with Salesforce was I graded very few slides. In fact, one slide mainly was guiding principles. And amongst these guiding principles, I think the number one theme at the end was don't reinvent the wheel use what is there, look in the store, but don't do yourself. I liked David. I liked that sign.

You had, you are not so different from the others at the end of the day. I think this got better. I have to admit with the shift to SaaS.

So in the, on premise world customizations, even more, more popular, but I think when we start customizing, we need to do it right. But moving forward. So I know you both are biased on that question, which will come right now, but anyway, why should an organization use service now and nothing else to accelerate workflows? So why would you say from your perspective, ServiceNow is the right choice for that or why not?

So I'll, I'll take that. I think the, from my perspective, I think it's the, the breadth that service.

So the, the variety of the modules and the, when you are, when you're designing and setting up your workflows, being able to have all of that data in one place makes, makes that so much of an easier, easier process. Even if you don't have, have it all in service today, it makes the roadmap of where you want to go so much easier as well. You're able to, you're able to say, okay, well today we're going to have in a year's time, we can use this. We can update this workflow and simplify it more to, to keep it all within, within service now.

And, but the other benefit is that even if you, you don't want to do that and don't want to go down the ServiceNow route for those modules, ServiceNow is so large. And so universal that your, the likelihood it is that your existing systems, your existing providers will have an integration active box. Anyway.

So yeah, it, it, it just seems like a sort of a staple system where you can that allow workflows. Yeah.

And, and Larry, what is your service now pitch? Well, like they say, service now is built for, to manage everything as a service. So as we hear bit multiple presentations today, so if organization is an in-house productivity and create savings in the long run service now, I think is an excellent tool to achieve these goals. And it makes sense that you kind of push everything to one platform or much as you can. So you have one platform, one data model, one architecture.

So your support teams and administrators don't need to learn a new platform to manage or have multiple tools with integrated together, and then try to manage those integrations. I, I, my background is from integration business. So that was something that I did in pass. So in the past, I would say something else maybe, but, and if you think about IGA solution, for example, the 13,000 employees within the service.

Now, I, I think they will put a lot of effort to do the development for the platform. And that will also be a backbone, of course, our IM solution within the service now. And it makes sense. So it's a high security, safe source platform, high availability. And I think the 80% of fortune 500 companies, or the hundred new customers monthly within the service now, I, I think most of them are great because there's 99% kind of renewable rate on the service now platform.

So, Yeah, and, and I think this entire integration theme is, is nothing. You know, you said you come from doing integration business, you would have seen a different, I believe at the end, even if you have a platform there's a lot to integrate at the end of the day. And so I could say, okay, I also have some, some history in the integration business. So I spent some time talking, thinking, writing about enterprise service buses, even, even doing architectures back in the days.

So, so quite a while ago. So I I'm at the end, I'm, I'm, I'm a big believer in having systems which, which help in integrating. And I think this is probably where it comes to the point that it, that it also helps you doing integrations by having so to speak the hub that, that helps you in doing so, which is I think a good thing.

So, so when you go a little bit more in practice, what are maybe the, so you braced it a little, but what are maybe more the pitfalls from an experience perspective with integration into the service now platform. So service now in the outer space, maybe lower you start this time. Can you repeat the question? Sorry.

Yeah, For sure. For sure. I can. I think the question at the end is, so we, we, you braced service now for, for the integration. On the other hand, you, you have some experience, so what are the pitfalls? What are the things where you say, okay, here, you need to be careful, keep this in mind when you do integration. So that really works smoothly. So what are the things to consider or, or the things where you say, okay, this might get bumpy if you do it wrong.

Yeah, of course you need to understand the target system and the kind of the source system that, how do they interact and what, what is, what do you want to accomplish? So you need to do the planning carefully because there might be something that you don't think about it. And of course you need to see that, okay, what is possible within those systems? Because everything is not possible when you do an creation within the service.

Now, of course there there's, there's no limitation, but if you think about the system, which have a certain API added, so, and you might not be able to modify that. So you need to think about, does this fit my purpose or not? If it doesn't, it doesn't make sense to start doing the integration, if you can't accomplish what you want to accomplish, if that makes sense. Okay.

David, I think over complicating is the, is the biggest pitfall. So when we were looking at designing this, we came up with a, we initially came up with a list of 13 systems that we wanted to integrate, and we decided they were all essential. As we went through the process, we narrowed that down to about seven and then having gone live, I think we probably only needed four.

So you, it's very easy to get wrapped up in the art of what's possible. Like Laurie said, where you can, you can make things so complicated and try and do too much from the offset.

I, I guess the, the recommendation to avoid that pitfall is just to, to start with the essential start with what you truly, really need to integrate with and then build up from There. Yeah.

And, and I think that that fits well to, so I'm more, more as you, you know, I'm more the identity management guy from history, at least I, to a lot of other things, but so just for my, my own experience and you look at many IGA projects, they started, oh, we have 400 business applications and other systems out there and, and we want to integrate them all. And then three Analyst later, they're still only three systems integrated or something like that. And the project is perceived as a failure, which is not necessarily true.

I, I think there, there are two, two things in that. The one thing is integration. When we look at IGA, there are a lot of systems where it doesn't make sense economically, where you could use just the, sort of the good old service management service desk capabilities to say, this is manual fulfillment. Also something you could can do in that world, we are talking about. But the other thing is, and I think this is the point here, when you talk about the things don't over promise, but look at what are the systems, what are the things I'd like to do? What are my use cases? What is the priority?

What is the technical visibility? How much does it help me in, in optimizing processes? Where is the biggest benefit? And if you just create an excellent and do a little bit of rating amongst three or four criteria, you will easily come up with the 3, 4, 5 integrations. And based on a couple of relative, also relatively few use cases that help you doing that. And so I really like that recommendation you give around integration.

So, so be careful, understand what it means. Don't go over the top here when, when we look at the use cases. So over the course of this event, we have seen a couple of use cases mentioned also by you David, but maybe both of you could come up with a top three list of your favorite use cases you should build on service now, maybe be beyond good, old, pure play it, service management.

So, so David, do you wanna start and then low? Yeah. So I think that the first one that comes to mind is the employee events. So talking about onboarding and off onboarding, and not just again from, as you said, Martin, not just from an ITSM perspective, but holistically from an end to end process, there's a lot of different departments, a lot of different functions that play a part in onboarding or off boarding.

I think creating a workflow within service now to do that from, from the recruitment process through to the, the provision of assets and accessories and computer equipment, credit cards, cars, whatever it may be and going right the way through to access management. And then through the whole life cycle of that onboarding process, to training to the coaching, to checking in a little bit further down the line, that's something that, that we are we're exploring now.

And it has already, we have already made some improvements on that, but the, the art of what's possible there and the potential is huge. Lovely. Your top three. Yeah. So of course companies will start with the IDSM as we have heard. So basic incident downturns and problem, and, and change management. What I like about our business, the IGA is that that will give you control a lot of things. So that will help with the onboarding as, as David mentioned.

So that will be something to, to build on that helps with the seeing that you don't have unnecessary accesses or unnecessary licenses within the service now or within the other other systems as well. And we can add that SSO through ad and so forth.

So I, I would say that IGA is something to look for once you have, of course, the platform in, in some other cases and okay. Yeah. I think that that's kind of my, my give at least, so that will keep a lot of power and that will help with onboarding because the, also the Porwal is somewhere where you order the laptops, your mobile phones. Yeah. It'll be easy. Porwal end users and so forth And, and integrating I chain ideas a way a must, because there's no way not to do it if you want to do it right. Because there's manual fulfillment, there are service requests.

So, so there's the need for that integration, whichever way you take it. So we have a couple of questions from the audience here. And so I'd like to, to get through them, to ask you for relatively short answers on that in the interest of time. So the first, first one is when I'm talking about automation of workflows, we also have to talk about interfaces. How about the interfaces of service now to the on-premises world?

So any, any experience here, anything you'd like to mention? Well, I, I can start with, so service now comes out with excellent APIs and also with the OnPrem. So there's the mid server which can install OnPrem. And that will kind of get the information from the service now. And for example, if you have on-prem 80, which is one of the major cases I would say, then you guys use that mid server to communicate with the on 80, and that will communicate or with the service now to get the tasks. Okay. So Basically David, yeah. David. Yeah.

I, I would echo, echo, Laurie, I think using that mids server and getting that design right. To, to keep that interface as simple as possible. Yeah.

That's, that'd be my tip as well. Okay. And the next question is one, I, I really like, we all said, don't over complicate the solution, but what if the solution already has been, become overcomplicated? So how do you cut, cut bait and start over? So the way our approach that was to get stakeholder buy-in, so go as high up in the organization. As you need to, to get the buy-in to say, we're gonna simplify this and create the consistent approach, getting those guiding principles right. Of the work you are doing, whether it's from scratch and service.

Now, whether it's just a general process improvement, make sure you've got the stakeholder buy-in to do this. And if there's any, any arguments or anyone saying that they can't simplify it or can't do it this way, then present your case and, and do it that way. Cool. Laurie. Yeah.

I, I would go again with David, so be the business case for, for that, and kind of build up their pro. So that, that will be my, my give or take for that.

And, and I think there, there are two elements and the answers, which I really like to, to, to, to emphasize again, the one is if there's the wish for over complication ask for what is the real reason behind that? Does it really deliver value to your re organization and, and many things that are overly complicated are not a must. The other part of that is it's not, you know, so I'm, I'm I'm parent, my children are already larger, but when they were younger, sometimes there's something on something went wrong and then kids tend to try to hide that. And that never makes things better.

So better stand up and say, okay, this is, we did it the wrong way. Yes. Okay. But we also learned how to do it better. So sell it as a positive and say, okay, yes, we need to fix it instead of wasting bad, good money after the bad money. I think this is also another thing hard to, to Sodo.

See, final question. And then we come to an end when building the plan, any suggestions on how to measure your success, any idea about a KRI KPI. So key performance indicators, specifically very short answers.

David, you look like you want to start. Yep. So from my perspective, I'd start with what you can measure today. So make sure you've got some baselines to what you're trying to measure, because it's no use having great metric targets for post implementation. If you can't compare to what it was like before. So start with your today.

Look, look forward from there, Laurie. Yeah, I, I will, I will say the same thing. So basically you need to have a baseline. What you compare it again. I was responsible for the support in my integration business. So kind of making those KPIs and then measure it. So if you are changing from one ticketing system to another, you need to know how fast or better or how you handle those tickets before. And what was the kind of gain from, from changing to something else?

Just an example, of course, but there's no straight answer that this is okay, PI, But, but it's, I think the, the key of the answer, if you don't have a, a baseline, you can't demonstrate your success. Laurie and David, thank you very much for this. Very interesting talk for the insights from practice.