Product Value Management

Product development is associated with a complex network of dependencies. Exact workflow is not fully predictable, while information shared between people evolves from sketchy and scarce to very detailed, high volume packages shared in a myriad of visual and structured data formats. PLM solutions attempt to provide some order and logic in managing this vast, yet continuously morphing field of information.

On the other hand, what we know as EA (Enterprise Architecture) is concerned with similar problem at a different level. It tries to establish a consistent and practical framework for managing all digital information assets supporting the full range of activities from strategic IT assets portfolio planning to phasing out of legacy systems and applications. How do EA and PLM intersect and interact?

EA – PLM intersecting points

The figure above gives a simple concept, albeit at a very high level. PLM focus is on utilization of advanced practices that depend on human skills and knowledge to transform information and data into profitable products following specific work processes. EA focus is on supporting work processes and data exchanges with appropriate applications and interfaces that can be deployed and maintained on advanced information management systems and infrastructure. There are more elements to the left and to the right of this picture, but our main concern is with the intersections between the two domains. What we can see in the middle is business process functional architecture – or organization of work functions that processes require to transform information into designed products and that applications need to support together with interfaces to exchange data. This common intersection area common to both domains is what we need to understand better. Let us call it simply – functional architecture.

From PLM perspective, functional architecture needs to show what typical (or standard) functions are available in each processing step and what data they need or manage to provide the outputs required for the work to proceed smoothly and add value to the final outcome – a profitable product that meets end user needs. From EA perspective, functional architecture needs to show what applications provide those functions and how data is used in order to deliver required outputs at each step in the process. While PLM is then quickly turning into skills, knowledge and practices advancement, EA tries to figure out what computing assets are required and how to deploy them to deliver required scale and performance. All elements are constantly evolving and need to be considered in relationship to each other. That is the simplest high-level concept. Let us dive into more detail.

Two critical questions arise: Can functional architecture be associated with a taxonomy supporting the needs of both domains? If so, what terminology should this taxonomy follow – the language of PLM business users’ or the one of PLM solution architects? To probe an answer to these two questions let us consider a simple taxonomy with three levels of hierarchy:

• Process element (business process activity)
• Functional area (logical grouping of system functions based on common skills or common data)
• Function (a known application or system function)

To name a process element we can use business terminology, whereby each useful process element may already be governed by some business reference model (a good example would be decomposing VRM into Development XRM, see www.value-chain.org). Thus for example, one XRM process element underneath VRM’s “DP4 Create Develop Plan” could be “product portfolio planning”. That way we allow business people to organize their process areas hierarchically decomposing activities to common process “building blocks”. At this point, we may want to associate maturity criteria, metrics and rules with this process element.

To associate system functions with the process element, let us consider various information processing steps and techniques that need to be supported by information management systems. Simple examples for the functional areas associated with the “product portfolio planning” would be “portfolio definition/modeling”, “portfolio planning data acquisition” and “portfolio alternatives evaluation”. At the level of functional area, we may want to associate some specific practices and skills/resources requirements with each functional area.

So far, we have used business terminology and have defined a “hook in” for the system functionality descriptions in the functional architecture. Our example would look like:

• DP4 – Create Develop Plan (external element from VRM)
• DP4.01. Product Portfolio Planning
• SFDP4.01.01 Portfolio Definition/Modeling
• SFDP4.01.02 Portfolio Planning Data Acquisition
• SFDP4.01.03 Portfolio Alternatives Evaluation

At the third level, we decompose functional areas into individual functions for which we need to define precisely informational inputs and outputs, as well as specific performance metrics in terms of service level agreements. For example within “portfolio definition/modeling” functional area, we can list functions such as “product family tree maintenance”, or “product planning master creation”. Inputs to these types of functions could be planning BOM-s, product options configuration tables, etc. Outputs could be product family list and product family hierarchical tree or product planning master. For each function, we can associate applications and systems required to support them, while for each I/O we can associate meta-schema definitions and interfaces if the I/O requires exchange of data between multiple systems.

Our Functional architecture would now look like:

• DP4 – Create Develop Plan (external element from VRM)
• DP4.01. Product Portfolio Planning
• SFDP4.01.01 Portfolio Definition/Modeling
• SFDP4.01.01.01 Product Family Tree Maintenance
• I:
1. Product Options Configuration Tables
2. Planning BOM-s
• O:
1. Product Family List
2. Product Family Hierarchical Tree
• SFDP4.01.01.02 Product Planning Master Creation
• I:
1. Product Family Hierarchical Tree
• O:
1. Product Planning Master
• SFDP4.01.02 Portfolio Planning Data Acquisition
• SFDP4.01.03 Portfolio Alternatives Evaluation

In its simplest form, such a taxonomy could help us bridge the PLM reference model describing processes, metrics and rules of operations in the business world with the assets of computing handling functions and interfaces required to organize and manage information and the work-flow.

To answer second questions from above, we can consider that process elements, rules, metrics be defined by business users, while functions, applications and interfaces be defined by PLM solution architects. Functional areas, I/O-s, skills and resources requirements can be defined in a consensus building fashion with clear definitions that both sides may agree with.

Functional architectures provide much needed Communication Bridgeand support precise business requirements gathering for PLM solutions planning purposes and implementation roadmaps. At the same time, these architectures constantly evolve and can contain hundreds or thousands of elements at each level of the hierarchy, including I/O-s, metrics and rules. The functional architecture may govern elements used for business process modeling (BPM), as well as essential services of the service oriented architecture (SOA).

Today, many efforts are converging on the need and justification for such architecture. These efforts start from different points of view, ranging from the need to consolidate application footprint to standardization of global PLM practices. Either way, the methodology required to address business needs must rely on functional architecture as a catalyst of the convergence between EA and PLM. I have advised and witnessed recently several efforts by large global manufacturers in developing a consistent EA framework for PLM transformation. Results point to the use of standard reference models and semantic frameworks as most effective methodology.