Change cycle and PDM/PLM
Change cycle and PDM/PLM
We are a small company (8-10 engineers) designing/developing simple to medium complexity products (imagine a lawn mower as the most complex product we make). We use SolidWorks as the main design tool, but have a couple of legacy products too.
We do not have a PDM/PLM system - we find almost all the products out there way too rigid to use, and too expensive to implement and manage. The overhead they impose on our workflows are very high. So we manage all our product releases using network storage and folders.
Recently we felt that a good design change cycle management tool would help us better understand the evolution of the design. Such a system must be on the web/cloud so all internal engineers and the external suppliers can freely participate in the change cycle process. We want to continue to manage the product release process we currently have.
Can anyone share ideas on this?
We do not have a PDM/PLM system - we find almost all the products out there way too rigid to use, and too expensive to implement and manage. The overhead they impose on our workflows are very high. So we manage all our product releases using network storage and folders.
Recently we felt that a good design change cycle management tool would help us better understand the evolution of the design. Such a system must be on the web/cloud so all internal engineers and the external suppliers can freely participate in the change cycle process. We want to continue to manage the product release process we currently have.
Can anyone share ideas on this?
Re: Change cycle and PDM/PLM
> a good design change cycle management tool
Fortunately these do exist.
> must be on the web/cloud
Hm...
> continue to manage the product release process we currently have.
Ah.
Your requirements suggest to me that your group would probably feel very much at home in something like Dropbox for simple versioning/marking of files and enabling the remote access by way of being cloud-native.
However: I am old school and would always favor on on-prem system, for a variety of reasons. If Solidworks is your primary design tool, then SW PDM is a logical choice. It is largely CAD or filetype-agnostic, even though it has the most bells and whistles for Solidworks integration.
To your first requirement that it support web/cloud:
It is not cloud-native but there are ways to have it cloud-hosted, I have seen the (very lengthy) documentation for setting it up in AWS and getting clients to connect.
External access to the system by third parties is possible but requires coordination with IT and management via active directory. This is satisfactory but will depend on your IT resources (time, staff, and technology both in the corporate IT proper as well as within your engineering department).
The web client is too feature incomplete to be considered a true alternative to the desktop thick client, but it supports some number of external access use cases (again with a considerable IT effort).
To the product release process/rigidity topic:
in my experience, product structure complexity does not correlate well with complexity of data/release/configuration management (a very simple product with only 10 BOM parts can be linked to enormously complex business process and data handling requirements). But no PDM or PLM needs to impose any more rigidity than necessary. They are systems for deploying processes for data management, and can be configured to be highly complex, inflexible and brittle -- or very simple and flexible. It depends on your use case.
In my opinion PDM is good for the latter case; for the former case I would use PTC Windchill.
But as I started out with, if you want to have as little "workflow logic" as possible and just need to lift-and-shift your network share into cloud to facilitate external access... then Dropbox and its ilk will probably do all you need.
Fortunately these do exist.
> must be on the web/cloud
Hm...
> continue to manage the product release process we currently have.
Ah.
Your requirements suggest to me that your group would probably feel very much at home in something like Dropbox for simple versioning/marking of files and enabling the remote access by way of being cloud-native.
However: I am old school and would always favor on on-prem system, for a variety of reasons. If Solidworks is your primary design tool, then SW PDM is a logical choice. It is largely CAD or filetype-agnostic, even though it has the most bells and whistles for Solidworks integration.
To your first requirement that it support web/cloud:
It is not cloud-native but there are ways to have it cloud-hosted, I have seen the (very lengthy) documentation for setting it up in AWS and getting clients to connect.
External access to the system by third parties is possible but requires coordination with IT and management via active directory. This is satisfactory but will depend on your IT resources (time, staff, and technology both in the corporate IT proper as well as within your engineering department).
The web client is too feature incomplete to be considered a true alternative to the desktop thick client, but it supports some number of external access use cases (again with a considerable IT effort).
To the product release process/rigidity topic:
in my experience, product structure complexity does not correlate well with complexity of data/release/configuration management (a very simple product with only 10 BOM parts can be linked to enormously complex business process and data handling requirements). But no PDM or PLM needs to impose any more rigidity than necessary. They are systems for deploying processes for data management, and can be configured to be highly complex, inflexible and brittle -- or very simple and flexible. It depends on your use case.
In my opinion PDM is good for the latter case; for the former case I would use PTC Windchill.
But as I started out with, if you want to have as little "workflow logic" as possible and just need to lift-and-shift your network share into cloud to facilitate external access... then Dropbox and its ilk will probably do all you need.
Re: Change cycle and PDM/PLM
Thanks for the response @rodface.
We did look at Dropbox & other cloud storage. They are good for managing the results of a change cycle. But what we are looking for is a way to capture the evolution of the design through the change cycle. What good is it to store just 'release A' and 'release B' in the cloud, if its not easy to know how A became B and who contributed to the changes in the parts and assemblies?
PDM/PLM is good at keeping a record of all the changed parts between A & B. But it doesn't show why those changes were made, just that they were made. Quite often a lot of discussions happen between all the stakeholders to effect the change in the part. This is crucially missing in PDM.
I hope this clears our requirement a bit more.
We did look at Dropbox & other cloud storage. They are good for managing the results of a change cycle. But what we are looking for is a way to capture the evolution of the design through the change cycle. What good is it to store just 'release A' and 'release B' in the cloud, if its not easy to know how A became B and who contributed to the changes in the parts and assemblies?
PDM/PLM is good at keeping a record of all the changed parts between A & B. But it doesn't show why those changes were made, just that they were made. Quite often a lot of discussions happen between all the stakeholders to effect the change in the part. This is crucially missing in PDM.
I hope this clears our requirement a bit more.
Re: Change cycle and PDM/PLM
I would be surprised if there wasn't a third-party extension that can bring some of the needed features to Dropbox.
> But it doesn't show why those changes were made,
I take issue with this statement. PDM/PLM not only keeps the record of all changes ("what happened"). The "how" and the "why" are entirely possible to capture, but that is all down to how the team chooses to use the system, and how well they follow that use case. I don't mean to tell you anything you don't already know (but it's good practice for me since I'm currently setting up a new PLM system). The terminology is from Windchill but the same principles apply:
HOW A became B would be recorded within the history of the change objects associated with the various versions of the part. The history of my released Revision 2 of the part will show that there was a Change Notice that authorized Rev 2's release. In the change notice, I can see all affected objects (perhaps the CN resulted in several other parts being revised), and in its attributes we may have noted the justification for the changes made. Under the CN is the implementation plan, and its attributes may contain the specific instructions given to designers, doc controllers etc. on what changes to carry out.
WHY A became B would happen by again looking at the change objects. The Change Notice would have resulted from a Change Request, and that in turn would have resulted from a Problem Report. Therein are the observed issue, desired outcome, history of analysis, reviews and approvals. At each stage, each task assignee may add their comments and cast their vote.
But, this is only going to be useful if: people add relevant comments in the system. Change object descriptions and other attributes are filled out by creators. If the discussions are important to you, then they are captured in meeting minutes or as recordings, which are then attached to the change objects or called out by a hyperlink to the external source.
I think all of the above can be accomplished in just about any system that maintains versions and history. A PDM can do all of this more easily than a cloud storage could because it's designed with the engineering process in mind, but a PLM with its customizable business object is really the right tool for this job.
Hope this continues to be helpful, and again, I do not intend to soapbox, just want to make sure we are on the same page in our understanding.
> But it doesn't show why those changes were made,
I take issue with this statement. PDM/PLM not only keeps the record of all changes ("what happened"). The "how" and the "why" are entirely possible to capture, but that is all down to how the team chooses to use the system, and how well they follow that use case. I don't mean to tell you anything you don't already know (but it's good practice for me since I'm currently setting up a new PLM system). The terminology is from Windchill but the same principles apply:
HOW A became B would be recorded within the history of the change objects associated with the various versions of the part. The history of my released Revision 2 of the part will show that there was a Change Notice that authorized Rev 2's release. In the change notice, I can see all affected objects (perhaps the CN resulted in several other parts being revised), and in its attributes we may have noted the justification for the changes made. Under the CN is the implementation plan, and its attributes may contain the specific instructions given to designers, doc controllers etc. on what changes to carry out.
WHY A became B would happen by again looking at the change objects. The Change Notice would have resulted from a Change Request, and that in turn would have resulted from a Problem Report. Therein are the observed issue, desired outcome, history of analysis, reviews and approvals. At each stage, each task assignee may add their comments and cast their vote.
But, this is only going to be useful if: people add relevant comments in the system. Change object descriptions and other attributes are filled out by creators. If the discussions are important to you, then they are captured in meeting minutes or as recordings, which are then attached to the change objects or called out by a hyperlink to the external source.
I think all of the above can be accomplished in just about any system that maintains versions and history. A PDM can do all of this more easily than a cloud storage could because it's designed with the engineering process in mind, but a PLM with its customizable business object is really the right tool for this job.
Hope this continues to be helpful, and again, I do not intend to soapbox, just want to make sure we are on the same page in our understanding.
- jcapriotti
- Posts: 1869
- Joined: Wed Mar 10, 2021 6:39 pm
- Location: The south
- x 1214
- x 1999
Re: Change cycle and PDM/PLM
You are getting into the PLM side of PDM ergarding "Change Management. For SolidWorks it's the "Manage" product. The bigger players are Windchill, Teamcenter, and Enovia (3dx). None of these options are easy or cheap.krisreddy wrote: ↑Wed Mar 29, 2023 3:51 pm PDM/PLM is good at keeping a record of all the changed parts between A & B. But it doesn't show why those changes were made, just that they were made. Quite often a lot of discussions happen between all the stakeholders to effect the change in the part. This is crucially missing in PDM.
We use SolidWorks PDM and customized it to handle "ECOs" but we are migrating to Windchill as our company is integrating with all of our global companies. This costs far more than PDM and the customization. And I get the feeling you feel that even PDM is too much $$ for your budget. PDM Standard does come with SolidWorks Pro licenses if you have that but it has limits, especially if you want to get into baking in some ECO process.
Jason
Re: Change cycle and PDM/PLM
Thanks a lot for your comments, @rodface , @jcapriotti
For simplicity, lets just limit this discussion to just a single part in an assembly.
1. The initial state of the part (in PDM). Lets call this release A.
2. (from your explanations) An ECN which could end up some or all of the following [specific instructions given to designers, doc controllers, changes to carry out, ECR, Problem Report, desired outcome, history of analysis, reviews, approvals]. In the atomic sense, each one of this is basically an interaction between the stakeholders with zero or more supporting documents (attachments). For simplicity, consider the interaction to be a 'chat' between stakeholders.
3. The changed state of the part (added to PDM). Lets call this release B.
In this scenario, the onus is on the engineers to record everything in step 2 in PDM, between A & B. Neither PDM nor PLM provide any tools to automatically capture this crucial info. I assume that @jcapriotti work to "customize to handle ECOs" is really about gathering/collating/sorting all or some of the EC related information from various stakeholders and storing it in the PDM at the appropriate place with the right CAD object.
IMHO, the most important information in product evolution is hidden in step 2. PDM and PLM systems are of little help in actually getting this this documented. This burden is especially high for companies where the product structure complexity is low, & the product release process is not burdensome.
Any thoughts?
For simplicity, lets just limit this discussion to just a single part in an assembly.
1. The initial state of the part (in PDM). Lets call this release A.
2. (from your explanations) An ECN which could end up some or all of the following [specific instructions given to designers, doc controllers, changes to carry out, ECR, Problem Report, desired outcome, history of analysis, reviews, approvals]. In the atomic sense, each one of this is basically an interaction between the stakeholders with zero or more supporting documents (attachments). For simplicity, consider the interaction to be a 'chat' between stakeholders.
3. The changed state of the part (added to PDM). Lets call this release B.
In this scenario, the onus is on the engineers to record everything in step 2 in PDM, between A & B. Neither PDM nor PLM provide any tools to automatically capture this crucial info. I assume that @jcapriotti work to "customize to handle ECOs" is really about gathering/collating/sorting all or some of the EC related information from various stakeholders and storing it in the PDM at the appropriate place with the right CAD object.
IMHO, the most important information in product evolution is hidden in step 2. PDM and PLM systems are of little help in actually getting this this documented. This burden is especially high for companies where the product structure complexity is low, & the product release process is not burdensome.
Any thoughts?
Re: Change cycle and PDM/PLM
@krisreddy PLM systems today can record e-mails, chats, and markup communication about the parts/assys being modified. You still have the venerable "Revision Table" on drawings and/or PMI outputs.
I also attempted earlier to recommend looking at Autodesk UpChain but it appears it did not post. It is a cloud-based PLM system that touted modern and flexible tools and they did have a interface for SolidWorks. Autodesk bought them a while ago and hitched it to the Fusion 360 Manage portfolio. Have not been keeping tabs on it since that happened.
Another less rigid option might be Siemens Xcelerator Share. More like a workgroup or adhoc engineering project management tool but works with multi-CAD and has built in viewing/markup and probably a few other things.
I also attempted earlier to recommend looking at Autodesk UpChain but it appears it did not post. It is a cloud-based PLM system that touted modern and flexible tools and they did have a interface for SolidWorks. Autodesk bought them a while ago and hitched it to the Fusion 360 Manage portfolio. Have not been keeping tabs on it since that happened.
Another less rigid option might be Siemens Xcelerator Share. More like a workgroup or adhoc engineering project management tool but works with multi-CAD and has built in viewing/markup and probably a few other things.
Re: Change cycle and PDM/PLM
This is an interesting discussion and I hope we can continue it. I get the sense that the desired feature is most closely described as
If I am understanding correctly then, the deficiency of the traditional PDM/PLM system is that its users must actively enter data into it.
The alternative would be... a passive system that vacuums up related data and presents it in a usable manner, automatically and correctly associating it with the job/object/part?
Well a month ago I might have called that fanciful... but perhaps this will be much more feasible for a company to implement in the very near future thanks to the new AI/LLM work being done.
At the moment though I do not know of any PDM or PLM that attempts to capture "unstructured" data rather than providing a framework for the entry of structured data by users. BUT: this may be the core "vision" espoused by projects such as 3DExperience: if we can get everyone to do everything inside this one system, then we can take what used to be disparate, siloed data and create the "graph" of knowledge with simple associative links and tags.
This is not really a new concept though. As I have gotten into learning Windchill, I have wondered what it would look like if deployed in a VERY secure, airgapped environment. Like a worker goes into a room that is behind 3 locked doors. There is a computer in this room, but no phone. They are alone. They sit at their terminal: there is no Start menu, no apps. One icon on the desktop-click it, and Windchill opens up. There are Meetings. Notebooks. Discussions. They add information into the system and interact with unseen other workers through the system. All information is associated to parts/change objects, etc. Requirement fulfilled.
Anyway, very interesting discussion.
and what is info:> tools to automatically capture this crucial info.
So this feature would somehow automatically capture the chat between stakeholders and load it into the "step 2" object.> For simplicity, consider the interaction to be a 'chat' between stakeholders.
If I am understanding correctly then, the deficiency of the traditional PDM/PLM system is that its users must actively enter data into it.
The alternative would be... a passive system that vacuums up related data and presents it in a usable manner, automatically and correctly associating it with the job/object/part?
Well a month ago I might have called that fanciful... but perhaps this will be much more feasible for a company to implement in the very near future thanks to the new AI/LLM work being done.
At the moment though I do not know of any PDM or PLM that attempts to capture "unstructured" data rather than providing a framework for the entry of structured data by users. BUT: this may be the core "vision" espoused by projects such as 3DExperience: if we can get everyone to do everything inside this one system, then we can take what used to be disparate, siloed data and create the "graph" of knowledge with simple associative links and tags.
This is not really a new concept though. As I have gotten into learning Windchill, I have wondered what it would look like if deployed in a VERY secure, airgapped environment. Like a worker goes into a room that is behind 3 locked doors. There is a computer in this room, but no phone. They are alone. They sit at their terminal: there is no Start menu, no apps. One icon on the desktop-click it, and Windchill opens up. There are Meetings. Notebooks. Discussions. They add information into the system and interact with unseen other workers through the system. All information is associated to parts/change objects, etc. Requirement fulfilled.
Anyway, very interesting discussion.
- jcapriotti
- Posts: 1869
- Joined: Wed Mar 10, 2021 6:39 pm
- Location: The south
- x 1214
- x 1999
Re: Change cycle and PDM/PLM
It's PLM territory for sure. Windchill and SolidWorks Manage have a "Process Management" module that allows you to track and process changes to parts and documents. But they also have "Tasks" of which some are auto created as part of a standard process and some ad-hoc created on the fly as needed. These tasks have notes and attachments.
Manage example: Windchill has more options for discussion threads and meetings. I've played around with it some and find it cumbersome and its not something we are looking to use yet, But we're just getting started so at the moment we are attaching documents and emails to the ECOs.
A lot of the detailed discussions are in meetings, both in-person and online, emails, phone calls, and Teams chats. Basically most of that is lost. The "Why" is put into a document and in the ECO attributes.
Maybe if Microsoft and Google buy the PLMs systems out there we'll have something where everything is connected....because so far from what I've seen, when the PLM systems try to build in functions that overlap discussions boards and Office functionality, it's usually pretty terrible to use.
Manage example: Windchill has more options for discussion threads and meetings. I've played around with it some and find it cumbersome and its not something we are looking to use yet, But we're just getting started so at the moment we are attaching documents and emails to the ECOs.
A lot of the detailed discussions are in meetings, both in-person and online, emails, phone calls, and Teams chats. Basically most of that is lost. The "Why" is put into a document and in the ECO attributes.
Maybe if Microsoft and Google buy the PLMs systems out there we'll have something where everything is connected....because so far from what I've seen, when the PLM systems try to build in functions that overlap discussions boards and Office functionality, it's usually pretty terrible to use.
Jason