Digital Thread: How the Service Bill of Materials Drives System of Record Across the Platform

“We’ve defined ERP as the system of record for our installed base”. This a phrase we hear quite often. Is it a smart choice, and what are the consequences of this choice? When you are in the business of managing the service lifecycle of an installed base, we believe you should consider an alternative approach to system of record.

This blog is part 2 in a series of three.

Limitations of ERP

ERP is often a solid choice for the system of record for many data objects. But lesser so for products, equipment and assets that have left the building. When products hit the field and start their operational lifecycle, those products become a handle for a lot of contextual usage data. Think in terms of how is the product being used, how is it being maintained, and what touch points have we had with the product?

Bill of Materials lifecycle

Let us paint a picture of the lifecycle of the Bill of Materials (BoM). In the design phase of a product, engineering will create an engineering BoM. In the build phase, manufacturing will pull the latest revision of the engineering BoM and use it as a template to manufacture a batch of x units. All those units have the same as-built. If we use a configurator in the sales process, the as-sold may differ from the as-built. So far the information we have captured is product specific.

Post-point-of-sales, when the unit leaves the building and the customer starts using the product, the unit becomes unique. Though the engineering team may have had a specific use profile in mind when designing the product, in real life, customers use the product within (or outside) a bandwidth of the product specifications. Tracking how customers maintain and operate the product thus becomes essential to keep the product running. Being in the operational lifecycle of a product we’ll refer to the BoM as as-maintained or as-operated.

Service lifecycle management (SLM), fit for purpose

If we have to name one single reason why any OEM should revisit their ERP installed base system of record paradigm, it is total product lifecycle cost.

For mission-critical assets, the lifetime Opex is a multiple of product expenditure Capex. Thus, if you want to make a valuable impact on the users/buyers of your products, you need to focus on the service lifecycle.

The SLM asset record is fit for purpose. SLM connects as-engineered, as-built, as-sold, and as-maintained. In part 1 of this series, we explained how the Service-BoM sets the standard of maintenance, underpinning the value promise of product uptime and sustenance. PLMERPCRM, and FSM all add data to the digital thread of the product. SLM, being on the receiving end, defines the data master for products in the field.

Enterprise data architect

Knowing that it takes both product and usage-specific data attributes to keep products running, we’d like to better understand why we’ve defined ERP as the system of record for our installed base. Is this a dogmatic, pragmatic, or conscious decision?

In the decision-making process for enterprise software, there are two factions. The business persona and the IT persona. Both weigh decisions along different (internal) metrics. Though it may seem obvious to abandon the ERP mantra from a business perspective, IT may have sufficient counterarguments not to do so.

This is where we can/should call on the help of the enterprise data architect. The enterprise data architect is key to any system of record conversation. What is primary, and what is secondary? How does data flow from one business area to the next? Does any function own data or is every function contributing data to an enterprise pool of data? The enterprise architect will be able to weigh the arguments and weigh the value of data beyond the individual functions in an organization.

Value of Asset Data

Knowing that the value of asset data is only getting bigger and bigger, we believe we are at an interesting point in time to create a digital thread of data. Focused on keeping the world running. Using the Service-BoM as a pivot. Using SLM as a system of record.

In part 3 of this series, we’ll focus on value using Service BoM and SLM data to drive cross and upsell. Teaser: when you exert a lot of effort in designing, building, and selling products, how much effort do you want to put into generating margin contribution off your installed base?

This article is published on Field Service Digital and PTC Blog.

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