 |
| Credit: Ryan O'Connell |
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.
- 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.
- 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.
- 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.
- 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.
- 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.
Related Posts
Twenty Years of ERP Lessons LearnedSAP botching up support transition for Business Objects
Infor's opportunity: value in maintenance and support
Oracle applications customers: wedded bliss or battered wives?
4 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