Product Value Management

Service Oriented Architecture has reached a critical point in its evolution. It has been extensively referenced by application vendors as their newly adopted paradigm for development, as well as by large computing infrastructure powerhouses as their platform for sustainable growth by merging acquired technologies on an accelerated basis. At the same time, the original vision of SOA, to enable fast transformation of business processes seems to be lost in between the two dominant approaches.

While SOA provides a solid set of guidelines for application interfaces development, using it simply for such purposes offers little more above and beyond of the current capabilities for application integration. SOA applied only to application integration (using standard interfaces managed via ESB message routing and transformation solutions) is nothing more then “EAI on steroids”. Many required SOA capabilities, such as service discovery, dynamic orchestrations and computing resources allocation remain unattended in this approach. The world of SOA based EAI does not look much different than before - it simply does not equates to elevated agility and flexibility of global business operations.

As far as using SOA as a information model normalization concept for merging acquired technologies, the results just seems to be somewhat more promising. Ontology based registries provide for much cleaner semantic integration of complementary business logic. However, the results of this approach remain under control of the vendor defining the roadmap, and are not necessarily exposed to the end users through widely open and accessible SOA registries. In other words, it is the vendor that decides what and when will be released in the model based environment on their still proprietary modeling platforms.

Unless, the third option, squeezed in between the two more dominant ones described above, re-emerges in a short order, we have probably seen whatever there was supposed to be of SOA. Yet, the work of many forward looking architects and developers continues under shadows of marketing clouds of gargantuan proportions casted by computing infrastructure giants who prefer the status quo. Perhaps for the sake of clarity we should stop using the acronym SOA, and introduce something much more specific - a methodology that has at least three words: business, transformation and agility front and center.

I have recently visited a project team fully submerged in designing a new (should I say - service oriented) business process information management infrastructure for a major banking institution. They have developed a three stage model based methodology whereby the team can prototype, test and evaluate and then release advanced processes for managing established and sometimes completely new offerings at the financial markets. I did not find their focus to be on SOA, or whatever we may call it going forward. The team, consisting of mostly young engineers led by few seasoned architects, follows most of SOA concepts, yet they have only fully adopted a set of principles and design techniques that enables their stated business objectives. Thus, for example, they evaluate services consumption using advanced models based on pattern recognition for forecasting demand on the computing infrastructure. Their goal is to enable end users trying to bundle a series of financial solutions to obtain a super fast quote from multiple rule based quotation engines, intelligently exchanging user profile data and marketing parameters stored in over a dozen of underlying applications. Similar approach they developed for fraud and money laundering solution, dynamically exchanging events between multiple transaction systems, intervening on behalf of the security officers by composing on a fly the sequence of events and alerting next system in the recognized pattern to disable certain services. Suffice to say their work is saving the bank tens of millions of dollars, and it is a completely sustainable model based solution that they have developed, with almost no latency in changing and adjusting to the new emerging requirements.

Yet, the team has fully deployed concepts such as standard registries and repositories, agent based frameworks, services discovery and assembly, dynamic services protocol binding, standard security profiling, and other typical SOA concepts. But, what made them successful the most, was their ability to define and deploy the entire business process within the same ontology and semantic framework fully tying model time and run time environment for dynamic promotion of process changes. I was very proud to realize that the team used some of the concepts I have published in the FERA body of work.

Back to what we think SOA is today. I met a leading architect of the large consulting and infrastructure behemoth, and discussed with him some of the work I have encountered recently, including the financial company menioned above. While he completely agreed with me that what I have seen there is some sort of best practice to utilize SOA, he also shared with me many other situations where similar solutions are emerging. The entire movement according to these new developments is very different then what we have observed with SOA so far. There is little regard to endless rhetorics of the past, perpetuated by a myriad of “guerrilla marketing” forums and their zealous pundits. However, for most of large IT vendors vying for larger control of the market, these news breaking events are not a welcome trend. They simply do not want a ground swell of independent solutions addressing what they would rather see as few proprietary platforms going forward. That way at least few of them have a chance of emerging at the top of a lucrative long term royalty base. Sharing it in two or three does not hurt them either, as it never did before.

I don’t envision the future of SOA the way that today’s leading vendors are crafting it. I also don’t see it as a free for all, open standard nirvana that has been perpetuated by well wishers and benevolent supporters without much direct interest in global businesses’ transformations. I see, however, a renewed focus on business process agility, harmonization and standardization of global value chain processes and computing infrastructure. And that may result in SOA principles simply exploding out of their current “controlled temperature egg shell” and morphing into something much more applicable and implementable - an end-to-end model based business process transformation framework. It is unclear how will the leading vendors regroup into that impeding movement. As far as I am concerned, it does not matter. Those who wait for them at the SOA cross-roads may as well be waiting forever, or accept to be taken into another direction altogether. It is a renewed competitiveness and new global business possibilities that will determine the future of enterprise computing. IT mastodons can cull SOA, or more precisely the marketing shell around it, since they have created it and funded by themselves. But, they cannot stop whatever is emerging out of its cracking shell - a yet to be named mutant of the new enterprise computing paradigm. The SOA is dead - long live the SOA.

Happy New Year. With the last moments of 2007 winding down I wanted to make a brief run-down of main developments that marked the passing year. In the next blog I will highlight our research agenda for the coming year.

For an analyst, it is always difficult to rate impact of significant industry events. Main reason is that analysts try to comprehend all consequences far beyond the immediate journalistic weight of an event. For example, Airbus problems with the A380 launch received significant press, while for an analyst the problems were a logical consequence of a major strategic misalignment between program complexity and company’s distributed infrastructure supporting product development.

My criteria for rating importance of an event is based on its potential to dramatically or significantly change how we do product development and consequently its impact on what we expect from PLM technology and how will we use it in the future. Using an actual and familiar analogy, an avalanche is not much of a news for me, I am more interested in understanding impact of climate conditions that may cause drastic change in the yearly number of avalanches.

With that in mind, my top five list events that marked PLM development last year are:

1. Launch of Teamcenter 2007.

Teamcenter 2007 is the world’s first commercial PLM system. Its significance is the final departure from PLM as a set of applications. One integrated information system can now connect all product information from early ideas and requirements to manufacturing release and support, spanning the entire scope of product life cycle. New process efficiencies can be obtained from more integrated streamlined process flows and above all, capture and reuse of product information can be institutionalized and measured.

Similar effect to the business performance was observed in early 90-es when ERP systems started connecting all transactions within an enterprise closing the feedback loop between financial performance and operational excellence. PLM is now entering same phase of maturity, paving the way for a closed loop between financial performance and strategic planning, and we will never look on PLM as software for engineering automation.

2. Toyota officially number one.

Many years in coming, it has finally arrived. With impeccable precision and predictability, the recognition of Toyota as the world’s number one automotive OEM marks the pinnacle of concurrent engineering era. Aside from many other dimensions, the importance of this event to the PLM is seen through three significant consequences:

a. Planned organic growth following a long term vision has proven its strategic superiority over “arithmetic” mergers and acquisitions;

b. It is organizationally possible to establish a standard process for product development as a measurable value stream;

c. In commercial/consumer product development, information technology is best utilized when planned and implemented within the context of process, people and overall strategic enterprise equilibrium.

Toyota will have its share of challenges in the near and distant future. Scalability and standardization of global development operations is yet unconquered business challenge. We will all learn much more form Toyota as it keeps thinking and creatively addressing new challenges.

3. SOA.

Perhaps most misused information technology advancement in last decade is the service oriented architecture (commonly known as SOA). SOA is a set of very simple and elegant principles for distributed process execution. Yet, it has been hijacked by overly zealous vendors who saw in it a shot in the arm for otherwise mundane value proposition of their boring infrastructure and enterprise application integration offerings. Same vendors that were well served with the “Y2K bug” (probably they liked that scare factor). Without clear vision of the adoption roadmap, they poured into shallow substance-less marketing hundreds of millions of dollars that ultimately more confused than educated likely beneficiaries of the SOA concept.

Yet, for PLM, SOA is a major advancement that marks a quantum leap in possibilities for faster and richer product information flow. SOA has been instrumental in executing Teamcenter 2007 and is instrumental in the plans of all other PLM vendors that will launch their own PLM system offerings this year. What remains to be seen is the use of SOA in the larger context of the process management, where we believe product development stands to benefit the most. It will require further maturing of the process management frameworks and semantic enterprise architectures. A great topic to follow in 2008.

4. Return of direct geometry.

Parametrization of geometry has been an undisputed leader in applied techniques for reuse and repurposing of product designs. It evolved over many years through maturing mass customization and engineer to order business models. Yet, the design devil is always in the details, small dimensional adjustments and tolerances. With the growing application of design optimization techniques such as DFSS and robust engineering, constrained “nominal geometry” becomes more of a burden than an enabler. Variability of production processes, performance and functional factors surrounding the system of parts is now a critical focus for optimization. Consequently, un-tethering the geometric shapes from their history and/or origin of their nominal dimensions becomes an important feature to quickly and more completely match optimal system design characteristics.

Contextual manipulation of geometry of mechanical systems within their virtual working environment, while preserving traceability and reasoning on their dimensions is a new modeling paradigm that has potential to change the flow of design processes. The question arises: is it more effective to constrain engineers to specific parts proportions thus preserving certain design and manufacturing rules, or to allow them to freely manipulate geometry of recommended starting design concepts while presenting them with consequences of their choices. There has to be a balance between these two ends of the spectrum and that point of balance will determine the exact process flow. Optimal balance will be different for different products and different manufacturing strategies. With new PLM offerings now supporting the entire spectrum of possibilities, it is quite realistic that early adopters who solve this puzzle will gain significant advantages.

5. SysML crawling out of the crib.

For many years we witnessed a quest for the holly grail of systems engineering - an integrated information model tying requirements, functions and components into a complete representation of the system design. Various data representation standards like STEP series came forward as results of multi-year efforts of many bright and dedicated engineers. However, implementation of these data exchange standards was always a challenging technology endeavor because their objective was a unified and normalized data model, what is a tall order for any single end user company to adopt and particularly for a diverse community of PLM vendors to converge on.

SysML grew from a much more humble objective - to provide a common representation language to express models required for functional design and simulation of electromechanical systems controlled by embedded software. Similar to how UML helped software designers express key properties and use cases of an object oriented application. Naturally, the system modeling language needed to tie together requirements, functions, interfaces and performance parameters. The idea of supporting exchange of system models between design and test engineers provided it with a much needed focus. Now, SysML looks like a logical choice for considering a language to capture and share system design information within a distributed collaborative design community. It yet remains to be seen what adoption by the PLM vendors will it receive, but we believe that its completeness and applicability to the growing problem of managing functional allocations warrants at least its immediate future.

These five events in my opinion have all long lasting consequences on how we do product development and how will we use PLM technology in the future. I probably missed some other important ones, please drop me a note if you have your own observation that I may have missed in this list.

Few weeks ago, CPDA had a workshop on Design Simulation Data Management hosted by GE Aircraft Engines in Cincinnati. The workshop was attended by a dozen of very active CAE technology strategists who all had experience in using and implementing sophisticated simulation management solutions. The discussion went into much detail of what are key requirements such solutions should satisfy to meet objectives of advanced CAE practices. I have to say I enjoyed the discussions and was very impressed with the advancements in the field where I started my career as a mechanical engineer over twenty years ago. The group very succinctly defined several dozens of functional and system performance requirements within the spectrum of data management, data integration, analyst task management and process integration categories.

However, one common theme surfaced in almost every discussion topic: what is the real business value of a sophisticated, automated design simulation management solution. Who are the beneficiaries and why would they support the transformation? Who else needs to participate in the transformation of the CAE domain into a sophisticated automated process. Many excellent ideas surfaced in the discussions and I wanted to share some of them in this summary.

First of all, everyone agrees that it is not just analysts and simulation/validation experts who benefit from an advanced solution. It is foremost the program management that gains by early validation of design ideas and capture of knowledge that can guide better design decisions along the program path. Another important benefit comes from the link with systems engineers and possibility to directly relate requirements and system/sub-system level functional models to the results of early simulation for design concept validation. Both of these possibilities equate to a higher throughput of useful product knowledge that can reduce variances in development schedules and quality/performance of the product. But that would be a rather trivial answer. We need to step back into the overall enterprise scope to actually properly describe potential impact and reasons for considering a sophisticated CAE management solution.

For many of us virtual prototyping and simulation have an intuitive value. We easily accept that eliminating physical prototypes equates to shorten product development cycle times. So much so, that at times, elimination of prototypes was one of key strategies for reducing development cycles at some large global manufacturers of passenger vehicles. Some of my friends with extensive lean background do not necessarily think so. Their arguments goes that there is so much waste in product development that they had eliminated over time that resulted in tens of percents of cycle time reductions, and that they have never found physical prototype to be a waste. Opposite, they would argue, physical prototype can help reduce manufacturing errors and reduce number of changes. It, of course, has to be properly planned and synchronized with the rest of the effort, but by itself it simply is never found to be a wasted effort.

Their argument has strong base. While we can always simulate with nominal geometry various alignment, strength, flow, temperature gradient, part and assembly deformation scenarios, we can never substitute for senses of touch and weight, taste or smell. Even the effect of complex assembly tolerances can never be fully comprehended without some physical prototyping. Not to mention the fact that engineers love to gather around physical mockups, brainstorm together and exchange very valuable information, and are not as excited with the digital version of the “would be” product.

On the other hand, Purely arithmetically, reducing number of physical prototypes shortens the cycle time. However, arguable condition is that the virtual replacement accomplishes same purpose and provides same quality of insight. Another notion is timing. When we decide to physically validate a portion of design, we have set a sense of a milestone. Yet, the milestone should not be seen as simply a chance to redo things after it, but a confirmation that the work done up to it has been properly planned, communicated and validated. Same feeling of “looseness” may apply to virtual prototype, too. Just because we can run them cheaper and many more times does not mean we should think we have a chance to fix things even if we did not communicate our decisions and pre-validated assumptions.

Lean thinkers teach us that rework is a waste unless it is done to provide new insight and incrementally increase value (better design, lower cost). In particular they are sensitive to change management that is simply a fix or retrospective of something that could have been done properly to begin with. Thus, physical prototype that helps eliminate significant change overhead, or furthers new understanding is never a waste. Same reasoning thus should be applied to virtual prototype. Not just because it is “faster to make or easier to produce”, but primarily because it can generate new insights early and provide for alignment of decisions and deliverables to avoid rework, design simulation adds significant value.

Therein lies the justification. Only when properly integrated with the rest of the design process, to plan for appropriate simulation needs and timing of validation runs, simulation will bring the team to new heights of understanding. It in fact goes hand in hand with lean thinking and robust design principles. Several possibilities arise:

- Front end loading to validate value proposition and new requirements, thus reducing risks due to new knowledge acquired early.
- Alignment of design parameters to perform cross-domain validation at the system level speeds up communication of constraints and promotes optimal choices in mechanical, electrical and software design.
- Repetitive validations with consistent modeling approaches enable higher granularity of parameters and increased number of variables to consider what increases chances of finding more optimal solutions based on more criteria.

Let me go back to the introductory discussion. Advanced design simulation solutions will only bring more work to analysts and system engineers. However, to justify the investment in acquiring these sophisticated tools and methods, one needs to think from the point of view of program managers and R&D and production managers. Only if fundamentally integrated with the rest of the process to enable improved planning and execution, these tools will be looked upon as strategic enablers. Just replacement of physical prototype does not warrant the overall improvement of the product development process. By speeding up one aspect of development, without re-synchronizing all other activities to take advantage, we can always release design faster, and then spend more productive engineer time in non value added changes after the release. As a result, resources get more strained, quality corners get cut and newly gained speed somehow does not equate in higher throughput of differentiated products with new features to markets.

My take is that to properly establish the value of a sophisticated CAE and design simulation solution,. one needs to promote a fundamentally different design process, and look for new ways of doing the entire process to obtain benefits in the area of better decision synchronization, risk management and elimination of non value added change management.

When we talk about master data, we often refer to a set of data that appear in multiple transactions and documents. Examples are data defining customers, suppliers, products, parts, prices, etc. Naturally, since this data are used in various processes’ inputs and outputs, their accuracy and completeness is very critical. Master data, like any other, changes over time. It gets created, modified, deleted, transferred from one data repository to another, and is used as reference in multiple reports. Master data is usually spread across many systems that can author it, exchange it and delete it. Thus, our chance of fully controlling the use of master data across all processes is very slim.

We often take it for granted that within a single system we can always perform any inquiry on the use of any data element. Suppose that any data field defined within a transportation management system can ask the system “What am I?”. The system should be always able to answer something like “You are a string value field ‘3′ in the table ‘342′”. Better option would be that the system comes back with “You are a system defined attribute called ‘address number’ in the entity called ‘address’.” Best would be to have an answer like “You are a ’street number’ for the ’ship to address’ of the final ‘delivery point’ on all internal ‘transportation orders’ and ‘3rd party delivery orders’, but not on ‘drop ship orders’ because I don’t handle those.” Which one of these answers do you think a legacy system will most likely give back? I’d say first. Which answer would an ERP or a specialized logistics system give back? If we are lucky and this is a system defined field, second is the best we can hope for. Can we expect any system to give back the third answer? No. Because that system does not really know that the street number in a ship to address of a customer is “master data” and does not know where else in the processes outside of that system is it being used and how.

Examples like this abound in all process domains. In product development we have many entities in many systems representing requirements, functions, parameters, components. Same is with order items, suppliers and contracts in sourcing and procurement. Lead times, resources, capacity, inventory in supply chain… Is it really worth making sure that all these elements represent exactly the same thing? Is it that critically important that they all have a single source of definition? Common belief is YES, but I have not seen any analysis defining all possible uses of master data across all systems and considering all implications (preferably in monetary terms) on the integrity of transactions and decisions they support. Simply because the moment such an analysis is complete and accurate, the problem is probably solved. So, why are we so much concerned with what we call master data?

The main reason is fear of loosing control. But haven’t we already lost it? Our processes are not well defined to even understand all occurrences of “master” data within all inputs and outputs requiring them. Our systems are so much proprietary and closed that we do not even dare to question accuracy and adequacy of the meaning of the data within them. We simply close our eyes to the fact that we are really not masters of the master data. Consequently, we cannot really govern it, we cannot control it, we cannot influence its evolution. We can only hope for a comfort of knowing that all master data reside in a single system where we can at least see the field within a table where it is defined, regardless of its true semantic value to support all inputs and outputs of all processes that may need it.

Well, let’s imagine a different approach. One where there is no master data, just data. And where data is not tied to any specific system’s definition of what it is, but to our preferred understanding (even without a full agreement) on what are all the things that that data may represent. Let’s then get back to our previous example. The data field asks the system within which it has been defined “What am I?” The system says: ” I think I know what you are, but let me ask the federation registry.” Then the system asks the federation registry:”I have the data that has been defined as field ‘3′ in table ‘342′. Have I ever exchanged that data with you in any of the service calls?” The registry says “Nope.” Then the system goes back with an answer :”It does not matter, just stay there and be happy.” Let’s say the registry comes back and says:”Yes, you have send me 35,564 calls with that field, and in 31,504 of cases it has been used in the ‘Transportation Order’ informational reference document, that had undergone 3 versions since the first use and where the latest definition of the field was the ’street number’ of the ’ship to address’. I have also seen it in 4,060 cases in a cloned informational reference document called ‘Expediting Drop Ship Order’, that had only one version and where the field was the ’street number’ of the ’ship to address’.” The system comes back to the field and says: “Your are a ’street number of the ship to address’.” There may be different kinds of inquiries and semantic searches returning all sorts of results like this once the data crosses processes and system domains.

The example above follows the utility approach, since it tells us that “it does not matter who you think you are, it only matters what people think they can use you for.” Same goes for master data. The only way to really control it is to understand all different meanings in all contexts within which the data adds value to information processing. And at the point of placing the informational reference between the content (data fields in a document type, e.g. ’street number of a ship to address’) and context (input/output in the process flow using that document type, e.g. ‘Transportation Order’ or its clone ‘Expediting Drop Ship Order’) is where we need to capture that link. That is how decoupled content and context work in SOA process modeling. We have written about this extensively in our FERA research (http://www.cpd-associates.com/index.cfm?content=subpage&file=include_RPPage.cfm&ID=72404138&DOC=194759508) and this approach has been a basis for the SOA-IM standard offered by VCG (http://www.value-chain.org/).

Semantic approach is based on modeling the business process using explicitly defined meaning of each building block - activity and input and output like in VRM (see link above). Then, referencing each I/O with the document types that represent its content, like in SOA-IM (see link above). Only then, makes sense to point document types to the web services required for populating their content with data from federated systems. Each system can consequently retain its internal meaning of the data independently from other systems. Yet, they can all inquire about all different uses of their data within the context of the connected process. Thus, “master” data really becomes data that has multiple uses and for each use a specified meaning and a preferred source. In semantic approach, we can even dynamically decide what source and what version to use given the context within which we want to use it. Orientation of the users relative to data and the process is achieved by decoupling content and context and allowing for semantic reconciliation of data elements between different activities. It is in our best interest to master all our data. It is not in our best interest to pretend that we can manage master data only to eventually apply governance that reduces its reach and limits its use.

I met recently a senior executive of a multinational automotive manufacturing company. I took the opportunity to get a practitioner’s point of view on much dreaded exodus of manufacturing jobs. The pragmatic nature of the problem makes it very trivial in the eyes of a manufacturing company executive. What was more interesting to me is the increasing importance of PLM in global manufacturing shift. That insight I want to share. Let me try to reconstruct the discussion as close to the actual, but since this a non-authorized piece, to preserve the confidentiality, real names will not be used. I don’t think it changes the message a single bit though, you will most likely agree if you read through to the end.

VD (Vasco Drecun): Bob, your company recently announced moving another large manufacturing operation overseas. Where does the buck stop?

Bob: We are in fact not moving as much as adding. Our customers are moving their manufacturing operations at a much faster rate than we are. I’d say that most of our established competition has been operating in new markets ahead of us. However, many local competitors are new to all of us and there are many surprises waiting in new markets even as we mostly do business with already established customers… We do expect to have over 50% of our manufacturing capacity worldwide in Eastern Europe, China and India within next seven years. Mind you, a larger portion of it will come through growth of local markets rather then just by relocation.

VD: Does that mean that your current “Great Lakes” manufacturing base will grow, too?

Bob: Most likely not nearly as much, rather maybe decline somewhat. However, there is significant growth potential here in areas other than manufacturing, primarily in research and development and value added services.

VD: You will have most manufacturing operations spread in new markets and low labour cost countries, while growing research and development in a completely different time zone? Please, explain that to me.

Bob: There is something very fundamental here at play. Many people get very emotional about globalization, and fail to recognize the basics of what is going on, although it is very simple. Let me explain. For many decades, as a society, we have been mastering and evolving cost based manufacturing capitalism. In that system, the cost equation drives your choices more than any other consideration. Simply, when everything else is equal or very similar (quality, service, taxes, cost of assets, ownership structure, etc.), lower cost drives your decision. And there is simply no way escaping that fact. The entire manufacturing economy today functions based on that principle. With the expansion of the system boundaries, the same equation still applies. Trade and other regulations are being normalized on an accelerated rate, making cost factor come forward as obvious as ever before. As soon as one of the competitors starts taking advantage of that others have to follow.

VD: So, you say it is inevitable. But, how far reaching is this trend? Does that mean that for as long as you can lower the cost, you have to pursue the opportunity?

Bob: That is a very interesting issue. Today, the world has adopted, more or less, a unified system of economy, and we are now witnessing the pinnacle of cost based manufacturing capitalism. However, we know that if we simply keep playing the game of cost on a long run, we are going to loose many other aspects of value, to our customers primarily, then to our company, to our employees, and to the society as a whole. Consequently, the system needs to evolve, and in a fundamentally different conceptual way. For example, our company is already investigating various for us completely new technologies and alliances that will put us much firmer into integrated telematics. And we never played in that space before. Just within few years of pursuing that opportunity we are on the verge of a major transformation in our business model. What I am trying to describe is how we all have to look at ways to increase value from our products and services to be able to differentiate in an increasingly cost based arena. Rather then focusing on cost, we are trying to define new value and establish much more sustainable competitive advantage to our company.

VD: Well, the technology also has its curve of maturing. Eventually every innovation that gets adopted becomes a commodity over time. In that case you would need to constantly innovate to extend your competitive edge. How does that happen? What changes do you need to go through as a company to execute on that vision?

Bob: This is where we have to apply very sharp focus as a company, with our industry groups and even if you wish, as a society. We are witnessing the dawn of the value based manufacturing capitalism. The system where constant increase in value over much shorter periods of time ties your customers and end users of your products to the brand and life style that your products are resembling. However, to get there our business models need to fundamentally change. For example, we have started our value chain vision exercise several months ago. Among seven areas of strategic focus for change were the profile of our engineers and fundamentally new, dynamic product development system.

VD: You are looking for new engineers across the globe?

Bob: No, the opposite. When we say “engineer profile” we are not considering where to hire more engineers like ones that we have today, but what should an engineer “look like” in order to get us to the value chain vision. And, just in that category the change is very dramatic. For example, we identified that the new breed of engineers needs to have a mixture of technical skills in various disciplines at a higher conceptual level, yet much more refined thinking skills about customer and social trends in general. That is almost directly opposite from having them to focus on details and excel at engineering quality thinking, what we have been mostly pursuing up until very recently. One of our executives called this a “socio-technical” set of skills. We know we cannot develop this profile alone. Educational institutions, government, industry groups, everyone needs to pitch in.

VD: Wow, you are looking many years ahead for sure. This value based capitalism is going to be quite a journey beyond our lives. What about other of the seven areas you identified, is there anything more immediate to be done?

Bob. It seems far fetched but it really is right here around us in many aspects. As I said, another area of strategic focus is our new dynamic product development system. Looking into the value chain that we need to master, we concluded not only that we do not have a very formal development system, that even the one we have documented is rather static, not very useful when it comes to metrics based planning and fast, very dynamic decisions making. In order to reduce the time it takes to plan and execute on innovation, we need much more dynamic planning and execution system tying together requirements, resources and deliverables across all programs. Planning visibility, portfolio balancing and knowledge capture and reuse are big determinants of the success of our new system. We need to increase throughput of new features. Our goals are 50% increase of new features and products over same period of time, and not more than 15% variance on projected program schedule and budget. Suffice to say, we do not want to do that by increasing cost and reducing quality. Thus, scaling our research and development organization to achieve these objectives is what we are focused on right now. And dynamic product development system is a big part of that agenda.

VD: Where are you going to get people to do all of this? Is this something you are trying to do globally as well?

Bob: All seven strategic focus themes are related. We have looked at many different staffing arrangements and ideas and concluded that the best possible option is to develop our base for this part of the transformation right here in Canada. The transformation will be global in nature, of course. However, we believe that the best chance of evolving this agenda is to develop a closely bound group of professionals working on the new DNA for the new type of competition. We are not looking for short term here, although some advancements were surprisingly beneficial and are already being deployed globally. We have also selected strategic transformation partners, and are looking for ways to speed up the transformation with innovative use of information systems and technology.

VD: This is all very interesting. You concluded that the fundamental shift is at play, you then worked out your own vision and transformation roadmap for the new economy and are already contemplating changes. How confident you are that you have guessed this shift right?

Bob: We are practitioners. We have no time to wait for anyone to figure things out for us. Even if we had in the past, the answers were coming as “to little too late”. The changes we are going through have global reach, the speed of changes is much more dramatic than ever before, and the accelerated complexity we are facing can literally freeze us out if we do not act now. We have to figure out our choices quickly and decisively. When we call it value based manufacturing capitalism, it is not to coin a new phrase, it is simply to embed into our heads that we are going to have to compete on a fundamentally different plane going forward. And that new competitive plateau is something that yet needs to be fully defined. Yet, we do feel we have an edge. Constant drive for innovation had been the basic advantage of North American manufacturing for many years. Not being satisfied with status quo, seeking new ways and developing new things, from simple to paradigm shifting innovations. If we reach new grounds faster, we will have more advantage in the global economy and take some of that advantage as profits to our shareholders sooner rather then later.

VD: So, PLM and product development are strategically critical for the new era?

Bob: New approach to product development is the corner stone of our vision. We are actively engaged in transforming our research and development into fast, highly effective operation. The range of possible improvements in this area are much higher than in manufacturing and supply chain right now. And what is more important, these improvements will give us much more boost from the strategic point of view than simply playing the cost game. Many of the tools you are writing about have been considered and few selected in aiding the transformation. The new competitive battleground will shift away from cost based manufacturing into value based manufacturing and we want to be one of first companies to arrive at that destination.

…It is always interesting to talk to practitioners. Their insights come from dealing with daily competitive pressures. It is also encouraging to realize that global shift has been comprehended. Companies coming out with new vision, and particularly those that can execute, establish the trend for many years to come. Looks like we have an interesting road ahead of us when it comes to new product development methods, tools and processes.

In part one of this blog series, we discussed roles of PLM business process architects and PLM enterprise architects as custodians of the process definition, process modeling and analysis techniques and tools. Having creative architects that can design better processes and specify blueprint for transformation is a required but not sufficient condition for success. Navigating through organizational dynamics that intensifies with every transformation requires firm stewardship, self reinforcing motivation and relentless focus on ultimate objectives.

Let me start with an analogy.

At some point in time, many people have a need to remodel the house they live in. Various reasons come to mind: new additions to the family, school age transitions, health needs, parents moving in, … They canvass the needs from the family members, discuss extensively the needs (with few heated arguments) to eventually approach good architect who figures out the current house layout and comes with an improved layout that meets all sorts of objectives, with few compromises. Looks good? There starts the trouble.

Several bids and negotiations later and already at least one of the family members fails to cooperate. Lets’ say, a promised piano purchase got postponed, or worse yet - bathroom or kitchen fixtures got downgraded - and of course, many hidden requirements only surface when the concept is done.

Eventually, after several painful compromises, best bid is selected, budget secured and preparations need to start. Looks good? There starts the trouble squared…. I hope you get where this is going. Let me cut this story here because it may get very ugly, let’s be optimistic that it ends with a truce and just one year of relationships mending extending the budget by mere 30% on Miscellaneous Items.

Similar issues follow in PLM transformation, since organizational dynamics is based on human nature. So, what would be a meaningful approach to govern PLM transformation beyond the blueprint design? I intentionally say meaningful, because there is simply not best practice in this aspect. What works for one company may not at all work for another, due to multiple reasons all ultimately buried deep within the organization’s DNA.

It actually starts before the architects are called to help define the blueprint. Several roles get engaged in goal setting and qualification of high level business requirements. Let me introduce a role of product development analyst.

Product development analyst is responsible for:

- Gathering and analysis of product development metrics across multiple development programs;
- Definition of development program estimation techniques;
- Benchmarking and comparative study of performance differences between internal and competitive development programs;
- Establishment of relationship between metrics and practices;
- Improvement of estimation techniques based on correlations between various measurable program parameters (innovation index, variance, key indicators of change, etc.)
- Development of proposals for process changes and communication to the PLM business process architect about the changes required in the process management framework.

It is often series of reports by product development analyst that triggers discussion of the needs for change. Another usual trigger is the change in company’s strategy. One way or another, product development steering committee is the body that evaluates if changes in the current practices and processes are needed or not. Who are members of the steering committee? How often do they meet? What do they discuss? What decisions they make?

Product development steering committee (SC) is a body that comprises three to five core members. One of the core members is always the company’s most senior leader, CEO or president. Other usual member is most senior leader in charge of product development organization, and usually when the company’s development function is decentralized, that membership is offered to multiple equivalent representatives from various divisions. The extended committee usually involves other senior leaders, such as most senior financial manager, operation leader and sales and marketing leader. However, the extended committee is usually only called upon the need to make a significant decision and when the usual members decide it is needed to communicate the issues at hand.

Steering committee meets on a quarterly basis. Since many of the members are already deeply involved in the product development decisions either as members of product direction team, or through portfolio planning sessions, they are usually well versed in the programs statuses and product planning trade-offs. The purpose of the product development steering committee is to discuss if the product development process requires deeper attention or not. Occasionally, steering committee members may require analysts to dig deeper into specific issue that they are curious about, either externally or internally.

When the SC deems the need for investigation into the possibility for change, they are aware that it may be a start of a transformation initiative. At that moment, the SC selects the sponsor of the initiative to act on their behalf throughout the initiative representing the objectives of the SC. Sponsor can be anyone that the SC chooses, whether on the SC or not. The role of the sponsor is to be a proxy for the stakeholders objectives and to preside over all key decisions that the initiative may undergo. There may be several initiatives at different stages of progress and the sponsors can be same or more people. Thus, the SC usually juggles several initiatives at different stages of progress and can decide to cut them short or change their scope and objectives depending at what point of progress they are. Just like in any other portfolio management.

The sponsor creates initiative team. In the first phase - investigation, it only requires the analyst and PLM business process architect. These two propose to the sponsor who they believe should be the best champion from the organization to help them define the scope and objectives of the investigation. Here we depart from the typical situation, where IT gets involved prematurely. Also, IT is not represented even on the product development steering committee. IT is a means to an end, not the purpose of the transformation. Enterprise architect gets involved when the sponsor, analyst and business process architect recognize that investigation points to the need for change in how the organization utilizes information and other assets.

If investigation points out to the need for further detailed assessment, depending on the scope that has been already determined by the champion and business architect, the sponsor may decide to start next phase - root cause analysis and blueprint design. The purpose of the root cause analysis is to determine if the current process design can be changed and how to eliminate the problem that the steering committee has deemed significant enough to start an initiative. This is where the two roles defined in the part one come to play in earnest.

The sponsor will make sure that an appropriate champion is assigned to this phase as well, and it may be a different champion than in the previous phase. Additional people may get involved in either defining as is or designing should be process. Sponsor is empowered by the steering committee to ask for help from anyone he/she deems required to get to the bottom of the root cause and to come out with the blueprint for transformation. This phase may take longer, but it is the critical phase where through series of iterations architects try to come out with an improved design and a blueprint for its implementation.

To eliminate most risks while still in planning mode, the sponsor may lengthen this phase in order to do prototypes of the solutions, talk to external vendors, assess readiness and maturity, determine ROI of different blueprints… It is discretion and responsibility of the sponsor to make sure that everyone is on the same page if he/she is about to propose transformation execution phase. Sponsor may require return on investment to be evaluated, detailed roadmap for change established, etc. Acting just like a chief engineer in Toyota, the sponsor is in charge of the success of the initiative. It is very unlikely that the steering committee will reject a request from the sponsor to get company engaged in the transition execution. In return, the sponsor may require all checks and balances from the PLM process and enterprise architects and analysts before asking for the budget to be approved.

When the budget is approved, negotiated contracts are put in place and the execution can start. Whether the sponsor selected a completely outsourced, or internally managed execution it is less relevant. The sponsor is in charge of decisions and trade-offs. Usually, the transformation may take several steps and each step may have goals and objectives that are measured. The sponsor reports back to the SC on the progress and trade-offs.

Since the responsibility of the sponsors is very significant, what is the most important enabler for them? It is methodology. Sponsors need to be goal driven, not willing to come to compromise with reduced goals. They have to drive architects to be very creative to come out with good blueprint. They need to relentlessly pursue changes once the changes are clearly defined and assigned to the people. Above all, just like Toyota chief engineers, they need to front-load the initiative, keep multiple options open, work-off risks early, drive the decisions and push hard on the implementers to stick to their agreed upon integrating events and milestones.

Centralizing the driving force, taking it away from IT, and giving it to the accountable professionals, gives to the steering committee latitude to pick the most adequate sponsors from the internal staff. It also eliminates the communication and motivation burden from champions, architects and analysts. It is not uncommon that the sponsor is selected from one of the members of the SC. After all, it is their ship to navigate, their battles to pick, win or loose.

This governance approach grooms champions into future sponsors, promotes organizational learning and reuse of process knowledge through captured business process and enterprise architecture. It also leaves IT to become experts in enterprise architecture and not to dwell on the business direction. Their input into blueprint design can literally point the company to the right direction.

Today, much discussion ensues about the tools and techniques for process modeling, analysis, execution and other “cool BPM stuff”. Significant time is spent debating applicability of different tools to development process modeling and analysis, process execution and monitoring. Albeit an important issue, that should not be the main focus in PLM transformation. As we have seen in this part, the issue is much broader and it is the methodology that the sponsors need to rely on. Having a sound methodology and organizational alignment around objectives is by far more important factor of success. In the next - last part, we will discuss the methods and tools that can be put together into a meaningful transformation framework.