I am trying to figure out by myself what is a good folders' structure
to use with PDMworks. From what I have read on this newsgroup, trying
to reproduce a Windows folders' structure into PDMworks' vault is not
a good practice. For example, the way we work now is that a top-level
assembly is stored into one folder and all the different sub-assemblies
are stored into their own sub-folders by types of equipment. Is this
kind of system appropriate for the vault structure or should all the
sub-assemblies be put together with the top-assembly?
And If I choose to separate everything, when I check the top-level in,
is there a way to make PDMworks place every sub-assemblies into their
respective sub-folders? From what I understand so far (I could be
wrong), it needs to be done manually. So then, isn't it more
efficient to put everything together in one single folder and not try
to create any kind of structure.
I know you should use the custom properties and a basic Excel register
to make enquiries. But then, what is the kind of folders' structure
that should exist in the vault and what is the goal of this structure?
I also don't understand why PDMworks gives the name "project" for
what seems to be folders. Does it mean we need to work by projects? We
Could someone gives a simple example of a transition from a Windows
structure to a PDMworks vault structure so I can start to understand
how to set up things. Even though a set-up is really company-specific,
I know there is general guidelines and I would like to hear about them.
I don't have preconceived ideas of how it should work. I just want to
have the picture of a good implementation scenario.
SW2005 SP3.0, PDMworks2005
I'm surprised that the obligatory DB shill has not done his drive-by
posting to say just off the cuff and without explanation that "DBWorks
can do that out of the box". I don't dislike the product, but there's
something rather banqueresque about those posts.
There are two basic ideas that you need to keep in mind for creating
pdmw "projects" (it's just a name, you can call it "folders" if you
want, I won't tell): permissions and browsability. By the way, most of
this advice will probably also apply to other pdm products.
Permissions are assigned per user per project. I have seen people
create the structure based on:
- document type
- part function
- department that created it or will use it
- part number (kind of useless)
Often you can combine strategies, such as make the upper level "by
function" and the second level "by document type". That would mean that
if you design race engines, you would have:
- top level engine assemblies
- common library components
- engine blocks
- drawings, engine blocks
- models, engine blocks
- drawings, induction
- models, induction
- drawings, exhaust
- models, exhaust
This is probably my favorite method, but it really depends on your
business. If you have various types of equipment that you make, there
might be another level of hierarchy on top, such as Engines,
Transmissions, Brakes, etc.
I like to separate models (assemblies and parts) from drawings because
of permissions. Non-sw users who look into the vault do not want to see
stuff they can't use, and in many cases that means that they only want
to see drawings.
I'm a big advocate of using a common library area, but again, there are
a lot of ways of doing this. There are parts that will be used in all
the categories or at least in multiple categories, and those go into the
common library area.
There is no way for PDMW to parse out different document types to
different folders, but after they are in the first time, they will
always go to the same folder by default for subsequent revisions. For
that reason, I don't get carried away with putting this here, that
there, etc., cuz it's a lot of initial work.
It also depends on how you work. If you tend to build the whole assy
and then check it and all the parts in, you're going to have to specify
each file that goes somewhere else. If you tend to build a part and
then check it in, there will be less work later.
Anyway, good luck,