Increasingly, corporations are striving to improve the efficiency of their business processes, the quality of their back-office administration, the automation of frequently occurring commercial operations, and to improve their ability to capture and report key business information.

Perhaps the most sought after tool for improving an enterprise's financial administration, materials management, customer relationship management, procurement operations and logistics, and human resources administration are comprehensive enterprise-wide software systems that can be configured and implemented to re-engineer their existing business processes – from initial data capture through to the production of comprehensive analytics and management reports associated with those business process cycles.

However, even the job of describing a corporation's existing business processes can be a daunting (if not miraculous) task, let alone describing their transformation. Since such business transformation projects will form the very heart of how your enterprise carries on business, you will be required to do everything you can to ensure their success.

Based on our ERP transactional and dispute resolution experience, we offer the following three must-dos to promote ERP project success and to avoid being substantially (if not drastically) off spec on functionality, excessively over budget and a victim of material delays, all of which can devastate your enterprise's business and reputation. Sadly, any one or more of the following three fundamental requirements to promote ERP project success are far too frequently ignored, always at the implementing corporation's peril:

1. Separate the Business Process Design (Re-engineering Blueprint) from Configuring the ERP Software: If the ERP software you will implement is not an off-the-shelf business-process-in-a-box that will allow you to simply replace your current operations with the vendor's automated solution, then you first need to undertake the business (not information technology) activity of re-engineering those processes to identify all of the procedures, systems, operational service level requirements, functional specifications and outcomes that your enterprise operationally requires. Arguably, your enterprise cannot be in a position to know what ERP software to select or implement until (and unless) those business process transformation requirements are first designed and articulated. Again, re-engineering the business processes in any industry is strictly a business activity, not an IT or computing activity. The greater the uniqueness or complexity of the business operations are, the greater the need is to first blueprint the business processes you require. On the other hand, the more generic or commoditized your desired business processes are, then the more likely it will be that an off-the-shelf process-in-a-box ERP solution will do the trick.

For everyone else, the Ontario Government's Task Force on Large-Scale Information Technology Projects¹ provided helpful recommendations concerning how to avoid large IT project (including ERP) failure, with lucky Recommendation #13:

PROJECT SPONSORS SHOULD SEPARATE DESIGN FROM BUILD IN PROCUREMENT. In the spirit of keeping projects and project steps small, we recommend… a practice that British Columbia is currently testing. When developing an IT solution, British Columbia separates the design phase from the build phase. It uses two or more private sector vendors to design a solution in partnership with the government. The province then uses the best design as the basis for the build phase of the project.

In the interest of ERP project success, the configuration of a complex software system is not the time for enterprises to make fundamental decisions about what its business process needs are. Until the enterprise knows precisely what its business processes and operational systems needs are, how can that enterprise possibly select, price, timeline or allocate personnel resources to the implementation of any particular ERP software tool. If the ERP project is phased correctly, the otherwise challenging ERP contract issues simply fall into place, such as:

• Defining ERP software's functionality and technical scope;
• Performance warranties and limitations;
• Setting out the requirements of database, network platform, interoperability and connectivity;
• Operational warranties;
• Agreeing upon realistic pricing and personnel allocations;
• Stipulating reasonable implementation timelines tied to testable milestones based on empirical operational criteria; and
• All related third-party product compatibility.

2. As Trite as it Sounds, Align Your Business Process Requirements with the Capabilities (and Limitations) of the ERP Software You Have Selected: There may or may not be a gap between your well designed business process requirements and the ways in which the ERP software you have selected can be configured. But the best way to avoid ERP project failure is to undertake that reality check. Unrealistic operational expectations are not fair to either party, and ERP buyers should ensure they will only pay for ERP operations that can actually be configured and delivered. Once that rational process of needs assessment, ERP capability limitations, and business process/price compromise is settled, then the parties can proceed to negotiate reasonable ERP software and implementation contracts.

3. Managing ERP Project Risk By Contract: Depending on your ability to separate business process design activities from the services that are required to configure the ERP software on spec, on time and on budget, there are many ways that the ERP software and implementation services contracts can mitigate and manage (if not avoid) ERP project risks:

• As a much less preferred alternative to the best-practice two-stage ERP procurement process we have described, you may consider dividing the implementation contract into several distinct (but inter-connected) phases where each subsequent phase is conditional on the success of the prior phase. For example, the first phase of the project could be to develop a business process transformation blueprint that will satisfy the enterprise's business requirements, and no ERP software will be procured and no implementation services will commence until that occurs. Another example might be, that unless the selected ERP software is contractually warranted to be capable (not that it will) of being configured to achieve that blueprint's design, no implementation services will commence;
• Distinguish the risks and liabilities of not achieving the agreed upon blueprint transformation deliverables on budget, on spec and on time (for any reason) from all of the other risks and potential liabilities associated with the project, such as negligence, intentional misconduct, not maintaining required service records, failure to protect personal information, or any infringement of either your or any third-party's contractual, intellectual property or confidentiality rights;
• Like the construction industry, structure all implication service fee payments with progress hold-backs based on empirically defined milestones and achievement requirements that will be tested and accepted by the enterprise;
• Focus on practical remedies that encourage and promote contractor performance rather than merely punitive financial remedies, such as requiring increased personnel or more experienced personnel to be assigned, requiring root cause analysis by independent investigators, and having the right to assign experienced and expert personnel from third parties (perhaps from the ERP software company) to directly assist senior consultants in their implementation services; and
• Identify project problems early and respond to them before they become either too numerous or too large to remedy easily. Joint Management Committees receiving internally escalated problems is an excellent practice in that direction. Frequent governance reviews of the project managers is another prudent step since many project managers may be reluctant to admit there are implementation problems until it is then too late to resolve them.

Summary

In our view, the majority of disputes and litigation concerning ERP software projects can, and would, be avoided if the following simple linear process was adopted:

1. First, design the required business processes;
2. Then, select the ERP software that best suits those business/operation requirements;
3. Then, determine whether any customizations, third-party components are needed and what company is best suited to help you implement the ERP software you have selected;
4. Rationally adjust your ERP software functionality expectations and the overall solution price;
5. Then, contractually formulate fair and reasonable configuration and implementation timelines, costs and milestone acceptance testing criteria, and change management terms. 

Notes

1. Report of Ontario's Special Task Force on the Management of Large-Scale Information & Information Technology, July 2005. The Task Force Final Report can be found at www.ontla.on.ca/library/repository/mon/11000/254912.pdf