Ask The Expert: How Systems Engineering and the Digital Thread Expose Hidden Delays

Systems Engineering and Digital Thread principles are exposing an often-overlooked source of schedule risk: the latency between an engineering event and a confident operating decision, or data cycle time. Aviation Week spoke with Jeff Miller, Principal & Global Industry Leader for Federal, Aerospace, Defense, and Electronics at Rockwell Automation, about finding and eliminating those hidden delays.

Aviation Week: Why have Systems Engineering and the Digital Thread become so critical to competitive advantage in aerospace and defense today?

Jeff Miller: They’re critical because they help uncover operating inefficiencies rooted in information flow. Systems Engineering, as a mature discipline, is creating a new improvement opportunity: data cycle time, the time between the creation of information and informed action.

Performance at the speed of data focuses our attention on data cycle times within and between processes and systems—especially in aerospace and defense, where complex environments generate enormous volumes of information moving among people, processes and technology systems. 

Consider a simple example: releasing an Engineering Change Notice to Production. We can separate the value-added engineering review—the analysis, discussion and design decisions—from non-value-added delays, like waiting for design files to be reformatted between systems, or extracting a bill of material because it wasn’t structured for materials science or sourcing review. 

Those are measurable data cycle times we can often eliminate through better process design. We’ve optimized our engineering and production processes so effectively that we’ve lowered the waterline and exposed the data-level inefficiencies beneath the surface—and once data cycle time is visible, it’s something we can improve directly.

AW: What is data cycle time, and why do manufacturers typically underestimate the delays it’s costing them?

JM: It is the time spent managing data. We underestimate it because it’s hidden. We’re conditioned to focus on process times already visible in enterprise, manufacturing execution and product design systems. When we send electronic work instructions to the factory floor, for example, we often bury the cycle time required to integrate product definitions, process specifications and supporting information instead of measuring it independently. 

If we isolate those data cycle times, we can engineer them out, but only after we stop treating them as invisible overhead. I often put it this way: the critical path should pass through the work, not through the preparation of the information needed to do the work. That principle applies to nearly every decision that constrains schedule.

Once you begin measuring data delays, they tend to fall into a handful of addressable categories:
availability, access, translation and trust. Identifying the category usually points you toward the solution.

AW: How do the digital twin and digital thread help manufacturers identify and eliminate data delays?

JM: The digital twin serves as a validation mechanism for the digital thread. If the twin performs well—whether modeling factory operations or product behavior—that’s a strong indication the thread is delivering the operating parameters and context the twin requires.

I worked with a manufacturer whose gear milling and deburring operations weren’t sufficiently connected: the vision system on the deburring machine received no information from the tool life management application supporting the CNC milling process. As hobbing cutters approached end of service, they produced more flash, increasing deburring requirements and vision-system errors. Once we shared cutter remaining-useful-life data between the two systems, and deburring began adjusting its parameters in response to cutter wear, the operation became more effi cient and predictable. The broader lesson: make the right information available, in the right form, at the right time, and the operation becomes faster and more efficient.

AW: For manufacturers new to this, what’s the first move, and what becomes possible when you reduce data cycle time?

JM: Start with a single high-value decision that occurs frequently and affects schedule, such as a production sequencing decision, a materials decision or a work-instruction update. Map the information dependencies behind that decision, and look for places where data needs adjustment to preserve context and continuity. That’s your use case.

I experienced this personally years ago as a nuclear fuel engineer, determining the manufacturing impact of product engineering changes. I was frequently on the critical path, waiting for information that wasn’t included in the Engineering Change Notice package. Provide the information upfront and the bottleneck disappears. 

Find a common, recurring process where information delays consume productive time, work backward from the loss, and solve it with data. Cycle times improve incrementally, and the cumulative eff ect can be significant. That’s what I mean by performance at the speed of data: it’s engineering and manufacturing performance limited by human decision-making, not by how long it takes to locate, assemble, and reformat information.

About the Expert
Jeff Miller helps manufacturing organizations create new, competitive capabilities at the intersection of business
and digital technology.