Selecting ERP Software – Best Practices – When the budget is too low

So you read my posts on budgeting…and you came away thinking, “He’s too high! We can do it for less!” And you just might be able to do it for less. But before you try, let me relate a true story…this happened to one of my clients about 5 or so years ago. They aren’t the only story I could tell…

A Budget Too Low

The easiest way to explain this is to tell you about my client…I’ll call them E-Corp (hey, if you watch the TV series Dr. Robot, you might know them…not really)

E-Corp set a budget of $150,000 for their software. They needed a lot of software. 40 or so users. Warehouse management. EDI. …and they had a huge need for customization…

You see, the software they had was developed in-house, and they knew they wouldn’t find anything that did exactly the same thing…and the programmer retired…and then the Controller who knew what the software did announced his retirement…

I told E-Corp that $150,000 was too low….but they insisted on that budget…even though I encouraged them to double or triple it...

The last time I talked to E-Corp, they had spent over $400,000..and still weren’t through!

What Happened?

E-Corp started with a list of potential software vendors. They sent them a rough RFP and asked for proposals. Several vendors whose products I knew didn’t respond. The client asked me, “Why?” I said, “Your budget is too low; I wouldn’t have responded either. You aren’t acting serious about this.” 

But because they got a response from a SAP dealer (BusinessOne), they thought they’d go forward. They did demos and discovery. They specified customizations. They drank the Kool-aid, as they say. And then came the proposal. $288,000. The client called me to check the proposal. “Can you help us get it down?” I reviewed it.

“This proposal is too low,” I said. “The fees are all estimates. You’ll never finish the project for this. The fee to product ratio is 50%, and you have data conversion AND extensive customizations.”

“What does the budget need to be?”


They told themselves (and me), “We have the technical ability to get this done for this price.” Only one of us believed them. It wasn’t me.

I told ’em so

The last time I talked to them, they had implemented the software for 2 of 5 business units (the easy ones), and they had spent $400,000 and were two years over schedule.

I can only tell you the truth. I can’t make you believe it.

Selecting ERP Software – Best Practices – Setting the budget

In the last post, I gave you some rules of thumb about software cost. In this post, let’s see if we can come up with a budget for a software implementation.

What you need to know (or estimate)

Before you calculate a budget, you’ll need to answer a few key questions:

  • How many users will you have? I suggest that you count or estimate two different user counts (which might be the same). First, the concurrent user count. That is, how many people will need access to the system at one time. The easy way to estimate this is to count the people that will use the system all day, every day. Then list the people who will use the system only some of the time. You’ll have to decide how many of the “some time” users will be using the system at any one time. One helpful question in the past has been, “Suppose some of our users can’t get on the system (because we are out of users). What is the business effect? The second user count will be named users. A named user is someone who needs a login in the system. The named user count will always be at least equal to the concurrent user count, usually more.
  • Will you convert data? If so, what kind and how much? We divide data into master file data, beginning balances, open documents, and history. Master files are things like customers, vendors, and inventory items. Beginning balances are open payables, open receivables, general ledger balances, and item cost and quantity. Open documents are things like sales orders that have not been shipped and invoiced, or purchase orders not received. History is…well…history. Things like past purchase history (what the customer bought last month or last year), what items were ordered from vendors. Our recommendation is that you keep the old system up and running for a year or two and access history from there.
  • Is the data to be converted both clean and easy to get? If your data is in Microsoft SQL Server, and you constantly clean up customers and vendors, the answer is “Yes.” If you’re using an old system that you’ve had for 20 years, have lots of history, and will need help to extract the data, the answer is “No.”
  • Do you need anything outside the scope of the pricing discussed in the last post? This would be features like manufacturing, service, point of sale, etc.

Looking  for a budget not a price

Before getting into the calculations, let me emphasize that we’re looking for a budget, not a price! Just because we set the budget for the wedding dress at $5,000 does not mean that we have to spend $5,000. We might spend only $1,000. But here’s the key point: I use a budget to eliminate products in the very first step of a selection process. If the vendor can’t tell me that they can deliver a solution within budget, they’re history.

This means that it’s important that the budget be reasonable. And that’s what this calculation will give you. Next post we’ll discuss what happens when the budget isn’t reasonable.

Setting a rough budget

This method is based on two observations about software projects. First, the more users there are, the more implementation is needed. Second, the more users, the more complexity that tends to be introduced into the implementation. This means that in most cases, the more the cost of the on-premises software, the more complex the implementation, data conversion, and customizations will be. And that assumption is what this formula is based on.

This isn’t a quote, and I can’t guarantee that you can implement a system for this amount, but here’s a reasonable budget formula:

  • If you need anything outside the scope of the features in the last post, use the amount $3,500 per user for on-premise software or $225 per month per user for cloud software. Otherwise, use $2,500 for on-premise software and $150 per month per user for cloud software.
  • Multiply the on-premise software number by the number of concurrent users. So if you have 10 concurrent users, you would either calculate $35,000 or $25,000 depending on the features you need. This number is the base number for calculating data conversion, implementation and customization.
  • To determine your data conversion budget, take this figure times 50% if you convert master file and beginning balance data only. Multiply by 75% if you convert open documents. Multiply by 150% if you plan to convert history.
  • To determine your implementation budget, take this figure times 75% if you think you’ll need very little help, 125% if you think you’ll need some hand holding, and 150% if you plan to redesign processes for the new software.
  • To determine your customization budget, multiple this figure by 25% if you just need a couple of reports designed. Multiply by 75% if you think you’ll need to change the way the software works in minor ways. Multiply by at least 100% if you expect to need extensive customization.

If we plan to convert master files and beginning balances, we need some hand holding, and we don’t plan to customize anything other than a couple of reports, we can come up with a budget. So, here’s how the base calculation would work for 10 users of the basic distribution software we discussed in the last post:

One of these:

  • Software budget (on premises): $25,000 ($2500 x 10 users) OR
  • Software budget (Cloud): $1,500 per month


  • Data Conversion: $12,500 ($25,000 x 50%)
  • Implementation: $31,250 ($25,000 x 125%)
  • Customization: $6,250 ($25,000 x 25%)


On-premise: $75,000

Cloud: $50,000 plus $1,500 per month.


Selecting ERP Software – Best Practices – Setting the budget

The first thing many companies do is decide on the budget for a software project. At a high level, I mean; round figures like $5,000, $50,000 or $500,000. That’s a good place to start. But how do you set a budget? Should you go high, low, or reasonable?

Software budgets based on industry surveys

Before we even talk numbers, we need to set the scope. That is, we need to know what we’re talking about in terms of software. Let’s pick something fairly common: distribution or wholesale software. That would include accounting (general ledger, accounts payable, and accounts receivable) as well as operations (inventory, order entry, and purchase orders). For basic, mid-range software you can generally expect to invest between $2,000 and $3,000 per user for software. I’m not talking about the low-end stuff that leaves out a lot of features like pricing, serial numbers, or multiple warehouses. I’m talking about the baseline features that almost every reasonable contender in the mid-market has.

So let’s pick the middle of this range as the price: $2,500 per user. But that’s for software purchase (buying the software). And there will also likely be an annual fee to the software provider for upgrades and maintenance. But what about software in the cloud?

Cloud software pricing

Cloud software pricing is all over the place. Most mid-market solutions run in the range from $125 to $200 per user per month. That includes the infrastructure (Windows, SQL Server, setup, security, etc.) as well as the software license. It can be more; it can be less. This is a decent range. And it usually includes the software maintenance; sometimes it includes upgrades.

What else should be included?

The numbers above include only software (or in the case of the cloud, software plus what you need to run it). There are three other items you’ll want to consider in your budget:

  • Data conversion. This is the cost of moving data from your current system to the new system. For some things like inventory items and customers, it can be pretty simple. For other things  like order history, it can be very difficult. Getting the data into the new software and getting it out of the old software are often straightforward. Cleaning up the data from the old system is where much of the effort lies.
  • Implementation and Training. Implementation is picking the right options and setting up the right processes to make the software work in your business. It also includes the technical setup of the software. Training is for the people who will be using the system.
  • Customization. Depending on the software and how your business runs, you may need customization. This could be as simple as creating a couple of reports. It could be as complex as developing major features for your system.

Industry surveys have shown that these three components generally run from 1 to 4 times the purchase price of the software. Data conversion and customization tend to increase the cost.

Can you do it for less?

Yes, it can be done for less. We have developed a system that can substantially reduce the investment in implementation. However, for most mid-market systems, companies will at least need an employee with recent experience in implementing ERP software.

In the next post, we’ll discuss the importance of setting a reasonable budget.


Selecting ERP Software – Two Critical Keys to Selecting the Right Software

(I generally don’t like RFPs for software because they never seem to produce responses that can be evaluated apples to apples, but I talk about RFPs in this post because people are familiar with them. What I recommend is a “Process and Requirements Document.” We’ll get to that in a later post.)

When I see a typical RFP for ERP software, it usually begins with something like, “ability to define chart of accounts,” “GAAP-compliant financial statements,” etc. Don’t get me wrong, these are important criteria. The problem is that most software packages from the bottom to the top of the market meet these requirements. An RFP needs to pay primary attention to two critical key areas:  feature coverage and unusual requirements.

The Concept: Common software features are not selection criteria.

The easiest software choice is for a company that needs basic features that all ERP software has. I’ve seen companies do elaborate RFPs for general ledger and accounts payable systems. They needed to print financial statements, documents required for accounting, track accounts payable and print checks. Every system I’ve seen from QuickBooks to SAP has these features. It doesn’t matter which system the company chooses, any one will do.

Of course, no company (particularly yours) has needs this simple. But many RFPs include mostly these types of requirements. These requirements are not going to help make a decision on the right ERP system for your company. If you feel that you need to state these requirements, put them in an appendix as a checklist. Then refer to them in the selection document. So what should you focus on in the body of the RFP?

Feature Coverage: The ticket to get in the door

The first thing you need to cover with software vendors–right up front–is the general list of features or functions that you need in the software. In the old days, we might have called these “modules,” but I mean something a little different. So let’s assume that you make toothpaste (process manufacturing). You’ll need at least basic accounting (G/L, A/P, A/R, maybe P/R). You’ll need inventory, purchasing, and sales orders. These things you’ll find in most products (see section above). I would generally summarize these to “basic accounting, inventory management, sales and purchasing.” You’re also going to need some other features, I suspect. It’s these other features that you should focus on in the feature coverage section. Manufacturing recipes (BOMs), shop floor control (if needed), production reporting, work in process, MRP, scheduling, etc.

These features form the “first cut” in selecting software. If you need a feature and the ERP software you’re evaluating doesn’t have it, mark it off the list without further ado. Don’t spend time watching demos of software that doesn’t have the features you need. By the time you get to the demo stage, watching demos will get tiring. More about that later.

So let’s say that by applying your feature coverage needs, you get to a dozen packages that you think might meet your needs. What now?

Unusual Requirements (that aren’t necessarily unusual to you)

Once you weed out the packages that don’t have the feature coverage you need, you should focus on requirements that not all software packages have or that you suspect not all packages have. These generally have to do with the way you operate your business, but they can be accounting requirements. Let’s take accounting requirements first.

Example: Unusual accounting requirements.

Suppose that you have four companies. Two are in foreign companies and keep their books in Euros and Rand’s (ZAR). The other two companies are in the US and keep their books in USD. You need a monthly consolidation of these four entities. To make things a little bit more interesting, you only own 75% of two of these companies (the ZAR currency and one US company). One of the companies has commodities as assets that need to be revalued daily and entries booked in a particular way, and these entries have to be processed in a very unique way for the consolidation. That’s an unusual accounting requirement, and should be documented right up front. In effect, you’re saying to the vendor, “If you don’t have this feature, we can’t use your software.”

Example: Unusual operating requirements.

A second type of unusual requirement relates to the way your company operates. Suppose you have a small manufacturing company. Eighty percent of your revenue comes from products you manufacture and sell through distributors (manufacture to stock). For this business, you make the same products over and over. Twenty percent of your revenue comes from specialty manufacturing orders that come with engineering designs. You create the tooling for these orders, and generally manufacture these only once (manufacture to order or job shop operations). You need to keep up with the costs on a product-by-product or job-by-job basis. Right now you do that with a “job envelope,” but you want to automate this.

So is this really unusual? No, not really. It’s a typical job shop. What makes this unusual is that you also do repetitive manufacture-to-order work. And what makes this important in an RFP is that many ERP systems that have repetitive manufacturing will also say they can do job shop or manufacture to order. Can they? Yes, they can. But you may have to jump through hoops to get the information you need into or out of the system.

Using  these Requirements

Once you have these, here’s how you use them. Feature coverage is your screening criteria. You don’t consider a product that doesn’t have feature coverage. We’ll talk about how to do this screening in a later post.

Unusual requirements become part of your initial requirements list to vendors and are your demo criteria. First, you’ll send an email (or letter) to the software vendor with your requirements. You’ll ask, “Does your software do this?” They’ll respond, and you’ll filter the products by looking at the responses. When you get to the point of demonstrating products, you’ll prepare a demo script. Basically, it says, “Here is the setup you’ll need. Demonstrate how this, this, and this work in your product.” The “this’es” in your email will be unusual requirements. When you see the demos, you’ll be able to compare product to product.

So now you know all my secrets…almost.


ERP Implications of Realism – Theranos Cuts Workforce – Update

A few days ago, we used Theranos as an example of the way tech companies are often more optimistic about their own technology than warranted. Today Theranos announced that it are closing blood testing facilities and eliminating 40% of its workforce.

Does this mean it’s bad tech?

Truthfully, I don’t think so. Theranos might (note that I said might) come up with a revolutionary product. The issue is that they got ahead of the curve and sold more than the product would actually do. Some day, the company might release a product that is marketable, or even revolutionary. Since I don’t have insight into the company’s products or market, I don’t know. How this applies ERP systems does interest me.

Realistic ERP has benefits

ERP (Enterprise Resource Planning) either changes the game or just improves it. Businesses with some degree of automation of operations (not just accounting) will likely find that ERP is provides improvement. Automating manual processes improves efficiency. For example, a company shipping manually (with a vendor product) that implements integrated shipping improves shipping efficiency. EDI makes ordering and receiving more efficient, depending on the specific messages implemented through EDI. Manufacturing companies find that MPS (Master Production Scheduling) increases efficiency and customer service. But these are not the end  of the benefits.

Second Tier ERP Benefits

The biggest benefits often come from second tier features of the system. A second tier feature is one that requires implementation of other features. In the examples above, a second tier effect of integrated shipping is the ability to quote shipping and rate shop at order entry time. Salespeople can propose rates to customers. EDI can automate restocking of key inventory; orders are transmitted to suppliers when products fall below set levels. Finally, implementing MPS effectively will enable the use of Order Promising. This allows order processing to calculate the earliest delivery date of particular orders, even for manufactured products.

Why harp on Theranos?

So if I’m really interested in the implications of business software, why do I keep using Theranos (a company in the blood testing market space) as an example? I’m really pushing toward a principle: it’s important to understand technology–including both capabilities and limitations–before falling in love with it. The right process for implementing technology involves knowing both your business and technology and matching the two.

Expectations are terribly important in this process. Expectations that are too high lead to disappointment or the feeling that the technology doesn’t work or won’t work. Expectations that are too low lead to reduced incentive to move forward with implementation. Realism is key. Many times, tech firms sell tomorrow and not today. Buy only today.

At the end of the day, technology and business software can make dramatic differences in business. Being realistic is key.