I met with a client the other day. He said, “You’re different from the other ERP salespeople we’ve talked to: you actually know something about the software!”

I’d like to think that’s because I’m not an ERP salesperson…but anyway…

And that’s the key in a sentence to selecting the right ERP. You must get the technical ERP employees (consultants, implementers, developers, trainers, etc.) involved BEFORE you buy the software. 

How do you do that? First, take a look at the suggestions we’ve made over the last year about needs analysis. Start with a good needs analysis. From your needs analysis, divide your needs into three categories: (a) Features every software product should have (you have to know something about ERP or accounting software to do this), (b) Features some, but not all, products generally have (again, you need to know the market), and (c) Features that may be difficult to find or are unique to you. The third option can also include sets of features that need to be in the solution that are unusual to find in the same product. I’m thinking about something like Point-of-sale, warranty management, service, and property management all in one product.

Now here’s the key: focus only on (c) items during the RFP and demo process. You can address (a) and (b) items later in the process when you have narrowed the field.

One last thing: the salespeople probably won’t like this approach. It means you’ll control the demo and the selection process. But it’s the way I’ve helped clients select ERP for 30 years.

More on this in later posts.

If you read more than one study about the reasons for ERP failure, you will know that the #1 reason ERP systems fail is lack of management support for the ERP project. That’s the reason, but it’s not the root cause. The root cause started earlier, even before the first product was identified, the first demo done, and the first proposal requested.

ERP Failure Starts…with budget setting

ERP failure starts in the very beginning of the project. It starts with budget setting. This also applies (perhaps even more) to those companies that “don’t have a budget.” Or those where the budget is, “we’ll spend as much as we have to.”

Humor me while I develop an example. Suppose that your company is about to hire a President. In your company, this position has broad responsibility. The President is responsible for financial management, overseeing purchasing, keeping track of inventory, providing basic data on the sales force, and a list of other duties. You’re setting the salary for the person who will control and manage most of the key items in your business.

After a brief meeting, the CEO says the following, “I think if we look carefully enough, we can find an excellent candidate that will work for $25,000 per year.”

Doomed before the search starts

To put it mildly, this company’s search is doomed before it starts. Every candidate will have less than the required skills. Many good candidates won’t even apply for the position. In the end, either the salary will go up, or a less-than-desirable candidate will be selected.

Of course, you might find a retired business person who just wanted to get back in the game. But are you willing to bet your business on that?

Almost enough is worst of all

Few companies would make this error. After all, my example is so extreme it’s silly… But I’ve seen a lot of companies set a salary at $75,000 when the market required a salary of $100,000. It’s this “almost enough” salary that attracts some talented employees, just not the full slate of skills and experience the company is going to need.

Effect on management…

I mentioned that lack of management support is the #1 reason for Failure. How does that fit?

Every time I see a budget or salary that’s too low, management has set it to be comfortable. If it works out…great! If it doesn’t…well, we can recover without too much trouble.

See?

Management doesn’t have serious skin (money) in the game from the beginning. Play the dirge; it’s going to be ugly!

Where does ERP software come in…

The same thing happens in ERP. Too low a budget restricts both the choices and management’s commitment to the project. My budget formula is just a way to get in the ballpark. The rest of the project will make it clear what the real investment should be…

…next time, how to get started.

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

“$500,000”

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.

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

Plus:

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

Total:

On-premise: $75,000

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

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.

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

At the end of the day, needs definition or needs analysis should control your selection of ERP software.

In the last post, I discussed why IT requirements should not be at the top of your needs definition. In this post, I’ll start the discussion of how to define needs. Let’s take a look at two typical requirements (needs) as an example. The specific needs aren’t that important, so if these don’t apply in your situation, keep reading; we’ll get to the point pretty quickly. Here are the two typical needs:

• Recurring payables capability. The system allows us to set up certain bills that we get every month like the mortgage or the pest control service bill and enters them to be paid so we don’t have to key them.
• Serial numbers for inventory. Some items we sell have serial numbers. It’s important that the system be able to track these serial numbers and who we sold them to.

The first item (payables) is an accounting need. If the system doesn’t have recurring payables, the mortgage and pest control will still get paid. It will just take more work to re-enter the transactions. The second item (serial numbers) is an operational need. If the system can’t track serial numbers, there will be work that needs to be done that can’t be done. In addition, operational needs usually have other operational needs that depend on them.

Operational Needs that Depend on Other Operational Needs

In this example, the reason many companies need to track serial numbers is for warranty work. Without this capability, many hours will be spent trying to trace down the invoice that a particular part came from to determine whether it is under warranty. More hours might be spent tracing the invoice from the vendor for that product. Recalls for ranges of serial numbers or lot numbers can be even more challenging.

In some industries, this need can be very important. For example, in the food industry recalls may be based on serial numbers (or lot numbers). Having this data is necessary to comply with government regulations.

The data may be needed to drive other business needs. For example, to track repairs on equipment or offer customers PM (preventive maintenance) contracts.

As you can see, the need for serial numbers may cascade into other needs. And these needs can be more significant that just a few hours a month of additional effort. There may be business opportunities that are either not possible or not practical without these software features.

Business and Software Expertise are Needed

What’s not as obvious from this is that both business and software expertise are needed to come up with a full needs definition. I’ve had many business people ask for serial number functionality. Only a fraction of that number also asked for warranty, service contract, or recall features. When asked, they quickly said that these were also issues.

Understanding how software uses serial numbers (or lot numbers, national accounts, warranty, etc.) allows an ERP provider to ask you the right questions to configure a system. Not all systems have the features we’ve mentioned in this post. For example, warranty tracking for is common in inventory systems that track serial numbers, but not all systems have it. Service and preventive maintenance is less common. For some systems, it is an add-on product; in others, it is part of the core system.

Make sure your ERP provider is asking good (and thorough) questions about your needs. And don’t leave anything out. The feature you leave out may be obvious to you but not to the ERP provider.

I really wanted to start this post with, “Get rid of IT…for now…” But I thought I might lose readers before I made the point. So here is the (real) point: make sure you start your ERP software search with Operational specifications, not IT specifications UNLESS your IT or accounting specifications are absolutely essential. Now let me explain.

So you want ERP for Linux?

About twice a year, I see a company looking for ERP software for Linux. There are a few, for example here and here. Watch out, though, because the features included in one ERP are not necessarily in all ERP systems. And these packages, being mostly free, don’t have competition to force their hand in adding new features. By specifying Linux, however, the company has excluded dozens of top-performing packages from companies like Microsoft, Sage, and SAP. In addition (although they may not realize it for a while), they may have specified an operating system or database that has no defined support. If you have a problem with Windows, you call Microsoft. If you have a problem with OS X, you call Apple. Who do you call for the Debian Distribution of Linux? What if Google can’t help?

Other IT Non-requirement Requirements

More commonly, I get requests for ERP that runs on Oracle or MySQL. There are some. But either of these specifications rules out some packages. MAC O/S is another requirement. What if the ERP runs in a web browser and thus works on MAC but requires a Windows server?

The question that should be asked of each of these requirements is this: let’s suppose that there is a package that would help us run our business perfectly but it doesn’t meet this requirement, would we give up this requirement? If the answer is “Yes,” don’t include it in the initial specification. Here’s the reason: as an ERP consultant, if you say you have a requirement for Linux, I’m only going to evaluate Linux. The only reason I’d return to look at non-Linux software is if you reject all the available Linux solutions. By that time, you’ll be exhausted with the process, and will tend to “settle.”

Best Practice: Evaluate IT Requirements Late in the Process

All of this is to say that often IT requirements are really IT preferences. If you drill into the requirements you’ll often hear, “Well, we prefer Linux because Jim is really a Linux guru.” Or more likely, “We’d prefer Linux because it is free.” These preferences can be considered later in the process after all possible solutions have been identified. Stating preferences early narrows down the field, and many companies are too fatigued with the process to revisit the preferences later.

More about this in later posts.

I’ve been in the software industry since 1984. I’ve seen many changes. Lately, some of the changes I’ve seen really concern me. Concern me in the sense that I’ve seen more and more businesses with fragmented systems and low productivity. Yet they don’t seem to know what to do about it. In many cases, the system IS the problem, but the business doesn’t realize it.

How can a system problem be invisible?

It may seem a bit difficult for some to believe that a system problem can both produce productivity issues and be invisible. In this case, I’m going to short circuit my normal writing style and jump straight to the point. The key problem in many of these businesses is that they have the wrong system in the first place. Once the system is in place, the business begins the process of trying to optimize a system that wasn’t an optimal system from the beginning. In short, they picked the wrong system. There are some clear signs.

Signs that you have the wrong system

Here are just a few of the signs I see almost every week from one or another business:

• Excel as a tool for core business functions that in the ERP systems include. Examples included schedules for technicians kept in Excel, documents to control ordering and billing, and reminders for various things. One business keeps an Excel spreadsheet of every work order assigned by technician, and monitors the spreadsheet to make sure paperwork is turned in. Another lists parts ordered for jobs and uses the spreadsheet to make sure they are charged to the right customer. Both of these businesses have a sinking feeling that they’re missing something, but they can’t put their finger on it.
• Key features that just aren’t in the system. These are things like maintenance tracking in an equipment rental business. In order to remove equipment from service when it is costing too much to support, this is a must.
• Accounting transactions can be processed, but key operational needs are missing. A system that does a great job of billing, but doesn’t track customer warranty information is the wrong system for a business that needs to track warranties.
• You did software searches in the past, and selected new software. The software purchase gets killed because it’s too expensive or not in the budget.
• Paper systems as a basis for key processes.

Signs that you’re not using what you have

There is another common malady in businesses today: not using the systems they have. In many cases, this is a lack of training. But training is almost never as expensive as the productivity hit from doing things manually. Here are some examples of what I’ve seen recently:

• Excel used to create financial statements even though the system seems to have a financial statement feature. Usually this indicates that the controller, CFO, or accountant is more comfortable in Excel than the financial software.
• ACCESS used to create reports or extract data.
• Excel as a tool for bank reconciliation even though the system has bank reconciliation. There can actually be good reasons for this, but I think they account for about 1 in 3 cases. In most cases, the software would be the more efficient choice.
• The software hasn’t been updated in 5 or more years. The reality is that if you’re holding on to software that is 5 years old (and that’s an eternity in the current environment), you’re not getting all the benefits from it.

What should you do if you see yourself?

If you see your business in any of these bullet points, you should evaluate where you are in terms of your ERP software. We will cover some of the best practices beginning with the next post.