Product Value Management

Body of research related to decision making in product development encompasses several key areas including:
- alternatives selection and causal chains (come from decision theory),
- product and work breakdown dependencies structure management (comes from systems engineering) and
- multi-dimensional objectives management (combines theory of optimization and value engineering).

These methods combined help engineers sort out all relevant information about design alternatives, constraints, objectives and criteria, generate applicable decision models, organize decisions into problem specific sequences to synchronize work across different groups, and perform required mathematical and physical problem solving in order to select best alternatives. A wealth of theoretical knowledge has been created in past two decades. More ambitious scholars even propose a complementary sets of techniques and methods coupled as a comprehensive decision framework. However, I find very few of design decision making principles and methods applied more broadly in management practices, even at leading manufacturing corporations. Well, that is going to change profoundly in very near future,much sooner than many would foresee. What is causing this major change in the way products are being developed? Let me back-track a bit, but you may have already guessed right - it is all about product and process complexity and our ability to manage it.

Just as an example of available theoretic work, in my doctoral thesis written in 1990/91, I offered a formula that ties a feature variation index (number of possible configurations that one feature can be delivered in, divided by the total number of combinations of all options of all features), to the probability of optimal design of that feature (e.g. number of decision sequences considered in the current plan divided by the number of all feasible decision sequences that can take place in order to design all options of that feature). In other words, one could use this ratio to judge if it is worth developing certain features and their options given the schedule and resources impact.
Back then (some twenty years ago) most of my colleagues had rightfully pointed out that no-one should bother figuring out these predictions using such a complex metrics since most development schedules only considered a handful of possible critical paths (a.k.a. what-if risk mitigation plans), and very few features involve multi-dimensional variability (e.g. require trade-off between multiple material alternatives, geometry alternatives, production process alternatives and finishing/packaging alternatives at the same time). Particularly considering that the data could not be handily retrieved (feature configurators were not common, and very few companies even heard of concurrent set based engineering and risk based critical path management - in fact, effort based critical path of point solutions was the norm). Cycle times that were acceptable to executives rarely had to match some sort of market takt. Also at that time, schedules were heftily buffered and protected by some combination of following “risk mitigation” approaches: drop a feature, increase budget, slightly compromise first production run quality. Markets were much more forgiving than today, and margin for errors were plenty given levels of product complexity. Just like the above mentioned, many other theoretical proposals for improved design decision management never gained attention of practitioners on a broader basis.

In the meantime, we witnessed an order of magnitude increase of complexity of products (from few dozen to few hundreds of configurations) and an order of magnitude decrease in margin for errors in key product development performance indicators - time, quality and cost (from tens of percents to just a few percentage points). Many factors played out at the same time to cause such drastic change - consumer segmentation and globalization of wealth, competition and sourcing were probably main drivers. Consequently, I find it much easier today than ever to talk to practitioners about design optimization, decision management, risk management, portfolio management, and other related disciplines. For example, my recent discussion with a leading manufacturer in aerospace and defense led to a conclusion that priority of their global engineering operation has to shift away from data management into decision management, all while emphasizing digital assets and knowledge reuse (that anyway play a significant role in decision management). In an ongoing wrestling match with complexity, cost, time and quality - managing decisions better, and in particular optimizing sequence of decisions, deserves unequivocal attention of executives and line managers.

Two leading efforts caught my attention. One is in electronics consumer area, and the other is in aerospace and defense area. To better understand their priorities and approaches, I talked to leading PLM strategists and architects in both companies. Here is what their approaches had in common:

- Both companies want to replace a static phase-gate deliverables based model with dynamic decision/metrics based model. Program work content and decision sequence will be configured (and re-configured upon up-front defined critical events) from a set of standard albeit very granular basic elements (what they called standard work procedures, e.g. the way things are done);
- Both companies look for sequencing of decisions using accurate dependencies structures that warrant feasible flow of tasks and decisions across all development teams;
- Both companies are struggling to define a technique for tuning feasible decision sequence (obviously there are multiple feasible sequences) into a globally synchronized (across all decisions and all teams) optimal sequence maximizing speed, feature coverage and resource utilization.

The differences are perhaps more interesting:

- Aerospace and defense company validates feasibility of the program decisions sequence by mapping it to a system breakdown information model. System breakdown and work breakdown should always match, and they use this as criteria for validating feasibility of decision sequence.
- Consumer electronics company does not perform system breakdown, but assesses feasibility of decision sequence by a functional and interface design checklist directly interrogated by product architects. They also use this process to assess variance in the schedule of key decisions.
- A&D company interviewed believes that optimization of the sequence will be achieved by partitioning a feasible decision sequence into clusters specific to changes of key requirements, thus minimizing rework and quickly executing on requirements adjustments/changes if they do happen (they were very interested in the formula I described above to help them determine impact of most complex changes even before they happen - yikes, it takes twenty years to mature some ideas to relevance),
- Consumer electronics company wants to optimize a feasible decision sequence by maximizing knowledge throughput, since new knowledge gathered early should help reduce the variance of the schedule, thus making program outcomes more predictable. This has similar effect to front-loading of work in set based concurrent engineering.

What is significant in these two cases are sizable impacts to information management and executive/operational metrics in these two companies, yet executives are fully supporting and driving these transitions. While none of the companies plans to change the way they perform basic design and engineering tasks (they were in fact relatively happy with their tools and methods for design capture, data management, concept validation, test and simulation), they both want to standardize them at a very granular level, so the process flow can be configured into a feasible sequence in a very fast and efficient manner. Naturally, deliverables based phase-gate models are not satisfying either of these two objectives: they are not granular enough to represent standard work procedures, yet are too static and arbitrary to be accepted as optimal decision sequences for specific programs. Both companies view their current phase-gate models as a stepping stone in the maturity of program management that now needs to be replaced to truly address the complexity challenge.

Another implication that is significant is that various information elements required for managing programs in such a dynamic manner are not readily available in any of the current business and product development information systems. Both companies are evaluating a number of options, gravitating towards federated registry based information management approaches, more akin to BPM/SOA solutions than to PLM applications.

Complexity will drive significant changes in coming years. Process and decision frameworks will converge to improve control of costs, schedules and quality, while information management solutions that offer decision support and dynamic process management will be sought and valued by executives and line managers. However, there is little appetite for traditional another-application-with-yet-another-database approach. Most companies have already invested significantly in their basic PLM application footprint and are happy to leave the data where the data is happy. Yet, they need to gather and evaluate locally authored data in the context of dynamic decision sequences that enable fast and accurate planning and re-planning continuously seeking optimum along main business objectives - predictability of schedules, adherence to cost targets and control of product quality from requirement to retirement. And should we mention, maximizing reuse. Vendors focusing on the PLM decision support will reap hefty rewards, while having to keep in mind that this new area is equally open for everyone - traditional engineering automation vendors, ERP vendors and new solution providers alike.

On one hand, we can be very frustrated with PLM complexity, on the other, we have to cherish its resilience to arbitrary norms and averageness. For we all know that competitive enterprise is a complex system having to act both as a creative community and as a disciplined hierarchy. With ERP, SCM and CRM all surrendering to normalization and commoditization, PLM is the last bastion in enterprise IT that defies implementation “blue prints”.

In a recent study of embedded software practices (in final publication stage), I talked to a dozen of leading aerospace and defense, automotive, industrial equipment and consumer electronics manufacturers, comparing their levels of capabilities and their approaches to project management, requirements management, system modeling and design, simulation, software implementation, verification and validation and reuse management. I came (again) across a common PLM paradox: common tools and methods in all categories of capabilities, yet very different processes.

So, how does this paradox manifest itself in mechatronics? Before summarizing it, let’s examine this situation:

You are asked to evaluate possible solutions to the following requirement: vehicle entry speed into a curve needs to be adjusted to the level that maintains “stable exit from the same curve with all wheels in contact with the driving surface” in all working tire and surface conditions.

No matter what kind of vehicle you are helping develop, you can start creating the model that will lead you to discovering what information you need for your investigation. Number of wheels, their configuration geometry, tire model (width, friction coefficient, …probably half a dozen parameters), type of surfaces in lieu with tire and road conditions (friction parameters, recession angles…another half a dozen), then vehicle mass distributions, power distribution, etc. And as you get through mechanical stuff (few dozens of design parameters), you need to figure out what are the proper control model variables (input parameters, control function, output parameters) and where are they coming from and where they need to be supplied to: How to collect reliable, most accurate, redundant real time input about the road curvature (satellite, close range, steering wheel, etc.) and vehicle configuration and working conditions (in-vehicle sensors and controls), how to send output variables to control units managing power transmission, throttle and fuel supply system, and how can they act upon the right variable, how to maintain all signals integrity, redundance, timing, etc.

Now, this all sounds common no matter what kind of vehicle are you helping develop. Modeling is a great engineering task creative system engineers love the most Your expectations from tools helping you define, store and share the models, collect proper information, simulate, analyze, change model when other design dependencies change and so on - is legitimately straight forward. And in most competitive organizations you will get the best tools for this. Where is then the paradox?

Let’s say you are developing a military vehicle. Your starting point is sorting through information in well documented and managed requirements, courtesy of your only customer caring to have all bidders equally favored with the chance to win over the design. You will realize that some required information is not supplied, but you may also count on initiating inquiries and asking for changes, all with a version controlled definition of almost all critical parameters. Minimize assumptions and capture all concerns.

If you are developing a commercial vehicle (let’s say this feature is related to an important operating mode for safety and economy of a class of heavy transportation vehicles driven on well documented and mapped out commercial highways), you may not have a luxury of having all requirements well documented and managed, but you may have very good idea where to get very good data for your starting models and information from previous development programs. Capture all assumptions and minimize concerns.

Herein lies the paradox: Work in one of these environments for significant part of your career and you will find it very difficult to become efficient in the other one, even if you can use exactly same tools for modeling, simulation and change management, and your systems engineering genius is equally welcome.

What does it mean to mechatronics? Clearly, after talking to all of corporations we assessed, priorities and needs differ. So do the benefits. Consequently, we believe that adoption framework for mechatronics needs to be different in different industries. For example, to gain maximum benefit from an integrated solution for system modeling and simulation in DoD environment, change-controlled requirements management is a pre-requisite. In automotive, to adopt same solution, requirements management can help, but only if it facilitates reuse of information, and not just collection of documents. A truly industry neutral requirements management solution would have to be based on system ontology supporting requirements, as well as functional, operational and architectural system views, offering users their own starting point in the process and their own flow of information dependencies that best suites their business needs.

Similar situation is in other areas (more elaborated in the upcoming report): project management, software implementation (covering code change and configuration, issue tracking and release management), and test and validation. And while we agree that famous SE “vee” is a general conceptual solution that applies to mechatronics, beware of the specifics of your business process before you develop a framework for its adoption. Your framework needs to address not just the tools for common engineering tasks, but to facilitate the optimal flow of tasks in your business environment.