Complex ERP implementations: 6 Flashpoint Areas and How to Avoid the Disputes they Can Create

By Allan Watton on

ERP projectImplementing an Enterprise Resource Planning (ERP) system is a significant undertaking for any organisation. It may promise to streamline operations, improve efficiency and provide insightful data for decision making. However, the journey towards successful implementation is often fraught with challenges. Because of this, potentially serious disputes between a client and their ERP solution provider are not uncommon.

Complex ERP implementations: 6 Flashpoint Areas

Evidence from both our dispute resolution work out of court and our Expert Witness work undertaken for the High Courts shows that there are six flashpoint areas where misunderstandings and/or material differences of opinion between an organisation and a supplier can have the most adverse impact during a complex ERP implementation. Those areas are:

    1. Functional requirements
    2. Management reporting needs
    3. Integration with third-party legacy solutions
    4. Data migration
    5. Articulation of business benefits and adverse impacts
    6. Discrepancies in resource allocation

Each of these areas represents a critical aspect of your ERP implementation process where disagreements have the very real potential for fatally derailing progress as well as significantly increasing implementation costs and time.

Preventing misunderstandings

Where you have relied on the specialist expertise of your ERP provider in guiding you to an appropriate solution, it is important to note that the responsibility for a successful implementation does not usually rest on your (the client’s) shoulders.

Whether or not they realise it, as industry experts, ERP solution providers play a critical role. Recent case law indicates that ERP solution providers are expected to leverage their industry expertise to guide you through validating your requirements, anticipate potential misunderstandings prior to implementation, provide key insights into the implementation process, and identify any potential challenges and propose effective solutions. This role extends beyond mere solutions provision, to encompass what can be termed an ERP solution provider’s ‘Expert Responsibilities‘.

What are the ERP solution provider’s ‘Expert Responsibilities’?

This refers to your ERP solution provider’s obligation to act as a strategic partner. It is usually implied in law that where they have represented themselves as ‘Experts’ or as ‘Specialists’ in providing ERP solutions, they are expected to provide proactive guidance, undertake appropriate due diligence to fully understand your business, communicate honestly and openly, and commit to your success, demonstrating flexibility and a long-term focus. In other words, they act as your ‘strategic partner’.

This role requires the supplier to lead your ERP implementation process while fostering a collaborative relationship with you, asking you ‘the right questions’ to validate your requirements.

Furthermore, if you have been reliant on the provider’s experience and expertise, they will often have a ‘Duty to Warn’, meaning that they are usually obliged to alert you if they foresee that your decisions or actions could lead to project overruns or jeopardise the successful implementation of your ERP system. This duty is a manifestation of the supplier’s role as a ‘critical friend’ – providing constructive criticism and challenging you when necessary, but always in a respectful and supportive way.

The 6 Flashpoint Areas for Dispute Issues and How to Avoid Them

In the following sections, we delve into each of the six highly significant dispute areas, exploring why they arise, how they could be prevented, and how they can be mitigated. Through both our experience and evidence of these issues, this article should provide a comprehensive guide to navigating key aspects of the complex journey of ERP implementation.

#1. Functional Requirements

This refers to the specific features and capabilities that you perceive you want your ERP system to have. Disputes can arise if your requirements are not met, or if there is a misunderstanding between you and the supplier about what the system can and cannot do.

    • Why issues arise: Issues can occur due to a lack of clear articulation about what will change in your organisation once your ERP solution has been successfully implemented and is running in business-as-usual mode. This is the why of your ERP implementation. You should articulate the imagined (visualised) ‘end-state’ of a successful implementation; what outcomes are now being achieved that were impractical prior to the implementation; what objectives are being met; and what obstacles or hurdles have been overcome.
    • Prevention: To prevent misunderstandings over your requirements, the business outcomes and objectives resulting from a successful implementation should be appropriately articulated and your ERP solutions provider should (a) validate them and (b) translate them into functional requirements through an appropriate business analysis (due diligence) process.
      Ideally, the supplier should be contracted specifically for this due diligence process before you purchase the full range of licences, implementation and consulting support.
      Once the provider has confirmed, after this due diligence, that the solution will meet the requirements of your organisation within your expected time scale, budget and resourcing, then the primary aspects of your ERP solution can be contracted for in a second phase (or subsequent phase if more extended due diligence phases are required).
      Both the terms of reference for the supplier undertaking an appropriate due diligence exercise on your organisation and the agreed output from the due diligence exercise to validate your expectations should be incorporated into the schedules of the contract terms and given precedence, should you need to determine a supplier’s priority of obligations.
    • Mitigation: If misunderstandings arise over your functional requirements post-contract, you and your supplier should revisit the original requirements. The supplier should also undertake a specific due diligence exercise on your organisation, re-translate any functional requirements, and clarify any misunderstandings.
      The terms of reference and the output for the due diligence exercise should then be incorporated into a revised version of the contract and schedules. This is important as it is likely that further misunderstandings, significant unexpected costs, and implementation delays will arise if the supplier is not instructed to undertake an appropriate due diligence exercise.

#2. Management Reporting

The reports and analytics that you need from your ERP system to manage your business are critical. Disputes often arise if the system does not provide the required reports or if the reports do not provide the expected insights.

    • Why issues arise: This issue often arises due to a lack of your supplier’s understanding of your reporting needs or a failure to understand the degree to which the new ERP system is capable of producing the management reporting required. ERP solution providers will often extol the virtues of their ‘open’ system and data repositories, along with just how ‘powerful’ third-party reporting tools are to help you obtain management insights on any aspect of the data held within the solution.
    • Prevention: To prevent issues here, your reporting needs should be clearly defined and agreed upon before the project begins. The supplier should confirm that your ERP system can meet these needs. Again, it comes down to the degree to which your supplier has undertaken appropriate due diligence of your operational requirements and management reporting needs, prior to your purchasing the solution.Our one area of caution. We deal with a lot of misunderstandings in disputes over inadequate management reporting capability from new ERP solutions. It makes sense to ensure the supplier is fully aware of your reporting needs through them conducting an extensive due diligence exercise and that you contract them to provide all of your key reporting requirements (whether they simulate your existing reports or provide new reporting requirements) as part of the implementation of the ERP solution.Some providers will put you off doing this because they do not want the hassle of actually writing the reports for you – and then finding out the solution you have just invested millions in needs further investment in data extraction tools and/or data warehousing facilities. Making your key management reports part of your contracted solution deliverables is the best insurance.
    • Mitigation: If disputes occur over your management reporting needs after the contract is signed, as outlined in point 1, both you and your supplier should re-review the initial reporting requirements. The supplier should also conduct a targeted due diligence exercise on your organisation to re-define the management reporting needs and clarify any misunderstandings. The scope and results of this due diligence should be integrated into a revised version of the contract and schedules. This step is crucial to prevent further misunderstandings, unexpected costs, and delays in implementation if the supplier does not carry out an appropriate due diligence exercise.

#3. Integration into Third-Party Legacy Solutions

The need to integrate your ERP system with other legacy systems that you are already using is a common requirement. Disputes often arise because integrations can turn out to be far more complex than the supplier anticipated, despite the supplier’s previous assurances of their experience at the sales stage.

    • Why issues arise: Issues in this area often arise due to technical challenges, a lack of the supplier’s understanding of the legacy systems, or a lack of coordination between your ERP solutions provider and the providers of the legacy systems.
    • Prevention: To prevent issues, the need for integration and specific requirements of your legacy systems should be clearly defined and agreed upon before the implementation of the project. The supplier should confirm that they can successfully integrate with the legacy systems, which they can do as part of their due diligence by reviewing the data available from the legacy systems and the data required to integrate the new system correctly.Facilitated due diligence (see ‘Prevention’ in point 1 above) sessions between you, your ERP solutions partner and the legacy solutions partners should be a fundamental requirement. Both the terms of reference for the due diligence and the output from the due diligence exercise should form part of your contract and schedules to ensure your supplier is clear about (a) your expectations from the integration, (b) whether it is possible to integrate in the manner both supplier and legacy solution providers need, and if so, (c) the degree of effort, cost and the timeframe necessary to achieve an on-going successful integration capability – including the inevitable upgrades that will occur between legacy systems over time and the subsequent ‘breaking’ of the data links as a result of the upgrades.
    • Mitigation: If issues arise here, a comprehensive mitigation strategy is essential. Begin by revisiting the original integration plan with your supplier to identify deviations. The supplier should then conduct a technical review to understand the root cause of the integration issues and engage with the providers of the legacy systems for their insights.Based on these findings, the supplier should develop a remediation plan outlining the steps to resolve the integration issues. This plan, including revised integration requirements, effort, costs, and timelines, should be incorporated into a revised version of the contract and schedules. The supplier should then implement the remediation plan, providing regular updates to ensure transparency and alignment.

#4. Migrating your Legacy Solution Data

This refers to the process of moving your data from your legacy systems to the new ERP system. Disputes can arise because the data is often incorrectly mapped, is incomplete, or is not ‘clean’ enough to work correctly in your new system.

    • Why issues arise: Issues often arise due to technical challenges, a lack of planning and preparation, along with a supplier’s lack of understanding of your legacy data. Your new ERP solution provider will often try to limit their exposure by offering 3-5 data migration ‘events’ within their proposal. Each of these transfer processes usually fails on several fronts due to inconsistencies in the data. Because your ERP solution provider has usually priced for 3-5 migration sessions in their proposal, they consider themselves ‘off-the-hook’ if the data migrations continue to fail thereafter. The implementation of the project will be severely compromised and often involves significantly increased costs for the ongoing process of continued data migration exercises.
    • Prevention: To prevent issues arising here, a detailed data migration plan should be developed and agreed upon before the implementation begins, as part of the supplier’s detailed due diligence exercise (see point 1). This should include ‘on-the-shoulder’ support from your ERP solutions provider for all aspects of their appropriate due diligence on the legacy solutions data, then to appropriately plan for data cleaning (while the planning should be the responsibility of the new ERP solutions provider, the cleaning itself is usually your responsibility, but under their ‘on-the-shoulder’ guidance), mapping (supplier’s responsibility), and validation processes (supplier’s responsibility, but using your business knowledge for their input). In this way, the limit of 3-5 data transfer processes becomes irrelevant, because with your ERP solution provider’s expert ‘on-the-shoulder’ support, you should only need 1-2 iterations of data migration, planned, implemented and driven by the supplier themselves.
    • Mitigation: If issues arise post-contract, the supplier may need to troubleshoot them, recover lost data, or re-migrate the data. This could involve significant technical work or additional data cleaning and validation. Again, follow point 1 and the process of contracting the supplier to re-engage in due diligence on your data migration, so that any future misunderstandings are minimised.

#5. Articulation of Business Benefits and Adverse Impacts

This refers to the need for you to clearly articulate the benefits you expect from your new ERP system and the adverse impacts on your organisation if the implementation is not successful.

    • Why issues arise: Issues in this area often arise due to unrealistic expectations you may have of the benefits of the ERP solution, a lack of understanding of your ERP system, or a lack of communication between you and the supplier. It is important to have an objectively quantified, balanced scorecard of benefits, correctly aligned to the financial and non-financial aspects that your organisation is likely to realise. During the supplier’s due diligence on your organisation, expectations, and requirements, if they also review (as they should) the financial and non-financial benefits you are anticipating, it will help in two ways:
    • Supplier understands the wider context. By having a clearly articulated set of balanced scorecard benefits, the supplier can see your anticipated benefits during its process of due diligence on those expectations. This helps your supplier ask you the right questions to really get under the business drivers of your requirements and the efficiency improvements you expect the new ERP solution to provide. The supplier can then critical friend challenge your expectations, knowing the wider context of what business improvements you anticipate. It will really help the supplier to guide your expectations based on the degree to which the ERP solution will assist you in delivering the improvements you expect.
    • Supplier has ‘reasonable foreseeability’. By providing that balanced scorecard, if the implementation does not go to plan, it is clear to the supplier what the consequential operational impact is likely to be on your organisation. If the implementation continues to fail due to the supplier not being able to deliver the project in the manner you both agreed at the outset, your balanced scorecard of benefits minimises the potential arguments over recompense if the project fails outright.
    • Prevention: To prevent these types of misunderstandings, the balanced scorecard of expected benefits and potential adverse impacts should be clearly defined and agreed upon before the project begins. This should be based on a realistic understanding of what your ERP system can and cannot do and should have been agreed during the supplier’s due diligence exercise covering your organisation and operational requirements.
    • Mitigation: If issues arise post-contract, you and the supplier should revisit the original expectations and adjust them if necessary. The supplier may need to modify the system or provide additional support to achieve the expected benefits.

#6. Discrepancies in Resource Allocation

Disagreements over the allocation and quality of resources from both you and the supplier are usually common. Disputes can arise if either party feels the other has not provided the promised resources or expertise for the project.

    • Why issues arise: Issues often arise due to miscommunication or misunderstanding about the resources required for the project. They can also occur if there are changes in the project scope or timeline that impact resource needs.
    • Prevention: To prevent issues in this area, both parties should clearly define and agree upon the resources they will provide before the project begins as part of the supplier’s due diligence exercise. This should be documented in the contract and project plan. Regular check-ins will also help assure that both parties are fulfilling their commitments.
    • Mitigation: If issues arise post-contract, both parties should discuss the problem openly and honestly. A renegotiation of the resource allocation may be needed, or additional resources sought to ensure the project’s success. If the supplier’s technical expertise is lacking, you could request a replacement, or additional training for the supplier’s team.

What about changes in your requirements?

Legitimate changes in your ERP requirements do sometimes occur through the implementation of a complex ERP project. Your business outcomes can change, for example, as a result of a change of ownership, or a strategic change in the direction of your target markets.

However, once the implementation commences, an ERP solutions provider should not complain (and it usually does not have a right to, as a ‘specialist’ in its field) that you have ‘changed’ your requirements, when in fact, you have not really changed your requirements. It is just that the supplier realises the requirement has become clearer as it progresses through the implementation and obtains a better insight into your requirements during that time.

Such circumstances are rarely a legitimate ‘change’. Such a lack of clarity is likely a result of the supplier not undertaking (or you preventing the supplier from undertaking) an appropriate due diligence exercise on your operational processes and requirements, as indicated in point 1 above. If misunderstandings over your requirements do occur, it is likely that the supplier has not completed its ‘Expert Responsibilities’ and its ‘Duty to Warn’ as a critical friend through the extensive due diligence exercise that it should have been expressly contracted to undertake. It is important that the supplier understands an ERP project is more than a ‘sale’; for you it represents a critical business transformation and you are relying on their ‘expert’ industry knowledge, business operational knowledge, and deep domain expertise to determine the most appropriate solution.

Conclusion

The larger and more complex your ERP project is, the greater the risk of misunderstandings arising from it and the bigger the resulting cost is likely to be. This is why it is always important to remember that a successful ERP implementation requires a collaborative effort from all parties. Clear communication, mutual respect, and flexibility can help to prevent, or more rapidly resolve, misunderstandings and disputes.

Successful ERP projects do not rely on reactive measures to fix active misalignment over expectations, they are created using preventative measures implemented from the outset of your client-supplier relationship. These include the measures listed above – a thoroughly analysed, calculated and conveyed explanation of your desired ‘future state’ and the data outputs you expect from the implemented solution, forward thinking on how your new solution connects and collaborates with existing systems, a comprehensive data migration plan, and a complete understanding of the implications of failure and the resources that success will require.

By adopting these strategies you can significantly reduce the inherent risks associated with large complex ERP projects and develop a more collaborative relationship with your supplier that will often prevent misunderstandings arising in the first place.