View Recording: How to Un-Screw-Up Your ServiceNow Environment

Bryan Schrippe 0:19 Good morning, everybody. Well, let’s get going. I’d like to take a minute to welcome you to one of many webinars I host over the course of a year directly related to ServiceNow. This one specifically. Is I like to call it my yearly, but recently it’s been yearly on how to unscrew your ServiceNow instance. So this is a culmination of things that we have seen in instances. Over the past year. Of things that clients have either seen or been engaged in, or things that we’ve helped fix. And it’s a whole bunch of musings of symptoms and solutions, and we’re going to talk through a lot of that today. But myself, my name is Brian Trippi. I’m the lead technical architect of the ServiceNow practice here at concurrency. I have a little bit over two decades of IT operations. Experience with specific. Experience with ITIL and setting up help desk infrastructures and my specialty is automation and business process automation and I’ll be guiding you through our webinar today. So what are we going to be talking about today? So we’re going to be talking about identification and common things that we see within instances to determine whether or not they are screwed up or not. Symptoms and solutions. When to start over, versus when to fix, and then lastly, how can we possibly help? All right. So let’s start with identification and specific commonalities to instance that we have seen clients deal with that are less than optimal. So before we necessarily fix things, we need to recognize that they’re broken. So if you check out the list here, this captures the top signals of an unhealthy ServiceNow instance. And every one of them means that your platform isn’t. It’s not delivering its promised potential right. So if let’s say you have inefficiencies in a workflow process, if your incident to resolution workflow has maybe 10 steps and sticks approvals and a whole lot of complexity, there’s a reason why your incident management tickets pop or pile up or your. Case workload piles up. You know. So if you’re looking at your tickets and you’re seeing your forms being overloaded with information or duplicated tasks, or finding steps that people are habitually bypassing, you may have an issue. You have low user adoption, so when agents and end users go back to e-mail or in some instances I’ve seen them even go back to spreadsheets, it’ll tell you that, you know, maybe your UI or your process isn’t as intuitive as you thought. You know, user training can help, but if they’re intentionally avoiding leveraging something like employee center or the experiences that you’ve given them from a front end perspective. There might be a deeper UI. I or process problem. Data quality is another thing that we’ve seen over the past year. You know, if your CMDB is being populated by multiple different areas, it’s not being audited. You have duplicate CIS stale records, bad data. You have issues with reporting or automations. You know when we’re looking at cmdbs, I like to do kind of like a sanity check when I’m looking at ACI and do that with my clients too. Like, if I’m looking at ACI and I ask them, I’m like, how much of this data do you trust? And? They can’t answer me with specificity in 30 seconds. Then we know that maybe their CI has a little bit more of. A or C CMDB slash CI has a little bit more of an issue then say. A clean cmdb. You’ve seen a lot of customization overload. You have a lot of different teams that are involved in ServiceNow architecture and build outs, and every team could be building their own different scripts and forms and flows. And if it’s not being routed through either a centralized development group or being handled through a governance or oversight committee, then you know you have things like Shadow Dev OPS that pop up, and next thing you know you have issues with upgrades. And things that were operating efficiently no longer do. What about technical and things in the maintenance world that are red flags? Things like performance problems. You know when you’re launching a form or when you’re launching a flow, things are slow. You know you have things in your API queues that are taking long to go. Delays in queue times. All of these things add up to loss efficiency inside of your environment. How about unresolved bugs and issues? Things that have been sitting out there in your backlog or your story that are high priority defects that haven’t necessarily been fixed because you’ve been too busy firefighting other things. If your backlog in your instance looks kind of like a black hole? And you have things that have been out there for a long time. Your processes may need a reset. Documentation is another huge thing that we’ve seen in clients over the past year. Some things have no documentation. There are other things that have a lot of documentation, but that documentation’s outdated. Auditing that documentation. You know when or if you have a developer that comes in and develops something for you and leaves, and there’s no documentation. How does the next person support it? What about high maintenance costs when you have things like firefighting going on in your infrastructure, your patching scripts, your fixing bulk and flows, you’re resolving user complaints, you know. That’s all IT infrastructure budget that you could be leveraging to do new features, new processes, new things. If your infrastructure was operating efficiently. So I want you to do a thought exercise with me as you’re on the call and out of all of the things that I’ve talked about, which of the things resonate most with you today. And anybody can do this, but if you just want to like, raise your hand quick. If you’ve battled any of these in the last month, just pop. Pop your hand up and let everybody know that you’ve seen something like this. OK. So we’ve diagnosed system symptoms and root causes. Now let’s surface 12 of the most common missteps and things we encounter in clinic. This is so I’ll kind of run through them in like 3 categories I think. Technical process and governance. So let’s talk about the engine under the hood. Right configurations. Things like tables that haven’t been indexed. Client scripts that are extremely. Commutative to the instance. Runaway flows that have looping logic that just keep going and going and going. You know we’ve I’ve ran into clients that they’ve had. They had so many client scripts running on their forms that when their analysts open the form, it would take 5 seconds to load because of all the client scripts that needed to load because of all the different things. That they were trying to do as far as efficiency was concerned, it was something that they had to battle and fix. What about configurations causing upgradeability issues like UI changes, deprecated APIs? Or things in the automation design world like huge mega flows that have like 50 steps in their extreme complex, no sub flows, no documentation where they become extremely hard to maintain. You know, it’s like I’ve also had a client that had a script that was in the environment that was like 1000 lines. When it could have been broken out into a much, much easier sub flow scripted you know, framework where they’re doing things a little bit more logically. Speaking of scripts, what about script performance? What if you’re doing extremely heavy glide aggregate calls? You’re not doing. You’re not doing things like. Set limits on your your queries. You know every so slow script in your instance adds seconds to every user interaction, and those seconds pile up over the course of a day. Another thing we’ve seen lately is lack of testing frameworks. During change management, you might have the capability to do testing, but creating something repeatable that can be run on things like upgrades. You know, having those in place allow you to have those upgrades go more seamlessly. Let’s talk about process adoption and pitfalls. What about things that are different in the environment? What about your cloning process production being different from development and test? Unexpected behaviors kind of slipped through when you’re developing in those environments and they’re not the same as production. What about process complexity workflows that have so many different approvals and branching logic that it becomes convoluted in the process takes forever, so your users end up suffering as a result. What about not leveraging the licensing that you’re paying for? Another big thing that we’ve seen this past year is people have that have bought licensing. They’re currently not using or. They don’t know that they have it licensing audits yearly can help mitigate some of those. How about governance pitfalls? What about the limited use of csdm? Not not leveraging. Your Ci’s and tying that to specific things in your in your infrastructure. As far as services, business services, technical services and being able to understand those at a high level. So you can explain those services to the business. All of these add up to a few different things. Right. Technical debt, budget overruns and team frustration. OK. So how can we mitigate some of these? So these next set of slides are going to walk through some symptoms that we commonly see with specific aspects of things that may be going on in your environment and the symptoms and the solutions that are out there that may be able to help mitigate some of these. Things and some of it you can implement in your environment, others. You may need to go through some process work. And to to figure out. Well, let’s take a look at them. So let’s talk about performance. So this slide captures one of the biggest cries for help we see in ServiceNow. General slowness. And unpredictable slowness like you thought it was slow, but it’s not necessarily slow in the times that you necessarily see it slow, whether it’s an analyst waiting on a form or an integration timing out, all these point back to like. Sub optimal instant setups. So let’s talk about slow loading times. Pages taking five to 10 seconds to render. That frustrates end users. Or it drives shadow it? High API usage. What if you built something that’s doing hundreds of thousands of interaction calls a minute, and next thing you know you’ve got a ServiceNow bill for $100,000 for interactions that you didn’t know you were using? What about large datasets? Client scripts that aren’t using set limit criterias that are choking your memory. What about concurrency issues? And indexing problems when two scripts scripts hit the same record without indexing, you’re going to get deadlocks. Road locks and timeouts. What about execution times, business rules and client scripts that are so interactive that they take an extra 500 milliseconds here or 800 milliseconds there every second on a form load adds up? And it isn’t just scripts. It could be flows, events, client scripts, every additional thing that adds latency or less efficiency is can add up. So what can we do? So now that you’ve kind of seen some of the headaches, how do we address them? So what I like to do is with all of our clients, I like to set up some things that they can do daily, weekly and monthly for daily. I like to do system diagnostics, so check memory, CPU, JVM, health each morning so you can catch runaway scripts before they snowball and then tackle them. API usage. Look at your 10 most commonly used API. If a background script jump from 1000 to 10,000 calls overnight, you might have a problem. Looking at the transaction. Any transaction over 2 seconds should appear in here. Investigate anything that’s extremely high immediately. It may be something system related. It may not be. Weekly reviews looking at scheduled jobs. Review those jobs. Are you running too many at once? Stagger them to avoid peak hour collisions and take a look at the top 20 transactions using the performance dashboard to list your slowest transactions. And tackle the biggest offenders first. On monthly reviews, monitor your table growth. Tables are growing by 10% a month. That’s a huge red flag. Archive or purge stale records based on your. How long you are able to hold those records in your environment? If it’s five years, seven years, get rid of all the outliers on a frequently basis. Again, look at your performance dashboard. Look at the slow scripts slow transactions. Leverage the built in indexing suggestions feature. Then again, use those index suggestions each month. Add the three to five indexes, typically on a table that yields 20 to 50% speed gains on data retrieval. And if. Your user table’s exploded. Look at, you know your testing or orphaned accounts. So imagine if you could do some of these and you cut maybe some of your page loads or form loads down by like 2 to 5 seconds. Would that increase agent efficiency? With that on the employee center, if you’re running catalog client scripts, would that help them get through forms more efficiently? Think about that for a little bit. Implement this simple review cadence Daily, Weekly, monthly. And you’ll transform reactive firefighting in the proactive performance management. Clicking just a few spots each morning, you can spot issues early and keep your environment performing at its peak. OK. Another thing that we’ve seen. Upgradeability issues, so upgrades you know, for some people, they’re the bane of you know. Analysts or an administrator’s existence, right? Every patch cycle without preparation is like diffusing a bomb, right one. Wrong script. One API call that gets deprecated and you don’t know about it. And something goes kaput and it’s maybe. Something super critical that’s important. On the left you’ll see some of the most common integration or upgrade headaches. We’ll take a look and see how we can assist with those. Now nothing kills momentum like a failed upgrade like halfway through. Locked records. Skipped messages. You gotta go through all your skip logs. You know you can have incompatibility errors. Oops. Where did I go? There we go. Sorry everybody. Back here. OK. So when we’re talking about incompatibility errors, let’s think if we have specific APIs that maybe we’re leveraging last year that we’re not leveraging this year. And maybe a module gets upgraded and those APIs are no longer in use, but you’re leveraging them and you didn’t know about it beforehand. Well, now if you push all that information up to production, you have to go back and rehash all of those API’s that you were leveraging and refactor them. What if you’re leveraging a custom script or a business rule that worked fine? In in, you know, Xanadu. But now you’re going to go up to Yokohama and it no longer works properly because you didn’t test enough. What about an integration failure where rest and soap calls that one once passed and we’re working? Now time out or have 40 fours or something on the platform changes. UI inform issues what happens if a field vanishes. Client scripts don’t fire properly or widgets break. Suddenly your forms are unusable. So how do we bulletproof our next upgrade? So let’s flip to the right side and let’s talk about what steps we can take to kind of proactively manage that. So one is the upgrade and the preview inspector, right? So if if we’re looking at if we’re looking at upgrades, making sure we’re previewing the upgrade. Understanding. What differences are going to be coming as a result of that upgrade and try to spot any issues or conflicts? Making sure we up making sure we understand if there’s any deprecated APIs that are coming out of the development group for specific particular module. Checking release notes. Making sure we’re understanding what net new features are coming in. If there’s anything from a development perspective that is being deprecated and if it is refactoring our scripts to understand that you know, if we have a deprecated API, we need to proactively manage that. You know adding in. Defensive checks into our programming. As far as our integrations are concerned, starting to leverage ATF or postman to do checks against our internal endpoints, you know from a rest perspective or soap perspective, understanding that whether or not it’s built and responding properly to our sub production upgrades. Auditing, auditing our performance again, you know, making sure that as a result of an upgrade, something didn’t get introduced that is gonna. Hinder performance for any of our forms or things like that. Manage ATF frameworks right? So it runs and checks your key proactive business steps. So that way you’re managing actively the things that are super important in your instance through ATF. So you can tell in an upgrade in an instant whether or not those core key things are behaving properly. Leverage code governance or cicd. A lot of companies you know, sometimes they’re leveraging Git, is for, for their repositories, for update sets and code frameworks, and making sure that the code is being properly managed and updated in versioned. ServiceNow does a good part of this, but some companies pull that information out and. Put it into things like git or. Or jira. Does anybody, out of anybody listening? Does anybody actually run the upgrade previews in their sandbox environment? If so, just pop up your hand. I’d like to see. So if you’re adopting any of these in your next patch cycle. Hopefully you’ll turn upgrades into just routine maintenance windows and something that you might actually look forward to. Alright, so let’s talk about scripts. So scripts are kind of like the muscle of your instance, you know, on the left are five the most common scripting patterns that we’ve seen that are causing issues in a lot of environments. And I kind of want to walk through them. So a lot of people aren’t putting defensive programming inside of their scripting, so they’re either leveraging devs that are. Necessarily familiar with ServiceNow and. Not necessarily codifying defensively. Using and trying to avoid loops in recursion, either through Chai catch loops or trying to understand and log out if looping is happening so. In addition, querying extremely large datasets, right? Trying to query thousands or millions of records when you’re trying to query like the CMD BCI table. Or consume a ton of memory and slow down everything else inside of your flow. Things like pulling entire objects when all you need to do is necessarily return fields, right? Can be overkill and slow down scripting. And then one things we’ve seen that is huge is generalized variable names. I can’t tell you how many times we’ve seen variables named X or GR that are everywhere in your code, which makes not only for. Badly readable code, but it’s extremely frustrating. Now, if you’ve seen some of those patterns. You know there are scripting best practices that ServiceNow has put forth that really help you isolate and identify and help give those who maybe aren’t as familiar with scripting inside of ServiceNow, the training that they need in order to properly script within the confines of the platform. But one of the biggest things that can help with efficiency is making sure we’re doing things like in our coding encoded queries to do things like set limits. On the amount of things that are coming back or set the amount of Max rows that are being returned, especially in back things like background jobs and business rules. You know, doing this prevents runaway queries and only returns the data specifically that you’re really trying to hone in on. And again inside of this is the links to scripting best practices and it helps you codify around defensive back best practices. Naming conventions and then it also has real world examples that you can copy paste and leverage. So with regard to scripting, making sure you’re using defensive programming, codifying against loopers and recursions, minimizing your large datasets, minimizing the the amount of information, and the object you’re returning, and not leveraging generalized variables can all go forward and help. Not only you managing your code bases, but. Ultimately, helping to identify when things go wrong. Wrong or awry? OK, here’s. Here’s the real big one that we’ve been getting asked about a lot this past year, and that’s testing frameworks. So a lot of companies have testing, right? Like they do testing during changes, but it’s not something that is thought about from an automation perspective. Now, there are some companies that are extremely mature that have started adopting. Automate automated testing framework, but from your medium to small business. They’re not really thinking about it from an automation perspective and I encourage everybody that is in the small to medium and you know kind of in the mid to maturity area to start leveraging automated testing frameworks to look at your internal processes from either an ITIL perspective or. Case management, perspective or even platform to start testing those changes in your lower and sub environments. To not only test the processes themselves. But also sanity check during upgrades. My scroll wheel’s going crazy today. So a lot of time we see, you know, things like manual testing or decentralizing your test cases where you’ve got test cases in Word docs or Excel spreadsheets. And then if you have testing like that, testing takes so long. When you’re doing things like upgrades or changes that. It delays. And can even stagnate those change windows or upgrade. Windows. So what if you could automate a lot of those critical tests, right? So that’s where ATF comes in. So by enabling ATF in your ServiceNow instance and getting familiar with automated testing framework and cloning the out of box tests that exist and using them to augment your processes. Helps making those testing phases a lot more iterative and although it takes a lot more effort up front can considerably reduce the amount of time you’re doing testing changes or testing processes or testing net new features or functionality. You know, maybe if you start this, you can go through some automated test training and I guarantee you at that outset of that training within 30 minutes or maybe even an hour, you should be able to confidently go through and create maybe just some few tests, maybe test. An incident create or. A change. Standard change creation. Try to do something with testing in an automated fashion. It. ServiceNow has extremely good documentation. On automated test frameworks and even their on demand, training has become free in just this past year. So if you haven’t now learning account, there is extremely good testing framework training. I think there’s six or seven, maybe 11:50 hours of training that you could do on automated test frameworks, and if you have the time, get spun up on it and try to start setting automated tests inside of your environment. And once you’ve got smoke tests, dive deeper into the ATF techniques sub flows, test setups, and leverage things like parallel execution. So what I want you to take after this is if you don’t have ATF enabled, go and enable it. Take a look at what’s coming in out-of-the-box and start to understand what automated testing frameworks can do for you. And if you can even start doing some of the simple things today to just check processes, you can leverage those when you do things like upgrades in the future. OK. So one of the one of the next things that we kind of see is complexity in process design and overly complex processes. So when a process branches into like 10 different branches, multiple loops, whole bunch of approval processes, multiple systems. You lose speed, you lose control, and you lose visibility into understanding which area can support which area of the process and who ultimately can manage. The core of those processes. So on the left are symptoms, right? Again are solutions. So. Take a look at your processes and check and see how many steps they have. Do they have 15 to 20 different steps required? Five to 10 different clicks and have to go through multiple different pages if they have multiple different multiple decision points. If every form has yes, no and maybe checks at every single point. Have you seen bottlenecks in those forms? Are there a lot of handoffs? Context switching. Do they have to go to different areas? Different systems. It invites. Miscommunication invites drop tasks. Are their dependencies across apartment? If your workflow touches 5 teams and three separate tools coordinating, all that becomes almost like a full time job. So how do you kind of go from tangled spaghetti of process to streamline flow? I hate to say it, but one of the huge things is process documentation. A lot of companies do this extremely well. Some companies don’t do this well at all. They don’t capture the as is process in extreme detail and treat it like a runbook. You know list each step the owner, the input, the output. Starting out, even with A1 page, Word document can help at least give you clarity into that process. Look at process mapping. Do mind maps process use lucid charts? PowerPoint SmartArt look at Decision Forks and handoffs. If you can take a look at it that at a macro perspective you can find redundancies. You can find process steps that can be maybe taken out. If you’re looking at a process that’s already exists, set up Kpi’s to audit that process. How long is the cycle time? How many handoffs are there? What? What does that process look like from a time perspective? Dev. Data will tell you where the slowest points in your process are. Look at that from an assessment perspective. Look at it as a simple scoring model. You know you assign weights to the steps. Look at your decisions and handoffs. Set a threshold. Anything that’s above that may be a candidate for streamlining, and then look for automate. Look at look at automation opportunities is a possible solution if you have. Really, really complex things. Are they all manual? What can we automate? How can those automation opportunities be be there? So for anybody who’s here do do this thought exercise. Think about a process in your organization that have a has a lot of steps, or maybe a process that hasn’t yet been documented. If you can take steps one to three in the solution area. And try to at least go through and do some of those exercises this week. Can you think about any step in that process that can theoretically be removed or automated to make that process more efficient? If so, how could you implement that in a ServiceNow? This month. So document one process, map it, try to measure it this week, this month. Small simplifications to those processes. Dropping a decision here. Approval there. If you can manage it, may shave hours off of cycle time or people process time. OK. So one of the things that I pride ourselves on at concurrency is we do something in house that’s essentially like a license audit. And we’ve done that for a lot of companies over the past year. And we have found that a lot of companies are either over LIC. Where they have they’re paying for too many licenses or they have bought licensing. They didn’t even know that they had or have investments in tool sets. That they can leverage, but they don’t know that they can leverage. So treat your licenses as investments, like if they’re sitting there, you’re literally just burning cash. So what I wanna talk through is how looking at your licensing. Can cause issues in your environment and what we can do to look at our licensure and gain some insights. So let’s say you paid for CSM HRSD virtual agent Iton, but you’re not using all of them. Maybe you’re just using CSM or ITSM? All of that spend delivers you absolutely 0. As far as ROI is concerned, you know, even when you’re partially adopted in some areas, but you’re not fully adopted into others. All of that usage and non usage. Is in effect wasted? Let’s talk about inefficient operations. You know, if teams are not leveraging your tool, you’re wasting money because the license capabilities you’re paying for aren’t in play at the moment. Maybe you’re missing opportunities to to integrate with your external users like things like virtual agent or guided tours that can help educate your end user base aren’t being leveraged because you don’t know that you have them. Maybe because you’re not leveraging specific automation that you have license to you or available to you. You’re missing automation opportunities. And maybe you’re trying to hire or get more people because you’re so inundated. Or you’re paying consultants to do you know, staff augmentation to fill in the gaps where you could spend that money trying to do automation. So how do we flip the script and get full value from the licensing that we own? So take a look at your departments. Map out. Map out two to three processes that you’re licensed for in that department. And see if you can automate or streamline them. Take a look at. License your subscription overview. Understand what your license for. Look at your entitlements inside of each subscription. Audit that quarterly to understand what are we using. What are we not using? Why aren’t we using it? Talk to the departments that have specific entitlements in those areas. Understand what you’re licensed for. For everybody here, when was the last time that you looked at your subscription overview? When was the last time it was audited? Does anybody here know how many licenses for anyone, anyone module that you were licensed for SAT idle last quarter? If you don’t go take a look at subscription overview. Find out what your license for what you license for. Run a license utilization report this week. Try to find out what if inside of your module, you’re entitled for what features of that module? Can you go talk to a process owner or module owner or functional area about to make sure that you’re gonna look into adopting some of those features in the near term. Or, if you really want. Come and talk to us and have us do a license overview with you. That way we can help you explore how to make some of those feature sets a reality. All right. Let’s talk about meeting customers where they are, and I’m gonna speed up a little bit in the interest of time. But a lot of things that we’ve seen is where you are forcing or have stagnation in the fact that you have people leveraging e-mail or phone. They’re not using the employee portal there. Low user adoption. They don’t wanna change. They are saying that the front end is a poor user experience. You know, maybe you’re not tracking. Employee usage. On the portal and where they are using it, where they’re using it, where you auditing, where customers are frustrated, you have missed feedback opportunities from either not doing surveys or customer survey or CSAT engagements. You know, maybe you have the opportunity to integrate with your customers from a chat. Or teams perspective. Integrating there, meeting the customer where they spend most of their time. If they’re spending most of their time in chatbased interactions, try to figure out how you can meet them in teams. Put the employee center in teams or slack. Leverage virtual agent or agent chat if you have it. Make sure your employees center from a UX UI perspective is functioning how users interact with it. I can’t tell you how many times I’ve gone to a customer and they’ve developed an employee Center for how it people would use it. They’ve never done focus or functional group testing with end users. Departmental end users. Highly vocal end users to make sure that the way that they would expect to use the employee center was set up for them. Not for how it would want it set up. Doing those things and meeting your customers where they are being able to adopt features and functionalities. That customers are looking for can help Dr. adoption. Help Dr. efficiency. Being able to give them information at the drop of a hat versus having to have them hunt and Peck for it. All of those things can help. Dr. Efficiency and Dr. adoption. So does anybody know if they’re actually licensed for virtual agent or teams or slack today? If you are, have you deployed it? If not, why? See if see if in your development environment if you are licensed for it, get it spun up. See what it does? Play around with it. See if it meets a need internally in your organization. Go talk with your end users. Find out if they can be leveraged. And then if it can start making a process map or start trying to put in a future project that can maybe leverage it. Another thing we’ve seen is limited or inaccurate use of cstm or CMDB. A lot of times we go into companies that have stagnated data limited visibility into that data. You know, maybe they’re only doing CIS, maybe they’re not tying those CIS to things like business services, application services, technical services. And not having insight into those. May offer your analysts less of an opportunity to understand the business. Because all they’re doing is firefighting from ACI perspective and not from a service perspective. To understand maybe the criticality. There maybe reduced automation opportunities because they don’t necessarily understand how services can be managed upstream and how they all interact. And maybe there’s opportunity. To understand how those CIS work in concert to maybe uplift a particular service. Or maybe we can automate an aspect of that service to drive efficiency. And reduce downtime. It drives inefficiencies in ITSM because if you have the wrong CMDB objects or they’re not accurate, your ITSM folks may go to the wrong computer. Or maybe the computers to the wrong end user and they don’t understand. Or there’s difficulty in compliance management. Maybe there’s a compliance or regulatory requirement to have your csdm and you need that audit capability and be able to understand like hey, this is. Our this service how do we audit that service? Oh, you can go here. Here’s all of our CR for that service. How nice would that be to give to an auditor versus having to go and hunt and Peck in five different systems to understand which CIS represent a particular business service in your org? One of the things that we’ve seen is a lot of ad hoc imports from Excel spreadsheets and things that are. More manual in nature where if you have the opportunity from a solution perspective, what we try to do is start integrating into third party tools like SCCM. Understanding. The deployment if you have it of discovery internal D org. If you have it, if you’re licensed for it, taking a look at service mapping to understand how service mapping can automatically. Tie back to things like your cstm and business services and technical services. Take a look at developing a service architecture. And taxonomy structure, at least at the base level, so that you start understanding what services does it provide the business. What departmental business services does do those departments provide the business? How do we map those back to objects in our organization and how do those objects tie back to CIS that may be in our CMDB? And how can we accurately represent those to our analysts so they can then understand upstream and downstream effects of maybe a server or stack going down? With all of that said, how do we know when to start over? Versus when to fix? It’s always a good question. So let’s start with when to fix. Rather than tearing down your instance, there’s kind of five key considerations that’ll tell you to patch, not rebuild. Right. One is minor issues, right? You’re seeing a handful of isolated glitches, slow forms, broken script, minor UI things. You know, I would say net issue fix it. Validate that you truly understand the problem. Try to understand what’s really broken and then determine whether or not you can fix it in short order, right? Another is limited budget. Maybe you don’t have the budget to re architect or rescue an app or redo something from a process perspective. You know, decide whether using an internal resource from a time perspective or bringing a consultancy for focus fixes. Spread your budget where it delivers the highest impact. For the highest criticality things. Maybe it’s a time constraint thing. Maybe you have a business deadline that can’t, can’t slip, or a upgrade window that you have to get after. You know, align quick fixes with your release calendar and change approval processes so you don’t burn or compromise any long term Rd. maps. So in those instances, try to fix it. Looking at your existing data, you’ve got a whole bunch of transactional data, manual workflows and integrations. You can’t necessarily disrupt. So this is where maybe in house versus outsourcing comes in? You know, if your team knows the insurance and outs, you know, leverage that knowledge. Try to do surgical remediation at that point. Otherwise, maybe time to consider outside help to avoid side effects in whatever critical processes you’re maintaining. Leverage your employee expertise. If your team has deep familiarity with the current instance and its quirks. Custom scripts, things, key tables. Make sure that you have tests there to verify any fixes that are in place. You know, doing a fast in house fix is great, but if you can’t validate it before it hits production. You may end be introducing. Or issues than not. You know when you have when all these considerations line up, you know, a targeted fix develops or delivers the fastest ROI, the least amount of risk. Now let’s kind of flip the script. And determine when you should consider a full rebuild of a process or module or architecture. So let’s say a surgical fix isn’t enough and your instance needs a completely fresh foundation. So here’s kind of the red flags where a full rebuild, or at least a re architect, pays off more than patching, right? So sometimes we see fundamental flaws with an implementation, right? So if your core data model processes integrations are built on either incorrect architecture or assumptions, or maybe your cstm was architected completely incorrectly. Or a workflow design or application was built that breaks all the time? You may need to look at a complete re architect or complete. Do over what I would recommend is starting off with an assessment to validate the current state of any flaw before you actually rebuild. Let’s say you have an unsatisfactory user experience. This is primarily around portal design. End user experience. If users consistently are driven away from your employee center, it’s maybe a sign that your UX UI may not be salvageable. Maybe it’s time to re architect the entire employee experience, the taxonomy where they go, how things are tagged, how things. Are. Keyworded. It may need to be re architected to that point. What about complexity in technical debt? What happens if you had? Merger and acquisition a whole bunch of people got. Swapped in and out. You have a whole bunch of spaghetti code business rules. A lot of technical debt. No documentation on processes. Maybe at that point it’s time to re architect to specific processes areas of your business in order to realign departmental considerations. Maybe there’s a shift in business requirements. Maybe it’s a new alignment or new path to digital transformation. Tie that rebuild plan to a long term change management strategy that also ties. In maybe the feasibility in starting over for a particular process or module type. So if any of these scenarios for rescoping isn’t just about surgical fix, but you may see some patterns that may necessitate a re architecture. Maybe it might be time to look at starting over in those particular situations. OK. So how can we help? Again, we conc. Concurrency operate in about eight different modules inside of ServiceNow, but we also offer a bunch of different things. So one could be a health and performance assessment. You know, we could take a look at your architecture infrastructure, your instance logic. We can look at your the health of those instances. If you have processes that you’re thinking that are broken or employee experiences that are less than lackluster, we can help you look at those and help you understand what can be done in the short, medium, and long term. If you have licensing that you. May be confused on or don’t necessarily understand what you’re entitled to. Versus features that you can leverage short, medium and long term, we can help you with that. Looking at next steps, we can help you with doing Rd. maps in direction, helping you with remediation plans. Looking at operational plans, maybe you’re looking to new features and you want to deploy some of those. How do we go about that? We can help you with that. Looking at fixing or implementing net new features, fixing an existing deployment, deploying new capabilities. Maybe you need to remediate a process back to something stable or optimize your operations. Maybe you’re doing simplification. Or doing automations we can help you with that. Maybe you’re trying to develop a new capability. Maybe a net new build or create a net new application? Trying to create something that may align to enhance value for your end users. We can help. We operate in the ITSM CSM, ITOM SEC OPS, hoursd. Arenas, along with CMDB and automation. If any of those areas resonate with you and you need assistance, come talk to us. Now, Amy and Amy put in the chat. A survey, if you fill out that survey, two things can happen. One this this, that, that this deck has links to all the information we talked about. If you’re ready to get started on anything that we talked from a health perspective evaluation perspective, fix or implement perspective for developing a new capability, fill out that survey. Get in touch and if you’re ready to get started, we’re ready to talk to you. I thank you for joining us. Have a good rest of your day. Thank you.