Find the relevant parts.
Configuration-aware information helps a team identify the service items that belong with the product.
Service Process ManagementService in context.
Service in context.
Ready for the field.
Connect the service view of a product with the definition behind it. Bring parts, applicability and instructions into a working relationship before information reaches the field.
Explore the service example
Make service information product-centricA product definition.
A product definition.
A service-ready view.
Service process management in PLM relates service information to the products and components it supports. Engineering information can be reused in service structures, parts information and technical content, with configuration and change context kept in view.
- Product reference
- The engineering definition provides the upstream context.
- Service structure
- The service BOM organizes serviceable items, replacements and kits.
- Delivered information
- Parts lists and instructions present the relevant information for use.
Start by separating three questions. What can be serviced? Which product does it apply to? What information must reach the person doing the work?
Evaluate the handoff, not just the documentHelp the technician.
Help the technician.
Prepare the information.
Correct service and parts information supports technician effectiveness. Define a practical improvement with the team that prepares, releases and uses it.
Prepare content earlier.
Engineering and service can review related information while the product definition is developing.
See the change impact.
Connected definitions help service stakeholders examine the implications of engineering changes.
An illustrative service-planning exampleOne assembly.
One assembly.
Three service questions.
Use a valve assembly to distinguish structure, applicability and change review. These are planning questions for an evaluation; the example does not prescribe a repair procedure.
Example reference: valve assembly · service planning
Structure
Organize around the service task.
A service BOM can group serviceable parts and kits differently from the design or manufacturing structure while retaining links to upstream definitions.
View structure planning details
- Engineering reference
- Valve assembly, housing, seals and fasteners.
- Service view to review
- A seal kit and the assembly it supports.
- Decision to record
- Which items are replaced together, and which are individually serviceable?
Applicability
Identify the product being supported.
Service information needs configuration and applicability context. A service BOM can account for variants, valid replacements and the product as maintained.
View applicability planning details
- Product context to bring
- The assembly variant and relevant asset or serial reference.
- Service view to review
- The kit and instructions proposed for that configuration.
- Decision to record
- What evidence confirms that this information applies to this product?
Change review
Carry the revision into service review.
Associations to engineering make changes visible to service stakeholders. Review the service impact rather than assuming every revised design is an approved field replacement.
View change review planning details
- Engineering event
- A revised seal specification enters change review.
- Service view to review
- The related kit, parts information and existing instructions.
- Decision to record
- What changes, where does it apply, and who approves the service update?
The appropriate structure, applicability rules and change workflow depend on your product, operating process and configured applications.
Connect the definition to its deliveryKeep each role clear.
Keep each role clear.
Connect the service output.
Product structures, authored content and visual guidance do different work. Plan their relationship around an identified service deliverable.
Govern product and service context.
Windchill provides a PLM foundation for service structures and their engineering relationships.
Author and publish the information.
Arbortext supports structured technical content and its delivery, including service documentation.
Make the task visible.
CAD-derived illustrations and supported 3D or AR delivery can provide visual service context.
Language delivery, access permissions, enterprise interfaces and connected-asset data each need their own scope. Confirm modules, entitlements, releases and configuration with the proposed environment.
A focused first conversationBring one service event.
Bring one service event.
Agree what to prove.
A small, representative example is more useful than a broad feature checklist. Bring the people who own both the product definition and the service information.
Choose the event.
Select a real assembly, replacement or service-information change. Bring the current parts view and the information used in the field.
Name the boundary.
Identify product variants, delivery languages, access groups and system handoffs that affect this example. Record the assumptions that still need answers.
Define the review.
Agree who checks the structure, applicability and published output. Choose an observable acceptance question and a person responsible for it.
Apply the discipline to a real product situationProducts in service.
Products in service.
Information that fits the task.
Service information must make sense for the product being supported. These situations focus on applicable structures and guidance rather than scheduling or dispatching field work.
Electronics & High-Tech
A service instruction may depend on a particular board or enclosure version. Establish the applicability reference before preparing the information for the receiving team.
Which product version is this service information intended to address?
Aerospace & Defense
A supported assembly can remain in use through several engineering revisions. Relate the service view to the relevant configuration and retained change context.
Can the team identify the service information applicable to this assembly?
Industrials
A machine’s service needs may vary with its installed options. Prepare the service structure and supporting guidance around that product context.
Which option changes the parts or instructions the service team needs?
Questions before the first service viewService questions.
Service questions.
Prepare the applicable information.
Use these distinctions to prepare a focused discussion.
Is a service BOM the same as an engineering BOM?
No. The engineering BOM represents the designed product; the service BOM organizes information for support, maintenance and service. Their relationship allows service stakeholders to review upstream changes in context.
How is a service BOM different from a parts list?
The service BOM provides structured service context. A parts list is a consumable view of selected items for a catalogue, illustration or service document. Agree how the list is derived and maintained.
Does this replace field service scheduling or dispatch?
This guide focuses on product-related service information and its preparation. Identify the execution systems that need that information, then scope the handoff rather than assuming a scheduling or dispatch replacement.
Are all publishing, AR and integration options included?
Confirm the selected applications, modules, licensing and configuration for each intended output. A useful evaluation names a specific deliverable and verifies the complete route from source information to the intended audience.
Your next service-information decisionStart with the product.
Start with the product.
Prepare the service view.
Bring a parts question, a configuration or a service-information change.
TriStar can help define the records, applications and handoffs worth evaluating.