Product Value Management

A substantial group of industry analysts and media reporters gathered this week in NYC to hear from Siemens UGS PLM Software eadership what lies ahead (yes, that is what it is called now - I’ll keep using short version - UGS). The UGS leadership did great job in explaining Siemens rationale for purchasing UGS, and tried even harder to outline their product direction for the near future. Technical explanations of their direction were as usually excellent - courtesy of Chuck Grindstaff and Steve Bashada, somewhat less clear on the marketing/sales side of things, and this time very tastefully sprinkled with customer testimonials, illustrating excitement about the momentum of Teamcenter 2007 (more on this later). So excited are UGS leaders about their prospects, that they managed to line up 25 (yes, twenty five) speakers and panelists in just the first day of the two-day event - all in one track. Suffice to say, one of side effects of that major accomplishment was to get yours truly tired enough to crash straight into bed in the heart of the city that never sleeps. Next time dear UGS event planners, please do this wherever airport ground delays last tad shorter than two hours.

Back to the content. First, let’s comment on the ownership transition. Being acquired by an owner that gets it, or shell we say - having acquired an owner that gets it, UGS has finally gained a position to, once and for all, establish clear definition of what exactly is PLM software. Judging by the interim results of the transition, they have firmly embraced that chance. Additions to the UGS leadership team, courtesy of Siemens A&D, and complementary vision of the Siemens MES software guardians, provided for an obvious synergy and convergent thinking about the role and place of the PLM software in an integrated world class design and manufacturing framework. There are two effects of that synergy that I particularly liked: first, never before in any PLM vendor vision was it so clear where does division of responsibility between ERP and PLM software truly lie. Second, never before could any vendor provide a concrete, executable vision of a closed loop optimization for design for manufacturing process.

So, why does it matter? I offer three immediate implications (among other possible ones that don’t come to me right away, but I am sure will over time).

1. Redefinition of competition in PLM market. I have written before that we need to distinguish between PLM software (PDM, decision support, program and portfolio management, requirements management, direct sourcing, collaboration) and design/engineering automation software (MCAD, ECAD, CAE, styling, test - simulation and validation), at least for as long as an integrated framework has not been established. Teamcenter 2007 redefines the PLM competition exactly in that sense. As far as I am concerned, it is a pioneering (read first) software product that breaks that division and establishes what we can all now call - integrated PLM.

2. Since now we have an example of what is an integrated PLM product, we can also clearly delineate what is not an integrated PLM product. Particularly, in terms of various ERP and similar attempts to claim a piece of the territory. Product data management (PDM) software is not integrated PLM, at least not as much as it is not CAD software, or modeling and simulation software. Teamcenter 2007 is an integrated PLM software, and as far as I am concerned it is the first one. Everything should get clear name and designation, that way planners and strategists in charge of transforming and automating product development processes can have universal and clear understanding of functional coverage they are looking for. We need a normalized dictionary of classes and types of PLM components with the clear division between integrated PLM software and PLM software components. In that sense, Siemens UGS PLM Software is first vendor of integrated PLM software.

3. As controversial as this may sound (and there will be debate for sure), I am confident that this issue will settle very soon, or let’s say, as soon as pretenders to this market fully realize what is it that they are up against. And they will not have to wait long. As soon as dust surrounding the cycle of denial, understanding and acceptance of implications 1 and 2 settles, the dust of consolidations (mergers and acquisitions) will emerge. And this time, it will have to be very significant changes. For only significant changes make sense now, that PLM market will undergo overdue, but imminent, accelerated maturing. We can speculate as much as we want, but there are not too many meaningful matches left out there, that can establish breadth and scope of the coverage we will be witnessing from UGS in the coming years. Better prepare for a big one.

What can dilute this scenario? First, as always is the case, de-focused execution of a plan or a vision. I don’t think that this will be the case here. Simply because Siemens/UGS vision convergence project (dubbed “Archimedes”) has already started. The project is based on simple premise of canvassing value added use cases from real world of product and process optimization. Business impacts of closed loop optimization using real time digital simulations can be mind-boggling, just like we witnessed in the days of supply chain optimization (70% of cycle time reductions, 80% of inventory and so on, big enough for the next fed chairman to attribute next wave of productivity advances to). So, there should be plenty of willing contributors to test and benefit from this vision. As a matter of fact, if you are a joint Siemens and UGS client, I suggest that you contact your account representative from Siemens or UGS and donate your use cases to the vision statement.

Second, more likely impeding factor is cash. The vision is big enough and will require significant investment. Even with the license growth that UGS has enjoyed recently, flashed out project budget numbers may require additional cash infusion. Having Siemens still fresh from justification cycle of the original purchase amount, it is going to be a significant uphill battle for the newly formed executive team to create another overwhelming case. With cost of borrowing potentially quickly leaving current lows, public investment offering help may have to be sought.

Third, most likely scenario, is related to the second one. Having opened the Pandora’s box of the PLM market, Siemens has little choice than to accelerate the maturity transition. You can try as hard as you want, but external forces change the momentum of a system, not internal ones (which in fact create more friction and stress). Having just invigorated such a momentum, Siemens will have little choice then to play the game it has started, whether willingly or not (”you asked for it”). What works for them is that, historically, biggest returns and profits have been obtained by software firms in the midst of similar market maturity transitions - from niche and segmented offerings into early integrated solutions, and ahead of the commodity game. Cases of companies that have significantly marked such transitions abound - like i2 (in SCM), Oracle (in RDBMS), SAP (in ERP), Microsoft (in OS-s) prove the point. PLM market is right now exacty in such a maturity transition (from segmented niche to early integrated solutions), and vendors that simply grab the market by the hand and mature it with their own offerings will obtain that rewarding leadership spot. If Siemens and UGS truly understand how to mature the market, they will come to the conclusion that they may have to do even further acquisitions in addition to the “Archimedes”. Portfolio management and mechatronics jump to mind immediately.

Either way, PLM market will never look back, having tested waters of maturity that send clear message to the end users what real benefits can be had and how, and what integrated PLM solution really ought to be. Coupled with process and organization transformation frameworks providing methodology and governance (such as VRM), integrated PLM software can be a powerful accelerator of the post-industrial era, establishing new levels of productivity and innovation, probably even being a catalyst of the emerging global markets that so much need a shift from traditional cost-based capitalistic to value-based capitalistic - and this time globally connected, environmentally sound society.

Continued from previous post…

The company’s global research and engineering council, sponsored by executive leadership, approved transformation plan for product development process. Leadership of two development organizations, together with supply chain and production operations management (now already consolidated) had several meetings to get familiar with the framework being proposed. IT representatives solicited consulting support and finally everyone accepted the three-fold plan:

- establish common phase-gate model that is applicable to all development programs;
- establish common metrics based on the global business strategy;
- standardize on tools and practices that are common across entire scope of development efforts.

Transformation champion was selected amongst five senior engineering managers and he was teamed with an IT project manager in charge of systems integration (and migration).

With the stage set, and greatly encouraged by chosen consulting firm, the group decided to follow their standard Business Process Re-engineering methodology - same one that has been greatly received by supply chain organization. The order of steps had it like this: define “as-is” process map in both development organizations, reconcile two processes into a common set of activities and procedures, assess metrics critical for success according to corporate strategy, evaluate and benchmark two processes according to the metrics, determine “to-be” common process and propose final solution. Information technology part of the team had to, in parallel, map out information flow and functional system coverage of the process to propose consolidation strategy in lieu with “to-be” process. And finally, a roadmap of well defined process changes would be committed to by both organizations.

As the saying goes “devil is in the detail”, the team encountered a formidable challenge right at the beginning. Although each team had detailed documentation with process flows and practices (”cost driven” team even had an exhaustive quality documentation for each step and each deliverable), there could not be obtained a common set of definitions that can be used for fair comparison of two processes. Early attempts at reconciled view delivered overly abstract process map that was too trivial for comparison. Subsequent deep dive into details only reinforced “nay-sayer” camps at both “poles of wisdom”. Sentiment of a futile effort quickly plagued the team, and majority of interviewed engineers started asking for being taken off the team. Stuck in this predicament for almost few months, the team reported back to the committee a recommendation to either abandon the effort or reinforce project criticality (hoping that engineers will start converging pressured by fear of prolonged disturbances to their daily efforts).

However, engineers knew better how critical it is to change process and realign resources into an unproven management paradigm. The push-back this time was even worse with few influential “gray hairs” leading the pack. Left with little to ponder with, the team gave up, with a significant dose of resignation and an overwhelming archive of deliverables - few dozens pounds of maps with flowcharts and interview recordings. Blame it on culture said the consulting arm, their cheque collection going undisputed.

Nevertheless, corporate strategists could not accept one of three pillars of globalization efforts to be undermined - that is - reusing brand and consolidating product portfolio. One of executives attended a workshop (invited by their large customer) where she heard of a reference model that she understood was “a Rosetta stone of value chains”, enabling comparison and reconciliation of any number of processes with same purpose, from corporate governance to customer service (of course, research and development included).

Her e-mail went to by now disillusioned project champion (otherwise a highly respected colleague from many years back) and after a coffee break and few web pages searched, he decided to reconsider his efforts, but this time in a stealth mode. No fanfares, no large consulting budgets, just trial and error on a limited sample. Being a manager of a fairly large simulation and validation team himself, he decided to talk to his peers overseas and agreed to map out computer aided engineering, simulation and validation activities between two organizations. If limited effort comes to a success, he was willing to propose an all around refresh of the failed initiative. His idea was accepted, and both the executive that proposed the effort and the senior executive in charge of global development agreed. They knew that if this moves forward with success, their job of convincing others on the executive team would not be too difficult. Let’s do it from within, they agreed.

Quickly, our change champion realized differences in methodology. One difference seemed very clever to him: Rather then asking selected groups of cross-functional professionals to sit together and model their processes jointly while listing any issues they think are causing lower efficiency, he would sit down with each functional group separately and ask them to, using a dictionary with their own terminology, describe what is it that they do for the company. Because, he would use same dictionary for every conversation, the deliverables chosen as one group’s outputs would eventually end up as different group’s inputs and so on. That way he would connect the dependencies wherever same inputs/outputs get explicitly mentioned by both connected groups, while also outlining any loose ends - inputs or outputs that have no consensus producers or consumers, or agreed upon level of quality and timing. He would then pursue these gaps in another round of clarifications until there is simply a set of well defined gaps.

The only missing link in this plan, otherwise very logical, was - dictionary. Well, he still had that large pile of documentation that consultants left behind. Buried somewhere within these pages, he hoped, were elements to build his starting dictionary. Quickly scanning through documents he observed various ways of classifying and organizing captured information. Documents had a mixture of items in each diagram - activities, swim-lanes, inputs/outputs, practices, systems and databases, rules, some also had issues as notes, etc., but for most part were consistently charted, obviously coming from same flowcharting tool. Forget the flow - he thought, let me just scrape off all repetitive activities and inputs and outputs. He hired a student to structure data in excel spreadsheet and in a week he had over a hundred activities with close to four hundred unique inputs and outputs. Sorting and comparing data, he eliminated roughly a quarter of activities as being duplicates or inconsistent with what he defined an activity (e.g. a deliverable, an event or simple some reported metrics), and also close to a third of inputs and outputs due to same sort of semantic noise.

Equipped with what he believed was right dictionary to start with, he called first group of engineers into discussions - his own team. “Here are rules he said: using this dictionary, you will list all our activities and for each activity inputs and outputs that apply. Give me also idea where you think inputs come from and where outputs go to, but do not worry about that if you make a mistake.” It took them roughly forty five minutes to agree on list of activities and I/O-s within their scope of work, with several items added to the dictionary and few other re-named and/or re-defined. The champion asked his colleague overseas to do same exercise using same dictionary and to actually do interview by themselves. So they did. Interestingly enough, other team took also around an hour to complete the task. Results were astounding - total count of activities between two groups was eleven, out of which only three were unique to either organization, eight being common. Total count of I/O-s was 27, with nine unique ones, eighteen being common. Everyone agreed that level of detail was not the lowest, but very applicable for the purpose - mapping out dependencies between organizational teams. They also determined that their understanding of who provides them inputs and who consumes their outputs was very sketchy at best (what sparked curiosity for the next set of interviews).

Not only did the trial group obtain consensus on similarities and on differences, they could hardly wait to find out how the entire flow connects. Further interviews with other groups involved same approach - using a common dictionary each group, one at a time, was asked same questions: What do you do, how do you add value, what inputs you need and what outputs you produce?

Let me fast forward several weeks… The resulting efforts produced not only a consensus “as is” map at proper level of detail for fair comparisons. They also produced a very important list of gaps and defined all iterative loops. They also determined true cycle times between various deliverables in the process, as well as variances of cycle times. The assessment led to much more realistic placement of gates (around clusters of major iterations) and recognition of true value streams of achieving integrating events (a.k.a. milestone). Each I/O was then mapped to information systems authoring it, their common meta-schema was defined and opportunity to support common activities and I/O-s with same set of tools was determined. Total efforts took a fraction of time and cost originally planned for previously failed initiative. The company now guards its process know-how tightly, evolving its dictionary and mapping various value stream scenarios to continuously seek root causes of under-performance and new ideas for improved performance.

PLM framework is not difficult to obtain, it starts with recognition of specifics of product development and avoidance of forcing other frameworks more applicable to transactional and sequential processes. It also requires keen interest in letting engineers express themselves with their own lingo, letting them describe their activities as an integrated system of value added elements connected by explicit dependencies (interfaces), not as a snapshot of most likely sequence of deliverables captured on a piece of paper. Engineers know systems - they design them, they are also fully aware that they operate as an integrated system themselves. Let engineers manage their efforts with devices they understand, while ensuring their integration with the rest of the organization based on consistent set of principles for measuring and continuously improving performance.

Join us on June 27, for a webinar on the PLM frameworks. Link to the event announcement is here https://cpd-associates.com/download/index.cfm?download=Process0607&company=

To increase robustness of their business model, manufacturers need to be present in as many as possible product markets, as well as labor markets. However, becoming less sensitive to business disturbances on the global scale comes with a price. It is usually paid by sudden drop in product development throughput and upward burst in cost of operations. The two often compound into a vicious punch that can throw manufacturers on ropes for a prolonged period of time. Yet, globalizing is a must for growth. The key to successful globalization is achieving scalability of development and supply chain operations.

I recently visited a large volume manufacturer of automotive components to discuss their efforts to achieve scalable, global product development operation. When exposed to accelerated loss of revenue coming from their long term customers (Detroit 3), the company decided to rapidly increase global presence. Aside from few logical acquisitions, their globalization strategy was based on the premise that product portfolio, or assortment as they call it, will cover all market segments, ranging from a full spectrum of price/performance/volume contracts with OEMs to boutique aftermarket. With successful branding strategy that would give them an edge against other global, as well as local competitors.

To globalize operations, it is required to foremost standardize and normalize business processes, so proper control can be established to quickly comprehend and react to adverse trends. In the first phase, the company successfully normalized supply chain operations, which they found much more portable than expected. The company had some starting advantage in the fact that both their original operations and the ones they acquired use ERP systems from the same vendor, and had (other then using different terminology) very similar material and financial transactions flows. They say that, in brief, what it took was an agreement to reconcile terminology, followed by few organizational changes to streamline communications between corporate planners and local operations… and, of course, few pounds of Advil for the IT folks. But, they were quite happy with the results of the effort. Customer orders matched inventories, materials procured globally yielded better costs, global data masters were reconciled with local applications, even few unplanned opportunities surfaced to better optimize inventory distribution and increase fulfillment velocity.

However, when it came to standardizing product development process, challenges started creeping up, some perceived and some totally unpredictable. As one of their engineering managers put it: “We had to dig deep into our souls… It’s like trying to sequence your own DNA to figure out if you should shave in the morning.” Yes, engineers love to do that. But, that deep dive into the basic reasons could easily be why, every once in a while, they invent a “killer product” that has potential of sustaining their company for many years… until the next flash of bright idea. Therein lies the predicament. If you are a global company, are you better off with a number of autonomous dedicated development teams (that may compete from time to time), or should you try to standardize all efforts and manage them from a centralized command and control tower? Depends. We’ll discuss later what does it depend on. Back to our company.

Quickly after the kick off of the global research and engineering council, the company figured out that the metrics used for evaluating effectiveness of product development was largely missing. Furthermore, what it meant to be successful to one development operation, was not that much critical to the other. For example, one “pole of wisdom” operated in a tight partnership with OEMs and had become accustomed to somewhat longer lead time tooling and extensive iterative evaluation loops. In short, they thrived on optimizing for cost and volume. The other “pole of wisdom” excelled in fast decision making, taking risks with innovative offerings sold to high end customers and consumers hungry for differentiated performance. In short, they thrived on optimizing for performance and durability. Yet, products were conceptually strikingly similar, with naturally some differences in underlying technology and materials used. Nothing was overwhelmingly unique, while technology and knowledge was excitingly complimentary and convergent, what sparked the promise of a unified kick-a** global portfolio.

Another difference discovered was that development teams used very different approach to major decisions and process flow, what was a logical consequence of having to master different development drivers.

Cost conscious team would postpone conceptual design freeze until their customer validation results of the prototype were fully reviewed. No production layout drawings were even started before conceptual design was approved. That was embedded in the quality system and was not for negotiations - period. Proud managers had quality related blurbs on large posters all over their cubes. However, just takt between conceptual design freeze and production samples was over ten months, and was undergoing third cycle time reduction initiative in as many years (surviving various lean and six sigma attacks).

Performance conscious team would develop multiple concepts, evolve them through simulation, run the prototype in their own lab and combine tooling details for production samples (in parallel with engineering) from multiple already proven production designs. Then, relatively quickly they would fine tune the final production layout and tolerances. Manufacturing had a big say in the design, embedding the quality right in the product, vying not to having to say much about it afterwards. The overall takt from idea to production was ten months.

Nevertheless, first team could work on multiple designs in parallel providing they stagger their introduction times, and through serialized workload could do more work with less engineers. Second team could do less parallel designs, but in a given year would make more total number of designs, given shorter cycle time. Yet, total throughput per development budget was roughly the same. Hence, the teams could not achieve consensus on which approach is better for scaling. They sensed that the truth is in between, but could not advise even a basic roadmap for merging the two approaches.

However, product planning with different product introduction takts was spreading havoc across portfolio planning and marketing efforts that were trying to benefit from reuse and re-purposing of developed technologies. Soon enough, the idea of exchange of knowledge and reuse of technologies seemed more like an academic exercise than an executable business strategy. So much so, that global branding strategy (another pillar of globalization strategy) was now under board scrutiny.

Then, someone at the executive steering committee proposed that they should do in development what supply chain people had done. Compare and contrast processes at the level of detail that will build terminology consensus at least, knowing that the design and engineering tools they used were similar (same CAD, PDM and most of CAE applications), and products after all, very similar. In addition, they would determine the common metrics based on which both approaches can be compared and contrasted and then define a hybrid approach with common takt times and normalized phase-gate model for portfolio planning. The highest support for the idea came from - marketing and sales. IT and business architects were asked to help and they developed a plan to try same approach that they used in supply chain. Everybody said - let’s give it one more chance before we throw in the towel.

Did it work? What do you think? The closing of the story in the next blog… Drop me a note if you want to predict the outcome.

This topic keeps coming up in so many conversations with engineering managers and engineering IT professionals alike. Let me explain the predicament (blog style - no thesis here).

Bill of Materials (BOM) is a list of items that define content of a product in its physical form (hence materials). In other words, BOM defines what makes up a product. BOM can represent product content at various levels of granularity. For example, I recently had to replace my printer cartridge. If I am defining a printer for my purpose (context: usage and maintenance), the cartridge (just like printing paper) can be a single line item with price (let’s say I am ordering it on-line or purchasing it from Business Depot). If I have to manufacture the same cartridge (context: manufacturing), I need to break down the final delivered product into several items (materials that I purchase and produce to make the final assembly including packaging, documentation and labels), and so on. Two basic notions in this simple example are:

1. BOM is defining some physical content;
2. Depending on the context, the makeup of the BOM will change (in both scope and depth);

Well, the word BOM, because it implies a structural representation of the product content, has been also (mis)used for other purposes - for example to describe functional content or to describe any other information appertaining to the product using a structured breakdown. Thus, we have engineering BOM-s, concept BOM-s, commercial BOM-s, service BOM-s, …

I hope the level is set with this much, enough trivia.

So, where does the problem come from? The problem appears not from the content perspective, but from the context perspective. As development progresses through various, for the most part parallel, stages of value added work (concept, detailing, prototyping, manufacturing process design, sourcing, …), the contexts within which the content evolves change and multiply. At some point, what is commonly called BOM, actually represents an entire ontology of associated entities that can be classified and re-purposed into multiple structured representations. The information about product thus may reach critical saturation where no single authority can effectively manage the entire scope and depth of “the BOM”.

So, how do we solve the problem? Well, this is where discussions heat up. I found two generic approaches in practice (with multiple subtypes).

First approach, traditional one, is to select a single representation of the BOM as a controlled master representation. In other words, choose a subset of the entire ontology as a structure that meets most critical process/business control needs (typically manufacturing/purchasing/fulfillment or cost/assets oriented) and use it as a master structure that all other structures will somehow relate to. This is very pragmatic approach, because it will satisfy integrity and change control of most critical product information. The strengths of this approach are primarily integrity of information and scalability. The limitations of this approach are, due to deliberately severed ontology, related to the process. In order to maintain information accurate and relevant, specially trained professionals need to collect and navigate the BOM from all control points of view (e.g. engineering, purchasing, manufacturing, sales,… all need to “follow the structure”). Another limitation is that control appetites inevitably grow: can we add quality info, can we add sourcing info, can we add some 3D design info? However, once the floodgate of tightly controlled information open, this approach can deteriorate into change control slowing and stifling the entire process. The key decision here is that scope and depth of the BOM has to be determined by trade-off between change control and speed.

For this first approach (let’s call it - Control BOM Management approach), transactional systems with normalized databases underneath are information technology solutions made in heaven. Transactions can be programmed at entity or attribute status change with change initation/approval workflow rules also with entities and attributes. Data can be captured in time series with change logs, and all associated rules of controlled change implemented, and so on. What is very strange (sometimes entertaining in a cynical way) is the entire discussion of how should this approach be implemented - in ERP or in PLM (read PDM)?. It simply does not matter, other than choosing the right tool enabling the purpose - control. If control BOM management approach is followed, the only clean way to use it is to make one tool the master and all other slaves of the controlled information. Quickly realizing this fact, the IT campuses engage in religious battles that add little to the overall understanding of the business trade-offs. Sometimes, if lucky, product sub-structures selected for control can have cleaner cut (e.g. no bi-directional associations), so different systems can equally exercise BOM control (I found this in contract electronics). But, I have seen the cases where BOM control was simply enforced as an opportune IT decision, although it was not a clean cut (found in medical device industry). Symptom to look for - change management is slowing the process down.

The other approach is to use the entire spectrum of product related information and to structure it in a form of pure ontology, whereby every piece of information preserves its natural associations to multiple entities that can then form a multitude of structures for representations in various contexts. Let’s call this approach a Total BOM Management approach. This approach preserves linkages between various content items, reinforcing relevance and greatly enhancing the abstraction of the information. However, some information can leak or get out of control, since associations constantly evolve and are difficult to contain as a single-source authored control structure. Thus, total BOM is a riskier route from the change control point of view. Total BOM approach also presents challenge to scaling, since there are only two physical ways of implementing it: everything in a single DB entails heavy server to client traffic (often thick client in order to implement context filters), or federated registry and repository entailing heavy messaging traffic.

However, the advantage is collaboration, ultimately much higher speed and throughput of the engineering process due to elimination of waste associated with information search and update (I found this waste in excess of 50% of total effort in some companies). You can find a brief overview of the total BOM management solution (single database flavor) from Class Technology here: https://cpd-associates.com?download=BOMTrends

So, we have a trade-off between tighter integrity and control of a subset of information on one hand, and relevance and abstraction of all information on the other. Hybrid approaches are also possible, but I’ll leave them for another occasion, since we will cover this topic in more detail at our annual roadmap conference http://www.cpd-associates.com/index.cfm?content=include_conference07.cfm

Naturally, the questions arise - what approach to use and when? Let me borrow VRM (formerly known as VCOR model) methodology here. VRM states that, in order to sustain competitive differentiation, companies have to excel in a subset of the following seven strategic priority dimensions: Innovation, Assets, Cost, Reliability, Adaptability, Customer and Velocity. In that case, the rule of thumb for choosing BOM management approach is this:

- If your company chooses to differentiate based on Velocity, Innovation and Adaptability (adaptability is fast organizational response to changing underlying business conditions - e.g. merger/acquisition, outsourcing, new products/markets,…) you have to master total BOM approach;

- If your company is differentiating itself predominantly on Assets, Cost and Reliability master control BOM approach (but then select only the most critical information from the entire ontology to avoid making it impractical). You have to then decide on ERP versus PLM on a total process efficiency basis (user level of training, data elements already contained in the database, ability to deliver reports, ability to execute rules of change management, etc.)

- If Customer is your primary focus, then you can go either way, depending on how the other six priority dimensions stack up underneath.

One way or the other, it is recommended that manufacturers first define their overall product ontology. Whichever way you choose to manage BOM, defining your own product ontology will help you determine the solution requirements:

- If you choose control BOM management approach, it will help you determine the boundaries of effective change control and what linkages lie outside of the master BOM scope and depth.

- If you want to use total BOM approach, it will help you enumerate various structures and views that you need to provide and to establish logical associations between them that will cut through the overhead of information search and reuse.

The ontology exercise will give you a plenty of ideas how to improve collaboration and process coordination. Often, if your product ontology is well defined, a simple registry and repository with version control, coupled with a portal for document management can suffice to improve your process. That initial thinking project will get you into a completely new paradigm of managing product information, particularly if you are contemplating practicing systems engineering. These are great times for testing and trying your understanding of your own product ontology. The basic technologies are very affordable, while learning by going through such an exercise can be priceless.