Product Value Management

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.