Rethinking the Relationship Between Tech Pubs and Engineering

Eric Neyer February 9, 2017 Tags: , , , , , , ,
featured image

NOTE: This article was originally published in the Center for Information-Development Management’s (CIDM) Best Practices newsletter in February 2017. The author is Richard Ackerman, Digabit’s Senior Director of Solutions Engineering.

Information developers in manufacturing environments have a natural desire to use engineering output to create product manuals, parts book content, and other technical support materials. The goal in reusing engineering content is to save time and effort. However, the negative impacts on user experience can lead to the opposite result for functions related to customer support, spare part sales, and service.

There are many reasons why exporting engineering content for customer-facing documentation is ineffective. Most of these reasons stem from the fact that engineers develop their content for different purposes, and with different requirements, than the technical information developers who are tasked with creating customer-support documents.

Let’s unpack and investigate a few of the reasons why information developers and engineers may be better off with an amicable break up.

Engineering’s role, in a nut shell, is to define what the final product is

Engineering output is in the form of bills of materials (BOMs), CAD models and drawings, specifications, and other data. Typically, engineers create BOMs to the extent necessary that parts can be purchased (from a third-party supplier) or built. Engineering references a purchased item by a single part number, and thus all the details for service items within the purchased component are not typically captured by engineering. Even if they are, service items do not necessarily appear in the BOM and certainly don’t appear in the CAD drawing.

Engineering departments usually follow industry standards regarding CAD models and drawings. These standards, such as ASME Y14.5, are designed specifically to achieve uniformity in drawing specifications and interpretation, and they lead to desirable outcomes throughout the manufacturing process — improved quality, reduced costs, and quicker deliveries. These standards result in familiar views of an assembly, such as top view, side view, front view, and so on. Internal details are shown by cross-sectional views.

While this information is an acceptable solution for manufacturers, customers who need to repair and maintain their machines are not necessarily versed in reading engineering diagrams. Customers are better served with a more intuitive, easier to understand visual presentation.

Engineering naming conventions and information hierarchies are not “user friendly”

A bill of material structure, or hierarchy, that is useful for engineering purposes does not necessarily reflect the way an end user would “think” of their equipment. For instance, if users need a component on a control panel, they might like to view a representation of the entire control panel so they can quickly find what they need.

Typical CAD design engineering drawing

Figure 1 – Typical CAD Output from Engineering

However, if there are various functions that each have components that live in the control panel, the engineering definition of the control panel may be split up into many different assembly BOMs. While this works fine for the manufacturing process, it certainly is not logical or efficient for an equipment owner or service technician. It is common for savvy information-development teams to rearrange a machine’s hierarchy (for example, in a parts book Table of Contents) to ease search tasks and provide a better user experience.

Engineering descriptions may not make sense to external users. Parts are commonly described with a nomenclature system similar to the following: noun, qualifier 1, qualifier 2, and so on. Additionally, engineers tend to abbreviate part descriptions so the key descriptors fit into the space-limited fields available.

Thus, you may have something like this from engineering: MTR, AC, 3PH, 5HP. This code is appropriate for internal use, but unfriendly for less technically capable end users. Sophisticated information developers take the time to translate this code into ordinary language such as, “5HP 3-PHASE AC MOTOR.” Not only is the terminology more readable, “motor” is the most likely search term entered by a customer in an electronic environment. We have another example of engineering output that detracts from a positive user interaction.

Engineering CAD drawings are not optimized for part sales or service

Figure 2 – Exploded Assembly Created from CAD Source

One of the greatest demands on information developers is the translation of engineering output into parts-book ready content. Figure 1 above shows a gearbox assembly drawing with individual parts identified by item numbers. Figure 2 is an illustration of the gearbox that has been “translated” with a graphic design application for better usability. You can see how 2D views are moved to exploded 3D. There are also item numbers added to the exploded view to show service items not captured in the engineering output. Which of these assembly illustrations is more useful to a customer or mechanic?

Can we automate publishing or modify engineering processes?

Companies have tried different approaches to solve the problems posed by using engineering output for information development. These include using various methods to automate information development, as well as trying to alter the methods by which engineering produces content. Both of these approaches can be very challenging.

Engineering resources are expensive

There are significant opportunity costs incurred when assigning engineers to create clean exploded views with service items added. Labor costs for engineers are generally higher than for publishers and illustrators, and they may not be as efficient as workers who are exclusively dedicated to information development tasks. Most manufacturers allocate engineering resources to create new equipment designs or to fix product flaws. The vast majority of manufacturers consciously decide not to use high-value engineering labor to build user-friendly content.

Automated integrations aren’t intelligent enough

Imagine that an off-the-shelf or custom-built system allowed a manufacturer to export and convert CAD data, and hypothetically build a parts book automatically. Without some intelligent (human, for instance) intervention, it’s nearly impossible to address issues related to service items, BOMs, and the other factors described above. Artificial intelligence may someday provide a better answer, but there’s a great deal of development to be done first.

Accurate parts lookup efficient maintenance

The path toward a modern solution

For the reasons provided here, it’s time to move on from the dysfunction caused by incompatible content. Engineering and information development aren’t the perfect partners that they might like to be, but there is hope! Using easily available, appropriate technology allows information developers to work alongside engineering, while avoiding the limitations and drawbacks of being tied to unaltered native content. Here are some high-level steps:

  1. Once parts-book-ready content is created, it should be tied to the engineering output via metadata or “tags.” Thus, the improved illustration is identified by the assembly number, revision, product family, status, or any other relevant information.
  2. Software should be deployed that provides optimized content to end users in a searchable online library that is built on a relational database. Then, when parts are revised, information developers can navigate to the appropriate data at the part or assembly level and make the modifications as needed ONE TIME. As a result, all documents containing that shared source information are updated simultaneously.
  3. The relational database should be able to manage alternate descriptions to accommodate internal and external users.
  4. The software should understand the hierarchy of the machine and most importantly provide a clean user interface so that an information developer can effortlessly rearrange content to better accommodate the customer.

With the right tools and methodology, information developers can provide truly useful documentation

The key is not to fight with engineering but to accept the translation process necessary to achieve superior documentation. Some manufacturers may view this as extra work; the truth is actually to the contrary. How much time and money is wasted when the wrong parts are ordered due to confusing documentation? How many customers lose confidence in the manufacturer when this unfortunate (yet common) event occurs?

Using modern practices and technology in information development can increase efficiency by 10X or more. Consequently, the initial effort to set up and implement such a solution becomes an easy investment to justify. Even the most overtaxed and resource-constrained information-development teams can deliver polished, comprehensive documentation in a world class manner.

Should You Update Parts Catalog Content? Do the Math!

Digabit Inc November 8, 2016 Tags: , , , , , , ,
featured image

With over 20,000 registered users, Digabit’s Documoto platform has generated enough data for us to estimate the return on investment (ROI) for various scenarios at manufacturing companies.

Here is one common dilemma: While it’s a given to create electronic parts catalogs for new and current models, some of our customers have decades’ worth of older models that are still in operation and require ongoing service and maintenance. Older units tend to generate more parts orders, so it may prove worthwhile to convert older parts catalog content into an interactive online format to help capture more of those revenues.

In a traditional desktop publishing environment, where the end product is often a paper copy and/or PDF, the process of converting and migrating older files and data into an acceptable format is so time-intensive that most companies cannot justify the labor and expense to update past technical documentation.

However, Documoto’s publishing platform automates or eliminates many manual tasks, like copy-and-paste and other layout chores, once a company has loaded its product data into the database.

So, how do you determine whether it’s worth the time and trouble to move older product info into Documoto?

Let’s assume a manufacturer has eight extremely popular models of earth-moving machines for which they want to update support documentation. Using desktop tools, Digabit customers have reported taking three weeks or longer per model for the publications department to convert older data and publish high-quality PDFs. That equates to a 24-week backlog of work to update eight parts catalogs.

We’ll conservatively estimate that the average publications employee compensation equals $50,000 a year. That means the cost of creating updated parts catalogs is roughly $23,000 for labor alone. And six months’ worth of labor during which those employees aren’t accomplishing anything else of value.

Imagine that you had a publishing system in which you could create electronic, print and PDF catalogs in three days versus three weeks?

Now you’re looking at around $4,600 in labor to update your legacy catalogs. Similar savings can be achieved every time a revenue-generating parts catalog needs updating. And it doesn’t take many returned parts, hours of phone support, or lost part sales to add up to the cost of transforming legacy to digital.

What would a modern publishing system like that cost, you ask? Digabit’s Documoto Authoring Essentials starts at $1650 a month, or less than $20K per year. Just about the cost difference between the old and new ways of doing things.

What are we not factoring in? The huge opportunities afforded by freeing up five months of publishing labor. And the potential boost in aftermarket sales provided by having up-to-date parts information in Documoto’s Cloud Storefront (with additional subscription costs). Customers have proven their willingness to pay for the convenience of buying online, especially when they know they’re getting the right, high-quality OEM parts!

The 3 Deadly Sins of Online OEM Part Sales

Eric Neyer October 20, 2016 Tags: , , , , , , ,
featured image

How do manufacturers of heavy equipment and machinery typically sell parts for repairs and ongoing maintenance? Most would not be very successful running print ads like the one from the Pullford Co. at the top of this post. However, some companies still employ similar tactics to sell to online prospects.

Print ad circa 1910 from C. L. Best, precursor to today’s Caterpillar. Note the instruction to “Write for catalogues, terms, etc.” How times have changed…or not, in some cases.

Print ad circa 1910 from C. L. Best, precursor to today’s Caterpillar. Note the instruction to “Write for catalogues, terms, etc.” How times have changed…or not, in some cases.

In this era of transition from legacy processes to increasing digitization of everything, how are manufacturers doing at creating easy-to-use online experiences for buying OEM parts?

The results are mixed. At the upper end of the spectrum, many advanced manufacturers have dedicated dealer/customer portals with secured log ins and some eCommerce functionality.

However, there are still plenty of profitable, successful companies who offer poor customer experiences when it comes to parts lookup and ordering. Let’s look at examples of just three of the deadliest sins committed by manufacturers in the online sales arena.

Sin #1: Generic Web Form


The screenshot at left is from the site of a $6-billion manufacturer of heavy construction equipment. Users can select a type of machine and model number, then enter text into an input field simply labeled: “description of parts needed.” The instructions at the top of the form state, “Your request will be directed to your local dealer who is equipped to give you the accurate answers to your needs.”

Okay. I get that this company is beholden to their dealer channel. If I absolutely must order through a dealer, why even bother offering this form? After submitting the form, then what? Wait for the local dealer to email or call back. When will that be? Who knows?

Sin #2: Static PDF Catalog

The number of manufacturers who generate over $1 billion in annual revenues and still offer PDF downloads of parts catalogs is simply astounding. This is likely the most common sin regarding online user experience. We won’t highlight any particular example here, in the interest of not embarrassing the worst offenders. If you’re curious, take a look at the Fortune 1000 and visit some of the manufacturing companies’ websites. It won’t take long to discover your own examples.

The quality of online PDF parts catalogs varies greatly. Some show long lists of part numbers and names with no illustrations. Others display crude drawings with part names but no numbers. Is it really helpful to display a photo of an assembly and list the part numbers underneath with no exploded views? Not so much. Grab a cup of coffee and prepare for a long phone call….

Sin #3: Generic Web Page with No Clear Direction

Most larger companies are more sophisticated than this, but the screen shot shows a corporate web page of a manufacturer that generates between $20-50 million in sales. There is a street address and several contact numbers listed on the page, so I guess the user is supposed to pick up the phone or write a letter to inquire about buying parts or getting equipment serviced. The company’s not giving you any more clues than that.

What do I do? Call someone, I guess.

What do I do? Call someone, I guess. Just like 1918 (see top image).

How to Avoid 3 Tempting Pitfalls of Structured Data

Eric Neyer October 12, 2016 Tags: , , , , , , ,
featured image

NOTE: This article was originally published in the Center for Information-Development Management’s (CIDM) Best Practices newsletter in October 2016. The article was contributed by Richard Ackerman, Digabit’s Senior Director of Technical Sales.

The technical publishing world has increasingly gravitated toward structured data concepts and tools over the past decade. From XML to DITA to component content management systems (CCMSs), the evolution continues thanks to savings in labor, improved accuracy, and optimized workflows afforded by structured data methodologies.

While using structured data to publish technical documentation offers significant efficiencies, it is quite common to find publishers who impose unnecessary challenges upon themselves. This article addresses the top three traps publishers should recognize and avoid.

Stop Putting Intelligence in File Names!

What is the purpose of a file name?

From a software perspective, often the only limiting parameter for a file name is a unique string of accepted characters. However, it is extremely common in practice for individuals saving files to include information associated with the file, or “intelligence.”

While it is important to capture metadata, the file name is typically the worst place to include attributes of the content.
As a hypothetical exercise, let’s pretend the file name for a particular manufactured assembly includes the model number of the product where the assembly is used. If engineering decides to use the same assembly on a related model (with a different model number), will the publications department update the file name accordingly? Probably not.

While this is a simplistic example, using intelligence in a file name, whether to facilitate search or for some other well-meaning objective, inevitably results in conflict, confusion, or unnecessary work to maintain.

It is much easier to set up a system where the file name simply uses the next available number or some other arbitrary convention. This system allows all respective attributes to be applied as metadata.

There will never be confusion in the case of a one-to-many relationship if you are diligent in keeping intelligence separate from file names. And you will avoid the unnecessary work of maintaining file naming conventions that are based on some descriptive aspect of the content.

Best practices for structured data suggest that you should leverage software to manage the attributes of a file or data element. Consider the file name to be the equivalent to a “key” in a database. A file name in structured publishing should simply be a unique identifier. Don’t be lured by the appeal of making it mean something more.

Choose Your Storage Wisely!

Most companies have a huge assortment of software tools, databases, server locations, and so on, which offers multiple feasible locations to store important information. Depending on the type of information, there are clear advantages in storing the data in a specific location.

Let’s consider a scenario in which text-based data is stored within an engineering drawing. Maintaining this information in CAD is significantly more expensive than managing the same data in text-based databases. Revising data in CAD requires skilled, highly compensated resources (usually in short supply), and also involves more demanding workflows to implement changes.

Obviously, high-quality models and drawings require CAD; however, text-based information is better suited for storage in other applications.

One example occurs when OEMs place vendor information on a drawing. This practice is not suggested, even if a part or assembly is sole sourced. Instead, vendor data can be captured in an ERP system, and then programmatically applied to a related purchase order. If a new vendor is eventually contracted to supply the part in question, the time difference in maintenance is profound.

With regard to electronic parts catalogs, including text-based information in an illustration is similarly detrimental. Use software that has appropriate places to capture text-based data. It is always easier to update a text field than an illustration. This ideal is readily apparent if the text field has many instances of re-use.

Furthermore, combining data elements such as the illustration and text attributes limits the functionality of relational database behavior if changes need to be made on one element rather than both elements simultaneously. Combining elements like this negates one of the major benefits of implementing a database publishing system.

Don’t Combine Data Elements!

Manufacturers employ a number of common strategies to increase publishing efficiency. Some of these strategies endure, even though they were born in an unstructured world.

For instance, consider a parts list matrix within a parts book that shows what the corresponding part is for each model. In other words, one page is detailing all of the parts within the machine assembly for all models. While this was extremely effective when creating standalone PDF-type documents, it is incredibly constraining in a structured publishing environment.

With structured database publishing software, tying multiple data elements into a rigid form severely limits the ability for the relational database to manage the data. Each data element needs to be distinct.

This rule of thumb also applies to our earlier example of placing text-based information within an illustration. Another common error of this type is placing metadata (or information that can be captured in metadata) within a description field.

It is incredible how many unique strategies creative publishers have invented in order to save time. While these approaches may have been advantageous in the past, and may still offer short-term benefits, these “benefits” eventually add up to an opportunity cost that manufacturers cannot afford. Continuing legacy practices that are incompatible with new technologies is guaranteed to create havoc when a modern system is inevitably adopted.

It may be time to pause and sharpen your axe before swinging at the trees. Are the “keys” to your relational database unintelligent? Are you using the most efficient location to store corresponding data? Are all of your data elements discrete? If you answer, “No,” to any of these questions, you have great opportunities to maximize efficiency in your current—and future—publishing tools.