In industries, like aerospace, automotive, and machinery, products are usually delivered in a customer-specific configuration.
At the very least, different customers may receive different modules. In more complicated cases, different customers may get different versions of the software and hardware, different variations of the same component, and so on.
How to make sure that the product documentation that each customer receives is properly aligned with the product configuration the customer ordered?
One way is just to provide the same generic documentation to everyone. That would be a fairly cheap solution. However, in the long run, it will lead to customer’s frustration which will be translated to increased customer service and maintenance costs.
Another way would be tailoring the documentation to each customer-specific configuration. Although theoretically, with small amount of content, it can be done manually, the manual solution wouldn’t be scalable and eventually, will become too expensive and too slow to maintain.
The way to automate the process of aligning product documentation with the product configuration is to involve a configuration database.
A configuration database typically contains information about all individual components as well as variations of their assembly. By using a unique identifier, such as serial number or customer order number, engineers can tell what a specific product configuration includes.
Manufacturing companies usually have a configuration database of some kind in place. However, often times, it’s a separate silo without any connection to the product content. Documentation teams either have informal or semi-formal ways to learn what each configuration involves or engineers provide them with Excel spreadsheets, and then the technical writers have to manually modify the documentation to make it properly reflect a specific product configuration.
A good news is that the silos can be bridged. Building a bridge requires several components apart from the configuration database:
Componentized content. Because the ultimate goal is to gain an ability to automatically assemble product documentation from the pieces of content relevant for a specific configuration, the content has to be organized as a collection of independent, fairly small components. For each configuration, only relevant content components would be picked up.
Semantic metadata. To enable an automated assembly mechanism to identify the content components to be selected for a specific configuration, each component needs to be labeled with semantic metadata. At the very least, the metadata should refer to the specific configurations to which the content is applicable. In some cases, it could be a very simple label, like “Applies to Serial Number 12345”. With more complicated products, the metadata may include Boolean statements, like “Applies to all configuration that include ((Component ABC of Version XX) OR (Component ABC of Version YY) AND ((Component Y) OR (Component Z))”.
Semantic markup within content components. Product configuration may not only determine the content components to be selected, but also content variations within the components. To be able to differentiate between such content variations, they need to be labeled on the level of individual elements, such as procedure steps, table rows, drawings, or even paragraphs.
With the configuration database and componentized, semantic content enriched with metadata in place, the automated documentation assembly can work like this:
The publication manager specifies the product configuration for which the documentation should be compiled. The manager can refer to the serial number, bill of materials, customer order, or a similar record in the configuration database.
The documentation assembly engine retrieves from the configuration database information about the components included into the specified configuration.
Then the assembly engine goes through the content database and picks up those content components whose metadata matches the required configuration.
Once the necessary content components are selected, they can be assembled into a publication (many manufacturing companies are still required to produce PDFs), published to a content delivery portal, or pushed through any other delivery or content distribution channel.
Bridging a configuration database and content can also bring an additional bonus. Configuration databases often contain information about the modifications done by the engineers. If content components are enriched with metadata that refer to these modifications, the documentation assembly engine can be also used to validate whether all important engineering modifications were actually documented.
In regulated industries, like aerospace, doing this validation is typically a must-have. But even in areas with more relaxed regulation, providing customers with the up-to-date product content that reflects all the engineering changes may result in decreased maintenance and service costs.
Does that sound like something you would do with your own documentation? Drop us a line at info@intuillion.com, and we’ll be happy to discuss with you how this process cold work for you.
Comments