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

2 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.

Leave a Reply

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