Unlock the full value of your ERP with a NetSuite training needs assessment. Tailor training to your team’s needs and maximize your NetSuite investment.
Most NetSuite training is designed backwards. Somebody decides how many sessions there will be, splits the system into modules, allocates a session to each, and invites everybody who might be affected. Nobody asks what any individual actually needs to be able to do.
The result is training that is simultaneously too much and not enough. Too much because people sit through material they will never use, and not enough because the thing they actually needed was covered in ten minutes between two things that were irrelevant to them.
A training needs assessment fixes that by starting from the work rather than the software. This article covers how to run one, what to look for, and how to turn the findings into training that changes behaviour.
The purpose is to answer three questions for every person who will use the system.
What do they need to be able to do, expressed as tasks rather than as features. Process a supplier invoice including the exceptions, not use the vendor bill record.
What can they already do, which for an experienced person is usually more than assumed and for a new one less.
And what will they need to be able to do that they cannot do now, which is the gap the training exists to close.
Done properly this produces a specific list per role rather than a curriculum, and the training design follows from it rather than preceding it.
The most reliable way in is to map the recurring processes the business runs, before looking at who does what.
Order to cash. Procure to pay. Record to report. Hire to retire if payroll is in scope. Whatever the equivalents are in your business, described end to end rather than by department.
For each process, identify the steps, the decision points, the exceptions and the handoffs. The exceptions and the handoffs are where training most often fails, because standard training covers the happy path and real work is mostly exceptions.
Only then map people to steps. That mapping is what turns a process view into a training requirement, and doing it in this order prevents the common error of building training around job titles that do not correspond to what people actually do.
Two people in the same role frequently need very different training, and treating the role as the unit wastes the time of whoever needs more.
Occasional users touch the system for one or two specific tasks, such as submitting an expense claim or approving a requisition. They need those tasks and nothing else, and additional material actively reduces what they retain.
Daily transactional users need their processes end to end, including the exceptions, with enough understanding of what happens downstream to know why the detail matters.
Power users need to understand the underlying model. How the records relate, what a saved search can do, where configuration lives. These are the people who will answer questions for everybody else.
Administrators need a different curriculum entirely, covering roles and permissions, workflow, release management and the boundaries of safe change.
Assessing existing capability is the part most often skipped, usually because it feels awkward, and it is what prevents both boredom and bewilderment.
Self assessment is quick and unreliable in both directions, since confident people overstate and careful people understate. It is useful as an input and not as the answer.
Observation is considerably better. Watching somebody complete a task in a sandbox tells you in five minutes what a questionnaire will not tell you at all.
Existing evidence helps where it exists. Support ticket history, error rates by user, and the questions people ask colleagues all indicate where the gaps are.
And prior system experience matters, since somebody who has used a comparable ERP needs a different starting point from somebody moving off a desktop accounting package.
Interviews with a sample of users produce better information than a survey, and a short list of questions is enough.
The question about who they ask is unusually informative, because it identifies the informal support network the business already has and the topics that generate repeated questions.
Where the system is already live, behaviour tells you more than any interview.
Manual journals indicate a process that people cannot complete as designed, and each recurring one is a training or configuration gap.
Spreadsheet exports indicate reporting that either does not exist or is not trusted, and the distinction matters because they need different fixes.
Workarounds indicate something the system was expected to handle. Roughly half the time it does and nobody knew, which is a training gap, and the rest of the time it does not, which is not.
And support questions clustered on one process tell you precisely which session needs redoing, which is considerably more useful than an average satisfaction score.
An assessment that classifies everything as a training need produces training that cannot succeed.
A configuration gap is where the system genuinely does not do what the business needs. No amount of training closes it and attempting to do so damages credibility.
A process gap is where the process itself is unclear or contested, and people are improvising because nobody has decided. Training a decision that has not been made is impossible.
A data gap is where the underlying information is wrong or incomplete, so the system produces answers people do not trust, and they route around it for entirely rational reasons.
A genuine training gap is where the system does what is needed, the process is clear, the data is sound, and the person does not know how. That is the only category training fixes, and being honest about the split is what makes the plan credible.
The assessment will produce more than can be delivered, so the ranking matters.
Rank first by consequence. A gap that produces incorrect financial data or a compliance failure outranks one that produces inefficiency, however irritating the latter is.
Then by breadth. Something affecting thirty people is worth more attention than something affecting one, even where the individual impact is smaller.
Then by frequency, since a gap in a daily task compounds far faster than one in an annual task.
And separately, identify the small number of gaps that are cheap to close, because delivering a few of those early builds the credibility that the larger pieces need.
The output of the assessment should be a plan that names, for each group, what will be delivered, in what format, when, and how it will be judged.
Content follows the gap list rather than the module structure, which usually means fewer sessions, each longer, each covering a whole process.
Format follows the content. Discussion heavy material needs a live session. Procedural material works as a recording. Reference material works as a one page guide.
Timing follows first use rather than project milestone, so that core daily processes land immediately before go live, month end processes land before the first month end, and periodic activities land before the first occurrence.
And sequencing respects dependency, since somebody cannot learn exception handling before they can complete the normal path.
The assessment should also establish what the training environment needs to contain, which is more consequential than it sounds.
Practice data should look like production. Your customers, your items, your approval thresholds. When the data is realistic the exceptions that appear during training are the ones people will actually meet.
The environment should be safe, meaning people can make mistakes without consequence, because a learner who is afraid of breaking something will not explore.
It should be resettable between cohorts, so each group starts from the same position.
And it should be available afterwards, because the most useful practice frequently happens in the week after the session rather than during it.
An assessment done before go live is a prediction, and predictions need checking against what actually happened.
Three months in, the picture is different. People know what they do not know, the exceptions have surfaced, and the questions are concrete rather than hypothetical.
A short reassessment at that point is unusually high value, because the same effort produces better targeted training than anything delivered before go live could have been.
It also identifies the things the initial assessment got wrong, which is worth knowing for the next time the business changes something significant.
The assessment should produce something reusable, because the population turns over and the arrangements for new people are usually improvised.
A short capability checklist per role, derived from the assessment, gives a new starter's manager something concrete to work from rather than a general instruction to get them up to speed.
Recorded walkthroughs of each core process cover most of what an individual needs, at no marginal cost, and can be watched at the point of need.
And somebody should own onboarding as a defined responsibility, because where it is nobody's job it defaults to whoever sits nearby and the quality varies with their patience.
Without this, each new person inherits the previous person's workarounds and the organisation's competence degrades quietly.
The assessment defines what good looks like, which is what makes measurement possible.
Capability against the gap list is the most direct measure. Can the person now do the specific thing they could not do. That is observable rather than a matter of opinion.
Error rates in the affected processes, tracked over the weeks after training, show whether the capability translated into behaviour.
Support question volume and topic tell you which sessions landed and which did not, and the topic detail is what makes the signal actionable.
And workaround prevalence is the honest measure, since people who genuinely understand the system use it, and people who do not route around it regardless of what they said on the feedback form.
A needs assessment performed once and filed is a project artefact. Kept current, it is the thing that stops training drifting out of relevance.
Revisit it whenever a process changes materially, since the gap list changes with it.
Revisit it after each significant configuration change, and after the twice yearly release if anything relevant moved.
And revisit it when the team changes, since a new starter or a promotion changes who needs what.
None of this is large. An hour a quarter keeps the picture accurate, which is what makes the training budget go to the right places. Our NetSuite training service is built around this ongoing model rather than one off delivery.
The value of a needs assessment is that it replaces assumption with evidence, and the evidence is usually surprising in at least one direction.
The practical starting point is small. Pick the process that generates the most support questions, map it end to end, interview the three people who run it, and classify what you find into training, process, configuration and data gaps.
That exercise takes a day and it will tell you more about your training requirement than a survey of the whole organisation.
Our pieces on NetSuite training strategy and user adoption cover what comes next.
If you would like help running an assessment for your own environment, get in touch.
