Subscribe
Share
Share
Embed
Let's talk IRM. The real stuff. Join Jada, a certified ServiceNow IRM practitioner, as she breaks down compliance automation, risk frameworks, and the strategies GRC professionals actually need. No fluff, no theory. Just real talk from someone who builds it. A SaaSCE Boutique Podcast.
Here's a question nobody asks before they buy the ServiceNow IRM application. Are we actually ready for this? Not, can we afford it or does it check the boxes, but really are we truly ready for this application? Because what I am seeing in community forums and analyst research and conversations behind closed doors is organizations doing everything right in the procurement side and everything wrong on the implementation side and by the time they realize it, they're years in, millions deep and no closer to a single improved process that was promised during their original demo. So, today we're playing true or false and the statement is IRM begins before tool implementation.
Jada:I'm pulling three real stories from the field and I want you to listen to the patterns because by the end of this episode, you'll have your answer and more importantly, you'll know what to do before you ever push purchase. What's good, Army Screw? I'm Jada and this is Let's Talk IRM. Alright ya'll, so I want to start with an IRM implementation order storing. So the comment goes, Hi team, I want to check for a ServiceNow IRM Greenfield implementation, let's say what should be the ideal order of implementation of ServiceNow IRM products?
Jada:Is it should be started from the policy and compliance first, then go with risk management and then to entity scoping? Please post the answers based on your expertise. I am looking forward to reading the responses. Thanks. So this is the initial poster's comment and the first thing that comes to mind for me at least is, well what is the business trying to do?
Jada:Are we looking from just a technical standpoint and then telling the business where to start or do we truly understand how the business is operating and what their pain points are? Every organization is different and I completely understand that some may be risk heavy and some may be policy heavy, but if we're not fully understanding how the business is operating, how they're doing their current processes today, what are they struggling with and what are they hoping to accomplish, it's really kind of hard to answer a question like this without more context. Now looking at some of the responses, we kind of get a few different perspectives. First perspective we have is that everything is based on entity scoping. So basically, I would start with either policy, compliance or risk.
Jada:Doesn't matter which one in combination with entity scoping. Now, this particular comment is interesting to me because if we're looking at from a technical standpoint, how are we going to scope our entities? Are we doing it from a business unit level? Are we doing it from a technology level? Are we doing it from a location level?
Jada:It's not really clear because if you're looking at your GRC team on the business, how exactly are they scoping? Are they looking at just groupings of technology products or are they actually looking down to the nitty gritty of their tech stack down to what cloud resources are doing what? So, response kind of gives me a bit of uncertainty on whether or not I should go with entity scoping without understanding the concepts of how the business is operating. I understand that the commenter is pointing to the success packs that ServiceNow provides which are great resources to learn more about the IRM application but one thing that I find about these success packs is that they don't really give enough clarity to understand that it's important to understand how the business is operating before kind of jumping into your full Greenfield IRM application implementation. Furthermore, we have another comment that says that we should just start with entity scoping, then policy and compliance, and finally risk management.
Jada:Now, this is pretty much a vague comment based off of what the user is asking for, but it's also pointing to checklist items, which is another resource that ServiceNow provides when it comes to implementing IRM. It's good to have a checklist in place to know what you need to implement within the IRM application but from my perspective, I feel like looking at those checklists again, it fails to consider what exactly is the business trying to do and every business that is unique, you can't really follow an implementation checklist without understanding how they do their processes, where do they sit at when it comes to their processes and how you can translate those workflows into IRM. So, just starting with this first comment in regards to implementation order, I feel like we are losing sight of how the business operates and I know I keep saying that because that is a key part of being able to have a successful implementation for ServiceNow IRM. If you don't understand how your business is operating, if you don't understand how their workflows are today, if you don't understand what their pain points are, how can we say that ServiceNow IRM is going to be the solution that solves their problem?
Jada:So, as I would say again, in regards to implementation order before looking at any components of the IRM application, let's start with the business and let's see where exactly they sit at when it comes to completing their processes so that we can then understand what type of roadmap do we need to develop based off of the now create documentations and the checklist that ServiceNow provides for the IRM application. So, let's move on to our second story from the field. Now, we just finished talking about the importance of understanding the business needs and what their pain points are. The second story starts out as pretty typical where the commentator is essentially asking how they can take policies within the IRM application of ServiceNow from a low environment such as the dev environment to a higher environment. That's a typical question, technical, nothing, nothing really out of the ordinary there, just looking for some feedback from the community.
Jada:Now, what really catches my eye in this exchange is the follow-up comment that the commentator posts and they say this, one additional query, I am working on the customer who is not having matured process and unexperienced team who is currently handling the GRC process manually, got stuck with language barrier as well as customer is not speaking English and we have non tech communicator. During discussion with the team, they said we have around 60 plus policies which need to be implemented and now I am not getting a clue to tell them the count of policies which can be considered for go live. Now, the key part of this story that really stuck out to me is that the customer has an immature process and an unexperienced team that is handling GRC processes manually. This is a big deal because when you're going from a manual state of doing things, the climb to go to an integrated risk management strategy can be difficult if you're not properly planned and prepared for it. And I say that because in my experience, I have seen organizations take those manual processes and try to customize their IRM application to meet them where they are, essentially turning integrated risk management, which is a powerful tool on the Now Platform into a very expensive spreadsheet.
Jada:And that is not what integrated risk management is for. So, from this perspective, my only concern is whether or not this commentator was able to get through to their customer to understand that before we jump into the ServiceNow IRM application, are we truly understanding what our goals are? Are we truly understanding what we're trying to accomplish by importing these policies into IRM? Are we just doing it just to have a place to store policies as if it's a shared drive or are we importing these policies so that we can tie our controls to them or even our exceptions to them? My assumption based off of what the commenter is saying about an unexperienced team is that they may not really know why or how or the purpose of putting these policies in, but know that they have policies that have similar language to them and they can get it in.
Jada:Another piece of this story that sticks out to me is that there is a language barrier that they do not have a non tech communicator. It is very common in this space where I've had to wear dual hats of being able to speak as a business user and be able to speak as a tech implementer. It is very important to be able to speak both languages in order to translate between the two so that you can get the value out of integrated risk management in the ServiceNow platform. Without having that clear understanding of how the business operates, it's gonna be very hard to direct the business in how they can transform their process into the integrated risk management application the way that it's meant to be. Out of the box, I do believe that the IRM application has a lot of benefit to an organization that is getting started in their integrated risk management strategy, but it takes an understanding between the two on how to make that work.
Jada:So, I'm not quite sure how this implementation ended for this commentator. I'm hoping that it went well for them and they were able to get the job done, but I would also probably believe that this was incredibly difficult for them and that there may have been moments where the customer got frustrated and vice versa. But one thing that I really truly want to highlight to the audience here and the listeners is that before tackling any piece of the ServiceNow IRM application, take a step back, understand the business, understand how they're managing their processes. Are they currently working in silos today? Where are they storing all of their data?
Jada:Where are their playbooks? How are they getting their job done? Fully understanding how they operate as well as understanding their pain points will get you a good solid foundation to understand how the ServiceNow IRM application can be a benefit to the business. So, if you're in a similar spot like this, take a step back and get to know your business counterparts first. So moving on to our third story from the field, I feel like I've kind of left the best one for last.
Jada:And I say that because it is kind of an extreme situation where we have an organization that invested into the ServiceNow IRM application. They spent millions of dollars trying to implement the solution. They switched between consulting agencies to help them with the implementation and at the end of the day, they still ended up with no progress. Now, to me that is extreme, that is quite unfortunate, a lot of money lost, but also highlights that this is probably a similar story that a lot of organizations experience where they spent a lot of time trying to implement the IRM application on the ServiceNow platform and it seems like they keep going around in circles. I've heard this story before and some of you guys may be experiencing this story today or even heard about it from others.
Jada:Now, what I like about this story is that it's written by Michael Rasmussen and based on some past articles that I've read from Mr. Rasmussen, he's made it very clear that ServiceNow IRM is not an easy tool to implement and it's quite frustrating across the board with other organizations. Just looking at the article, just highlights of sections is the core issues of ServiceNow for GRC is that it's cost and complexity. It has performance issues, maintenance and upgrades are difficult. GRC decisions driven by IT and not business needs.
Jada:Consulting firms stack the deck and the story goes on that it's across healthcare systems, retail enterprises, banking and large FinTech organizations. Now, I can believe that that is probably the case, that a lot of these situations have happened. But when I do look through the article, just starting with the first bullet of cost and complexity, the article says that ServiceNow promotes its GRC modules as out of the box solutions, yet in nearly every client conversation I have, these modules require extensive and expensive customization to even begin functioning as needed. Now, when I hear that, I can understand that if we were trying to take our existing process, whatever state it's in, and merge it into ServiceNow, it may not fit like for like And so a lot of time I've seen instead of understanding what the differences are, we have a tendency to want to change how the out of the box operation works so that it fits what we understand. Now I can't say that's the case for everyone, but I can say that's the case for what I've seen in implementation practices where the request from the business is, well, we don't do it that way, we need to do it this way.
Jada:So how can you get it done so that we can do it the same way that we've always done? Now, there's two ways to that situation. The tech team can agree and make a way to change how the out of the box functions so that it meets how the business is working together today or they can push back and really get an understanding of why do we want to continue to do it the same way in a new product that we've purchased. I mean, from my perspective, if we are adopting a new solution, change comes with it. So we have to accept there's going to be some change when it comes to learning how to use a new tool, learning how to reimagine or reinvent our processes.
Jada:So instead of changing how out of the box works, let's take a step back and understand what are the components of the out of the box solution that is supposed to be successful that we can leverage to improve our processes, right? The second bullet point, performance issues. The underlying architecture of ServiceNow was not originally built for GRC. Clients report slow response times, clunky workflows, and user experience limitations, especially when dealing with cross functional risk and compliance processes. Now, I can admit that sometimes when I am working in lower environments that the dev environment may be slow or even UAT may be slow.
Jada:Every software product has its quirk, but reading this particular bullet point makes me want to understand is, does the business understand the Now Platform? Are they only looking at it from one lens? What processes are happening underneath that could be slowing down their ServiceNow instance? Are there too many script includes? Are there too many business rules firing off at the same time?
Jada:There's a lot of reasons why you would have performance issues on your ServiceNow platform, but the key sentence here that I'm seeing is dealing with cross functional risk and compliance processes. This is almost telling me that we have compliance group A and compliance group B doing their own thing. Instead of integrating our processes so that we're in a unified approach for risk management, we are still trying to work in a siloed way of working, way of process in the IRM application and we keep stepping on each other's toes because my process is getting in the way of your process and your process is getting in the way of my process. So, that's kind of how I'm interpreting it. I've seen it in practice before, not saying that this is the case for everyone, but it really does take a unified approach when it comes to utilizing integrated risk management on the ServiceNow platform so that instead of running into issues between all the different groups that operate on the platform that we're working seamlessly together.
Jada:The third bullet point, maintenance and upgrades are difficult. ServiceNow Relational Database Foundation includes an overwhelming number of interconnected tables. Customization increases fragility. Even ServiceNow's GRC modules can become unstable with virgin changes. For organizations with moderate to high customization, every upgrade is a risk.
Jada:Now, that is a true statement. When you are customizing on the ServiceNow platform, you are risking breaking when upgrades happen. A customization is meaning that we're taking away out of the box functionality to fit a mold that we want because that is what we're used to. And this kind of goes back to my premonition of change is hard, some organizations don't want to experience change and instead of adapting to a new way of doing things, they want the new tool to adapt to them. Then what comes the time to upgrade and things break.
Jada:Scripts break, processes break, access controls that were customized break, and now we're spending a certain amount of weeks trying to fix whatever broke from the upgrade so that we can get the business going again. This is why I try to encourage anyone that is learning or that I'm teaching IRM to that there needs to be pushback when the business is asking for customizations. Sometimes it could be just a translation issue where the business doesn't quite understand how their current process translates to the IRM application. And that's where we come back to wearing the dual hats of understanding how the business operates and also understanding from a technical implementation. This also goes back to understanding how the business operates, where are their playbooks, are they siloed and where do they keep their data at.
Jada:Understanding the business will allow us to be able to articulate to them what we can and cannot do and shouldn't do. And as the saying goes, but I've heard plenty of time and service now, is just because we can, doesn't mean we should. And that goes for customizations. Now the fourth bullet, and I'll leave us with this one, it's GRC decisions driven by IT, not business needs. This may be the most persistent challenge.
Jada:Many implementations begin with IT departments selecting ServiceNow simply because it's already in use for ITSM. The problem? Risk, compliance, audit and legal teams are not consulted or heard, one organization told me. Now I can believe that, that I have seen that, I have seen this particular situation where the GRC team has wanted one tool, they weighed their opinions on a particular tool, whether it's because of experience, ease of use or whatever the case is, and then the next thing they know, IT has decided, nope, we're going to go with this product and you need to accept that. I've seen it.
Jada:Now, that's a huge disconnect when it comes to wanting to work collaboratively in my opinion, but I can also understand why that may be a solution that the IT team would see as valuable. Because when you think about it, the network team has their own tools, right? Who manages those tools? The network team. The security operations team, they have their own set of tools and who manages those tools?
Jada:They do. Now, historically, GRC teams are known to not be technical and that's not to down them or just to send flat to them, but historically working in spreadsheets and Word documents doesn't require any kind of technical maintenance. So, if we're bringing in an application for the GRC team to use, who is going to take that ownership to maintain that application? That is a conversation I have been in previously. No one really knows.
Jada:And when you don't have clear ownership of an application, how do you ensure that it's going to maintain the security policies that are required for the organization? Having IT involved, if you're already in a ServiceNow house that's already managed by a platform team, I've seen it come out and say that, hey, ServiceNow IRM is the way to go because we already have a team managing the platform. Now, the offset to that is just because the ServiceNow platform team manages the platform, it does not necessarily mean that they truly understand how IRM works. Like we mentioned before, there are several many tables inherited in the IRM application and so it takes an extensive amount of time to understand the purpose of these tables, why there are so many tables, and what function will they provide to the business. So I can see how this can be a very peculiar situation where which side is right and which side is wrong.
Jada:It's kind of a thin line, honestly, if you ask me, but from my perspective, if I were to be in the decision seat of to go with ServiceNow IRM or to not, I would ask who is going to manage the application for the business. That is a key point in understanding down the road that when things break or when updates need to happen or changes need to be made, there is a clear path of who's going to take on that responsibility. So again, just as I've reiterated for each story here, while ServiceNow IRM in of itself implementing the tool takes time, it is very important to start your implementation with understanding the business. That business concept is going to help you get through your tool implementation and be able to find what is that low hanging fruit to get that quick value so that you can continue to show the success of the ServiceNow IRM application to your organization. So true or false?
Jada:IRM begins before tool implementation. Now, everything we've just heard today, clearly that's a hard true, right? We've had three different stories, three different situations, but the same pattern. Nobody stopped to understand the business first and that is the takeaway I want you all to have. IRM does not start when you install the plugins on the ServiceNow platform.
Jada:It starts when you sit down with your business counterparts and really figure out how they actually operate. Get that right and the tool becomes powerful because you're understanding the business and where to take the business with the platform. If you skip it, then you're just building an expensive spreadsheet. If you're listening to this and thinking, that's us or I've been through this, I've been through something like that. I want to hear your story.
Jada:Send it my way. This podcast is built on real stories from real practitioners and yours could be in future episodes. I'm Jada and thanks for rocking with me today. Let's Talk IRM is a Sassy Boutique podcast. If you're looking to go deeper on how to implement IRM as a strategy and as a ServiceNow application, we're building something for you.
Jada:Head to thesassyboutique.com to join the waitlist and be the first to know when it drops. Connect with me on LinkedIn to keep the conversation going and follow the show so you don't miss what's next. Links are in the show notes. But until then, friends, let's keep making sense of IRM one conversation at a time.