This is Part 2 of a 4-part series on ERP pricing, and the why companies first need to complete a Business Process Analysis before acquiring a new software system. It reflects the cumulative lessons gained from 25 years’ experience implementing ERP and MRP systems. The first post is found here.
Where to Begin
We are often contacted by a business after it has come to the inevitable conclusion that the software on which they run their business is simply no longer up to the task. Whether that’s because it’s a pre-Y2K relic… or a hodgepodge of disconnected ‘silos of information’… or the progeny of some earlier homegrown solution… or simply because the firm’s growth has outpaced its software’s capabilities… the decision has been made to find new software.
So we get a call from a prospective or existing client. As we discuss our experience and process, we ask questions, explore their needs and suggest a site visit. After more questions, a tour, a discussion about next moves and a few war stories, we usually suggest the key first step: the Business Process Analysis.
First, we should point out that the Business Process Analysis (BPA) has a minor role in helping to select which ERP system is right for you. True, it helps there, but… its real purpose is to help your company learn more about itself, and only then gauge the size and scope of the actual project. We usually back into ‘which’ software from there. The BPA is rooted in a simple premise: we cannot quote what we do not know.
We start by explaining what a BPA is. How it allows us to define and understand a company’s current key processes. How it allows us to project what a future-state process may look like. How it creates the very roadmap that tells us, and anyone else, your key goals and how simple or complex your project is.
At this point, we typically hear one of three responses:
“The other guys will do that for free.” Sure they will. We’ve seen examples. Typically, it’s a brief fly-by, maybe a few pages in a report, describing your business in general terms and how their software will help improve it. Most “free” analyses are worth what you paid for them: a bit of high-level fluff and perhaps some technical jargon aimed at getting you to commit to a specific piece of software — and its accompanying vendor’s services — long before you truly know what problems you are trying to solve. It won’t give you a roadmap for your journey, and it certainly shouldn’t convince you that Software Brand X is just right for you.
“We’ll start laying out the processes after we’ve selected the software.” A slight improvement. At least this answer acknowledges the fundamental need for the analysis. But it’s still putting the cart before the horse. It’s tantamount to making the process analysis Phase One of the implementation project itself. The problem with that is you’re doing it after you’ve selected software and a vendor. By that point, you’ve committed a lot of money already to software and services that you don’t necessarily know will actually solve your problems.
“Before we can approve a process analysis, we’ve gotta’ have at least a ballpark number.” Okay, we’ll concede this point… sort of. As noted earlier, we can ballpark a software price quote based on general functionality and user counts — emphasis on ballpark, but it’s valid. But services estimates can be all over the map, and no one can prove or disprove them because the necessary work to validate them has not yet been done. So even an estimate can be off by a factor of five. Easily two or three. Being off on a price estimate for an ERP implementation by a factor of two or three is enough to get yourself canned.
In our next post we’ll take a brief look at The Analysis Process. Stay tuned…