5 steps how to prevent a ServiceNow® restart
05.07.2021
If you are running a poorly configured ServiceNow® environment, you are sitting on a perfidious time bomb, not noticing for a long time how the fuse is glowing underneath you. And if you don't know the exact state, it's probably been glowing for a while. Prevent the detonation - there are remedies and extinguishing waters, which we discuss in this article.
If you are running a poorly configured ServiceNow® environment, you are sitting on a perfidious time bomb, not noticing for a long time how the fuse is glowing underneath you. And if you don't know the exact state, it's probably been glowing for a while. Prevent the detonation - there are remedies and extinguishing waters, which we discuss in this article.
I have been working exclusively with ServiceNow® for many years and have seen just about everything and experienced the rocket-like development of ServiceNow® live, both technically as a partner and from a customer perspective. Finally, I read more often about ServiceNow® "reboots" and ask myself: does it have to be?
Disclaimer: No two environments customers or projects are the same. It is important to evaluate the particular project, environment, and state individually to determine if a restart makes sense or not. It must be consciously decided for each individual case. There is no generally valid rule...
Risks of a new start
As a cloud platform, ServiceNow® is subject to constant growth and change. With each of the now twice-yearly releases, the platform grows, offers more functionality and promises more and faster benefits. Continuing to make adjustments feels more complicated and tedious. The more customized the customizations (which naturally increase in volume over time) the more likely they are to lead to potentially critical side effects, their technical debt growing. Companies react with endlessly long test cycles during release changes. This leads to increasing costs and in combination with the pressure to always use a current (not discontinued) release for security reasons, one finally gets into a deadlock in which a restart seems to be a feasible (and supposedly cost-effective) solution.
However, this involves risks that can be divided into the following groups:
- Transition risks
- Loss of individual benefits
- Side effects
- Operational aspects
Transition risks refer to uncertainties that arise as a result of the transition. How will your employees work during this phase? What happens to active, possibly long-running workflows? How do you get users used to changes? Does temporary productivity drop during this phase? Are there existing backlogs that need to be worked through before a cut-over?
Assessing the loss of individual benefits as a risk is not easy, because it requires you to know exactly what the current "delta" is to an OOTB ServiceNow® environment. Often, unfortunately, this is not given and requires very good preparation and analysis in the preliminary phase. What is not conscious (read: documented, known, considered) cannot be taken along. And this does not only apply to your ServiceNow® environment itself, but also to the connected peripheral systems.
This brings us to the side effects. These are often hidden right here, at the interfaces to peripheral systems. Often, these interfaces rely on certain data formats or content in the exchange, which may have changed after a restart. Timing communication profiles on the technical (time-outs, etc.) and business (when does an exchange occur, what triggers, etc.) side must also be considered.
Operational aspects are often a pain-point that one tries to mitigate with a reboot. It is very worthwhile to examine today's challenges in operational issues in detail and to draw conclusions about what should not happen in a restart. And it does not hurt to be prepared for the future.
Preventing a restart in 5 steps
If you do not want to take the risks, you can take measures to improve the situation. In order to consistently counteract the need for a restart, a procedure model with the following five steps has proven itself:
- Identification of pain-points
- Description of the ideal state
- Neutral review
- Definition and prioritization of measures
- Iterative implementation
Then design an ideal state - what would it be like if what is hindering you is eliminated? What specifically do they use to measure success? It helps to put yourself in the position of individuals or organizational units involved to show these concrete benefits. This can be used to get internal buy-in for measures.
Commission a neutral review of the environments. No measure, no matter how well-intentioned, will ever be successful without an accurate understanding of the current state. The survey should be done by a neutral party. Typically, companies work with ServiceNow® and their partners, but also have internal staff who take a long-term view of the environment. Choose someone else and define the scope based on your pain-points and ideal picture, don't forget to include surrounding systems if necessary and ask for both a data and a process oriented analysis.
The result of the review helps you to define, select and prioritize measures. These form a backlog for implementation. It is important to note that an existing backlog and/or projects must be re-evaluated and scheduled in light of the "repair measures". Does the working method change (keyword: consistent scoping), do interfaces or processes change?
Then it is a matter of consistently implementing the prioritized measures. An important technical aspect is the consideration of partner "toolboxes", which are often very specific, poorly understood by companies and not maintained after partners leave. Here, it is urgently recommended to use only modules available in the ServiceNow® Store, because this ensures compatibility for new releases even after the partner has left or changed. In general, it has proven effective to involve experts during implementation, who not only learn and implement improved techniques together with the on-site team, but also practice simplified operational procedures together. This is an iterative process that then transitions into the new normal of using and maintaining your environment.
Takeaways
Rebooting ServiceNow® is not necessarily the last option left when you see a grown ServiceNow® instance starting to show signs of age. There are proven and effective procedures and practices to get back closer to an ideal state with just normal work.
The risk of an iterative removal is in any case lower and more controllable than that of a restart. But not only the risk, but also the costs as well as the potential benefits have to be considered. Whether it makes sense to avoid a restart can only be decided on a case-by-case basis.
Ultimately, however, companies should never - consciously or unconsciously - relinquish control of their ServiceNow® environment. This requires ownership (responsibility and decision-making authority in one's own hands) and clear governance.