I am frustrated by folks who think that doc-control/CM solutions come automatically when a company installs a PDM system. In my experience, this wishful thinking has had the opposite effect. Basic best practices for engineering document control is nearly impossible to achieve because the PDM system has been implemented in a way that is incompatible with generally accepted principals. Because of the money poured into the PDM software and the time invested, moving in a new direction meets huge resistance. Has anyone figured out a way to get out of this type of hole?
Eng-Tips is the largest engineering community on the Internet
Intelligent Work Forums for Engineering Professionals
-
Congratulations waross on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
PDM vs CM 1
- Thread starter ptruitt
- Start date
-
1
- #2
First rule of holes, when you find yourself in one, stop digging.
In this case though, the only way out is to keep digging until you come out on the other side. Most people think software is going to fix everything. All that software does, especially PDM, is create more of your current mess faster.
During the planning stages of PDM implementation, there should have been a review of doc-control procedures and how they fit into the software. Apparently, that step was missed for you and will now cost time and money.
The best way out, create a 2nd PDM system. But this time, plan its implementation with the procedures you would like to follow. Maintain the existing system in the meantime. And then migrate to the new system when its ready. Of course, migration also comes with its own difficulties that have to be dealt with. Some organizations just keep to systems: legacy and new products.
--Scott
In this case though, the only way out is to keep digging until you come out on the other side. Most people think software is going to fix everything. All that software does, especially PDM, is create more of your current mess faster.
During the planning stages of PDM implementation, there should have been a review of doc-control procedures and how they fit into the software. Apparently, that step was missed for you and will now cost time and money.
The best way out, create a 2nd PDM system. But this time, plan its implementation with the procedures you would like to follow. Maintain the existing system in the meantime. And then migrate to the new system when its ready. Of course, migration also comes with its own difficulties that have to be dealt with. Some organizations just keep to systems: legacy and new products.
--Scott
I'll back Swertel on this one. In the planning stage figure out what the fundamental CM system is, and that it's compatible with the chosen PDM, then introduce it.
The software folks usually claim they can follow any documented system, untill you try getting into details.
The software folks usually claim they can follow any documented system, untill you try getting into details.
Posting guidelines faq731-376 (probably not aimed specifically at you)
What is Engineering anyway: faq1088-1484
What is Engineering anyway: faq1088-1484
- Thread starter
- #4
Thanks. Unfortunately, my co-workers seem satisfied with what is in place. I don't really have a problem with the software, although it seems clunky. There are no defined terms such as "interchangeability" or formality as to the difference between 'superseded' and 'obsolete'. Everyone seems satisfied to put out the fire de jour.
Your software may be fine, but the implementation may make it seem clunkier than it should.
I want to clarify that when I stated create a second PDM system, I didn't mean find a new software. I meant create a new database, with new roles defined, workflows planned, and forms for metadata created, plus all the other fun things to do with PDM, on a different server.
Once that 2nd database is ready to go live, transfer all the data from the first server and then shut it down. Or, maintain 2 distinct databases: 1 for legacy projects and 1 for new projects.
--Scott
I want to clarify that when I stated create a second PDM system, I didn't mean find a new software. I meant create a new database, with new roles defined, workflows planned, and forms for metadata created, plus all the other fun things to do with PDM, on a different server.
Once that 2nd database is ready to go live, transfer all the data from the first server and then shut it down. Or, maintain 2 distinct databases: 1 for legacy projects and 1 for new projects.
--Scott
- Thread starter
- #6
ptruitt,
May I ask what PDM system you're using? We're in the process of revamping our current engineering design standards and considering company wide PDM/PLM system software. I suggested implement it for engineering only for now, test drive it, work out the bugs, and then turning it on for the rest of the organization to use.
Thank you,
Colin Fitzpatrick (aka Macduff)
Mechanical Designer
Solidworks 2009 SP 4.1
Dell 490 XP Pro SP 2
Xeon CPU 3.00 GHz 3.00 GB of RAM
nVida Quadro FX 3450 512 MB
3D Connexion-SpaceExplorer
May I ask what PDM system you're using? We're in the process of revamping our current engineering design standards and considering company wide PDM/PLM system software. I suggested implement it for engineering only for now, test drive it, work out the bugs, and then turning it on for the rest of the organization to use.
Thank you,
Colin Fitzpatrick (aka Macduff)
Mechanical Designer
Solidworks 2009 SP 4.1
Dell 490 XP Pro SP 2
Xeon CPU 3.00 GHz 3.00 GB of RAM
nVida Quadro FX 3450 512 MB
3D Connexion-SpaceExplorer
Colin,
That may work, but usually you will need to configure the system to do everything up front and then implement it in stages.
It is critical that you have a grasp on what your CM needs are and how the PDM software can be used to meet your CM requirements. In some cases, processes may need to change to meet the software processes. It is easier to chnage an undocumenetd, or even a documented, procedure to match the software processes than to modify the software to do it 'your way'.
Also, be careful with too many customizations to the software because what works in this release may not work in the next. You have to be able to upgrade your software solutions in a timely manner.
PDM systems typically do NOT show a productivity increase within engineering. The interface and procedures all take time to do in the course of the typical workday.
"Wildfires are dangerous, hard to control, and economically catastrophic."
Ben Loosli
That may work, but usually you will need to configure the system to do everything up front and then implement it in stages.
It is critical that you have a grasp on what your CM needs are and how the PDM software can be used to meet your CM requirements. In some cases, processes may need to change to meet the software processes. It is easier to chnage an undocumenetd, or even a documented, procedure to match the software processes than to modify the software to do it 'your way'.
Also, be careful with too many customizations to the software because what works in this release may not work in the next. You have to be able to upgrade your software solutions in a timely manner.
PDM systems typically do NOT show a productivity increase within engineering. The interface and procedures all take time to do in the course of the typical workday.
"Wildfires are dangerous, hard to control, and economically catastrophic."
Ben Loosli
- Thread starter
- #9
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question
- Locked
- Question