Citec developed this connection and the methods of having the CCMS (Component Content Management System) and PDM (Product Data Management) connection more than ten years ago and has since been a pioneer in this area. Based on experience Citec has made solutions outperforming many of the PDM systems including a CCMS module due to the understanding of not only the way to document but also having understanding of the products described.

Information overload is a common phenomenon in today’s world. The abundance of data has led to the development of smarter and smarter information management tools. Information “consumers” are increasingly conscious of how well suited some information is to their needs. Are they able to find answers to their questions? Is the information relevant to their particular context? People do not want to have to figure out what variant or version of a product they are using. They do not care about features that are only available in other markets. Instead, they want information that is perfectly adapted to their context.

The key to relating a product, as expressed through a BOM, and its documentation formally in this way, is to ensure the mapping is flexible insofar as a change in the PDM system has minimum impact on the CCMS.

The process of creating a manual that is perfectly adapted to the product it describes must be cost-efficient and repeatable. XML-based, modular documentation offers excellent building blocks when done right. Consistently structured and carefully curated content is authored as standalone pieces of content. Those pieces can then be combined in new ways. This approach also allows us to include snippets of information aimed at different contexts side-by-side and to tag each snippet with a clear label (think “car A” and “car B”, for example). At publishing time, a set of values that represent the context of the manual is specified, for example:

• “chassis”: “hatchback”,
• “fuel”: “Diesel”,
• “model”: “A”,
• “series”: “Ultimo”,
• “transmission”: “automatic”

The publishing process is fully automated. It includes or excludes content in the XML source based on the context and then transforms the content to paged output such as a nice-looking PDF or HTML output for the web.

While the principle is simple, the crux is that the number of features (values in the context) can number in the hundreds or more. Defining the context can become an overwhelming task. Done manually it is both a time-consuming and error-prone process. In the most common case, it is unnecessary, as that information, that is, what a product is made up of is already available in a PDM system. It might be in the form of a BOM generated from a PDM system or it can be a simple feature matrix in Excel – or something in between!

Bridging two paradigms

PDM and CCMS systems are completely different in terms of data model and logic. However, they are both intimately related to products, although from rather different perspectives. The PDM system has very granular information on each product, down to the last nut and bolt. The CCMS system contains descriptions, procedural information and reference data about the same product. Users of a product are typically not interested in a list of every component that is part of the product – they want to know what the product can do and how to do it!

From a documentation-oriented perspective, we can talk about “features”. Normally what is considered a feature in the documentation corresponds to several assemblies, subassemblies and components on the PDM side. Suppose we are talking about the headlights in a car, for example. There may be a number of variants available, such as Halogen, LED and Xenon lights. Internally each variant may consist of any number of components, and there are most likely multiple sub suppliers involved. Suppose a component is exchanged for a functionally equivalent component from a different sub supplier. That is an important change from a manufacturing perspective, but from a documentation perspective, it is not.

The two levels of features defined (blue boxes) allow a Technical Writer to distinguish between the three variants, but also to talk about headlights in general.

From a documentation perspective, there is a need to distinguish between the different variants. On the image above, there are two levels of features defined (blue boxes). These allow a Technical Writer to distinguish between the three variants, but also to talk about headlights in general.

Behind the scenes, a set of material numbers is associated with each variant. For each variant, for example Halogen headlights, there will be new revisions over time. Again, that is not something that necessarily impact the documentation heavily or at all. When the BOM is received and examined, the end result is a flat list of features. This list represents the context according to which the product manual should be adapted (as a fully automated process).

The end result is a flexible solution that minimizes the amount of continuous maintenance caused by product changes.

The key to relating a product, as expressed through a BOM, and its documentation formally in this way, is to ensure the mapping is flexible insofar as a change in the PDM system has minimum impact on the CCMS. The PDM system contains more granular data and it is consequently no surprise that it is revised very frequently. Any change must be reviewed and the material number(s) related to a feature or alternatively marked as having no impact on documentation.

Depending on the complexity of a product or system, there may be a need for additional feature levels to allow technical writers to make distinctions. A careful conceptual analysis of a product or system is the first step in building the model.

Summary

It is possible to generate product-specific information products on the basis of a BOM. This requires building a logical bridge between two inherently very different types of system: PDM and CCMS. We achieve this by introducing an abstraction layer between the two systems, where material numbers are related to features used in the source XML of the information products. This allows Technical Writers to use intelligible labels in the text editor. The end result is a flexible solution that minimizes the amount of continuous maintenance caused by product changes. We have delivered this Citec SPECO solution to great benefit to several of our key customers.

Want to know more? Contact us and let us streamline the delivery of your information products!

Joakim Nybäck
Information Architect
 joakim.nyback@citec.com