Team PDM _and_ enterprize PDM

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?

Thanks, Roy

 

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.

 

Roy,

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.

Cheers,

Len K. Mar, PEng.
Engineering Data Solutions

 

Thank you for your answer - it was very helpful.

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.
www.emptech.jotne.com/newletter/press/PDMdataexhange-190202.pdf 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.

Some "balloons" I made to help thinking at
http://www.isv.hut.fi/html/systems_files/frame.htm

Thank you once again,
Roy