ERP Consulting

Read the post-mortem on any ERP programme that went badly and the software is seldom the culprit. The recurring causes are the same: requirements gathered as a feature checklist, process decisions deferred until configuration forced them, and an integrator paid by the day to build whatever it was told.

Selection and fit

We start from how your business actually runs - order to cash, procure to pay, record to report, and whatever your manufacturing or service model demands - and derive requirements from that. A feature-comparison spreadsheet tells you what products do; it does not tell you which one fits the way you take an order.

We take no licence commissions and resell nothing we recommend. That occasionally means telling you the honest answer is to fix the implementation you already have rather than buy a new one, which is not a conclusion a reseller reaches often.

Implementation assurance

Most organisations run one ERP implementation a decade; their system integrator runs several a year. That asymmetry is the real risk, and it is not solved by a stricter contract.

We sit on your side of the table: reviewing the design against the process you agreed, testing whether a proposed customisation is genuinely necessary, checking that data migration has been rehearsed rather than planned, and asking the uncomfortable questions at each stage gate while there is still time to act on the answers.

The customisation conversation

Every customisation is a permanent tax - on upgrades, on testing, on the next implementation. Some are genuinely justified because they encode something that actually differentiates you. Most are there because a process was never challenged. We separate the two before they are built, not during the upgrade five years later.

Process design

The design work happens before configuration and in business language: who approves what, where exceptions go, what a credit block means commercially, how period close is sequenced, which variances get investigated and by whom. Configuration is then a translation exercise rather than a negotiation conducted through change requests.

Upgrades and re-platforming

Whether to upgrade in place, re-implement clean, or leave a stable system alone for another two years is a business decision that gets presented as a technical one. We model it honestly, including the option of doing nothing, and including the accumulated customisation debt that makes the cheap-looking path expensive.

After go-live

Adoption is where the benefit case is won or lost, and it is almost always under-resourced. We stay through stabilisation, measure whether the process is being followed rather than merely available, and hand over cleanly - either to your team or into managed application services, where the same process knowledge keeps supporting it.