Go to portal
There’s been a lot of talk in recent times about returning ServiceNow to out of the box functionality. ServiceNow themselves have been encouraging it and many managers and architects have been focusing on it as a goal. But what is it and why is it desirable?
What is Out of the Box?
So let’s define what out of the box means. Literally it could mean returning ServiceNow to vanilla/factory settings. However, most organizations are going to be changing things to some extent. Even if it’s as simple as defining new permissions in an ACL. Such a change can be done within the base functionality of ServiceNow. It’s here that it’s useful to define two different terms.
Configuration – changes that are made using default platform functionality (i.e. clicks not code).
Customization – changes that are made using code and modify core functionality.
When many organizations talk of returning to out of the box they can often mean that they want to clear out customizations and return to a configuration first approach. But before doing that, they need to clear out redundant and bloated systems. Then they can start building again, with new design principles. Many organizations wish to do this on their existing instances rather than facing the very daunting situation of starting from scratch, though this is not unheard of.
Why Revert ServiceNow to Out of the Box?
So why do platform owners and architects want to restructure their ServiceNow instances? Some of the most frequently heard reasons are that overly customized platforms become more and more complex to maintain, difficult to scale, and can cause massive performance issues. You can accumulate massive amounts of technical debt which can become very difficult to overcome. Some of the technical debt is in service of solving problems that base functionality could solve on its own. Worst of all, having too much technical debt may wrest control of your development timetable away from you. This can lead to development slowing down to fix numerous issues and user functionality deadlines being missed.
Another important issue comes into play with upgrades. When you customize core ServiceNow functionality and modify out of the box elements with code, they are more liable to break on upgrade. ServiceNow will not account for the modifications you have made and if it is adding on new features to something you have reworked, then it can cause a massive headache for your development team. And with ServiceNow only supporting the current and most recent release, this is something that is more important to consider than ever.
Reverting to out of the box is a bold decision by many ServiceNow teams to cut the Gordian knot. Instead of attempting to work ever harder to maintain their platform as they go along, it is a statement of intent. It is a proactive approach to platform management, reengineering your platform rather than reactively fixing fraying edges.
How to Revert to Out of the Box
So if we’ve established the desirability, then how exactly can you go about returning to out of the box? Well, first you need to establish what you actually have in your instance. You may have documentation on this, but more than likely this might require a substantial undertaking if done manually. Automated solutions can save considerable time here and allow you to reduce the amount of time this takes by up to 88%.
From a business point of view, this is also a good time to question certain processes. Creating a diagram mapping out the way data flows and who needs to access it and when. You may discover inefficiencies that would simplify platform architecture. Align processes to ServiceNow functionality wherever possible, instead of trying to impose an exact replica process on ServiceNow.
Once you have established your priorities, remediation is the next step. You could embark on a project with the main objective being to revert to out of the box. This would require defining the scope of what you were going to work on and you would need to monitor the project closely as it went along. Another method, which we’ve encountered frequently, is to make it a side goal of another project. Upgrades being an obvious example. This way you can organically incorporate the reversion into your pre-existing trajectory.
Another useful approach might be to consider using more scoped apps, especially for areas that might require a lot of customization. Developing in the global scope can have unforeseen implications and is a lot trickier to unpick. Scoped apps, by design, remain separate from other applications making them easier to maintain and fix. This can limit platform risk while still delivering necessary functionality.
How to Keep Your ServiceNow Out of the Box
When you have managed to revert your ServiceNow, the real challenge is to keep your platform lean and avoid over customization. As with the last step, frequent inventory checks need to take place to ensure this objective remains on track. When issues are spotted, the earlier they are solved the better. An issue spotted at the implementation stage can be 15x cheaper to fix than it would be in production. Ensuring that you have some kind of automated quality gating process involved is crucial to ensure nothing slips through the cracks.
Establishing a change management process is also crucial. Ensure there is always a question over whether to customize or not. Though sometimes necessary, it always merits evaluation. When customizations are undertaken, remember to document them as thoroughly as possible. One further way to keep ServiceNow Out of the Box is by ensuring your team all have a grounded knowledge of the platform and its best practices. Training and tools can empower them to make smarter decisions and work more autonomously.
