Customizing an ERP During Implementation? Just Say No
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
When you are implementing an Enterprise Resource Planning (ERP) system, you or your stakeholders will likely identify a number of areas where the new system may not perform in a manner consistent with the legacy system running the organization’s administrative business functions. This is to be expected as no two ERP systems function the same. In particular, no ERP functions like either a Mainframe system or disjointed and disparate administrative software, which are the environments ERP systems often replace. A common approach to dealing with such perceived shortcomings is to seek a customization of the new ERP, often in an attempt to make it function like the system it is replacing or to meet the organization’s existing operating practices. While there can be gains in terms of user convenience for such efforts, customization is both expensive in the short term and presents a management, maintenance, and software version control burden in the long term.
In this article, I present a rationale for avoiding all customizations to ERP systems in their early stages and at best postponing such customization decisions until later in the ERP's life cycle.
NOTE: For convenience, I refer to ERP systems in this article; however, the rationale applies equally to Integrated Library Systems (ILS), Electronic Medical Record (EMR) systems, and other administrative business software systems used throughout an organization.
The Rationale Against Customization During the Early Stage of ERP Implementation and Adoption
This section presents my general rationale for avoiding customizing an ERP and especially during early stages in its implementation. It is my recommendation that organizations delay any and all customization for a minimum of six months, and preferably a full fiscal year, after the go-live date to allow staff a complete business cycle to use the ERP in a full production capability. My specific reasons for discouraging customization during ERP implementation include the folllowing:
1. Customization Goes Against the Business Process Re-engineering Value of ERP Implementations
Enterprise resource planning systems can bring value to an organization in terms of its automation, defined internal workflow capabilities and—through increased decision support—transparency and operational efficiency. However, to achieve these goals, organizations almost universally must commit to reassess and re-engineer their existing business processes.
A pre-implementation stage is the ideal time to document current operations in an effort to find and cut out unnecessary steps, streamline operations and reduce operating costs, as well as track how operations will translate into the new environment. The exercise of examining business practices helps and is often considered critical to a successful migration to the new system. However, this preliminary planning doesn't always happen, at least not as effectively as would be hoped.
Another way an organization can ensure business processes are modified is to essentially force itself to operate with the new ERP right “out-of-the-box” and with no customizations, however slight, to the code, work flows, and system operations permitted in the first fiscal cycle.
Such a delay or postponement of customization efforts will be seen as a polite way to deny such requests. Honestly, there may be some truth to this as postponing a request can be easier than openly saying no. However, organizations that truly embrace the notion that the ERP implementation is an effort to change business practices that perhaps don't work as well as they did in the past, even though they have been done that way since forever, generally can find greater success in the overall project.
2. Cost
Given the current fiscal situation throughout our economy, avoiding measures that increase operating costs in both the short and long term is often essential. At the least, such measures should be undertaken only when there is certainty about the fiscal budgets for the duration of the implementation project, and when there is certainty on the cost implications of the customization.
The true cost of customizing an ERP is rarely accurately considered and includes at a minimum all of the following:
Cost of custom code development by ERP vendor or 3rd party
This is often the only factor considered. However, what is considered is only the invoice amount presented on a custom code development proposal. Cost overruns, mid-stream changes to scope, or modifications that account for insufficient requirements are not considered, even though many acknowledge such a likelihood.
Additional end user training and consulting costs towards adoption of customized code
Customizations, whether altering the core source code or creating a new workflow, are often funded through the original implementation budget and often at the expense of training and consulting dollars. Introducing customized and unique code into an ERP system complicates the overall system use and management effort and usually requires additional training and consulting assistance.
Its an interesting act of irony that training and consulting funds are often raided to fund the customizations in the first place, when the customization itself usually requires additional training and consulting support beyond what was originally allocated.
Further, since the ERP is customized, the ERP vendor's trainers and consulting professionals may themselves need time to learn how it now operates before they can effectively provide the training and consulting services. Depending on the contract language for implementation support and consulting services, firms may have to pay for the time vendor representatives spend to learn the customization.
Increased cost of post-implementation ERP maintenance
Changes made to an ERP often alter the work process when implementing a vendor's regular patch updates. For example, many ERP systems present a social security number on screens that also provide other, less sensitive demographic information. Given the concerns surrounding identity theft, many consider enacting measures to remove the SSN for such screens so the screen itself can still be assigned to users as necessary for the execution of their duties without giving those users access to the SSN. It sounds worthwhile, and perhaps a change that removes one field from one screen will not be so expensive. However, such a change will have to be tested each time a patch to the ERP system is made to ensure the new patches do not overlay, reverse or otherwise alter the coding changes made in the customization. This added staff burden must be taken into consideration when evaluating this approach to making changes.
In light of this, the cost of customization should include the cost of custom code development, additional training and consulting expense, and additional manpower required to maintain the system in the long run.
Further, customization necessarily involves time, which may push back go-live dates. If doing so involves financial penalties for missing delivery dates, such financial penalties should also be considered.
3. ERP Implementation and Adoption Considerations
Prior to actual “real world experience” in using an ERP to accomplish the numerous tasks that must be performed at all stages of the business cycle, staff may simply not be in the position to identify and articulate all of the areas where customization may present value.
Until the organization has seen how the ERP supports all of its administrative and business functions—and certain functions only come up once or at certain stages in a fiscal year cycle—it may not be in position to know where enhancements will be most helpful to the organization.
Further, customizations have the potential to alter the ERP system in ways that affect its functionality in other areas. As ERP systems are integrated systems, changes in one area can have unexpected and unintended consequences in other areas. Often, these changes may not become apparent until later in the business cycle. Only after a complete business cycle would the organization know how to articulate the design constraints that will affect the specific changes desired without compromising functionality in other areas.
For example, a client implemented a customization to synchronize a Microsoft Active Directory with another, previously in-place LDAP directory in order to facilitate seamless new account creation. However, upon doing so, users who changed their demographic and other account information in systems and applications attached to the LDAP directory were now changing their account information through to AD and to all applications leveraging that directory as well. This led to users unintentionally locking themselves out of certain applications because their account information was now wrong. There were also numerous cases of the unexpected release of sensitive demographic information.
While the synchronization between these two directories and efforts to simplify new account creation would certainly be considered beneficial, the customization effort turned out to be a net negative considering its costs, the inconvenience it brought to users and the loss of data confidentiality.
While functional user and technical staff are still trying to fully understand the operation of the ERP, they may not be in a position to fully articulate the design requirements for any customization, nor accurately predict the consequences of customizations they do implement, as the example above illustrates.
During the migration to the ERP, the first task is really to understand the ERP and its unique intricacies. Customizing it at this early stage has the effect of giving both end users and technical staff a “moving target,” making such projects more challenging from both the operational and system administration perspective.
Conclusion
In short, organizations should avoid a “rush to customize.” It is to be expected that any new ERP system will have shortcomings, both real and perceived. All work-arounds and alternatives should be explored before making a commitment to changing a system that is not yet fully implemented. It is important to bear in mind that customization does not mean “fixing” an ERP, and there is no guarantee that the ERP will behave exactly as desired once a customization has been completed. There are numerous examples where programs were modified to address an expressed need only to discover the modified programs didn't achieve the desired result. Customization in year two, or after the organization has reached maturity with the ERP, have a far greater change or being successful.