For all of the reasons I wrote about last week, ERP software system contracts are becoming increasingly complex to negotiate and draft owing to the growing number of functions such systems are required to accommodate.
Because of the complexity, there are many ways an ERP project can go wrong, starting with how a user defines their needs. So, on December 5, 2018, noted ERP consultant Eric Kimberling and I presented a workshop to executives and managers responsible for implementing and running ERP software systems on how to help ensure their project stays on track. My talk focused on using the contract to reduce the likelihood of an implementation failure, providing an overview of a typical ERP dispute.
Broadly speaking, some of the principle challenges to a successful ERP implementation include:
- The project takes longer than expected,
- It costs more than was budgeted,
- The overall benefits anticipated by a business – or promised by the vendor – are not realized, or
- The ERP system causes a major disruption to the business.
Complaints and Mistakes
In my career as an attorney whose practice focuses on negotiating and drafting ERP software system contracts, I have seen a pattern of complaints from clients: The software vendor or implementer lacked experience in the user’s industry, they misrepresented the functionality of the software, or the ERP system was unusable after it went live, failing to deliver the promised benefits.
On the user side, sometimes the problems begin with the company not clearly defining its business goals and requirements for the system or not setting realistic expectations for the implementation. One of the key lesson’s companies should take from the failure of others is to be sure to address the non-technical resources that are needed to ensure a successful implementation. At the same time, users must manage the scope and cost of the project diligently to prevent either to escalate out of control; doing this means managing the software vendor closely.
Critical Pieces
With respect to a software license and to ensure that it works in favor of a user while protecting a developer it needs to include five essential pieces. As an ERP litigation attorney, in most of the cases I have handled for clients I found elements missing or inaccurately stated in one or more of these areas:
- The Warranty. It needs to include both a time period as well as include a reference to what is covered.
- Define the Software. The ERP contract needs to describe in detail what you believe you are licensing including descriptions of the modules, their functionality and features. It also must comprehensively describe how upgrades, updates and fixes to any bugs will be handled by the vendor.
- Limitations on Liability. ERP vendors and integrators have an interest in capping their liability under the contract as much as possible. You need to understand what is reasonable: What should be capped and by how much and what should not be capped.
- Price Increases. A major issue always seems to revolve around price hikes. The contract must define what a “reasonable” increase would be and when it can be levied.
- Terminating the Contract. It’s crucial for a user to be able to get out from under an ERP contract if the vendor or integrator isn’t delivering what is called for in the deal. Many times, a template contract from the developer makes it impossible for a user to terminate even if the problem was caused by the seller.
Statement of Work
When the user is creating their statement of work for an ERP software system, they and the developer need to agree in writing on what will be covered. This includes incorporating a cost estimate, the scope of the project including how changes will affect the scope of the effort, the budget and what will be delivered. At the same time, the deliverables have to be defined closely as does spelling out deadlines and milestones.
Equally important, the statement of work needs to define the process the user will employ in accepting or rejecting the deliverables from a vendor and integrator.
Lastly, the ERP implementation contracts I negotiate and draft include a warranty provision and the remedies available to the user in the event what was ordered isn’t installed. How will the supplier repair, replace or refund a deficient system also will help avoid the project ending up in a courtroom rather than in the buyer’s servers. Part of this includes being able to approve or reject the staff a vendor uses to build the software because too often the people doing the designing and coding have no real understanding of how the customer’s business works, their relationship to customers and the terms under which finished products are sold.
ERP software systems are too expensive, too important to the smooth functioning of a company, and too easily derailed not to have a carefully negotiated and tightly drawn contract governing the relationship between all of the parties. In the end, a solid contract protects the developer, the integrator and the user paying for the project.