Friday, August 27, 2010

Oracle Apps User Survey now live

Our new survey for users of Oracle Applications is now online.

If your organization is a user of ANY of Oracle's applications systems--whether E-Business Suite, JDE, PeopleSoft, Siebel, or others--please help by taking this easy 10-minute survey.

The survey is to solicit the views of Oracle customers on several "hot topics," such as Oracle's maintenance and support programs, Fusion Apps, and the Sun acquisition.

Take the Oracle Applications User Survey Now >>

What's in it for you?
A free copy of the final report, which will otherwise only be available to Computer Economics subscribers or to those who purchase the report.

Only IT professionals directly involved with Oracle Applications should participate in this study. If you are a software vendor, VAR, reseller, or consulting firm, please feel free to forward this request to any Oracle customers you know.

If there is someone within your organization more qualified to take this survey, please feel free to forward this request to them.

Thank you in advance!

Tuesday, August 24, 2010

Calling all Oracle Apps customers

I'm getting ready to launch a short survey for Oracle Applications customers. If your organization is a user of ANY of Oracle applications systems--whether E-Business Suite, JDE, PeopleSoft, Siebel, or others--please let me know if you'd like to respond to the survey. It should take less than 10 minutes. My email address is in the right-hand column.

What it's about. We are interested in the views of Oracle Apps customers relative to several "hot topics," such as Fusion Apps, Oracle's maintenance and support, and the Sun acquisition. We will use this information to prepare a special report to be published by Computer Economics.

What's in it for you? A free copy of the final report, which will otherwise only be available to Computer Economics subscribers or to those who purchase the report.

Only IT professionals directly involved with Oracle Applications within their organizations should participate in this study. If you are a software vendor, VAR, reseller, or consulting firm, please feel free to forward this request to any Oracle customers you know.

If there is someone within your organization more qualified to take this survey, please feel free to forward this request to them.

Monday, August 23, 2010

Factors that affect ERP implementation cost

The CEO of a small software vendor contacted me last week with a simple question. Did I know of any recent research that provided typical ratios for Tier II ERP implementation cost to software license cost? He didn't say why he was asking, but I assume it was in order to position his own customers' experience against some sort of industry benchmark.

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.
In addition, there are several other factors that affect implementation cost but do not generally affect software license cost. These include the following:
  • 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.
There are other factors as well, such as the degree of standardization of business processes among multiple facilities and the organization's track record in managing cross-functional business change projects.

"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

Thursday, August 12, 2010

ERP implementation: plan for the worst

Chris Kanaracus, always on the lookout for lawsuits and regulatory filings related to enterprise software, spotted this case study today: a company that was forced to delay reporting of quarterly results due to problems with a newly installed ERP system.
VAN NUYS, CALIFORNIA -- August 11, 2010 -- Superior Industries International, Inc. (NYSE:SUP) today announced that it is postponing the release of its financial results for the second quarter and year-to-date periods ended June 30, 2010, and its earnings conference call originally scheduled for today, Wednesday, August 11, 2010. The postponement is the result of delays in finalizing the quarter financial close due, in part, to the recent implementation of a new Enterprise Resource Planning (ERP) system. Superior is working diligently to finalize its second quarter results and will provide new dates and times for the earnings release and earnings conference call in a forthcoming news release.
Chris provides further details:
The problems were primarily due to closing a quarter for the first time with the ERP system, along with changes to Superior's legal structure in Mexico, it added.

The company recently implemented a product from QAD, CIO Ross Perian said in an e-mail. He did not respond to requests for further details on the project, which went live on March 29, according to another SEC filing.
Fortunately, according to Chris, it appears that only a five day extension will be necessary. And it pales in comparison to some of the catastrophic ERP failures reported over the past decade.

My take
There are several unanswered questions, and several take-aways from this mini-case study.
  • According to Chris's digging, the new system went live on March 29. That's over four months ago, more than one quarter. How did the firm manage to close the previous quarter? Or, was it running the old system in parallel for purposes of financial reporting?

  • The firm had four months since it went live on the new system to test the quarter-end close routines. Did it do so? If so, what were the results? Did it have any forewarning that there were problems? I have personally witnessed QAD implementations that took less than three months. Four months in QAD-land is a long time. What was the project team doing during this time period?

  • Was there a contingency plan? Did anyone ask and answer the question, what will we do if the new system can't close the quarter?

  • QAD's MFG/PRO is a mature product. The financial close routines should simply work. Did the firm modify the vendor's source code or make other non-standard configuration changes to the system?
  • Finally, if I were the top executive, I'd be asking some tough questions about the new system's readiness to close out the fiscal year.
I don't mean to pick on Superior or QAD in particular. The fact that only a five day extension appears to be required is a good sign that the project team was not far off from success. Still, this is a publicly-held company, which doesn't need these sort of SEC filings.

Our latest Technology Trends study at Computer Economics this year shows that, among 19 technology investments, ERP is among the most risky IT initiatives. Yet, we've had 20+ years to learn how to do it right.

Unfortunately, it seems we keep learning the same lessons over and over again.

Related posts
Philly pulls plug on failed Oracle project
What went wrong with HP's SAP migration?
Four problems with ERP
Solving the four problems with ERP