by eos consulting | May 27, 2026 | Homepage Featured, Manufacturing, Manufacturing Strategy
In previous explorations of agentic AI in manufacturing, I’ve traced the evolution of intelligence from scheduling (S&OP) and planning down to the digital nervous systems of networked machinery on the factory floor. Yet the ultimate horizon isn’t just a smarter spreadsheet or more communicative machinery. It’s physical AI.
Physical or “embodied” AI refers to systems that can perceive, reason, and act within the three-dimensional, physical world. These are the robots and autonomous machines that move with the nuance of a human and the precision of a computer.
While autonomous humanoid robots are not available yet, enormous investment is going into foundational models, compute/chips, and robot bodies or platforms by companies like Figure AI, Tesla, Google, Boston Dynamics, NVIDIA, and more. This is the ultimate vision, but a quiet, fundamental bottleneck has emerged: to move from a digital brain to a physical body, AI requires a different kind of fuel.
Foundational physical AI data is required to train the models and fine-tune the robots.
Understanding the data bottleneck
Large language models (LLMs) lean heavily on the internet. They learn from symbolic content like text, code, and images. Physical AI, however, learns from sensorimotor experience: what was seen, what action was taken, what happened next, and whether the action succeeded in the real or simulated world. It needs to understand that when a gripper applies X amount of force, Y happens to the material.
This requires time-aligned, multimodal, action-labeled data — a granular record of observations, actions, context, and outcomes.
This data does not exist on the internet, and it’s what’s necessary to train the foundational models of physical AI. It is expensive to harvest and even harder to scale.
The rise of VLA models
Vision-Language-Action (VLA) models are the current frontier for robotics. These systems take visual inputs and language instructions (e.g., “Tighten the bolt on the interior housing”) and translate them directly into robotic motor commands. They map robot observations to actions while retaining the benefits of large-scale vision-language pretraining.
That pretraining is the challenge. VLA models are typically trained on large robot demonstration datasets gathered across many tasks and robot types, like the Open X-Embodiment dataset, which contains more than one million real robot trajectories spanning 22 robot embodiments contributed by 34 labs. While datasets like this are promising, there still aren’t enough of them. As NVIDIA’s Jim Fan has noted, data is the primary constraint for robot foundation models.
Current data strategies
Recognizing the need for this data, industry leaders are experimenting with four primary methods to build the type of training data repositories they need to train physical models. However, each of these current strategies comes with its own set of compromises:
- Teleoperation/demonstrations: Collecting and aggregating data from robot embodiments. This method produces high-quality data but is slow, labor-intensive, and expensive to scale to the levels required for general-purpose intelligence. It is also inherently limited by what robots can currently actually do.
- Simulation: Creating digital twins of robots that can practice millions of times every second. While this can be an appealing solution to the constraints of collecting physical data, the “sim-to-real gap” — the subtle differences between digital physics and the messy real world — is a persistent hurdle, and it remains costly to build simulators.
- Synthetic data: Using AI to dream up new scenarios based on a small seed of real-world data. This method depends on real teleoperated data to post-train the model, and the seed data must be high-fidelity, physics-aware, diverse, and representative, which means results are only as good as the initial seed. It also requires extensive computational resources.
- World models: Predicting robot observations and task outcomes. While world models show promise, they often struggle with unfamiliar objects and navigation errors over longer periods of time.
AI leaders are working urgently to overcome this data problem, but the expense, speed, and lack of scalability continue to hold organizations back.
Breaking through the data bottleneck
If robots and simulations can’t yet provide enough data, why not look at the experts already on the floor?
Companies are using human video capture — often from the worker’s perspective — to train their models. By recording a veteran technician performing a complex assembly, it’s possible to capture the gold standard of physical action. Figure, for example, has done this to build training data for their Helix VLA model, and they’ve reported zero-shot human-video-to-robot transfer for navigation.
However, raw video is just noise until it’s labeled and searchable for operational knowledge.
Historically, this meant tedious manual annotation. That process was expensive and difficult to scale — so much so that there have been attempts to crowdsource the work. Now, AI is capable of largely taking it over.
Modern systems can now pre-label video, chunking it into task-sized segments and labeling what task is being performed, what equipment is used, what actions are taken by the worker, what anomalies or deviations occurred, and the outcome of the task. AI systems are increasingly capable of pre-labeling data and selecting only the most informative examples for human review. This makes building physical AI datasets easier, faster, and more manageable at scale.
Setting the foundation today for physical AI tomorrow
Even when it’s possible to start building these datasets, there is often pushback about building datasets for robots that don’t yet exist. But if the training doesn’t exist, it’s impossible for the robot builders to make robots that are fit for the tasks at hand.
Don’t wait for the robot to arrive to begin documenting the work. Physical AI data — specifically labeled, point-of-view video — is immensely valuable today for human-centric operations, especially in areas where fixed cameras cannot reach. It presents opportunities to make work processes safer and more productive today while also being useful in training the robots of the future.
Consider these high-stakes environments:
- Aerospace: Fastening and sealing inside fuel tanks or closed structures
- Medical devices: Assembling catheters or tubing inside lumens or hub connections
- Automotive: Installing wiring harnesses, connectors, or clips inside body cavities or dash structures
- Shipbuilding: Welding in confined spaces or fitting inside hull sections or tanks
These activities are common and often critical. When you document and label these activities, you aren’t just training a future robot; you are creating searchable operational knowledge that can unlock improvements in:
- Production operations: Efficiency, throughput, cycle time, schedule adherence
- Safety and regulatory compliance: Compliance improvements, identification and remediation of safety risks
- Asset management: Downtime, maintenance execution, reliability
The immediate impact
Labeled physical data allows you to document how work is being done, rather than just logging the final result. This shifts the focus from post-mortem analysis to real-time variance reduction and compliance.
What does this look like? Consider an aerospace final assembly line. The ability to see exactly how a fastener was installed in a blind cavity could save millions per year. It avoids non-conformance investigations, reduces out-of-station rework, and mitigates the risk of high-consequence safety incidents.
Furthermore, this data can feed into existing agentic systems, providing a better understanding of what’s really happening. Conventional agents know what should happen based on ERP, MRP, and MES data, along with other forms and logs, but can still miss what is actually happening. Direct, contextual shop floor data collection improves visibility into actual execution and gives AI systems a more accurate basis for analysis, orchestration, and decision-making.
Selecting a starting point
This type of data collection requires coordinated effort, and most manufacturers start with a pilot program to prove value.
To select the best-fit processes or activities to prioritize, first compile a set of activities that are difficult to observe, yield variable outcomes, and put value at risk. Then, score them against each other for:
- Value at stake: What is the economic exposure (volume X deviation rate X cost per deviation, including the cost of downtime)?
- Variance: How much do outcomes vary across different operators or crews?
- Task-boundary clarity: Can you clearly and effectively identify tasks and deviations to label actions and objects?
- Correctability: Can systemic deviations be reliably and cost-effectively corrected?
- Time-to-value: Can a pilot or demonstration show measurable benefit in 90 to 180 days?
- Automation adjacency: Does this process lend itself to agentic automation or assistance?
- Change management feasibility: How difficult will it be to deploy wearables, gain workforce acceptance, and integrate data into QA?
How you weigh these elements depends on your objectives and resources. For initial projects, I would recommend prioritizing areas with high potential impact — those where deviations could be corrected with training, aids, or process redesign or where value could be generated quickly via rework reduction or yield improvement — and areas that are natural fits for automation and robotics.
Constructing a new industrial foundation
Building physical AI datasets is the foundational work of the next decade. It is a rare “no regrets” move: short-term, it secures your operations, improves safety, and slashes the cost of quality; long-term, it feeds the proprietary brain that will eventually inhabit an autonomous factory.
The path to robotics starts with capturing intelligence about the work already being done on the factory floor. Agentic management of these activities isn’t just a side benefit — it’s the first economically defensible step into the future of manufacturing.
by eos consulting | Aug 11, 2020 | Manufacturing, Homepage Featured, Uncategorized
We’ve been talking about challenges for incumbent manufacturers, and suggested in our last post that for manufacturers to thrive, they need to command privileged positions in at least some of the business ecosystems in which they participate.
A privileged position means:
- Being core to or at the center of the ecosystem; or
- Owning vital elements of the ecosystem (standards, technology, proprietary software, etc.)
We suggested some ways to achieve that, among them:
- Ensuring that if there’s value in making your product ‘smart’, you play an important role in doing that — controlling or influencing the development of software, APIs, capabilities, standards, etc.
- If your product has software in it, owning its design and development as much as possible, especially for controls.
But designing and developing software poses distinct challenges for incumbent manufacturers — even if they don’t try to do it themselves.
In particular, incumbents’ existing development processes for many industrial products (such as electro-mechanical devices ranging from valves to combine harvesters) are likely much slower than for software & electronics — and for good reason. Such products (especially large ones) often comprise multiple integrated systems and components. Changing one affects others, and can have unpredictable effects on the performance of the entire machine. Moreover, a design change means changing manufactured parts and/or their fabrication — which, especially if it involves suppliers, can be slow, risky, and costly. Accordingly, incumbent manufacturers have learned how to update their products carefully and with manageable pacing.
Software development cycles, on the other hand, are much shorter. Software is easier to edit, test and replicate (even if the consequences are just as unpredictable, if not more so). But precisely because it is easier to edit, software development processes have come to be dominated by modularity, agile methodology, and rapid development and deployment.
Harmonizing these differing development processes across a set of design projects for a specific product is not easy, even (or especially) if the software development is outsourced. Except in cases of an entirely new product form, the physical product exists already, and the software project is about adding or upgrading sensors; adding communications in or out (from those sensors, for example); or automating (and/or optimizing) controls. Hardware engineers do not generally write software, so the first challenge is setting and maintaining execution schedules between hardware and software engineering teams (coordination only between individual engineers is often insufficient). A technical surprise or a shift in funding priorities can disrupt timelines, leading (in the worst case) to product delays or even incomplete (or buggy) solutions coming to market. In addition, design changes to the physical product and the software can get out of sync, again requiring time and often-scarce resources to reconcile. (Your software people may be spread thinner than you realize — especially if they must work with several product families.)
But there’s a deeper issue which may produce or exacerbate execution challenges: it’s not uncommon for requirements to change (or to be too vague), leading to misalignment between hardware and software teams. This especially plagues projects where the software component is outsourced or developed by a different unit of the company. It may even be unclear who owns the user experience, or the entire solution’s architecture and requirements.
In addition to adding cost, time delays are a frequent outcome of these challenges; yet for a large industrial product, missing a competitive product upgrade cycle (or two!) can be fatal to market share and/or profit margin.
So, what can be done?
- Start upstream from execution, with a shared vision across hardware and software of the value proposition for what you’re doing. Are you adding software-enabled features because the competition has them, and you must keep up? Ask yourself what the new capabilities will do for the customer, and whether/how that fits into your value proposition. If you must catch up, you might as well leapfrog — but only so far as you are meeting a real customer need, and not just trying to “out spec” the competition. (Yet leapfrogging can be a dangerous temptation — you are likely to take on additional technical risk, as well as marketing / channel challenges. And you had better be confident about profitability.)
- Ensure the product requirements are specific, measurable, and deliver the value proposition. Work together and be willing to listen to each other — often, the software team can suggest capabilities the hardware team didn’t realize were feasible. Most important, when requirements change (as they often will over the course of a project), don’t assume everybody is aware. Revisit the timeline and collaboratively make any needed adjustments.
- Consider developing a realistic, actionable product roadmap, incorporating some high-probability variants (e.g., funding cuts). This can align expectations and enable planning for contingencies. Perhaps most important, it enables you to be proactive — not re And the roadmap needs to reflect — and reconcile — the differing challenges of hardware and software development (e.g., seasonal product testing).
- Establish program governance across all the participating organizations for the set of projects together delivering the product update. This doesn’t have to be extensive or bureaucratic, but it does need to include:
-
- A joint repository of the project documents, including staffing, leadership, schedules, and requirements.
- Who decides what, and how conflicts are managed (“decision rights” — especially over product architecture, standards, and shared systems). And not just in theory — the organization must honor the process and “walk the talk,” especially when it comes to balancing the interests of not only hardware and software, but of design, manufacturing, and sales & marketing. (For example, who owns the specifications of the CAN bus on a vehicle? Especially if it is the factory which must carry the cost of a better one?)
- How communications between software and hardware teams will happen (e.g., when software teams change delivery dates for product features, how they will ensure the hardware teams know about it so they can plan).
Incorporating intelligence and connectivity into industrial products and components can be challenging, but it also opens new opportunities (as well as challenges) for incumbent manufacturers. Failing to do so can mean eventual relegation to commodity status. The manufacturing companies that will thrive in the future are likely to be “smart industrials.”
For more about operational governance, please see here.
by eos consulting | Feb 22, 2021 | Homepage Featured, Manufacturing Strategy, Uncategorized
If you Google manufacturing strategy, one of the top results is a Harvard Business Review article — from 1994. How can it rank so high given its vintage? The reason: it gets clicked on a lot — not only because it was written by two authorities on the subject, but because its insights remain on-point and highly useful (even after twenty-five years).
Let’s start with what they say about manufacturing strategy and strategic flexibility. Hayes & Pisano argue that:
In a stable environment, competitive strategy is about staking out a position, and manufacturing strategy focuses on getting better at the things necessary to defend that position. In turbulent environments, however, the goal of strategy becomes strategic flexibility. Being world-class is not enough; a company also has to have the capability to switch gears—from, for example, rapid product development to low cost—relatively quickly and with minimal resources. The job of manufacturing is to provide that capability.
That seems like kind of a big ask, doesn’t it? Perhaps it’s less daunting if we break it down into manufacturing capabilities that can deliver strategic flexibility to the business, such as:
- Agility & Responsiveness — the ability to handle changes in production volumes or product mixes; and to react quickly and effectively to product design changes, raw material changes, or customer order and delivery requirements (product options, order changes, delivery modes / timing / locations)
- Resilience — the ability to withstand shocks or rapid changes in exchange rates, labor or input costs, trade conditions, shipping rates, pandemics, and other operational disruptions
- Integration — the ability to incorporate new processes, products, or product architectures into the manufacturing operation
- Innovation — the ability to develop and deploy new or unique manufacturing processes to dramatically improve manufacturing performance
- Control & Improvement — the ability to direct and regulate operating processes, correct errors or inefficiencies, and to improve manufacturing performance
Such capabilities depend on much more than manufacturing sites, equipment and technology. As Hayes and Pisano point out, “a company’s capabilities are more than its physical assets. In fact, they are largely embodied in the collective skills and knowledge of its people and the organizational procedures that shape the way employees interact.”
Assembling the right combinations of assets, people, and process to deliver a desired capability — such as resilience to trade disruptions or global pandemics — takes time, commitment, and judgment.
And of course there are tradeoffs: low-cost production which relies on offshore suppliers can be brittle, subject to supply shocks (as many learned during the pandemic); yet steps to increase resilience can also increase costs. Production agility, if achieved with highly flexible lines, can also be expensive (but there are other ways to do it…).
These choices should be made in view of the business strategy — particularly the “how to win” elements. And good decisions about how to win can’t be made in ignorance of the actual or potential capabilities of the manufacturing organization. In fact, by “expanding the range of their manufacturing capabilities, [manufacturing leaders] increase their strategic options” for the business.
Which is why manufacturing leadership should be engaged in the business strategy.
by eos consulting | Mar 3, 2021 | Manufacturing
It’s widely accepted that for traditional manufacturing leaders to continue to thrive, they need to become solution providers — not solely product manufacturers. They must seize the high ground of emerging information, communication and analytical capabilities embodied in the “internet of things,” and incorporate the necessary hardware and software into their products. They must re-think how they respond to customer needs, fully align all product organizations around addressing these needs, and change the way they define development programs and allocate R&D dollars. In particular, they need to:
- align priorities across product groups and regional organizations, both across and within the customer’s production assets;
- understand the customer’s production economics;
- and then employ data and analytics to identify not just product improvements, but process improvements for customers.
This reorientation represents a fundamental change in the how to win of strategy, as well as the where to compete.
But implementing this strategic change is difficult if the company is organized around its products, rather than its customers and their tasks — and the challenges begin with how the company is organized and operated.
For long-established manufacturers, most product development is traditionally performed within distinct product-based organizations — for understandable reasons. But having those groups individually prioritize all R&D for their products risks the over-improvement of existing product forms and makes it difficult to address customer needs that span product types.
This problem becomes more acute when the company sells a collection of products to be used together in a “production system” (the full set of practices and products employed by the customer to produce a product). In industries such as road construction; airlines; mining; agriculture; building construction; or forestry (to name just a few), the range of equipment needed can be quite extensive and varied. Customers obtain their preferred equipment, consumables, and information from various suppliers who tend to specialize in each. The leading capital equipment suppliers generally seek to maximize their share of the equipment supplied for the production systems they serve, offering incentives to customers to purchase more of their equipment from them instead of assembling a heterogeneous mix. They do this with favorable financing, and increasingly by making their products work better with each other than with the products of others. But product organizations even within the same company face challenges that make it difficult to ensure their products will work together to maximize performance in the customer’s production system. This problem will only become harder as products become smarter and more connected, and the information layer spanning production systems becomes thicker, broader, and more valuable.
Organization by product presents several challenges to a strategy shift to solutions:
First: Within a single supplier, as each product organization prioritizes developing the features and capabilities that most improve their products’ performance (and their organization’s financial performance), it becomes difficult to coordinate across product organizations to deliver integrated capabilities to customers.
For example, in agriculture, consider a production system for a particular crop. Tractors, planters and combine harvesters are required equipment (among other things). The tractors and planters may be high priorities for the tractor and planter organizations, but the market for the harvesting equipment best suited to that crop may not be sufficiently attractive to the harvesting organization for them to fund development ahead of pressing needs for another crop. This disadvantages dealers as they seek to grow their share of customers’ spending, and leaves openings for competitors to exploit. Absent a way of prioritizing particular crop production systems and then picking where within them you will compete, important choices are made by default and not on purpose.
Second: Having each product group prioritize their own projects risks missing emerging customer needs. Indeed, some customers’ most important needs can only be seen by companies looking to innovate across the entire production system, decomposed into the many “jobs” that a customer needs to accomplish. For example, in agriculture, seed selection with precision planting may bring the greatest value to the customer, but it can be difficult to justify investments in those if you must take the funding from the larger product forms (e.g., tractors and harvesting combines) which generate more margin for the company.
Third: Focusing R&D on individual product forms which together make up (the equipment portion of) the customer’s production system also makes it more difficult to realize the full value of smart, connected products (see Porter & Heppelmann, HBR Nov 2014) — because typically there is no reward within one product organization for absorbing costs when the value is mostly realized by another product organization. For example: sensing and data collection (related more to production system performance than combine performance) are difficult to justify in the context of funding a combine project, especially if the benefits accrue to another organization (e.g., precision planters). Product organizations are more likely to invest instead in the features and capabilities of immediate interest to their higher-margin, most advanced customers — thus falling prey to “the innovator’s dilemma.” Additionally, much of the benefit of Big Data will be realized by changing practices in the customer’s production system (e.g., timing, inputs, processes). Seeding and feeding practices may have large effects on costs and productivity — yet may not necessarily require different equipment, but rather data collection and analysis. Equipment manufacturers who neglect such opportunities risk becoming marginalized.
John Deere recognized the risk, and began the strategic shift to being a “Smart Industrial.” As part of that shift they introduced a new operating model — organized around production systems; the technology stack; and lifecycle solutions. Deere’s reorganization has been extensive, because leadership recognizes the value of organizing to deliver the business strategy.
#manufacturingstrategy #orgstructure #strategy
