Why do Digital Transformations fail? Part 1: what does a pack number even mean?
Digital transformations are more known for their failures than their successes. Blame is typically attributed to the technology, whilst other aspects such as organisational and cultural readiness are rarely considered dimensions. The usual story goes like this: the organisation buys a platform, development and deployment turn out harder than the sales deck suggested, the budget stretches, and in the end everyone agrees the technology wasn’t quite ready.
I’ve never quite believed that. For me, digital transformation as a sub-category of change management, and it fails when only the technology is considered. Even the work that’s meant to put people first, UX and UI development, tends to focus on the technology and not so much on the U. Human-machine interaction is a whole area that can go undeveloped when the focus is functionality. If it functions but users can’t interact with it, what’s the point?
I’ve just finished a 100-page dissertation on semantic interoperability, I won’t attempt to summarise it in a post. So this is part 1 of n. I’ll start with a small, concrete example and work outwards.
The tools aren’t the gap
Connecting systems is a mature field. Federation protocols exist. Ontology languages exist. Schema mapping tools exist. You can move data between platforms, query across them and join as needed. If two enterprise systems fail to work together today, it’s rarely because nobody has worked out how to connect them. And yet programmes still stall. So if the tools aren’t the gap, what is?
The gap is in the people who built the systems
My working answer is that the meanings inside the systems were never reconciled by the humans who built and those who use them. Here is an example from the MES I work with: batches and serial numbers are both held in a field called pack number. Whether a given pack number identifies a single unit or a whole batch depends on how the part is configured, and that configuration isn’t visible to most users. The mapping exists, but only a few privileged users can see it, normally those the administrators or super users and are more proficient than a regular user just trying to find a part, or a production order.
The same system has something called “lot control”, which when enabled, matches the work order number, standard stuff! For batch traceability, those are effectively the same thing. In the integration to ERP, the field that carries all this across is called “external pack number”. I still don’t know why, it probably made sense when the integration was decided.
Nothing broken here, the join works, but users also bring their own perspective and understanding. Without more visible mappings, incorrect interpretations can be made.
Why nobody catches it?
This is the part I find hardest, the failure doesn’t announce itself. Nothing crashes, the system returns a number and this number might even look reasonable, and a decision is made. When someone says “that doesn’t match what I see”, and a long, tiring conversation begins about whose data is right. Usually neither is wrong, they were simply talking about different things under the same name.
Some people are vague and casual in their wording, perhaps because they deliberately want to stay at a more operational level rather than getting “into the weeds”, or perhaps because they don’t grasp the difference and its significance. From the outside, I can’t tell. What I do know is that more precision would save a lot of time.
What helped me, and what I’d try
I’ve written before about getting an ERP and MES to integrate and how a session with the vendors was needed until all the ambiguity was spelled out and mapped. Shared meaning is not the same as agreement. The goal isn’t to make everyone understand “pack number” or “batch” in one identical way. It’s a reliable, explicit mapping between the understandings, kept somewhere the people who need it can read it. In my example, the mapping exists but it’s invisible to the users. That makes it a translation problem rather than a persuasion problem, and translation needs things a technology budget rarely pays for: time for people from different functions to say what they mean, someone tasked to map up all, and an owner who keeps it current when the business changes.
Where this is going
The conclusion of my dissertation fits in one line: interoperability is a socio-technical challenge, not just a software integration.
The pack number is a simple example. The software side works, the social side: who knows what the field means, who sees the mapping, who notices and asks, is where it goes wrong unless deliberately planned. If the problem is meaning, more tooling won’t solve it, and buying the next platform may only move the same disagreement somewhere new.
That is why my own attention has turned to ontology development. For the last few months, it’s been a bit of an obssession, and it sounded alien when I started asking around. Slowly, people are beginning to see the need. An ontology externalises meaning and relationships, so that conversations can be better grounded, between humans and, lately AI models too. Without it, those associations are inferred, and we all have “lost in translation” experiences to tell.
That is where part 2 will pick up. For now, a question for you: in the last transformation you were part of, was there a point where someone sat down and wrote what the key terms meant to each group? Or did the project start from the assumption that the words were already shared? My bet is that the latter is more common.
