@Beth: Throughout the design process things constantly change. Sometimes, even after production has begun. Typically, until the client or a VP says it's perfect, things are in flux.
PLM does not allow for going back to a previous version. You're replacing the last version with the newest one in the system. When management wants to go back to a previous version, it's no longer there. You have to hope that the designer kept a copy in their files and can reload it.
I guess I'm still confused. Wouldn't those changes to the 3D sketches or models be maintained in a PDM or PLM system using the inherent verison control capabilities to ensure everyone is using the latest version? Or are you talking about more conceptual designs prior to actually having a formal 3D CAD model?
@Beth: Maybe my comment wasn't clear to you. It's not about "keeping track of changes". As a designer, I have to create CADs (or 3D sketches). When management asks to see a tweak or change, it ranges from a few minutes to a several hours of work. If I save over the latest version and management wants to "go back", I've created more work for myself. If I save duplicates, I'm using a lot of space on the server (that's where IT comes in).
I used excel as a tracking tool before PLM. It worked well. I've helped develop custom PLM systems for companies over the years and still work as a UX Design consultant for up and coming companies. PLM systems are great for production but only marginally helpful for creatives.
My point is that having a system that can store, maybe, up to 3 versions, without crashing the serving or weighing down the cloud, would be great. Designers would appreciate it.
@NadineJ: The pain point I think you're describing is change management around engineering changes--a common and tricky thorn in the side of all engineering teams, now and in the past. Product Data Management (PDM) and PLM systems were born, originally, out of the need to maintain a central repository of engineering data (and keep track of changes), but they are admittedly often complex, big, and expensive systems--well beyond reach of many shops. Excel spreadsheets have been another stable for managing the changes, but clearly not able to do so in any kind of automated and centralized fashion.
Products like Sunglass and other Web-generation-based collaboration platforms are taking on this problem again and attempting to solve it in a much more streamlined and simpler fashion. Perhaps it's time to get your IT group or your engineering management to revisit the problem now that the technology is bit less onerous.
This is a nice evolution. I'd welcome any opportunity to work with it. I'd like to see the other big problem in the design process addressed. I call it go-back-itis. I can spend hours on a change (or two) only to have the decision makers want to "go-back" to the original.
Of course, I save every version. And, I'm always friendly with IT to make sure I have the amount of space I need in order to keep saving every version, just in case.
Beth, I have noticed many "innovations" in the design engineering space that follow developments in the software engineering field from many years ago. That makes sense for a couple of reasons. Software, since it has no real "manufacturing" process is a bit different. Second, software is appearing in the products, and even for physical objects, in the design flow of the products. This use of a Git like distributed repository is a natural, and good, evolution.
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This discussion will examine what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.