I don’t get involved in ERP implementations much. My thing is helping with systems already in use.

So please don’t call me about running an implementation for you. It takes a skilled team, because there are more things to configure than one person can know. And a project manager, which I am not. There are consultancies that specialise in implementations, and for Kinetic there’s Epicor themselves, of course. Our little business doesn’t compete with them.

I have been in the thick of some implementations, though, enough to talk about it.

So here’s the thing about implementing an ERP …

Businesses do it because they’re growing or changing, usually, which means they’re busy.

They settle on an ERP, hopefully making a wise choice and not allowing “shiny” or ideas of prestige to sway them, and are OK with the cost. ERPs are expensive, but it’s going to pay for itself in efficiency and accuracy.

Then they find out what implementation costs. And they’re shocked, but they sign that off too. After all, they are going to be in the hands of experts, and better to pay experts than try to do it themselves.

They’re busy. Busy with the business itself.

Then the experts come in and get started, and not a lot seems to happen, because they all say they need time with the busiest people.

What was going to be experts coming in, seeing what needs to be done, doing it, and training everybody on what to do …?
It’s not that. It’s meetings. Requests for documents, procedures and data. There’s a lot of waiting, because they’re waiting for the people in the business to do things, and the people in the business are busy.

The experts are used to this. They’ll tell the business what the business needs to do, and wait, because this is what always happens. Time passes, and bills tick upwards. It’s not the experts’ fault, because they can’t work magic.

So what happens?

At some point frustration spills over, because these are the experts, and they should be doing what they need to do, advising and getting on with it. At least as far as management are concerned. The whole project turns into a drag on the business, costing money and acting as a distraction and a drag on making money.

So maybe more or different experts are needed, to break the logjam? At this point, the cost seems secondary because it’s running away anyway.

Sometimes a different expert CAN help (this is the stage at which I’ve joined a few times), but not because of the expertise, as such.

What’s the actual problem?

The whole point of an ERP is to mirror the business itself. That means most ERPs, including Epicor Kinetic, are complex, flexible, and configurable, because no two businesses are the same. The system, as it’s sold, won’t even work without being set up to match the business, and that’s before you start any gap analysis.

Any honest salesperson or consultant will tell you all this. They don’t hide it or cheat (normally). But the business buying the system often doesn’t take in the implication for the process of getting the ERP up and running.

Which is … the experts, the consultants, know the ERP, but they don’t know the business, and they can’t. It would help if they could embed themselves in the business, but even then they can’t know everything about all of it. And at consultants’ rates it’s not likely to be signed off as an idea anyway.

There is no real way round this. What an implementation is, is:

• Finding out the processes and the data (which needs the staff).
• Matching those to the ERP (which consultants can do).
• Configuring and customising the ERP (which is what everybody expects consultants to do).
• Testing whether it does the right things (which needs the staff).
• Training and preparing (which needs both the staff and the consultants).

Most of the time and resource is needed from the business itself. And the business is busy.

And nearly all the problems everybody hears about in ERP implementations are because this is a very hard fact to accept, and a lot of businesses get a long way down the road before they can accept it. I suspect the core reason is that nobody involved in selling and implementing ERPs feels they can afford to be as up-front as it would take to avoid the problem, for fear of businesses shying away from doing it at all.

So what’s the answer?

The answer is that there is no answer. This is just the ugly fact of ERP implementations. When a business accepts that they’re disruptive, and realistically faces the trade-offs needed, that’s when it can make the best of it.

A good ERP implementation needs maybe half the available time of the best people in the business, roughly speaking, the people it can least spare. Because it’s their input that makes the ERP actually do the right things in the right way. The job of management, having decided that the ERP is going in, is to work out exactly how those people can spare that time, over the timeframe they can spare it, and keep the business functional for as long as it takes. Getting it over quickly means more time out, and skimping on the time out means it will take longer.

As I say, implementations are not what I do. There will be experts who say I’m being cynical and negative in this, rather than realistic.

Maybe so. But think of it this way: if you go into a project assuming what I’ve said here is gospel truth, you’ll be prepared in a way that makes it more likely to succeed. If you don’t, what happens if you come to a point where it does look like this? Can you afford to bet it won’t?

OK, but is there ANYTHING that will help?

Yes, as long as you focus on dealing with this basic fact, rather than looking for something to make it go away.

The biggest thing, probably, is project management and accountability. Visible, in both cases.

I’ve seen that work extremely well with sticky notes on a huge whiteboard, so it doesn’t need to be elaborate. If people are scattered then you’ll need a software solution, almost certainly. It’ll feel like more admin, which is the last thing anyone wants, but it pays back when done properly.

If it is digital, then it can pay to have a huge display somewhere everybody passes, that shows what’s going on and who is responsible for each bit that’s going on. This works well for scenario testing, as a specific script passes between departments. Everybody can see if something is being held up because nobody has got to it. And everybody can see the list of things that need fixing, too.

And it’s the fixes that I can help with, as I mentioned that I’ve come into implementations at later stages a few times. Once the business itself is driving the cycle, as it has to do, then it can quickly come to seem worth having a nimbler developer in the loop, where the same person can discuss what the fix should look like and get it in place, in a timeframe in which a team of consultants might still be gathering requirements. That team of implementation consultants never runs out of things to do, so they rarely mind another pair of hands.

But the business itself, and the people in the business, can’t escape doing a lot of the work.

Harsh but true.