I did not start with long workshops. I did not block calendars. I did not ask everyone to align. I started alone.
Not because collaboration is bad — but because unstructured discussion at the start wastes time and hides gaps in your own understanding.
I Started With What I Already Knew
Before talking to anyone, I mapped the workflow as I understood it. This forced an uncomfortable check: what do I actually know, and what am I assuming?
I set a hard boundary early. This exercise covered operations only. No sales, no marketing, no growth narratives. O9X was not being built for scale. It was being built to keep the business running and compliant.
One Unit. One Lifecycle.
I chose a single unit of reality: one guard. From the day a field officer identifies him for deployment to the day he exits the system.
I traced onboarding and document collection, training and supervision, daily attendance, customer approvals, customer issue resolution, personnel training, and the final data flow into Zoho Books for invoicing.
I did not map departments. I mapped time. Because ERPs do not break inside modules. They break across transitions.
I Mapped Days, Not Roles
Instead of starting with org charts, I asked a simpler question: what does a normal day actually look like?
I followed a field officer’s day, office operations, payroll, and HR. That is when the real gaps appeared. The same event meant different things to different teams at different moments. That mismatch is where disputes, delays, and compliance failures are born.
Map First. Talk Second.
Once my version was on paper, then I spoke to people. This order mattered. Instead of open-ended discussions, I could ask: this is how I think this works — where am I wrong?
I kept it constrained. One day per team. A pause to let patterns settle. One joint discussion where assumptions were challenged. Operations and field reality came first. Compliance was non-negotiable. Everything else was flexible.
Good Workarounds vs. Dangerous Ones
This is where the mapping paid for itself. I found two kinds of deviations.
Some were clever shortcuts — teams adapting to weak systems to save time and cost. Others were quiet risks. The biggest one surfaced in overtime calculation. Operationally, the method worked. Legally, it did not. If audited, we would be exposed to penalties.
The team was not careless. They were compensating for a broken tool.
I fixed the immediate problem manually. But I also knew the truth: if this rule stays in people’s heads, it will break again. And I could not wait for the payroll vendor. Their backlog is not my emergency. This judgment had to live in my system.
From Reality to Structure
Once the lifecycle was mapped, the next step was clear. I needed to see whether this reality could exist without contradiction. Not features. Not screens. Structure.
I built just enough structure to test who owns what, when state changes, and where responsibility shifts.
This was not engineering. It was validation. Without it, any project brief would have been fiction.
Why I Did This
I did not map operations to document the business. I mapped them to remove ambiguity, expose risk, and decide what judgment the system must own.
Only after that did it make sense to formalise anything. That is where the design of O9X could begin.