Service Planning or Service Documentation

Service Planning or Service Documentation?

Back in the early 2000s, I became involved in a project to address the cause of a tragic incident that occurred during “routine” maintenance. The wrong parts and wrong procedures resulted in a fire that claimed lives. The investigation determined that the cause was a degraded ability to manage the configuration and technical documentation for the fleet of assets being operated.

Today, manufacturers generate and deliver service documentation consisting of more information in more formats, in the hope that it will be what is needed for service personnel to do the job right the first time. But is the end goal service documentation or is it the ability to plan and execute service correctly? Personally, I think good service plans and accurate asset configuration knowledge drive service documentation. Let’s discuss each of these in turn.

Source of Service Information

Service providers depend heavily on service manuals (electronic or paper) to plan operational service events, but where does all that information come from? If we consider what proactive service operations require for optimal execution, we begin to understand the importance of service planning versus service documentation.

During product design, service concepts are developed using the product and component reliability models, virtual product and system modeling, physical testing, and historical performance data. This combined information helps formulate the elements of a service plan.

Service planning

In service lifecycle management, service planning starts with core elements based on the approved configuration(s) of products that will be in operation. However, the way a product is designed and the way it looks when you serve it can vary. To overcome this, planners will usually restructure the engineering bill of materials (EBOM) into a service bill of materials (SBOM) to indicate how a product will be serviced. From there, planners can use the SBOM to establish a detailed service plan using the information mentioned above.

So what goes into a service plan that helps operations plan for actual service events? In the table below are core service plan elements.

This information is associated with a component part, subsystem, or system within the configured SBOM. From the SBOM, not only can these parts and their service information be controlled and approved, but they can be linked back to the EBOM to ensure consistent design throughout the SBOM, the service plan, and operating assets.

This structured service plan allows your service work orders to be specific to the physical product as configured in the as-maintained BOM (ABOM), since this ABOM is linked to the SBOM. This approach not only removes the ambiguity of generic service information (documentation) but with associated elements of a service plan linked to the physical BOM, those plan elements when used directly by service scheduling can drive compliant service work content and execution. This connected, configured information approach ensures correct and up to date service information is always used and your assets or service technicians are not at risk like in the tragic event mentioned in the opening.

Additionally, as service plans are defined, the planner can examine procedures to reduce time wasted in non-productive activities and confirm best practices have been captured. Once completed and approved, service plans can be exported as needed to support other service systems or used with other service lifecycle management solutions such as service scheduling.

Service documentation

Now let’s get back to the topic of service documentation. Service documentation contains many components: boilerplate acknowledgments, general hazard or other warnings, parts lists, illustrations, and service procedures. Great portions of these are reusable from one document to the next thus saving authoring time and processes. You’ll also note that many of these components are product/part specific, specifically illustrations and service procedures. If you generate service documentation based on the configuration of the as-maintained BOM for an asset linked to the service BOM containing the service plan, you can end up with asset-specific configured service documentation that will reduce service errors.

Summary

As you can see starting with service planning with its key elements for the what, when, and how of service based on product knowledge, the SBOM, and asset configurations allow you to drive accurate service documentation. Of course, support of the full lifecycle BOM enables a unified strategy of product and service. Service lifecycle management within a PLM strategy achieves this full product/service vision.

For another topic on service, documentation effectiveness check out Joe Barkai’s recent blog “Who Needs Service Manuals?” For more on the topic of service, BOM see my previous blog Service Lifecycle Management with PLM.