At the beginning of an ERP implementation, your company might be of the mindset that your ERP system will go live with out-of-the-box settings. In fact, many businesses start their ERP journey with this goal in mind and with good reason – staying out-of-the-box will significantly reduce implementation cost and can keep your upgrade path free of compatibility issues.

While implementing a “vanilla” ERP system sounds easy, it’s actually very difficult to achieve. Most companies end up with customized ERP solutions, or at the minimum, a specifically configured system and several integrations.

While ERP systems are built to meet industry standard business processes, many companies find the need to customize because standard ERP functionality doesn’t always align with their company’s unique business processes.

So, how do you determine which of your ERP requirements can be met out-of-the-box, which need configuration and which require customization? Based on our experience evaluating ERP systems across a variety of industries, we have outlined some guidelines to help you make these tough decisions. But first, let’s clarify some terminology:

ERP Customization vs. Configuration

A configuration is a setting, parameter or personalization built natively into the ERP software. A setting or parameter could be a simple flag or field or as complex as a table defining a list of rules. A personalization could be rearranging the order in which fields are displayed on a form or changing the label of a field. No coding typically is required to enable or disable these settings.

Customization, on the other hand, almost always requires changes to the system’s source code. Customizations can be new features that enhance the core software, they can be custom reports, or they can be integrations between the ERP solution and third-party applications.

Making the Decision

While every company has unique requirements, there are two things all businesses have in common: they want projects under budget and on schedule. Based on these goals, we created the below decision tree to help you decide whether a requirement should be met via out-of-the-box features, configuration or customization:

erp configuration 2

How to Use the Decision Tree

We recommend selecting an ERP system with functionality requiring minimal customization. Your RFP responses and ERP demo results can help you determine this for each of your requirements. Ultimately, though, some requirements may entail software customization, so you will need to weigh the costs and benefits of customization versus business process reengineering.

That said, let’s walk through each branch of the decision tree:

Does an out-of-the-box feature meet the business requirement?

To answer this question, it’s important to schedule an ERP demo. Business users can then determine if the demoed functionality truly meets each requirement.

For example, a business requirement may be “the ability send vendors an invoice displaying both the company billing address and the delivery address after purchase orders have been received.” If the demo reveals that the out-of-the-box invoice document only displays the billing address, then the business requirement would go through the next step in the decision tree.

ERP Selection Guide

This ERP Selection Guide will help you select technology that will support your organization for at least the next ten years.

Does a standard configuration meet the business requirement?

To know every setting in an ERP system and what outcome it drives is nearly impossible. This is why it’s important to write demo scripts for ERP vendors to encourage them to show exactly how their system fulfills a requirement even if it means they must demo the steps required for a configuration.

If the vendor does not demonstrate how their system can be configured to meet a requirement, there may be enough time for a question and answer session at the end of the demo.

Depending on the extent of the configuration, a follow up demo may be necessary, so the vendor can demonstrate the system with the software already configured. If the business is satisfied with the way the requirement is fulfilled, then the configuration should be documented so it can be put into testing environments and eventually production.

If the business rejects the configuration, then the next question is . . .

Do you have the budget for customization?

The answer could be a simple yes or no, but it likely will depend on several factors.

In your ERP project budget, you may have set aside some funds for customization. Depending on your customization budget, you may need to determine which requirements needing software customization are the highest priority.

Regardless of budget, how much customization is appropriate? While tailoring your new ERP software to exactly match your needs sounds desirable, it also has some consequences.

Besides the fact that customization requires design, development, deployment and testing work, customization also puts your upgrade path at risk.

For example, if you are using a cloud ERP solution where upgrades are automatic, then customizations can cause compatibility issues. In fact, upgrades may overwrite or conflict with your custom code.

If you are using an on-premise ERP solution, upgrades of customized software also are challenging. Performing capability checks and addressing issues will be another hurdle to add to the already arduous on-premise upgrade process.

If these upgrade risks don’t scare you, the customization process itself might. The development effort and rounds of testing are both time-consuming.

If you decide not to customize the software to meet a particular requirement, you have one more option:

Can you reengineer some of your processes?

While you may already have reengineered many of your processes before ERP selection, more opportunities for improvement may present themselves throughout your evaluation. This is especially true if you find that some of your requirements are not worth the time and effort of customization.

Many companies like to avoid process improvements because they know their employees will resist change. However, when the alternative is going over budget with customizations or not meeting a requirement at all, then process improvement starts to look a lot more attractive.

After all, organizational change management is always an option. Change management helps prepare employees for new processes and technology, and it is essential even for companies that perform extensive customization.

Revisit the requirement and ensure its validity

If it seems a requirement cannot be met out-of-the-box, through configuration, through customization or through process improvement, it’s time to reevaluate why the business has this requirement to begin with. Is this a requirement because it’s a restriction of the legacy system? Will there still be a need for it after go-live?

Select the Right System to Minimize Customization

Ultimately, if you’ve spent the time preparing for ERP selection, you will have clear business requirements that reflect your business’s competitive advantage and strategic goals. As a result, you won’t waste time evaluating a system that ends up needing extensive customization. Ideally, all the systems you evaluate will meet most of your requirements either out-of-the-box or through configuration.

Panorama’s ERP consultants can help your company narrow down your list to only the systems that align with your organizational goals. Contact us to learn how clear business requirements can serve as your secret weapon during ERP selection.

About the author

Avatar photo
Panorama Consulting Group is an independent, niche consulting firm specializing in business transformation and ERP system implementations for mid- to large-sized private- and public-sector organizations worldwide. One-hundred percent technology agnostic and independent of vendor affiliation, Panorama offers a phased, top-down strategic alignment approach and a bottom-up tactical approach, enabling each client to achieve its unique business transformation objectives by transforming its people, processes, technology, and data.

Posts You May Like:

Rebuilding Trust After a Failed Software Project

Rebuilding Trust After a Failed Software Project

Failed software projects often disrupt operations and erode trust among employees, stakeholders, and clients. Rebuilding trust requires transparent communication, accountability, and a comprehensive recovery strategy. Transparent communication, employee engagement,...