Why we need a new word for collaboration in PLM

Oleg Shilovitsky, one of the most thoughtful bloggers in the PLM space, has tackled one of the biggest issues in manufacturing IT: the need for people to work better together. As Oleg says, “To help people to work together is extremely important.” And, to no one’s surprise, Oleg reminds us that “collaboration is one of the most overused words in Product Lifecycle Management.”

Think about these two polar-opposite comments. One stresses the need for better teamwork in product development. The other notes the wreckage of numerous attempts at solving this problem with collaboration technology. That’s why collaboration has such a bad name: everyone knows it’s a code-word for something only an IT guy can love (and use).

That hasn’t stopped PLM vendors from trying, of course. The opportunity to (finally!) extend PLM to users beyond just R&D is so compelling, they have to keep trying. Never mind that it’s stuffing an overweight dude into a Speedo bathing suit. At the opposite end of the PLM vendors’ approach — where Oleg labels simplification an “interesting trend” — one loses domain specificity. Betting the product development process on a technology that doesn’t understand what a product is won’t succeed either. If it could, then email — the simplest and most generic form of collaboration — would have settled the whole question. Chatting in a Google Docs document might be “fun,” but it doesn’t help a design team manage all the different types of deliverables it cares about.

For all these reasons and more, we avoid the term collaboration, something we are grateful that Oleg noticed. Instead, to differentiate Vuuch from failed attempts at both generic collaboration and PLM-based collaboration, we propose the term interaction. And we insist that interaction must be based on social technology to avoid the black hole collaboration fell into.  Allow me to explain our logic in a couple of graphics.

We assert that there are plenty of tools to create content. CAD, Microsoft Office applications, 3DVIA Composer — to name just a few examples — all excel at allowing different classes of users to create (or author) content that is enormously valuable in the product development process. 40 years of progress in creation technology doesn’t lie: these apps have proven their value. We also believe there are plenty of good systems for managing that content. Whether it’s a project management system, ERP or a PLM system, the actual digital artifacts created by the product development team can be stored and managed effectively.

It’s the third layer in our graphic above that hasn’t been solved. It’s the messy work of product team interaction that has stubbornly resisted all technology attempts to automate it. There are many reasons why but one of the most important is that most legacy collaboration systems have seen themselves as extensions of the create and manage layers. They have tried to “extend” a structured, workflow-based approach to the dynamism of product development. Worse, most couple the straight-jacket of pre-determined workflow with a file-based metaphor (poster child = Windchill ProductPoint). These are bound to fail. When people are involved, basing interaction technology on a file metaphor and/or requiring specific processes is anathema to people who “just want to get things done.”

Enter social technology. The beauty of social technology — even in Google Docs Discussions — is that there are no rules and no predetermined content. Groups of users can roam wherever they need to, discussing and acting on issues in the way they think most appropriate. The problem with Google Docs Discussions is that a Google Doc doesn’t know a product from a river. It’s completely domain-knowledge-free. This is the Achilles heel of Facebook and Twitter (and the enterprise wanna-be’s like Yammer). They are know-nothings about the very thing the development team cares most about: its product.

If you’ve read this far (and thank you for doing so), you won’t be surprised to know Vuuch has the solution. We propose to automate the interaction layer using social technology — but social technology that, at its core, understands what a product is. We believe this is not an extension of existing systems, though it embraces the tools and technologies in the create and manage layers. It is its own layer, what we call an enterprise social system.

The interaction layer effectively automates product team interaction by using social techniques (like friending) to allow the team to work on things it cares about. And those deliverables can be created in the common tools of the create layer and they can be managed by the manage layer. Instead of trying to stretch good technology beyond its capability, a social system solves the collaboration quandary Oleg talks about by revolutionizing the very nature of team interaction.