ERP Users don't know how to test

One of the deep-rooted problems in ERP work is the gap in knowledge.

You can get expertise in the software platform. The vendor will supply it, or consultants, or specialised new employees. You already have expertise in the business itself, how everything is done, and the particular needs. Those two sides don’t overlap, though, and there’s almost always a distance, areas where it isn’t clear how they even fit together.

A great team can get a long way overcoming this, with willingness to listen, consult, and work together, and with a bit of humility on all sides. Genuine expertise, in my experience, is usually confident enough to be humble about what others know better.

Other organisations and projects may power on through as though the gap isn’t there.

Until testing starts.

This is where expertise hands off to expertise. The software specialists say “Here, we’ve done what you said needed to be done, based on our knowledge of how the software works and what you said you wanted. Now please sign off that it does do what you want.”

The problem with this is that users typically don’t know how to test.

The software experts DO know how to test, but they don’t know how to tell what’s practically needed. It’s convenient, in that case, to formally make clear that that is not their responsibility. In many cases, the process and documentation is structured specifically to make it clear and legal that their obligation is only to do what they’ve been told in writing needs doing, and whether that works or not is the responsibility of the client. This is professionally sensible, but further pulls their incentives away from putting real functionality first.

So it lands on the users to say whether everything works.

Users know how to do their day job, so they’ll spot anything clearly unworkable. Nearly always, they’re not technical, and haven’t been trained or gained experience in how to work systematically through scenarios and types of data and activities that will surface less obvious problems.

What's more, they're usually busy people with day jobs that they know are important, whereas this testing ... well, it's a bit theoretical, and who knows?

It suits everybody to assume this is all fine, though. Because if something breaks, the people who matter have proof that it wasn't their fault.

Training fixes most of this.

The best implementation teams know all this from the start, and they make absolutely sure that not only the work but the testing is arranged, clear, mapped out and documented. Companies tend not to like being pushed into creating full detailed scenarios, let alone working through them over and over, but experienced project managers know how important it is.

Yes, only the users know what the crucial elements of their business system are, so only users can say what must happen and what must not happen. But consultants can make clear why they need to spend time on that, and provide proven strategies for doing it. Good consultants will avoid the temptation to let it be skipped by those who don't yet know how important it is.

And, of course, once the ERP has been in place long enough that in-house staff know it well, that's the best of all worlds. There will always be a select few who develop a nose for what needs testing and what might break, and others who can keep a testing plan current.

Because testing doesn't stop ...

As ERP becomes a cloud thing, and upgrade cadences quicken, a lot of this testing needs to happen every time.

The ERP vendor puts it on you, the company, to make sure that your business won't break when they upgrade the system it runs on. They'll typically upgrade a development system first, and if you haven't tested that in time, that's on you. That testing plan had better be good.

If you never learned how to test in that original implementation, you may struggle for a long time and never really appreciate what you lost when cutting those corners at a time when things were so pressured. You'll go live again and again, always with fingers crossed.

Really, I can't stress this enough – in the heat of an implementation, it's so tempting to push the final say off onto the lowest-level people involved and call it a day, but it needs to be treated as vital as anything else and done seriously. That effort will pay back again and again.

The next level, though ...

It is possible, though still rare in my experience, for testing to be made completely routine. In software development itself, most testing is organised and automatic, and the same mindset can be brought to user acceptance and upgrade testing.

When you can detail precisely what needs to be tested, and what will test the required outcomes, you can move from hoping to knowledge for each upgrade.

And, we could mention, that is where you can be with META eight's automated upgrade testing, which takes a lot of the effort and time away, once you've set up what needs doing with us.

But whether or not you do that, when your business depends on a cloud ERP you won't regret being organised and efficient in testing it, and investing time in making sure the right people know what to do to be sure it's working as they need.