The workaround was the business case

What a homemade "ELN" taught me about digitalization, and why the hardest barrier to change is almost never the technology.

I didn't expect to meet this question in 2026: why change?

But there it was. I was working with a long-established pharmaceutical company — a place with real scientific depth, a business that worked, and a lab organization that had quietly decided it was already digital. It wasn't a naïve assumption. They had files. Every file had an ID. Everything lived in a system. From the inside, that looks like digital.

It isn't. And the gap between those two things turned out to be the whole story.

Digitized, not digitalized

Their day-to-day was built almost entirely around paper. The most advanced thing in the setup was a document management system — the kind of tool meant for storing controlled documents — which they had bent into something else. Bottom-up, without anyone signing off on it as a strategy, they had built a file structure inside that system to hold their laboratory notes. And they had given it a name: their ELN. Their electronic lab notebook.

It wasn't an ELN. It was a filing cabinet with better search. But the naming is the part I keep coming back to, because it tells you something the org chart never would.

This is the distinction that matters, and most people blur it: digitization is turning paper into files. Digitalization is turning work into data. Scanning a worksheet and giving it an ID is digitization — you've made the paper electronic, but the information inside it is still locked in a document a human has to open and read. Digitalization is when the result of an experiment becomes structured, queryable, connected data the moment it's created, flowing from instrument to system without a person retyping it in between.

They had done the first and called it the second. And honestly — it worked. The business ran. Science progressed. New medicine got made. When something works, the cost of how it works becomes invisible.

The invisible cost

That cost was real, it was just scattered. Instruments in these labs already produced perfectly good digital output. But the results were printed, and then transcribed by hand, and then transcribed again — three to five times before a number reached a controlled record. Every one of those hops was a place for an error to enter, and unsurprisingly, manual transcription was the single largest source of their data-integrity problems.

You could never see this cost in one place. It didn't show up as a line item. It lived in hundreds of tiny, ordinary actions across every department — a few minutes here, a re-check there, a report re-keyed into a slightly different format for the next team. Distributed like that, the total was enormous and completely unaccounted for. Nobody was doing anything wrong. The system was simply built to hide its own price.

The workaround was the answer

Here's the turn that reframed the whole engagement for me.

When a team builds a workaround, it's easy to read it as a small failure — a gap someone patched over. I've come to see it as the opposite. A workaround is a business case in disguise. People don't invest effort improvising a tool unless the need is real and unmet. By building a homemade "ELN" out of a document management system, this organization had already proven, with their own hands and their own time, that they needed a real one. They'd written the requirements document. They just hadn't realized that's what they were doing.

Calling a file structure an "ELN" wasn't confusion. It was a genuine need surfacing on its own — unmet not because the people weren't capable, but because they'd had little exposure to what the lab-IT landscape looked like beyond their own walls. They were solving the right problem with the only materials they could see. The value of an outside perspective wasn't to tell them they were behind. It was to show them that the thing they'd already built by hand had a name, a category, and a mature market of real solutions.

The barrier that was structural, not technical

The technology question, it turned out, was the easy one. The recommendation I landed on was deliberately unflashy: a proper LIMS and ELN core, data governance designed in from the start rather than bolted on later, and instrument connectivity phased in by value rather than attempted all at once. Nothing exotic. A benchmarked, sensible architecture that any good lab of their size should recognize. The point was never novelty. The point was a target the whole organization could stand behind.

The genuinely hard part sat somewhere else entirely.

The hardest barrier was structural, not technical. Technology ownership sat with central IT, while the business ran the science — which meant the people closest to the day-to-day work had limited say in the systems that shaped it. That's not unusual in organizations of this heritage, and it isn't anyone's villainy. It's an operating-model pattern: decision rights for technology living in one place, and the value those technologies serve being created in another. But it's exactly the kind of misalignment that quietly stalls a transformation until someone names it out loud. Change here was never only a question of funding. It was as much a question of who owned the outcome.

Why start with people, not systems

All of this is why I don't start these engagements with technology. I start with people and process, and I only let the technology conversation begin once I understand how the work actually flows.

So I interviewed every department and mapped what they really did — not the tidy version on a process diagram, but the messy, real sequence of steps. Then I did the part that made everything else click: I generalized. Underneath the surface variety, the same handful of workflows recurred everywhere. Once you can see that, two things become possible. You can assess honestly which systems would touch which work, and where. And you can show a room full of departments — each of which had privately assumed it was too small and too particular to be worth the investment — that they are not a handful of separate problems. They are one organization, running variations on a shared set of workflows, and the case for change is a collective one.

That reframe is what turned a technical plan into something with momentum behind it. Not a tool someone was trying to sell them. A direction they could see themselves in, and choose to fund.

What I'll be watching

If I'm honest about where this goes next, my prediction is this: the hardest barrier for this organization will be structural, not technical. Because technology ownership sits with central IT rather than the business running the science, the people closest to the work have limited say in the systems that shape it. Progress will depend as much on aligning governance as on funding or lab-IT insight. The architecture is the part I'm least worried about. Whether the business and IT can agree on who owns the outcome is the part that will decide it.

What I took from it

The lesson I carry out of this one is simple, and it generalizes far beyond a single lab.

If you want to know where an organization should invest, don't start with the roadmap. Look at the workarounds. Look at the thing people built by hand because they needed it badly enough not to wait for permission. That homemade tool, with the slightly-wrong name, is the most honest requirements document you'll ever find — a need that surfaced on its own, priced in real human effort, waiting for someone with an outside view to recognize it for what it is.

They thought the question was why change. The workaround had already answered it. The only thing left was to help them see it.

If you're wrestling with a lab or process-development organization that's drowning in files but starving for data, this is the kind of problem I love. Get in touch.