How to Include Tech Pubs in Engineering Change Notices



You know what one of the worst parts of a field service technician’s day is? Spending time finding information. That’s according to a survey that The Service Council conducted in 2017.

What the survey’s analysts meant by “information” could have been many things – service history, the customer’s equipment model, and other details related to a specific service call – but it could have also been general service information about a product.

You’d find the latter type of information in service manuals, parts catalogs, and other such publications. There are two reasons why the information in those materials may be difficult to find:

  • Technical publications are inaccessible: Can a field service technician pull up 3D technical content on his or her mobile device? How difficult is it to obtain information?
  • The information within the tech pubs is inaccurate: Do the isometric drawings, technical illustrations, and other content match what field service technicians see in the real world?

If the latter statement is true, then the problem is that technical communication teams aren't included in engineering change notices.

Applying engineering change notices in a cost-effective manner

For those of you who work in tech pubs, this issue isn’t anything new. In the best of times, you have an open line of communication with engineers who proactively include you in engineering change notices. In the worst of times, you hear about design changes several weeks (or months) after those changes occur.

The most efficient way to update tech pubs with engineering change notices is to use a concept known as associativity. Associativity links engineering source data to downstream service information – technical illustrations, XML topics, etc.

Implementing associativity can be pretty tricky because many technical publications teams don’t use product lifecycle management (PLM) applications. PLM systems usually have modules that are specifically designed for managing service information, allowing content authors to utilize associativity. 

For example, before using a PLM system, one of our clients was just storing publication content in SharePoint folders, requiring technical writers to email each other whenever they received ECNs from the design team. Once they applied the changes in the ECN, they had no way of tracking what content they adjusted. As a result, it often took them over a year to release a single publication.

Criteria for choosing a product lifecycle management system

Now, not every PLM system will have the capabilities your team needs to track ECNs and quickly apply changes to technical content. My recommendation would be to look for functionality that:

  • tracks which XML topics, illustrations, and drawings are affected by specific ECNs
  • allows technical writers and illustrators to review ECNs before applying changes to downstream content
  • stores content for reuse across multiple publications

A research firm, Tech-Clarity, surveyed around 100 service leaders to learn what service information management capabilities made their organizations successful. The firm created a buyer’s guide based on the survey, which you can access below:

Extend PLM to Service Parts Information Buyers Guide