What I learned this week … came from a presentation given by Jim Heppelmann and Brian Shepherd of PTC and this week’s PTCUser conference. 
The presentation gave a view into some of the interesting things that PTC is working on in their solution set, and a peek into their vision for the future of PLM systems. More accurately, what Jim and Brian said the future for their Product Development System as opposed to “PLM,” which is an important differentiation for them.
Overview
User conferences are a great place to let software customers know about all of the great new solutions they should be considering. This conference is no different, PTC has been busy and they have a lot to show off. Of particular interest to me was getting an update on their views on the use of social computing techniques in PLM. I have posted before on PTC’s social product development strategy, and I was looking forward to the update. The most interesting part of the conversation wasn’t directly about social computing, but about how these “community” applications fit in with the rest of PLM…err, I mean PDS.
Enter the “Triad”
I will not do this justice here, so I will introduce it quickly and we can drive some conversation around it in the comments. The core message is that there have been two primary sets of applications for product development and engineering, and now there is a third category. The concept is PTC’s, but I am putting it in my own words below. The three legs of the stool, then, are:
User – This are the individual productivity tools. This is what makes the engineer more efficient in their work. These tools include CAD, CAE, and others. They are the “Microsoft Excel” types of tools, those that help one person at a time do their job.
Corporate – The are enterprise applications. These solutions provide control and coordination across a business. They are typically more complicated, and sometimes require a trade-off between personal productivity and corporate value (such as capturing and managing IP). Many times, users feel these solutions are an extra part of their job as opposed to an enabler, and that they have to “feed the system.”
Community – These are social computing applications. These help companies collaborate and share information in a lighter weight, looser environment. This is the new area of solutions that promise to drive better team performance.
I have some additional thoughts and questions, but I will hold them for now. The one piece I will share is that these areas are not entirely distinct, and that they get more value when they are together. The value gained from one does not exclude potential value from the others. A quick example is that by logging the collaborative comments in the “community” applications, you are creating new corporate knowledge and IP – but without feeling like you are “feeding the system.” So maybe in the long run the “community” category helps provide some of the control but with a lower level of effort from the user? OK, enough on that from me right now.
Implications for Manufacturers?
In the short-term, this is a new way to look at social computing applications and how they fit with your individual productivity tools and your enterprise applications. It is a way to think about how to complement your current solutions with new capabilities. It is also a good metric to use when evaluating the vision of your PLM solution provider. Are they looking out for all three legs of your triad? They should be.
So that is what I learned this week, I hope you found it interesting. Let me know what you think.
Gee that sounds an awful like the three layered model we put forth last year as part of our PLM 2.0 vision enabled by V6 solutions:
Creators = Users
Corporate = Collaborators
Community = Communities
It trisects the solution space – so what? Since the model could be applied to CRM, ERP, SCM, SFA or other user-group-organization ecosystem, how does this “insight” uniquely inform any PLM solution?
As a literal model, it’s more of a “collaboration continuum” than a stool, since any one leg can, in fact, be useful on its own. And these “legs” are rather fuzzy: the distinction between community and corporate is somewhat arbitrary, and determined as much by implementation decisions as by a crisp boundary. Similarly, the distinction between individual apps and collaborative solutions are often a matter of degree, rather than kind (Google docs, anyone?).
Without offering much rationale for the customer value of such segmentation, it seems more useful to the vendors for drawing lines between applications rather than an interesting vision of the future.
Stan,
Sorry for the delayed reply, still catching up from a couple of weeks of travel. There are some similarities, although I think it is probably a little bit more aligned with PTC’s prior “create, collaborate, control” message. In this case, the solutions are a bit more aligned to it than they were before because the “collaborate” was tied in closely with the “control.”
How I think it differs is the (at least partial) separation of “control” from collaborative and community aspects. The message from PTC (clearly tied to Social Product Development” is that they heavier, enterprise-class software required to manage configurations, release to manufacturing, etc. is not aligned with the needs of a “sand box” environment collaboration is more free-form and loose.
My opinion (I know you didn’t ask, but are dying to know) is that the intersection of collaboration and control holds tremendous opportunities. Let’s be honest, a lot of conversation/collaboration happens outside of PLM today. If PLM can capture free-form collaboration unobtrusively and turn it into usable corporate IP, we would have the needs of the creators and collaborators met – but with much less effort required to control the information. To me, that is the significance of what PTC is talking about.
Does it need to be in three, distinct sets of applications and architectures? My opinion is no. That the natural evolution of “create” applications is the addition of easy, seamless collaboration and control. Likewise, the “collaborate” applications will evolve to generate control as a byproduct of the collaboration effort. I know this is a lot to ask, but I think the value is there. It won’t be fast, but it will evolve.
PS – I know that at least one person I know will disagree about different architectures for different functions. I am open to learning from those opinions, and I would probably agree that most architectures today are poorly suited to do all three.
Ed,
Thank you for your opinion. I agree that there are aspects of each of these areas that are blurred. And while I accept that you could apply this model to other enterprise applications, I also contend that the differences are much slighter. Let’s take CRM as an example. The tools required for a sales person (or a marketing person) to “create” sales leads and campaigns is the same solution used to “control” that information. The distinction in that solution set is almost negligible. Likewise, to “collaborate” on a sales lead probably requires very little difference other than some nuances in the security model and ensuring it is available remotely. It requires simple forms, business rules, and database storage/retrieval. So no magic there. So far, I am agreeing with you.
But… (and here is where the real conversation starts):
– The requirements to create a 3D model for a product is much different than creating a record in a relational database for a sales lead
– The ability to collaborate on those models (due to size, complexity, and availability of the authoring tools) is much different than reviewing a record in a RDBMS and perhaps making a comment (or even a redline)
– The ability to control the designs in a PLM system (size, syncing between multiple sites, revisioning, associativity, etc.) is more than it takes to manage a sales lead.
– Finally, you can’t ignore history. What PTC is proposing is an evolution. I don’t know that they would say that there “should” be 3 legs to the stool if PLM were starting from scratch. My opinion is that they will blend over time. But I also believe that they are relatively distinct today, and that the model will help PLM solutions evolve appropriately.
What are the implications for users? I hope I was clear about that in my post. The practical implication is that you make sure your strategy and your software vendor covers those three aspects. I am not proposing that they have to be separate product lines, architectures, or even priced modules. It is a logical framework that can put a different lens on the way the view PLM solutions. It should not be the only one, but I think it is a valuable one.
My net comment: If Google were creating a PLM system right now they would likely break all of the rules and do something fundamentally different. I would love to see it. In the meantime, we have a lot of large PLM vendors with a lot invested in existing solutions that can’t rip and replace the way their solutions work. Nor can their customers. It’s not a perfect model – but it’s not a perfect world.
Thank you again for your opinion, I realize I took one specific example. I would love to hear more of your thoughts on this now that you have a better idea of where I am coming from.