It's 10.30pm - an hour and a half before midnight, and about an hour before I'll wake both my wife and my 6 year old daughter so we can head up to the hotel rooftop and watch the Merdeka fireworks. A yearly tradition for about three years now.

The last few weeks I have literally been walking the floor of a business, designing the full architecture of a system that will end up taking over almost their entire operations. I'd started the long discovery last year. We're on prototype version 5 now, ironing out kinks and making refinements.

And a number of those kinks turned out not to be system problems at all. They were what I've come to call Workflow Scar Tissue.

There are other names for it, but it boils down to this: the humans in the team are completely reliant on - sometimes married to - one particular part of the process, without realising that the process was never a process. It was a workaround. Something they, or the team before them, or the team before that one, arrived at because of a problem or a limitation in a system that may not even exist anymore. And somewhere along the way, the workaround became the rule of law.

Two files, same data

I'm reminded of one from the very beginning of my work with SaaS.

At the time, our CRM ecosystem was taking over from the existing one, and while we had our standard features, we of course made sure to tailor them to the actual real-life workflows on the ground.

One of the teams had put this on the die-die-must-have list of requirements: every evening at 5pm, the system was to output two Excel files of the day's transactions.

Sounds normal enough. Except when I dug into it, the two files contained exactly the same data, and were going to exactly the same email address. The only difference was that one was arranged by transaction timestamp and the other by customer.

It took us three days of digging. The first thing we found was that nobody currently in the building knew why the requirement existed - only that it sat near the top of the SOP list marked high priority, and had for as long as anyone could remember.

What we eventually found was this. The requirement wasn't from the system I was replacing. It was from the system before that one - built more than a decade earlier - which had trouble updating transaction records and customer records at the same time. Partly, it turned out, because at the time those two updates were done by two different people in two different teams. Then one of those two people left. Only one set got updated. Reported transactions dropped for an entire month before anyone noticed.

And so the rule went onto the SOP chart, in capital letters, marked PRIORITY.

It was marked so high that the team who built the system before mine never questioned it either. They simply built the double-file quirk into their workflow, and that was that. Law.

It's everywhere, and finance has the best ones

Once you start looking for this, you see it everywhere. Finance and accounting seem to grow particularly impressive specimens, possibly because the consequences of getting it wrong are severe enough that nobody wants to be the one who touches it.

There's the early close. Books shut on the 25th, every month, everywhere in the group. It's in the calendar, it's in the SOP, new joiners are told it in week one and nobody explains why because nobody thinks it needs explaining - that's just when close happens. Which means five or six days of transactions get pushed into the following period, every single month, and the numbers everyone reports on and makes decisions from are quietly not quite the month they say they are. Finance knows, and manages it with a set of accruals and adjustments that one senior person really understands. The origin? Fifteen years ago, before the group standardised anything, the local figures had to physically reach the regional office by a fixed date. By courier. The 25th was working backwards from a courier schedule that stopped existing over a decade ago.

There's the parallel spreadsheet. When the ERP went in, one module miscalculated something for about four months, so somebody built a shadow reconciliation in Excel to catch it. The bug was fixed eight years ago. The spreadsheet is still maintained - by the third person to inherit it - and in the meantime two other departments have started pulling from it, because it's easier to get at than the ERP. So the workaround now has dependents. Killing it breaks things that have nothing whatsoever to do with the original bug.

And my favourite: the balancing entry. Every month somebody posts a small adjustment to make two systems agree. It's on the close checklist. It's called "the adjustment". Nobody currently employed knows what causes the variance, and the amount has drifted over the years without anybody treating that drift as information.

Why this matters now

None of the people in these stories are stupid. That's the part worth sitting with. Every one of these started as somebody solving a real problem with what they had in front of them, and every one of them was handed down in good faith by someone who was told it was crucial and had no reason to doubt it.

The problem isn't the workaround. The problem is that nobody ever went back.

And I think this matters more now than it did five years ago, because so many of us are in the middle of AI implementation. We are pointing genuinely extraordinary tools at our operations and asking them to make everything faster - and if you do that without questioning how you work and why you do things a certain way, all you have really done is automate the scar tissue. Faster. At scale. With a dashboard.

So it's worth asking, before you build anything: which of these do we have, festering quietly under the layers of workflow bandaid, waiting for somebody to finally ask why?

Right. The fireworks are in an hour.

Selamat Hari Merdeka!