Service Plan to Service Execution – Right Job, Done Right, First Time

By SteveOLear

I don’t change the oil in my family cars anymore. I stopped primarily because it was easier to let someone else properly dispose of the oil. Today both family cars have oil life indicators that signal it’s time for a change based on duty cycle (mileage) or quality (viscosity). My car has a simple display, “Change Engine Oil,” that comes on every 7,500 miles or when the oil is really dirty. My wife’s car, a little newer, has a display that indicates the remaining oil life as a percentage aligned to the OEM recommendation of mileage or oil health. The oil change still needs to be executed through a service event somehow but I don’t crawl under the car anymore.

Service execution is successful when service events are complete, accurate, quick, and affordable which means based on service requirements in service plans linked to product and as-maintained configurations. I suggested in Service Planning or Service Documentation that service planning is done as part of the development of the product with the service BOM. Done their product configuration can ensure accurate service documentation if generated. I’d like to continue the thread of the importance of the service plan through the simple example of service execution mentioned above, the oil change.

For me, oil changes are done either at the dealer or a generic oil change place. When not taken to the dealership, the oil indicator in her car is not reset, but it is in mine. The difference? The reset instructions in my owner’s manual are correct. The reset instructions in her owner’s manual are wrong for the year and model (the pitfalls of generic documentation). The dealership knows the proper procedure for her car and executes the complete service properly. When her car comes back from a non-dealership oil change, I look up the proper instructions on YouTube to reset the indicator, to complete the service work.

Now back to the topic of service execution driven by a service plan and accurate documentation. If service plans have all the service requirements (the service, error code, duty cycle/ frequency/condition, procedures, and warning notices) and the resource requirements (labor skills/certifications, tools, parts, and equipment), then based on the as-maintained configuration the correct work content for a service event can be generated. Of course, discrepancies or additional service requests filed against a specific asset can expand the work content of a service event generating additional service work orders. It would be for the service scheduler to optimize total service work with one or more service events to maximize asset value through availability and reliability for the customer.

With correct work content, the service execution proceeds accurately. The oil indicator light or display says it’s time to change the oil. I or my car tells the service center that an oil change is needed, a work order is generated with the proper documentation and parts request. The service scheduler takes the work order and places it on the schedule based on the availability of a service bay, skilled technician, and parts. There might be some upsell by the service organization because they note recalls, upgrades, or other services (tire rotation, timing chain service, transmission service, etc.) that might be desirable and determined by my car configuration, service history, and status. The service center will, of course, attempt to get all this work done quickly in one service visit. But when the technician(s) takes my car, they should have everything needed to correctly complete all work ordered.

Now I don’t depend on my car to generate revenue. But an airline depends on an airplane, a factory on a machine, and a utility company on a generator. Each is much more complicated than my car’s oil problem. In any of these industries, there are very straightforward service goals starting with keeping the customer happy by maintaining high availability and reliability of the asset. This goal is achieved by having as few service events, especially disruptive ones, as possible, and completing all work correctly and quickly. Hence the value of the service plan and complete knowledge of the as-maintained asset configuration and status. As products become more intelligent and connected through IoT, “live” status should be reported and capture to drive service and product improvement not just through big data analysis but intelligent calls for help from products.

Defining a well-thought-out service plan based on initial reliability analysis, product design, and configuration and improved over time with empirical data from the field allows the service organization to standardize and optimize service procedures and drive service execution for accuracy and completeness anywhere. With certain assets, a lot of preplanning of the service work and schedule is necessary to ensure the briefest possible outages or a minimum number of service events. If it takes a couple of days to spin down and cool a generator and a couple more days to spin it back up to production, you want to make the most of the downtime to complete both the required service or repair and possibly other near-term service needs to avoid outages. The same thing goes for an airplane in for depot maintenance or a service team heading to the North Sea to repair an oil rig.

Such detailed planning coming directly off the service plan and combined with the as-maintained configuration ensures that you are fully prepared to keep the customer happy through excellent service. Work orders generated from the service plan can feed to other solutions in your SLM infrastructure, such as inventory management, the supply chain, and schedule and fleet management. The service plan empowers the service operation to schedule and executes service with higher efficiency and greater accuracy- getting the right service done right the first time. For another look at service, execution check out Joe Barkai’s recent post on Field Service Excellence: Right Technician, Right Information.

Leave a Reply

This article first appeared on the Siemens Digital Industries Software blog at