An ERP implementation consultant owns the practical work of getting enterprise software live — requirements, configuration, data migration, testing and training — so the business ends up with a working system rather than an expensive installation.
The evidence supports that framing. Project Management Institute research found 47% of unsuccessful projects miss their goals because of inaccurate requirements management. The Standish Group’s CHAOS research puts outright IT project failure at roughly one in five, with half of all projects landing somewhere between rescued and ruined.
Sorcha Systems, an independent IFS consultancy working from Preston and Belfast, sees that gap up close. This piece covers what the role really involves, how to tell a capable consultant from a confident one, and where thinly staffed implementations quietly come apart.
What Does an ERP Implementation Consultant Do Beyond Configuration?
The job starts long before anyone opens a settings screen. Consultants shape decisions about scope, process, and data that are hard to reverse later, and they do it while balancing what the software does well against what the business insists on keeping.
Getting Requirements Right Before Anyone Builds
Weak discovery is expensive. Consultants run structured workshops with the people who actually do the work, document what they find, and get written sign-off, because a requirement nobody agreed to becomes an argument during testing.
Deciding What to Configure and What to Customise
Modern platforms handle most standard processes out of the box. Good consultants exhaust that functionality first, then reserve development for genuine differentiators, since every custom object adds maintenance work to each future upgrade cycle.
Cleaning Data and Proving It Reconciles
The legacy systems are mostly duplicates, inconsistent, or completely inaccurate. Consultants establish migration guidelines, clean the data, reconcile the opening balances to the legacy system, and turn it off only after that, because inaccurate data is a factor that destroys credibility right away.
What Are the Signs of a Great Consultant From an Average One?
Asks consultants what kind of mistakes they have made in the past and not just success stories. The best consultants will be the ones who are comfortable sharing their worst cases related to scope creep, integration failure, or challenging stakeholders.
| Area | Strong consultant | Warning sign |
| Requirements | Documents and secures sign-off | Accepts a vague brief and starts building |
| Design | Configures standard features first | Reaches for custom code early |
| Knowledge | Trains your team, shares notes | Keeps expertise close to the chest |
They Say the Thing You Do Not Want to Hear
Honesty, on occasion, involves suggesting a different module, taking more time, or a change to procedure rather than new software. Consultants who always agree with their clients are likely safeguarding the sale, not the result.
They Leave Knowledge Behind, Not Dependency
Handover matters. Your staff should handle routine administration after go-live, with consultants involved for complex work. An engagement that leaves the internal team unable to run basic tasks has not succeeded, however smooth the launch felt.
They Can Name Where the Risk Sits
There is always a vulnerable spot in any project: bad integration, bad data, a resistant department. An experienced consultant will spot these vulnerabilities at the planning stage and plan accordingly instead of having to face them during the last week of cutover.
What Goes Wrong When Implementation Support Is Thin?
The failures are rarely technical. They cluster around governance, over-specification and unclear ownership, which are organisational problems that show up looking like software problems once go-live arrives.
Systems Over-Tailored to Every Department
The National Audit Office found that building complex shared services over-tailored to individual departments increased costs rather than saving money. The same instinct appears in ERP projects when every team wants bespoke processes.
Dependency That Outlives the Project
Some consultants stay useful for years. Others become a permanent crutch because nobody documented configuration decisions or trained replacements. That distinction rarely appears in a proposal, but it shapes how much control you retain afterwards.
Accountability That Slips Between Three Parties
Each of the vendor, implementation partner, and internal IT department assumes that somebody else is taking care of escalation management. It is at this point that consultants bring maximum value by making it very clear who owns what.
How Sorcha Systems Works Alongside In-House Teams
Sorcha Systems is an independent IFS partner that does not sell licences and is not affiliated with, endorsed by or licensed by IFS AB. Its consultants include former IFS employees and long-term customer-side users of industrial and financial systems, which gives the advice a practical edge rather than a sales one. IFS itself reported 32% annual recurring revenue growth in 2024, so demand for people who know the platform well keeps rising.
What they bring to an implementation or an independent IFS technical consultant brief:
- A network of more than 140 ERP consultants, mobilised around workload
- Former IFS staff and experienced customer-side users
- Independence, with no vendor agenda shaping recommendations
- A 24/7 service desk covering live system issues
- Sector experience across energy, engineering, telecoms and manufacturing
Conclusion
A good consultant shortens the distance between go-live and real benefit. They own requirements, configuration and data, then stay close while the system settles. Where the platform is IFS, bringing in an independent IFS technical consultant usually means advice shaped by operational reality rather than a sales target.
Frequently Asked Questions
Do we need a consultant if we already employ a project manager?
Usually, yes — the roles need different expertise. A project manager tracks schedule and budget, while an ERP software implementation consultant handles configuration, data, and functional problem-solving. Sorcha Systems works in exactly that space, and PMI links weak requirements work to 47% of unsuccessful projects failing.
What happens if the consultant leaves mid-project?
Agree in advance who owns documentation and configuration records, and insist on knowledge transfer throughout rather than at the end. Where consultants work through a partner network, a replacement usually steps in without restarting discovery, though some disruption and re-learning time is realistic.
Is it worth customising the system to fit how we work?
Only rarely. Heavy customisation complicates every future upgrade and makes support harder to resource, which is why the NAO criticised shared services over-tailored to individual departments. Configure standard functionality first and reserve custom development for genuine differentiators the platform truly cannot handle.
How involved should our own staff be?
More than most expect. Internal process owners need to attend design sessions, test scenarios and sign off migrated data, because consultants cannot know how a business really operates. Teams that delegate everything end up dependent on outsiders and slow to resolve routine issues after go-live.
Can one consultant cover every module?
Rarely. Finance, supply chain, manufacturing and field service configurations are deep specialisms, so larger implementations need several specialists plus a coordinator. Ask who exactly will deliver each workstream, because a single generalist stretched across complex modules is a common source of delay.
Leave a Reply