Product Information Management - Structured vs. Free-Form Approach

Product Information Management - Structured vs. Free-Form Approach

Defining product structure (what is key prerequisite for any PDM system to work) that will satisfy needs of all users is still a "holy grail" of PLM. To make it a more attainable goal, compromises are required. They entail reduction of scope (often targeting a group of users sharing some relatively well defined product view - e.g. manufacturing release of the product), and standardization of the product definition within that scope (e.g. part numbering nomenclature, hierarchical trees, attributes, naming rules, etc.).

Even when limiting scope, to bring everyone to speed on how to use the information management solution may take long time. Stories about out of the box, fast and easy enterprise wide adoption are largely unfounded (most in fact relate to cases where a handful of early users test the system as a proof of concept for larger enterprise adoption). The limitation at play here often is less related to software. The culprit is nature of creative professionals to resent structure when it comes to sharing information. Yet, without sharing information in a fast and efficient manner, product development cannot be planned nor executed with quality and timeliness required in today's business environment. Let me elaborate on this before coming back to the main dilemma - when to use structured and when to use free-form approach to product information management.

Like many other information management solutions, systems used for product information management serve four main purposes: storing data, retrieving data, finding information, sharing information. For the purposes of storing and retrieving data, databases with relatively simple meta-data structures suffice and that is what most information systems found today in product development are designed for. In order to support finding and sharing of information, systems need to use structures with much more complex data models representing contexts within which the information is used. Visualization and 3D viewers coupled with structure trees are very popular for this. Yet, there is a myriad of contexts in product development not supported with any system. Since most information systems, in order to be successful, are designed with a narrower scope in mind, an inclusive data model that represents all contexts is not present in any single system. Consequently, structures useful in supporting data storage and retrieval for one group of users may confuse another group of users who simply want to see the same data in a context not considered in the system storing the data. For example, a product planner would love to know what would be a true cost of a new feature for which the price is yet to be determined, or sourcing manager may want to know how heavy are die cast parts of specific material (lets' say zinc alloy) currently being designed across all products...

Structures often get in the way of creative thinkers who over time develop alternative information searching and sharing solutions, following an informal (or free-form) approach. Let's examine our options here. I see three options, first one being alluded to above - a single data model supporting all contexts and all data required to generate information in all of the supported contexts. To support the fact that data is changing continuously, this option would require not only that all possible contexts are supported by the single data structure, but that all data be stored in a common repository and governed with a central meta-data authority. It is frightening to see how many enterprise architects out there still believe in this utopia. Second option, is to move data back and forth between various authoring databases to support multiple contexts represented in multiple systems. This option is popular when limited to just few systems and contexts, but would become unwieldy when extended to all recognized contexts. Change management would bring this option to its knees.

Here is a very interesting fact: vast majority of enterprise architects consider only these two options, quickly determining that second one for practical reasons will have to deteriorate into first, once the entire domain of structured product information is considered. While these two options are different in the architectural concept, essentially both options require product structure definition up-front.

Third option is to let the product structure evolve using morphing free-form definitions of the contexts within which the information is exchanged. In fact, that is what is going on in most of development organizations. As much as we would like to believe that our information systems bring discipline and order, we also have to be aware of the fact that they only cover a tip of the iceberg of the critical information and based on which decisions are made. As it follows, informal information sharing is a predominant approach to product development information management today. Usually, only final records of decisions make it to some structured data capture format where they are managed through subsequent iterations. Most contexts and problem solving steps that lead to these decisions never get tracked through any official data repositories. Social rules like authority and credibility govern the information sharing in the free-form approach.

So, what would the free-form approach look like. First, it is not based on product definition structure, but on organizational hierarchy and taxonomy of various skills and knowledge items. It lists all people who participate in the process and through series of associations with roles and key words describing their work products, it provides quick look ups of who should be in charge of what work product. Just like in this blog, each participant would maintain a log of tasks and/or posts that link to the underlying data directly related to their work products (3D designs, part tolerances, tests, material costs, ...). Here, even some fairly loose governance comes handy. For example, some users could automatically publish their task logs from internal tracking systems providing they have used them for their work. Others could choose from pre-specified log forms that are appropriate for the type of task they perform. Within these forms, links can be inserted to specific digital artifacts (data and documents) contained in their internal authoring systems. In each case, system architects would enable series of policies for retrieving and storing data directly into the systems through free-form entries wherever the logic of the process allows for it. Web services and XML document types come very handy for this purpose. Thus, exposing data from the authoring systems in contexts freely maintained by the users allows for fast finding and sharing of critical information.

Using structured and free-form approaches combined enables best of both worlds. Structure helps maintain and manipulate vast amount of data, while free-form contexts make that data available to all users based on their natural way of sharing it. Over time, the two can evolve, replacing the free-form contexts with mature structures (repeatable patterns) and allowing for new contexts to take shape as they are being discovered by the users. Governance in this approach is much more relax than in either centrally managed repository or system to system data exchange. Semantic reconciliation is simply left to people to execute through their internal preferences and shared points of view, while structured information does not need to cover complex contexts, becoming more and more reusable and reliable. Latest updates from several companies developing free-form solutions for product information management is more and more encouraging pointing to an accelerated adoption in the near future. Insight into early adopters shows very elegant solutions coupled with strong 3D and visualization capabilities, XML content re-purposing and web services for in-context data retrieval. Amazingly, the technology components required are very low cost, mostly available already in many companies, while best practice governance ideas are already forming as very portable and powerful policies for information sharing and search. My recommendation is to try free-form approach using common portal technology in limited scope (such as systems requirements management, simulation data management, test and validation) and observe how the organization reacts to it.