So what is Google up to with Circles?  My belief is they fully understand the problem of information overload that results from social streams.  Yammer, Jive, Facebook, Twitter, or any other social application [...]]]> I was reading Oleg’s post http://plmtwine.com/2011/07/07/google-plm-and-the-product-data-sharing-models/ on sharing models and Google circle and it got me wondering what they are up to…

So what is Google up to with Circles?  My belief is they fully understand the problem of information overload that results from social streams.  Yammer, Jive, Facebook, Twitter, or any other social application generates a stream of information that flows by so fast it results in feeling overwhelmed.  Would reducing the amount of email or multiplying the amount of email by 100X make each person on a team more effective?  I would bet people already feel overwhelmed by the amount of messages they get and that doubling, tripling and worst multiplying this by 100 is not what people are looking for.  But this is exactly what will happen if a message is generated for everything that happens…

IMHO Google is trying to provide a way for people to collect filter the streams you care about by allowing you to decide who you care about.  While this is a very good idea and may be very effective in our consumer lives it will not work within the enterprise.  Take a simple case of a design engineer and purchasing person – the designer and purchasing person are connected based on the things they are working on, not based on a personal connection.  There are many things the purchasing person may “post” that have nothing to do with what the designer is working on.  The designer only wants to see “posts” that are relevant to what the designer and purchasing person are working on together.  For example if the purchasing person is buying prototypes for a part the designer is working on and there are issues, then the designer is interested.

In the case above a circle is needed for this part.  The team needs a way to organize the problem the purchasing agent is having with the prototypes.  The team needs a way to track this issue, no where it stands and ultimately resolve it in time.  This is what  a Vuuch Page does.  A Vuuch Page creates a dynamic circle for the part.  A Vuuch Page circles together the activities that need to be resolved and those people involved.

Want to learn more about Vuuch Page and content specific connections then register for a webinar at www.vuuch.com/webinar or drop us a note at contact@vuuch.com.

So [...]]]> Although I’m not sure if it was SharePoint or ProductPoint that was once the new love… it is now clear they have the makings of an ugly divorce and customers are getting another technology dear john. In the beginning emotion and promotion was rampant – Like any new love affair…

• http://www.ptc.com/appserver/wcms/standards/textsub.jsp?&im_dbkey=72398&icg_dbkey=21
• http://www.ptc.com/WCMS/files/72439/en/6227_PLA_PP_DS.pdf
• http://beyondplm.com/2011/05/05/plm-sharepoint-and-productpoint-lessons/
• http://www.deskeng.com/articles/aaasaj.htm
• http://www.imakenews.com/ptcexpress/e_article001205333.cfm?x=bd69qP1,b3jsqcsB,w

So what went wrong?

Could it be as Tyler Cox said, in a comment about ProductPoint - “This is the dumbest idea that PTC has ever pursued.” and “The things they are proposing to use this tool for can be done in 1/2 the time with a 1 minute meeting in my cubicle. It’s a solution in search of a problem.”

Or is it something else?

• Did SharePoint fail to scale?
• Did a lack of an upgrade path to full Windchill scare people away?
• Or as Al Dean questioned, was there just no revenue profit in it?

And what about Social Product Development?

While it is clear that social still has links at PTC and that these are fueled by SharePoint… why then remove the data management aspect of the solution? Maybe I’m missing something but I thought ProductPoint was the meat behind the Social Product Development message.

Al’s article quoted Tom Shoemaker as saying “In truth, this was simply a natural outcome of our ongoing rationalization of our product portfolio” and that customer feedback “had been generally positive, particularly around ease-of-use.” Doesn’t hearing “in truth” make you think about a guilty politician taking the podium to explain their indiscretions? And how could something that was launched less than three years ago need “rationalization”?  I will ignore “generally positive” as that might be good.

OK enough questions.
If you simplify what a product development team does you will discover they must author content, manage this content and interact in order to make decisions about the project and product they are working on.  Therefore it is clear that product development teams use three distinct layers of technology (Create, Manage and Interact).  And it is also clear that users of any one tool from the create or manage category are a subset of all the people who must interact during a project. Therefore it can be concluded that the interaction layer cannot be rationalized into either the create or manage layer.  Which offers an answer to why ProductPoint failed, as ProductPoint attempted to rationalize the interact layer into a manage tool. I know many of you are crying bull - interact is just another name for collaboration. Well it is not. Interaction is the next generation of collaboration. Collaboration tools were focused on a subset of users and in any product development project the solution used to interact must reach everyone involved. Which means it must be a separate solution that can be used by every person involved in the project, no matter who they are, if they are an employee or partner or what tools they use for create and manage.

…The real problem is the CAD-based work processes to which most product development slavishly clings. Vuuch requires potential users to think outside the box about their product development methods.

We have been [...]]]> Writing about the release of Vuuch 4.5, GraphicSpeak pinpoints the real issue preventing product development teams from improving their core processes:

…The real problem is the CAD-based work processes to which most product development slavishly clings. Vuuch requires potential users to think outside the box about their product development methods.

We have been on the soapbox for some time that legacy “collaboration” solutions in which PLM systems simply bolt on SharePoint simply cannot work. Now that PTC has thrown in the towel on just such a misadventure, we believe the time for true social technology has arrived.

As Oleg points out there are two distinct things going on.  There are, as he states, systems of record and WIP tools.  While I agree the [...]]]> This post started as a reply to Oleg’s post on work-in-progress (WIP) versus system-of-record http://plmtwine.com/2011/06/06/plm-work-in-progress-vs-system-of-records/ but by the time I was done I had written more than a comment…

As Oleg points out there are two distinct things going on.  There are, as he states, systems of record and WIP tools.  While I agree the system of record vendors have always wanted the WIP tools to just go away I do not see this ever happening.  A system of record implies structure/complication and therefore they cannot serve the WIP needs of a team.  Systems of record force a paradigm that does not make sense for WIP.  For example PDM/PLM is built on the idea of a “file” and that the “file must be managed”, which is great if there is a file, but many times there is no file, and in any project there is a ton of time when there is no reason to manage the file.  For example if I have a GPS that I am designing and based on where we are in the life-cycle the “Electronics” are not represented by any files.  What do I do in PDM/PLM?  And what if the files I have are a random collection of things likes sketches, calculations and spreadsheets that the team is using to make decisions?  What value is there for me as an individual user to check these in and why should I stop using email?

Analyzing the current working environment and tools people are using and you will see there is three layers.

• Content Creation tools – Things like CAD, PowerPoint and Visio.  Applications that create files.
• Content Management tools – Things like ERP, CRM, PDM and PLM.  Applications that manage deliverables.
• Interactions tools – Things like video conferencing, phones, meetings, whiteboards, email and lists.  Applications that help people make decisions and track what needs to get done.

The interaction layer which can also be thought of as the decision support layer and the content management layer which is the system of record layer will never converge.  I know it is a very popular belief that somehow these two layers will merge and that the pundits of this idea follow on to say the only way for an IT solution to ever survive is to become a system of record…  Well if this were true how then did we ever end up with email and an inbox?  A big part of the misconceived notion, on the part of the pundants, is well articulated in this article http://gfxspeak.com/2011/06/06/vuuch-product-development-social-network-migrates-to-amazon-web-services/ from Jon Peddie, al la the “we must manage the files” thinking.

Now I am not saying that better integration of the Interaction layer and the Creation and Management layers wouldn’t be great.  Actually I believe it is a requirement of the next generation of Interaction solutions and a big part of what makes this layer social.  In the Peddie article he talks about thinking “outside the box”…  OK so lets get out of the box – PLM provides a way to capture a revision history for a file across a life-cycle.  If you can get yourself outside the box you will see each file also has a social life-cycle that is not captured as part of a revision history.

Just look at the change note on an ECO and you will see things like ”changed for cost reduction”, which hardly explains what happened, who was involved or what decisions were taken as part of the change.

Of course the social life-cycle is relevant to revisions but the PLM tool has no ability to capture this because the social aspect is contained in the Interaction layer.  The social life-cycle can be seen as those people and decisions that moves an item forward.  The decisions and human interactions that took place to move a file from version A to B.

The FDA has figured this out and has implemented the “Design History File” requirement in order to capture this.  Design History forces a company to understand the decisions/interactions taken from A to B.  The Design History File captures the social life-cycle of each part of a product.

Every item, data, file or deliverable has a social life-cycle.  Even something a simple as a Purchase Order (PO), which the ERP system has well managed, yet people involved on any specific PO exchange and track activity related to it outside the ERP system.  And do not forget that the specific PO might be for prototype parts for a product being designed and therefore this PO’s social life-cycle is connected to that product and related project.  For example maybe there is a problem processing the PO and people need to get together and make decisions with respect to how to proceed and what the impact will be on the project.  The ERP system has no record of this social interaction that is part of the PO’s life-cycle.

OK so it is clear we are outside the box and that the interation layer is here to stay.  So what do we call the next generation of interaction technology?  An Enterprise Social System.

Attached to this post is a recording of a webinar originally presented on December 2, 2010 detailing how SolidWorks can become the source of social system activity across the enterprise. The webinar, about an hour in length, details Vuuch social technology for product development, including the first-ever public demonstration [...]]]>

Attached to this post is a recording of a webinar originally presented on December 2, 2010 detailing how SolidWorks can become the source of social system activity across the enterprise. The webinar, about an hour in length, details Vuuch social technology for product development, including the first-ever public demonstration of a new feature in Vuuch 3.5: import of an entire SolidWorks assembly directly into the social system.

We had a blast presenting this and hope you will enjoy seeing it if you missed the live presentation and/or reviewing it.

All file formats contain the same content; they differ only in codec and size, with the .avi being the largest, the .m4v in the middle and the .wmv the smallest. The last file attached to this post is a PDF of the slides presented in the overview.

In a recent blog post titled “Do we really need structured workflows if we have visibility and status?” Christine Longwell writes, “One of the major objections to implementing a PLM system is that it is going to tie a creative organization into a structured workflow that can [...]]]>

In a recent blog post titled “Do we really need structured workflows if we have visibility and status?” Christine Longwell writes, “One of the major objections to implementing a PLM system is that it is going to tie a creative organization into a structured workflow that can slow down their process and ability to react.”

Computers are machines that do exactly and precisely what their programming tells them to do. They aren’t flexible; they aren’t responsive to changing conditions. Situations the developers don’t anticipate are impossible to manage using the software and, sometimes, can even crash it. This means that PLM software that attempts to automate workflow must “choose” in advance what to understand and support. It can automate only what it knows about. Its “workflow” is a simply series of pre-determined choices. To allow for the largest possible number of pre-programmed possibilities, developers model intricate cases or permit scripting of the PLM system. But at the end of the day, PLM “workflow” is like a trolley: the destination is wherever the tracks have been laid. As long as your team’s destination matches where the trolley is going — and you can stand the ride — all might be well.

Unfortunately, this is the antithesis of what teamwork is about. Teams do not work on linear paths. They go back and forth. They go sideways. They debate and diverge. They revisit decisions in light of new information or requirements. Teams, because they are collections of human beings, are infinitely flexible. They often must go “off the tracks” to solve a problem or tackle an issue. The bottom line is that trying to automate the ebb and flow of teamwork in a PLM system is fundamentally quixotic. Pre-coded PLM “workflows” and real teamwork are oil and water: they just don’t mix well.

End users intuitively understand the limitations of PLM “workflow.” They “feel in their bones” that PLM imposes limitations that will impede creativity. This unease is what Christine is talking about in her blog post. And it’s why users outside R&D steadfastly refuse to use PLM tools. So, PLM systems end up being used for what they are actually good at: “cold-storage” of the final decisions the team has made. But the “messy,”  human process of arriving at those decisions is not stored anywhere. And so the actual design intent, along with all the history of how a decision was made, is lost.

But let’s rethink the problem of using computers for teamwork: if we can’t pre-program a computer to handle the entire universe of workflows that a product team may need, what could we have a computer do for that team? What is a computer really good at that would enable teams to do what they want, how they want to do it?

It’s a shockingly simple answer: computers are good at managing lists. And how do product development teams want to manage their work? They want to list things.

Wikipedia points out that linked lists “…provide an easy implementation for several important abstract data structures…” There’s no news here. Consider your own personal life. It revolves around the power of lists. We list our to-do’s and grocery lists. We have “TV listings” and “top-ten lists” of all kinds. We list the best- and worst-dressed people. We make lists of things we want for holiday gifts. We list and list and list. And because lists are so important to us as individuals, it’s a natural, shared metaphor used by teams to manage their work. After all, nobody has to explain to a new team member what a list is and how a list works.

The intersection of lists and the power of computers to manage them doesn’t mean that we should all use Excel or Notepad all the time. Far from it. But it does mean that any software that attempts to support product development workflows must have a list metaphor at the heart of its design. Rules, steps and states…all the things PLM “workflow” says are useful for teamwork…are as unnatural as the four-armed man at the carnival. This is the obvious truth Christine has blogged about: structured workflow, as classically implemented in PLM, can never be a natural teamwork metaphor.

In a future blog post, I will explain how Vuuch enhances lists with social technology to implement a social system that works the way teams expect it to instead of demanding they change what they do.

If you’ve attended one of our weekly webinars (you can sign up here to join us any Tuesday), you know that we bristle at the mention of Microsoft SharePoint as a collaborative extension to PLM. We believe SharePoint is perfect if you want to add complexity to [...]]]>

If you’ve attended one of our weekly webinars (you can sign up here to join us any Tuesday), you know that we bristle at the mention of Microsoft SharePoint as a collaborative extension to PLM. We believe SharePoint is perfect if you want to add complexity to PLM. It’s a good thing if you want your team to spend more time on configuration than on working together. Select SharePoint if you believe people and teams should conform to the software rather than the other way around.

Still, because of Microsoft’s presence in the marketplace, lots of PLM purists (who believe PLM could succeed “if only people will change the way they work”) talk about SharePoint a lot. Oleg Shilovitsky, one of our favorite PLM bloggers, has just published a post pointing out that despite PTC’s (and others’) embrace of SharePoint, the shine is wearing off.

How about we skip surveys and go right to the source to see if SharePoint and manufacturing are a match? Let’s start with the 106-page “SharePoint 2010 Walkthrough Guide,” which can be downloaded here. Believe it or not, the fictional company in this marketing collateral is a manufacturing company. That’s perfect. What better way to see if SharePoint can actually promote better PLM collaboration? Maybe SharePoint will have our team up and running fast, collaborating to improve products.

First, the document sets the stage:

…Contoso is a fictional manufacturing company that produces gears for other industries that rely on gears in their products. You will be playing the role of Erika Cheley, who is a project manager at Contoso. She has just assumed the role of Project Manager for one of the projects that focuses on improving the production process for the manufacturing of the Great White Gear product. Throughout this walkthrough she will be configuring the site that she will be using to work with her project team. We will start the initial walkthrough as Erika makes some design changes to her site.

“Makes some design changes to her site?” Why do I want to start there? Why do I need to design a site before I can do anything with it? But wait, that’s not really the first task.

First, Erika has to create “the team site that will be used to manage her project” (page 5). Whoa! Wait a minute…before I design the site…I have to create it? Sounds like I need an IT guy.

But even creating the site…and making design changes, whatever that means, doesn’t get the team going. After Erika creates the site, she has to customize “the project team site to include a project description” (page 5). Doesn’t the project team already know what product it’s working on? This reminds me of what my eighth-grade English teacher used to tell me about essays: to make them good, you needed to throw away the first three paragraphs because most writers spend that time warming up. The good stuff is buried in the middle.

Yet, in Microsoft’s own documentation describing SharePoint for manufacturing, the first activity — simply describing what everyone already knows — takes nearly five pages to explain.

This is valueless work. It’s an example of what’s wrong with SharePoint for manufacturing. Every second of time spent putting knowledge we already have into some system adds to the cost of the product and slows down time-to-market. This is classic IT for IT’s sake. And it’s the reason the team won’t use it. It requires so much effort to simply get started, only die-hard PLMers will ever use it. That means you can forget ever getting finance people, marketing people, vendors and partners to use it.

Still, Erika doesn’t give up. She decides on page 11 that “she would like the site to reflect the Contoso brand and provide a graphical representation of product data…” OK. We’re about 10% into the walkthrough based on page count and so far we have had to create the site, describe it and now, duplicate the CAD data stored in the PLM system. Sorry, I am just not feeling it.

The graphics setup goes on to about page 17 — including creating a Silverlight “web part,” the function of which in the scenario escapes me — and would probably escape the team as well. Have we gotten to any collaboration on the gear part yet? Not quite.

It seems that while Erika is “very pleased with the changes made to the site” she still wants more setup. So, starting at page 17, Erika decides to change the site theme. This, including a “media web part” (wouldn’t 3DVIA Composer be so much simpler?) goes on to page 25.

OK, now that we’ve spent about 25% of our time just getting ready to do something, are we there yet? Are we ready to friend people to something the team cares about? Can we use Outlook and SolidWorks and Inventor to discuss problems, assign tasks and track issues? (These are things you can do in Vuuch from the start.)

Well, not quite…

Now that Erika has spent some time designing her site, she is ready to move on to the creation of content for her team site. She has a few specific things she would like to configure, including a custom order tracking solution, some document library configurations, and some workflows.

We’ve spent nearly 30 pages in this document setting up libraries and workflows (why anyone wants a collaboration workflow is beyond comprehension. Collaboration is, by definition, non-modal and and non-linear).

And we are still nowhere near being able to use the site for anything approximating collaboration. The document goes on and on and on with more configuration…more setup…more customization. We never quite seem to get to the actual teamwork.

I’ll spare you the rest. But you can see for yourself. No matter how hard its marketing people try, SharePoint isn’t about collaboration or improving teamwork in manufacturing. SharePoint is simply about glomming more “platform” onto already overweight PLM systems. That suits PLM vendors…not customers.

The result? End users avoid it like the plague, manufacturing IT people can’t understand why users “just don’t get it” and the wheel just spins.

Could your product development team work together better? Are decisions being made that aren’t being communicated immediately to the entire team? Does your team have any nagging issues with the project (how’s that for a leading question? )

If so, you will want to join us to see how [...]]]>

Could your product development team work together better? Are decisions being made that aren’t being communicated immediately to the entire team? Does your team have any nagging issues with the project (how’s that for a leading question? )

If so, you will want to join us to see how Vuuch can solve these problems.

Please join us on Tuesday, September 14 at noon ET, 9am PT, 16:00 GMT for an introduction to Vuuch. Register for our webinar at http://www.vuuch.com/webinar. In less than an hour, you will learn how social technology can revolutionize teamwork in product development projects.

Oh, and this week’s webinar will be the world premier of Vuuch 3.0.

We hope you will be able to join us. Register here.