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.
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
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.
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:
- 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.
- 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.
- The relational database should be able to manage alternate descriptions to accommodate internal and external users.
- 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.