Customizations: Copy/Paste vs OOB

[tekkytommy]

Hi All,

We have a resource that has zero business analysis skills. So, what is happening... A template is filled out by the Requester (who has no training on ServiceNow). All the info from the template is copy/pasted into a RITM, then ServiceNow developers/architect customize the code according to exactly what is on the template. This has been going on for years. 

The issue is all these customizations are made, without any analysis of how the Out of the box works. Therefore, all these customizations will break if/when the Customer buys the OOB product.  For example, via the Service Catalog, they are adding Asset Management that totally conflicts with OOB processes. So, when or if the Customer buys let's say Hardware Asset Management all of the code will break, go down the drain, and cost the Customer to reverse engineer the system.

I would like opinions from other SMEs. When a Customer comes to you with these customizations, do you conduct a business analysis and design the system keeping the Out of box architecture in mind? Or do you just say "Who cares how ServiceNow works? I am just going to put whatever status field/variables on the screen, and customize the heck out of this? The Customer gets what they asked for right or wrong." 

[Mark Manders]

ServiceNow works like ServiceNow works and if a customer buys ServiceNow, they should be aware that it will work differently than their previous system.

A lot can be customized, but with every customization you should ask yourself if the requirement is important enough, related to the effort and consequence. Customization isn't bad, but should have some governance.

I don't know exactly what it is you are saying here, because you mention that for years the ServiceNow developer/Architect have been working in a certain way, but the customer hasn't bought it? 
By the way: you should remove the 'Architect' title from this user if he really is just doing what they say.

With everything: if you have a custom process and you are going to replace it with an OOB process (like you mentioning HAM), you will always have to get rid of what was and start working like it was meant to, including getting rid of all the weird forms/code. This is exactly the same as when you move from a different tool to ServiceNow. The only difference is that the 'other tool' now is your customized part of ServiceNow.

So yes: reverse back to OOB and only customize what is absolutely needed. The fact that the customization was added instead of buying OOB modules, was probably cost-motivated. And now they are paying the prize. Remember: it's always the customer as a whole that allowed this to happen. Maybe one or two people did it or started with it, but in the end it's the customer's responsibility that it got this far. They started breaking the platform the moment they started 'just doing what is asked' instead of thinking first and providing the best solution.

[Dr Atul G- LNG]

Hi @tekkytommy 

This is what happened: at the start, governance wasn’t considered an important pillar, so everyone built the platform based on their own preferences. Now, after a lot of customization, you’re stuck due to a lack of governance processes. As a BPC, I always recommend starting to think about governance from day one.

Earlier, there was a lack of standard practices, but now if anyone comes to me as a BA or BPC, my first question is whether this customization can be done via configuration. I study the user’s business case, then we decide what’s right and how to proceed. Being a BPC means focusing first on value, then on how to achieve it.

If you want to revert changes, it’s better to take a new instance and start using it as out-of-the-box (OOTB). If you try to revert existing customizations, you may break a lot.