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.