Hi, didn´t find any PDM related newsgroup maybe I can find the truth here :-).
I´m looking for all kind of information related to the problematics of using one PDM for CAD-users (product development) and other PDM for the enterprize level. To be open minded, the question does not suppose that those PDM´s are provided by same company. An example would be that a company has PDM X and is moving to a new 3D-CAD-system. PDM X doesn´t seem to be suitable for handling the product development data of CAD-systems under evaluation (~no ready-made interface) though it is well adapted for enterprize actions. One option is therefor to handle
3D-models etc. with Team level PDM Y that is tightly integreted to the CAD-software(s) in question. Use of separate PDM during the R&D phase also has some other advantages. But how does the PDM X and PDM Y communicate? There is some analogy to the merged companies having separete PDM´s. Any experiences?
-From which system to which system?
-How tight integration do you have and how it is done? (I have one example where they copied the items from TeamPDM to Ent.PDM manually due to the _very_ high integration cost offered).
-Costs of integration / linking (cheap, average, expensive...)?
-Any possibilities just to "batch" the contents of PDM Y database to another and PDM X would read it propely (this reveals the fact that I don´t know much about the databases...)
-What data do you migrate in your case - 3D-models, pdf´s, items...
-Do you transfer the model structure to be used as a product structure?
Having two different PDM systems that cannot talk to each other is a bad thing. Don't even consider it. At the minimum you would want some level of functionality between the two, even if it is the basic ability to transfer data via plain text files, or similiar.
The example you give is typical of workgroup vs. Enterprise PDM systems. The primary differentiators between the two is
a) Enterprise version has an ECO (Engineering Change Order) sub-module b) There is a built-in interface between MRP (Manufacturing portion of ERP) and PDM. c) Enterprise PDM/ERP systems can handle many different CAD systems (with the proper adapter).
I am unclear as to the perceived benefits of the existing enterprise PDM system. The biggest disadvantage of enterprise ERP/PDM systems (besides their expense) is the quality of the add-ins. Most of the time (but not all ways) the level of integration will vary between applications. Most ERP systems are "designed" around specific type of MCAD software. Depending on who wrote the adapter - playing well with others may be a pipe dream.
Question - do you have another CAD application (Legacy Data) that you want to maintain? Is this the reason for a two tiered system?
The cost of integrating the two systems (which I would strongly advise against) depends on what type and level of protection/encryption they use to secure the data. If it is encrypted, they will charge you a fortune for the adapter as there is no other way to get too the meta data and file relationships. Protection (such as file locking) may be easier to get around. Either way, trying to tie the two systems together would probably be cost prohibitive - not to mention very scary since it is mission critical data we are talking about. Note - check your licensing agreement - most subscription support contracts are writtten in such a way as to void the support contract if you decide to go down this path.
Should you have to go down this path..... here is my advice:
See if the ERP system has an EDI interface. Some of them may have specific PDM modules. If they don't, see if you can batch import flat asci files.
Use the workgroup PDM system for new product development. Upon release
- use the workgroup PDM system to output the purchased items, BOM structure, and vendor data to a formatted ascii file. Then use the import or EDI function of the ERP system to bring it into the enterprise PDM system. Again, make sure the ERP system does data verification prior to acceptiing the batch import. Nothing will bring your ERP system to its knees faster than incorrect or corrupt data. Note - this is just purchasing data - trying to bring in reference documentation will add to the complexity and costs. The question then becomes "Which of the two competing systems will have control or ownership of the files - what happens when it needs to be changed?)
Assign someone full-time to look after this system - if it isn't all ready -- it will become a very high maintenance application. I wouldn't want the job.
You will be dual entering information (three times)with all its inherent inaccuracies and chances of errors. Once, pushing development data to manufacturing -- the second time when you run an ECO from manufacturing back to engineering and a third time returning information from Engineering to Manufacturing. My guess is that this will become such an awkward process (unless you get lucky with the automation of the transfer) that the number of ECO's will be reduced. And it won't be because the product you are making is suddenly "better".
Running this type of senario will cost your company one way or another. The only question is which department will take the hit in time, money, and effort (not to mention the frustration factor).
If you want to supply me with more information on what you are trying to achive (process wise) I can try and provide you with specific help.
Yes there is some legacy data but there are plans to move the old data to the new CAD to be used as a base of our "project type product customization" - it will take some time though. The life-cycle of the product is decades and maintain-utility will be there for the old projects.
As I see the big picture it is a selection between three systems fields:
1) To implement the new enterprize version of the PDM that is integrated to the new CAD and throw the old PDM out.
+One system backbone
+Tight CAD-integration
-More work: org.specs & ERP-integration
2)To integrate the new CAD to the existing PDM
+Less work for org.data
+No major changes in ERP
-The support for the interface of PDM / new CAD (from different vendors, we have some nasty experiences about changing API-specs...)
3)The old PDM + Team PDM for the new CAD
+No changes for org-side & ERP
+Tight integration between CAD / TDM
-communication between PDM & TDM (e.g. ECO´s)
We assumed that because the product customization efforts are a big part of everyday work there will be a lot of "try´s" (obsolete items) under design phase. They would be, I think, easier to clean from the database if the system contains only the design data.
One kind of solution for the third point is one related article about Vebasto AG´s way to transfer data between Windchill and Enovia.
formatting link
but it doesn´t seem to resolve the lack of ECO-process.
This "enormous cost" is probably the reason why one reference has "manual item-copy-system".
We will study this - if "a backdoor to the PDM" would meet our needs.
Yes, this is a major problem - it might rule out all other than centralized systems.
I don´t know if I can describe this in a process wise - this was one scenario based on the restrictions of existing PDM and new CAD´s. Options are like points 1, 2 and 3 above.
PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.