Discover the value of ERP consultants in your ERP implementation by understanding the differences in their roles for successful project management.
Everyone involved in an ERP project is called a consultant at some point, which makes the title nearly useless for working out who you are actually talking to and whether they can do what you need.
The distinction matters commercially. Engaging a functional consultant to solve a technical problem, or a technical one to redesign a process, produces slow progress and an uncomfortable conversation about scope. Both are avoidable if you know the roles.
What follows are the types you will meet on a NetSuite project or any comparable ERP programme, what each is genuinely good at, and how to tell whether the person in front of you is what their title suggests.
The functional consultant translates between your business and the system. They are the person who understands both how your order to cash process actually works and how NetSuite expects it to work, and who decides where those two things meet.
Their output is configuration and design. Chart of accounts structure, approval workflows, item and customer setup, transaction forms, the dimensional model that determines what you can report on later.
The good ones ask about your business before talking about the system. They will want to know why a process works the way it does, because the answer determines whether it should be preserved or changed.
This is the role you spend most time with during design, and the one whose decisions you live with longest. A weak functional consultant produces a system that works and does not fit, which is the most expensive kind of failure because it is not obviously broken.
The technical consultant writes code. In NetSuite that means SuiteScript, and increasingly the tooling around deployment and integration.
Their work covers customisations that configuration cannot achieve, integrations between NetSuite and other systems, data migration scripting, and the automation that sits behind complex business rules.
The distinction from a general developer is platform knowledge. NetSuite has specific constraints, particularly around governance limits, script types and execution contexts, and a capable general developer who does not know these will produce something that works in testing and fails at volume.
The good ones push back on requests for customisation. A technical consultant who builds whatever is asked is expensive in the long run, because every script is something to maintain, test against two releases a year, and eventually explain to whoever comes next.
The architect makes the decisions that are hard to reverse. System landscape, integration approach, whether a requirement is met by configuration, customisation, a third party application or a process change.
They are typically involved heavily at the start, lightly through the build, and again whenever something significant is proposed.
Their value is in preventing the accumulation of individually reasonable decisions that collectively produce an unmaintainable system. Anyone can approve one customisation. Knowing when the fortieth one indicates a design problem is the architect's job.
Smaller projects frequently do not have a dedicated architect, and the role is absorbed by a senior functional consultant. That works when the person is genuinely senior and fails quietly when it is a title rather than a capability.
Industry specialists bring domain knowledge rather than platform knowledge, though the good ones have both.
The value is in knowing what your business is going to need before you say it. Someone who has implemented for wholesale distributors knows about landed cost, consignment stock and the way rebates complicate margin reporting. That knowledge shortens design considerably.
It also prevents a class of mistake where a requirement is met literally and misses the underlying need, because the consultant did not know enough about the industry to ask the follow up question.
Industry depth matters more in some sectors than others. Manufacturing, construction and not for profit have enough specific complexity to justify it. A straightforward services business gains less from it than from general capability.
Data migration and integration are frequently underestimated and they consume a disproportionate share of project effort.
The data side covers extracting from legacy systems, cleansing, mapping to the new structure, loading and reconciling. It sounds mechanical and it is not, because most of the work is deciding what the old data actually meant and what should happen to records that do not fit the new model.
The integration side covers the ongoing connections between NetSuite and everything else, which means understanding both ends, the middleware if any, error handling, and what happens when one side is unavailable.
These are frequently the same person on mid sized projects, and the skill set is genuinely distinct from either functional or general technical work.
The role most often cut when a project runs late, and the one whose absence most reliably determines whether the implementation delivers value.
Their work covers preparing people for the change, building training around processes rather than modules, supporting the first weeks after go live, and dealing with the resistance that appears when familiar ways of working are removed.
The good ones were present during design, because training delivered by someone who does not know why decisions were made can describe the system without explaining it.
Where this role is absent, it usually falls to the functional consultant, who is generally competent at it and rarely has the time. Our training service exists because this is the gap we see most often after go live.
Not a consultant in the technical sense and central to whether the engagement works.
Their job is scope, schedule, resource coordination, risk and the communication that keeps everybody aligned. On a well run project they are largely invisible, which makes the role easy to undervalue.
The distinguishing quality is willingness to deliver bad news early. A project manager who reports green until the week before go live is not managing the project, they are reporting on it.
Note that your partner's project manager manages their side. You need someone internal who owns your side, and projects where that person is not appointed or not given time reliably struggle.
Different discipline from implementation and frequently confused with it.
Implementation work is project shaped, with a defined scope and an end. Support work is continuous, reactive, and requires knowing your specific configuration well enough to diagnose why something behaved unexpectedly.
Good support consultants are pattern matchers. They have seen the symptom before, across many clients, and can narrow the cause quickly rather than investigating from first principles.
The best arrangements keep some continuity between implementation and support, so the people who answer your questions know why the system was built the way it was. Our support service is structured that way for exactly that reason.
Titles are unreliable, so the practical approach is to ask about work rather than about roles.
Ask what they did on their last three engagements, specifically. Someone describing configuration decisions is functional. Someone describing scripts and integrations is technical. Someone who describes both at a high level and neither in detail may be a generalist, which is fine if that is what you need and a problem if it is not.
Ask them to describe something that went wrong and what they did. Experienced consultants have several of these and answer readily. People who have only ever been on projects that went smoothly have not been on many projects.
Ask what they would push back on. Consultants who never say no are agreeable and expensive.
The composition shifts through a project and understanding the shape helps you judge whether a proposed team is sensible.
Early on it is architecture and functional work, with the emphasis on understanding the business and making the structural decisions.
Through the build it is functional configuration, technical development where required, and data work running in parallel, usually with the data effort larger than expected.
Approaching go live it shifts to testing, training and cutover planning, with the functional people supporting rather than designing.
After go live it is support, with a period of elevated intensity that tapers. Where a partner proposes disappearing at go live, that is worth questioning, because the first month is when the real problems appear.
Not every role needs the most experienced person available, and knowing where seniority pays is how you keep a project affordable without weakening it.
Design decisions justify seniority, because they are the ones you cannot easily undo. The dimensional structure, the integration architecture, the decision to customise or not.
Execution of decided work does not. Configuring what has been designed, building a script to an agreed specification, loading data to an agreed mapping, all of these are done well by capable people who are not the most expensive on the team.
The pattern to watch for is a proposal where senior people are named and junior people do the work, which is common enough to be worth asking about directly. Who is actually on this project, how much of their time, and what specifically do they do.
Delivery location varies across roles and the sensible answer differs by role.
Functional design benefits from proximity and timezone overlap, because it is conversational work that depends on understanding a business, and understanding is slower across a twelve hour gap.
Technical development travels well. A clear specification produces the same script regardless of where it is written, and the cost difference can be substantial.
Data work sits in between. The mapping decisions need business context and the execution does not.
Support depends on your tolerance for delay. Same timezone response matters more for a business with urgent daily processes than for one where a next day answer is acceptable.
Both are viable and they fail differently.
An independent gives you direct access to the person doing the work, usually at a lower rate, with no account management layer. The risks are capacity, cover during absence, and narrow range, since one person cannot be strong across functional, technical and data work.
A partner firm gives you range, cover and continuity, at a higher rate and with more distance between you and the individuals. The risks are that you get a different team than the one you met, and that your project competes internally with larger clients.
The hybrid that works for many mid sized businesses is a partner for the implementation and an ongoing relationship for support, with an internal person developing enough capability to handle routine change. Our view on solution providers and alliance partners covers the structural differences between partner types.
The consultants leave, and what remains determines your cost of ownership for the following decade.
The most useful internal role is a system administrator who understands your configuration, can make routine changes, and knows enough to judge whether a request needs outside help. That person does not need to be a developer.
Building that capability during the implementation rather than after it is considerably cheaper, because the consultants are already there and the knowledge is fresh.
Insist on it explicitly in the engagement. Shadowing, documentation, and a defined handover are things partners will do when asked and rarely volunteer.
Our guidance for system administrators covers what that role needs to cover.
Work out which type of problem you have before you engage anybody. A process that does not fit the system is a functional problem. A requirement the system cannot meet is a technical or architectural one. A system that works and nobody uses properly is a training problem. A system nobody can maintain is a support and capability problem.
Those need different people, and matching them correctly is most of the difference between an engagement that goes well and one that grinds.
Our pieces on working with NetSuite business advisors and what to expect from a partner cover the relationship side, and our advisory and strategy service is where the architectural conversation usually starts.
If you would like help working out which capability your project actually needs, get in touch.
