The product you designed is not necessarily the product operating in the field

For engineering, manufacturing, service, quality and asset management leaders, the challenge is no longer simply having asset data, but rather knowing whether that data accurately represents what is operating in the field.

This article explores how asset information becomes fragmented across the lifecycle, why maintaining a trusted as-maintained view is so difficult, and how PTC Orbit can create a unified asset intelligence layer across existing enterprise systems. It also highlights practical implications for engineering changes, service planning, quality investigations and installed-base analysis.

It’s imperative to realize the same physical asset can have several representations:

  • As-designed – what engineering intended to build,
  • As-built – what manufacturing actually produced,
  • As-maintained / as-operated – what is physically installed and operating after commissioning, repairs, replacements, retrofits, upgrades, etc.

These representations are not static. An asset can gradually change and diverge from its original configuration due to its operational life. This can happen as a result of many manufacturing or servicing activities. A typical example:

Engineering releases a product with a particular component revision. Manufacturing builds the product using the released configuration. The asset is shipped and installed. A service technician later replaces a component with a newer approved part. A customer requests a modification. Another component is replaced under warranty. As a result, the asset now has a configuration that may no longer be represented accurately in engineering Product Lifecycle Management or the original manufacturing record.

The business may have all the individual pieces of information, but they may reside in different systems and belong to different organizational owners. As a result, the real problem is not necessarily a lack of data, but a lack of continuity of it and its relevant context across the asset lifecycle.

Why fragmented asset data breaks asset lifecycle continuity

As mentioned before, multiple departments can operate on a different context-oriented configuration of the same asset. For example, Manufacturing would utilize the most data regarding manufacturing records, production processes, deviations, substitutions etc. – a data set vastly different from the one operated by the Operation, which instead focuses on performance, telemetry and asset health.

The problem is created when these views remain organizationally and technologically disconnected. Every department owns a piece of the asset history, each maintaining different categories of information best-related to its purpose. No individual system is necessarily wrong. The problem is that the organization cannot reliably reconstruct the current state of the physical asset from those systems if they’re dispersed.

In practice, lifecycle information is distributed across multiple enterprise systems, each designed to support a different business function. Engineering data may reside in PLM, production information in ERP or MES, service history in EAM or FSM, while Customer Relationship Management platforms provide customer and commercial context. This creates a broader PLM-ERP-CRM integration challenge in which the organization must understand not only individual records, but also how they relate to the same physical asset.

The challenge is therefore not simply shifting asset data from one platform to another. It is about connecting information from these and other enterprise systems while preserving the relationships, history and engineering context required to understand the asset correctly.

Why the as-maintained system is difficult to keep accurate

Because of the before-mentioned lifecycle changes to individual assets, the as-maintained configuration is difficult to maintain in a static manner, but should rather be a living representation, evolving with the physical asset. This is particularly important for enterprise asset management, where decisions about maintenance, service and asset performance depend on knowing the actual configuration and history of each physical asset.

Typical organizations trying to stay up-to-date with industry best practices have invested significantly in PLM, ERP, CRM, MES, EAM/CMMS, FSM, and IoT platforms. Their existence does not automatically create a unified asset view. One system may identify an asset by serial number, another by equipment ID, another by customer reference, and another through a service or work-order identifier. This creates apparently duplicate assets, missing relationships and ambiguity about whether two records refer to the same physical object.

Effective asset data consolidation must therefore go beyond bringing records into a single location. It has to resolve asset identity, establish relationships between records and preserve its context.

A maintenance event may be recorded in FSM/EAM but not immediately propagated to engineering or quality systems. Similarly, engineering may release a new component revision without an immediate understanding of exactly which installed assets contain the affected component.

Without a shared view, management of these data in efforts to transform it into holistic asset representation requires a dedicated solution. Without it, manual reconciliation becomes not only inefficient, but also error-inducing, often creating more issues instead of solving them.

PTC Orbit: an asset intelligence solution for the complete asset lifecycle

PTC Orbit connects engineering, manufacturing, service and operational data into a unified asset intelligence layer. Rather than creating another isolated repository, Orbit aggregates and connects information from systems such as PLM, ERP, MES, EAM/CMMS, FSM, CRM and IoT platforms. The objective is to create one trusted asset record that provides lifecycle context: from the as-designed and as-built states through the as-maintained configuration and into operational performance.

By creating relationships between records associated with the same physical object, Orbit reconciles asset data originating from different systems and organizational functions. This allows the asset itself, rather than an individual application, to become the common point of reference.

At the foundation is data unification and validation. Dispersed records must first be associated with the correct physical asset and brought into a common structure. Orbit’s data foundation uses aggregation, data unification and validation, followed by a semantic layer that applies business and engineering meaning to the data. This process is critical: gathering records is not sufficient if the organization cannot determine what those records mean, how they relate to one another, or whether they describe the same physical asset.

On top of this foundation, PTC Orbit adds an Artificial Intelligence layer. This creates the basis for AI-powered lifecycle intelligence, combining trusted asset context with analytics and intelligent recommendations. Users can explore asset data without having to manually investigate individual source systems and can analyze relationships across engineering, manufacturing, service and operational information. With sufficient operational and historical information, such intelligence can help detect service patterns, identify anomalies and support organizations as they calculate asset health scores for individual assets or an asset group. This functionality is called AI Canvas, as it allows the user to freely configure and „paint” the interface suited to their needs.

Orbit creates a trusted, contextualized view across existing systems and uses that unified asset context as the foundation for extended intelligence and decision-making.

What changes?

A typical issue stems from disconnected systems. When the data is contextualized against certain system, not the asset itself, different asset definitions may lead to an uncertainty about asset’s actual state. This in turn usually leads to a manual reconciliation of the data. This process is often required to be undergone more than once, depending on the type of information needed for a specific decision to be made. This slows the process significantly, making said decision more difficult to make and – as a result – less impactful.

With PTC Orbit the data is connected via an unified asset record. This provides a contextualized lifecycle history across multiple specialized systems. It ensures a trusted configuration record. Executed actions are coordinated, rooted in verified data, but also providing relevant feedback based on their results.

  • Before approving a design change, Engineering can investigate which installed assets contain the affected component and correlate them with service and operational history.
  • A failure can be associated with particular asset configurations, components, suppliers, lots and service histories rather than treated as an isolated incident.
  • The organization can select the appropriate parts, technician capability and service action based on the actual asset configuration rather than the generic product model. Better visibility into installed configurations and historical interventions can also help organizations understand future service and maintenance demand and plan resources more effectively.
  • Instead of contacting every customer owning a product family, the organization can identify the specific assets and configurations that require action. The same visibility can support more targeted aftermarket revenue programs, allowing service organizations to identify relevant installed assets and offer appropriate upgrades, maintenance activities or lifecycle services based on their actual configuration and history.
  • Field performance can be fed back into engineering so that future product decisions are based on actual operating evidence.

Asset intelligence Use Case: from product lifecycle change to installed-base impact

Business context

A manufacturer produces a complex industrial machine with hundreds of components and sells it globally. Engineering discovers that a particular component should be replaced by a revised version because field data indicates that the original component has a higher-than-expected failure rate.

Without a unified asset view

The investigation requires several teams, becoming cross-functional:

  1. Engineering identifies the affected component revision in PLM.
  2. Manufacturing provides historical production information.
  3. Service provides records of component replacements.
  4. Quality provides warranty and failure records.
  5. Operations data is investigated separately for actual asset performance.
  6. Analysts manually reconcile serial numbers and configurations.
  7. Management waits for a consolidated estimate of the affected population.

With PTC Orbit

Because of Orbit’s connection to organization’s PLM, ERP/MES, service management/EAM and relevant operational or IoT data sources, this process is streamlined significantly. The resulting unified asset record allows the organization to move from a product-level question to an asset-level question.

Orbit can connect the engineering definition of the vulnerable component with the corresponding assets, their configurations and their service histories. The organization can then identify where the affected configuration exists and distinguish assets that require action from assets that are already compliant. By adding quality, operational and service information, the same analysis can also identify whether the affected configuration correlates with particular failure patterns, operating conditions or maintenance histories.

The value is not simply that the data has been brought into one interface. The value is based on the fact the asset becomes the common context through which engineering, service and quality information can be interpreted. Engineering can assess the impact of the change; quality can investigate the associated failure population; service can identify the assets requiring intervention; and management can estimate the operational and commercial consequences using the same underlying asset context.

The organization moves from:

“We believe approximately 2,000 machines could be affected.”

to:

“These specific assets contain the affected configuration; these have already been modified; these remain exposed; these customers require action; and these assets exhibit the associated failure pattern.”

Important note on data quality

Orbit’s architecture explicitly places data aggregation, unification, validation and semantic modeling beneath the AI layer.

Therefore:

  • Establish asset identity.
  • Resolve relationships between systems.
  • Validate data quality and configuration consistency.
  • Define the semantic meaning of important asset information.
  • Establish governance and ownership.
  • Apply analytics and AI to the resulting asset context.

AI cannot compensate for an asset record that the organization cannot trust. The quality of asset intelligence is bounded by the quality, consistency and context of the data underneath it.

Closing remarks

Most manufacturers already have substantial amounts of lifecycle data. The question becomes: „Can the organization reliably connect that data to the physical asset that exists today”?

Once an asset leaves the factory, its configuration continues to evolve. Managing that evolution requires a connected understanding of the asset across its lifecycle. PTC Orbit addresses this gap by creating a unified asset intelligence layer across existing enterprise and operational data, providing the foundation for faster decisions, stronger traceability, better service outcomes and continuous feedback from the field into engineering. The ultimate objective is to know what the company designed or built, but also to know what is actually operating in the field — and to make that knowledge actionable.