ERP Integration & Risk Management – Part Three

DAN MITZENMACHER: My name is Dan Mitzenmacher. Today's episode is the third and final of this three-part series around ERP rescue and recovery.

DAN MITZENMACHER: In our first episode, we gave a high-level overview of ERP project failures and challenges and some of the early warning signs of those failures. In our second episode, we dove into alignment of ERP strategy, stakeholder buy-in, and change management. In today's session, we'll speak about ERP system integration and customization, and we'll address risk assessment and mitigation planning used with clients in their rescue and recovery efforts.

DAN MITZENMACHER: I'm rejoined with my colleague Jim Holman, Director of Strategy and Operations within Digital Transformation Services. We're both part of Cherry Bekaert's digital advisory practice, where we guide our clients forward in their digital transformation journey.

JIM HOLMAN: Let's dive into some aspects of integration and customization in an ERP project. How do you help clients ensure their ERP system integrates with their overall landscape of applications and drives operational efficiency?

JIM HOLMAN: One of the items we discussed in a previous session is understanding your inventory of systems. What does your technology ecosystem look like? If you're replacing an ERP that already sits with other systems in the client's ecosystem, there may be existing integrations that must be thoroughly understood before a new system is placed and expected to work seamlessly.

JIM HOLMAN: Other solutions, such as a CRM, may not be integrated to the legacy ERP, but the client's expectation is that the new ERP will integrate. You could be dealing with a situation where the existing solution lacks an integration, but the expectation is that one needs to be built. Make sure before you get started that the solutions are compatible and that there is plenty of time for integration testing.

JIM HOLMAN: Regarding compatibility, we've seen existing solutions that lack open API standards, which means you may have to resort to more expensive and risky integration technologies, such as robotic process automation or direct interfaces within the platform database. Those approaches are undesirable if you can avoid them.

JIM HOLMAN: Once you decide how you will integrate and what data will pass back and forth, understand how the data will be controlled and secured, particularly if one solution is not on premise and is in a different cloud. Cloud-to-cloud data governance projects can go sideways if organizations are not prepared.

DAN MITZENMACHER: Integration of data is another piece of the process realized through data flowing from system to system. Knowing your processes and mapping how the data transforms across systems is very important.

DAN MITZENMACHER: Let's dive into customization. This is at the heart of many ERP implementation issues—trying to customize a system exactly to a client's needs. How do you help clients anticipate and manage customization throughout an ERP implementation?

JIM HOLMAN: Customizations in an ERP could be a podcast all on their own. Every project where a client—especially one moving from an older ERP—has many customizations, those were often normal 10 to 20 years ago when there weren't open API standards.

JIM HOLMAN: With excessive customizations comes increased complexity, higher costs, and potential ineligibility for rolling updates the provider offers every six months. We want clients coming from a custom solution to focus on their true, unique functional requirements and to leverage standard features whenever possible.

JIM HOLMAN: When a client has a unique requirement they are used to, we challenge them to self-assess: does this customization make them unique in the marketplace or make their goods or services higher quality? If not, they should consider adopting standard features and best practices.

JIM HOLMAN: Prioritize critical customizations and enhancements. For example, regulatory considerations that are non-negotiable must be accommodated. Specific customer requirements—such as packaging materials, labels, or instructions placed within a packaging set when goods are shipped—must be supported. Anything less should be considered optional.

DAN MITZENMACHER: Are there other considerations organizations overlook when moving from a custom solution to a less customized solution?

DAN MITZENMACHER: Clients often start by trying to recreate a process the way they currently do it. The first step in an ERP implementation is to look at the inherent capabilities of the software and leverage those as much as possible. Avoid customizing when you can, and explore workarounds and process changes that enable the requirement in a different way.

DAN MITZENMACHER: Where the software does not fit, consider alternative off-the-shelf solutions that you could plug in to meet requirements. Before heading down the customization-first route, start with what is in the software, identify possible workarounds, and evaluate other available alternatives.

DAN MITZENMACHER: We've talked about the risks ERP projects carry, and managing that risk is critical to project success and the role of project management. How do you work with clients to develop risk assessment and mitigation plans throughout their ERP implementation, and how do you work with them during rescue and recovery?

JIM HOLMAN: The best time to engage on risk assessment and mitigation is before go-live. For complex or heavily regulated organizations, a proper go-live readiness assessment should be formulated about midway through the implementation to ensure hot-button issues are addressed.

JIM HOLMAN: We look for areas of business disruption that, if they occur, will have a material or financial impact. For example, in the late 1990s Hewlett-Packard went live on SAP and their ink business could not invoice for three months. Identify the critical areas where disruption would be most damaging.

JIM HOLMAN: Outline and understand the processes to be tested and what happens if a function fails. Some functions can be in limp mode for a time and an organization can survive, but others—such as accepting customer orders or shipping product—are critical and will have significant downstream effects.

JIM HOLMAN: As clients go into testing and training, ensure they understand which areas are more important. Month-end close processes may be less risky to defer if necessary, but transactional processes that interact with trading partners deserve priority.

JIM HOLMAN: Second, define escalation procedures and rules of engagement for cutover. We want the solution provider to have an on-site presence during cutover and the first month end. When the provider lacks the right level of expertise on site, organizations may stop processing in the new system because users lack information or confidence.

JIM HOLMAN: The ERP may be functioning, but users who lack comfort in training may stop the process rather than risk making a mistake. That logjam can cause an ERP failure where there wasn't one to begin with.

DAN MITZENMACHER: Are organizations generally well prepared for what to do if a failure point occurs?

DAN MITZENMACHER: During migration, expect the unexpected and prepare contingency and backup plans for every step of the migration process. You have a go-live date and you start to migrate data. Challenges arise—data complexities or technical integration issues—and you must be prepared to pivot and implement backup plans if things do not go smoothly.

DAN MITZENMACHER: Test as much as possible to limit surprises, but be prepared for issues because they do happen.

JIM HOLMAN: I've been part of many ERP recoveries. One area we discuss with clients is how they define ERP failure. It used to be a software or server failure in an on-premise solution, but ERP is so expensive and disruptive that failure can also mean not meeting goals and expectations.

JIM HOLMAN: For some organizations, not achieving expected benefits is a failure. We had a digital signage client where failure was the order management team remaining on QuickBooks instead of moving to the new ERP. The expectation was that QuickBooks would be fully replaced.

JIM HOLMAN: At go-live, the order management team continued to use QuickBooks for a variety of reasons. That caused manual processes because shipments and billings still occurred in the old system and had to be updated in the new ERP manually. Integration was never in scope, so the automation, efficiencies, and economies of scale were not achieved.

JIM HOLMAN: The client also could not deliver technology customers expected, such as automated order acknowledgments via EDI, because the new system of record was not being utilized.

JIM HOLMAN: Another issue is identifying open and potentially disruptive issues. Many clients experience testing fatigue during user acceptance testing. Users testing repeatedly may not report perceived minor errors or defects because they do not want to stop testing as go-live approaches.

JIM HOLMAN: In the digital signage case, the inside sales process owner was not on board and felt their needs were not fully considered. They found the new ERP harder to use and, rather than communicate defects during testing, they proceeded with go-live and then reverted to the old system when operational difficulties arose. That reversion was not communicated.

JIM HOLMAN: What did Cherry Bekaert do to get this back on track? We were brought in initially to help select a new ERP, but the client proceeded on their own during implementation. We were engaged midway through the project for a checkpoint and again about two weeks after cutover.

JIM HOLMAN: Two weeks after cutover we met with the C-suite, specifically the COO, to understand the defects missing from the ERP and to reassess functional requirements. There was a gap not fully addressed due to defects in requirements gathering and in user acceptance testing.

JIM HOLMAN: We had existing relationships with third-party providers and were able to escalate a vendor proof of concept to trial the needed sales workflow. Those gaps were identified and mitigated. The client conducted escalated user acceptance testing and decided to deploy the solution. All of that took place about two weeks after go-live.