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:

1. Number of employees: 100
2. Number of named users: 20
3. Upfront costs (licenses, customization, training, and implementation): $20,000
   or, $1,000 per user
   
4. Hardware and operating system (Dell and Microsoft): $3,800
5. On-going support from Compiere partner: $12,000/year
   or, $600 per user
6. On-going support as percentage of upfront costs ($12,000 / $20,000): 60%
   

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.

Related posts
Compiere's open source ERP business model and growth plans
Open source ERP gaining adherents
Why organizations choose open source software
Build/buy pendulum swinging back toward build
Key advantage of open source is NOT cost savings
Open source: turning software sales and marketing upside down
Open source ERP
Buzzword alert: "open source"

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

1. Trying to make the new system work just like the old system
2. Rushing the implementation to satisfy unrealistic schedule expectations
3. Expecting the IT project manager to represent business users as well as IT
   
4. Underestimating the complexity of data warehouse projects
   
5. 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.

Read the whole article.

Related posts
Philly pulls plug on failed Oracle project
Project management: the missing discipline