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.