The customization conundrum of ServiceNow

[Alfred Brorsson]

One eternal ServiceNow discussion is that of configuration vs customization, often expressed in other words such as “out of the box” and “minimizing technical debt”. These phrases may not be synonymous, but they are all branches of the same tree.

Basically said, ServiceNow is a platform delivered with fully functional components of data models and processes, iteratively being upgraded and complemented. This meaning that you should be careful about what you customize to ensure that you can benefit from new functionality, and simply to make sure that your platform works as it should.

We encounter this topic from the moment we start learning about ServiceNow, whether it be from ServiceNow’s training programs or discussed as part of our company’s development practices. And with great reason. Over-customization can ruin a whole application, giving crappy functionality or performance, or both. Often leading to huge amounts of work trying to undo those same customizations.

To explain further, one thing that is sometimes overlooked with the products developed by ServiceNow is that they are created as they are for a reason, usually because the delivered process is adhering to best practice solutions in industry standards such as ITIL. If you must change it drastically to work for your organization, it might be your own processes that are bad, not the platform. Instead of changing the platform and keeping a bad process, you could use the platform as is and adopt a greater way of working at the same time. Simply put, you get a win-win instead of a lose-lose.

But, it’s not that simple. If you lean too heavy on the “out of the box” way of thinking as described above, you might miss great opportunities to create value for your users. You shouldn’t simply ignore use cases on the basis that they require customization, instead they should all be evaluated based on some sort of matrix aligned to your goals with the platform and your technical governance practices. Here is an over-simplified calculation of how said matrix could work:

Low value provided + High customization required = Don’t do it.

High value provided + Low customization required = Do it.

Another good thing to remember in these discussions is your main purpose for buying ServiceNow in the first place, and why you are employed/contracted to support it. Is it to create an easier job for those managing the platform, or is it to serve your end users and help them in their work? These aren’t necessarily contradictory, but you will in some cases find yourself having to compromise in one end to enable the other.

Always stay up to date with what ServiceNow delivers out of the box, and what might arrive in upcoming upgrades. Adopt the platform where it’s possible. But if you find that you need to customize or build your own solutions to enable your users, do it!

As long as you are aware of the possible risks and consequences, and work proactively to mitigate those, then customizations might just be what makes your ServiceNow platform great.