Enterprise System Spectator blog: ERP and enterprise system vendor evaluation, selection, and implementation.

The Enterprise System Spectator

Thursday, January 31, 2013

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?

Labels: , , ,


by Frank Scavo, 1/31/2013 02:31:00 PM | permalink | e-mail this!

Subscribe!

 Reader Comments:

Frank,

As a vendor in the government financial space, I have to disagree with your first point. Success is ultimately shared. Otherwise it becomes the hen and pig all day breakfast restaurant: the hen is involved. The pig is committed.

Software vendors distance themselves from customer success and failure in numerous ways. Rarely is the software vendor part of the project governance structure. This is a fundamental flaw, particularly when public money is at stake.


 
I do understand your point, Doug, and agree in principle. It all depends on what we mean by "responsibility." From a contractual perspective, yes, there is shared responsibility. That is the whole point of a contract. But my point is that the customer (whether private or public organization) should plan for the contingency that vendor may not live up to its responsibility. This is all about risk management.
 
We've been asked to do this and the idea of giving our source code to a third party outsider is anathema, probably a deal-killer for us.

I've seen very few articles on this subject via a Google search and only 10% of those are from neutral observers (not software escrow companies).

One big problem here is that the customer could very well like to purchase (own) the assets of the vendor and it would then be in the interest of the customer to see the vendor go out of business.

It's a huge threat to a vendor to say for instanec "If you end up in the hospital, we're just going to take your company out from under you".

And maintaining a working version of a cloud service with documentation would take months of work in and of itself. The escrow service is supposed to know how to run things, especially if the service has other complicated elements?

This sounds like an idea for a business that sounds good to customers but not to suppliers.

 
To the previous anonymous poster, I think you are overestimating the risks to the vendor in software escrow agreements. Having represented software buyers for years, I can tell you, no customer wants to see a software escrow code release take place.

Furthermore, as you point out, there are huge issues with applying software escrow to a cloud service. In fact, I wrote about this in a previous post here: http://fscavo.blogspot.com/2009/09/saas-contingency-plans-need-more-than.html

I do think that software escrow is proposed as a solution too often, when in fact, it is rarely if ever invoked. As Jeff Gordon points out in a comment on that previous post, in all his years negotiating contracts, he has never seen a successful code release.
 
Post a Comment
 

Links to this post:


 

Powered by Blogger

(c) 2002-2014, Frank Scavo.

Independent analysis of issues and trends in enterprise applications software and the strengths, weaknesses, advantages, and disadvantages of the vendors that provide them.

About the Enterprise System Spectator.

Frank Scavo Send tips, rumors, gossip, and feedback to Frank Scavo at .

I'm interested in hearing about best practices, lessons learned, horror stories, and case studies of success or failure.

Selecting a new enterprise system can be a difficult decision. My consulting firm, Strativa, offers assistance that is independent and unbiased. For information on how we can help your organization make and carry out these decisions, write to me.

For reprint or distribution rights for content published on the Spectator, please contact me.


Go to latest postings

Custom Search

Join over 1,700 subscribers on the Spectator email list!
Max. 1-2 times/month.
Easy one-click to unsubscribe anytime.

Follow me on Twitter
My RSS feed

AddThis Feed Button


Computer Economics
ERP Support Staffing Ratios
Outsourcing Statistics
IT Spending and Staffing Benchmarks
IT Staffing Ratios
IT Management Best Practices
Worldwide Technology Trends
IT Salary Report
IT Help Desk/Service Desk Management

Get these headlines on your site, free!


Awards

2013 Best ERP Writer - Winner

Alltop. We're kind of a big deal.
 
Constant Contact 2010 All Star Technobabble Top 100 Analyst Blogs


Blog Roll and Favorite Sites
Strativa: ERP software vendor evaluation, selection, and implementation consultants, California
StreetWolf: Digital creative studio specializing in web, mobile and social applications
Vinnie Mirchandani: The Deal Architect
Oliver Marks' Enterprise 2.0 Blog
Si Chen's Open Source Strategies
diginomica
CISO Handbook


Spectator Archives
May 2002
June 2002
July 2002
August 2002
September 2002
October 2002
November 2002
December 2002
January 2003
February 2003
March 2003
April 2003
May 2003
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
July 2008
August 2008
September 2008
October 2008
November 2008
December 2008
January 2009
February 2009
March 2009
April 2009
May 2009
June 2009
July 2009
August 2009
September 2009
October 2009
November 2009
December 2009
January 2010
February 2010
March 2010
April 2010
June 2010
July 2010
August 2010
September 2010
October 2010
November 2010
December 2010
January 2011
February 2011
March 2011
April 2011
May 2011
July 2011
August 2011
September 2011
October 2011
November 2011
December 2011
January 2012
February 2012
March 2012
April 2012
May 2012
June 2012
July 2012
September 2012
October 2012
December 2012
January 2013
February 2013
March 2013
May 2013
June 2013
July 2013
September 2013
October 2013
December 2013
January 2014
February 2014
March 2014
Latest postings