Do Model-Based Initiatives Require Process Change?


Not all that long ago, I started a blogfight with Jos Voskuil. Jos had written an excellent post titled PLM is Journey. In it, Jos suggested that PLM is not an IT solution, but a journey that an organization takes involving the improvement of product development. I wrote a response titled PLM Requires Business Transformation? Bollocks. Pardon my language, but as you might guess, I didn’t agree with Jos’ theory, especially in the light of the fundamentals of PLM like data management, design release and change management.

The point to all this lies in assessing the need for process change for any technology adoption. In this case, I want to take a hard look at Model-Based Enterprise initiatives. I have an opinion, of course, like I always do. But I’d like some feedback on this one in particular. In this post, I propose that the adoption of Model-Based Enterprise initiatives do, in fact, require process change within an organization.

What is Model-Based Enterprise?

If you’re not familiar with MBE, there’s a very good resource out there that you can reference: the Model-Based Enterprise web site. It’s jointly run by the US Office of the Secretary of Defense, The Army Research Laboratory, BAE, NIST and many more. Here’s their definition of MBE.

What is the Model Based Enterprise? Here is a technical definition: A fully integrated and collaborative environment founded on 3D product definition detailed and shared across the enterprise; to enable rapid, seamless, and affordable deployment of products from concept to disposal.

My take? Model-Based Enterprise initiatives focus on embedding information into 3D models for their use across the enterprise in organizations like service, manufacturing, quality and much more.

Dig deeper if you need to at the site. But I that’s enough for our purposes here.

Some Context: Desktop Applications and Change

Before we dive into MBE, let’s talk about desktop applications and whether or not they require process change. Normally, desktop applications, like Computer Aided Design (CAD), Computer Aided Engineering (CAE) or Simulation, Computer Aided Manufacturing (CAM) and editors for documents, spreadsheets and more and personal productivity tools. Individuals use them to do their tasks faster and more efficiently. As a result, most do not associate desktop applications with process change. Traditionally, adoption of these technologies don’t require changes to how organizations execute their design, simulation, manufacturing and other processes. Instead, procedural changes are affected. This simply means that the way in which individuals do their work is affected.

Now, I know that some of you disagree. Many of these tools are evolving to collaborative creation and editing tools. Look at Google Docs. Multiple people can modify a document or spreadsheet simultaneously. In fact, other peoples changes are color coded. You actually see them being edited in real time. So yes, such technology affects multiple people now. And yes, it’s a fair debate that could imply process change. But my point here is that traditionally, these desktop applications affect individuals, not organizations. As a result, procedural change and not process change is associated with them.

OK. Let’s proceed.

Model-Based Enterprise Efforts and Process Change

So what makes me think that MBE initiatives imply process change? Well, it wasn’t my fault. I blame Ram Pentakota.

Ram is a Global Chief Engineer at Johnson Controls, a large automotive supplier. He is also heavily involved with the Strategic Automotive product data Standards Automotive Group (SASIG). Think of it as the global version of the US based Automotive Industry Action Group (AIAG).

Back in May 2013 at the 3D Collaboration and Interoperability Congress (3DCIC), Ram presented an update on SASIG’s perspective of MBE. It was a great presentation. You can review his slides and listen the entire presentation at the 3DCIC site. It specifically reviewed four use cases for MBE, detailing what information needed to be embedded in 3D models for each one. Furthermore, it outlined who owned such information, and as a result needed to embed the information, as well as who would consume such information. Essentially, it called for many different stakeholders to be involved with MBE efforts. It also called for specific organizational processes by which such deliverables should be created, delivered and consumed.

And therein lies the basis for my opinion.

I’m convinced that MBE is an organizational effort. Many different stakeholders must change how they participate. Even though an MBE initiative could rely completely on desktop applications, merely installing software won’t get it done. In fact, I’d argue that unless you make process changes, an MBE initiative is almost doomed to failure.

Recap and Questions

  • Model-Based Enterprise initiatives focus on embedding information into 3D models for their use across the enterprise.
  • Desktop Applications are usually associated with procedural change, not process change. Many new  versions of desktop applications, however, enable collaborative creation and editing of deliverables, which can imply process change.
  • Ram Pentakota, a Chief Engineer at Johnson Controls and SASIG representative, presented several MBE use cases at the 3D Collaboration and Interoperability Congress. You can review his slides and listen the entire presentation at the 3DCIC site.
  • Those use cases affect how many different stakeholders create, share and consume MBE deliverables. It also carries implications for how organizations need to change how their processes.
  • In my perspective, process change is truly required for MBE efforts as a result.

Hmm. Feels a little funny arguing that PLM doesn’t require process change, yet MBE does require process change. Crazy.

Anyone ready for a BLOGFIGHT? I know there’s a few that probably won’t agree with my perspective on it. I’d love to hear your opinions. So sound off, leave comments and let us know what you think.

Take care. Talk soon. And, again, thanks for reading.

This blog post has been licensed for hosting by PTC. The concepts, ideas and positions of this post have been developed independently by Industry Analyst Chad Jackson of Lifecycle Insights. 2013-2014 © LC Insights LLC

This entry was posted in Reinventing Design, Uncategorized and tagged , , , , . Bookmark the permalink. Trackbacks are closed, but you can post a comment.

One Comment

  1. Posted Dec 11, 2013 at 2:32 pm | Permalink

    It is funny, through out the article the word “Standard” was not used.

    PLM and MBE will fail as processes until they are set up as a standard and with the vested interests of Dassault, PTC and Siemens that is not going to happen soon.

    I have had rich experience working as a contract engineer in my days on the board. I would walk into any job that I was hired based on my engineering experience (not like today, based my CAD system experience). I would hit the ground running. Why? Because all companies worked on standard engineering practices and processes.

    Boeing used the MBE to design and build its 787. I sell to the Boeing suppliers and they have laughed at these efforts, mostly working around the ridiculous demands. I have heard of stories about parts that could not be made, or changes to parts months after all have been delivered, Titanium parts!!!

    But this story I have been waiting for.

    One of my suppliers told Boeing there was an interference in an assembly he was manufacturing. How did Boeing handle that. Did they go back to the model and revise the incorrect part and release the new revision, sending it to the supplier?? Ha ha.. How long would that take? A couple of weeks, a month, I am not even going to go into the verification process of a Catia solid model used as the authorizing document. I mean they are designing parts for a plane that goes 500 MPH.

    They sent him a sketch and allowed him to modify the parts. Official document, ha. Once you violate the standard revision path, you are opening Murphy’s door.

    In the past when the drawing was the authority we would create an ADCN. Advance Drawing Change Notice, it would be stapled to the drawing. These could be instant fixes, checked by the checker and signed off by the lead engineer, incorporated in the documented history of the the parts. (This was all in the realm of drafting)

    The PLM and MBE process is just to cumbersome. It was designed by people that think all engineering is done perfectly. Boeing recommends that it suppliers use a 3rd party verification and ECO packages. There are even 3rd party program to turn PMI (3D drawings) into conventional drawings.

    You pay millions for a PLM system and it can not talk to your suppliers without 3rd party software programs. No experienced Boeing drafter could take PLM seriously. Oh, I forgot to tell you, Boeing got rid of the drafting and document control department prior to the implementation of PLM. The engineer is now the chief cook and bottle washer.

    Today… it is a mess. These efforts will all fail and we WILL return to some sort of standard, hopefully duplicating the success of the past standard that was establish over centuries of development. All the industry needs is more IT folks and PLM consultants.

Post a Comment

Your email is never published nor shared. Required fields are marked *

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <pre> <q cite=""> <s> <strike> <strong>

  • Archives

  • Connect with PTC Creo