Semi-random thoughts on ERP and accounting software, Microsoft, Windows, business, and life in general.

Main menu

Post navigation

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.

Share this:

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.

Share this:

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

Share this:

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.

Share this:

My CRM server told me that there were Windows Updates to be installed. I typed “Windows Update” in the search, clicked the appropriate item, and clicked “Install now.”

The install failed with code 80246013. The “click here for more information” took me nowhere. So I called tech support, also known as Google.

Someone else had the same problem. There were two solutions proposed:

Solution 1 – Generic troubleshooting

The first techie who replied to the question suggested (1) disable antivirus, and (2) do a clean boot and troubleshoot. These are not bad suggestions, particularly when the error code is not documented anywhere. It would have taken perhaps thirty minutes to an hour to do this. We could also have looked at the Windows Event Viewer’s Application Log. We could have rebooted the server, logged in as local admin, and retried the installation.

Rather than spend this time, I went to option 2.

Solution 2 – Restart the Windows Update Service

The next solution connected this error with the Windows Update service. It said, simply, that if the service is not started, you’ll get this error. Press Windows Key + R, type services.msc, and check Background Intelligent Transfer service and Windows Update service. If they are stopped, start them.

Share this:

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.

Since last year, articles about technology startup Theranos have popped up all over. At first, the articles were about the blood-testing technology Theranos was developing didn’t always seem to give accurate results. In some cases, the results were dangerously, fatally wrong. And now it seems that perhaps the company, at least the founder, knew this and concealed it.

I wasn’t surprised. I deal with it every day.

Vaporware: Software That Disappears

The first significant scandal that I remember was dBase IV. Ashton-Tate was the developer of dBase. The company announced a new version to replace its working, but clunky, dBase III as early as 1986. Finally, in 1988 (an eternity in the tech world), dBase IV was announced in February with an anticipated release in July. dBase IV version 1.0 finally arrived in October of 1988. It was buggy and slow. Ashton-Tate finally delivered an upgrade to version 1.1 almost two years later in July of 1990.

It was about that time the term “vaporware” became popular. Vaporware is an announced software product with announced features that does not exist; sometimes it never comes to market. It fades like vapor into the air.

Features that exist, sort of

I continue to hear from customers about things they have read. This software does such and so. This should work like this. Sometimes, it’s “we just signed a contract with x to do our y.” Trouble is, many times I know the software they are talking about. I ask (trying to gather information and tip them off without creating doubt), “Were they using some add-on to do that?” or “May I take a look at the proposal?”

Too often, the reality is that software WILL do what the customer thinks it will. To put it in business terms, the transaction is possible. However, the issue is often that it doesn’t work the way the client was led to believe it worked.

Case Study: Oops, hand over $50K

Several years ago, we met with a client who wanted to buy software for a particular purpose. We made a proposal and included some customization (which was going to be required). The customization was to add a feature that came up in the first 10 minutes of the first conversation about their needs. They purchased the software from a larger provider who quoted a lower price.

Twelve or fifteen months later, I got a call from their IT Director. The conversation started like this, “Bob, you remember the proposal you gave us for our system about a year ago?”

“Was there some specific secret you knew about how to do that with the software?” he asked.

“Why?” I replied.

“Because our vendor has just now gotten to the point of implementing the software,” he started, “and they want at least $50,000 more to customize it to do that.”

“Oh. Well,” I started, “I knew that the feature was going to have to be customized. I included that in my proposal.”

“I was afraid of that,” he said.

Unfortunately, they were too far into the implementation to change providers at the moment.

Other examples

I wish I could say this was isolated. I’ve run into far too many technology companies pushing products that had severe limitations. Low-end products in the market today are sold to companies that will ultimately find that the architecture (the basic way the software is built) won’t support the volume of transactions they have. I see boxes of software gathering dust in offices; the company purchased them with the belief that they met their needs, and they did not.

As competition increases, I see and hear about more and more proposals that seem dramatically under-stated. A consultant for a now defunct consulting firm told me that it was a regular practice at his firm to submit proposals that underestimated the required hours by 50%. The employees doing the work were then responsible for “selling” the need for the more time to the customer.

Avoiding the issues

Here’s the fact: most vendor salespeople know their product at a features level, not at an implementation level. They know that the payroll system does multi-state payroll. They don’t know how the multi-state features related to worker’s compensation in multiple states, or how multi-state withholding works, or what the system requires if they have employees that work in multiple states during the same pay period. As a result, when a requirements document says, “multi-state payroll,” they say, “We have it.” The fact is that they don’t know enough about payroll or their software to ask the questions they need to ask to give a meaningful answer.

For 30+ years, I’ve believed that before a customer buys software, someone ought to think through HOW they were going to implement the major features. Without this, you may be sold a Theranos: a device that over-promises and doesn’t deliver.

Here’s the key: Ask not “Will the software do this?” for key functions; ask, “Can you show me how the software will do this?”

Share this:

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.

Share this:

The WSJ this morning reported that Proctor & Gamble is rethinking its Facebook advertising. The article sighted lack of effectiveness as the reason.

Electronic Advertising Provides Precise Information

The more you look at the possibilities for electronic advertising and marketing, the more attractive it seems in theory. For businesses it’s the equivalent of being able to test magazine advertising in real-time. Push an ad out and immediately know how many people could have been exposed to it. How many people clicked. What path they followed when they reached your web site, etc.

Audience targeting is very precise. Age, gender, interests, geographic area, etc. can be controlled very precisely. You can display your advertisement only to men between the ages of 25 and 45 who live in Jackson, MS or Memphis, TN. And you can control your spending down to a limit of only a few dollars per day.

With a tad more effort, it’s possible to track what was clicked on the web site, and how far down the page the user scrolled. In short, all the things that we have guessed at for many years can be measured down to the mouse click.

Down Side of Advertising

First, getting the best results requires knowledge and effort. That’s another way to say that if you do it yourself (and there are plenty of resources out there to help you), you’ll spend time. Otherwise, you need to pay someone to do it. The other down side is that without this type of ability, you’ll spend a lot of money potentially without any result.

Second, as the P&G announcement actually reveals, some advertising venues are not right for all products. P&G would do well to check their customer base and particularly the purchase cycle for their products. I glance at Facebook. No matter how low my inventory is, I’m not likely to think as I scan the dog pictures, personal stories, etc., “I think I’ll run out and buy some Charmin…or Gain…or Febreeze.” And it doesn’t matter how bad the laundry, dog, or sofa smell as I’m thinking it. It’s the same reason that I don’t intend to buy the Dash button for any of these type products. For cat litter (I don’t have a cat) or baby food, I see the value. If they ever come out with a way to offer a button you can press to refill your wine cellar or beer fridge, I bet they’ll sell a million of them. If you have a Dash button and use it, I’d love to hear about it.

Conclusion: Get Educated

If you don’t know anything about Facebook, Amazon, or Google advertising, you should. This doesn’t mean that your brand or company should spend money on it. These advertising venues are much like billboards: other options for your toolkit.

Share this:

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.