Why digital transformation is an act of translation, not installation.
Ask three people in the same company how an invoice gets approved, and you will often get three different answers. None of them is lying. Each one is accurately describing the system as they experience it. The real system, the complete one, lives somewhere between their answers, and nobody has ever seen it in full.
After years of building software and automation for businesses, this is the observation I keep returning to: every business is already running software. It is just not written in code. It is written in habits, spreadsheets, inboxes, verbal agreements, and the memory of whoever has worked there the longest.
We talk about companies as “digital” or “not digital,” but that distinction describes the storage medium, not the existence of a system. The logic always exists. A business that has survived ten years has pricing rules, escalation paths, quality checks, and exception handling. All of it runs daily, reliably enough to keep the company alive. The system simply happens to be stored in people instead of machines.
Once you see this, you start noticing the architecture everywhere. The standard procedure is a function. The “always check with Funke before sending anything above two million” rule is conditional logic. The veteran employee who knows every customer’s history is a database with one fragile backup. The email thread where approvals happen is a message queue. The workaround everyone uses but nobody documented is a patch, deployed years ago, author unknown.
If it is not written down, it is stored in someone.
This is not a metaphor I use to make technology sound friendlier. It is a literal description, and taking it literally changes how every project that follows should be approached.
Why automation projects really fail
Here is a story that repeats across industries. A company decides to modernize. It buys a tool, commissions custom software, or subscribes to a platform. There is an announcement, a training session, a few weeks of genuine effort. Then, quietly, people drift back to their spreadsheets. The tool becomes a monument. Eighteen months later, someone proposes replacing it with a different tool.
The usual explanations are resistance to change, poor training, the wrong vendor. Those are sometimes factors. But the deeper cause is almost always this: the new software encoded a version of the process that never actually existed.
It was built from the official description: the process as it appears in documentation, or as a manager describes it in a requirements meeting. But the official description and the lived system are two different artifacts. The lived system contains the exceptions, the judgment calls, the unwritten rules that make the work actually work. When software ignores those, it does not feel like an upgrade to the people using it. It feels like a downgrade that management is enthusiastic about.
Both drawings describe the same invoice.
You cannot automate what you do not understand. You can only accelerate it. And accelerating a misunderstanding means executing it at scale: faster, with more confidence, and with fewer humans positioned to catch the error.
The exceptions are the process
There is a naive model of software cost that says the expensive part is building it. Anyone who has built systems for real organizations knows the expensive part is discovering what the organization actually does.
And the discovery that matters most is rarely the main flow. The main flow is easy; anyone can describe the happy path. The real specification of a business lives in its exceptions. Every sentence that begins with “well, usually we do this, but if the client is government, then…” is a business rule. It has been enforced for years. It has financial consequences. And it has never been written down anywhere, because it never needed to be. The people executing it simply knew.
This is why building software is such a clarifying exercise, even before the software exists. A machine cannot follow the instruction “use your judgment.” So the act of specifying software forces a business to articulate its judgment precisely, often for the first time in its history. I have sat in specification meetings where colleagues who had worked together for a decade discovered they had been applying different rules to the same situation the entire time. The contradiction was always there. It was just distributed across two people who never compared notes.
Digitization does not create a system. It reveals one.
Reading the invisible system
Because of all this, the first phase of serious technology work has very little to do with technology. It is closer to archaeology.
The most useful technique I know is to trace one real transaction from beginning to end. Not “walk me through your process,” because that question produces the official description. Instead: take last Tuesday’s actual order, one specific invoice, one real customer complaint, and follow it through every hand it passed through, every tool it touched, every delay it sat in. Including the part where someone walked to another desk to ask a question. The distance between that trace and the official description is where all the important information lives.
Failure is another honest teacher. Asking “what happened the last time this went wrong?” reveals more about the real rules of a business than any process diagram, because recovery procedures are the rules people actually trust.
Then there is the unofficial spreadsheet. Nearly every organization has one: the file nobody formally owns, built years ago by someone, quietly depended on by everyone. That spreadsheet is not clutter. It is the system compensating for what the official tools cannot do, and it is often one of the most accurate documents in the company.
And finally, there is the person whose vacation breaks things. Whatever that person holds in their head is critical infrastructure with no redundancy. Finding it is not a documentation exercise. It is risk management.
What digital transformation actually is
All of this leads to a quieter definition of digital transformation than the one usually sold.
Digital transformation is not installation. It is translation, the migration of operating logic from biological storage to digital storage. And like any serious translation, its consequences go beyond convenience. Logic that lives in code can be inspected, questioned, measured, and improved deliberately. Logic that lives in habit can only be inherited.
This is also why the process is uncomfortable. Making a system visible means exposing its contradictions, and a company meeting its own real system for the first time is rarely flattered by what it sees. But that confrontation is where the value is. Some of the most successful projects I have been part of delivered their biggest return before launch: the shared understanding the company built while specifying the software changed how people worked, regardless of what eventually shipped.
The companies that transform successfully are not the ones that adopt the most technology. They are the ones that understand their own system well enough to teach it to a machine.
So before asking which tools to adopt, ask a better question: what system are we already running? Where does it live? Who carries it? What does it do when something unusual happens?
Before you write a single line of code, read the system you already have. It has been running in production for years.
