Product Value 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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