Survey Results are in for ERP Implementation Strategies

 

It has been a very busy 1st quarter closing and I have not been able to post an article in a while. I cannot really explain the business activity other than to recognize that there is a “business cycle” and despite stimulus packages or not, our economy was going to emerge from the recession sooner or later. From the depths of the economic woes, it appears the economy is emerging later rather than sooner. There is a pent-up demand out there, for example durable items still have a tendency of wearing out and needing to be replaced. As far as software licensing and the consulting agreements needed to implement the software, procurement departments had been under a short leash, but projects are starting to come online.

In the interim, Houston Neal, Director of Marketing at Software Advice, has collected all the results of his survey on the ERP Implementation Strategies in use and presented them in an updated version of his article entitled ERP Implementation Strategies – A Guide to ERP Implementation Methodology (see my posting in this Blog immediately below). The results may be of interest and assist in your decision making process and which path to take. Neal has also inserted an interesting commentary section from the respondents claiming their implementation failed. Here is a quick glance at those results from the 45 respondents:

“Of those that answered “No,” we received the following comments:

“Logistics problem (visa issue delay, user delay for data collection, delay in top management support).” – Phased Rollout

“We are still under the progress of phased manner, only “Materials and Finance” is under parallel run and they’re facing some bugs/modifications.” – Parallel Adoption

“Still running both systems in parallel, 3 years later!” – Parallel Adoption

“1 year late, although all other success parameters achieved.” – Big Bang

“Concentrating on tools not architecture.” – Big Bang”

 

ERP Implementation Strategies

 

Houston Neal, Director of Marketing at Software Advice, is conducting a survey on ERP implementation strategies. Specifically, which implementation strategy (big bang, phased rollout, or parallel adoption) has the best success rate.

You can find the survey in his article entitled ERP Implementation Strategies – A Guide to ERP Implementation Methodology.

Licensee's Bill of Rights by Forrester's R. Ray Wang

 

 

So I’m sitting at my desk buried in work one day last week. As an aside, it appears that my writings on SaaS have sparked some interest and so I have been putting together some SaaS agreements for a couple of new clients. My email alert lets me know that an email has just arrived. It is an email from R. Ray Wang, Vice President of Forrester Research Inc. I have been reading a lot of Wang’s writings and research and have been quite impressed to say the least. I have even Blogged on some of his writings. He had a few kind words to say about my Blog and then he attached the latest update to the Enterprise Software Licensee’s Bill of Rights. I promised him that I would read this latest research work and mentioned in my email reply that it would probably be a treasure trove of vital and current information. Well I did read it and my comment hit that nail on the head. As a practitioner for over 20 years, with the last 10 years concentrated in this crazy world we call software licensing, this is a must read. As a Licensee, whether prospective or a veteran of ERP negotiations, perhaps a higher standard is in order, such as mandatory reading material. Here are some highlights from this latest work as detailed by R. Ray Wang:

  1. Surveyed 71 vendors and 101 end users.
  2. Built best practices from personal experience of 1000 contract strategy interactions.
  3. Resulted in the inclusion of 11 new rights that support new deployment options, cost savings, client best practices, and vendor lock in avoidance.
  4. Suggested seven simple steps to successfully negotiating enterprise software contract.

Of course reproduction of this research work is strictly prohibited. Regardless of the prohibition, space constraints in this Blog prevent me from adequately commenting on all the salient points. I do not think Wang or Forrester would mind if I whetted your appetite the best way I know how – with Wang’s own words in the Executive Summary.

For Business Process & Applications Professionals

Executive Summary 

July 7, 2009

 

An Enterprise Software Licensee’s Bill Of Rights, V2

 

Forrester Redefines 47 Basic Rights That Licensees Should Expect From Vendors

 

This is the 10th document in the “Building A Long-Term Apps Strategy” series.

 

 

by R “Ray” Wang

with Paul D. Hamerman, Andrew Magarie, and Ralph Vitti

 

 

“Of all the assets that an enterprise acquires, enterprise software brings with it the most unusual, onerous, and restrictive set of constraints. In most cases, licensees may not resell, reuse, or share their license. Licensees often encounter numerous grievances across the software ownership life cycle from selection to implementation, utilization, maintenance, and retirement. Poor economic conditions have kept vendors from raising prices for now; however, rapid vendor consolidation has eliminated choice and customer leverage in the market. Upon economic recovery, enterprises can expect price increases in software categories where only a handful of solution providers compete. Fortunately, advances in new deployment options (e.g., software-as-a-service, platform-as-a-service, cloud computing, managed services, and virtualization) may slowly shift the pendulum in favor of the customer. Forrester’s updates to its 2006 Enterprise Software Licensee Bill Of Rights (LBoR) reflect these new best practices from more than 1,000 interactions. CIOs, business process and apps professionals, enterprise architects, and procurement experts should immediately review and incorporate these best practices into their vendor relationships, contract strategies, and packaged apps strategies.”

 

 

For information on hard-copy or electronic reprints, contact Client Support.

 

R. Ray Wang’s Blog is A Software Insider’s Point of View.

  

How To Protect Maintenance Revenues During the Recession

The recession is upon us and from all reports it looks as though it is going to be a long one. I will leave to others to discuss and argue if the current proposed stimulus package is indeed a real stimulus package or just a spending bill that will do little to nothing in the short term. In my practice I am beginning to receive an inordinate number of requests from software licensee’s to either cancel maintenance or reduce user counts in an effort to lessen the annual expense. Chris Dowse and Ben Galison have written a very important Op-Ed piece for SandHill.com entitled Software’s Clear and Present Danger. They begin their article with a no nonsense approach to the subject of maintenance revenues:

“… the software industry’s cash cow, maintenance and support revenue provides high margins that are the funding engine for new product research and development. The maintenance revenue stream is also used as a basis for company valuations in mergers and acquisitions and financing arrangements.”

Dowse and Galison have identified three major reasons placing downward pressure on the maintenance stream:

1.       The customer’s perception of value has affected pricing, the basis for the maintenance calculation.

2.       The recession has caused customers to postpone purchases and upgrades.

3.       End User Monitoring (“EUM”) has created a new view into usage and so under-used applications are being targeted as a drain on ROI.

The approach that Dowse and Galison suggest as a remedy to the threat on the maintenance stream might seem simplistic at first blush. They suggest the Independent Software Vendor (“ISV”) become more customer-centric and strive to have a successful adoption of the software suite as opposed to the traditional implementation services. I suggest you read further and examine their three step approach and follow it in the sequence they suggest. It may be a bit of a paradigm shift for some ISVs, but at the very least it will take a lot of effort. I will try to summarize the three step approach, but please read their whole article to get the full impact. The three step approach is as follows:

1.       Create a Positive Customer Experience: This enhances customer loyalty which is the first step in protecting the maintenance stream. However, more importantly, Support and Services must concentrate on an effective adoption of the applications. A significantly improved customer interaction of the delivered applications can have a direct and positive impact on the customer’s ROI. This should also eliminate the fragmentation that occurs when their customer information gets locked in silos. An effective adoption of the software suite should enable delivery of this customer information across the enterprise. The ISV must encourage cross-functional dialog and empower their employees to identify their Customer problems.

2.       Understand Customer Usage: This has to be a proactive approach, hence my comment above that “at the very least it will take a lot of effort”. The ISV must strive to understand usage patterns and barriers to adoption. This is where the ISV should take advantage of the new EUM technology and use it to get past the reasons for downward pressure on maintenance. Once usage rates are indentified the ISV should intervene with perhaps more training or services. This activity could lead to new products and services to increase usage and eventually ROI.

3.       Deliver Business Value, Not Just Technical Service: Customers want and will pay for services that will lead to effective adoption. Traditional implementation services do not go far enough. Placing the focus on user adoption yields tremendous benefits. Dowse and Galison state it best: “Effective user adoption increases customer switching costs, enables value-based pricing that prevents price erosion, produces visible ROI for customer success stories to drive other sales, and provides a platform for upselling and cross-selling.” Another by-product of this approach is a lower amount of the lower margin traditional implementation services required.   The ISV’s service profitability should go up.

For another perspective on this topic see my November 24, 2008 post in this Blog: How to increase revenue in an Economic Downturn.

 

Checklist: Preparing for the Master Service Agreement

 

I have stated in an earlier article, Checklist Before Outsourcing Your IT, the high value I place on the use of a checklist before drafting an agreement. It is also obvious that a tool such as a checklist can provide invaluable assistance to the IT Project Manager when preparing for the implementation of a newly purchased software suite. In my research I have found a very interesting article in Wisconsin Technology Network News, WTN News, by Richard Marcus entitled Six things to consider before a major software implementation. Marcus presents a very useful list in his March 2006 article. Admittedly this article is over 2 years old and in this fast-paced high-tech environment the concept of what is “new” and what is “old” takes on different meanings from our traditional understanding of the terms. However, I believe his advice stands the test of time regarding this subject matter.


Marcus begins his article by cautioning the buyer on the critical nature of the purchase and that concentrating solely on the pricing could be a perilous mistake. He then provides his six points that the purchaser should take into account before forging ahead with the implementation. A brief synopsis of these six crucial points is as follows:

 

  • The Software Vendor and the Customer are partners in this undertaking. Both parties must bring their knowledge and skills together in a committed relationship. Success depends on having sufficient resources. The Vendor should already have their team ready and the customer should have a comparable team prepared to spend the estimated time needed for the project. See also the February 15, 2008 post to this Blog, The IT Worker Shortage: Practical Considerations for Tech Buyers

 

  • Communication is key. Insist that the Vendor set the correct expectations. Talking is not the only art form in this communication process. Listening is essential. Ask questions and let those answers lead you to more questions. Strive to learn not only what the software can do, but also what it cannot do. In the past, I was a consultant for a large software vendor. As a newbie on one of my first implementations, I learned the catchphrase consultants were often overheard to say to the customer when discussing the software’s capabilities, “The salesman said it could do what?” Make sure your requirements are well known and can be met.

 

  • Pricing. Marcus’ admonition above is still valid. Price is not the only factor, but it is still a factor nonetheless. Negotiate a payment schedule that is tied to clearly defined and identifiable milestones that are realistic. Holdbacks dependent on successful acceptance test results should be discussed and inserted into the contract. Too much money upfront surrenders too much influence to the vendor. I was interested to read that Marcus warns the reader not to be swayed by the software vendor’s pleas and worries about revenue recognition. In my career I have discussed this many times, but only in a software license agreement negotiation. A Master Service Agreement is usually a time and materials agreement and hence revenue can only be recognized as it is earned. A Fixed Fee arrangement is a totally different case and will be a topic for a separate post to this Blog.

 

  • A separate Master Service Agreement should be drafted. Marcus points out that it is common for the license agreement itself to contain sections pertaining to services such as ongoing support and maintenance. However, these services are not directly related to the implementation. I have come across license agreements that purport to contain the implementation services section within the license. This should be avoided. His article deals with a major implementation and so most major software developers and vendors already have their contract model set up to have a separate license agreement and a separate Master Service Agreement. This is the preferred approach. An implementation section contained within a license agreement may not address all the salient points of an implementation and also may not be clear and unambiguous on other necessary elements.

 

  • The Master Service Agreement should contain Service Levels. This is a very important item and one that should not be overlooked. A service level agreement (“SLA”) can take the form of a separate schedule attached to the license agreement. Alternatively and depending on the complexity of the requirements of the customer, a separate SLA may be more appropriate. In the SLA the customer should make certain that all of its requirements that were fleshed out during its communications with the software vendor (see point 2 above) are memorialized for future reference.

 

  • Know the use limitations in the license and plan accordingly. Many software licenses are User based pricing. Many vendors are willing to provide some form of price protection for future purchases of users. The Customer should verify that no further implementation work will be needed if more Users are added. However, if the Customer is faced with product based pricing and is not purchasing the entire software suite of products, then further implementation work will be needed if more products are added. This possibility should be fully explored and the consequences understood in the event of future growth.

Marcus concludes his article by stressing that the Customer must do their due diligence on the front-end. With proper planning the Customer can avoid mission-creep and other costly mistakes. Once a major implementation is set in motion it becomes cost prohibitive to put a complete stop to it or redirect your efforts towards another project.