The Enterprise System Spectator

Wednesday, August 29, 2007

Total cost study for an open source ERP project

Baseline Magazine has an interesting case study on PerTronix Performance Products, of a small manufacturing firm that implemented the open source ERP system, Compiere. What's interesting is that the article reports the specific costs that the company incurred for the open source implementation. Thus, it provides a useful comparison with the typical costs for proprietary ERP systems.

Here are the metrics reported for PerTronix's open source ERP implementation:

Now let's look at these metrics in light of a typical implementation of a proprietary ERP system:

The up-front costs really stand out as exceptionally low: $1,000 per user is about one-fourth of the typical cost of a proprietary ERP implementation. For planning purposes, I generally assume about $2,000 per user for software, plus at least one times that for implementation, or $4,000 per user--usually more. Of course, the fact that there is little if any software license cost is a major driver of the low cost advantage of open source, here. (The article does mention "license costs," indicating there may have been some proprietary extensions of Compiere as part of the deal here--the article doesn't say. But whatever they are, they couldn't account for much of the upfront costs.)

The $600 per user for on-going support is only somewhat higher than that for proprietary ERP, which generally runs about 20% of the initial license fee. Assuming an initial license fee of $2,000 per user, a proprietary ERP system would generally cost about $400 per year in maintenance fees, which cover software patches and help desk support. The $600 per user figure is certainly not out of line.

Because Compiere is running on low-cost hardware and a Windows operating system, these costs are quite low, although many proprietary ERP systems, especially packages written for small and mid-size firms, run on this platform. So, we cannot point to an advantage for open source here.

So the major difference in cost between open source ERP and proprietary ERP lies primarily in the up-front cost. The on-going support costs are similar, which is not surprising, since those costs are largely driven by the cost of labor.

One might also point out the advantages of open source in terms of flexibility. If the lead development organization, Compiere Inc., goes out of business, PerTronix still has rights to the source code. If the Compiere implementation partner raises its support fees, PerTronix can go look for another, or it can hire its own support technicians. There is no vendor lock-in.

The article also discusses the benefits of the new system, which include centralizing of order processing and inventory management across multiple facilities, productivity improvements, ability to implement price revisions more frequently. But we can assume that those benefits would have been realized from a proprietary software implementation as well. Therefore, the real difference between an open source ERP system and proprietary software stand out more on the side of cost and flexibility.

Is open source ERP the right solution for all companies? Definitely not. These products, such as Compiere, Open For Business (OFBiz), ERP5, Tiny ERP, are still small in scale. Although they may have strong functionality in a few areas, they lack the overall breadth of features of established proprietary offerings. This is why there is almost always customization involved in the implementation.

But open source operating systems (e.g. Linux) and application platforms (e.g. Apache, JBoss), were once minor players as well, and today they have significant market share. In the case of Apache, it is the market leader. Open source is moving up the technology stack to business applications. Whether it can gain significant market share remains to be seen. ERP systems are much more specialized than operating systems and application platforms. It is not clear to me whether there are sufficient populations of developers to gain critical mass for these products, as there has been for products lower in the stack.

Who should consider open source ERP today? In my opinion, these solutions today are not so much an alternative to proprietary software as they are to custom development. An organization that knows it will need to do significant customization or enhancements to an ERP system should consider open source as a starting point instead of proprietary ERP. Organizations with unique requirements or unusual business models may be in this category. Modifying core code of a proprietary ERP system generally voids the warranty and makes on-going support less relevant, since the vendor will not support your custom modifications. Why not start, then, with open source ERP, where there is little if any charge for the source code? To me, that's a better choice than to start with 100% custom development.

I'm looking for more cost metrics on open source ERP implementations. If you're willing to share them with me, let me know.

Friday, August 10, 2007

IT project management lessons learned, and re-learned

Liam Durbin, CIO at GE Fanuc Automation, writes in CIO Magazine about one of the most important lessons learned in IT project management--the need for strong leadership from the business side.

I took my current position on the heels of such a hard lesson. Our software business was the scene of the crime for our disastrous CRM implementation. Inside sales team was bleeding badly from several deep wounds and a thousand paper cuts. Channel partners were revolting. Activities that used to take minutes, like placing an order or checking availability, now could take half an hour. The system was bouncing frequently. The IT team was releasing a Siebel recompile every other day.

The root cause of the problems? A lack of strong functional leadership on the project. To emphasize this lesson, Durbin points out five scenarios where IT projects fail from lack of functional business leadership (in my words):

Expecting the IT project manager to represent business users as well as IT

Underestimating the complexity of data warehouse projects

Having multiple functional leaders instead of a single commander

It's not that IT executives don't realize the need for engagement by functional leaders--it's that they too often forgot or compromise "just this one time." They know what's right, but they don't stay strong in the face of false assumptions or unrealistic expectations.

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.

My IT research firm, Computer Economics provides metrics for IT management, such as IT spending and staffing benchmarks, technology adoption and investment trends, IT management best practices, IT salaries, outsourcing statistics, and more.