Gayle Nelson

Writing

The Operator Test: Your Consultant Should Have Done Your Job

Platform expertise is table stakes. The question is whether the person designing your revenue recognition has ever survived a month-end close.

I spent two months off my feet after a skiing accident, and what I kept thinking about was billing rates.

At the time I was helping lead an SAP S/4HANA Cloud implementation inside a very large company. We were paying insane hourly rates for consultants from a Big Four firm, and most of them were fresh out of college with no real-world experience in complex business operations. They were bright. They were not the problem.

The problem was arithmetic, and I couldn’t stop doing it. Why were companies paying premium rates for junior resources? Why wasn’t there a firm that combined deep technical expertise with actual operational experience?

That question turned into my company. But it isn’t really a question about my company, so let me make the general version of the argument — the one about how this market is built and why buyers keep complaining about the same things.

Knowing the platform is no longer a differentiator; certifications are everywhere and every firm has them. The real differentiator is whether the person designing your revenue recognition has personally closed a month. Traditional consulting economics work against that: firm profit is the spread between what a consultant costs and what they bill, multiplied by how many hours they bill. The model rewards putting the least experienced person on the most hours. You are not buying a logo. You are buying whoever is in the room on a Tuesday in month three.

Platform expertise is table stakes now

Technical capability is expected. Understanding NetSuite and being able to architect a solution inside it is the price of admission, not the differentiator. Anyone can sit for the certifications. My own team sits for them constantly. None of it tells a buyer anything useful, because everyone bidding on your project has it.

What separates good from great is understanding people, distilling complexity, and solving problems in a way nobody else in the room thought of. That comes from having been on the receiving end of a bad system — from having been the person who has to produce a number on the fifth business day whether or not the design supports it.

The executive who put this best was a chief accounting officer at a software company with a genuinely complicated subscription model. He’d been evaluating firms and struggling. Some were too large-scale for what his team needed. Others didn’t seem to grasp his business model at all. His revenue manager had just resigned and he was carrying the operational weight himself.

At the end of our first conversation he said: “You understand what I’m going through because you’ve been here. You’ve walked this path.”

He was right. I served as Controller at a public company. I dealt with the intricacies of subscription revenue recognition, complex billing structures, month-end close pressure, and scaling a finance function faster than the systems underneath it could scale. When one of our subsidiaries was cranking out more than 20,000 invoices a month in QuickBooks, it took a small army of AR specialists to keep it moving, and the system was constantly on the edge of collapse. I’m the one who raised my hand and said we need to implement NetSuite. Then I had to go do it.

I solved those problems from the inside. That’s a different thing from having studied them.

What does “done your job” actually mean?

It does not mean industry knowledge. Those two get conflated constantly, and the distinction matters when you’re writing a check.

We hired a consultant recently for her NetSuite experience, her accounting ability, and her consulting instincts. Nobody hired her because she knew anything about oilfield services. Then we put her on site with an oilfield services client and she started using all the right industry terminology, because it turned out she’d grown up around that world. Delightful coincidence. It was not the reason she got the job.

Industry vocabulary is learnable. A curious consultant picks up your jargon in a few weeks.

What isn’t learnable in a few weeks is the instinct that comes from having owned the output. It’s knowing, before anyone says it out loud, that the reason your close takes eleven days is not the close — it’s a decision somebody made about how orders get structured nine months earlier. It’s hearing “we just make a few adjustments at the end” and knowing exactly where that road goes: a top-side entry, meaning a manual adjustment made outside the system to make the reported numbers work, then a few more, and before long a shadow version of your books living in a spreadsheet.

So the question to ask a consultant is not “have you worked with companies like mine.” It’s: do you know my industry, or have you done my job? One gets you advice. The other gets you a partner who won’t let you fail.

Why the leverage model produces the outcomes buyers complain about

Here’s the part nobody says out loud, and I want to say it structurally rather than as an accusation, because it isn’t a moral failing. It’s a business model working exactly as designed.

Professional services firms make money on leverage — the ratio of less expensive staff to more expensive staff on an engagement — and on utilization, the share of a consultant’s available hours that get billed to a client. Margin is the spread between what a person costs you and what they bill, times the hours. Widen the spread, raise the hours, and the P&L improves.

I run a firm. I have a utilization number too. I’m not claiming to have repealed economics.

But look at what that math rewards. It rewards a pyramid: a senior person sells the work and appears at steering committees, and a much larger group of junior people delivers it. It rewards a standard methodology, because a methodology is what lets inexperienced people execute at all. And a standard methodology quietly requires your business to conform to it, rather than the solution being designed around your business.

That’s the mechanism behind the complaints buyers have been making for decades. The team that sold the project wasn’t the team that delivered it. We felt like a number. Poorly designed workflows got carried forward unchanged, locking us into the same inefficiencies on a new platform. Nobody was there after go-live, when the real work started.

None of those are failures of effort. They are what the model produces when it runs correctly.

The counterweight is worth saying too: Big Four training is genuinely valuable. Our Director of Consulting Services came out of public accounting with a controller’s lens, and finding someone with those roots and the systems mindset to architect complex ERP solutions is nearly impossible. The critique isn’t of the people. It’s of a staffing economy that bills a person’s second year of experience at the rate of someone’s fifteenth.

The uncomfortable question is the cheapest thing in the project

I’m not everyone’s cup of tea, and I’m more than okay with that.

I’m outspoken. I’m direct. I ask uncomfortable questions and say the quiet part out loud. Somebody once compared my requirements gathering to a Barbara Walters interview, and I took it as a compliment.

That style isn’t a personality quirk I’m defending. It’s the deliverable. Because the questions that feel rude in week two are the only ones that are still cheap.

The questions sound like this. Show me the spreadsheet you actually close from. Which reports get exported and adjusted before the board sees them, and who does the adjusting? How do you eliminate intercompany transactions today — meaning, how do you strip out the sales between your own entities so your consolidated financials aren’t overstated? Who reconciles the AP subledger in your ERP against the AP automation tool sitting next to it?

That last one isn’t hypothetical. During a business process review for one client, I pulled the accounts payable aging out of NetSuite and ran the same report out of the connected AP application. They didn’t tie. By more than a million dollars. Transactions had failed to sync and had simply accumulated, month after month, because nobody had ever told this company to monitor for synchronization exceptions or reconcile the two agings as part of the close. They had no idea.

That is not an exotic control. Any of us who have closed books know to tie a subledger to its source. But it only gets built into a close checklist if the person designing the process has ever had to sign off on one.

I see the same shape everywhere. Global companies that bought NetSuite and still run consolidated financials out of an Excel workbook, booking manual journal entries to compensate, because intercompany was set up wrong at the start. A client who designed a whole new purchase order approval flow without involving us; by the time we were engaged, we weren’t optimizing a process, we were undoing and rebuilding it.

Design decisions are the wiring behind the wall. You can paint over them and the room looks finished. You find out what’s back there the first time you need the load.

So yes, our process takes longer up front. We ask more questions than other firms, and we push back when clients want to skip steps that feel tedious but aren’t. We also write our assumptions into the quote — this assumes X, this is contingent on Y, if Z changes the scope changes — and we give a range of hours, because nobody honestly knows the full effort until design is done. I’d rather be upfront than win a deal with an artificially low number. Some firms sell simplicity to win the deal. The buyer pays for that fiction in change requests.

How do you test for this before you sign?

Four things, none of which require you to trust a proposal.

Ask the person who would design your revenue recognition to describe their worst close. Not a case study — an actual close, with a date on it. Someone who lived it will tell you what broke and what they did at 11pm. Someone who didn’t will answer with a framework.

Ask whether the team that sold the project is the team that will deliver it. Get names, in writing.

Talk to their clients, and ask specifically how supported they felt once the system was live and the real work began. That’s where the leverage model shows its seams.

And start small. You don’t have to go all in on day one. Run a focused engagement, evaluate the result, expand from there. A firm confident in its bench will take that deal.

The ruling

Platform expertise gets a firm into the room. It does not tell you anything about what will happen in your close, because everyone in the room has it.

What you’re actually buying is judgment — and judgment is the residue of having been accountable for the output. Scar tissue, gray hairs, whatever you want to call it. It cannot be certified and it cannot be delegated down a pyramid.

So ask who will be in the room on a Tuesday in month three. Then ask that person what their worst close looked like.

If the answer is a story, you’re in good hands. If it’s a methodology, you’re paying premium rates for someone to learn on your general ledger.

Questions people ask

How can I tell whether an ERP consultant has real operational experience?
Ask them to describe their worst month-end close. Not a case study, not a methodology, an actual close. Someone who has lived it will tell you what broke, what they did at 11pm, and what they changed afterward. Someone who has only read about it will answer with a framework. The difference is audible in about ninety seconds.
What is wrong with the leverage model in consulting?
Nothing morally. It's arithmetic. Firm profit is the spread between what a consultant costs and what they bill, multiplied by utilization. That math rewards staffing the most hours with the least expensive people and calling it scale. It works fine for repeatable work. Implementation is not repeatable work. The judgment calls happen in design, and junior staff have not seen enough to make them.
Does it matter if my ERP consultant knows my industry?
Less than people think. Industry vocabulary is learnable in a few weeks by anyone curious. What is not learnable in a few weeks is the instinct of someone who has closed books, sat through audits, and lived with a bad design for three years. Ask whether they know your industry or whether they have done your job. One gets you advice. The other gets you a partner.
When is the cheapest time to raise a hard question on an ERP project?
Design. Always design. A question asked during requirements gathering costs an hour of a meeting. The same question asked after go-live costs a rebuild, because by then you are not optimizing a process, you are undoing one. I would rather be uncomfortable in week two than be right in month nine.