Tag: #sparepartslist

Using Engineering Information to Achieve a More Efficient Service Delivery

In my previous blog, I wrote about the blindfold-challenge; sending a service technician into the field with impaired visibility on an installed product, scarce access to knowledge, and poor spare parts support. The challenge hit a nerve with many based on our numerous responses. This challenge proved that getting the job done is more than having a customer service department and a sophisticated scheduling tool. You need insights into the installed product such as how it was engineered, how it was installed, and how it is maintained and used.

In this blog, I will go over using engineering information such as asset-centricity, asset lifecycle, and real-life information for efficient service delivery.

Asset Centricity

Can you imagine how frustrating it is for a technician, to be sent on a job, showing up and feeling the pressure to perform a miracle in the absence of essential product information? This is the reality of the traditional reactive-break-fix model. Not only does this model affect the technician, but it also aggravates customers, service managers, and CFOs.

Customers expect their products to work, and if they don’t, they insist on an instant and first-time fix. Service managers care about utilization and cost, only to get inefficiency caused by technicians scrouging for information and parts. CFOs want predictable earnings, only to get margin contribution at a risk due to unplanned service costs.

The alternative to the above blockers is embracing the concept of asset centricity. Instead of hopping from one isolated reactive incident to the next, we want to position the installed product at the core of the service delivery model. With asset centricity, we collect and connect the data from all the interactions we have with the product over its lifecycle. As a result, we can deliver proactive, predictive, and prescriptive services. Instead of fixing what breaks, we’ll know what works.

Wider perspective

With an asset centric approach, the technician will have a lifecycle view of a product. Meaning, having visibility of all historical and upcoming service events for those products. These insights put the current job in a wider perspective. The bigger picture allows the technician to make better decisions and deliver service faster, better, and cheaper. This will allow the technician to know what was installed and how the product is being maintained and used. They will also know what engineering changes and upgrades are available for that product.

Having a wider perspective on the As-Installed and As-Maintained is already a tremendous help to the technician, still an important piece of information is missing; the plan, the reference.

When the product was designed, the engineers had a specific use case in mind. Based on that use case, the maintenance engineering function defines the service-BoM, the spare parts list, maintenance intervals, and a whole array of reference documents. This maintenance engineering data will enable the service delivery organization to plan the work and get the job done. When putting this information in the hands of the technician, the technician would both be informed and empowered for success, removing the metaphorical blindfold.

A visual representation of the function of maintenance engineering

Plan versus Actual Data

When a product is ‘in the field’ it generates data on how it performs and what maintenance interventions it incurs. This is called “actual” data. The reference data from maintenance engineering serves as “plan” data. When you set up your service delivery organization to combine both sets of data, you have created a powerful tool to manage the service lifecycle of your installed base. At PTC we call this service lifecycle management (SLM).

“Plan” data will help you to prepare, be effective, and be efficient. When the actual data equals plan data, you’re on course. When they don’t equal each other, you trigger a mitigating action. There are a few reasons this may occur. It could be the customers are using the product differently than the intended use case or not all prescribed maintenance procedures were followed. It also could be the engineers had a different perception of real-life data. Whatever the cause, managing the data is at the core of successful service lifecycle management.

Efficient service delivery

Let’s give some examples of successful service lifecycle management through the lens of today’s three service delivery challenges.

  • Technician shortage: Almost every service organization is in search of technicians. Getting the job done is generally treated as a capacity and utilization problem. However, when organizations remove the blindfold and empower technicians it not only leads to achieving efficiency but also creates a more fulfilling job leading to more applicants.
  • Identifying the right part: When we ask technicians about their main pains, the identification of spare parts is in the top 3. In selecting a field service management (FSM) tool – optimizing for the labor component –  is often the primary focus, but we fail to realize that parts cost is 40-60% of service cost. If you have a better record of the installed and maintained bill-of-material, your identification process would be more effective leading to a faster, better, and more efficient fix.
  • Knowing what must be done: Modern-day products are getting more and more complex. Good to know that engineering has defined instructions, dos, and don’ts to sustain the outcome of a product. When we use this data as a reference when we install and maintain an instance of a product, we can provide the technician with contextual information needed to perform the tasks without being blindfolded.

If you would like to hear more context and interact with experts from PTC, please join us in person at the High Tech Campus in Eindhoven on March 15th or tune in to the PTC Talks on April 12th.

This article is published on Field Service Digital.

Back to the Future with Design-for-Service

“Yes, it’s really happening!”. That was my feeling when a customer of ServiceMax contacted me to enlighten them on the Design-for-Service concept. Six years ago, they started their service transformation journey to get Visibility and Control. Now they are moving the needle towards Excellence and Growth. What makes this ask even more ‘special’, is that it is the engineering department that wants to know what service needs to deliver value.

Black swan

Most of us will have plenty of examples where engineering asks technicians to record all kind of diagnostics, reason and fault codes during the service execution. What happens with that data? Will the technician feel taken seriously when servicing yet another piece of equipment that is engineered for manufacturing?

Thus, you can imagine my positive surprise when engineering wants to ‘learn’ what service needs and what modern service execution tools are capable of. It is a true win-win when both service and engineering are seeking the joint benefit of their siloed effort. 

  1. Technicians will get a return on their administrative effort when they see that it results in easier-to-maintain products.
  2. Engineering will get the justification to fund their design-for-service effort when they see that service can improve the margin and drive new revenue streams.

Attach Rates

The concept of design-for-service is not new. Still many organisations only apply design-for-manufacturing. The latter concept drives for cost optimisation in the manufacturing process of a product at the expense of a potential higher maintenance cost over the life cycle of the product. Design-for-service optimises both the manufacturing and the maintenance aspects of a product. Yes, I hear you. What about TCO, total cost of ownership? TCO is great, but TCO only works when capital expenditures (Capex) and operating expenses (Opex) are evaluated by a single entity.

Cutting a few corners and dialling it down into a single metric, have a look at your Attach Rates. You can imagine that when engineering puts more effort/ cost into the design of the product, the selling price of the product goes up. Balancing the effort equation, you have the maintenance cost going down due to better quality and more efficient maintenance delivery. On top of that, the engineering effort may also result in the creation of new types of service offerings like availability services and data-monetisation. To reap the benefits post point of sales, you need to have or get your customer ‘attached’.

Attach Rate: the percentage of your installed base that has an associated service contract with your organisation

Getting ‘attached’ customers might be easier when you sell your product via your own direct sales channel versus units sold via your indirect channel, read dealers and resellers. That all changes when engineering starts including concepts like ‘digital activation’ of the product.

Serviceability

When engineering defines the Product, the result is captured in a BOM (Bill of Material). So far, nothing new, this is design-for-manufacturing 101. When we start designing-for-service, we need to make a number of explicit decisions. Amongst those I’m highlighting two of them:

  1. What components from the BOM are serviceable?
  2. What service delivery model is applicable for that component?

First, is the product serviceable at all? If it remains a single unit, you have made the implicit choice to exchange the whole unit with the option to have the defect unit repaired or scrapped at a depot. This model may be a fit for some products but the larger, expensive and critical the product, the more you’ll need to ‘open the box’.

Second, in the BOM you’ll have to identify those components that are serviceable. For each component in the Service-BOM or SPL (Spare Parts List) you’ll have to classify the part.

  1. FRU: Field Replaceable Unit – the repair/ replace of the component requires specialised skills of a technician
  2. CRU: Customer Replaceable Unit – the repair/ replace of the component can be done by any customer (no explicit skills required)
  3. DRU: Depot Repairable Unit – the repair cannot be done in the field, but requires the asset to come to a depot where dedicated skills, tooling and components are available

Old-school textbook?

I’ve come to learn the above two service design considerations when I stumbled into my first service job at IBM in 1993. Though I did not grasp the full impact at first, the more I talk to today’s customers, the more I am convinced we need to re-establish the handshake with engineering to deliver above and beyond the service value promise. 

Handshake

In my session with this customer, I had conversation with a very adept, eager and forward-looking engineer. He understood the consequences of engineering choices for the service delivery … and ultimately the impact to cost, revenue and customer expectation.

Next, he wanted to know how service delivery constraints and possibilities would impact his engineering process. It was clear to him that state-of-the-art service execution tooling, with a high degree of asset centricity would enable him to create a positive ROI for his design-for-service efforts.

This article is published in ServiceMax Field Service Digital on December 10th, 2020