Mitigating Risk in Software Vendor Support

Credit: Ryan O'Connell

For implementation and ongoing support, most customers rely on their original vendors of major enterprise applications, such as ERP, CRM, and supply chain management (SCM). But what happens when the vendor is not up to the job? What steps can buyers take to mitigate the risk of vendor support failure and protect their investment?

These are questions that come to mind when reading about a recent lawsuit by a governmental agency in Puerto Rico against Infor, alleging that Infor "has been absolutely incapable of resolving serious problems" with the agency's implementation of an Infor product.

The Allegations

The agency, known the Municipal Revenue Collection Center (or, CRIM by its Spanish acronym) originally purchased a license for a computerized tax management system in 2006, prior to Infor acquiring its developer, Hansen, in 2007. Complicating matters, CRIM originally purchased its Hansen license through a Hansen partner, Rock Solid.

Reading the agency's lawsuit, CRIM appears to have done at least a partial implementation of Hansen starting in 2006. Then in 2009, CRIM negotiated and executed contracts with Infor totaling approximately $1.1M to provide services and support for its Hansen system.
Sometime after signing these agreements with Infor, things appear to have broken down.

The details of CRIM's complaint against Infor are summarized by Chris Kanaracus at IDG News Service. In summary, CRIM alleges that the original resources Hansen assigned to the project left Infor after the acquisition, and that Infor was unable to provide other resources that were up to the task. As a result, CRIM claims it has had to create patches and workarounds to keep the system active and working, a job which is made more difficult by not having access to Hansen source code. According to CRIM, serious problems remain unresolved.

Take Steps to Mitigate Risk

Although any legal complaint will, by definition, be one-sided, there are important lessons that buyers can learn, regardless of the outcome of this legal action. In fact, lawsuits of this type are often settled without disclosing the details, meaning we may never know who is at fault.

Therefore, it is more important to focus on what buyers can do, before entering into a vendor relationship, to mitigate the risk of getting into a situation similar to what CRIM claims. 

1. Implementation success is ultimately the buyer's responsibility. By all means, reach out to the vendor, or a vendor's partner, for implementation and ongoing support. But recognize that you cannot delegate success. Ultimately, it is your implementation, and your responsibility to ensure you have support. 
    
   
2. Every mission-critical system implementation plan needs a risk mitigation plan. It appears that CRIM's system was core to the agency's mission--to "collect, receive, and distribute public funds corresponding to municipalities." Inasmuch as its Hansen system supported that mission, the system is, by definition, mission-critical. Did CRIM have a risk mitigation plan? Did that plan identify the risk of losing key vendor support personnel? Apparently, not.
    
3. Software product change of ownership introduces risk. Your risk mitigation plan should include a scenario where your software product changes ownership. In some cases, support actually improves under new ownership, especially if the new owner views the acquisition as strategic and the previous owner did not have the resources to deliver required levels of support. But in other cases, the vendor may be viewing the acquisition as simply an asset purchase and may be looking to drive support costs out of the business to improve profitability. Either way, a customer should pay close attention whenever a software product changes hands, and certainly before making new investments in that software, whether in purchasing additional licenses, or as in this case, in negotiating new service contracts.
    
4. Avoid single point of support failure.  It is important for customers to always have alternative sources for support. The vendor does not need to be the only source. Sometimes local partners are a better source. Other times, third-party support may be available from organizations that are not vendor partners. Even individual consultants, if they have the right skills and experience, can be a good source, and an excellent value. A combination of vendor support and support from other sources can often be the best approach, to minimize risk and ensure continuity of service.  
    
   
5. Secure access to source code. Finally, customers should negotiate access to source code as part of their initial license agreement, to allow the customer to take over its own support. If the vendor does not accommodate this need, then it often can be negotiated as a condition of a change in control, such as a buyout or acquisition of the vendor. In cases where the vendor goes out of business, a software escrow agreement can at least deliver original source code to the customer.

Commercial software is an attractive alternative to in-house custom system development, in part, because it relieves the customer of the need to provide its own ongoing support. Most of the time, vendors deliver their end of the arrangement. But customers should plan for the times when they don't.

Related Posts

Twenty Years of ERP Lessons Learned
SAP botching up support transition for Business Objects
Infor's opportunity: value in maintenance and support
Oracle applications customers: wedded bliss or battered wives?