Why Digitalisation Needs a Bottom-Up Approach

Imagine two technology companies bidding to supply manufacturing software to the same industrial organisation. The first arrives with a prepared presentation: here is our platform, here are its modules, here is the architecture, here is what your factory will look like once it is implemented. The second asks a question before it opens a single slide: what can your operators not do today that they need to be able to do?

Walker Reynolds, one of the most influential practitioners in manufacturing digitalisation, used precisely this contrast to distinguish the approach of vendors who consistently deliver value from those who consistently disappoint. The first type designs solutions top-down — from the platform toward the problem. The second designs them bottom-up — from the problem toward the solution. The distinction seems minor in a sales presentation. It becomes decisive in implementation.

Reynolds was direct about which companies embodied each approach. Microsoft, he argued, exemplifies the top-down vendor: it arrives with a finished platform — Azure, Dynamics, the broader cloud ecosystem — and works to fit the customer's factory into that architecture. Google, by contrast, has historically started from the customer's problem and worked backward to the solution. Both companies build powerful technology. The direction from which they deploy it is fundamentally different — and that direction, it turns out, determines almost everything about whether the investment delivers what it promised.

Two Directions. Fundamentally Different Outcomes.

Reynolds used Microsoft and Google as the clearest illustration of this divide — not to dismiss either company's technology, but to name two recognisable philosophies that any manufacturer can learn to identify in any vendor they evaluate.

Why Top-Down Fails — Four Mechanisms

The top-down failure is not simply a matter of bad planning or inadequate budget. It is structural. The approach contains within it the conditions for its own failure, regardless of how competently the programme is managed. Here are the four mechanisms through which this plays out.

Microsoft, Google, and the Direction That Determines Everything

Walker Reynolds articulated the bottom-up principle through a comparison between Microsoft and Google that initially appears to be about vendor selection but is actually about epistemology — about whose knowledge of the factory should be treated as authoritative.

Microsoft, Reynolds argued, operates on a top-down assumption: that Microsoft understands the customer's problems better than the customer does. It arrives with a fully formed architecture — Azure IoT, Dynamics 365, the cloud-first stack — and a defined implementation methodology. The customer is a market for a solution that already exists. The factory must be made to fit the platform.

Google, he contrasted, begins by treating the customer's operational knowledge as the primary input. It does not arrive with a finished architecture. It arrives with a question: what is the problem? What can your people not do today? What decision is being made on incomplete information? The technology is then assembled backward from those answers. Reynolds pointed to this customer-first, problem-backward orientation as the reason Google's approach to manufacturing technology is more likely to deliver outcomes that operators and engineers actually trust.

"The vendor who says ‘here is our platform’ is telling you that your factory exists to justify their architecture. The vendor who asks ‘what can your operators not do today?’ is telling you that their architecture exists to serve your factory. The direction of that relationship determines everything."

This is not a minor philosophical distinction. It has direct consequences for what gets built. A vendor who starts from their own architecture will produce an implementation that fits their architecture. A vendor who starts from the customer's problem will produce an implementation that fits the problem. In complex operational environments — where the gap between a vendor's generic model and a specific factory's actual logic is wide — this distinction determines whether the system gets used.

The same principle applies not just to vendor selection but to how the organisation itself designs its programme. A digital transformation programme designed by the IT department and the C-suite, handed to the shop floor as a finished architecture, is as likely to fail as a vendor-imposed platform — for exactly the same reason. The people who know the factory were not the people who designed the system.

The Shop Floor Is the Source of Truth

Underneath the bottom-up argument is a claim about where the true description of a factory lives. It does not live in the ERP system — which records what was planned and what was reported, both of which are approximations of what actually happened. It does not live in the management dashboard — which aggregates and abstracts operational data to the point where the specific events that drove the numbers are invisible. It lives in the machines, the sensors, the control systems, and the people who operate them.

This observation, which seems obvious stated plainly, has profound architectural consequences. If the machines and processes are the authoritative source of what is happening in a factory, then the data infrastructure should be built to capture that reality as completely and faithfully as possible — and then make it available, upward, to every application that needs it: the MES, the ERP, the analytics platform, the management dashboard.

This is the architecture that Reynolds advocated through the concept of a Unified Namespace — a single, semantically organised data infrastructure that captures events at every level of the plant and makes them accessible as a shared source of truth. Not a data warehouse that aggregates and loses resolution. Not a set of point-to-point integrations between specific systems. A living, real-time representation of the factory that any application can query in the form it needs.

The critical architectural principle is the direction of authority: the operational data layer is the source; the enterprise and analytics layers are consumers. In a top-down architecture, this is inverted — the enterprise system defines what data the shop floor must produce, and the shop floor is configured to provide it. The inversion seems subtle. Its consequences are not.

Four Principles of Bottom-Up Programme Design

Bottom-up is not a methodology with a prescribed set of steps. It is an orientation — a consistent preference for beginning with the operational reality and working upward toward the enterprise view. These four principles describe what that orientation looks like in practice.

The C-Suite's Role in a Bottom-Up Programme

A common misreading of the bottom-up argument is that it diminishes the role of leadership. It does the opposite. In a top-down programme, leadership selects the platform and defines the architecture — tasks for which they are not well positioned, because those decisions require deep operational knowledge that executive roles do not routinely accumulate. The decisions that leadership is uniquely positioned to make — which outcomes matter, which investments deserve priority, which trade-offs are acceptable — are made by default, as consequences of the platform selection rather than as deliberate choices.

In a bottom-up programme, leadership's role is more demanding and more valuable. They define the questions that the programme must answer: which operational decisions matter most to business performance, which costs are too opaque to manage effectively, which risks are most consequential. These questions become the design brief for the data infrastructure. The architecture is then built, from the bottom, to answer them.

This division of responsibility — leadership defines the strategic questions; operational knowledge defines the data architecture; technology enables both — is the governance structure of programmes that work. It keeps leadership focused on outcomes rather than implementation details. It keeps engineers focused on the operational reality rather than the enterprise wish list. And it keeps the vendor focused on the actual problem rather than their standard deployment playbook.

"The C-suite's job in a digitalisation programme is to define the questions that cannot be answered today — not to select the architecture that will answer them. Those are different jobs, requiring different knowledge. Programmes that conflate them consistently produce systems that answer the wrong questions very expensively."

What to Look for in a Partner

Reynolds made a point about vendor selection that goes beyond methodology: mission and values matter. When choosing a technology partner, the alignment of purpose — what the partner is fundamentally trying to accomplish — is more predictive of a successful outcome than any combination of technical capability, reference list, or feature comparison.

A partner whose mission is to sell licences will make different implementation decisions than one whose mission is to build the client's operational capability. A partner whose organisational knowledge was built in vendor sales roles will approach the factory differently than one whose knowledge was built on the factory floor and in the operational leadership roles that depend on the factory floor's data.

The bottom-up approach is not just a technical preference — it is an expression of a particular set of values about whose knowledge counts. It says that the people who operate the process understand it better than the people who sold the platform. It says that the factory's operational truth is more important than the vendor's model of what a factory should look like. It says that value is measured in operational outcomes, not in system deployments.

Organisations that find a partner who shares these values — who genuinely starts from the operational problem, who builds data infrastructure before application layers, who measures success by whether the people on the shop floor are making better decisions — are the ones whose digitalisation programmes deliver what they promised.