Software Vendor Implementation Services Not Always Best Choice

In our software selection consulting, clients often seek our advice on implementation partners. In fact, our experience over several decades tells us that the choice of an implementation team is as important, sometimes more important, than the choice of a new system.

In choosing an implementation consulting group, clients often start out thinking that it’s best to choose the vendor’s own professional services group. They think that no one can know the software as well as the vendor’s own personnel. They think that when problems arise, the vendor’s consultants will be in a better position to deal with the software vendor. They also think that there will be less finger-pointing: the consultants blaming the vendor, or the vendor blaming the consultants.

These considerations have merit. But there are other factors to consider, factors that may make an implementation partner, or even an independent consulting firm, a better choice.

Read the rest of this post on the Strativa blog:
Software Vendor Implementation Services Not Always Best Choice.

The Role of Fear in ERP Implementation

Photo Credit

One of Deming’s 14 points for management was, “Drive out fear, so that everyone may work effectively for the company.” By this he meant that employees should not be afraid to point out problems, provide feedback, or make mistakes in an effort to improve. Business leaders should engage employees positively in continuous improvement.

But when it comes to business leaders themselves, fear can be a powerful motivator. And, nowhere is a healthy fear more needed than in ERP implementation.

It is difficult to think of a major project that is riskier for an organization than an ERP implementation. It ranks right up there with a major strategic merger or acquisition in terms of potential to disrupt the business. This is because an ERP implementation touches nearly every function of the business, nearly every business process, and nearly every employee. Although ERP systems involve computers, they are not IT projects: they are business change initiatives. Do it wrong, and you may find yourself as a case study on the front page of the Wall Street Journal.

Hopes and Fears

I recently co-led a half-day workshop for a large client in the manufacturing industry that is about to embark on a wholesale replacement of their aging ERP system. The participants were 18 of the firm’s business leaders. We covered the history and role of ERP, reasons for failure, lessons learned from successful implementations, typical processes most in need of improvement, and the roles and responsibilities of business users in the implementation.

At the end of the workshop, we conducted a short exercise that I call, “Hopes and Fears.” We invited the participants to list the things that they hoped would result from the implementation. They responded with a variety of benefits, such as improved efficiency, lower inventory, better planning, and a more modern user experience.

We then asked them to list the one thing they were most worried about, the thing they most feared as they looked forward to the implementation. Here the mood turned more serious as they expressed their fears, such as that they might not get enough training, that inventory might actually increase during the transition, that employees might not speak up when things weren’t going well, and that customer delivery schedules might be disrupted.

But the one thing that worried this group the most was that they wouldn’t have the resources to get the implementation finished while still taking care of their regular duties. Would they have the bandwidth? We had told them that they had to put their best people on this project, but could they afford to do that? Where would they get additional personnel? The top executive in the room spoke up and assured the group that the company was ready to spend the money to make those resources available.

At this point, I told them that I had accomplished my unspoken objective. My goal in conducting this workshop was to put some fear into them, as business leaders. Nothing concerns me more than when I see a company begin an ERP implementation thinking that it is no big deal, that they can delegate the project to the IT department, or to the system integrator. Or, thinking that they can treat an ERP implementation as just another project, like installing a new production line, or implementing a new safety program.

Address Fears in Contingency Planning

Healthy fear can be a strong motivator in ERP implementation. At the same time, fear should not lead to paralysis, leading an organization to not move forward with new systems.The right response is to address each of those fears in the project plan, in the form of contingency planning.

• Are you afraid you won’t have sufficient resources? Allocate budget to hire additional resources to back-fill the regular responsibilities of project team members. 
• Are you concerned that business users won’t adopt the new system? Develop and implement a change management plan as part of the implementation. 
• Are you worried that customer delivery might be disrupted? Allocate extra time in the acceptance testing phase to ensure that doesn’t happen. 

You can never completely eliminate risk in an ERP implementation. But with careful planning, allocation of resources, and management commitment you can greatly mitigate those risks.

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?