Are You Winning or Losing?

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!

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.

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. Just like 1918 (see top 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.