Start Manufacturing DX Small

Tomohiro Iida · Published June 23, 2026 · Updated July 11, 2026

A practical guide for manufacturing DX leads: how to test a hypothesis small with a PoC and reach a fast decision, within the real constraints of frontline operations, core systems, and safety requirements.

Why manufacturing DX is hard to move forward

Manufacturing DX often feels harder than DX in other industries. That is not a matter of motivation or capability; it comes from structures specific to the shop floor. Unless a plan is designed around three constraints, frontline operations, core systems, and safety requirements, it tends to stall partway through.

Frontline operations cannot be paused

Production lines run to a daily schedule, so testing something new by stopping the line, or trying a different work procedure, is not simple. Because trying anything new carries a risk to production itself, it is structurally hard to just try it on the floor first.

Core systems are built to run reliably, not to be reconnected

Production-management systems and ERP are built on the assumption of long-term stable operation, so connecting them to a new outside system tends to get treated as a separate project. Where no data-extraction path or API already exists, even scoping the integration can take real time.

Safety and quality requirements set a high bar

Manufacturing sites operate under strict equipment-safety standards and quality-management requirements, and any new system has to be confirmed not to affect them. Even at the verification stage, concern about what might go wrong tends to narrow the scope of what people are willing to try.

Frontline knowledge and management or IT language diverge

The tacit knowledge held on the floor and the DX vision held by management or IT often run on different words and different assumptions. When what the frontline actually struggles with and the problem leadership wants solved are never reconciled, what gets built tends not to get used.

Put the other way round: an operation that cannot be paused, a core system that runs reliably, and rigorous quality standards are, seen differently, solid assets built up over many years. Treating them as a foundation to connect to and draw on in a small, bounded way, rather than as a constraint, is what gets manufacturing DX moving.

Designing a small PoC

Changing an entire plant at once is difficult, but testing a single process in a small, bounded way is achievable with the right design. Four design principles keep a PoC safe to run even within manufacturing constraints.

Narrow the hypothesis to one

Narrow the scope until you can write, in a single sentence, what this PoC needs to show for you to move forward. Limiting the target to one specific process, one specific dataset, or one specific decision, rather than DX for the whole plant, lets you verify it while limiting the impact on the frontline. The wider the scope, the heavier both safety review and integration become.

Confirm the scope of existing-system integration first

At the start of the design, confirm what data can be pulled from the production-management system or ERP, at what granularity, and through what path. Deciding early whether to use live, read-only data or to work from exported data or a mock reduces rework later.

Choose a verification method that does not stop production

Prioritize methods that can be verified without stopping the line, using historical data, running in parallel, or trying it in a limited area. Designing so a hypothesis can be tested on data or within a small scope before touching production equipment is the precondition for getting the frontline’s cooperation.

Set Go/No-Go criteria before starting

Agree with stakeholders, before starting, on the standard for which metric, at which level, means moving forward or not. Without a criterion, a disappointing result tends to get extended with a little more time, and the decision keeps getting deferred. Treating a No-Go as early learning rather than failure is an important part of this.

Issues specific to manufacturing PoCs

General DX information rarely covers points that are specific to manufacturing. Knowing them ahead of time sharpens how the PoC gets designed.

The reality of integrating with production-management systems and ERP

Connecting to a production-management system or ERP starts with confirming the data-extraction path, format, and update frequency. At the PoC stage, options that minimize impact on the production system are worth considering, such as using live data read-only or working from exported data. Feasibility and load depend on the system’s configuration, so understanding the current state first is the starting point for the design.

Bringing the frontline on board, and testing whether it actually gets used

One reason DX PoCs fail to turn into an ongoing business is that the frontline never actually uses what gets built. Interviewing frontline staff from the design stage, on what is burdensome about the current work and what would make it easier, sharpens the hypothesis. Showing a working version to the frontline early and feeding their reaction back into the next round of testing is an effective way to proceed.

Phased budgeting and internal approval

Trying to get a PoC’s entire budget approved in one go raises the bar for approval. Splitting the request into phases, technical and data-integration verification, then a frontline trial, lowers the initial decision cost. Clear Go/No-Go criteria also make it easier to justify additional budget between phases.

Assessing the impact on safety and quality

Any verification touching the manufacturing floor needs to build in an assessment of the impact on safety standards and quality management from the start. Separating the verification scope from production equipment, and limiting the scope of impact, is a precondition for getting internal agreement, on the basis of controlling risk.

Designing a PoC that builds on your existing systems

Netsujo is based in Kyoto and works as an implementation-led business-development partner across Web3, AI, and other emerging-technology fields, from concept structuring through to implementation. We do not yet have a manufacturing delivery track record, but we do take on PoC (proof of concept) design consultations that assume integration with existing systems.

In the PoC context, we work with companies from the stage of having a hypothesis but no one who can judge whether it is technically feasible, or having a design but no one who can build the first working version.

We would not say we have an industry-specialized track record in manufacturing. But talking through the design, how to make use of existing systems and data and how far to scope the verification, is something we can help with regardless of industry.

• We want to organize a hypothesis we can test small, using data from our production-management system.
• We have a DX concept but do not know which process to start with.
• We would like help designing a verification scope that does not stop the floor.
• We want to use AI but do not know if it can work with our existing systems.

Frequently asked questions

Where should manufacturing DX start?

Rather than launching a company-wide DX effort all at once, we would recommend starting with a PoC (proof of concept) narrowed to one process or one problem. Setting a small question, such as whether a given hypothesis holds up, and starting with a verification method that does not stop production lets you build up learning while limiting the impact on the frontline.

What does it mean, concretely, to start a factory’s DX small?

It means testing something with the scope limited to one process, one dataset, or one decision, rather than the whole plant or all of its equipment. Choosing a verification method that does not stop the line, using historical data or trying it in a limited area, lets you test the hypothesis while keeping risk down.

Can a PoC integrate with our existing production-management system or ERP?

Whether integration is feasible depends on the system’s data-extraction path and format. At the PoC stage, we look at ways to minimize impact on production, such as read-only access to live data or working from exported data or a mock. Confirming the current system configuration at the start of the design lets us assess technical feasibility concretely.

How should we judge the results of a PoC?

It matters to agree, with stakeholders, on Go/No-Go criteria before starting, meaning which metric, at which level, means moving forward. Deciding this in advance lets you judge the result on evidence rather than instinct once it comes in, and make the call to continue or step back quickly.

Do you have a track record supporting manufacturing DX?

We do not have a manufacturing delivery track record at this point. That said, we do take on PoC (proof of concept) design consultations premised on integration with existing systems. Regardless of industry, we welcome conversations about building on what a company already has while trying something new in a small way.

Summary

Manufacturing DX has to be designed around constraints: frontline operations that cannot be paused, core systems built to run reliably, and strict safety and quality requirements. Ignoring these and trying to push DX through company-wide tends to make a plan stall partway.

What is realistic is narrowing the hypothesis to be tested to one, confirming the scope of existing-system integration first, and testing it small using a method that does not stop production. Setting Go/No-Go criteria before starting lets you make the next decision on evidence once a result comes in.

Existing systems are not a constraint to work around, they are a foundation to build on. Starting from the design conversation, how far to scope the verification and which data to use, is how manufacturing DX moves forward steadily, in small steps.