Digital Thread: Closing the Loop

For more than 25 years I’ve worked in the after-sales domain. Hardly ever I came across the words Digital Thread. That changed when PTC acquired ServiceMax a couple of months ago. I wish I had come across the Digital Thread concept a lot sooner. I’ve come to learn it as a powerful paradigm and being very useful in creating momentum for digital transformation. I get even more excited when I tie the ends of the thread and create an infinity loop.

What’s so compelling?

Having been a service executive for 25 year I’m rather practical and down-to-earth. I like to talk about service excellence, but my actions are more around service basics. When I hear a phrase like “data is the new oil”, I’m sceptical at first, immediately followed by curiosity.

I’d like to illustrate this through a research we commissioned about the rise of “Asset and Service Data Gravity“. Though friend and foe agree on the value of data, siloed organisational design and behaviour inhibits the flow of information. Since the publication of the report in 2018, I’ve seen and heard many more stories about the value of data, but I’ve always missed the handle, the story to break the siloes.

What is the ‘binding entity’ across all the business functions of an organisation? Yes, the product they sell! Some people have the idea, others design the product, next you produce it, then you sell it. Once the product goes into the ‘field’, you’ll help your customers install, operate, sustain and decommission the product. The common demeanor is the product lifecycle. 

In each phase of the lifecycle the product creates data. Instead of each organisational function creating its own siloed representation of the product, you can picture a ‘thread’ where each station passes the baton onto the next. That is a compeling message for me.

Design-for-Service

One of my favourite activities in my current job is that I get to do frequent ride alongs. I ‘staple’ myself to a service request and observe each step in the process. The eye-opening part in the ride along is the ‘field’ piece. I mean the part where either the customer, technician or depot repair operator is in front of the product, tasked to fix it.

Sometimes it appears like we ask customers, technicians and operators to perform service activities ‘blindfolded’. Some examples:

  • The engineering of the product is optimised for manufacturing but not for service.
  • The service and operating manuals are available as reference documents, but not as actionable bite-sized instructions contextual to the job at hand.
  • There is a spare parts catalogue, but finding the right part is like finding Wally. Especially when the product is a configure-to-order product.

All these bullets make it harder to service products. More effort. More cost. Less efficiency. Less margin. Lower customer experience.

With Digital Thread we can picture an alternative future. Engineering designs a product with an intended use case in mind. Maintenance engineering ‘translates’ the product design and use case into a recommended preventive maintenance scheme, spare parts kit and component MTBF. Wouldn’t it be great if all that knowledge ‘flows’ into the after-sales and service delivery function? On the same platform?

Closing the loop

Now we have a linear thread starting with the definition of a product all the way up to sustaining and augementing the product, what would happen if we close the loop? Why is that important and who benefits?

Let me tell you a true story when I managed a field service organisation. The engineering department asked me to collect 25+ data points during the debrief of every service activity. Knowing that my technicians had not signed up for the job to do admin, I needed a lever to steer the conversation.

The good news, engineering recognised the value of data once the product was in the ‘field’. The bad, the cost of collecting the data was in after-sales/ service. To solve this dilemma, I played a game. 

25 Data points equals 15 minutes admin time. Multiplied by volume. Multiplied by fully burdened cost. “Engineering, the cost of your data request is 581k per annum”. Can you guess the response? Isn’t this internal money? Endgame, engineering reviewed the list of 25+, settled on 5 questions that had an impact on value creation. Engineering funded service to collect the data. Technicians understood the reasoning of the 5 extra questions. Technicians got extra time (and pay) for retrieving the additional data points.

In all, we closed the loop, created value, balanced cost/ effort, got lasting funding and mitigated adoption. We all won.

There is more

Once engineering receives relevant and quality feedback on the performance of products in the field, you can setup a ‘plan versus actual’ process. In designing revision 1, engineering had a plan. Now the product is in the field, they receive actual. The comparison of ‘plan versus actual’ is useful in designing revision 2 of the product. This will benefit both the sale of new products as well as allow the service function to target the existing installed base with engineering and upgrade offerings.

Knowing that modern products are getting more complex and have an ever increasing digital component, establishing a closed PLM-SLM loop is critical to a sustainable and profitable business model.

Let me end with a personal note. Throughout my career it was fashionable to say “customer first”. Being in service, I deliberately voiced a counter message: “design your business processes along the axis of the product and service lifecycle”. Hence you can see why I am so enthusiastic about the Digital Thread concept and the infinity loop. For me it is a game changer.

I have no doubt why organisational siloes should, even must, work together. When you plot each organisational function on the digital thread and infinity loop, you have a simple, powerful and reinforcing visualisation. The graphic emphasises both the organisational dependencies and value amplification.

No surprise, I will repeat this message infinite times .

Digital Thread: How the Service Bill of Materials Links Engineering to Service

When we embark on a digital transformation journey in the after-sales domain, where does the process start? With the sale of the product? Commissioning of the product? First service call? We believe the foundation for the design of your service delivery processes starts in engineering.

This blog is part 1 in a series of three.

The creation of the service manual

When Engineering designs a product, they have an intended use profile in mind. That use profile defines wear-and-tear. Subsequently, the maintenance engineering function will define mitigating strategies to maintain the output specifications of the product and to sustain/prolong its lifecycle. The results are typically captured in the service manual and the Service Bill of Materials (BoM).

The golden standard of service

In a recent engagement with a prospect of ours, we asked to see the service manual of a medium-complex product to scope the service delivery business processes. Our premise: we may upsell on the service manual and promise higher value, but when we deliver less, product continuity and lifecycle may be at risk. As such, the service manual can be seen as the golden standard of service delivery.

In the 165 page pdf-document, we found a wealth of information on what to do, when to do it, and how to do it. Bill-of-materials, serviceable parts, PM-frequencies and kits, recommended consumables and spare parts, installation parameters, calibration values, and MTBF rates. We got enthusiastic. If somebody in engineering created this document, how does it ‘flow’ to after-sales? What system of record does after-sales use to be able to act upon the information in the service manual?

Digital thread

In the last decade, we’ve seen a lot of digitization initiatives driving the transformation agenda. We’ve also seen that a lot of digital data is still created and collected in silos. Engineering is digitizing product lifecycle management (PLM), manufacturing is pursuing Computer-aided manufacturing (CAD), sales are rolling out customer relationship management (CRM) and service is reshaping field service management (FSM). But how do they link to one another? Isn’t the overarching value promise of digitization the sharing of data leading to 1+1=3?

If your organization is in the business of designing, manufacturing, selling, and servicing products, then all those functions are connected through a digital thread. The carrier of the thread is the product itself. Starting as an as-engineered and subsequently transitioning into an as-built, as-sold, and as-maintained. In each stage of the lifecycle, additional information is added to the thread. Zooming out, each function will look at the digital thread through a lens to increase the value proposition.

Design for service

In our engagement with the above-mentioned prospect, we were curious how much design-for-service thought was put into the engineering phase and how that information would shape the design of the service delivery processes. Though the wealth in 165 pages of the service manual was phenomenal, the service organization had not yet invested in processes to receive the engineering baton.

The opening paragraph of the service manual provided a great narrative to introduce the baton. “Congratulations on your purchase. To protect your investment and get maximum return, we’ve defined some handles for good husbandry. This manual contains the instructions to guarantee the nominal output over its technical lifecycle”. In other words, the service manual defines the golden standard of maintenance to underpin the value promise of the product sale[1].

What Engineering documented in the 165-page service manual can be condensed in the following picture. In the first column, we find the Service-BoM. The Service-BoM is a subset of the Engineering/Manufacturing BoM. It contains only those parts that are serviceable. The manual pre-empts what skills are required to perform that serviceable activity. Can it be done by the customer, does it require a skilled technician or should the part be swapped in the field to be repaired in a depot/repair center?

With the above information from maintenance engineering, service delivery has a great blueprint defining what output its business processes should deliver. Analogously, service sales has an anchor to model cross and upsell offerings for customers having needs beyond the baseline described in the service manual.

Design for improvement

The service manual also serves another very important purpose; improvement. Improvement in two directions. Engineering giving handles to service and service giving feedback to engineering. As an illustration, I’ll use the mean time between failures (MTBF) column in the above table.

When Engineering designs a product, they typically have an idea of the lifecycle/MTBF of used components. Those values initially are theoretical numbers. Call them Plan. When the product hits the field in larger numbers, empirical values will trickle in. Call them Actual. When Actual is within a narrow margin of Plan, we say this is expected behavior. When it falls outside the margin, we call it an outlier. Understanding the root cause of the delta between Plan and Actual will enable you to drive improvement by process design.

  • Maybe the product was not installed properly
  • Maybe the product was not used as intended
  • Maybe engineering was wrong
  • Maybe service delivery was not in line with the service manual
  • Maybe the customer pushed out a preventive maintenance cycle
  • Maybe non-approved spares have been used

Actionable Service-BoM

What started as a trivial ask “can you share the service manual of a medium complex product” resulted in a pivotal conversation bridging engineering and service. The service manual is no longer a static 165-page pdf-document sitting in a knowledge repository. It is now an actionable document driving improvement and value in both the service and engineering domains.

[1] When selling products with a transfer-of-title, the risk of maintaining the product transfers to the buyer. Thus, the buyer becomes responsible to mitigate that risk in order to continue receiving the outcome/value of the product. The buyer may purchase maintenance services from OEM or choose differently. Read further in part 3 of this Digital Thread series.

This article is published on Field Service Digital.