My reply was simple. I wrote:
Dear XXX, Unfortunately, I do not have current stats on implementation to license fee revenue. It is something we should survey, as we do get asked this a lot. I usually quote a range from about 75% to 200%, typically. But as you can imagine, discounts on the software license fees affect that, and also the extent of data conversion and interfaces/integrations and modifications. Also the amount of business change being introduced.A few moments later, I tweeted a short status update, "Chatting with a vendor about implementation cost to software license cost ratios." That triggered an interesting three-way discussion between Dennis Howlett, Martijn Linssen, and myself on the subject.
Martijn has already followed up in a blog post. In short, Martijn's position is that "there is a clear, direct and fairly linear relation between the initial cost of a product, and the additional cost(s) involved servicing it" [emphasis mine]
Not a direct relationship
I agree with Martijn that there is a relationship between the cost of the software and the cost of implementation. But I do not agree that it is a direct relationship. For example, if Company A pays more for SAP than Company B does, you can expect Company A will pay more for implementation. This might be because Company A has more users or is installing more modules. These factors will cause the software cost as well as the implementation cost to be greater for Company A. But what if SAP greatly discounts the software cost for Company A? Will that bring the implementation cost down for Company A? Of course not.
What drives implementation cost?
In fact, I have been in deals where software vendors have basically offered to sell the software at little or no cost. Does that mean the vendor or systems integrator will be willing to support the implementation for little or no cost? Of course not.
This thought experiment essentially proves that the relationship between software cost and implementation cost is not a direct relationship. There is no cause and effect. Rather, based on our ERP selection and ERP implementation project management experience at Strativa, we find that total ERP cost is affected by a number of factors.
First, there are two factors that affect both the cost of the software and the cost of implementation:
- Number of users. Software is often priced by the number of users. The number of users is also a factor in implementation cost, as more users generally means more user functions affected, more business processes affected, and more training required.
- Number of modules/amount of functionality. Similarly, software is often priced by the scope of functionality included. Software with more functionality is generally more expensive than software with less functionality. Likewise, implementing software that supports a broader set of business functions will cost more.
- Amount of data conversion or interfaces required. An organization that can implement the new system cleanly, without a lot of data conversion from the old system and without building interfaces to legacy or third-party systems, will get by with a lot less implementation budget than an organization that requires much data conversion or integration.
- Amount of business change required. An organization with well-defined business processes that conform to the business processes defined in the software will generally pay less for implementation than an organization that needs a lot of business process change.
- Skills and availability of the internal project team. An organization that has a well-formed internal project team with skilled resources will generally pay less for implementation than an organization that depends mostly on outside contractors to undertake implementation activities. (The organization with the well-formed team is also at less risk of project failure.)
- Choice of the implementation consulting partner. An organization that engages the help of a qualified systems integrator (or the vendor's own consulting arm, if so qualified) will generally spend less on implementation than an organization that chooses an SI with lesser skills or a poor track record in delivering services within budget.
"Complexity" of the software may be a factor
Finally, there is one other factor that is a wild-card, in my opinion. That is, the complexity of the software itself. This may or may not affect software license cost, but it often affects implementation cost.
This may be easiest to define with an example. SAP and Oracle are two well-know, so-called "Tier I" ERP systems. It is generally understood that these systems can support the largest, most complex, most geographically-dispersed organizations. They can support the widest number of industry sectors. They do this by incorporating a great deal of functionality for various industries, business processes, and local regulatory requirements. They are highly configurable. In other words, they are big pieces of software, or as I like to put it, they have a "big footprint."
This complexity comes with a price. It means that to make use of the system in a specific organization, many decisions have to be made during the implementation. These decisions cost time and money to configure the software and test it specifically for the organization's needs. This drives up the cost of the implementation.
SAP and Oracle are well-aware of this issue and have worked hard over the past decade to pre-configure their systems for specific industries and use cases. If a customer fits well into the vendor's pre-configured templates ("accelerators" in Oracle-speak, or "best practices" as SAP calls them), much of the complexity of the software can be hidden from view. Customers that fall neatly into the vendor's template can sometimes achieve very rapid and cost-effective implementations. Both vendors will gladly share references of such with prospects.
But don't the higher-end software packages still cost more than software targeted for small and mid-size businesses? This is not always the case. I have seen situations where SAP and/or Oracle were actually the low-cost bidders. In cases where a software vendor wants the deal, it is not safe to assume that the higher-end package will cost more. For this reason, I don't believe software "complexity" in itself is a consistent factor in either software license cost or implementation cost. As we consultants like to say, "it depends."
Popularity of implementation-to-license cost ratio
So, why do software vendors, customers, or systems integrators continue to use the implementation-to-license cost ratio? Because, as flawed as the ratio is, it does serve to set expectations as to implementation cost. To me, the ratio best works in hindsight. If a system implementation, on average, requires 1.5 times the software cost, a customer better not be assuming that it can do it for half the license cost.
But to really judge the prospective cost of an ERP implementation project, nothing beats doing a detailed estimate based on a realistic work-breakdown structure, with realistic estimates that take into consideration the factors outlined in this post.
Related posts
ERP implementation: plan for the worst
Epicor's Shared Benefits program: watch for unintended consequences
Revisting Epicor's Shared Benefits program
Oracle claiming ultra-fast installs in SMB market
5 comments:
Frank,
pretty fine post! I now get where you're coming from, and I agree on all your points. I've worked knee-deep with Siebel implementations for a long time and have watched Oracle and SAP implementations from the side, and your points are all valid
I also agree with the cost-estimation system although that is kind of like measuring a shoreline: the higher the detail, the longer it gets. Sometimes Sales talk to Architects and then decisions get made, and things go wrong a bit
Then again, that extra interface might cost a bit of functionality or drop a tab - there is a ballpark out there somewhere
Your discount is tricky as it drops the software price all of a sudden - I'm fairly sure that a lower software price [eriod would have another effect. Having said that, I'll see if I can round up some numbers on FLOSS and SF.COM
I'll swallow the 'direct' and replace it by 'not so very indirect at all' ;-)
Thanks for the conv and the post(s), I enjoyed it and came out the wiser
Martijn, thanks for the feedback, and thanks also for stimulating the discussion.
Thinking a bit more about this, the implementation-to-software cost ratio might work a bit better if one were to normalize it based on some common denominator, like number of users. I routinely reduce all software bids to per-user cost (I don't care how the vendor calculates it) and it is surprising how much vendors converge on a very narrow range of price-per-user.
If one were to adjust the software cost if it varied from that range (to eliminate outliers) the ratio might hold up better. On the other hand, one could simply calculate implementation cost per user and get the same result. But no one thinks that way.
Thanks again.
one other factor that can vary greatly is travel costs. If the vendor is in the clients back yard, has a branch office nearby, or implementers that are geographically diverse and use a home office, then travel costs (room, board, airfare, rental cars, parking, mileage, etc) won't be as high. Choosing a qualified vendor within a couple hour drive can allow for more face-to-face training sessions versus webinars and conference calls without driving costs too high.
Example: A small city purchases a new ERP that estimates 40 days of training with expectation that they will be live on all purchased modules in 1 yr. The vendor is based in a town 50 miles away. At that distance there will be much more flexibility for scheduling training, and hotel, airfare and some meals will be eliminated. A fair estimate of travel expenses in this case would be $2000 in mileage and $400 for lunches. I can easily assume that travel costs will come in under $3000.
Same city chooses a vendor 200 miles away. The Trainer would most likely drive. If those 40 days are broken up into 20 2-day sessions the estimate for expenses would be: $4000 in mileage, $3000 in hotels, $1500 in meals. We have now put our travel budget at $10,000 to be safe.
If the city chooses a vendor 500 miles away we now eliminate mileage and introduce rental cars and airfare. The scheduling also becomes much less flexible - So we do a week-long on-site session to start and then 10 2-day sessions mixed with 15 days of webinar trainings. Not only can we estimate our expenses going up -$5500 in airfare, $3750 in hotels, $2500 in rentals cars/gas/airport parking, $1250 in meals, so our travel budget now goes to $15,000 - but we also lose valuable face time with Trainer.
My company charges between $1000-1250/day for training x 40 days = $40,000-50,000. Add in conversion, interfaces, OSDBA, and some small customizations and I would think in this scenarion the Implementation (outside of travel) wouldn't be more than $80,000.
Further, this scenario only includes 1 Trainer... what if the Implementation requires 2, or because of glitchy hardware a Tech Support has to come out on multiple occasions to do configuration and trouble-shooting? Those travel costs can almost double. With this in mind I would certainly include "travel expenses" as another highlighed item on your list, as it can add anywhere from 5-40% to your Implementation.
Geoff, thanks for the extensive comment. I do agree with you that travel expenses should also be taken into consideration when estimating implementation costs. Many organizations do not realize what a difference it can make utilizing local resources versus implementation consultants that are more than a short drive away.
In addition, as you point out, the ability to schedule single days also provides flexibility, which may have a positive effect on cost management.
Thank you Frank for the post and insight. You know, There are several documented examples of ERP implementations that went over budget or did not hit the original go-live date. There are also many explanations out there to explain why these ERP implementations did not meet budget or timeline. Instead of repeating common information out in the ERP blogosphere, I would like to speak to a root cause that is typically overlooked by our industry – inaccurate ERP implementation estimations. In the next sections we will take a closer look at building a better ERP estimate.
http://gbeaubouef.wordpress.com/2012/07/04/building-erp-estimates/
Post a Comment