The tracker was true the day it was saved. Then a truck left, a drawing came back with comments, the store issued material to the wrong zone’s neighbour — and forty WhatsApp messages carried the truth away. Now the tracker is a guess wearing a grid. Nobody failed: Excel is a calculator and WhatsApp is a walkie-talkie, and you were using them to run a factory and six sites.
Muthari OS is not a report about the work — it is where the work happens. The storekeeper receives against the PO and stock is simply correct. Production stamps a stage and the project page already knows. Site records installation and the claim already carries it. There is no update meeting, because there is no updating.
“Who typed that?” In Muthari the answer is: nobody. It came from a goods receipt, a stage stamp or an inspection — records your team already makes.
Keep Excel for analysis — every register exports to it. Keep WhatsApp for talking. Retire them from being your database.
This is not a discipline problem and it is not solved by a better template. A spreadsheet is a calculator with a grid, and five things it does not do are the five things a live project needs.
Either the file is shared and two people overwrite each other, or one person owns it and becomes the bottleneck every question queues behind. The moment a tracker matters, it is either contested or it has a single point of failure standing next to it.
Trackers get emailed, downloaded, renamed and worked on offline. Within a month there are four versions with plausible names and no way to tell which is current except by asking the person who made it — which is the phone call the tracker was supposed to prevent.
A spreadsheet has no referential integrity. “L08-E2”, “L8-E2” and “L08 E2” are three different zones to a pivot table and one zone to everyone on site. Quantities split silently across the spellings and the totals stay plausible, which is what makes it expensive.
There is no audit trail. When a claimed quantity is challenged six months later, the file shows the number but not its history, so the argument is settled by whoever remembers most confidently.
A spreadsheet will happily let you claim for a zone that was never delivered, issue material that failed inspection, or record production against a superseded drawing. It has no concept of sequence, so every rule that matters lives in somebody’s head and holds only while they are paying attention.
Underneath all five is one property: a spreadsheet stores values, not state. It was true the moment it was saved and it has been decaying ever since, and nothing in the file knows that.
Analysis. A one-off calculation, a rate build-up, a cash-flow model, a pivot to answer a question you will ask once. Anything exploratory, anything where the structure is the thing you are working out. Muthari exports every register to Excel precisely because that work is real and should keep happening there. The change being proposed is narrow: stop using it as the database of record, keep using it as the analysis tool.
Less than people expect, because there is no historical migration. You do not import three years of trackers. You take one live project, break its bill of quantities into zones, and start recording goods receipts and production stages in the system instead of beside it. The old tracker keeps running in parallel for a few weeks and you compare them — that comparison is the demonstration, and it usually ends by itself when the tracker stops being the one people check.
The honest cost is not the software or the setup. It is that the storekeeper, the factory supervisor and the site engineer each have to make their record in the system rather than on paper or in a message. If that does not happen, status stops being derived and you have bought a more expensive spreadsheet.