The MBE and PLM Lord of the Rings Saga

Two common questions seem to come up often during client meetings regarding the implementation of MBE and PLM. One is generally from the MBE champion who asks, “How do I get more buy-in and support from senior management?” The second question is usually from a concerned senior manager who asks, “How do I implement and justify a return on my investment for such a wide-ranging enterprise initiative?”

While both questions are valid, they are reinforcing the misperception that MBE and PLM implementation is a “Big Bang” event that can be rolled out in 18 to 24 months and neglect the larger picture of MBE and PLM implementations. Enterprise-wide roll-outs affect the entire organization, not just a couple of departments. MBE instantiation must include all Engineering, Manufacturing, Procurement, and Quality functions plus tie into some form of data management system. PLM implementation can be more complex yet, as it acts as an umbrella that connects all engineering systems, as well as Requirements Management on the front end, and Maintenance, Repair, and Overhaul Management on the back end. Add in existing point-to-point system connections that may or may not be documented, and there is justifiably a great fear and risk of system instability. So, having established implementation complexity, how does one deal with the elephant in the room?

The first thing to do is to admit that MBE and PLM implementation is a journey not unlike the Lord of the Rings saga. The end goal is enormously lofty, without an understanding of the obstacles and issues that will be encountered, and often a reluctance to embark on such a large endeavor. A common response at this point is, “Why? Why should I invest in this epic journey that is going to disrupt the way I think and do business?” The answer should always be, “To make life easier.” Management’s life is easier because accountability and traceability of product information reduce cost and liability. Engineering’s life is easier due to commonly established processes, increased reuse of data, and a single source of product definition. Procurement’s life is easier because the engineering data provided to suppliers is up-to-date, correct, and easily accessible. Manufacturing’s life is easier because accurate engineering information is fed into the manufacturing equipment without reproduction. Quality’s life is easier because the inspection data is digitally associated with the original engineering requirements, and defects become less common. The customer’s life is easier because the collaboration makes for a lower cost, more robust product with a shorter lead time. The digital thread journey is necessary because it will benefit you, and those you rely upon, whether you are a hobbit or a machinist.

Now that the basic Why has been answered let’s move on to the Who. Who should I have on the implementation team? As Gandalf knew, the success of the endeavor cannot rest on the shoulders of a single individual, although specific segments of the journey might. Therefore, a team of individuals with varying talents and frequently competing interests need to come together for the common cause. All systems, functional areas, and senior management must have a voice and representation on the team. A focus on team communication to identify common goals, develop creative tension, and establish relationships is imperative. Seeing an intimate level of engagement between implementation team members generates the necessary buy-in for users and functional areas to embrace new processes. It is also necessary for the implementation team to understand when team leadership must pass from person to person to avoid power struggles, traps, pitfalls, and take advantage of unique talents.

Let’s get back to that proverbial elephant in the room to discuss the How at a high level. It has been said that to eat an elephant, it must be done one bite at a time, lest one choke. It is true that one may consume a large amount of food, but only with the requisite time to digest before heading back to the table – just ask Bilbo. Likewise, MBE and PLM should be implemented in multiple segments with time for users to adjust to changes and provide feedback to the implementation team. A phased, incremental implementation creates massive buy-in from the end users as they see that their input is valued and that the implementation is not simply being rammed down their throats. The conversations with the end users provide the implementation team with opportunities to discover those hidden point-to-point connections that may exist between systems. It also serves the implementation team by shifting their focus from the seemingly insurmountable big picture and placing it on the immediate roadblock ahead.

Obviously, every implementation will have its own unique circumstances specific to the organization and will not be without its share of disruption. The grand scale of MBE and PLM implementation makes that almost a certainty. However, once the journey is complete, there will be peace in the Shire once again deserving of a pint with Frodo and the lads down at The Prancing Pony.

Save

Save

Save

Save

Save

Save

Save

Save

Save

7 thoughts on “The MBE and PLM Lord of the Rings Saga

  1. Very wise and very well written. There is just no substitute for experimentation and organizational learning. No set of requirements is ever fully accurate, and there are indeed hidden communication streams that can be missed. I would also offer that PLM is best viewed as a set of business practices and procedures. There is no such thing as a single source of the truth. In the big picture, MBE and the Digital Thread are intended to make product information available to all business operations requiring complete information in the context of the responsibilities of knowledge workers in that area. Digital Thread assets always reflect the latest releases of authoritative information. In that sense, the Digital Thread is the last mile of the PLM journey.

    • Thank you for your positive comments. I would like to expand on your comment about a single source of truth. Truth in product information is a matter of perspective. Manufacturing may have its source of truth in a STEP or JT file. Quality may have its source of truth in a QIF file. However, those files are all derivatives of the original native CAD model developed by Engineering. Lifecycle management ensures that the associativity of native CAD and its derivatives is intact and traceable to a specific source part revision. This digital pedigree establishes authority should a conflict develop. I think that I understand what you are saying about the digital thread being the last mile of the PLM journey because it is extremely difficult, some would say impossible, to have a digital thread without PLM.

  2. A few comments on the origin of the term. The “single source of the truth” concept sprang from the struggle between battling systems in the old days. CAD grown PLM versus those that came from the ERP world. Customers and suppliers struggled and spent millions to develop a reliable integration between CAD grown PLM systems and ERP. CAD folks brought the light weight visual approach where ERP grown PLM brought deep functional integration though text based. The attempt to harmonize these solutions into a single reliable solution failed in most cases. The need to constantly sync the two systems caused inconsistencies in the data and hence various versions of the truth. This drove the need for “a single source of the truth.” There are different ways to try and get there and I am sure we will be discussing these in the coming posts.

    • Thank you very much for the background information. The concept of the single source of truth as I have mentioned before is a matter of perspective for the end user. However, hierarchical traceability is the founding cornerstone of this prime truth. That is, the ability to identify derivative data branch points and follow the path upstream to the parent data. Pragmatically speaking, this is easier said than done as you have pointed out. Point-to-point data exchanges between data management systems must be mapped, analyzed, and understood during implementation to avoid data-stomping and maintain clean, traceable data.

    • This analysis is spot on Peter. In my experience over the past few years, the biggest misconception is that the MBD CAD Model needs to be the single source of truth. In my opinion, the “Part” needs to be the single source of truth, whether it is a WT.PART in PDMLink or any other definition of the “Part” in whatever PLM system being used. The MBD CAD model should really only include the “Geometric Product Specification” that includes the geometry and it tolerances. There will also need to be some parameters/attributes that define the MBD model, however a lot of the information that has been stored as textual data (notes, parameters, etc.) should be moved from the context of a CAD Model as the authored document to the PLM “Part”. I believe it is called “Part-Centric Design”. So no our PLM systems are no longer CAD Data Management/Product LifeCycle system, but must also be perceived as a design tool. That is a pretty significant paradigm shift, especially for long time CAD users who often perceive PLM as a necessary evil to manage changes to our CAD data. Great article Duane! I really enjoyed it.

      • Forgot to add. The CAD document is a document that describes the “Part”. So by making the “Part” the single source, you also have the ability to include any documents related to the “part” in that definition of the single source of truth.

      • Thank you for the additional insight. You are correct that MBD and the management of data is a paradigm shift – more so than many of us like to admit. There is an ever greater blurring of lines between what system controls which data. Just ensuring that data is controlled is the most important cultural change we can make, regardless of what system controls the data.

Leave a Reply

Your email address will not be published. Required fields are marked *