We live in a highly customizable world.

Most of complex products we buy, from computers to cars, can be assembled by request and include the components that we need. When you order a car, depending on your preferences, it can be delivered with a manual or automatic transmission. Or it may be supplied with a diesel or gasoline engine. With more complex products, the number of combinations can be more complicated.

From the documentation perspective, it means that the product documentation needs to be customized as well. If you are using single-sourcing concepts or writing in DITA, you definitely know a bunch of approaches that allow you to customize content for a specific product model or flavor.

However, the question is which approach would allow you to deliver the customized documentation in the most efficient and error-free way. I think there are some things that we can learn from engineers.

 

Mulitple BOMs, Multiple DITA Maps

In manufacturing, to define the components to be included into a specific product, engineers use a structure called bill of materials (BOM). If the product have multiple variations that determine which components are to be included, there are different ways to handle the BOM.

One way is to have a separate BOM for each product. If you are in DITA, it’s like maintaining a separate DITA map per product. It might be a good way to go, but you have to properly set up reusable parts of the maps so that if a new component is introduced in to 10 products (=10 maps), you would need to add it just once.

 

One BOM, One DITA Map

Another approach is to have a so-called 150% BOM. This is a term that engineers use to refer to a single bill of materials (BOM) that includes all optional components that the product may have. For example, if a car may be produced with a manual or automatic transmission, and may have a diesel or gasoline engine, the 150% BOM would look something like this:

  • Transmission
    • Automatic
    • Manual
  • Engine
    • Diesel
    • Gasoline

Because such a BOM includes more components than an actual final product will have (more than 100%), it’s called 150%. A 150% BOM needs to be stripped down to a 100% BOM by selecting the components exactly should be included into a specific product. This task is usually done using a configurator, which is often a part of PLM systems. There were some discussions in the engineering world about the future of 150% BOMs. One of the ideas with which I agree is that with the growing complexity of products and mass customization, the 150% BOM approach will be dead in the future and will be replaced with more flexible and automated tools.

But you can find the 150% BOM approach in the documentation too. In terms of DITA, it’s similar to having one huge master map that includes content about all possible components and then filtering it on publishing. While at first sight it seems to be easier to maintain and manage, in the long run, it will likely turn out to be a disaster. Think of translations, for example. If you have one huge master map that represents multiple products and you need to translate content for just one product, what would you send to the translation agency? You would either have to send them everything and therefore, overpay because they will translate content for other products too, or somehow pre-filter the master map to create a submap that will represent a specific product.

 

Automated Assembly for BOMs and DITA Maps

A much more effective approach would be assembling BOMs and product documentation automatically. For BOMs, it’s already happening with automated rule-based generators that automatically build a BOM for a specific product based on the data retrieved from the customer’s order. For documentation, an entire set of documents can be assembled from individual topics.

For example, a solution we’ve built for one of our manufacturing customers works as follows:

  1. It retrieves customer’s order data from the PLM system.
  2. It compares the order data with the metadata associated with topics stored in the central content repository.
  3. Based on the structural templates for different types of documents (e.g., sales guide for dealers, operation guide for consumers, troubleshooting guide for the support center, etc.), it automatically assembles documents from individual topics and publishes them.

With the complexity of products and customization growing, I believe that the need in an ability to automate content assembly and content generation will be growing increasingly while manual work will be getting more expensive and risky.

 

Leave a Reply

Your email address will not be published. Required fields are marked *