"I'd like to know does it create a vault database that we would load files into or is it more like an overlay of Windows Explorer that leaves our current file system and individual file paths in place? "
The answer is Yes It kind of does both depending on what you want it to do. I've taken existing folder structures and literally picked them up and moved them into the PDM vault. I've also created completely new folder structures since the company realized their past mistakes and wanted to get control of their data. I think the latter is where you want to go.
Whether you want to migrate your data or not, I would get what you have analyzed so you know how crazy and knotted up your duplicate files and missing references are. Not knowing will just create problems down stream.
And yes, it can see and manage configurations, although you only get one data card per file so don't expect configurations to have their own system managed revisions. Config Specific properties are fine, but I only see one revision per file.
Thanks for the response, Steve. I'm glad it can do a database, though still disappointed it can't fully manage configurations. I'd had a webinar of EPDM a number of years ago and it couldn't then, I was hoping it was improved by this point to do so. Trying to migrate any of our current data over to a vault would be like herding cats, instead we're taking the remodel/replace route for what current product we're staying with so it's all playing together nicely using all the same start parts, properties, etc.
I've worked with a few companies in setting up an EPDM vault. My experience is that it is never easy to transition from an uncontrolled system to a controlled vault. It's a culture change not just a computer software change... With this being the case it has always paid off in the long run!
If you've got duplicates of the 'same' file from pack and go's you'll have your work cut out for you, but the ease of controlling the release of the correct drawing to the shop floor will improve dramatically. Spend the time planning it so you can execute it well.
As for migrating your data:
- How are the duplicate files named, is it a serial/part number or is it a text description?
- Are these 'duplicate' files duplicates (ie exactly the same) or are they potentially different from one file to another.
My experience is that over time they are similar but not always the same. Personally I'd "allow duplicate file names" it's a check box. Get the files in the vault, and work through removing the duplicates. Then uncheck the box, forcing users to name files differently.
As for configurations I manage them with an incrementing number. The part number becomes:
###### - ConfigNo
The config number increases. I find it works well. The revision of the config changes with the .sldprt file though.
All the best with the migration however you decide to do it.