“Yes, it’s really happening!”
That was my feeling when a ServiceMax customer contacted me to learn about 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 made this ask even more special was that it was an engineer who wanted to know what service needs to deliver value.
Most of us will have plenty of examples where engineering asks technicians to record all kinds 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 engineers want to learn about 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 —
- Technicians will get a return on their administrative effort when they see that it results in easier-to-maintain products.
- 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.
The concept of design-for-service is not new. Still many organizations only apply design-for-manufacturing. The latter concept drives for cost optimization 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 optimizes both the manufacturing and 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 dialing it down into a single metric, have a look at your Attach Rates. Your attach rate is the percentage of your installed base that has an associated service contract with your organization. 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-monetization. To reap the benefits post point of sales, you need to have or get your customer ‘attached.’
Getting ‘attached’ customers might be easier when you sell your product via your own direct sales channel versus units sold via your indirect channel, dealers, and resellers. That all changes when engineering starts including concepts like ‘digital activation’ of the product.
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:
- What components from the BOM are serviceable?
- 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 defective unit repaired or scrapped at a depot. This model may be a fit for some products but the larger, more expensive, and more 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:
- FRU: Field Replaceable Unit – the repair/replacement of the component requires specialized skills of a technician
- CRU: Customer Replaceable Unit – the repair/replacement of the component can be done by any customer (no explicit skills required)
- 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
The forward-looking engineer I spoke with about design-for-service definitely understood the consequences of engineering choices for service delivery and ultimately the impact on 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.
In the next blog, I’ll elaborate on what is blocking us from designing for service.