I started my career as a consultant.
Like many consultants, I was trained to think in terms of requirements, business processes, system design, configuration, testing and delivery. We worked closely with Finance teams, listened to what they needed, translated their requirements into systems, and then moved on to the next project.
I thought I understood Finance.
Then I left consulting and joined a Finance office.
That was when I realised that understanding Finance from the outside and actually living Finance are two very different things.
And years later, when I returned to consulting, I found myself looking at EPM solutions through completely different eyes.
There were three shocks during my time in Finance that fundamentally changed the way I think about consulting.
Shock #1: A number is never just a number
One of my earliest lessons came from my Finance Director.
We were reviewing a set of numbers, and something simply did not look right. We went through the figures, challenged the assumptions and tried to understand whether the result made sense.
At one point, my Finance Director looked at me and said:
“Jasmine, if the number is really like this, you and I should go home and become millionaires.”
That sentence has stayed with me.
As a consultant, I had always been very focused on whether the calculation was technically correct.
But in Finance, a number has a meaning.
A revenue number tells a story about the business.
A cost number can tell you whether an operation is under control.
A variance can tell you that something happened somewhere in the organisation that management needs to understand.
A forecast can influence a CEO’s decision.
A single number can therefore trigger a chain of questions:
Why is it like this?
Is it correct?
What is driving it?
Can I explain it?
Can I trust it?
What decision should I make because of it?
That was a major shift in my thinking.
As a consultant, I had been trained to make the system calculate the right answer.
Working in Finance taught me that the real objective is bigger:
The system needs to help Finance understand whether the answer makes sense.
Shock #2: A budget deadline changes everything
The second shock came during a budget cycle.
Anyone who has worked in Finance knows that a budget deadline is not an ordinary deadline.
It can be late at night.
The CEO wants the numbers changed.
The CFO wants to see the impact.
The business wants the budget closed.
And someone suddenly says:
“Can we put another 5 million here?”
This is where theory meets reality.
I remember being in the middle of a budget deadline, trying to find where to put a top-down adjustment that would reflect exactly what the CEO wanted.
On paper, this sounds simple.
In a well-designed model, it should be simple.
But when you are actually sitting in Finance at midnight, you realise how important the model design really is.
Where should the adjustment sit?
At the company level?
At the business unit?
At the department?
At the account?
Should it be allocated?
Should it override the bottom-up plan?
Should it be a separate assumption?
And, perhaps most importantly:
After making the adjustment, can I still understand where the number came from?
That experience changed my view of “good modelling”.
A model is not good simply because it can produce the answer.
A good model needs to allow Finance to intervene when the business changes its mind, while still preserving the logic and traceability behind the number.
Because Finance does not operate in a perfect world.
The CEO may change direction at 11:30 p.m.
The CFO may ask for a different scenario at midnight.
A business leader may challenge an assumption five minutes before the deadline.
The model needs to survive that reality.
That was something I understood much more deeply after becoming a Finance user myself.
Shock #3: Hunting for a number is harder than I thought
The third shock was probably the most important one.
Before working in Finance, I used to think:
“If the number is wrong, just trace it back.”
Simple, right?
Not always.
When you start tracing a number through a real organisation, you may follow it from a report into a cube, from a cube into a mapping, from the mapping into an ETL process, from the ETL into a source system, and then further into another source.
You start chasing the “fox” into the forest.
And sometimes, you don’t just lose the fox.
You get yourself lost in the forest.
That was when I truly appreciated how important usability and transparency are in an EPM solution.
A Finance user should not need to understand the entire technical architecture just to answer a simple question:
“Why is this number here?”
This experience also changed one of my personal habits.
I became almost obsessed with using thousand separators.
1,000,000 is much easier to read than 1000000.
10,000,000 is much easier to distinguish from 1,000,000.
When you are working with millions and billions of numbers, formatting is not cosmetic.
It is part of control.
When you are tired, under pressure and trying to find a problem at midnight, a small design decision can make the difference between understanding something immediately and spending another 30 minutes figuring out what you are looking at.
I honestly felt that if I stopped using thousand separators, I might not survive Finance.
And that may sound like a small thing.
But it represents a much bigger lesson:
Good system design respects the person who has to use the system.
Coming Back to Consulting
Eventually, I returned to consulting.
But I was no longer the same consultant.
Before my Finance experience, I tended to look at an EPM solution from the perspective of:
“Can we build it?”
After working in Finance, my questions became:
“Can Finance actually use it?”
“Can they understand the number?”
“Can they challenge the number?”
“Can they trace the number?”
“Can they make a last-minute adjustment without breaking the model?”
“Can they explain the result to the CFO or CEO?”
And perhaps the most important question:
“What happens when they are using this system at 11:47 p.m. on the night before the budget deadline?”
That is when I realised that the best consultants are not necessarily the people who know the most technical tricks.
They are the people who understand what it feels like to sit on the other side of the table.
Consulting taught me how to build solutions.
Finance taught me why those solutions matter.
And returning to consulting gave me the opportunity to bring both experiences together.
Today, when I design an EPM solution, I try not to think only like a consultant.
I try to think like the Finance person who will eventually inherit the model.
The person who has to explain the number.
The person who has to find the problem.
The person who has to make the adjustment.
The person who has to answer the CFO’s question.
And sometimes, the person who is still sitting in front of the screen at midnight.
Because ultimately, an EPM solution is not just about getting the number right.
It is about making the number understandable, traceable, controllable and useful for making decisions.
That is probably the biggest thing my journey from consulting to Finance and back to consulting has taught me.