Is it okay to customize you ERP?

Introduction

There has been a debate over the last several years about the extent that a company should customize their Enterprise Resource Planning (ERP) system. This debate has laid out the pros and cons of the customization argument and the conventional wisdom emerging has been to keep customizations to a minimum consistent with focusing on the core business processes that enable the company to be competitive. Customization is also high on the list of reasons why ERP implementations fail. So then should customization be absolutely avoided?

ERP philosophy

ERP systems have been around for a long time and their purpose has always been to track and aid a company’s operations. If we break down the term ERP, it is to enable the Enterprise to effectively Plan the utilization of its Resources. To that end, ERP needs to mimic the organization as closely as possible so that management can gain effective insight into operations (people and processes) and finances, and deploy resources accordingly. 

In order to closely align systems to organizations, software developers have looked to industry best practices to guide the development of ERP functionality. The source for best practices are typically industry associations like the Association for Supply Chain Management (ASCM – formerly APICS), the Supply Chain Council, current good manufacturing practices (cGMP), and industry specific groups that represent a consortium of companies in Aerospace, Automotive, Life Sciences, Electronics, etc.

The challenge here is that best practices are an ideal goal. Most companies do not have the combination of resources needed to achieve this goal. Companies are challenged with the availability of skilled staff in their region at an affordable price within their business model to dedicate to the goal. Additionally, a company’s culture and ‘secret sauce’ (that which makes them uniquely able to win business in their industry) are likely to be different from other companies that fall into their industry group and therefore create a divergence from best practices.

So now we have an ideal (the ERP solutions functional model) trying to be utilized by the unique (the company). As the system is implemented and evolves over time, the company will be faced with decisions on how to address business needs that do not fit nicely into the design of the ERP. These tend to be accomplished through workarounds, process changes, customizations, and any number of other approaches. 

For the purpose of this article, we will only focus on customizations.

What is a customization?

A customization is a feature, extension, or modification that requires program or database changes to the native toolset offered by the vendor. We use toolset here since many vendors offer the ability to modify the functionality of their system without customizing the solution. These can be alerts, workflow, triggers, etc., that can be created to suit a business need, but do not limit the company from updating to newer releases of the software. 

Not all customizations are created equal, and there are different points on the customization continuum that must be addressed differently. Typically, customizations can be placed into two categories non-intrusive and intrusive.

·        Non- Intrusive customizations do not impact the company’s ability to update the vendor’s software to future releases.

o  Changes to field labels, modification to reports and making screen layout changes can normally be addressed within the configuration of the software and do not impact the ability to update the ERP or require source code.

o  Workflow changes and the integration of data with other third-party software, will require some degree of customization, but are typically part of the vendor’s toolset.

·        Intrusive customizations add cost and effort to updating the vendor’s software

o  New functionality that changes or complements the vendor’s software capabilities that requires changes to the source code are considered intrusive.

The pros and cons of customization

A great deal of care needs to be taken when moving along the customization path. It is not only the extent of the customization that needs to be taken into account but also how well the customization process is controlled. We have seen cases where companies have lost control of the individual customizations and also lost control over their implementation budget.

The pros and cons for customization have been rigorously debated over recent years and the arguments can be boiled down to the following:

Moving away from best practices

However, we now come to the real issue. How do you weigh the Pros and Cons to come to a decision about what level of customization works for your company? Why a business process is better, and how much better it is, may not be obvious without an explanation, and that explanation may not be forthcoming from the ERP vendor, given that one of their income streams is professional services that include developing customization requests. The ERP vendor may not feel any obligation to educate a company on best business practices and their associated business benefits.

A final note in this area comes from Panorama Consulting. In a June 2018 study, only 11 percent of organizations implemented an ERP with no customizations; 33 percent of ERP systems incorporated some customization, modifying up to 25 percent of the code, and 37 percent of companies modified 26-50 percent.

The selection process

Suffice it to say, that if your company is looking to maintain or increase its competitive advantage by electing to customize significant areas of the ERP system, then the selection process needs to focus on those ERP vendors that can provide the skills sets to be able to collect requirements, and can efficiently provide tools to develop these requirements into robust solutions. Some things to check when interfacing with software vendors:

• What percentage of their income comes from the sale of their software solutions versus what percentage comes from professional services. If professional services is more than 50%, then can be possible that they maybe a developing solutions for customers, rather than just configuring.
• When asking for references, ensure that the references include other clients that have done significant customizations, even if in a different industry.
• Ask the vendor for a meeting with their custom development team so you can discuss their modification methodology, skills, tools and general rationale in some detail.

The customization process

Any customization should go through a robust process.  A successful customization process depends on two things:

1. The functionality that the company has decided that needs to come via customization.
2. The extent to which the customization process is controlled.

It is this second area we have found insufficient controls, and where the largest hemorrhaging of cash can occur.  We have seen several examples of where companies do not know exactly where they are in the customization process and have no real idea of the expenditure needed before the process is completed.

This customization control process should include the following:

• A request for a customization. This should be a pre-established controlled part of the process.  We have seen too many customization requests coming via an email, a hard copy paper passed to IT, or even a verbal request. Any customization request should include:

A specific and clear requirement. This can be laid out in user terms, but it must be specific to a particular functionality, screen or report and mockup.

A justification. Given that ERP systems are generally based on best practices, there needs to be a solid justification for why the deviation is necessary. Does it enable a process to be done more efficiently? Are keystrokes saved? Does it bring clarity to users of the information? Again, we have seen too frequently that requests are being made with the purpose of resisting change and not being open to new ways of operating, which to a large extent, is why you upgraded your ERP application. 

An assessment of the customization’s long-term business value. This may be difficult for functional changes, but it would give management a return on investment calculation when dealing with budget concerns or could be used for prioritizing the customizations themselves.

• A prioritization process to enable the more important customizations to move forward. The person doing this should be very careful in this process to ensure that customizations in the same functionality area are done, as much as possible, at the same time. This will prevent, to a degree, the very real possibility that some customizations must be modified as a result of further requests in the same functionality area.
• A conversion process. By this we mean a method to convert the “raw” requirements of the user into a specifications document that can be acted on by those responsible for the approval and development. This is a major step in the conversion of the user requirements into the code that will reflect these requirements. To the extent that the user has defined these requirements well and that the conversion into programmable code will achieve the users’ goals.
• A quotation process. This will be done by the software vendor or a third party responsible for the coding changes. A word of caution here; we have rarely seen customization changes that have come in under the quote. Some manage to hit the quote exactly or within a few percentage points, but the overwhelming majority come in at an average of 30-50% above the quotes. Be prepared for the “devil is in the details” comments from the coders requesting more time and thus more expense. To this end, customizations need to be well thought out, discussed with management, users and developers to fully comprehend the changes needed to achieve a complete resolution.
• An approval process. This is another important part of the process and it involves not just the approval of the customization alone, but the approval that the steps of the customization process have been adhered to, along with the disciplines needed to obtain the end product, which is an excellent customization that works well for the user, adheres to the budget, and also the strategic goals of implementing the ERP system.
• A sandbox process – moving the customization to a development data base.  This process should include all settings that need to be changed as a result of the customization, any authorization or security levels that need to be modified, and any other operational issues, such as printer access that may need to be addressed. This should come under revision control and is a good test that the company can move back to the previous version if thought necessary.
• A preliminary testing process. This is done internally within the implementation project group and it is done to ensure that all the modifications have been completed as per specification. This makes certain that the customization test does not fail “off the bat” because of the environment or any aspect of user set up. We have often seen a deterioration in user morale simply because this step was not in place and the users had wasted a lot of time trying to make it work, rather than trying to make it fail which is the very point of testing. Customizations historically fail 70% of the time when first tested, and with this step-in place, the users will experience a much-reduced customization testing fail rate.
• A user acceptance testing process. This is a test done by the user, in the user’s environment, with the user’s data, and without the assistance of the implementation project team. This is the acid test for the customization, and thus sufficient time must be allocated to ensure this is done thoroughly. This is the last place that errors can be found, and the code modified. If this is not done well, there will be major problems when the system goes live, and it is a part of the process that is totally within the control of the user community.
• Cross functionality or string testing. This step is where the company must harness its SMEs’ skill sets to ensure that the customization fits into the strategic development of the product customizations. We have seen, on numerous occasions, customizations that met all user requirements for that functionality, and that tested well, but those changes had unforeseen effects across other areas of functionality within the organization. Especially look out for major changes in the code, for example, to part numbers and Bill of Material changes that will have tentacles throughout the functionality of the ERP system.
• Managerial monitoring.  We have mentioned managerial monitoring in the Approval process, but it should not stop there. Managerial involvement in all the latter steps will go a long way to ensuring that the customization product meets specification.

The company will have to invest a lot of time in the customization process. If this is not done the process will get out of control and cost the company a significant amount of money. Many examples of this cost escalation exist across manufacturing and distribution companies.

How do you measure customizations?

What does it mean when a company says their ERP is 20% customized? A company needs a way to find out how much customization has been done. So, let’s explore the ways that customizations can be measured, bearing in mind that a frontline IT person, dealing with ERP vendor’s programmers may look at customizations a lot differently than a project manager dealing with functional issues, or a senior manager confronted with budget and expenditure concerns.

Let us look at some of the ways that customizations can be measured:

• Dollars spent on customizations compared with the original amount spent on the vanilla ERP package. This will at least give the organization a feel for the number of customizations being done and will probably be the first red flag that senior management see relating to the management of customizations. Even if all the customization costs are entered under the same project account it will still be relatively easy to analysis the specific customization costs.
• Time spent on customizations. Depending on how the costings ledgers are set up it may be difficult to differentiate between time the company’s personnel spend on implementation (operational discussions, training, documentation etc.) and that spent on purely the customization effort. However, an estimate would be useful to plan and manage customization resources.
• Take all the basic functions of the ERP system (Creating a PO, Releasing a work order, etc.) and find what percentage of these functions have been modified in some way. This is an approximate measure but one that will give the company an idea of the amount of customizing that is being done and whether it is within what was envisaged when the project started.
• Most ERP systems have reporting that can tell you how many programs there are and how many of those programs have been customized. This again is an approximate indication as it is measuring input rather than output, but it will provide some level of information.

Conclusion

What this article has attempted to bring to light is that a company wishing to strengthen its competitive advantage or improve its internal processes should not be afraid to modify the source code of an ERP system if done correctly, with the right foresight, justification and controls in place. Be very judicious about the amount of customization by assessing the customizations’ long-term business value and ensure that the complete customization process is managed and under control.

About the Authors

Robert Ratcliffe (CPIM, CSCP) - Bob has 30+ years of experience and knowledgeable in manufacturing and finance operations. Bob has assisted over 50 companies with process improvement and standardization, ERP implementation and supply chain strategy.

https://www.dhirubhai.net/in/robert-g-ratcliffe-consulting/

Anil Khanna - Anil has 25+ years of experience in project management and business analysis in sales, operations, and information technology. He has managed over 200 projects with delivery teams of up to 300 people. He has delivered over $100M in value to his clients.

https://www.dhirubhai.net/in/anilkhanna/