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