Product Value Management

Manufacturing companies must increase throughput of differentiated profitable products in order to stay competitive. Releasing new products more often, with more features, and to more markets, requires scalable process. To increase scalability of their current development processes, manufacturers pursue various strategies - standardization, automation, mergers, or most often a combination of the three. Yet, scaling a development organization and process is not a trivial task whether a challenge is in fusing multiple organizations DNA-s or trying to replicate a single organization DNA.

This blog series analyzes approaches that global manufacturers undertake in order to transform their PLM practices into a highly mature, scalable processes that consistently provide higher throughput and higher quality of profitable new products. In the first part of this three-part blog we will discuss roles of business process architects and enterprise architects, and their contributions to clearly defining changes required, building the consensus for change and preparing feasible roadmaps. In second part, we will discuss roles of managers and senior leadership in mobilizing and motivating large scale organizations to change. Third part discusses possibilities of deploying a comprehensive integrated framework (methodology and tools) for continual PLM transformation.

Many companies that we analyzed do not have business process architects per se. They usually have some sort of process standards and standard documentation administrators, but by and large people in charge of the process definition do not feel responsible for continuously evaluating process performance and coming out with ideas for improvement. They are also rarely in situations to influence discussions on business strategies that may result in requirements for process changes. Here is a summary of findings regarding PLM process management covering 21 manufacturing companies:

The table represents percentage of companies at specific level of process management practices described in the left column.

Not surprisingly, where business process architects are assigned to the PLM domain with a clear objective to aid in evaluating processes and possibilities for improvement, results are much more attainable and consensus for change easier to develop. In order to provide more value, business process architects have to evolve their process management framework to the level defined by lowest row in table above. Only two of the companies reviewed have reached this level though. We will discuss later what needs to be done to improve this situation.

Once business process architects develop solid understanding of the changes that can help improve process performance, they need to communicate them to the enterprise architects whenever (re)deployment of information technology and other organizational capabilities may be required. Enterprise architects develop solution direction, and establish a spectrum of possibilities for which they have to compare returns on investment and total costs. Planning a solution implementation always involves third party vendors and integration specialists, imposing another spectrum of communication rules and policies.

Here is a summary of findings regarding PLM solution planning and deployment covering same 21 manufacturing companies:

Nearly seventy percent of the companies observed have reached the conclusion that they are better off by sharing and reusing solution elements and clearly communicating process flows and interfaces. However, very few have developed a comprehensive model based environment for fast configuration and deployment of PLM solutions. Although it is good to have requirements documented and agreed to by all, it is far more effective to directly map business process configurations to services that can be reused and reconfigured for a global coverage, because PLM processes need to change fast and broadly, while large PLM solution implementations may take several years to accomplish.

To be able to match business needs and strategies with better processes on a global scale, companies are much better served by assigning dedicated business process architects and enterprise architects to PLM domain. Let’s define these two roles’ basic responsibilities:

- PLM business process architects are responsible for defining and maintaining process definition in a form that enables:
a) configuration, planning, execution and monitoring of development projects by program and functional managers using standard definitions of tasks, dependencies and metrics;
b) continual evaluation of process performance by process analysts, fast determination of root causes for performance degradation and fast establishment of the consensus for changes required to improve, standardize and replicate the process.

Business process architects are also responsible for communicating changes required to enterprise architects in a form that can be easily mapped into the models for solution definition, configuration and deployment.

- PLM enterprise architects are responsible for:
a) determining a spectrum of feasible solutions to the transformation requirements,
b) selection of solution(s) that best match requirements and have highest return on investment,
c) planning of a successive series of implementation projects to gradually transform the business process to the desired state.

Obviously, both PLM business architects and PLM enterprise architects depend on clear communications, process design and evaluation techniques. It is not accidental that companies that practice at highest levels of maturity, have adopted integrated model based frameworks covering the needs of both business and enterprise architects.

Although, very often, the tools deployed in practice to support architectural frameworks do not match the needs of PLM, model based approach is more productive that traditional BPR. We have written in several previous blogs about how to select the most appropriate tools for the PLM transformation framework. Business process architects need to select their methodology first and then decide what kind of tools are best suited for their work. While many established methods offer good support for specific steps in transformation, it is most important for the business architects to use them only when appropriate. In fact, we recommend that Lean, Six Sigma, Systems Engineering and other methods be subdued in the overall framework and only used as they address the deliverables required. For example, it is far more productive to quickly determine the true value stream and identify and discuss all opportunities to better synchronize decisions, then to dwell for months over Lean philosophies and “workshop people to death” with theoretical considerations. Customers can care less if you have used Lean or not for as long as you establish quickly a consensus for change that is going to result in significant reduction of wasted effort. That is why it is more important to hire as business process architects, those professionals who can clearly communicate in language of engineers and managers, and are driven by passion to find a way to improve process, then to choose from certified purveyors of theories that have no established practical use in your company. In other words, best business process architects will not hide behind their methods and techniques hoping that by miracle everyone else somehow does their job, they will use what it takes to deliver on improvements, following the mantra that “it is the craftsman not his toolbox that matters”.

Enterprise architects in PLM face much broader and more complex environment than in many other areas of business. They need to to be well versed in large complex information models, ontology oriented master data management, and open-ended rule based iterative workflows. Above all, they have to be fully open minded to a spectrum of possibilities, including not having a preferred vendor and preferred platform before the needs are fully defined. Best enterprise architects in the area of PLM are those that achieve simplicity not by limiting vendor and platform choices, but by limiting number of permutations of doing the same process sequence. Their ingenuity is in recognizing patterns of process sequences and clear understanding of how to commonize and reuse information models to achieve flexible, yet very normalized process services library. Best enterprise architects are not those that can explain to their internal end users what can vendor solutions do for them, but those that can persuade vendors to quickly improve on what they don’t do or cannot do well.

Overall, companies that adopt best practices in PLM transformation achieve speed and scalability ahead of their competitors, providing for another competitive advantage on a long run. Hiring best suited business process architects and enterprise architects for the PLM domain is just one step in the right direction. Enabling them with an integrated complete framework for managing transformations is the best second step to do. In the next blog we will cover the role of other participants - senior executives, managers and engineers.

When enterprise architects are approached by business stakeholders to help improve business process, in most cases they have to come up with some creative use of information management solutions. Today, there are two basic paradigms that they can base their solution design on. One is application software, and the other is SOA. Both require methods and tools to establish a business solution. And these methods are very different.

Increasingly, enterprise architects find themselves very reluctant to resort to using additional application software, since in many cases they have reached saturation point where adding another application makes processes more confusing and less efficient due to overlaps and difficulties of normalizing business semantics. Many companies today have reached the saturation point with applications. To these companies SOA is and should be a very promising concept. It says that one can increase process automation coverage by reusing already established capabilities. It also says that changing and reconfiguring processes can be technically done much faster and with much less cost. It also uses business needs to drive solutions not the other way around. As much as SOA makes sense, it’s lack of wider adoption does not. What is making SOA difficult to practice? According to my recent discussions with nearly a dozen of early adopters, the main culprit is in misalignment of methodologies. Enterprise architects simply resort to the methods they have been familiar with for many years - exactly those that fit well application software paradigm, the one that they are trying to replace. EA-s still follow frameworks well tuned for business process re-engineering and packaged application implementations. They simply do not come across well defined methods for SOA paradigm right now. Yet, few that did well with SOA and are quite happy with early adoption results, report that such methods have been established already in their companies. Except, in other area of business. Where did they find these methods?

Modular system architecture is intuitively familiar concept to product designers and engineers. Just like products, business processes undergo conceptual design, detailed engineering, prototyping, test and validation, first release, ramp-up and full scale roll-out to the end users. It is very critical to reduce cycle times, control budgets and achieve first time quality of products, so is the case with business processes and information management solutions.

Over many years of practice, product design engineers have adopted sophisticated models to represent mathematically (some would say virtually or digitally) complex products that need to satisfy a range of requirements of end users, manufacturers and distributors. Using model-based design and simulation, product architects turn cross-disciplinary knowledge into innovation. By expanding their models to capture more requirements, design and manufacturing rules at increasingly deeper detail, engineers rely less on physical prototypes, are able to clarify requirements early, avoid costly mistakes and explore wider spectrum of alternatives to further enhance product performance, quality and reduce costs. As a result, lengthy change management cycles at later stages of product and process design are eliminated and resources spent on rework can be redirected into increased throughput of new features. Suffice to say, in an increasingly competitive manufacturing arena, model based design and engineering becomes strategic source of sustainable market differentiation.

No other area of product development has this approach as evolved as mechatronics. In mechatronics, we represent entire system of elements using virtual models to evaluate system responses to usage, production and service conditions. That way, design engineers can eliminate some and fine tune other design concepts through series of adjustments until all user requirements are satisfied and designs meet all other business criteria. Furthermore, same models can be used for synthesizing detailed design artifacts such as embedded software code and logical and physical layouts, supporting a complete design process within model based paradigm.

Creative enterprise architects intuitively recognize benefits of model based approach, and use same principles when they have to design and engineer business processes. In their approach, organization is a system comprised of functional elements that interact through interfaces and can be configured to satisfy a range of requirements. Business process is then represented by models that allow validation of various configurations, working conditions and responses to those conditions. Variability of performance metrics to variances of inputs can be analyzed to optimize design of business processes. Thus, resulting set of configurations satisfies full spectrum of requirements of the end customers, is robust to disturbances and is designed to operate within desired metrics. Furthermore, these process models can generate very detailed specifications for implementation of information management systems (functional capabilities, data interfaces, process flow logic, etc).

So, why is it that enterprise architecture largely remains oblivious to these principles? We are still witnessing document based frameworks, proliferating drawings (maps) of process flows, often depicting a severely limited set of configurations, that cannot be used for any analyses or simulations, never to mention self-generation of implementation artifacts. As if business processes do not change often enough to require fast and accurate response. Lack of model based enterprise architecture techniques and methods is a main culprit for slow adoption of SOA, otherwise a very promising paradigm of business automation.

Mechatronics system architects have abandoned drafting boards and have reduced dependency on physical prototypes. They have developed models for simulation and analysis of key requirements. They reuse standard interfaces and common components. They have developed methods for managing user options and configurations. They have parts management systems. They can evaluate critical parameters to make architectural trade-offs… Enterprise architects are still drafting, they are still struggling to make lists of parts and generate part numbering schema for standardization and reuse. They communicate using unstructured documents and slides. They are not sure what performance metrics to use for evaluating alternatives…

I have a recommendation to EA-s who rightfully have reached conclusion that SOA is superior to application chaining, but have been frustrated to date with the lack of sound methods. Spend some time working with product, particularly mechatronics architects, and ask them how would they develop a solution starting with a given set of requirements. Look how they model product functions based on requirements, how they reuse these functions, represent complex configurations, measure and evaluate system responses, and apply components standardization and architectural modularization. Then apply these principles to modeling your organization, organizational functions, standard interfaces, operational metrics, process configurations, rules, roles, … Simply, stop drafting, start modeling and many useful principles of SOA will fall into place. Take a look at reference models delivered by non-for-profit Value Chain Group http://www.value-chain.org. Their VRM and SOA-IM reference models are an excellent catalyst to jump start your model based enterprise architecture 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.

In theory of optimization, simplest formulation of the problem consists of a goal (or objective) function, variable parameter(s) within that function for which we want to find optimal values, criteria defining side effects of the goal function being of certain value and constraint(s) that tie parameter(s) to unavoidable limitations. Normally, there are multiple feasible solutions (combinations of parameters’ values satisfying limiting constraints), offering a spectrum of values of the goal function accompanied with a set of values for criteria. Optimal solution is one that defines feasible combination of parameters that gives maximum (or minimum) value of the goal function within an acceptable range of values for criteria. Hence, there is always a trade-off involved between different criteria that come along maximization or minimization of the goal. Obviously, changing constraints and/or relaxing criteria leads to different set of parameters’ values that define optimal solution.

Why this theoretical background? Simply because, it is then obvious that optimal customer solution is very different when we deal with already designed product, and when we deal with multitude of alternatives that have yet to be designed. When optimizing supply chains, our constraints are already put in place during design of the product providing for a limited set of feasible solutions and allowing us to consider simple goal functions with just few criteria (let’s say minimize delivery time with lowest possible cost of transportation and limited inventory). Over-constraining makes optimization simpler, but at the same time, reduces our chances to truly optimize value to customers. In supply chain optimization, value of product to customers is approximated by aggregate forecasts with several pricing scenarios tied to projected volume of demand. We then trade-off between availability of the product to customer, production resources allocation (capacity and materials) and cost of delivery (inventory and logistics). Often, for any given demand and warranted delivery terms, the only two parameters that we can really play with are capacity and inventory.

In product development, we have to maximize utility of products to customers while minimizing cost of materials and production assets required. Demand is then not an aggregate probabilistic volume/pricing curve, but a complex goal function dependent on a spectrum of possible value propositions estimated with much more uncertainty (let’s say a set of innovative features we have never designed before). The problem is very different and consequently our approach to optimization. Nevertheless, certain techniques are interchangeable (e.g. simulating using genetic algorithms within a set of pre-textured feasible solutions).

This would not be much of a problem if each discipline carried well divided responsibilities - design and engineering optimize utility (aesthetics, ergonomics, performance, functionality, quality, direct costs), and supply chain optimizes availability and production assets utilization (capacity and inventory). This was the case when planning horizons between the two areas of responsibility were much apart and of different order of magnitude (e.g. product development cycle was three years, while materials and capacity planning cycle was three months). Today, with accelerated shrinking of development cycles and profitable product life cycles, the situation is much different - with the two horizons not only converging into a single horizon, but planning cycles being virtually of the same order of magnitude. Picture below illustrates the point.

View image
Let’s discuss the picture for a moment. Three immediate conclusions come to mind:

1. Product introduction horizon (the time horizon for which product development resources need to be allocated to the portfolio of new products) is now of same duration as materials and capacity planning horizon (the time horizon for which materials and capacity are allocated to production).

2. Product development cycle (how frequently a new product is released to markets) is the order of magnitude of the materials and capacity master planning cycle (how frequently are key material and capacity constraints aligned with the changes in demand forecast). Thus, it is not uncommon that within a single product development cycle, master resources plan is done only once.

3. The overlap between the two horizons can cover an entire master planning cycle, e.g. production resources plan must be created well before the product design has been finalized, and then often changed immediately after launch.

It follows that demand forecast used for planning product introductions has to be the same one used for planning materials and capacities. Hence, if we know what target markets (competitive acceptance, volumes, prices, options, …) we need to maximize flow of new products to, we have actually determined our demand forecast. It does not make sense to double guess demand once we start planning allocations of materials and capacities, when we have already justified allocating development resources on designing for a specific set of requirements (features, volumes, costs, …) including targeted demand. Things will not change much since the two planning cycles are firmly within same horizon and with overlapping cycle times. Even if changes happened, they would rather be within acceptable tolerance from originally assessed market acceptance of the new product.

This new reality requires a a new planning paradigm - value flow management. Not unlike demand flow management, in value flow management, a common planning horizon is divided into time fences of different granularity within which planning decisions progress from more degrees of freedom (less constraints) to more constrained trade-offs. Unlike demand flow management, value flow management deals with both supply to demand matching, as well as product features to customer value matching. Herein, value is tied to demand. Picture below illustrates this paradigm.

View image
In a summary, value flow management is constrained based planning method used to maximize flow of value to customers, and product margin to the manufacturer by leveraging innovation to limit fluctuations of materials flows and assets utilization.

In value flow management, product development fully integrates with supply chain management to optimize both development and production resources. Single (or synchronized) demand plan is derived from a well targeted value proposition to determine pricing and production volume that will keep materials and capacities within a steady takt with minimal change to both product development and production plans. For as long as there is significant innovation leverage in the product, demand is driven by elastic pricing, keeping supply chain operating within targeted (plus/minus tolerance of the materials flow fluctuation) adaptability. Thus, plans can be optimized early, products developed to match targeted value proposition and then produced within predetermined steady takt that warrants minimum inventory and maximum capacity utilization. When the product life cycle within the targeted product margin and volume production cannot be further extended by reduced pricing, that product has lost its innovation leverage (differentiation to competition) and a due replacement must be timely planned within the portfolio of products.

Value flow management thus eliminates the need for forecasting of demand beyond the final determination of targeted value proposition. In other words, if we are smart enough to allocate development resources based on specific market needs and pricing, why would we start double guessing our business case within the same time horizon for which we have already planned assets. We can decide to stop development though before major costs have been committed, however once past the launch time fence all our capacity and material constraints have to be within tolerance of the profit margin that warrants manufacturing of targeted volume. Forecasting thus gets replaced with intelligent requirements management, whereby requirements need to cover all aspects of business planning and life cycle value proposition from idea to the end of life. Our design decisions need to be postponed until requirements have been fully evaluated, and then fast product integration needs to bring everyone on the same page around the targeted value proposition. The decisions thus get elevated to the portfolio level where multiple scenarios need to be planned for, and changes in plans are made before they have expensive impact on resources in development and production. Development and supply chain have thus been finally merged into a common phase-gate decision model with common planning horizon, total enterprise resource and assets allocations (development and production budgets), and integrated value and demand planning to fully reconcile innovation push with market pull.

Value flow management is applicable to all consumer driven industries - from high-tech, semiconductor, consumer electronics, passenger vehicles, commercial airplanes and consumer packaged goods, where cycles of product development and supply chain planning have converged to market driven takts (e.g. it takes 12 months to develop a yearly vehicle model). The entire planning method centers around two parameters - innovation leverage obtained by creative development and adaptability of the supply chain to match dynamically adjusted pricing with a steady flow of materials (within targeted plus/minus adaptability). Strategies like reuse, virtual manufacturing, simulation based robust design and collaborative portfolio and requirements management play major role in our ability to practice value flow management.

This method firmly positions responsibility for product success to collaborative effort between value creators and value deliverers. The trade-offs associated with this very lean approach to planning (like with any other lean technique) are in favoring our ability to maximize use of knowledge and business intelligence over our ability to react to unpredicted changes in market conditions. I leave it up to discussions if this is better approach for global manufacturers than traditional planning of demand flow decoupled from innovation flow. In the meantime think how and why can Apple justify slashing price of the iPhone by nearly 40%?

If you decide to pursue an ontology based solution to your product definition management, governance of such a solution becomes critical for two basic reasons:

1. Ontology is managed by a community of architects in a federated manner. These architects will need to know how to get benefits from the ontology for their own data reconciliation needs and how to use the ontology to maintain semantic convergence as strong as possible.
2. Integrity of data reconciled by the ontology depends on policies that are flexible in design, yet strictly administered for all registered users and data exchange protocols. That way, run time execution of various read and write calls between systems and users follows best possible choices between all authors and consumers of information.

Thus, governance of an ontology based solution must contain at minimum two major sections, (aside from general security and performance related guidelines that are common to most service oriented approaches and not specific to ontology based solutions). First section deals with managing content of the ontology - what is in it, how to expand it, how to promote new elements, how to retire old elements, who are custodians of different sections in the ontology, how the request and approval of changes needs to be administered, etc. Second section describes guidelines for run time, contextual reconciliation of data - how to register XML schemas, how to link entities to informational references, how to define read/write policy, how to execute read/write policy, etc.

To best understand what goes into what section, let’s use an example of a simple ontology and its few simple uses for data reconciliation (I like this example because it illustrates basic concepts that can be easily enhanced for more elaborate information reconciliation cases). Our ontology contains three basic entities registered as extrinsic objects: Requirement, Function and Performance Parameter.

Naturally, these basic entities have their attributes (slots) and other entities associated with them (grayed out in the picture above). Similar examples could have been followed had we chosen a Product, Customer, Issue relationships. This approach is not unique to any specific area of product development or supply chain management.

Let’s suppose that three data architects are custodians of three solutions (requirements management, functional decomposition management and simulation and analysis management). They happened to have implemented three distinct applications for each of the three areas. Each application has some notion of entities in the ontology. For example, functional decomposition application offers a hierarchical multi-leveled functional breakdown, but really only ties functions to “committed” requirements that they satisfy, not offering information on status change of requirements, their sources, use cases, contracts with customers that originated the requirement, etc. Requirements management application provides full support for life cycle management of each requirement, their grouping, common sources, reuse and re-purposing, etc. However, it cannot point to a set of test and simulation models required to validate the requirement feasibility, performance trade-off or cost. And so on, the understanding of coverage of the ontology can be documented by three architects and their respective ideas of what should be in the ontology can be shared until a common model arises. Gradually, a memorandum of the ontology content, who owns what section and how will each section be changed in the future emerges. Formalizing the memorandum of ontology maintenance and enhancement and documenting its content helps other users who may want to reconcile their information in the future.

Once the governance for maintaining ontology in the registry and repository is established, each architect can populate their section and establish their respective XML schemas for data reconciliations. For example, architect of functional decomposition management solution decides to represent in his/her XML meta-schema many-to-many relationship between requirements and functions, and wants to have use cases tied to requirements. That way, if any change of functional definitions and decomposition happens to take place, a broadcast message to the registry can be sent to set informational references pointing to the new versions of the data. In a similar fashion, if there is any new instance or a new version in the registry of any requirement or a use case, the informational references to the new data will be sent to the specified users and they will decide if they want to pull the change into their system or not. That now brings us to the second part of the governance - contextual reconciliation of data.

To implement the desired logic described above, our architect needs to follow a set of guidelines for establishing the flow of events that will result in full reconciliation of information between requirements management system and functional decomposition management system. Three sets of guidelines are typically used here:

1. Entity read-write policy. This set of guidelines determines what systems and users can instantiate new and change informational references to the registered version of the entity, and what systems and users can only read the informational references.

2. Versioning policy. This policy determines which of the entities will have every version of each informational reference for each instance captured in the registry. often, only informational reference to the last version is kept. However, it happens that some entities are associated with version controlled information in at least one system that needs to be reconciled.

3. Persistence policy. This policy specifies what content associated with each informational reference version controlled in the registry will be stored in the repository. Sometimes, registry and repository combined can act as a data mart to immediately pass the data between applications, if persistence is enabled for specific fields within or entire document types used as information references.

Combinations of these three policies may result in a set of possibilities:

Simplest: one system writes, others can retrieve only the latest version of the data accessed through available informational reference instance (a document specifying web service to obtain the data),
….
Most elaborate: multiple systems can read and write, some of them accessing the latest version that their system wrote, others using the latest available that any system wrote, and some using latest available that specific system wrote, all while persisting specific values directly in the repository and taking persisted values rather than referenced web service to access the data in other system.

Thus, a spectrum of policies supports various situations of information reconciliation. In addition to these policies, a set of security, digital signature and other general policies can be specified.

Once a full access policy is configured, required XML schema content can be created. Last step that architects need to define is sequence of events that will lead to desired information reconciliation. Most events are generated by simple triggers representing specific data being created or changed. These events can lead to automatic execution of protocols for data exchange if the policy specifies that. However, often, a set of logically connected events may be required to justify logic for reconciliation. In that case, architects need to establish flow of events that will lead to desired outcome. This can be done in multiple languages, CPID being most comprehensive for several reasons described in the blog here: http://cpd-associates.com/blog/pvm/2007/08/bpm_in_plm_modeling_language_t_1.html
However, this would require that all components of the extended reference architecture be available (see previous blog: http://cpd-associates.com/blog/pvm/2007/09/how_practical_are_product_defi_2.html

A complete check if adequate run time governance has been fully applied will require answers to similar questions:

- What system(s) can read and write specific entities and using what informational reference document types (XML schemas)? How will different versions of an entity be used: read latest whoever wrote, read my latest of read latest from a specific system? Will any data be persisted in the repository available for direct upload? Will all required informational reference documents be available for exchanging the data through the gateway? How will the sequence of reconciliation events go between systems and people: change alert - change review - change upload?

Often, architects can use administrative console that will list next to each entity how many XML schemas are associated with it, who registered them, how many versions of each instance have been generated, by what system using what XML schema, what documents and active data in the repository is available for this entity, etc. Various usage reports can be generated on demand, and they could be good indicator of semantic value of the ontology.

This blog concludes the three-part series. I tried at a high level to bring closer the ontology based solutions for product definition and their way of working. Ontology based solutions are generally better solutions then direct meta-mappings, but should be tested and tried in all aspects of governance and performance to establish a working solution. Then, they gradually grow to cover more complex cases of product development information reconciliation. It is not uncommon to find few dozens of applications in product development space that may require reconciliation of information. Benefits of fast and accurate change propagation and information reconciliation cannot be stressed enough, it is up to us to bring better solutions with each new generation of technology. Service oriented solutions and loosely coupled ontology based integrations are such an opportunity in the immediate future.

Accelerated product complexity drives a need for structured, intelligent product definitions to support various aspects of product planning, design, manufacturing and service. These definitions (often very sophisticated in their coverage and depth of relational detail available) enable rapid search, retrieval, analysis and re-purposing of product related information with the aim to support more precise design trade-offs, speed up cross-functional communications, and increase reuse of proven solutions. However, when various product definition constructs evolve without much regard for each other, efforts can result in detrimental divergence from the overall goal. At the same time, overly simplistic standardization of product definition constructs can cause constant leak of product related knowledge, duplication of efforts and costly manual fixing of errors in product data. This problem is not new. CPDA (and formerly DHBA) has applied significant resources to researching the problem and solutions of product definition management, releasing series of materials along the way, culminating in the work of Wayne Collier and Gahl Berkooz internally dubbed “12-Fold Way” product definition framework. (see link here http://cpd-associates.com/index.cfm?content=subpage&file=include_RPPage.cfm&ID=102&DOC=137651120

Recently, much has been done in conceptualizing various advanced constructs to enable at least targeted subsets of the product definition reconciliation scope prescribed by the “12-Fold Way” framework. Shared representations have been developed for generic physical architectures reconciling 3D part designs with configurable engineering BOM-s. Also, generic feature architectures have been deployed to reconcile definable sales configurations with pick to order and assemble to order manufacturing BOM-s. While these advances solve particular product definition reconciliation problems, they can be implemented in a variety of information management architectural approaches. Two conceptual approaches come to mind: meta-schema mappings and ontologies.

Meta-schema mappings apply data-model to data-model mapping rules, providing for direct reconciliation of each common entity, attribute and association defined in each data model meta-schema. Thus, a cross-section of two data-models at a time is reconciled applying programmed data translation, transformation rules and transport protocols. Often, if more then two data models need to be reconciled, one of the models needs to be claimed as a master model that others will have to be reconciled against. This is common approach in strategic sourcing (for example Explore technology originally developed by Aspect Technologies) enabling roll-up of spend categories across multiple procurement systems.

In ontologies, a superset of product definition attributes is described independently of any data-model that may have to be reconciled. The entire ontology is then stored in a registry where it can be examined, evaluated and used for referencing content stored in various independent data models. Thus, a reference can be placed on any intrinsic or extrinsic entity, its slots (attributes) and associations, annotating where and in what specific format a structured data representation (an object or a table) is available for a subset of the ontology. Consequently, one ontology can be referenced by multiple meta-schemas, providing clues for how can they be reconciled when the needs arise. Cross-sections of different independently stored product related data representations can then be easily observed and analyzed with the aim to define applicable policies for data reconciliation via a version control enabled registry (more about these mechanisms in the Part 2). This is common approach in service oriented registry and repository deployments for federated content management (for example ebXML Registry and Repository developed by Semantion).

What are differences between the two approaches, and what criteria should be used to determine which one is more beneficial for any given situation?

1. Integrity of data reconciliation. In meta-schema mapping, information integrity is guaranteed by explicit rules of mapping of each attribute and association between reconciled data-models. This enables high degree of integrity. In ontology, the integrity of information is dependent on understanding of the meaning of each declared entity, slot and association (often called semantic value). Often, this may result in semantic divergence if different architects interpret the meanings of the ontology differently and claim their informational references without discussing their respective use cases. Weak semantic affinity may cause degradation of information integrity if subjective interpretations are not prevented by governance rules within the architectural community that has rights to place informational references.

2. Scope and flexibility of coverage. Meta-schema mapping works on the principle of cross-section, e.g. a common subset of data-models coverage for which direct reconciliation rule can be established. In ontology, a superset of all definitions can be established without having to worry in advance how will respective data repositories interpret the meanings. However, ontology will evolve over time, becoming semantically richer with each new reference. Thus,as a special case, ontology can “behave” as a meta-schema mapping if strict rules for allowing only strong semantic affinity references are applied from the beginning.

3. Scalability and maintenance. Meta-schema mapping is a high maintenance endeavor. Particularly when multiple data models need to be reconciled, all while evolving in their respective coverage. Restrictive meta-schema mappings defy the purpose quickly, while too broad coverage can bring the entire approach to its knees if rapid changes are required too often. Ontologies are very friendly when it comes to maintenance. They can be as scalable as meta-schema mappings when it comes to performance (a number of data reconciliation requests processed in a unit of time). Their main advantage comes from federated maintenance and concept of loosely coupled informational references that can be used on as needed basis.

In general, ontologies are more applicable to reconciling knowledge intensive aspects of product definition stored across many information repositories (requirements, system models, functional models, use cases, trade-off studies,…), while meta-schemas mappings are more applicable to transactional aspects of product definitions stored in few information repositories (sourcing BOM-s, manufacturing BOM-s, service BOM-s). Ontologies can also be better choice for cross-referencing transactional information to conceptual design information to facilitate reuse. Another important dimension is centralization of the information model management. In a more federated environments (multiple domain architects collaborating on process integration) ontologies are better choice. In a more centralized architectural organization, meta-schema mappings can appear as a more natural choice. However, when making the decision, we strongly recommend that a good analysis of the starting point of coverage, flexibility required and maintenance overhead considerations be made. Knowing that very little structured product information coverage is available in many companies, I predict that ontologies will gradually overtake the product definition reconciliation space.

In the next part, I will describe in more details various technical aspects of data reconciliation and governance policies when using ontologies, and contrast them to meta-schema mapping approach. Stay tuned….

Several years ago, I visited a global manufacturer to facilitate a workshop on semantic framework for enterprise architecture. With a dozen of architects from various disciplines attending, one of senior PLM architects shared an overview of their experience with several architectural frameworks and how his understanding of the business needs evolved while using these frameworks. In short, he divided the architectural frameworks according to two dimensions:

1. Focus - The frameworks were either assets focused or process focused. Assets focused frameworks were very good in providing guidelines, governance and techniques for managing IT assets. They were useful for categorizing and classifying various IT assets and relating them to each other - from infrastructure to applications. They were not that useful in defining processes at the required level of detail for driving business transformation. Process focused frameworks were much more demanding when it comes to defining processes within the enterprise and describing how those processes interact to deliver value. They were not that useful in mapping processes to a full stack of IT assets to enable consolidation of requirements and specifications for implementation.

2. Deliverables - As second dimension, he used the notion of what kind of knowledge capture the framework enables. Document based were frameworks that only specify what deliverables need to be created, and what various deliverables need to contain - e.g. process flow diagrams, functional requirements, return on investment calculations, etc. Model based are frameworks that specify what kind of models need to be delivered at each step in the methodology, and how to reconcile and reuse these models across the entire spectrum of architectural, solution design and implementation efforts.

And then he listed examples. Zachman was a good example of assets focused - document based framework, TOGAF, DoDAF, were examples of process focused - document based frameworks… etc. The one that he was missing to make an example of, was a process focused, model based framework. And that exactly was his point for the need of semantic framework - business process transformation in PLM domain requires process focused, model based architecture framework. My immediate question was - Why did he conclude that? Even though I did get a very satisfying, qualified answer, I understand that point of view much better now than then.

First of all, let’s start with assets. Corporate assets that PLM predominantly deals with are brand and knowledge. Both are crucial for strategic differentiation of any manufacturer. Yet, they are very unrelated to the IT assets, despite the fact that we can easily point out to various data elements that offer a remote notion of knowledge (like some test results and requirements trees) and some notion of brand (like some logo graphics files). However, brand and knowledge are overarching synergistic assets that are results of efforts of many creative people working together, honing them over a long period of time. I asked once one senior product development leader in a large manufacturing company, if loosing all their PLM data currently captured by systems, would be a show-stopper for a new - not yet conceived development program? The question did provoke a somewhat longer pause in our conversation. “Absolutely not,” he claimed…”it may slow us down in some tasks. Then again, when I think of it in all aspects, it may also provide an opportunity to gain some velocity… You have to realize that the only sustainable differentiators in our industry, when it comes to product development, are creativity and intelligent collaboration. And our people are very good at both.” As our PLM architect pointed out - an assets focused enterprise architecture framework would not relate much to the current business needs in PLM. Even though, it is still probably the most appealing framework when it comes to explaining to executives the entire inventory of items that consume mighty IT budgets. For meaningful business transformation, PLM requires a process focused architectural framework - one way or another.

Frameworks define deliverables that, when part of a well conceived business transformation methodology, help us communicate and tie together strategies, tactical objectives, change requirements, solution designs, functional capabilities, business benefits, technology roadmaps and implementation options, cost and return ratios, bill of changes, detailed interface specs, etc. These documents can be rich in detail and precise in content, however, if just documents, they cannot be nearly as dynamic as the PLM processes are. When I managed methods and tools for product development in a semiconductor company, I was stunned with the speed of change. I’d noticed that the half-life of a most stable process flow in value creation domain was about six months - before it has to morph into something very different. This “continuously morphing product development process” phenomenon has been recently observed in all manufacturing verticals that serve consumer markets (from passenger airplanes and cars to electronics gadgets and apparel). The consequence is that an entire flow down of logically connected PLM architectural documents may become obsolete by the time the solution is ready for implementation. The frustration will prompt PLM architects to actually never make any of the required documents to begin with, thus inevitably engaging in what can be a drastically suboptimal response to business needs. And this is a nirvana for crafty vendors. Oops, we’re then back to the assets focused approach, aren’t we?. “That data we can store in SAP, this function we can do in UGS…” PLM architect then becomes an arbitrary guardian of elusive tool standards usually selecting what is least disruptive to business, not what is most beneficial for the strategic differentiation. It is a disheartening situation - management of brand, knowledge, that can wait - maybe we should even delete a big chunk of PLM data from time to time to regain some lost velocity.

PLM and EA can be “friends”, if EA provides a framework with a set of modeling guidelines and techniques that capture PLM processes as detail rich models that provide executable process definitions across a common information model defining the entire spectrum of PLM data. PLM and EA will appear as “foes”, if EA only provides for a set of documents that PLM architects need to populate as solution design and implementation requirements artifacts, all while knowing that the time it takes to fully define all of the required design artifacts may have to be longer than the half-life of the processes defined within them. When EA proposes a process focused document based framework to PLM, they are essentially pushing it back to the assets focused approach. And then, the PLM architects look less mature and less advanced when it comes to processes than other enterprise architects who address much more stable, more repeatable, usually transactional process flows.

It is not uncommon to find PLM architects who then start developing their “mini” EA frameworks to address the specifics of the processes they need to support. A process focused, model based architectural framework for PLM transformation often arises from a sheer frustration and a paradox. The paradox of having to appear as less mature, while actually knowing first hand why and how to be more mature.

When we encounter multiple “versions of truth” - we have a natural inclination to try to quickly sort out whom to believe and whom to double guess. Our preferred information sources also aspire to become exquisite “go to” places for all our information needs. However, not all sources are equally good in managing all types of information, some are closer to the action where the information is generated, others are more like second hand reporters. Then we usually end up with multiple sources, having more faith in some over others for specific information, trying to use aggregation and abstraction techniques to further streamline our information feeds and eliminate noise and distraction perpetuated by out of context data. Over time, we all develop our own techniques for information management and have our own master sources and broadcast channels.

Social approach to information sharing is dominant when it comes to business related information, too. We trust more people whom we believe and know well than any formal source of information. There is something what I call a “3Meta” effect here. First “meta” comes from our selection of trusted sources. These can be people, selected official channels and systems. Second (middle) meta comes from our belief that these people or systems indeed have access to the best possible information. Third meta is our final recognition that the information is in fact exactly what we are looking for. Database designers and application architects deal with the third meta only. They design and maintain meta-schema that define the values, meaning and association of different data elements stored in information repositories, and they consider use cases of immediate users of the database and application. System integration architects control the second (middle) meta, providing rules for data distribution between systems and for security of access to the information. First meta is not formally managed. It is a fluid set of preferences that we all establish for ourselves based on our own experience and under some influence by others.

Here is the most dominant information management cultural phenomenon: the more widely used the information the more important the first meta (who are you getting it from), the more specific the information the more important the third meta (how is it stored in the information repository). In other words, we tend to entrust systems (generally better equipped then people to manage large amounts of complex information) with more mundane type of data, leaving key bodies of critical and widely shared information and corporate knowledge to the social network and much less formal information management practice. This cultural phenomenon becomes very significant when we take into consideration growth and constant morphing of business processes and supporting information systems.

As a natural bridging point, we then try to address the “middle meta”. This is commonly called master data management, e.g. establishment of rules and guidelines for the life cycle of critical shared information. These rules can be who can create data, who can access, who can change and modify, how to name it, how and where to store it, how to retrieve it, and so on. On average, I found several dozens of attributes defining various aspects of managing master data. And they often cover only transactional information (orders, customer billing and shipping info, resources, logistics, inventory, product configurations, materials, production and supply chain meta-data). There are two problems with this approach to master data management:

1. It is conceptually just an extension of the application/database approach (third meta). Externalizing master data from multiple applications can cause significant release synchronization and maintenance overhead, knowing that all applications now have to adjust to the common definition and implement interfaces to the external master data registry. This approach can also reduce speed of implementation and cause degradation of performance and functionality of certain applications required to conform to the master data approach. Inevitably, this approach can work well only when fully complemented by enterprise wide process management and business architecture strategy.

2. It works only for structured and well defined data. However, most shared information that is of high value to strategic users is not conforming to any sort of structured meta-schema. Consequently, they will resort to the first meta (captured only in their brains) to organize and manage their access to the information. This way, most critical strategic processes will stay firmly detached from the middle meta layer.

With these two problems in mind, it becomes very important to establish real value of master data management using a middle-meta approach (commonly followed today by Oracle, SAP, IBM and others), considering its limited impact to corporate agility and speed, given cultural challenges and total costs associated with implementing and operating it. Current master data management approaches often only deliver (relatively minor) cost savings associated with pure administrative aspect of collecting and distributing operational meta-data. It is much more pragmatic approach to consider master data management as a part of the overall strategy for enterprise agility and adaptability, particularly in the context of overall business process architecture, service oriented architecture and more fuzzy, but often more differentiating assets (such as knowledge, brand, intellectual property).

Having considered pros and cons and ability to manage all three metas, in any global manufacturing company that develops its own products, enterprise master data focus should shift away from normalizing operational data by middle-meta, and into top down approach addressing product portfolio management, knowledge reuse and intelligent information search ontologies. Addressing first meta first, by modeling and understanding corporate social circles, patterns of decision making, abstraction levels of decision criteria and alternatives, information retrieval routines by administrative and decision support staff, security and access control, shared ontologies that executives use to communicate and make decisions, may reveal more about the true state of maturity and true needs for master data management then simply bottoms up integrating systems that can be manually reconciled with an affordable approach if the shared data is strategically assessed first.

In conclusion, be careful what you wish for when preparing for master data management. Inevitably, your master data management will hinge on your PLM architecture - from the front of portfolio management to the back of BOM release. Address all three meta layers before you determine where is the highest payback. You may be surprised to discover where should you focus first.