work in a large team with the vault

[Avoplus]

Good morning to all,

I beg to review all the threads open so far (not to run the risk...:tongue without, however, find answer to my doubt. I read that some of you do not use the vault because they are "isolated" designers others because they are in a team of only two or three people, others still because, even, they do not have it...

My question, however, is: how to organize teamwork with a pdm?

(for convenience, I refer to iv2010 and the vault, but I imagine that the "philosophy" is generalized to any other pdm...)
Until a project is easily subdivided into sub-projects (think of a assembly line, for example), one can entrust to a single designer the development of the sub-project and the project leader "assembles" the pieces. but when the project is complex and the designers are numerous and must "interagire" in the same together, how can you do it?

to make an example (sciocco, very forced and not quite relevant but that can make the idea...): The car. a designer takes care of the frame, one of the mechanics, one of the body shop, one of the insides.. .
all, ultimately, must refer to the same group but each developing a sub-axieme that interacts with others (points of attack, encumbrance, etc.).

how would you organize it?

 

[Stiky]

the problem of organizing a design team does not rejuvenate the fact of subdividing the "big together" into many "miniassieme", as this for the software is configured as a series of separate projects.
problems arise when parts/axis are changed common to the various projects, in that case or you have vault or do not leave alive

ps. vault is not a pdm, but a simple file manager.

vault works with a single project file, and many subfolders in which the various files are distributed, various versions and versions of each file are stored, check in/check out is managed, a database stores the version history and references between the various files.

I have not understood what you mean to organize the work, if you mean what procedures are adopted in the company with the pdms, it is a little long discussion and depends on the type of pdm adopted, the type of corporate organization, however the speech is a little long. Can you specify the question better?

 

[Mario SJPD]

as this for software is configured as a set of separate projects.

It is true but they are interconnected so the vault is obligatory.
Now I'm working on a big plant with 9 other colleagues in two different offices without vault we'd be lost.

 

[Avoplus]

ps. vault is not a pdm, but a simple file manager.

"product data management"... the vault not only manages the files but also the links between them and, although in a resible way, its versions (ok that are not really revisions, but with a little imagination... ).
Let's say I like to consider it an embryo pdm. .

I have not understood what you mean to organize the work, if you mean what procedures are adopted in the company with the pdms, it is a little long discussion and depends on the type of pdm adopted, the type of corporate organization, however the speech is a little long. Can you specify the question better?

Let's say that my curiosity is about the practical aspect: feeling and comparing me a little with other experiences. . .
when I talk about "managing a project" I mean: how to organize the management of project files. Let's see if I can explain...
manage everything through a general set and leave to the individual designer his subassieme (extracted)? or, create more general assemblies and using derivative parts for what does not interest?
or again, how to make sure that, unintentionally, do not update parts/axis that are pertaining to others? (ok, in this case it would be enough to have extracted them, however, it can happen that the modification of a subaxieme affects another...).

Unfortunately, to this day, I couldn't define "auree rows" with colleagues and it is a chase of white, green and red... of assemblies with "high" constraints and things so...

 

[Stiky]

"product data management"... the vault not only manages the files but also the links between them and, although in a resible way, its versions (ok that are not really revisions, but with a little imagination... ).
let's say i like to consider it an embryo pdm. .


let's say that my curiosity is about the practical aspect: feeling and comparing me a little with other experiences. . .
when i talk about "managing a project" i mean: how to organize the management of project files. let's see if i can explain...
manage everything through a general set and leave to the individual designer his subassieme (extracted)? or, create more general assemblies and using derivative parts for what does not interest?
or again, how to make sure that, unintentionally, do not update parts/axis that are pertaining to others? (ok, in this case it would be enough to have extracted them, however, it can happen that the modification of a subaxieme affects another...).

unfortunately, to this day, i couldn't define "auree rows" with colleagues and it is a chase of white, green and red... of assemblies with "high" constraints and things so...

the speech is very complex, personally i wouldn't compose my life with derived and similar parts, you could force your colleagues to work on the general axieme by forcing them to use a certain lod with subsitutive parts, but what happens if one of your colleagues is forced to change one of another's assemblies to inhale his piece. (e.g. the technician who draws the wiring will have to insert holes in the shell for the passage of the cables).
the procedure that you usually follow is to store everything every evening and load from vault each time you open a file, taking care not to override the extracted files.
it seems very difficult not to allow technicians to edit pertinanenza files of others, you should give different roles and accesses for the various files....maybe if you use vault manufactoring you can do something similar, but i have no experience.

p.s.: p.d.m. = product data management, product non file, therefore it is previewed the management also of db, technical manuals, costs, and other:smile:
i know i'm pedant:redface: