“We need to go digital.” Everyone in the room nods, but they are often picturing different things. To one person it means a faster laptop. To another it means dashboards. To a third it means AI models that predict experimental outcomes. All three are talking about digital. None of them are wrong. But if a leadership team cannot agree on what digital actually covers, it is very hard to build a coherent plan for it, let alone measure progress against one.

This note lays out the layers that make up “digital” in an R&D setting, based on the author’s experience building a Digital R&D function from scratch. Naming these layers is a simple exercise, but it solves a real problem: it lets you place any specific complaint, request, or initiative into the right box, instead of letting everything get lumped together under one word. Would a slow laptop count as a digital problem? Under this breakdown, it sits in infrastructure, a real issue, but a different one from the data and modelling work most digital initiatives are actually meant to deliver.

A familiar request that is not actually in scope

Product developers want to see the cost of the ingredients they are working with. That cost data lives in the ERP system, owned by procurement, not by R&D. The Digital R&D team gets asked to make it available, and it seems like a reasonable ask. Product developers need cost visibility to make good decisions, and Digital R&D exists to give people better access to data.

Here is the catch. Digital R&D can make R&D’s own data more usable: digitising it, cleaning it, opening it up through dashboards or models. What it cannot do on its own is unlock data that another part of the organisation owns and has not yet exposed. If the ERP data has not been moved into a data lake or opened up by IT, no amount of effort inside Digital R&D changes that. The data simply is not accessible yet.

This is why a clear scope matters. Data owned and managed by units outside R&D belongs in the infrastructure bucket, not the data layer that Digital R&D directly controls. Digital R&D can request that data be unlocked, and can be the first team to make good use of it once it is, but unlocking it is not their job to deliver alone.

The data layer

Most of the actual work of “going digital” happens in the data layer. This covers a chain of related activities:

  • Digitising data or processes. Turning something that lives on paper, in someone’s head, or in a disconnected file into a structured, storable record.
  • Finding and searching data. Once something is digitised, can people actually locate it again, or does it disappear into a folder nobody remembers?
  • Cleaning and transforming data. Raw data is rarely usable as it is. It needs standardising, joining, and correcting before it supports anything.
  • Exploring data through BI. Turning cleaned data into dashboards and visual tools that let people look at it themselves, rather than waiting for someone else to pull a report.
  • Creating models. The most advanced end of the layer, where data is used to build predictive or optimisation models rather than just describe what already happened.

These five activities build on each other, but not in a way that applies to a whole organisation at once. An organisation does not sit at one single point on this scale across the board. Different use cases can sit at different points at the same time. The innovation project pipeline might have clean, well maintained data and be ready to move toward modelling, while lab notebooks in another part of R&D are still stuck at the digitising stage. The lesson is not that every use case has to climb the ladder in order before anything else can happen. It is that each use case needs to be honest about where its own data actually stands before jumping to modelling. Skipping ahead on a use case whose data is not ready is a common reason AI pilots struggle once they try to scale.

Automation, running through everything

Automation is not really a separate layer so much as a way of running the layers above without manual effort. You can digitise data manually or automatically. You can clean and transform data by hand or through a repeatable pipeline. Automation is what turns a one-off improvement into something that keeps working without someone doing it again every week.

Governance, the layer people forget

Data governance rarely makes it into the first conversation about digital, but it belongs there. It covers who owns which data, what quality standard it needs to meet, and who is allowed to access or change it. Without governance, the data layer above tends to decay. People stop trusting it, start keeping their own private copies again, and the organisation slides back toward spreadsheets and shared drives.

Why naming the layers matters

Once you separate hardware, data, automation, and governance, a few things become easier.

You can diagnose requests properly. “Why can’t we see cost data” and “why is our own experimental data such a mess” sound similar but sit in different buckets, one in infrastructure owned elsewhere, one squarely inside R&D’s own data layer. Knowing the difference changes who should be doing the work.

You can set expectations correctly. A leadership team that expects Digital R&D to unlock data owned by other functions will be disappointed, since that depends on decisions and investment outside R&D. A team that understands where Digital R&D’s own remit starts and ends can ask for the right things and push the cross-functional request to the right owner.

You can plan investment in the right order. Data quality and governance are not the exciting parts of digital, but they are the foundation the more visible parts—dashboards, automation, predictive models—actually depend on.

The scope is broader, and narrower, than most people assume

The scope runs from infrastructure, through data digitisation, cleaning, exploration and modelling, all held together by automation and governance. Most of the value sits in the middle of that chain, in the parts that rarely get their own headline announcement. But the boundary matters just as much as the breadth. Knowing what belongs to Digital R&D, and what belongs to infrastructure owned by someone else, is what keeps expectations realistic and requests going to the right place.

Frequently asked questions

What counts as digital in R&D?

It covers infrastructure and hardware, the data layer, automation, and governance. Most of the practical work sits in the data layer: digitising, finding, cleaning, exploring, and modelling data.

Who owns data that comes from outside R&D, like cost data from an ERP system?

That data belongs to the function that owns the source system, procurement in the ERP example. Digital R&D can make good use of it once it is accessible, but unlocking it is not Digital R&D’s job to deliver alone.

Why does a slow laptop not count as a digital transformation problem?

It sits in the infrastructure layer, which matters but is a different issue from the data and modelling work most digital initiatives are meant to deliver. Fixing it removes a friction point; it does not move an organisation closer to being more digital.

Does an organisation sit at one point on the digital maturity scale?

No. Different use cases within the same organisation can sit at different points at once. One area might have clean, well maintained data ready for modelling, while another is still stuck at the digitising stage.