ERP implementation roles — who does what, and which you fit

“ERP consultant” is not one job. It is an umbrella over six roles that differ in skill, path and salary, and whose holders sit in the same meeting — which is why anyone new to the room takes them for one thing.

The cost of not knowing that is specific. Apply without knowing which of the six the advert is for, and you are assessed on skills you never claimed to have. You come away believing the market is closed. You knocked on the wrong door.

The six, and what each does with a working day

Role	What it actually does	What it is measured on
Functional consultant	Translates how the business works into system configuration	Does the cycle run the way the client runs?
Technical consultant	Writes the customisations, integrations and reports	Does the code work, and survive the upgrade?
Project manager	Scope, schedule, resources, escalation	Delivered on date and on budget?
Business analyst	Gathers requirements and writes them so they can be built	Is the document enough for somebody else to build from?
Data migration lead	Extract, transform, load, reconcile	Did the trial balance agree to the penny?
Post-go-live support	Receives problems, resolves them, classifies them	Response time, and repeat rate of the same problem

The first is what most people mean when they say “consultant”. It is also the most in demand and the hardest to replace, because it is the only one that has to understand the client’s business before it understands the system.

Functional or technical — the choice that decides everything after it

Confusing these two is what costs beginners years.

	Functional	Technical
Starts from	The accounting and operating cycles	The language and the system’s architecture
Works with	Configuration, testing, training	Code and integration interfaces
Sits with	The accountant and the warehouse manager	The functional consultant and the sysadmin
Usual background	Accounting, business, operations	Computer science, software engineering

The dangerous version of this mistake is a programmer entering the field through the technical door alone. Someone who writes an inventory customisation without understanding the costing method writes code that runs, looks correct, and corrupts balances silently. That is why every path on this site starts from the cycles rather than the code — including the path for people whose goal is programming.

Three client-side roles that job seekers never look for

Wider demand, less competition, because nobody searches these names.

Internal product owner. An employee of the company itself who owns the system after go-live: receives departmental requests, decides what gets built, manages the vendor. This role grows in every company that has implemented anything, and it is usually filled by internal promotion rather than external hire.

Power user. An accountant or storekeeper who mastered the system and became their department’s reference point. This is the fastest available entry into the field for anyone currently in an operational job, because it requires no change of employer to begin.

System administrator. Permissions, users, backups, environments. It is the only one of the roles that can be performed without understanding the cycles, which is exactly why it is the narrowest for progression.

Which door to enter by

The rule is to enter through the door you already hold half the key to.

• Accounting or operations background? Functional — and the shortest route in is to become the power user where you already work.
• Programming background? Technical, on the condition that you go through the four cycles before your first line of customisation.
• Administrative or coordination background? Business analyst, then project management after two projects.
• No background yet? Support or data migration. Both take you across the whole system within a few months, and both are paid learning.

Nobody starts as a project manager. That role is built out of projects the holder has watched succeed and fail. It is not built out of a certificate.

What the interview asks, per role

Three questions, asked in various phrasings. Knowing which belongs to your role is most of the preparation.

Functional: “Talk me through the procurement cycle and where it produces a journal entry.” Two minutes of the answer reveals whether the candidate understands the domain or has memorised screens.

Technical: “How do you keep your customisation working after an upgrade?” That is a question about discipline, not about the language.

Business analyst: “Show me a requirement you wrote yourself.” A document that is not sufficient for somebody else to build from is not a requirement. It is a note.

What to do today

• Pick one of the six by name and write it down.
• Open three job adverts for that specific role and extract the skills that repeat.
• Compare the list against what you have today, and name the two largest gaps.
• Start from the cycle your chosen role leans on most, not from the system.

Where to go from here

All six roles stand on the same four cycles: procurement, order to cash, inventory and the ledger and the close. The vocabulary you will hear in the first meeting is in the ERP glossary, and the reading order is on the learn ERP page.

Choosing the role comes before choosing the system; each product’s limits and the job market around it are in the systems comparison. The next practical step is your first job in the field.