How to choose an ERP system

Most failed ERP projects were lost during selection. The software was chosen for the wrong reasons, against requirements nobody had written down, from a partner nobody had checked.

This is the sequence we would follow if we were buying rather than selling.

Start with what is broken, not with software

Before looking at any product, write down what actually goes wrong now. Stock figures that are never right. Invoices raised late. No idea which jobs made money. Three people keeping separate spreadsheets that disagree.

That list is your requirement document, and it is worth more than any feature checklist because it is specific to you. It also gives you a way to judge the project afterwards: in a year, is each of those things fixed?

Insist on demonstrations with your own data

Every ERP demonstrates beautifully with the vendor's sample data. Ask instead for a demonstration using a handful of your own records — your items, your customers, a real order the way it actually arrives, including the awkward ones.

Watch specifically for the workflows you described as broken. If a vendor deflects to a different example, that is your answer. Any competent partner can prepare this, and unwillingness to do so tells you something worth knowing before you sign.

Check the partner harder than the product

ERP platforms rarely fail. Implementations do. Ask these before deciding.

• Who specifically will do our work, and will they still be here in six months?
• Can we speak to two clients of similar size in Qatar — including one whose project was difficult?
• What happens after go-live, for how long, and at what cost?
• What if we want to leave — can we export everything, and could another firm take this over?
• What did your last project overrun on, and why?

The mistakes we see most

Almost every troubled project we have been asked to rescue made at least one of these.

• Choosing on price alone, then paying twice when the first attempt is abandoned
• Trying to switch on every module at once instead of sequencing
• Nobody inside the business owning the project, so decisions stall for weeks
• Migrating dirty data and permanently inheriting the old problems
• Skimping on training, then concluding the software is unusable
• Treating go-live as the end rather than the point at which real questions start

At a glance