The first version often starts with columns: customer, site, model, serial number, warranty date and last service. That is enough to make a list. It is not enough to answer the questions that create value after the sale. Which motor sits in the package now? When did the operator move it? Which software version was running when the fault occurred? Did the customer buy the machine directly, or did a dealer place it there? Which source proves the answer?
Those questions span different kinds of facts. An asset has identity. A customer plays a role. A site contains functional positions. Components occupy positions for a period. Service, shipment and commissioning create events. Documents and source systems provide evidence. If the data model treats all of them as fields on one row, the team must overwrite history or create another row that nobody can reconcile.
This guide shows how to model the equipment record as a small set of objects, relationships and events. It is detailed enough for an industrial OEM to design the schema, map existing systems and test the first product family without trying to rebuild ERP, PLM and field service in one database.
Start with the decisions the record must support
List the decisions that require equipment data before you design the schema. A service coordinator needs to identify the affected unit and its location. A parts specialist needs the configuration and effectivity rules. Warranty needs the covered object, trigger and usage. Engineering needs an affected-serial list. An account manager needs the active fleet and credible upgrade candidates.
Each decision gives the model a test. If the proposed record cannot answer it without opening five systems and comparing notes, the model is missing an object, relationship or event. If a field has no decision behind it, leave it out of the first release. Industrial asset schemas become unusable when teams collect hundreds of attributes that no workflow maintains.
| Decision | Minimum equipment facts |
|---|---|
| Dispatch service | Physical asset, current site, access, status, symptom and coverage |
| Quote a spare | Asset, current component, position, serial effectivity and approved successor |
| Decide warranty | Covered object, contract, start event, limits, usage and failure date |
| Issue a bulletin | Affected model, part, configuration, serial range and modification state |
| Propose an upgrade | Current state, compatible target, operating context and account role |
Choose the equipment boundary
An asset record should represent a physical object that the OEM needs to identify through time. Give a component its own identity when it can move between parent machines, carry separate coverage, receive software, appear in a safety or compliance action, or determine whether a part fits. Model ordinary fasteners and consumables as quantities unless the business has a specific traceability requirement.
Write the boundary for each product family. A packaging-line OEM may identify the line, each machine, the controller and each high-value servo drive. A pump OEM may identify the skid, pump, motor and variable-frequency drive. The model can still relate untracked components through part and position. It does not need a serial record for every washer.
IFS distinguishes serial and functional service objects. A serial object can move; a functional object represents a stable place or function. That distinction is more useful than a blanket rule that every maintained object must look the same.
Use five core objects
Most industrial OEMs can begin with five objects: product model, part, physical asset, site and functional position. Separate them even when one system stores several in the same table. Their identities and lifecycles differ.
The product model holds the family description and service defaults. The part identifies a manufactured, purchased, stocked or sold item. The asset identifies one physical instance. The site identifies a customer location. The functional position identifies the stable duty that an asset fills at that site. A motor can leave one position, enter repair inventory and later serve another machine without becoming a new motor.
| Object | Identity | Changes when |
|---|---|---|
| Product model | OEM model code | The reusable product definition changes |
| Part | Part or item number plus revision where applicable | The controlled item definition changes |
| Physical asset | Permanent asset ID plus serial and aliases | The physical object is created, merged or retired |
| Site | Permanent location ID | The customer location opens, changes or closes |
| Functional position | Reference designation within a site or system | The stable function or site structure changes |
Give every physical asset a durable identity
Create an internal asset ID that never carries business meaning. Customer name, location, owner and parent can all change. The ID should survive those changes. Store the manufacturer serial, customer tag, barcode, connected-device ID and old system keys as identifiers attached to the asset.
Do not assume that a serial number is globally unique. A supplier can reuse a serial across part families. A merger can bring two serial schemes together. A customer can type the same tag on unrelated sites. Define the scope for each identifier: manufacturer plus serial, part plus serial, customer plus site plus tag, or source system plus native key.
Oracle Installed Base uses a unique instance number and treats serial number as a separate attribute whose uniqueness depends on inventory setup. That is a useful pattern: one permanent internal key, many externally meaningful identifiers.
| Identifier | Example | Uniqueness scope |
|---|---|---|
| Asset ID | AST-01J8F4… | Global and permanent |
| OEM serial | PX4-02481 | Manufacturer and product family |
| Customer tag | FILLER-04 | Customer site |
| Device ID | gateway-9ac2 | Telemetry platform |
| Legacy key | SAP-EQ-10003842 | Source system |
Model roles instead of one customer field
One “customer” column collapses relationships that often diverge. The sold-to party may be a distributor. A leasing company may own the machine. A contract manufacturer may operate it. Another legal entity may buy parts and service. Record the party, role and effective interval as a relationship to the asset or site.
This matters when the machine changes hands. Closing the old owner relationship and opening the new one preserves the original sale and service history. Overwriting the customer field erases the chain and can expose contract or service information to the wrong party.
| Role | Typical question |
|---|---|
| Sold to | Who placed the original order? |
| Owner | Who owns the equipment today? |
| Operator | Who runs it and reports operating conditions? |
| Service account | Who requests and pays for field work? |
| Warranty beneficiary | Who can make a claim? |
| Channel partner | Who sold or services it under agreement? |
Separate site, location and position
A site is a customer facility. A location is a physical area inside it. A functional position describes the role in the customer’s system. These can share one hierarchy for a simple product, but the model should preserve the distinction. The same pump can move from a warehouse to standby duty and then into the process line while its asset identity remains unchanged.
SAP describes a functional location as the place where equipment can be installed and where teams preserve the history and requirements of that function. IEC 81346-1 gives general structuring principles and unambiguous reference designations for objects in industrial systems. Use the customer’s existing designation system where it is sound; do not invent a parallel plant hierarchy only for the OEM portal.
Store an installation as a dated relationship between asset and position. That lets the model answer where the asset is now and where it served last year. SAP’s equipment installation history follows the same logic: installation and dismantling produce time periods instead of one overwritten location.
Represent hierarchy as dated relationships
Do not put parent serial number directly on the asset and overwrite it when a component moves. Create a relationship with parent asset, child asset, relationship type, position, valid-from, valid-to and evidence. The current configuration is the set of relationships active at a chosen time.
Use explicit relationship types. “Component of,” “installed at,” “controlled by,” “supplies” and “connected to” mean different things. A drive can be a component of a machine and connected to a motor. A chiller can supply several machines without becoming their parent.
IFS supports parallel functional, location, process and electrical structures. The lesson is practical: forcing every useful relationship into one tree hides how the system works.
| Relationship | From | To | Required dates |
|---|---|---|---|
| Component of | Servo drive | Packaging machine | Install and removal |
| Installed at | Packaging machine | Line 4 / filler position | Install and removal |
| Controlled by | Machine module | PLC | Commission and replacement |
| Supplied by | Three machines | Compressed-air system | Connection and disconnection |
| Located at | Spare motor | Customer stores | Receipt and issue |
Preserve the states that explain the current configuration
The accepted order, manufactured unit, shipment, commissioning result and maintained asset can all describe different configurations. Store those baselines separately. Do not copy the released engineering BOM into the asset and call it current forever.
The as-sold baseline answers what the customer bought. The as-built baseline records what manufacturing produced. As-shipped records which serialized units left and how modules were grouped. As-installed records what commissioning placed in service. As-maintained records the configuration after field replacements, software updates and modifications.
Siemens describes physical asset configuration as the mechanical, electrical, software and document state of a specific asset plus its change history. Siemens also distinguishes the service BOM, which defines how the product can be serviced, from the physical BOM of one asset. That distinction prevents the product template from drifting every time one machine changes.
| State | Created from | Do not use it to answer |
|---|---|---|
| As-sold | Accepted quote and order | What actually shipped |
| As-built | Manufacturing serial record | What site work changed |
| As-shipped | Delivery and packing events | What entered service |
| As-installed | Commissioning and acceptance | What later service changed |
| As-maintained | All effective configuration events | Original contractual scope |
Use an event ledger for every physical change
Events explain why the current record changed. Create event types for manufacture, ship, receive, install, commission, relocate, replace, repair, modify, update software, inspect, deactivate and dispose. An event carries time, actor, source, affected assets, before state, after state and the work order or document that authorized it.
Write the state change and event in one transaction where possible. A component replacement should close the old parent-child interval, open the new one and record the removed and installed serials. If only the service note is saved, the asset hierarchy stays wrong. If only the hierarchy changes, nobody can audit why.
Late data needs both event time and recorded time. A technician may enter Monday’s replacement on Thursday. The configuration should take effect on Monday while the audit shows that the system learned it on Thursday.
| Event field | Purpose |
|---|---|
| Event ID and type | Stable identity and controlled meaning |
| Occurred at | When the physical world changed |
| Recorded at | When the system received the information |
| Actor and organization | Who performed or reported the work |
| Affected assets and positions | What changed and where |
| Before and after | State transition |
| Source and authorization | Work order, certificate, shipment or approved change |
Treat software, documents and settings as configuration
Modern industrial equipment can change behavior without changing a physical part. Record controller, device, software product, version, parameter set and deployment date. Link the software state to the physical asset or component that runs it. A top-level “firmware version” field fails when the machine contains six controllers.
Documents also need applicability. A manual, wiring drawing, certificate or service bulletin can apply to a model, serial range, component, software version or one modified asset. Store the controlled document ID and revision as a relationship. Do not attach a PDF to every asset and lose the rule that determines where it applies.
Model warranty and contract coverage separately
Coverage is not a property of the asset alone. It is an agreement that applies to an object for a period under stated conditions. Create a coverage record with provider, beneficiary, covered object, start trigger, limit, inclusions, exclusions and source clause. Link usage meters when hours or cycles can end coverage before the calendar date.
One asset can carry several coverages. The OEM warranty can apply to the machine. A supplier warranty can apply to a replacement motor. A service contract can cover labor at a group of sites. SAP allows warranty processing against equipment, functional locations, installed bases and serialized materials. Your model should also name the exact covered object.
Attach service history to the object that failed
A work order may concern a complete line while the failure belongs to one encoder. Link the case to the reported asset, the diagnosis to the failed object and each part movement to the affected position. Preserve symptom, cause, remedy and result as separate fields. “Pump failed, replaced seal” does not say whether the seal caused the failure or was replaced as routine work.
Use the product taxonomy to constrain failure codes. A drive and a gearbox should not share a flat list of hundreds of failure modes. ISO 14224, although written for petroleum and related industries, shows the pattern clearly: equipment taxonomy, equipment attributes, failure data and maintenance data form distinct categories, with data quality controls for exchange between owner, manufacturer and contractor.
The service completion should update the configuration when work changes it. Make configuration update a closeout requirement for jobs that install, remove, exchange or modify a tracked object.
Record provenance at the property level
The asset record will combine ERP, PLM, field service, telemetry, customer files and employee confirmation. A single source field on the asset is too coarse. Track source system, source record, observed time, imported time and confidence for material properties and relationships.
A shipment can prove that the OEM sent serial 4812 to the customer. It does not prove that the asset remains at that site. A commissioning certificate can prove installation. A recent field visit can confirm current location. Store the strongest evidence and retain the earlier events instead of declaring one system authoritative for every point in the lifecycle.
ISO 8000-100 addresses master-data quality at the property-value level and at interfaces between systems. That matches the installed-base problem: the team needs to know whether this value is complete, accurate and exchangeable, not whether the asset row has a green badge.
| Evidence grade | Example | Permitted use |
|---|---|---|
| Observed | Technician scanned serial at the site yesterday | Service, warranty and part selection |
| Transactional | Shipment or completed work order names the serial | Planning; verify if the decision depends on current location |
| Reported | Customer spreadsheet lists the asset | Outreach and review |
| Inferred | Model, account and date match an unlinked record | Candidate match only |
| Conflicting | Two active sites claim the same serial | Block automated entitlement and dispatch |
Assign one owner to each fact
The combined equipment view can cross many systems, but each governed fact needs one owner. ERP may own the manufactured serial and shipment. PLM may own model, part and service definition. Field service may own completed work. An installed-base service may own current physical relationships. CRM may own the account and commercial action.
Store each external key and sync state. Do not copy data in both directions without a rule. If ERP changes a customer address while a technician changes the physical site, those are different facts. If two systems both change the same installation relationship, stop and route the conflict.
| Fact | Typical owner | Installed record stores |
|---|---|---|
| Product model and released service definition | PLM | Reference, revision and applicability |
| Part, serial production and shipment | ERP | Reference and transaction event |
| Current installation relationship | Installed-base or service master | Dated relationship and evidence |
| Completed service work | Field service | Work reference, findings and resulting change |
| Account and contact | CRM or customer master | Party relationship and role |
| Telemetry stream | IoT platform | Asset-device mapping and derived events |
Define required fields by lifecycle event
Do not make every field mandatory when the candidate asset first appears. Require the information available at each event. Manufacturing can create asset ID, model, part and serial. Shipment can add customer and order. Commissioning can confirm site, position, configuration and operational date. Service can add current readings, replacements and findings.
Use validation rules that match the object. A serialized asset needs its serial scope. A functional position needs a site and reference designation. A software deployment needs a target component and version. A warranty record needs a covered object and start rule. Generic completeness percentages hide whether the missing field actually blocks the next decision.
| Lifecycle event | Required result |
|---|---|
| Manufacture | Asset ID, product or part, serial and as-built baseline |
| Ship | Order, recipient, serialized contents and shipment event |
| Commission | Confirmed site, position, operational date and accepted configuration |
| Service close | Target asset, finding, work, part movement and resulting state |
| Relocate | Old interval closed, new site or position opened and authority |
| Retire | Status, date, reason and disposition |
Migrate records as claims, not truths
A migration file can say that a serial belongs to a site. It cannot prove that the field remains correct. Import each source record with its provenance, then match it to the durable objects. Use deterministic rules first: exact source key, exact serial in a known scope, shipment line or prior cross-reference. Send ambiguous candidates to review.
Do not merge records only because customer, model and approximate date match. A customer can own several identical machines. Preserve the candidate links and evidence until a person or later event resolves them. Likewise, do not discard an old record because it conflicts. The conflict may reveal a site move, swap, duplicate serial or bad transaction that affects warranty and service history.
Load one product family, inspect the exceptions and improve the rules before scaling. The hard cases will expose the real identity scheme faster than a six-month data-model workshop.
Worked example: one drive moves through three machines
A servo drive, serial SD-8812, ships inside packaging machine PM-204 at the customer’s Monterrey site. Commissioning confirms the machine at functional position Line 2 / Cartoner. The model creates an asset for the drive and a component relationship to PM-204 effective on the commissioning date.
Eighteen months later, service exchanges the drive after an intermittent fault. The work order closes SD-8812’s relationship to PM-204, installs SD-9420 and moves SD-8812 into the OEM repair loop. The machine’s current view now shows SD-9420. Its historical view still shows that SD-8812 ran when three earlier alarms occurred.
Repair finds no fault. The depot updates SD-8812’s status and installs firmware 6.4. Two months later, the OEM ships it as a replacement for drive SD-7741 in machine PM-317 at another customer site. The asset record stays SD-8812. A new parent relationship opens, a new software interval begins and the ownership and location relationships change.
A year later, engineering issues a bulletin for drives of this model running firmware before 6.3. The query excludes SD-8812 because its software interval shows 6.4 in the current state. It includes the earlier interval when investigating old faults. No employee has to infer this from work-order notes.
| Time | Event | Resulting record |
|---|---|---|
| 2026-01-12 | Commission PM-204 | SD-8812 component of PM-204 at Monterrey |
| 2027-07-03 | Exchange drive | Relationship closes; SD-9420 takes the position |
| 2027-07-18 | Repair and update | SD-8812 available; firmware 6.4 starts |
| 2027-09-22 | Install in PM-317 | New customer, site and parent relationships open |
| 2028-08-10 | Bulletin impact check | Current firmware excludes SD-8812; history remains searchable |
Test the model with events, not screenshots
A clean asset page can hide a weak model. Test the lifecycle. Move an asset between sites. Replace a serialized child. Backdate the event. Transfer ownership. Apply a warranty to one component. Correct a duplicate serial. Ask for the configuration at three past dates. Every result should remain explainable.
Then test the business questions. Can a parts specialist determine fit? Can service see the current location and past moves? Can engineering find every current and historical asset affected by a component revision? Can warranty show the contract clause and triggering event? Can the account team distinguish confirmed assets from inferred ones?
| Test | Pass condition |
|---|---|
| Identity collision | Duplicate serial enters review without creating a silent second asset |
| Component exchange | Old interval closes and new interval opens from one event |
| Backdated work | Event time changes historical state; recorded time preserves the audit |
| Ownership transfer | New owner gains the active role without erasing the old relationship |
| Point-in-time query | The system reconstructs site, parent, software and coverage on a chosen date |
| Source conflict | Automation stops the affected decision and shows both claims |
A practical first schema
The first release does not need a graph database or a universal industry ontology. It needs stable IDs, typed relationships, effective dates, source references and a transaction that applies events consistently. A relational model can do this well. Use join tables for identifiers, party roles, installation relationships, configuration items, coverage and source claims.
Expose a current-state view for ordinary work and retain the intervals and events underneath it. Most users need the asset now. Investigators, warranty reviewers and engineers need the history. Do not force every screen to reconstruct the ledger, and do not throw the ledger away to make the current view easy.
- asset: permanent identity, type, model, lifecycle status and creation source
- asset_identifier: identifier type, value, scope, valid interval and source
- party_role: party, role, asset or site, valid interval and authority
- site_position: site hierarchy, functional designation and requirements
- asset_relationship: two objects, relationship type, position and valid interval
- configuration_item: physical part, software or controlled document in an asset state
- asset_event: occurred time, recorded time, actor, source and state transition
- coverage: covered object, provider, beneficiary, limits and contract source
- source_claim: property or relationship, source record, observation time and confidence
How Bourne uses this model
Bourne can assemble the equipment record from ERP, PLM, CRM, field service, service documents and telemetry without asking employees to maintain another flat master by hand. It resolves known identifiers, proposes candidate matches, shows conflicts and asks the person who owns the decision to confirm uncertain relationships.
The same record then supports work. Bourne can prepare a service case, check whether a spare fits the current serial, identify a bulletin’s affected fleet, test coverage or build an upgrade proposal. When a completed job changes the physical state, Bourne prepares the dated relationship and source update for approval and writes it to the system that owns the fact.
This makes the data model operational. Shipment, commissioning, service and account work improve the record while the record makes each task faster and safer.
Build the first version around one painful decision
Choose one product family and one decision that currently wastes time or creates risk. Spare-parts fit is a strong test because it needs identity, configuration, effectivity and supersession. Warranty is another because it needs the covered object, contract and dated events. Import only the records needed for that decision, then follow the result through real work.
The pilot passes when employees can identify the physical object, see the current and prior state, trace the material facts to evidence and complete the decision without rebuilding the asset from emails. The completed work must also update the installed state. Expand to the next product family only after the identity and event rules survive the difficult cases.
Buğra Gündüz
Buğra Gündüz is the co-founder and CEO of Bourne and co-founder of HockeyStack. He built HockeyStack into an eight-figure AI business. At Bourne, he works with entrepreneurs and established companies to create AI products and services.