How do you balance customizing ERP vs. the risk and expense?

We hear advice not to customize ERP because it breaks upgrades, causes implementation risk and cost, and so on. On the other hand, most businesses want some customization to match their particular needs. How do you balance and where do you draw the line?

It's a slight tug-of-war between software vendors and customers when it comes to customizations. Vendors prefer to support only what they've produced but their products can't possibly be all things to all people. The customer on the other hand does not want to be made to squeeze and conform their business processes into the software vendor's "box".

As a general rule, customers seeking a solution should first gain a clear idea of what they need to do and how they need to do it. This is the essential foundation to evaluating software products. Once the requirements are formalized, categorized, and documented, they can send solid RFIs/RFPs to their top vendors. Finally, after an optional proof-of-concept, a fit/gap analysis can be performed.

The fit/gap analysis is crucial to accurately identifying where application customizations will actually be needed. This is also an opportunity to decide if the gaps are better filled by operational process changes or if a configuration work-around will get the job done. When a minor operational change or configuration change can suffice, this will usually be the better choice. When customizations are required, a cost-benefit analysis should be performed to ensure that the money spent on development and integration will actually produce corresponding savings or revenue. Often, customizations are ordered that are very expensive and result in negligible benefit.

A bit more on customizations:
Once this ground work is laid, good customization planning can take place. Generally speaking, customizations that interact with the core application through a service or API are most desirable. These types of customizations are often referred to as bolt-ons. Since these peripheral customizations don’t interfere with the internal workings of the application vendors are less wary of them. However, if they are fairly complex, there may be additional support required for them. At the other end of the spectrum, are what can be called “integral” customizations. These types of changes alter the core application functionality directly. If these types of customizations are required, it’s usually best to have the vendor or a professional services partner perform the change(s). These are the changes that are most likely to drive up risk and cost and can be a support headache down the road.

As luck would have it, “integral” customizations are the ones that customers generally prefer because they tend to be seamless with the rest of the application. Bolt-ons can often be cumbersome and awkward.

Modern enterprise applications solve this problem by employing Service Oriented Architecture (SOA) and tend to be more like frameworks than traditional applications. As a result, they’re highly configurable and accept bolt-on customizations that behave more like integral ones. These applications however are very complicated to configure and typically require specialized product knowledge and professional services for deployment.

Finally, when integral customizations are designed and requested, the vendor will often roll useful ones into the next release of their software. While this makes your customization fully supported, it also potentially gives your improvements (and sometimes even operational trade secrets) to your competitors if they happen to use the same product(s). This is often the biggest risk in integrated/integral customizations and often goes unnoticed.

Before you customize, did you both re-examine your business, it process flow and that of the ERP Porgram?

Next did you examine the differences found. Which is absolutely needed (yours or the ERP solution)?

That's your answer.

Okay...I'll bite...a very large percentage of ERP projects involve customization. For arguments sake lets establish that it is unavoidable. The second any customization is developed that version of the system is yours: Version 1.Yours. That being the case, select an ERP that has the least proprietary code, find a Subject Matter Expert in each area of your company the application impacts and promote them to the Functional Lead in perpetuity, find the most effective technical/software development team and instead of investing in the maintenance contracts with the software vendor, put that money toward the Functional and Technical team.

You can't avoid customization. You can, however, avoid paying a maintenance contract for a system you cannot upgrade. Pretending to have an upgrade path with a system that has been customized is fiscally irresponsible. So you don't get invited to the User Conference...big deal.

So to answer your question Michael, draw the line in favor of your own business. Thank the ERP company for the "base" software and take the on-going support costs you were going to pay to the software company and establish your own. Maybe combine your expense with those of another, non-competitive company that requires similar functionality and is using the same application base.

This is in the context of SAP and by customizing I am making the assumption you mean custom coding. Because in SAP you "customize" the system by making settings related to how your business operates but do NOT code. However coding for your company's nuances is possible.

What are SAP Best Business Practices Anyway?
http://www.r3now.com/what-are-sap-best-business-practices-anyway

I've written quite a bit on this topic in the past. I devised a "test" that any company can apply for doing custom coding of their ERP system (SAP and NON-SAP ERP solutions).

Do You Know When To Do SAP Custom Development?
http://www.r3now.com/when-to-do-sap-custom-development

In a nutshell (from the post):

Use SAP Best Business Practices For Commodity Processes But More Carefully Evaluate Competitive Processes

The best counsel for any company would be to look at any particular customization in the light of its strategic value to the company. Some functions, like Fixed Assets Accounting, will never be strategic. This is a tactical function that should utilize standard software with no modifications. Honestly, if your firm is trying to do something 'creative' with depreciation schedules, run from that place as 'creative' and 'accounting' should never be in the same sentence (unless it's a jail sentence).

Many applications that are close to your firm's customers (e.g., order entry, online catalogs, billing, etc.) may be good targets for both tailoring and modification of the software. Why? The way your firm interacts in the market may be your single greatest source of competitive differentiation. If modification budget exists, do it to these strategic applications (instead of the general ledger).

Some applications are sort of strategic and sort of tactical. Procurement is one that many companies see this way. For these applications, do everything in your power to use the vendor's tailoring and configuration capabilities and avoid code level modifications, if possible. Alternatively, write some 'surround-sound' code that envelops the vendor's code without modifying the package. This could help protect the integrity of the application and software support.

Ultimately, these decisions are often a mix of company politics, change management resistance, power and technical needs. If users insist that specific processes must be used, your choices are often to: educate the users, go over their heads, train them on the new product's innate capabilities, delay the project until they come around or do the mods in the least invasive manner possible.

One other point absent in these threads is that multi-tenant cloud SaaS apps, while permitting tremendous tailoring (generally), do not usually permit code modifications. These are precluded as this would prevent the vendor from automatically upgrading (and keeping current) all customers with each new release/upgrade. Businesses going with multi-tenant solutions must decide at license time whether they can live with the software as is, or eschew going with this product altogether. More and more are voting to go with the multi-tenant apps as the no-cost upgrades often trump user demands for 'customization'.

Finally, if I got a nickel for every user that told me "We're different!", I'd be retired. The reality usually is that the differences are really rare (particularly in tactical apps) and almost always in a strategic application area.

Greetings Brian - excellent question! Here is how I draw the line - does the software change has a material impact on the cost of the business process (10% or more) or the software change will sustain a competitive advantage. Only revenue-generating business processes create real competitive advantage. A customer does not need to be world-class in revenue supporting or regulatory business processes - only Competent and efficient. Many customers do not like to hear this - especially those customers that are functionally siloed. See the following blog article for further examples:

http://gbeaubouef.wordpress.com/2010/12/07/embrace-change-erp/

Michael,

What is missing is a low cost platform for integration so the cost of the "customization" does not afect the "code-forward" cycles. If customization causes risk of downstream system viability, it must be reconsidered. Seeing industry-wide falures from protracted code-cycles without customer ROI spoeaks to the risk for both customer and developer. If the package you deliver does not have this at a minimum, pass on it and get one that does.

http://www.scc-co.com/blog/bid/30797/ERP-Software-Integration

Gerry

The assumption that customizing an ERP system can cause items to break during upgrades is not necessarily the case. The more modern, sophisticated SaaS platforms, such as Salesforce.com and NetSuite, allow for customizations to automatically transfer along with product upgrades throughout the year.

Having said that, I don't believe in customizing more than necessary as it does cost time and money but if you are using the right ERP platform, customizations do not pose the "version-lock" risk that they used to.

Rob

The real question here is: How well can your ERP Solution handle modifications that do not impact other code or your ability to upgrade to future versions without impacting these modifications?

The truth is, some systems can do this very nicely because they are designed from the ground up as SOA (Service Oriented Architecture) applications. What this basically means fundamentally, is that each segment of code is designed to stand on it's own with s imple function rather than being more monolithic with more complex functions. The result is that you have access to these pieces of code and can create new procedures by using these segments of code together in new arrangements.

In a good ERP system, you can create these new procedures WITHOUT IMPACTING EXISTING CODE. Sorry for shouting, but that point needs to be very clear. The new procedures stand on their own and are NOT impacting existing code at all. I know of one system, Priority 14 WPF that calls this Superset programming. It has two layers, one for existing code, another for all modifications; very nice and very clean and all upgrades work just fine without breaking mods. Not all ERP systems are created equal in this respect and it is important to know this before moving forward with any true customizations on your ERP solution.