Installed base management for OEMs

The sales order says the OEM shipped a compressor package in 2018. Service needs a different answer. Which serial number is at the customer’s Texas site? Which controller and firmware run today? Did the field team replace the original motor? Does the extended warranty cover the failed bearing? Which spare kit fits the machine after two upgrades?

That answer rarely lives in one system. ERP knows the shipment and serial. PLM knows the manufactured configuration. CRM knows the account. Field service knows the work performed. A technician has photographs. The customer has moved the equipment and changed a component. Each system can be correct about its own transaction while the OEM remains wrong about the machine now in service.

An installed base joins those records around the physical equipment. It creates a durable identity for each serviceable asset, places it in a customer and site hierarchy, records the as-maintained configuration and carries its service history, coverage, usage and commercial opportunity through the rest of its life.

Decide which physical objects deserve identity

Start with the unit a service, warranty, parts or upgrade decision must identify. A complete packaging line may need one top-level asset and serialized child machines. A pump skid may need a skid serial plus serials for the motor, drive and seal system. A replaceable commodity fastener does not need its own installed-base record.

Use serviceability, configuration risk, warranty, compliance, value and movement to decide the level. If a component can move between parent machines, carry separate warranty, receive firmware, require traceability or drive spare-parts fit, give it identity. If the OEM will only ever manage it as quantity inside a parent, a part relationship may suffice.

IFS makes a similar distinction between serial objects that can move and functional objects that represent a stable function or place. Its service object model can link an object to model, part and serial while preserving parent structure.

Separate model, part and asset

A model describes a family the customer recognizes. A part number describes something the OEM buys, makes, stocks or sells. An asset describes one physical instance at a customer or internal location. These records overlap, but they are not interchangeable.

The model can supply default skills, maintenance plans, meters and spare recommendations. The part can supply inventory, substitution and price. The asset carries serial, ownership, location, installed configuration, usage, coverage and event history. Mixing them causes changes to one customer’s machine to alter the template for every machine of that model.

IFS installed base documentation uses the model as a service template, the part as the inventory or manufacturing identity and the service object as the specific equipment under service or coverage. That is a sound boundary even when the OEM uses other software.

Create one durable asset identity

Assign an internal asset ID that survives customer renaming, site moves, ownership transfer and component replacement. Preserve the OEM serial, customer tag, registration number and prior aliases as searchable identifiers. Do not use the customer name or current location as the primary key.

Prevent duplicates at creation. Match on serial, manufacturing record, shipment, customer tag and known aliases. When two records describe the same machine, merge relationships and preserve the retired ID as an alias. Do not create another asset because a technician typed the serial with a space or a customer called the machine by a local nickname.

Build customer and site hierarchy independently

The sold-to account, asset owner, operator, bill-to party and physical site can differ. A dealer may buy the machine, a leasing company may own it and an end user may operate it. Record each role with effective dates. Do not overwrite the original sale when ownership changes.

Represent the physical site as its own hierarchy: campus, building, line, area and functional position where useful. Assets can move between positions while the location remains. This lets service plan work at a function even when the customer swaps the physical unit.

SAP defines a functional location as the place where maintenance work occurs and equipment as an individual object that can move into or out of that location. Its warranty-object model can apply coverage to equipment, functional locations, installed bases or serialized materials.

Create the initial installed state from the order

Do not wait for the first service call. Create the candidate installed base from the accepted order, manufactured serials, released BOM, software load, inspection results and shipment. Confirm the actual installation and commissioning state before marking the asset operational.

Separate as-sold, as-built, as-shipped and as-installed states. They often differ. Engineering can approve a substitution during build. Shipping can split modules. Site work can change cable lengths, instruments or software. Each state answers a valid question and explains the next one.

Represent the service structure the technician needs

The service structure may differ from the manufacturing BOM. Manufacturing needs every component and operation. Service needs replaceable units, access relationships, compatible spares, procedures and parent context. Create a service BOM or service structure linked to the released product records.

Show the whole installation when diagnosis crosses assets. A cooling failure on one machine may originate in a shared chiller. A controller can serve three modules. The technician needs the parent, children, functional position and connected systems, not an isolated serial record.

SAP Installed Base Management groups equipment, serialized materials, functional locations and documents into a multi-level installation. That structure is valuable because the service event can reference the object that failed while retaining the larger customer system around it.

Record every configuration-changing event

A service completion should update the installed state when the work changes a component, software version, setting or location. Capture removed serial, installed serial, quantity, position, date, technician, work order and reason. Preserve the earlier configuration with its effective interval.

Field replacement is not inventory consumption alone. The OEM must know which machine received the part and which part left it. Oracle Service Logistics, for example, can capture the parent asset and installed-part serial during debrief. That closes the link between the service transaction and the current asset structure.

Track warranty by object, coverage and time

Record the provider, covered object, start trigger, end date or usage limit, included work, exclusions and claim process. A machine can carry an OEM warranty while a replaced motor carries a supplier warranty and an extended service agreement covers labor. The service order should evaluate all applicable coverage.

Start dates need evidence. Shipment, installation, commissioning and customer acceptance can occur months apart. The contract determines which event starts coverage. If the event has not occurred or lacks confirmation, show the uncertainty instead of inventing a date.

Link every service event to the asset and symptom

A service case should identify the affected asset, reported symptom, operating state, failure code, work performed, parts used, labor, measurements, finding and resolution. Free text can add context, but structured links make the history useful for diagnosis and product improvement.

Distinguish the customer’s symptom from the technician’s cause and the corrective action. “Machine stopped” is a symptom. “Encoder cable shield failed at connector” is a cause. “Replaced cable and rerouted away from VFD output” is an action. Mixing them destroys failure analysis.

Connect meters and telemetry to physical context

Usage and condition data matter only when the OEM knows which asset produced them, which sensor and unit apply, and which configuration ran at the time. Record meter identity, reading time, unit, quality and source. Preserve resets and replacements.

Do not copy every telemetry point into the installed-base master. Store high-volume time series in the system designed for them and link the asset identity. Carry the latest readings, alarms, health features and derived events needed for service decisions.

Control spare-parts fit and supersession

A parts catalog says which parts fit a model in theory. The installed base says which parts fit this serial in its current configuration. Use model, serial range, installed option, component position, engineering effectivity and field modification to determine compatibility.

When a part becomes obsolete, record its approved successor, required kit, software dependency, modification instructions and interchangeability. “Superseded by” does not always mean drop-in replacement. A new drive may need a bracket, parameter file and firmware update.

Know what each enterprise system owns

Do not copy the entire asset into every system. Assign ownership by record. ERP may own material, serial inventory, shipment, warranty entitlement and financial transactions. PLM may own released product and service definitions. Field service may own work execution. CRM may own account and opportunity. The installed-base view joins them for service and commercial work.

Choose one owner for current customer, site, asset status, as-maintained structure and each identifier. Store cross-system IDs and synchronization state. If a technician updates a location offline while ERP receives an ownership transfer, the integration should detect the competing events and route a resolution.

Repair the installed base through normal work

A one-time data cleanup will decay. Design each operational event to update the installed base: shipment creates the candidate asset, commissioning confirms the site and state, service debrief records component movement, warranty review confirms coverage and an upgrade order updates configuration after installation.

Give employees a fast exception path when the record disagrees with the field. A technician should be able to report an unknown serial, missing component or wrong location with a photo and customer confirmation. Route the correction to the record owner. Do not let every user edit history directly.

Use confidence and provenance for inherited data

Older fleets may start from shipment history, spreadsheets, service notes and customer lists. Do not present every inferred asset as confirmed. Record source, extraction date, match method and confidence. Ask service and account teams to confirm records through their normal work.

A shipment line can prove that an item left the factory. It may not prove where the customer installed it or whether it still operates. A service invoice can prove work at a site but may omit serial. Keep those distinctions visible until a stronger event resolves them.

Turn the record into service and commercial action

The installed base should answer work, not sit as a database project. Service can find the right asset, procedure and part. Warranty can decide coverage. Engineering can identify affected serials for a bulletin. Sales can find aging equipment, missing contracts and upgrade candidates. Supply can forecast service parts from active configuration.

Create actions from explicit rules and evidence. A warranty ending in 90 days can trigger an account task. A drive family approaching obsolescence can produce an affected-asset list. High usage plus repeat failure can trigger an inspection. Do not send a generic campaign to every asset of the same model when configuration and operating state differ.

Worked example: a fleet of 64 compressor packages

An OEM has shipped 64 compressor packages to one energy customer across seven sites since 2014. ERP shows 64 top-level serials and 211 serviceable child serials. CRM shows one global account and nine operating entities. Field service has 386 work orders. A spreadsheet maintained by the aftermarket team lists current controllers and warranty dates.

The OEM creates durable asset IDs from manufacturing serials, then links shipment, account and site records. Commissioning reports confirm 51 current locations. Recent work orders confirm eight more. Five assets remain supported but unverified. Two serials appear at two sites and enter conflict review.

The initial as-built structures come from serial BOMs. Service debriefs replace 73 component intervals and add 18 field modifications. The spreadsheet supplies controller versions with provenance; technicians confirm them at the next visit. Warranty logic finds that four compressor packages have extended coverage tied to acceptance, while the spreadsheet had started all coverage at shipment.

The team discovers 14 packages with a drive that will lose supplier support in 16 months. Nine can take the successor drive directly. Five need a cooling and firmware kit. Bourne creates two upgrade cohorts, identifies site access windows and builds account-specific proposals. Service parts planning also removes the obsolete drive from those long-range recommendations.

Six months later, 61 of 64 assets have confirmed sites, every completed service visit updates component movement and the OEM has sold six upgrade kits. The value came from connecting the physical record to ordinary service and proposal work, not from finishing a perfect migration before anyone used it.

Measure coverage, freshness and business use

A record count does not prove installed-base quality. Measure how much active revenue and service work has confirmed identity, site and configuration. Track freshness by the event that last verified each field. Count service jobs that finish without updating component movement.

Measure outcomes too: first-time part fit, warranty decision time, repeat visit rate, affected-asset identification time, renewal coverage and upgrade conversion. The data exists to improve these decisions.

Choose software from the system boundary

IFS, SAP, Oracle and other ERP/EAM suites fit companies that want the installed base close to service orders, serial inventory, maintenance and entitlement. PLM fits companies whose service structure and product change need deep engineering control. CRM and field-service products fit customer case, dispatch and commercial work. Specialist installed-base products fit OEMs that need fleet intelligence across a fragmented stack.

Bourne fits when the records already exist across those products but employees still reconstruct the equipment before each decision. It can assemble the asset view, ask for missing evidence, prepare service or commercial action and return approved updates to the systems that own them.

Do not buy a second asset master without assigning ownership. The implementation should name which product owns asset ID, site, as-maintained structure, warranty, service event, telemetry and commercial action. The combined view can cross systems while each final record retains one owner.

How Bourne works with the installed base

Bourne links the accepted order, manufactured serials, product records, shipments, commissioning, service history, parts movement, warranty, contracts and telemetry around each asset. It shows the customer, site, hierarchy, current configuration and confidence behind each material field.

The application can prepare a service case, validate a spare, find a bulletin’s affected serials, identify a coverage gap or build an upgrade cohort. Your people approve uncertain matches, engineering fit and customer action. Bourne writes confirmed changes back to ERP, PLM, CRM and field-service systems.

The asset record improves through the work. A technician confirms location. A parts order resolves configuration. An account review confirms ownership. A completed upgrade changes the as-maintained structure. The installed base becomes more useful because the team uses it, and using it makes the record better.

Pilot one product family and one service decision

Choose a product family with meaningful serial history, active service demand and a clear decision such as spare-parts fit, warranty or upgrade targeting. Start with the assets that generated work in the last two years. Link shipment, product and service records, then verify the current state through recent evidence.

Test five difficult cases: ownership transfer, site move, component exchange, field modification and unknown serial. Make the pilot produce an operational result. Quote the correct spare, decide coverage, identify an affected fleet or create a qualified upgrade proposal.

The pilot passes when the decision uses less manual search, the result traces to current asset evidence and the completed work updates the installed state. Then expand by product family and site while the same identity, event and ownership rules still hold.

Arda Bulut

Arda Bulut is the co-founder and CTO of Bourne and HockeyStack. He leads engineering at Bourne, building the platform people use to create AI products, agents and automations.