NEWSROOM | The Next Battle for Industrial AI: Who Owns the Context?

Lionel Grealou Digital News 5 minutes

From the Newsroom: PLM, engineering software, scientific R&D and enterprise AI — the developments that matter, and what they mean.

Industrial AI is entering a different phase. The race is no longer simply about developing more capable models or introducing AI assistants into enterprise applications. Increasingly, the competition is about who controls the information, processes and evidence that allow those models to deliver meaningful outcomes.

This week’s announcements from Dassault Systèmes, Waters, Rockwell Automation, IDBS and Nemetschek illustrate that shift. They come from different markets, but raise a common question: will competitive advantage come from better AI, or from better control of the domain context in which AI operates?

1. Scientific software: A new battle for lifecycle ownership

Dassault Systèmes has completed its $1.8 billion acquisition of ArisGlobal, with up to $200 million in additional consideration linked to AI-related revenue milestones. The acquisition extends Dassault’s life sciences portfolio beyond BIOVIA’s scientific capabilities and MEDIDATA’s clinical development environment into regulatory affairs, pharmacovigilance and medical information.

The strategic ambition is understandable. Scientific research, clinical development and regulatory submissions are often managed through separate applications, information models and organisational structures. Bringing these capabilities together creates the possibility of greater continuity across the therapeutic lifecycle. But owning the applications is not the same as connecting the information.

The challenge will be establishing meaningful relationships between scientific results, clinical evidence, regulatory commitments and subsequent changes. Without that continuity, portfolio consolidation risks becoming commercial integration rather than lifecycle transformation.

Meanwhile, Genedata has announced an integrated electronic laboratory notebook that extends its existing scientific information environment. The proposition is different, but the underlying objective is similar: preserve experimental context alongside structured scientific data.

The question is whether the future of scientific informatics belongs to integrated platforms or interoperable specialist applications. There is no one-size-fits-all answer.

Sources: Dassault Systèmes, 28 October; Genedata, 28 October.

2. From AI promises to measurable laboratory outcomes

Waters Corporation has introduced AI-powered peak integration for its Empower chromatography data software. The announcement stands out because it provides specific performance evidence rather than relying exclusively on the promise of agentic AI.

In a customer pilot involving 400 chromatograms, manual interventions reportedly fell from 90 to four, representing a 95% reduction. Separate testing reported a 50% reduction in review time and a 72% reduction in analyst-to-analyst variability. These are encouraging results, although the underlying datasets have not been independently published and the capability is not yet generally available for validated production use.

The significance extends beyond chromatography. Waters is embedding AI into an established scientific workflow, where methods, results, reviews and changes are already subject to formal controls. The model itself must also be managed, including versioning, qualification and retraining. That is quite different from giving a scientist access to a general-purpose AI assistant. The value is not only that AI can produce an answer faster. It is that the answer can potentially become part of a controlled, reproducible scientific process.

For regulated R&D, the decisive measure of AI maturity may be the quality of validated outcomes rather than model sophistication.

Source: Waters Corporation, 28 October.

3. Engineering software: The context problem moves into the field

Rockwell Automation’s latest SecureOT announcement extends cybersecurity management across the machinery lifecycle. The offering addresses software and firmware inventories, vulnerability identification, continuous monitoring and compliance evidence, with reference to the EU Cyber Resilience Act and Machinery Regulation.

This is a development worth watching from a PLM perspective. A product’s configuration does not stop evolving when it leaves the factory. Installed software, firmware updates, replacement components and operational modifications can all affect its cybersecurity posture. Consequently, understanding which deployed products a vulnerability affects requires more than an asset inventory.

It requires relationships between engineering configurations, software bills of materials, deployed product instances and service interventions. This is another example of lifecycle management extending beyond its traditional boundaries. In parallel, Nemetschek has presented a common AI architecture spanning Archicad, Allplan and Bluebeam. Its approach combines shared intelligence services with specialised engineering applications and support for open interoperability standards.

The architectural proposition is interesting: retain discipline-specific tools while introducing AI capabilities that operate across them. Yet technical connectivity is only part of the challenge. Engineering semantics, configuration integrity and decision authority remain difficult to preserve across application boundaries.

The ability to connect applications should not be confused with the ability to maintain a coherent engineering context.

Sources: Rockwell Automation, 29 October; Nemetschek, 29 October.

4. The bigger picture: Domain intelligence, not just artificial intelligence

These developments illustrate three increasingly important competitive strategies.

  1. Dassault Systèmes and Genedata are strengthening their positions around scientific information continuity.
  2. Waters is demonstrating how specialised AI can improve a specific, controlled scientific process.
  3. Rockwell and Nemetschek are addressing different aspects of engineering context across products, applications and operational environments.

None of these approaches is inherently superior. Their relevance depends on the problem being solved, the maturity of the underlying information architecture and the ability to demonstrate business outcomes. What they share is a recognition that enterprise AI cannot operate effectively on model capability alone. It needs access to authoritative information, an understanding of domain constraints, and mechanisms to validate and govern the actions that follow.

The next competitive battleground may therefore be less about who has the most powerful AI model and more about who can turn domain knowledge into reliable, actionable intelligence across the lifecycle of things.

The question for industry leaders

Are we investing in AI to make existing applications more intelligent, or are we redesigning the information and decision architecture through which engineering and scientific innovation actually happens?

The difference will determine whether AI becomes another layer of enterprise software complexity or a meaningful driver of transformation.

What are your thoughts?

References:

  • Dassault Systèmes Takes Its Life Sciences Ambition to the Next Level with a Unified AI Platform Connecting Science, Medicine and Patients. 28 October. Available at: Dassault Systèmes press release (Accessed: 31 October 2026).
  • Genedata Launches Fully Integrated Electronic Lab Notebook to Help Biopharma R&D Teams Move Faster. 28 October. Available at: Genedata press release (Accessed: 31 October 2026).
  • IDBS and a-tune Strengthen Long-standing Partnership to Connect Preclinical Workflows. 29 October. Available at: IDBS press release (Accessed: 31 October 2026).
  • Nemetschek Group Brings AI to Design, Engineering and Construction with Newly Released Max Solutions. 29 October. Available at: Nemetschek press release (Accessed: 31 October 2026).
  • Rockwell Automation Introduces SecureOT Capabilities to Help OEMs Address Emerging Cybersecurity Regulations. 29 October. Available at: Rockwell Automation press release (Accessed: 31 October 2026).
  • Waters Launches AI-Powered Peak Integration, Expanding Its Suite of Premium AI Subscription Capabilities for Empower Software. 28 October. Available at: Waters Corporation press release (Accessed: 31 October 2026).

Disclaimer: articles and thoughts published on v+d do not necessarily represent the views of the company, but solely the views or interpretations of the author(s); reviews, insights and mentions of publications, products, or services do neither constitute endorsement, nor recommendations for purchase or adoption. 

Product Memory: Are We Remembering What Really Matters?

Lionel Grealou Digital PLM 7 minutes

Why the future of enterprise intelligence depends on knowing what to remember, what to trace, and when to challenge yesterday’s decisions.

AI is reshaping daily PLM and wider enterprise conversations. Beyond connected data and digital threads, attention is shifting towards product memory: preserving the knowledge, decisions and reasoning that explain how products evolve. The proposition is compelling. Enterprises have accumulated decades of engineering and operational information, yet much of the context behind their decisions remains fragmented across systems, documents and people.

AI introduces new possibilities for discovering relationships and recovering context that traditional enterprise software and integrations were not designed to capture. However, remembering more does not necessarily mean understanding more. What should an enterprise remember? What must it retain for traceability? And what should it be prepared to challenge as circumstances change?

These questions take product memory beyond engineering knowledge and into the broader discussion of enterprise cognition.

Product Memory Extends Beyond PLM

PLM preserves important information about product definitions, requirements, configurations, engineering decisions and changes. However, this represents only one perspective of the product lifecycle. ERP manages suppliers, purchasing, materials, costs, manufacturing orders, inventories and financial transactions. MES captures manufacturing execution, while quality, laboratory, regulatory and service systems preserve further evidence of conformity, performance and product history.

Consider a material substitution. PLM may explain why an alternative specification was approved. ERP identifies supplier availability, costs and procurement commitments. MES establishes which production batches used the material, while quality systems provide evidence of conformity. Each system contributes to understanding the decision, yet none provides the complete picture. Equally, decisions do not flow exclusively from engineering into operations. Supplier constraints, production failures, cost pressures and regulatory changes frequently trigger new engineering decisions.

Product memory is therefore distributed across the enterprise, not owned by PLM or any other software platform. The opportunity lies in connecting these perspectives and preserving their relevant decision context, rather than creating another repository claiming to contain the complete product history.

Remembering Everything Is Not the Objective

Enterprises generate thousands of decisions and transactions every day. Some represent valuable knowledge, while others are routine, temporary or relevant only to specific circumstances. Should every engineering discussion, discarded alternative, supplier quotation, production adjustment or AI-generated recommendation become part of permanent product memory? Not necessarily.

Indiscriminate preservation may make valuable knowledge harder to identify, while obsolete assumptions and conflicting interpretations accumulate over time. The challenge is determining which decisions deserve preservation, what evidence must remain traceable and which information continues to have value for future decisions.

Three questions should guide this process:

  • What must be retained? Records required for legal, regulatory, contractual, quality or intellectual property purposes.
  • What is worth remembering? Decisions, rationale, experience and lessons that may improve future innovation and operations.
  • What should be reconsidered? Assumptions and conclusions whose validity may change with technology, competition, regulation or business priorities.

These considerations overlap, but their application depends on the organisation’s operating model and the significance of the decisions involved. A production record may require long-term retention without becoming active knowledge for AI reasoning. Conversely, an engineering lesson may remain valuable even when its supporting records are no longer subject to mandatory retention.

Product memory’s value lies in preserving relevant decision context, not in remembering everything. Appropriate context must reflect the decisions an enterprise makes, the risks it manages, and the obligations it must fulfil.

Product memory cannot be defined solely by the information available for preservation or the technology that can retrieve it. The enterprise must first establish which decisions are material to its operating model, which require demonstrable evidence, and which historical assumptions remain relevant to future decisions. This determines the appropriate depth of decision context, its governance and its lifecycle. Without that business perspective, Product memory risks becoming another exercise in accumulating information rather than improving decisions.

Traceability and Memory Serve Different Purposes

Traceability establishes what happened, when, where, and under whose authority. Decision context explains why it happened, which assumptions influenced the outcome and what the enterprise may learn from it. These capabilities complement each other, but serve different purposes.

This distinction is particularly important for OEMs operating across complex supply chains, manufacturing environments and regulated industries.

Information domainEnterprise requirement
Engineering and IPPreserve design rationale, inventions, patents and technical know-how.
Regulatory and complianceRetain submissions, notifications, approvals and conformity evidence.
Quality and manufacturingTrace production genealogy, inspections, deviations and corrective actions.
Commercial and supply chainUnderstand supplier choices, procurement commitments, costs and constraints.
Service and warrantyMaintain relevant product history, warranty evidence and field performance.
Organisational knowledgePreserve selected assumptions, lessons learned and decision rationale for reuse.

These domains have different owners, retention requirements and levels of criticality. An aerospace manufacturer, automotive OEM and consumer goods company cannot reasonably apply identical traceability and knowledge-retention practices.

Traceability may be mandatory, while organisational memory must be purposeful. This distinction becomes more important as AI enables richer traceability. Traditional integrations generally connect predefined data structures, transactions and workflows. AI can increasingly discover relationships across engineering documents, supplier correspondence, manufacturing records, quality reports and other previously disconnected information. It can help reconstruct decision context and reveal dependencies that conventional integrations may have overlooked.

However, AI-discovered relationships are not automatically verified traceability. Provenance, source authority, evidence, applicability and appropriate validation remain essential, particularly where safety or compliance is involved. The opportunity is to establish richer contextual traceability across systems without compromising the integrity of authoritative records.

Enterprise Context Must Drive Product Memory

What an organisation needs to remember depends fundamentally on how it operates and creates value. Its mission, products, business model, markets and regulatory environment determine which decisions matter, what requires evidence and how much context must be preserved.

An aerospace manufacturer may prioritise configuration integrity and long-term safety evidence. A consumer goods business may focus on formulations, supplier qualifications, regulatory submissions and manufacturing consistency. A software-intensive OEM may require deeper relationships between hardware configurations, software releases and cybersecurity decisions. These differences reflect distinct operating models, not simply different technology architectures.

This is where my earlier cognitive PLM debate becomes particularly relevant. The Product Digital Backbone establishes structural continuity across processes, systems, people and governance. The digital thread connects lifecycle information and supports traceability. The cognitive data thread extends these relationships by preserving decision context, including rationale, assumptions, constraints and human judgment.

The appropriate depth of that context, its retention requirements and its relevance to future decisions must reflect the organisation’s operating model rather than a blanket approach applied across every system and process. Together, these capabilities provide the foundation for enterprise cognition: the ability to interpret information, understand dependencies and support decisions across functional boundaries.

The starting point is therefore not what PLM, ERP or AI can remember, but what the enterprise needs to understand to fulfil its mission and make better decisions.

Intelligence Also Means Challenging What We Remember

One risk of organisational memory is assuming that historical knowledge remains valid. A supplier decision may have been justified by cost and availability, a design may have reflected the best technology available, and a manufacturing process may have been optimal under previous operating conditions. None of these conclusions is necessarily permanent. Markets change, regulations evolve, technologies advance, competitors introduce alternatives, and strategic priorities shift.

An enterprise that retrieves yesterday’s reasoning without reassessing its assumptions may simply become more efficient at repeating obsolete decisions. This is where enterprise cognition must move beyond memory towards learning, adaptation and the ability to unlearn.

Unlearning does not mean deleting historical evidence or rewriting previous decisions. It means recognising when assumptions no longer apply, challenging established conclusions, and superseding knowledge while maintaining the traceability required for accountability. Historical evidence and current decision guidance must remain distinguishable.

AI can support this process by identifying contradictions, revealing dependencies and evaluating alternatives across functions and systems. However, accountable business owners must retain authority over the interpretation of evidence, the validity of decisions and the actions that follow. A genuinely intelligent organisation should understand not only why it made a decision, but whether it would still make that decision today.

From Cognitive PLM to the Enterprise Brain

Memory is one cognitive capability, but it is not intelligence itself. The enterprise brain represents the broader organisational ability to interpret information, reason across constraints, learn from experience, challenge assumptions and coordinate decisions. It is not another software platform, nor a competition between PLM, ERP, MES or other enterprise applications. Rather, it extends cognitive PLM thinking across the enterprise.

AI could significantly enable this evolution. Enterprise software vendors are embedding AI into their platforms, improving information retrieval, automation and decision support within their respective environments. These capabilities create value, but when confined to individual applications, they may also reinforce existing information boundaries.

Cross-platform AI introduces a different possibility: intelligence that can reason across systems of record rather than remaining constrained by the application in which it operates. This could change how organisations discover knowledge, establish contextual relationships, coordinate workflows and support decisions across engineering, manufacturing, operations and commercial functions.

It also raises important questions about the future of enterprise software. Where should intelligence reside? How should applications expose information and capabilities beyond their own boundaries? Who governs AI-generated relationships and cross-platform actions? How can enterprises preserve authority, security and accountability when reasoning spans multiple systems and technology providers?

These questions do not diminish the importance of existing enterprise applications. Their structured information, transactional integrity and domain governance remain essential. Rather, they suggest that the boundaries of enterprise intelligence may increasingly differ from those of enterprise software.

For OEMs, the opportunity is to connect engineering intent with manufacturing reality, supply-chain constraints, commercial priorities and regulatory obligations. Success should ultimately be measured through better decisions and business outcomes: faster innovation, stronger quality, more efficient operations, reduced risk and improved profitability. These contribute directly to return on innovation and return on operations.

Product memory has an important role in preserving and making enterprise knowledge accessible. Yet its value depends on understanding which decisions require context, which information must remain traceable and when previous conclusions should be challenged.

The future is not about enabling enterprises to remember everything about their products. It is about preserving what matters, tracing what is required, discovering what was previously disconnected and applying that knowledge to make better decisions as the business evolves.

That is where product memory contributes to enterprise intelligence.

What are your thoughts?

Disclaimer: articles and thoughts published on v+d do not necessarily represent the views of the company, but solely the views or interpretations of the author(s); reviews, insights and mentions of publications, products, or services do neither constitute endorsement, nor recommendations for purchase or adoption. 

Are We Measuring Change at the Right Time?

Lionel Grealou Digital Leadership 5 minutes

Transformation readiness and adoption cannot simply be inferred from a green program dashboard. Readiness tells us whether the organization can operate; adoption tells us whether new ways of working are actually taking hold. Both need active management and measurement, but the required evidence changes as the transformation progresses.

This makes Organizational Change Management (OCM) a continuous discipline rather than a set of activities around go-live. What we measure, who needs to be involved, and who owns the outcomes must evolve from readiness through implementation, adoption, and ultimately value realization.

Another important dimension is stakeholder involvement. OCM cannot be delegated to a change team that periodically measures the organization from the outside. Sponsors, business leaders, process owners, managers, SMEs and impacted users need to remain involved throughout—not simply consulted at the beginning or trained at the end.

Prosci’s research consistently identifies active and visible sponsorship as a leading contributor to successful change and emphasizes the importance of building a coalition of support across the organization. The implication is straightforward: measurement, engagement and adjustment need to continue together throughout the transformation.

Before go-live: are we ready?

Before deployment, the emphasis should be on readiness, not adoption. Training completion, communications delivered and stakeholder engagement are useful, but they remain leading indicators.

Core measures should include:

  • Change-impact coverage: have impacted roles, processes and organizational units been identified?
  • Stakeholder engagement: are the right stakeholders actively participating in decisions and validation?
  • Training and competence: can people demonstrate the critical tasks required by their future roles?
  • Process readiness: can representative end-to-end scenarios be executed by the business?
  • Business readiness: are roles, decision rights, data, support arrangements and dependencies in place?
  • Readiness risks: what critical gaps remain, who owns them and what evidence supports closure?

The distinction between completion and competence is important. “95% trained” tells us that an activity occurred; it does not tell us whether 95% of users are ready.

Go-live and hypercare: can we operate?

Once the solution is deployed, the evidence changes. We no longer need to rely exclusively on plans, surveys and readiness assessments because we can observe real behavior.

The focus should shift toward:

  • Active usage: are the intended users actually using the new environment?
  • Critical process execution: are end-to-end processes operating successfully?
  • User proficiency: where do people still require exceptional support?
  • Support demand: what issues are recurring and why?
  • Process exceptions and workarounds: where is the intended process being bypassed?
  • Business continuity: can the organization operate without disproportionate program intervention?

Stakeholder involvement also needs to change. Users and managers now provide operational evidence rather than hypothetical feedback. Process owners need to determine whether exceptions are temporary stabilization issues or symptoms of deeper process, data or solution gaps.

A temporary spike in support after go-live may be perfectly normal. Continued dependency on the program team months later is more significant.

Post-implementation: has adoption really occurred?

This is where OCM measurement often becomes weaker just as it becomes more meaningful. The program may be closing, consultants may be leaving, and governance may be transitioning to business-as-usual, but adoption is not established simply because implementation has ended.

We should now measure sustained behavior:

  • Sustained usage: are people continuing to use the new capabilities?
  • Process adherence: are intended processes becoming normal practice?
  • Proficiency: can users operate effectively without exceptional support?
  • Shadow processes: have legacy systems and practices genuinely disappeared?
  • Workarounds: what is still happening in Excel, email, shared drives or local tools?
  • Local variation: where are teams deviating from the target operating model, and why?
  • Stakeholder sentiment: are managers and users identifying new barriers or improvement opportunities?

This last point matters. Stakeholder engagement should not end because the solution has gone live. Feedback now becomes more valuable because it is based on real experience.

Continued spreadsheet use, for example, is not automatically evidence of failed adoption. Excel may remain entirely appropriate for analysis and flexibility. But when people reconstruct processes, data or decisions outside the new platform, it provides evidence worth investigating.

The question is not simply “Are people still using Excel?” but “Why do they still need to?”

Beyond adoption: did anything actually improve?

Even sustained adoption does not prove that the transformation was worthwhile.

ERP, CRM, PDM/PLM, MES and other enterprise platforms are rarely implemented simply to generate system usage. They are intended to improve business capabilities and outcomes.

Measurement therefore needs eventually to move beyond OCM activity toward value realization:

  • Process performance: cycle time, throughput, quality or other relevant operational outcomes.
  • Data quality and availability: has information become more reliable and usable?
  • Productivity: has unnecessary manual effort and duplication decreased?
  • Business performance: are the outcomes used to justify the transformation improving?
  • Operating-model effectiveness: are functions collaborating and making decisions as intended?
  • Benefits realization: are the benefits in the business case actually materializing?

McKinsey’s transformation research illustrates why this longer-term perspective matters: while 56% of respondents reported initially achieving most or all transformation goals, only 12% said those gains were sustained for more than three years. Respondents estimated that an average 42% of potential financial benefits was lost during execution and sustaining phases.

The specific KPIs will obviously vary. PLM engineering-change performance differs from CRM sales effectiveness, ERP financial close, or MES manufacturing performance. OCM metrics eventually need to connect to the business outcomes the transformation was intended to change.

Avoid the single adoption score

There is an obvious temptation to aggregate all of this into an executive-friendly number: “Adoption = 87%.”

I would be cautious.

A high login rate can coexist with poor process adherence. High training completion can coexist with low proficiency. Strong transaction volumes can coexist with extensive Excel workarounds. Positive stakeholder sentiment can coexist with poor business outcomes.

Enterprise transformation is too interconnected to assume that one aggregated number adequately represents adoption.

The dashboard should help leaders ask better questions rather than manufacture certainty.

Track the transition, involve the stakeholders

Perhaps the simplest model is:

  • Before go-live: Readiness — Can we operate?
  • Go-live and hypercare: Stabilization — Are we operating?
  • Post-implementation: Adoption — Are the new ways of working becoming sustained behavior?
  • Beyond implementation: Outcomes — Is the transformation producing the intended value?

Throughout these phases, the measures, stakeholders and ownership should evolve. The program may initially coordinate much of the OCM activity, but business leaders, process owners, managers and users increasingly need to own the evidence, decisions and improvements. This is consistent with the broader evidence on transformation sustainability: maintaining implementation rigor, active leadership and people-oriented practices into the later stages is associated with a much greater likelihood of sustaining performance improvements.

This is not a linear sequence. Enterprise transformations increasingly progress through successive releases and periods of stabilization, each introducing new change while the organization itself continues to evolve. Readiness, adoption and outcomes therefore form a continuous management cycle, with evidence from each iteration feeding the next set of transformation decisions. OCM therefore cannot be a workstream that finishes when the program finishes. It is a continuous process of engaging stakeholders, observing behavior, measuring outcomes and adjusting where the evidence tells us the transformation is not working as intended.

Perhaps the real test is simple:

If we stop engaging stakeholders and measuring adoption when the implementation team leaves, were we ever really measuring adoption—or just implementation?

The research basis is strong enough without overloading the article: Prosci says sponsors should remain “active and visible throughout the life of the project,” build coalitions and solicit management feedback; its broader research also identifies active and visible sponsorship as the leading contributor to change success. McKinsey provides the complementary post-implementation evidence: only 12% in its survey sustained transformation gains beyond three years, and organizations combining later-stage rigor, people goals and adequate resources were 3.4× more likely to sustain gains.

What are your thoughts?

References:

Disclaimer: articles and thoughts published on v+d do not necessarily represent the views of the company, but solely the views or interpretations of the author(s); reviews, insights and mentions of publications, products, or services do neither constitute endorsement, nor recommendations for purchase or adoption. 

Transformation Readiness and Adoption: Who Marks the Program’s Homework?

Lionel Grealou Digital Leadership 5 minutes

A recent discussion raised a deceptively simple question: why are transformation readiness and adoption so often reported by the same program team responsible for delivering the transformation?

This is common across large ERP, CRM, PDM/PLM, MES, and other enterprise transformation programs. The program establishes the milestones, defines the readiness and adoption measures, collects the evidence, and consolidates the status. The same governance structure then reports whether the organization is ready before deployment and whether the transformation has been successfully adopted afterward.

There is nothing inherently wrong with programs measuring these things; in fact, it is essential and often neglected by implementation partners. The problem arises when program reporting becomes the primary evidence that the organization is ready and that adoption has occurred. Delivery management and assurance then become difficult to distinguish.

Would we design financial, quality, cybersecurity, or regulatory controls this way? Probably not. So why do we accept it for transformations that can fundamentally change how an organization operates?

Readiness is not adoption

The distinction matters. Readiness asks whether the organization can operate effectively in the new environment. Adoption asks whether it actually does.

Transformation programs naturally operate around milestones: design completed, data migrated, testing passed, solution validated, users trained, and cutover approved. These are necessary controls, but completing them does not necessarily establish readiness.

The same problem continues after MVP deployment. Users have logged in, transactions are being processed, support tickets are declining, and legacy applications may have been switched off. Again, these are useful indicators, but they do not necessarily demonstrate adoption.

Training completion does not prove user competence. Successful migration does not prove that the data is sufficiently accurate and usable. Login statistics do not prove that the intended business process is being followed. Transaction volumes do not demonstrate that workarounds and parallel processes have disappeared.

We frequently measure what the program can easily observe and use it as a proxy for outcomes that are considerably harder to observe.

Why does everything become green?

Anyone who has worked on major transformation programs will recognize the pattern. As deployment approaches, readiness dashboards progressively move from red to amber and from amber to green. After go-live, adoption dashboards often follow a similar trajectory.

This does not require deliberate manipulation. Programs operate under pressure to deliver. Resources have been mobilized, business teams have prepared for cutover, partners have committed capacity, and leadership expectations have been established. Moving a deployment can have significant consequences.

Issues are therefore mitigated, actions assigned, workarounds accepted, and residual risks documented. A training gap becomes manageable because additional support will be available during hypercare. A data-quality issue is accepted because remediation can continue after deployment.

The same can happen with adoption. Low usage becomes a training issue. Continued spreadsheet use becomes temporary transition behavior. Process deviations become local exceptions. Benefits that have not materialized move into a longer-term benefits-realization horizon.

Each judgment may be reasonable. Collectively, however, they can create a substantial gap between program-reported success and operational reality.

The technology can be live without the transformation being adopted

ERP, CRM, PDM/PLM, and MES illustrate this particularly well because they sit within complex, interconnected business systems rather than operating independently. Transformation complexity does not come simply from the technology; it comes from the dependencies among people, processes, data, organizations, and multiple technology platforms. A program can therefore be green within its own boundaries while important dependencies remain unresolved elsewhere in the enterprise.

An ERP platform can be technically stable while procurement or finance teams manually compensate for process weaknesses. CRM can show excellent login statistics while sales teams maintain critical customer information elsewhere. PLM can successfully manage product structures and workflows while engineering teams continue exchanging information through spreadsheets and email. MES can process production transactions while operators maintain parallel processes because they do not yet trust or use the new environment efficiently.

In every case, the technology is live, and people may be using it. Yet the intended transformation may not have been adopted.

The relevant question is therefore not simply whether the system works, but whether the operating model works with it and has become the organization’s normal way of operating.

That requires evidence from real end-to-end processes. Can people execute their roles without program support? Have legacy processes genuinely disappeared? And, perhaps most revealingly, what work is still happening in Excel, email, shared drives, or other tools outside the intended process?

Continued use of Excel does not necessarily mean poor adoption. But when users rebuild processes, data, or decisions outside the new platform, it raises a sharper question:

Is this an adoption problem, or evidence that the transformation did not fully address how the business actually works?

These questions are harder to represent on a dashboard, but they are much closer to what transformation is supposed to achieve. The greater the transformation complexity and the number of interdependencies, the less credible a single aggregated readiness or adoption measure becomes.

Who owns the assessment?

The program should own its delivery plan and provide evidence against its commitments. Business leaders and process owners should own operational readiness and adoption. Technology, architecture, data, security, risk, and other functions should provide assurance within their respective domains.

The assumption that the program can also be the sole judge of the outcome it was established to deliver should be challenged.

This does not require another bureaucratic assurance layer. It requires credible challenge, clear accountability, and evidence that can withstand scrutiny outside the delivery organization.

Instead of asking whether training is green, ask whether people can perform the critical activities required by their roles. Instead of asking whether adoption has reached 90%, ask what that 90% actually represents. Instead of celebrating transaction volumes, determine whether the intended processes are being followed and whether parallel processes have disappeared.

Most importantly, ask:

What evidence would cause us to conclude that we are not ready or that adoption has not occurred?

If the governance process makes either conclusion practically impossible, then we are probably measuring progress toward an expected answer rather than objectively assessing transformation.

Go-live is not the finish line

Go-live is important, but it is ultimately the point at which many transformation hypotheses begin to be tested in the real organization.

Before go-live, we are primarily assessing readiness. After go-live, we can observe adoption. Only then can we properly assess outcomes and value realization.

These should not be collapsed into a single program status. An organization can be ready but experience weak adoption. It can achieve high system usage without delivering the expected business outcomes. Equally, adoption can take longer than planned while ultimately producing substantial value.

The underlying issue therefore extends beyond change management and beyond ERP, CRM, PDM/PLM, or MES. It is a question of transformation governance.

Readiness should demonstrate that the organization can operate. Adoption should demonstrate that it is operating in the intended way. Outcomes should demonstrate that the change is delivering the value that justified the transformation.

The program should provide evidence and make its recommendation, but it should not be the only judge of whether that evidence proves success.

What are your thoughts?

Disclaimer: articles and thoughts published on v+d do not necessarily represent the views of the company, but solely the views or interpretations of the author(s); reviews, insights and mentions of publications, products, or services do neither constitute endorsement, nor recommendations for purchase or adoption. 

The AI Layoff Illusion: A Digital Transformation Problem Hiding in Plain Sight

Lionel Grealou Business Digital PLM 5 minutes

Recent industry layoffs framed as “AI replacing jobs” reflect a deeper issue in digital transformation: organizations are optimizing cost faster than they are redesigning how work and decisions actually operate.

The current wave of AI-driven layoffs is often presented as a natural progression of digital transformation. The narrative is simple: AI improves productivity, automation reduces the need for human labor, and organizations adjust accordingly.

Recent developments appear to support this view. Oracle’s restructuring, tied to increased investment in AI infrastructure, is one example among many. At the same time, governments such as China are beginning to introduce measures to limit or shape AI-driven workforce reductions, signaling that the transition is not purely technical.

However, when viewed through a digital transformation lens, these signals do not describe a straightforward substitution of human work by AI. They point instead to a structural imbalance. Organizations are moving quickly on cost reduction while moving more slowly on redesigning how work and decisions are actually performed.

Work Is Not Being Redesigned, Only Reduced

At the core of the issue is a mismatch between how work is structured and how it is being reduced.

Work inside engineering and industrial organizations is not defined by roles alone. It is defined by a combination of tasks, decisions, and exception handling mechanisms that evolve over time. These elements are often distributed across systems, teams, and informal practices.

In many current transformation efforts, organizations are reducing roles without first decomposing the underlying work. Decisions still need to be made, knowledge still needs to be applied, and exceptions still need to be resolved. When these capabilities are removed without redesigning how they are executed, the system becomes unstable.

This explains early signals of rehiring or re-engagement of subject matter experts in some sectors. The issue is not that AI failed. It is that the operating model was not redesigned before capacity was reduced.

From Transformation to Capital Reallocation

What is often framed as AI-led transformation is, in many cases, closer to capital reallocation.

Organizations are shifting investment from labor to infrastructure. Spending increases on data platforms, AI models, and compute capacity, while workforce costs are reduced. This can improve financial metrics in the short term, but it does not automatically translate into improved operational performance.

Transformation, in contrast, requires a redesign of how value is created. It involves redefining decision flows, clarifying ownership, and aligning data to support those decisions. Without this layer, cost optimization risks removing critical capabilities faster than they can be replaced.

This distinction is particularly relevant in engineering contexts, where decision quality directly affects product integrity, compliance, and time-to-market.

The Missing Layer: Decision Architecture

Digital transformation programs have historically focused on systems, processes, and data integration. What remains underdeveloped in many organizations is the explicit definition of decision architecture.

Decision architecture defines how decisions are made across the lifecycle, including ownership, required evidence, escalation paths, and validation mechanisms. It provides the structure that connects data and processes into a coherent system.

Without this structure, organizations rely on tacit knowledge embedded in individuals and teams. When those individuals are removed, the decision system does not disappear. It becomes fragmented and less predictable.

AI can support decision-making, but it requires a well-defined context. In the absence of clear decision architecture, AI amplifies existing inconsistencies rather than resolving them.

Why Engineering Feels the Impact First

The effects of this imbalance are most visible in engineering and product development environments.

Engineering work is inherently decision-intensive. It requires continuous trade-offs between performance, cost, compliance, and time constraints. These decisions depend on context, experience, and access to structured data.

When workforce reductions occur without corresponding redesign, engineers are left to absorb the resulting complexity. This often leads to increased rework, longer decision cycles, and a growing reliance on informal workarounds to compensate for system gaps.

In this context, AI can assist with analysis and automation, but it cannot replace the need for coherent decision structures. The result is a system expected to operate faster but become more fragile.

AI as an Amplifier of System and Data Quality

AI capabilities are often presented as independent drivers of change. In practice, they act as amplifiers of the legacy systems and existing data.

In environments where data is connected, relationships are defined, and decision ownership is clear, AI can extend its capabilities. It can support scenario exploration, improve responsiveness, and enhance decision quality.

In fragmented environments, AI accelerates the generation of partial insights and exposes gaps in data and governance. It increases the speed at which inconsistencies propagate across the system.

This explains why similar AI investments produce very different outcomes across organizations. The determining factor is not the sophistication of the model, but the maturity of the underlying digital transformation.

An Ecosystem Under Tension

The emergence of government intervention, such as the measures introduced in China, highlights a broader systemic tension.

Organizations are under pressure to improve productivity and demonstrate AI adoption. Governments, meanwhile, are increasingly aware of the workforce disruption and capability risks associated with rapid automation-driven restructuring.

At the same time, enterprises themselves are discovering that removing expertise is easier than replacing operational knowledge. Many engineering and industrial environments still depend heavily on tacit understanding accumulated through experience, collaboration, and exception management.

This creates a contradiction at the center of the current AI transition. Enterprises are accelerating infrastructure investment, while many underlying operating models remain insufficiently redesigned for AI-enabled execution.

The Risk of Optimizing Before Redesigning

A consistent pattern is beginning to emerge across sectors.

Organizations optimize cost first and redesign work second. This sequencing creates short-term financial gains but often introduces medium-term correction cycles. These corrections manifest as rehiring, project delays, quality issues, and increased organizational friction.

The problem is not the adoption of AI itself. The problem is assuming that workforce reduction and digital transformation are interchangeable.

Digital transformation is not achieved when technology replaces labor. It is achieved when organizations redesign how decisions, workflows, and knowledge interact within a connected environment.

That is a far more complex undertaking.

Implications for Engineers and Transformation Leaders

For engineers, the implications are significant. Engineering functions are becoming central to how organizations rethink decision-making, traceability, and lifecycle continuity in AI-enabled environments. The discussion is therefore shifting from simple automation toward:

  • Decision integrity
  • Connected data foundations
  • Governance of engineering knowledge
  • And the ability to maintain coherence across increasingly distributed systems

This is where digital thread, PLM, and systems engineering become strategically important. They provide the structural framework required for AI to operate with context and continuity rather than as an isolated productivity layer.

For transformation leaders, the challenge is equally clear. AI adoption without an operating model redesign risks scaling inconsistency outpacing capability.

A More Accurate Framing

The current transition is often framed as AI replacing humans.

A more accurate interpretation is that organizations are attempting to remove labor faster than they are redesigning how work, knowledge, and decisions are structured. That distinction matters.

It explains why contradictory signals are emerging simultaneously:

  • Layoffs alongside rehiring
  • Automation alongside knowledge gaps
  • Acceleration alongside growing governance concerns

The issue is not whether AI will transform engineering and industrial work. It already is.
The real question is whether organizations are prepared to redesign the underlying decision ecosystems before removing the capabilities that currently hold them together.

What are your thoughts?

Disclaimer: articles and thoughts published on v+d do not necessarily represent the views of the company, but solely the views or interpretations of the author(s); reviews, insights and mentions of publications, products, or services do neither constitute endorsement, nor recommendations for purchase or adoption. 

MY FIRST BOOK: Adaptive Intelligence, AI, and the Future of PLM

Lionel Grealou Business Digital PLM 4 minutes

Book launched at ACE 2026 in Miami (April 2026)

Engineering and manufacturing are entering a phase characterized by increased connectivity, product complexity, software proliferation, and rising AI-driven expectations.

The implications extend far beyond technology adoption. They increasingly affect how enterprise PLM is structured, governed, scaled, and operationalized across the lifecycle.

At the same time, many organizations are still struggling with fragmented systems, disconnected decision-making, inconsistent governance, and transformation fatigue.

AI is accelerating expectations across the enterprise. AI accelerates execution. Without lifecycle coherence, it also accelerates inconsistency.

Those challenges became central themes in Adaptive Intelligence: Rethinking PLM in the Age of AI & Digital Thread, the first book I had the opportunity to lead as Editor, in which I curated and connected 10 industry perspectives on the future of PLM, AI, and digital transformation.

The Intent Behind the Book

The book was launched at ACE 2026 and distributed to registered attendees by Aras.

It brings together ten perspectives from industry practitioners across different leadership roles, industries, and technology domains. The objective was not to promote a single methodology, platform, or vendor narrative.

The intent was to explore how PLM is evolving in practice as organizations attempt to connect engineering, manufacturing, software, supply chains, operational data, and increasingly AI-driven capabilities across the enterprise.

What made the process particularly valuable was the diversity—and sometimes contradiction—of perspectives involved. Some contributors approached transformation through simulation and digital twins. Others focused more heavily on governance, traceability, software-defined products, AI enablement, organizational adoption, or supply chain continuity.

Several viewpoints openly contradicted each other. Over time, it became clear that this tension was precisely the point. The industry is not converging toward a single model of PLM transformation. It is navigating a broader restructuring of how engineering, manufacturing, software, and operational decisions remain connected over time.

Key Themes That Emerged

Despite different vocabularies and priorities, contributors repeatedly converged on a few fundamental realities:

  • AI without connected and governed data simply accelerates inconsistency.
  • Digital transformation remains more constrained by organizational behavior and fragmented decision-making than by technology itself.
  • The digital thread is evolving from a systems-integration challenge into a decision-continuity challenge.
  • PLM is progressively evolving from a system of record into a system of decision, the digital backbone of product innovation across the broader operational intelligence landscape.

A central theme that repeatedly emerged was decision integrity.

The challenge is no longer simply managing data or integrating platforms. It is maintaining continuity of decisions, assumptions, accountability, and context across highly distributed ecosystems of people, suppliers, platforms, AI agents, and operational workflows.

That may ultimately become one of the defining industrial challenges of the next decade.

AI, Scalability, and Lifecycle Coherence

Several contributors also reinforced an important nuance that remains under-discussed in many digital transformation programs: scalability is not simply about deploying technology faster.

It is about sustaining decision integrity as products, regulations, software dependencies, supply chains, and operational realities continuously evolve.

That becomes highly visible when organizations attempt to operationalize AI at scale.

AI can dramatically accelerate workflows, automation, and analysis. However, if the underlying lifecycle data lacks governance, context, ownership, or traceability, AI can amplify inconsistency across the enterprise at unprecedented speed.

This is where governance, decision continuity, and lifecycle context become critical.

Another recurring theme was the need to balance experimentation with stabilization.

Across many transformation programs, organizations are under pressure to modernize continuously while simultaneously maintaining operational continuity. That balance becomes even more difficult as AI accelerates expectations across engineering, manufacturing, and enterprise IT functions.

Several discussions throughout the book reinforced that transformation fatigue is becoming a real enterprise risk.

Organizations cannot endlessly layer initiatives, pilots, platforms, and operating model changes without also investing in simplification, adoption, learning cycles, and organizational clarity.

In many ways, the future of PLM may depend less on adding more systems and more on improving how decisions, context, and lifecycle knowledge remain connected over time.

A Personal Reflection

A sincere thank you to all contributors who helped shape this work through their experience, challenges, and perspectives: Marcellus Menges, David Long, Jim Cashman, Sree Krishna Manikanta Vaddi, Sumit Kumar, Chris McDermott, Bryan Riley, Tony Affuso, Amol Chitte, and Rob McAveney; with a foreword from Leon Lauritsen.

I appreciated the opportunity to maintain a practitioner-led, editorially independent perspective throughout the project, with Aras’s trust and support. Special thanks to Josh Epstein, Brigitte Spencer, and Mary O’Hara for supporting and coordinating the initiative throughout the process.

Personally, the experience reinforced something I increasingly observe across digital transformation initiatives and associated corporate ambitions: technology maturity is accelerating faster than organizational maturity.

AI, simulation, connected platforms, and digital thread capabilities are advancing rapidly. Yet many enterprises still struggle with fragmented ownership, inconsistent governance, disconnected processes, and siloed decision-making. That gap may ultimately define the next decade of industrial transformation more than the technology itself.

One thing the process also reinforced for me is that transformation remains fundamentally human. Technology can accelerate transformation, but it rarely creates it on its own. Meaningful change still depends on people willing to challenge assumptions, rethink operating models, and actively drive transformation rather than simply optimize existing ways of working.

What are your thoughts?

Disclaimer: views and interpretations published on v+d are solely those of the author(s) and do not necessarily represent the views of associated organizations. References to products, companies, or services do not constitute endorsement or recommendation.