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: Should Service Execution begin with the handover from Engineering?

I had the privilege to present to the Advanced Manufacturing Research Centre (AMRC) of the University of Sheffield. Their website is packed with tags like “tomorrow done better”, “shaping the future of manufacturing”, and “world-leading technology experts”. What better place to discuss the topic of Design-for-Service with an audience immersed in Design-for-Manufacturability (DFM)? Allow me to share a back-to-the-future story. 

Blindfolded 

Service Blindfold challenge: Win $1000 cash.

About two years back, we interviewed a contingent of field service technicians. We asked them what makes them happy and what puts them off. 

In short, technicians love to be the hero-on-site, fixing technology and keeping the world running.  

On the flip side, they dislike going on a job blindfolded, with their hands cuffed and not being empowered to do their job. 

To elevate a technician’s role from reactive fire-fighter to proactive savior, first and foremost, we need to give them tools to see. This includes understanding what the product is, its current state, and how it is being utilized. Rather than immediately entering repair mode, it’s crucial to provide engineers with access to product engineering data, using this information so that they can diagnose the problem effectively. This is where the handover between engineering and service unfolds. 

Intellectual property 

When Engineering designs a product, they have specific use cases, product output, and performance in mind. For an original equipment manufacturer (OEM) the entire design and engineering thought process is considered intellectual property (IP), leading to the creation of great products. It’s the IP that sets their product apart from the competition. 

Then those products go into the field and buyers start using them. This is where the rubber hits the road. Does the product in the field behave like it was designed to in the development lab?  

Products in the field are best taken care of by Service. The more information Service knows about the engineering IP, the more efficient and effective Service can be in managing and supporting the operational lifecycle of the product. When mastered, you can even use Service as the primary revenue model

The IP can also flow from Service to Engineering. Throughout the operational lifecycle of a product, the Service team has multiple touch points with the product. Each touch point generates data. This data is on the actual behavior and performance of the product.  

Now we have two sets of data; the planned data from Engineering and the actual data gathered from Service. This opens up a plethora of instruments for continuous improvement. This improvement includes data for personnel in engineering, quality control, sales, product planning, supply chain, service sales, and service delivery. 

Handover from Engineering 

Not only in this Advanced Manufacturing Research Centre (AMRC) discussion– but in practically all conversations we have with OEMs– we often get to a point where product focus and service focus end up on two ends of a scale. It’s as if they are being treated as mutually exclusive; which should not be the case. 

There is a middle ground. Through the use of technology to hand over the engineering IP to Service and have Service embed that IP in their service execution processes we remove the blindfold. This is best illustrated through the function of maintenance engineering. 

A visual representation of the function of maintenance engineering

Maintenance engineering defines how to maintain the product, it sustains the product performance and output. Service translates the engineering-BoM into a service-BoM, identifies spare parts & kits, and creates preventive maintenance schemas. They also bundle installation, maintenance, and operating manuals. 

The good news is, the technology to hand over engineering data to Service in a clear and digestable format is there. Even better, most OEMs have a maintenance engineering function created in their IP making the barrier for entry low.  

Back to the Future 

Since November last year, I’ve been using the maintenance engineering narrative more forthrightly. I’m fascinated by the responses I get from customers, prospects, and researchers. First, a deafening silence, then comprehension and realization. It’s all so logical. It’s all so prognostic. So why haven’t we jumped on the bandwagon? 

To get a feeling of the engineering-service-handshake in 2023, we spoke to 50 service business leaders at Copperberg Field Service Forum. We started with an easy question. How many pages does the maintenance manual of a medium complex product have in your organization? The response: anything between 20-2,000 pages.  

We progressed to the more difficult questions. What information is in that document? Where is the document stored? Who reads it? Why? Why not? Does the content bring value? Should one use it? The conversation was not meant to create anxiety, but to make one see how existing engineering IP could be leveraged better in the service domain. 

It’s today’s technology that makes it possible to act on the handover from engineering to service, to apply the maintainability concepts in service execution, and to reap the business benefits. This puts the ball back in the court of OEMs. Do you want to remain silent or do you want to act now? Do you want to walk the talk? 

I am guessing that this will not be our last conversation on this topic. 

 See why service needs to be a team sport: Learn More 

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

Digital Thread: How the Service Bill of Materials Enables Cross-selling & Upselling

It’s 2010, and an OEM has asked me to blueprint their after-sales organization. I went to our sales executive and asked, “What do we tell our customers about life expectancy and maintenance costs when we sell the product?” He looked at me with a confused look.

Why is this important? Because, if you want to cross-sell and upsell services in the after-sales domain, you need to know what value was promised when the product was sold. This is where the service manual and the Service Bill of Materials come into play.

This blog is part 3 in a series of three:

The value promise of the product sale

My sales executive sold complex capital equipment. For each product in his portfolio, engineering provided him with technical specifications describing the output capabilities. He would ask customers for their intended use profile and select the model that had a matching output bandwidth. To not complicate his CapEx sale, he would avoid a conversation on:

  • How many years will the product be able to sustain specified output levels?
  • What is the expected decline in output levels given the customer use profile?
  • What maintenance efforts are required to sustain product specifications?

Upon delivery and title passage of the product, the buyer would have access to the operator and service manual. These provided insights into the ‘size of effort’ required to use and sustain the product. If a total cost of ownership calculation were a prerequisite to the product sale, my sales executive would defer the calculation of the OpEx piece to the after-sales department.

Total cost of ownership

I’ll skip the semantics on if we should talk about the total cost of ownership or lifecycle cost. The idea is to create an understanding of what it costs to sustain the product over a prolonged period of time while maintaining output specifications.

Once more we can draw on the intellectual property and effort from engineering. As we’ve mentioned in part 1 of this series, the service manual describes the efforts needed to maintain nominal output specifications. To put it another way for the customer, “If you maintain your product as stated in this document, we, the OEM, guarantee the output specifications.” Thus, when we cost/price those activities, we have a pretty neat approximation of the OpEx piece of TCO.

Title passage

When an OEM is in the business of CapEx sales, it will have a title passage of products. Beyond title passage, all pains and gains of the product transfer to its owner. Now it is the responsibility of the owner to act upon the instructions in the service manual. Most likely there will be a clause saying that non-compliance with these instructions ‘may’ void OEM output level guarantees. There may be a clause that voids the warranty when non-authorized parties perform maintenance activities on the product.

This is where it gets interesting and dualistic at the same time! On the one hand, the OEM bestows the risk of owning the product onto the buyer. On the other hand, the OEM wants something from the product buyer post-title passage—“buy my maintenance services.”

This happens in a context where the owner of the product has the legal right to choose to follow the user manual instructions, to ignore or deviate from them. The owner can also choose to perform the activities themselves or to outsource. If your business model is driven by title passage, you can’t force a product buyer to buy associated services. You can only entice product owners to buy your services.

Cross and upsell

The first step to cross and upsell is establishing a baseline on what comes included with the product sale and what is extra. If the product is sold with a warranty, the warranty conditions will define what is included and what is not. It is important to clarify that a warranty is predominantly promising the correct working of the product. Not a ‘free pass’ to mitigate actual wear & tear as a result of using the product.

The second step to cross and upsell is having a conversation on how the owner will use the product. When the use is exactly as envisioned by engineering, then the operating and service manual will define the maintenance standard for sustaining the output specifications. When the customer uses the product in different settings, you may want to introduce ‘bundles’ of maintenance activities associated with low, medium, and high usage. Call them bronze, silver, or gold. For more granular services you may want to use a concept like a menu card.

Once you have jointly agreed on what maintenance activities are required to sustain output specifications given said use profile, the final step is defining who does what. This is a risk versus cost conversation. Either the product owner bears the cost and risk of using the product or those are outsourced to a service provider/OEM at an agreed price.

Companies that have a large installed base of products and trained internal technicians may choose to execute the service manual activities themselves. Others may evaluate the risk versus cost differently, and buy services ranging from preventive maintenance to full service. Mastering the risk/cost conversation in conjunction with intellectual capital captured in the Service-BoM and service manual will become your toolset for cross-selling and upselling.

Digital thread

In three blogs we’ve spotlighted the Service Bill of Materials through the lenses of cross & upsell, system of record, and linking engineering to service. We’ve seen the value of the digital thread spanning engineering, manufacturing, service, and sales—proving value across the entire product lifecycle.

This article is published on Field Service Digital.

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.

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 and PTC Blog Site.