Before writing any code for O9X, I spent weeks mapping how the business actually ran — not how I assumed it ran.
Every new software forces realignment. Old processes get questioned. Some deserve to be replaced. In an operations-heavy business, that realignment carries a hidden cost. You do not just remove bad processes. You also destroy the quiet workarounds teams built to survive the daily grind. That destruction creates resistance. And usually, that resistance is rational.
The Trigger Was Attendance — But That Was Not the Real Problem
Attendance failures were the visible crack. Violations discovered late. Too many systems. Too much time spent reconstructing what happened instead of preventing it.
But once I stepped back, I saw the deeper problem. My team was not spending time on important work. They were spending time reconciling between systems: WhatsApp, Excel, payroll software, Zoho Books, paper registers. Each system held a partial truth. None agreed fully. Every month, energy went into stitching reality back together. That is not scaling pain. That is structural leakage.
Code Freezes Behaviour
The most dangerous assumption in building internal tools is this: we broadly know how things work, we will refine later.
That assumption is how broken systems are born. The moment you write code, you freeze behaviour. Whatever you encode becomes the rule. Not a suggestion.
If the system does not match reality, people work around it, exceptions multiply, and trust in the system dies quietly. I saw this play out at Jio. A project management tool was deployed for real-time updates, but it was too rigid. Everyone quietly went back to Excel. Eventually, a dedicated person was hired just to keep the tool in sync with the spreadsheets.
Fixing that later is not a refactor. It is a political problem.
Departments Do Not Break Systems. Transitions Do.
Before mapping, I thought in departments. HR had one truth. Ops had another. Accounts had a third. Individually, each was right. Together, they were a disaster.
HR said the guard was marked absent in the attendance sheet. Ops said the guard was present at the site. Payroll asked: do we pay him or not?
Separately, they were all correct. Together, they created a collision.
My team had already built workarounds to handle these collisions — workflows that saved costs, got work done faster, and reduced immediate friction. These workflows were not scalable. But they worked.
When I started mapping operations, I did not just find inefficiencies. I found small optimisations the team had invented, workarounds that existed because systems were weak, and quiet payroll and compliance errors that could become serious problems during an audit. None of this came from malice. People did what they thought was right to keep things moving.
Why I Mapped Transitions, Not Features
I did not ask: what features do we need?
I asked everyone the same set of questions. What is our current workflow? How does data get fed into each system? What happens when there is a conflict between systems? How do we resolve it? Are we sure we are correct? Who gets blamed when it is wrong?
That is where reality leaks. Eighty per cent of the complexity was not the work itself. It was proving that one system’s truth matched another’s. If I had replaced the system without mapping these collisions, I would have destroyed the quiet optimisations my team built to survive.
Why I Did Not Outsource This
I did not hire a consultant. I did not assign this to a project manager. I did not ask AI for a process document. Instead, I spent time talking to Operations, HR, Accounts, and Field Coordination — not to extract flowcharts, but to understand where reality diverged from policy.
At every step, I asked: where does this break? What happens when someone is absent? What do you do when the system does not support the situation?
As I refined the workflows, I took them back to the teams to discuss what changed, why it changed, and what risks it removed. This was not documentation. It was threat modelling for the business. Because if this knowledge stayed only in people’s heads, it would decay, it would be lost with attrition, and people would revert to old habits under pressure.
The Risk I Was Avoiding
The risk was not that I could not buy or build software. The risk was building a fast, modern system that executed the wrong process with confidence.
I did not want an ERP that looked clean but hid risks. One that forced teams to abandon necessary workarounds blindly. One that continued manual processes even when a system was in place. One that scaled compliance mistakes at speed.
If the new system did not match reality, trust would die. So before any code, schemas, or frameworks, I needed to understand exactly what I was freezing into the business.
I mapped operations before writing code because code does not fix confusion — it multiplies it. Only after that mapping did it make sense to design the scaffold.