Spreadsheet hell, and the year we stopped looking backwards
By 2010, “quality management” mostly meant one thing: hoping a number typed into a spreadsheet three shifts ago was still there when you went looking for it.
I was quality manager at a growing fuel cell manufacturer in Sussex, and growth had quietly outpaced the tools we were using to run the factory floor. We had several processes and checks per serialised product and thousands of records a week, all of it resting on people remembering to type things in correctly, and nothing catching it when they didn’t.
Fixing it meant replacing spreadsheets with a proper system: my first real systems integration project, and the first time I had to get an ERP, an MES, and the machines themselves mapped to understand each other.
This is that story.
The situation
In late 2010, I was quality manager at a fuel cell manufacturer in Sussex. The company was growing fast, and our quality management and work-in-progress tracking system hadn’t grown with it. It ran entirely on spreadsheets.
That sounds manageable until you picture the scale. Every product was serialised, and every order had to tracked through several manufacturing processing steps with separate quality checks. Multiply that across a growing production line and you get tens of thousands of records typed in by hand.
We were losing trust in the data itself. Entries would vanish, a computer switched off before saving, a value typed over by mistake as sheets were shared, copy of a copy becoming the new master file. As the checks were manual, a missed observation at the point of production often couldn’t be reconstructed afterwards. If it wasn’t captured properly the first time, it was gone.
The problem underneath the problem
The real issue wasn’t that spreadsheets are a bad tool. It’s that we were asking a tool built for calculation to do the job of an enforced process. Nothing stops a step being skipped, a field left blank, a file closed without saving or being overwritten.
We also had a reporting problem that was the same problem in disguise. Collating and publishing the data in a meaningful way took half a day, so we only did it weekly: meaning any trend we spotted was already a week old. We weren’t managing quality in real time. We were managing it in hindsight.
What we did
We concluded that what we needed was a Manufacturing Execution System (MES); something built to enforce data capture at the point of production, rather than rely on someone remembering to do it right. We evaluated specialists and, by mid-2011, settled on Lighthouse Systems (now Infor MES). The new system went live in March 2012.
The technology was the “easy” part. What made it work was broader than that:
The first was involving the operators early. They’d be living with this system every day, so we brought them into decisions like screen layout rather than handing them a finished product. We also ran extensive training and communication programmes, so people understood not just how to use it, but why we were moving away from the old way.
They clearly weren’t used to being asked. I remember asking one group what colour they wanted the screen background. They were genuinely taken aback the question was even on the table, and half as a dare, said purple. We obliged. A week later they asked, rather sheepishly, if we could change it, because it was giving them headaches. Small moment, but it told me the engagement was landing.
The second was reducing how much depended on typing at all. Where the old process was entirely manual, the new one captured data through barcode scanners, pulled information from our ERP system, and communicated with machines directly via OPC. People were still very much involved; there were just far fewer points where an incorrect keystroke could quietly become a Data Quality issue.
Getting the ERP and MES to actually talk to each other wasn’t quick. After a few rounds of back-and-forth between the two vendors with little progress, an in-person session was scheduled. With all the required parties in the room and an ultimatum: “nobody was leaving until it was clear what needed doing to get the systems integrated”; we got somewhere. Sometimes the fix for an integration problem isn’t more emails: it’s putting everyone in the same room until the ambiguity has nowhere left to hide.
What changed
The most obvious change was trust: assurance that the data we needed was being captured and retained, rather than hoped for.
The less obvious change, and the one I think mattered more, was speed. Reporting that once took half a day, once a week, became available on demand, every day. Instead of reviewing what had gone wrong a week after the fact, we could act on it while it was still happening. We went from looking backwards to operating at the speed of the business itself.
What I learned
This was long before I had language like “semantic interoperability” for what we were doing. But it was the same problem I keep meeting in different clothes: data existing somewhere in an organisation isn’t the same as data the organisation can trust and act on. We had no shortage of records in 2010, what we lacked was confidence they were complete, accurate, and available when needed, which for any practical purpose is the same as not having them at all.
The other lesson was about the operators. It would have been easy to treat this as a purely technical migration: pick the software, configure it, switch it on. The training, communication, and early involvement of the people who’d actually use the screens wasn’t a nice-to-have at the edges. It was a large part of why the system stuck rather than becoming something people quietly worked around.
Part of why that engagement mattered is a lesson I learned the hard way: what a process map says happens, and what actually happens on the floor, can be quite different. Not the sequence, which tends to be right, but small efficiencies operators find for themselves that never make it onto a diagram. A new system had to accommodate those, or it slows the process down rather than speeding it up. You only find them by asking the people doing the work.
I didn’t know it at the time, but this was my first hands-on brush with what I’d later call the semantic layer problem: getting an organisation’s systems, and the people feeding them, to agree on what the data means and how it should be captured. Fittingly, my first real integration project was also the first time I had to get an ERP, an MES, and a set of machines speaking via OPC onto the same page: different protocols, different vocabularies, describing the same production line. I’ve been circling that question ever since.
