When I was 17, I used to help my neighbour Vic work on his AMC Javelin. Sort of.
One day he told me to get him an "American screwdriver." I had no idea what he meant, so after looking around the shed for something that presumably only Americans used, he eventually pointed at the hammer.
That was the American screwdriver.
It was actually a pretty good tool. Not necessarily the right tool, but you'd be surprised how many problems could be solved with it.
A few years later, when I was 21, I was introduced to Business Intelligence for the first time. I remember somebody explaining what it did, and I asked what seemed to me like an entirely reasonable question.
"Why can't we just report from our million-dollar ERP?"
There were good answers then and there are even better answers now. ERP systems are designed primarily to process transactions. Analytical workloads are different. BI gives you better modelling, much better visualisation, more analytical freedom and the ability to combine information from multiple systems.
All true.
I still didn't particularly like the answer.
I've had much the same relationship with planning and budgeting software for most of my career. We already have the actuals. We already have the chart of accounts. We already have the organisational structure, customers, products and most of the things describing the business. Why do I need another system, another model and another collection of mappings before I can put a budget next to it?
After nearly three decades working with ERP systems, I obviously understand the answers considerably better than I did at 21.
But I never completely lost the question.
Another hammer
Years later I had a boss called Chris. At the time I had developed a habit of finding increasingly creative uses for a particular function to solve a problems it was notdesigned to solve.
Chris remarked to someone about this, "Give a man a hammer and every problem starts to look like a nail."
He had a point.
If you've worked with NetSuite for long enough, there is another hammer you become extremely familiar with: Saved Search.
Need an exception report? Saved Search. Need something on a dashboard? Saved Search. Need to answer some peculiar question nobody thought about when the system was implemented? There is a pretty reasonable chance somebody is going to suggest a Saved Search.
It's hardly the bleeding edge of modern analytics.
But if that's the hammer you've been given, after a while you get pretty good at swinging it.
Then I didn't have a choice
Earlier this year I started working with a business that needed better financial reporting, and not slightly better financial reporting.
We needed weekly management reporting, proper business classifications, budgets, prior-year comparisons and eventually a Board Pack. The existing reporting architecture wasn't going to get us there.
There was no BI platform sitting there waiting for me to solve it. There wasn't a planning and budgeting platform either. More importantly, there wasn't a budget for me to go shopping for them.
The job was basically: make it work with what we've got.
So I reached for the American screwdriver.
Initially that meant all the usual things. Saved Searches, SuiteAnalytics Workbook, custom records and some scripting. Nothing particularly revolutionary.
But as the reporting became more sophisticated, something started bothering me. I kept having to teach every new report the same things.
What is Sales? What is COGS? What counts as Employment? Where do rebates belong? Which sign should this account have? How does management want this part of the P&L classified? What exactly constitutes the comparable period last year?
The answers existed. That wasn't really the problem.
The problem was that every new report needed to know them.
And once I saw that, I started to think I might be solving the wrong problem.
What if the report didn't have to know?
ERP data isn't badly designed. Transaction tables are shaped the way they are for very good reasons.
They're just not necessarily shaped around the questions management wants to ask.
So instead of continuing to make the reports smarter, I started changing the shape of the data they were reporting on.
The complicated accounting and business rules could be applied once. The resulting facts could be persisted in a much simpler form and then reused.
A week. A site. A customer group. A category. An amount. A budget. A prior-year amount.
Nothing particularly exciting.
In fact, that became the objective.
I was trying to make the data boring.
And once the data became boring, something interesting happened.
The reporting tools started mattering less.
Wait. That's a Saved Search?
Once I had the data in the right shape, I could start asking questions that I'd never seriously have considered answering from a NetSuite Saved Search before.
How is the composition of the P&L changing over time? Which costs are becoming a larger percentage of the business? Which are shrinking? As sales grow, which costs are growing more slowly? Where are we actually getting operating leverage? Which parts of the cost base are moving in the wrong direction?
These aren't exotic questions. They're exactly the sort of questions a CFO ought to be able to ask.
They're just not questions I'd normally expect to answer particularly elegantly from a NetSuite Saved Search.
Except now I can.
Not all of them. Not perfectly. And certainly not with the analytical freedom I'd have in Snowflake, Power BI or another modern analytical platform.
But enough that it made me stop and think about what had actually changed.
I hadn't made Saved Search any smarter.
I'd made its job easier.
That's a pretty important distinction.
The irony
The funny part is that this experience has probably given me more appreciation for BI and planning platforms than I had during the previous 25 years.
I finally like them.
Give Snowflake, Looker, Power BI or a good planning platform clean, governed data and they can do extraordinary things. There are plenty of analytical problems I wouldn't even attempt to solve inside an ERP, and there are plenty of perfectly sensible reasons to move data somewhere designed specifically for analytics.
But being forced to work without those tools taught me something as well.
We sometimes ask downstream technology to solve complexity that doesn't necessarily need to arrive downstream in the first place.
Every time we do that, somebody has to recreate the meaning. Somebody has to remember what the accounts mean. Somebody has to rebuild the classifications. Somebody has to maintain the mappings. Somebody has to make Actual, Budget and Prior Year agree.
Then we build increasingly sophisticated technology on top of it.
The fancy chart at the end was never really the hard part.
Getting everyone to agree about what the numbers mean was.
And that is ultimately where my little reporting exercise ended up becoming something much bigger. The rules became a Semantic Map. The financial facts became SpeedLedger. Weekly operational comparisons became Weekly Facts.
None of those things were really about replacing BI.
They were about making the data underneath BI, NetSuite, Excel, AI or whatever comes next easier to consume.
So was 21-year-old me right?
Not really.
You can't replace a modern analytical platform with a Saved Search, and I certainly wouldn't recommend trying.
But I think the annoying 21-year-old asking why we couldn't report from our million-dollar ERP may have been asking a better question than I gave him credit for.
Maybe the answer shouldn't always begin with another reporting platform.
Maybe the first question should be:
What would the data need to look like for this question to become easy?
Because if you solve that properly, something useful happens.
The same governed facts can be consumed by a Saved Search or SuiteAnalytics Workbook today, Excel tomorrow, Snowflake or a planning platform somewhere else, and increasingly an LLM asking questions about the business.
The consumer can change without everybody having to reinvent what the numbers mean.
At 16, Vic taught me that a hammer could also be an American screwdriver. Years later, Chris warned me that if you give a man a hammer, every problem starts to look like a nail.
Both lessons stuck.
But this year I learned another one.
Sometimes you don't have the budget for another tool, so you work with the hammer you've got.
And every now and then, being forced to do that makes you realise you were trying to solve the wrong part of the problem.