Installed base software for OEMs: what to compare

An industrial OEM can buy an ERP service module, a PLM service-lifecycle product, field-service software, an installed-base intelligence platform or an AI application that works across the existing stack. All five may show an asset page. They differ in what owns the asset, how the configuration changes, which transaction updates it and whether the product can turn the record into service and commercial work.

That distinction decides the purchase. A global manufacturer running IFS across service, inventory, contracts and finance has a different problem from a Teamcenter customer that cannot connect the engineering BOM to the machine in the field. A mid-market machinery OEM replacing spreadsheets has a different problem from a company with clean records spread across SAP, Salesforce and a field-service product.

This comparison uses current vendor documentation and evaluates the products against the work an OEM must complete: create the asset from order and manufacturing data, preserve the as-maintained configuration, run service and coverage, support customers and partners, find aftermarket opportunities and update the source systems after each action.

The shortlist

Start with the product whose center matches your main constraint. The summary below states the strongest fit. The detailed sections explain the boundary and the work you still need around it.

Do not buy “an asset record”

Every serious product can store a serial number, customer, site and service history. That is the entry price. The hard questions start when the physical machine no longer matches the shipment. A component moves. A technician loads new firmware. A dealer performs work outside the OEM system. A contract covers the line but excludes one retrofit. Engineering issues a bulletin against a component revision.

Ask each vendor to run those changes on one real machine. Show the accepted order, manufactured serial structure, current field configuration, applicable coverage and service history. Replace a component in the demo. Then ask the system to identify every affected asset, quote the correct spare and write the result back to ERP, PLM and service records.

A polished asset page proves presentation. The change proves the model and workflow.

Use one evaluation case for every vendor

Give every vendor the same case so differences remain visible. Use a product with serialized children, software, a customer-specific modification, a service contract and at least one field replacement. Include conflicting source data. A clean demo dataset will hide the integration and governance work that consumes the implementation.

1. Bourne: cross-system AI for asset work

Bourne is the best fit when the OEM already has ERP, PLM, CRM and field-service systems but people still reconstruct the equipment before each decision. It reads the order, serial history, product data, service record, contract, customer correspondence and telemetry, then builds the case for the work at hand.

For a spare-parts request, Bourne can identify the customer and target serial, assemble the current configuration, apply part effectivity and supersession, ask for missing evidence and prepare the quote. For a bulletin, it can trace the affected component and revision into the fielded fleet, group assets by current state and create review tasks. For an upgrade campaign, it can find eligible assets, exclude unsupported assumptions and prepare account-specific proposals.

The platform leaves governed records in the systems that own them. ERP still owns item, inventory, order and invoice. PLM still owns released product and service definition. CRM still owns the account and opportunity. Field service still owns execution. Bourne carries the evidence and decision across those boundaries, then writes approved results back.

Choose Bourne when cross-system work, unstructured documents and human judgment cause the delay. Choose a transaction suite first when the company lacks basic service orders, contracts, inventory or asset masters. Bourne can coordinate those systems; it does not need to replace them.

2. IFS Cloud: the strongest integrated service backbone

IFS Installed Base Management models families, subfamilies, models, parts and service objects. A model can supply warranty, meter, spare-parts and skill defaults. A service object represents the specific equipment at a customer and can connect to both model and part. The product supports inherited and instantiated service attributes, which matters when a fleet needs common policy without erasing asset-specific state.

The service object goes deep into execution. IFS documents parties, skills, test points, parameters, recurring service, service history, costs, contracts, spares and resource availability against the object. Its broader suite adds service requests, work tasks, scheduling, inventory, contracts, depot repair, finance and project or manufacturing context.

IFS is the clearest choice in this list for an OEM that wants one suite to own a large share of the service transaction chain. It also fits companies already running IFS ERP or field service, because the installed base can participate directly in the surrounding processes.

Test the implementation boundary. Decide whether IFS will become the master for current physical configuration or receive it from PLM. Check how dealer work enters the service history, how offline technicians record component movement and how model inheritance behaves after a service rule changes. A broad suite reduces product boundaries but increases design and migration scope.

3. SAP: best when SAP already runs the asset and supply chain

SAP gives manufacturers several asset constructs. Equipment represents an individual maintained object. A functional location represents a stable place or function. An installed base can hold a multi-level structure whose components reference equipment, material, functional locations, documents or another installed base. Service, maintenance, warranty and field work build around those records.

SAP’s installed-base documentation explicitly supports machines, devices and software at customer sites and lets business transactions refer to the whole installation or an individual component. SAP also publishes the mapping between S/4HANA equipment, functional locations, service orders and SAP Field Service and Asset Management.

SAP fits an OEM that already governs material, serial, customer, order, inventory and service transactions in SAP. The value comes from using the same enterprise backbone, not from buying a standalone installed-base screen.

Map the exact product set before selection. Ask which SAP application owns equipment, current installation, service contract, field work, mobile execution and customer self-service in your target architecture. Test the integrations with the editions you will deploy. “SAP supports it” is not the same as one configured process in one product.

4. Oracle Fusion: best for service tied to Oracle supply-chain execution

Oracle Fusion installed-base assets connect naturally to Oracle Supply Chain and Manufacturing. The strongest story appears when service needs parts sourcing, inventory, returns, costing, billing and maintenance. Oracle Service Logistics sends parts, labor and expense debriefs back for billing, costing, inventory updates and installed-base configuration updates.

Oracle B2B Service can use the installed-base asset on service requests and work orders, then pass that ID to Field Service or Service Logistics. The documentation also states a boundary: customers choose between installed-base assets and the default asset object globally, and the installed-base asset has limits in CX Sales and extensibility. That choice deserves architecture review before migration.

Oracle fits OEMs whose service operations depend on Oracle product, inventory, order, pricing and finance. A technician can request a part from the supply chain, record the installed and removed items, create charges and update the asset configuration through one vendor stack.

Test the exact CX and SCM flow. Show how an opportunity or aftermarket proposal finds the installed asset, how service contracts apply, how field debrief changes the parent configuration and which subscriptions and integration recipes the complete process requires.

5. Siemens Teamcenter SLM: best for configuration-heavy products

Teamcenter Service Lifecycle Management starts from engineering and service definition. It links the engineering BOM to a service BOM and the physical configuration of each fielded asset. That suits aerospace, energy, transportation, industrial machinery and other complex products where the wrong component, software state or procedure creates serious risk.

Siemens describes Teamcenter SLM across service BOM, physical asset configuration, status, service history and service planning. Its physical asset configuration guidance covers mechanical, electrical, software and document components and the changes made during operational use.

Teamcenter is the strongest choice here when service engineering owns the hard problem. It can preserve the link from design intent through service structure to the as-maintained asset and feed accurate information to execution products. Siemens documents integrations with IBM Maximo and Salesforce, which also makes the boundary clear: many customers will still execute field work, contracts or customer interactions elsewhere.

Test whether field events update the physical structure with enough speed and discipline. Ask a technician or service system to replace a serialized component, then show the engineering feedback, applicable procedure and affected-fleet query. Confirm what Teamcenter owns and what the FSM or EAM owns.

6. ServiceMax: best for asset-centric field service

ServiceMax centers the installed product in field-service execution. It tracks asset hierarchies, timelines, technical attributes, work, returns, depot repair, maintenance plans, contracts, warranties and entitlement. Technicians can use mobile and offline workflows, while service leaders can analyze asset health, attach rate, cost to serve and contract performance.

Asset 360 documentation describes multi-level asset hierarchy, activity timeline, IoT attributes, return management, depot repair, maintenance templates, entitlement and packaged service processes. PTC positions Asset 360 as a native extension to Salesforce Field Service, with as-maintained asset data and service coverage on the Salesforce platform.

Choose ServiceMax when the main goal is to run service around equipment and Salesforce already owns the customer context. It offers deeper asset-centric service operations than a basic CRM asset object.

Test the engineering and ERP boundaries. Ask how the as-built structure arrives, how engineering effectivity reaches parts selection, how service debrief updates PLM, and how inventory and billing post to ERP. Asset 360 can orchestrate strong field processes, but it does not turn Salesforce into the engineering or manufacturing master.

7. Salesforce Field Service: best for a configurable CRM-native asset layer

Salesforce models a purchased or installed product as an Asset. The asset can link to product, account, contact, location, maintenance plan, work order, entitlement and service contract. Parent and child records provide hierarchy, and asset relationships can record replacement.

Salesforce’s own asset walkthrough shows those relationships directly. That makes Salesforce Field Service a credible choice when the company wants a configurable asset layer close to cases, customers, contracts, scheduling and mobile work.

Choose the standard Salesforce route when the installed product is structurally simple or the company will design the missing OEM-specific behavior on the platform. Choose ServiceMax when the service organization needs a packaged asset-centric model, entitlement, depot, return and service process depth.

During the demo, ignore the easy account-to-asset screen. Test serialized component movement, point-in-time configuration, engineering applicability, dealer work and the round trip to ERP and PLM. Those tests show how much custom design the standard asset object will require.

8. Entytle: best for installed-base intelligence and aftermarket coverage

Entytle targets equipment manufacturers whose installed-base data sits across ERP, CRM, field service and spreadsheets. It unifies and cleans those records, then supports aftermarket analysis and selling. That focus differs from a transaction suite: the product starts with fragmented fleet data and the commercial value hidden inside it.

Entytle describes its platform as purpose-built installed-base intelligence for equipment manufacturers. The public product material highlights CRM, ERP and FSM data organization, cleaning, account and asset visibility, competitor equipment, channel partners, underserved customers, churn and upsell potential.

Choose Entytle when the aftermarket team cannot see the fleet, coverage or wallet opportunity and replacing the enterprise systems is out of scope. It is especially relevant for OEMs with decades of shipments, acquisitions, channel sales and dirty historical data.

Test operational closure. After Entytle finds an opportunity or corrects an asset, ask how the approved change returns to CRM, ERP and service. Then close a field job and show how quickly that event refreshes the installed record. Also test configuration depth if parts fit or engineering bulletins depend on serialized child state.

9. Makula: best for machinery OEMs replacing spreadsheets with a focused service stack

Makula combines an equipment database with service history, documents, preventive maintenance, customer and site structure, field service and customer portal features. The product targets machinery manufacturers and distributors, which gives it a tighter starting model than a generic CRM or EAM.

Makula’s installed-base product page shows asset lists and maps, machine-level documents, service history, preventive plans, customer-site structure and aftermarket opportunity. Its buying material also emphasizes distributor access, QR or NFC entry, customer portals and historical-data import.

Choose Makula when a machinery OEM needs a modern installed base and service experience without implementing a large enterprise suite. The customer portal and machine-centric documents can create visible value early for a team moving from spreadsheets, folders and ERP exports.

Test the upper bound. Use the most complex product structure, software configuration, contract, dealer model and global data volume you expect. Ask how engineering changes and part effectivity reach the machine, how transactions post to ERP, how access works across distributors and how the system preserves historical configurations.

The products are not interchangeable

A procurement sheet with “asset hierarchy,” “service history,” “contracts” and “AI” will mark several products yes. It will not show the architectural difference. The product that owns service execution has a different job from the product that owns engineering configuration or the product that unifies data for aftermarket selling.

Compare the asset model before the dashboard

Ask the vendor to draw the objects and relationships used for your machine. You need product model, part, serial asset, site, functional position, parent-child configuration, software, document applicability, customer roles, coverage and event history. Ask which relationships carry effective dates and which screens only show current state.

Then test identity. Can the product store several serial scopes, customer tags, device IDs and legacy keys without creating duplicate assets? Can it merge two records while preserving source references? Can one asset move across customer, site, parent and ownership relationships without losing history?

Compare how data becomes current

Installed-base software fails when it launches as a clean repository and then waits for employees to maintain it. Ask which ordinary transactions create and update the record. Shipment should create a candidate asset. Commissioning should confirm the site and configuration. Service should record component movement. Customer and dealer portals should collect changes with review.

Measure the closed loop. When a technician replaces a motor, does the mobile debrief capture removed and installed serials? Does inventory move? Does the current configuration update? Does PLM receive the field event? Does a future spare-parts quote use the new motor? A vendor should show the whole path.

Compare service, commercial and engineering work separately

Do not award one overall workflow score. Service execution, aftermarket selling and engineering control use the installed base differently. A product can excel at dispatch and remain weak at affected-serial analysis. Another can find upgrade whitespace but not run a depot exchange.

Compare integration by ownership and event

A connector logo says very little. Ask which objects and events move in each direction. “SAP integration” could mean nightly customer and equipment import. It could also mean real-time serial creation, inventory movement, service order, parts issue, debrief, billing and error recovery. Those are different implementations.

Build an ownership matrix before the purchase. Name the master for part, serial, current site, physical configuration, coverage, work order, contract, device mapping and opportunity. For each event, name the system that starts it, the products that must react and the reconciliation rule when one update fails.

Compare implementation work honestly

License price does not predict implementation effort. A suite can already contain every target process and still require large migrations, master-data decisions and operating change. A focused product can launch faster and still require custom integration or leave adjacent work elsewhere.

Price the first business outcome, not a generic phase one. For example: “For one compressor family, identify active assets, validate spare fit and create a quote from the current configuration.” Include data extraction, cleanup, mapping, workflow, integration, permissions, training and the work needed to update the record after the quote or service event.

A scorecard that exposes the real fit

Weight the scorecard from the decisions and architecture. An OEM with complex serialized products may give configuration and engineering 25 percent. A service-led distributor may weight mobile execution and portal higher. A company with a fragmented stack may put integration, provenance and workflow above native transaction breadth.

Score the demonstrated case, not the sales answer. Give full credit only when the product completes the step on your sample data and the vendor identifies the owning module, integration and human review.

Our recommendation by situation

If you run IFS and want one service backbone, start with IFS. If SAP or Oracle already owns the product, serial, inventory and service transaction chain, test the native stack before adding another master. If engineering configuration determines service safety and part fit, Teamcenter SLM deserves the first evaluation.

If field service, entitlement and mobile execution cause the pain, evaluate ServiceMax. Use standard Salesforce Field Service when the asset model is simpler and your team accepts platform configuration. If the immediate problem is dirty fleet data and missed aftermarket coverage, evaluate Entytle. If a machinery OEM needs an installed base, portal and service operation without a large suite program, evaluate Makula.

If the systems already exist and employees still assemble evidence, make judgments and rekey updates between them, Bourne is the best fit. It can turn the existing stack into working service and commercial applications without moving every master record into a new suite.

Run a paid pilot on one product family

Select one product family with live service demand and visible aftermarket value. Give each finalist 50 to 200 assets, the source records, a real component exchange and one revenue action. The vendor should build the working flow, not a slide deck.

Measure identity resolution, confirmed current configuration, time to answer a part or coverage question, manual touches, source-system updates and the quality of the resulting service or commercial action. Include the exceptions: duplicate serial, site move, dealer work, field modification and missing commissioning record.

Choose the product that completes the target work with the clearest system ownership and the least unsupported judgment. A long feature list cannot compensate for a broken record or an unfinished loop.

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.