Looking for expert NetSuite Business Advisors? Our team can help you optimise your business processes and maximise ROI. Contact us today for a consultation!
Most businesses running NetSuite are using a fraction of what they have paid for, and the gap is rarely a knowledge problem inside the platform. It is that nobody in the business has the time, the vantage point or the mandate to ask what the system should be doing that it is not.
That is the gap a business advisor fills, and it is a different role from implementation and different again from support. This article covers what the role actually does, when it is worth engaging one, how to judge whether you are getting value, and what has to be true on your side for the arrangement to work.
The distinctions matter because they determine what you should expect and what you should not.
An implementation consultant delivers a defined scope. They configure what was designed, they hand over, and the engagement ends. Their success is measured against the specification.
A support consultant answers questions and resolves problems. They are reactive by design, which is appropriate, and it means they only ever address what somebody noticed and raised.
An advisor is neither. Their job is to look at how the business is running, work out what the platform could do that it is not doing, and help you decide what is worth pursuing.
The distinguishing feature is that an advisor brings you problems as well as solutions, because most of the value is in identifying opportunities the business has stopped noticing.
Businesses do not underuse their systems through carelessness. There are structural reasons and they are worth naming because they explain why the gap persists.
The people who use the system daily are focused on completing today's work, which is exactly what they should be doing, and it is not a vantage point from which improvement is visible.
The person who knows the platform best inside the business is usually also the busiest, and improvement work always loses to operational work.
Nobody sees other businesses. A finance team knows how their processes work and has no comparison, so a process that takes three days seems normal because it has always taken three days.
And the platform itself changes twice a year, which means the set of possibilities expands continuously while nobody is watching.
The work is more concrete than the title suggests.
They review how the system is genuinely used rather than how it was designed, which means looking at manual journals, spreadsheet exports, approval behaviour and where the workarounds have accumulated.
They identify what standard functionality would address, which is frequently more than businesses expect, because a substantial proportion of perceived gaps turn out to be configuration nobody switched on.
They quantify what change is worth, in hours and in risk, so that decisions are made on something better than enthusiasm.
And they sequence the work, which is the part that most affects whether anything actually gets done, because a list of twenty improvements produces paralysis and a list of three produces progress.
The single thing an advisor brings that cannot be built internally is the comparison across many businesses.
They know what a month end takes in businesses like yours, which tells you whether your close is slow or normal, and that is a question you genuinely cannot answer from the inside.
They know which configuration decisions cause problems two years later, because they have seen those problems arrive.
They know which third party applications are worth the investment and which create more work than they remove.
And they know what typically gets deferred at implementation and never revisited, which is usually where the largest untapped value sits.
The trigger is usually a specific frustration rather than a general sense that things could be better.
Your implementation completed some time ago and nothing has changed since, which is the most common and most costly situation.
Month end takes longer than it should and nobody can explain exactly why, or the explanation is that it has always taken that long.
You are considering a significant addition, such as a new module or a third party application, and want an independent view on whether it is the right answer.
Manual work is growing rather than shrinking, which usually means the system is drifting away from how the business now operates.
Or you have inherited a system nobody can explain, which happens more often than people admit and is a genuinely difficult position to be in without help.
Advisory work comes in different shapes and it is worth choosing deliberately.
A one off review is a defined piece of work producing an assessment and a prioritised list. It is useful for establishing a baseline and it delivers nothing by itself, since somebody still has to act on it.
A periodic arrangement, quarterly or twice yearly, keeps the assessment current and provides a rhythm that makes improvement happen rather than remaining an intention.
An ongoing advisory relationship, with a smaller regular commitment, gives you somebody to consult before making a decision rather than after, which is where most of the value sits.
Which fits depends on how much change your business is going through and how much internal capability you already have.
The output of an initial engagement should be specific enough to act on rather than a general assessment.
A list of where manual effort currently goes, quantified in hours per period, because that is the business case for everything that follows.
An assessment of what standard functionality would address without any purchase, which is frequently the largest and cheapest category.
A view on the customisations you are carrying, which are still needed and which have been superseded by standard functionality.
An honest assessment of your data quality and your dimensional structure, since both constrain everything downstream.
And a sequenced plan, with the highest value item first, rather than an undifferentiated list of everything that could be improved.
Advisory is easy to claim and harder to deliver, and a few questions separate the two.
The question about telling clients not to do things is the most revealing, because an advisor whose recommendations are always to buy or build more is a salesperson with a different title.
Whether your advisor should be independent of whoever implemented your system is a genuine question with arguments both ways.
An independent advisor gives you a view unencumbered by having made the original decisions, which is valuable precisely because the original decisions are what you are reviewing.
Your implementation partner knows why the system was built the way it was, which saves considerable time and means the advice accounts for constraints an outsider would miss.
Where the same firm does both, the thing to watch is whether they are willing to say that an earlier decision was wrong. Firms that can do that are more useful than firms that cannot.
In practice many businesses use their existing partner for ongoing advice and bring in an independent view periodically, which is a reasonable balance.
Advisory engagements fail on the client side at least as often as on the advisor side, and for predictable reasons.
Access to the people who actually do the work, not just to management, because the workarounds and the real process live with them.
Honesty about what is not working, including the parts that reflect badly on decisions somebody in the room made.
Capacity to act on the findings. A review that produces a good list and no capacity to deliver any of it is worse than no review, because it adds a documented failure to the situation.
And a decision maker who can authorise change, since an advisory engagement that produces recommendations nobody can approve is an expensive way to confirm what people already suspected.
The gap between a good assessment and an improved system is where most of these engagements fail, and closing it is mostly about scope discipline.
Take one thing first and finish it, rather than starting several. A completed improvement changes what people believe is possible, and a set of half finished ones does the opposite.
Choose the first item by hours saved rather than by technical interest, because the unglamorous fix that returns four hours a month to somebody is worth more than the sophisticated one that saves an hour a quarter.
Name an owner for each item with a date, since improvements without an owner do not happen regardless of how good the analysis was.
And measure the result, because the second improvement is considerably easier to fund when the first one can be shown to have worked.
A good advisory relationship should reduce your need for it over time rather than deepening dependency.
The most useful internal capability is somebody who understands your configuration well enough to make routine changes and to judge when a request genuinely needs outside help.
That person does not need to be technical. They need context, access, and enough time to keep up with the platform.
An advisor worth having will actively build that, by explaining reasoning rather than delivering conclusions and by transferring the diagnostic method rather than only the diagnosis.
Our guidance for system administrators covers what that role needs to cover.
Across the environments we see, the same areas come up repeatedly, which is useful because it tells you where to look first.
Reporting is almost always incomplete, because it is the last thing built and the first thing compressed, and because people do not know what they want until they have live data.
The dimensional structure is frequently narrower than the business now needs, since it was decided before anybody had used the system.
Approval and workflow is often still partly manual, running on email, with no visibility of what is waiting on whom.
And there is usually at least one significant process, such as fixed assets, lease accounting or project costing, running in a spreadsheet alongside a platform that would handle it.
Some markers make the value of an advisory relationship observable rather than a matter of impression.
Month end has compressed measurably, and the reason is documented rather than attributed to people trying harder.
Manual journal volume is falling rather than rising, which is the single best indicator that the system fits the business.
At least one significant spreadsheet has been retired and the process moved onto the platform.
Somebody internal can now make routine changes without raising a ticket.
And the leadership team can get an answer to a new question in hours rather than weeks, which is ultimately what the platform was bought for.
The businesses that get the most from NetSuite are not the ones with the largest implementations. They are the ones that kept improving afterwards, in small increments, with somebody accountable for it and an outside view periodically.
If your implementation completed some time ago and nothing has changed since, a review is likely to find more than you expect, and the largest findings are usually configuration rather than purchases.
The cheapest version of this exercise costs nothing. Spend an hour listing the manual work that survived your implementation and how long each item takes, and you will have most of a business case already.
Our pieces on post implementation strategy and features you probably are not using cover specific opportunities, and our advisory and strategy service is where this work sits for us.
If you would like a review of your own environment, get in touch.
