Enterprise System Spectator blog: ERP and enterprise system vendor evaluation, selection, and implementation.

The Enterprise System Spectator

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!

by Frank Scavo, 8/27/2010 12:20:00 PM | permalink | e-mail this!

Subscribe!

Read/post comments!
(0) Links to this post

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.

by Frank Scavo, 8/24/2010 01:39:00 PM | permalink | e-mail this!

Subscribe!

Read/post comments!
(0) Links to this post

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 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

by Frank Scavo, 8/23/2010 09:36:00 AM | permalink | e-mail this!

Subscribe!

Read/post comments!
(5) Links to this post

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

by Frank Scavo, 8/12/2010 01:40:00 PM | permalink | e-mail this!

Subscribe!

Read/post comments!
(1) Links to this post

Powered by Blogger

(c) 2002-2014, Frank Scavo.

Independent analysis of issues and trends in enterprise applications software and the strengths, weaknesses, advantages, and disadvantages of the vendors that provide them.

About the Enterprise System Spectator.

Frank Scavo Send tips, rumors, gossip, and feedback to Frank Scavo at .

I'm interested in hearing about best practices, lessons learned, horror stories, and case studies of success or failure.

Selecting a new enterprise system can be a difficult decision. My consulting firm, Strativa, offers assistance that is independent and unbiased. For information on how we can help your organization make and carry out these decisions, write to me.

For reprint or distribution rights for content published on the Spectator, please contact me.


Go to latest postings

Custom Search

Join over 1,700 subscribers on the Spectator email list!
Max. 1-2 times/month.
Easy one-click to unsubscribe anytime.

Follow me on Twitter
My RSS feed

AddThis Feed Button


Computer Economics
ERP Support Staffing Ratios
Outsourcing Statistics
IT Spending and Staffing Benchmarks
IT Staffing Ratios
IT Management Best Practices
Worldwide Technology Trends
IT Salary Report

Get these headlines on your site, free!


Awards

2013 Best ERP Writer - Winner

Alltop. We're kind of a big deal.
 
Constant Contact 2010 All Star Technobabble Top 100 Analyst Blogs


Blog Roll and Favorite Sites
Strativa: ERP software vendor evaluation, selection, and implementation consultants, California
StreetWolf: Digital creative studio specializing in web, mobile and social applications
Vinnie Mirchandani: The Deal Architect
Si Chen's Open Source Strategies
diginomica
CISO Handbook


Spectator Archives
May 2002
June 2002
July 2002
August 2002
September 2002
October 2002
November 2002
December 2002
January 2003
February 2003
March 2003
April 2003
May 2003
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
July 2008
August 2008
September 2008
October 2008
November 2008
December 2008
January 2009
February 2009
March 2009
April 2009
May 2009
June 2009
July 2009
August 2009
September 2009
October 2009
November 2009
December 2009
January 2010
February 2010
March 2010
April 2010
June 2010
July 2010
August 2010
September 2010
October 2010
November 2010
December 2010
January 2011
February 2011
March 2011
April 2011
May 2011
July 2011
August 2011
September 2011
October 2011
November 2011
December 2011
January 2012
February 2012
March 2012
April 2012
May 2012
June 2012
July 2012
September 2012
October 2012
December 2012
January 2013
February 2013
March 2013
May 2013
June 2013
July 2013
September 2013
October 2013
December 2013
January 2014
February 2014
March 2014
April 2014
May 2014
June 2014
July 2014
August 2014
September 2014
October 2014
Latest postings