Asking for Recommendations for Starting PDM

[DennisD]

I just started with a new company. We are using ADesk products (2D and some 3D), Solid Edge, and have some legacy Catia files. As we grow and our SE maintenance expires we will be moving to SWX Professional, which includes SWX PDM Standard.

We see that PDM Standard can be converted/migrated to PDM Pro. But I am looking for information from you guys, the real users.
1. Is the migration from PDM Standard to PDM Pro easy? The information from the SWX website indicates it is.
2. We want to start small, with a new project in SWX and start using that with PDM in order to learn how to use it before expanding it to other existing projects. Have any of you started this way?
3. Actually, we are looking for recommendations on how to start, what to watch out for, and your general advice so we can do this successfully and with as little pain as possible.

Thanks in advance!
-Dennis

[bnemec]

@matt , I think someone hacked @DennisD 's account. Please check into it.

[DennisD]

@matt , I think someone hacked @DennisD 's account. Please check into it.

No. It's me. I haven't been on the forum in a while because I've started with a new company. My request is legit.
- - -Dennis

[RMcHugh]

Sorry, not a helpful reply, but I'm about to start a new position and I'll be in a similar boat, Dennis.

I'm using PDM Professional now, stepping back to PDM Standard next week at the new place, then on to either Pro again or a 3rd party software that I'll help research and choose.

I'm interested to see the replies here.

Ray

[AlexB]

1. The migration can be as simple or as complex as you decide to make it. It's sounding like you don't have any SW files right now so would you essentially be re-modeling everything in Solidworks and saving that into PDM fresh? If that's the case, then you won't have to worry about a file migration plan.

PDM Standard has a limit on the number of workflows(1) and number of file states/transitions. So for PDM Standard, simpler is better.

Setting up PDM will focus on 2 main areas:
- The server set-up will need IT involvement. A central server can host SQLExpress as well as the PDM Database Service and PDM Archive Service. The archive service requires a large hard-drive(s) to store every version of every file that is/has been in the vault. Every client needs access to this server on your network.
- The PDM Architecture will require an admin to create data cards, workflows, manage users, etc. for the new vault. Since you're starting from scratch, this is important to determine what files will be in your vault, what data you want shown, how you want to handle it, and create a process for users to follow that adheres to this.

To my knowledge, the upgrade from Standard to Pro will require updating SQLExpress to SQL Standard (licenses can be $$). I haven't done a standard to professional upgrade, but I feel like the installer/upgrade tool should allow for this. I feel like one of the bigger VARs probably wrote an article on the process but I'm too lazy to search.

2. I think this is a good approach to a new vault setup. This way, a workflow can be tweaked or file states added/removed without too much headache for the users. More files in the vault means more potential for problems when changing the vault configuration.

3. I think you have a good grasp on how to start. Try and mimic your current drawing release process if you want your CAD data to "Issue" when your ERP system issues engineering changes.

Edit: Link outlining upgrade from Standard to Pro
https://help.solidworks.com/2016/englis ... af5606#Pg0

[bnemec]

No. It's me. I haven't been on the forum in a while because I've started with a new company. My request is legit.
- - -Dennis

You didn't give much specifics in your question. In my one case of experience the chances of success are buried in minutia.

Will any of the parts in the existing SE data set be needed going forward? Either for new projects or maintenance and support of existing.

Does the company still sell products that are modeled in SE or are the products more project based and one and done type of thing?

Does the company use sheet metal?

Have the other users used SW?

Are the parts used on a "per job" basis (again more one and done type of thing) or do they all have part numbers that are managed in some kind of ERP and produced by shop orders then stocked and used across many customer orders?

Are the parts used in many assemblies? High where used counts?

[JSculley]

I just started with a new company. We are using ADesk products (2D and some 3D), Solid Edge, and have some legacy Catia files. As we grow and our SE maintenance expires we will be moving to SWX Professional, which includes SWX PDM Standard.

We see that PDM Standard can be converted/migrated to PDM Pro. But I am looking for information from you guys, the real users.
1. Is the migration from PDM Standard to PDM Pro easy? The information from the SWX website indicates it is.

I believe that product itself is identical to PDM pro, with just a few limitation added. So the underlying technology is the same and migration from Standard to Pro should be straightforward.

2. We want to start small, with a new project in SWX and start using that with PDM in order to learn how to use it before expanding it to other existing projects. Have any of you started this way?
3. Actually, we are looking for recommendations on how to start, what to watch out for, and your general advice so we can do this successfully and with as little pain as possible.

Keep in mind that you do not want to be doing any sort of project where some of your files are in PDM and some aren't. If this new project involves 100% new files, then starting with that project in PDM to work out the wrinkles is a good idea.

If you have existing files that need to be part of the new project, things are more complicated.

When we moved to PDM we had two different types of files: organized (newer stuff) and disorganized (ancient stuff). The organized files all had part and drawing file names that matched their part numbers and custom properties that were (mostly) consistent and complete. The disorganized files had none of that. When we moved to PDM the decision was made to first bring in all the organized files, and PDM was set up to mimic (but automate, to some extent) the manual processes we already had in place. This prevented the 'deer in headlights' problem of introducing users to PDM. The organized files were all brought in to a quarantine area of the vault (visible to admins only) where they could be reviewed to make sure nothing had references to disorganized files. We created all new custom properties linked to PDM variables and I wrote an add-in to map the old to the new and ran the add-in on batches of files. The add-in also synched the PDM revision with the existing drawing revision. Once all that was done, the files were moved to their final location where they were visible to other users.

The disorganized files were then brought in to the same quarantine area and more or less left there. Some of these files are from one-off projects 20 years ago, so there is really no need to do more than put them in the vault. They are only touched if needed, and the rule here is that if you want to use them, you have to put in the work to get them from their disorganized state to the organized state. The PDM workflows and automation help with that process, and it's often just a matter of cleaning up the data card, updating the drawing template and 'releasing' the model and drawing so that a part number is created and the files go where they should based on part number (also handled by an add-in).

The nice thing about PDM is that you can make it as simple or complex as you want. You could simply have a one state workflow where you are just checking files in and out so that you have a file history. If you later want to add more states, you do that and you can transition the files to the new states. If you have files that should be in a different workflow (e.g. Purchased Parts vs. Manufactured Parts) you can add a workflow link and move files between workflows. You do not have to have your entire system planned out to the smallest detail before moving to PDM. If you have processes in place that your users like, you can try to replicate them in PDM and automate the tedious bits where you can.

The one thing that you do want to have planned out as best as possible is what variables/fields you want to have on your data cards. Adding fields/variables is simple, but any files added to the vault before the fields/variables were added to the card won't have values in those fields. You have to go back and add them.

[mike miller]

[SPerman]

In my case, I waaay underestimated the time it would take to prep my data for migration. It was probably 3x what I originally anticipated.

[bnemec]

In my case, I waaay underestimated the time it would take to prep my data for migration. It was probably 3x what I originally anticipated.

I was fairly comfortable with the Design Manager API and had worked in our soup of SE files for several years. So I was able to map out all that needed fixed and how to fix it before loading it into PDM. That's where things went south quickly. The three day PDM Admin course is not sufficient for someone new to PDM to migrate data. In hind sight we shouldn't even bothered migrated the SE data into PDM. As stated by JSculley, trying to work with files in and out of PDM is just not worth while. But, all of our new projects use old parts so new projects had to be done in SE or remodel all the needed parts and assemblies into SW. That's why all the questions about how the CAD data is used and how projects go.

Oh, the bit about projects with files in and out of the vault made me think of some fun we had. If you decide to migrate the old CAD system files, be sure to tweak the name a little. Don't have identical names inside and outside the vault. Yeah, maybe you could cut off access to the old network shares (maybe) but there will still be files squirreled away. CAD doesn't care where the file is, it only looks by name and will silently use the wrong one when you're not looking. Good times. Off the top of my head because it's happened so many times.

User: "I can't check in my file, Vault is broken"
Me: "What does the check in error say?"
User: [blank look]
Me: "Show me"
User: [Tries to check in, ignores everything in the RFD and clicks ok.] "See! doesn't work."
Me: "Do it again but don't click the button."
User: [grudgingly tries again]
Me: "See the warning on that file? The one that says it's not in the vault?"
User: "yeah but it is in the vault" [searches and shows me that pdm finds the file]
Me: "Thank you for using search tool. Now, back in Solidworks File -> Find References. See that file path for the file not in vault? Open that folder."
User: [opens path and sees file with identical file name] "How'd that get there, I didn't save that there..."
Me: "now close Solidworks and delete that file."
.....

[SPerman]

It probably would have made sense to hire someone to prep the data, but they would have had to make a lot of decisions that someone who wasn't familiar with my parts and assemblies wouldn't have. I am glad I did it on my own, but it took a while.

I did hire out the setup of the PDM. (I found the PDM admin course to be lacking also.) I'm sure I could have fumbled my way through it. But I'm also sure I would still be dealing with the consequences of ill informed decisions.

[bnemec]

It probably would have made sense to hire someone to prep the data, but they would have had to make a lot of decisions that someone who wasn't familiar with my parts and assemblies wouldn't have. I am glad I did it on my own, but it took a while.

I did hire out the setup of the PDM. (I found the PDM admin course to be lacking also.) I'm sure I could have fumbled my way through it. But I'm also sure I would still be dealing with the consequences of ill informed decisions.

I'm still fumbling my way through it.

Still on topic for staring PDM, I look back on a metaphorical Venn Diagram. I've stated this before but you're on it again. There were two circles; what knew about PDM and the other represented what our VAR knew of our usage. Unfortunately, they were barely touching when we went live. If I had to do it over (I wouldn't but for conversation sake) we would have slowed up until the two circles shared at least 50% area. Would have cost more at first but could have saved many times that.

[JSculley]

I'm still fumbling my way through it.

Still on topic for staring PDM, I look back on a metaphorical Venn Diagram. I've stated this before but you're on it again. There were two circles; what knew about PDM and the other represented what our VAR knew of our usage. Unfortunately, they were barely touching when we went live. If I had to do it over (I wouldn't but for conversation sake) we would have slowed up until the two circles shared at least 50% area. Would have cost more at first but could have saved many times that.

Most of what our VAR set up went right in the trash shortly after they were gone. You simply cannot explain your processes and future needs to them in the time available. I requested the Admin Guide after we purchased PDM but before we implemented it. I read it cover to cover before they showed up so that I understood what they were trying to do and could point out areas where I didn't think what they were doing fit our needs. I didn't let them touch our data at all. It would have taken them years to clean it up, whereas it took me a few months, but the users were able to start making new stuff right away and if they needed some old stuff, I could bump it up my priority list for cleanup/conversion.

[AlexB]

Most of what our VAR set up went right in the trash shortly after they were gone. You simply cannot explain your processes and future needs to them in the time available. I requested the Admin Guide after we purchased PDM but before we implemented it. I read it cover to cover before they showed up so that I understood what they were trying to do and could point out areas where I didn't think what they were doing fit our needs. I didn't let them touch our data at all. It would have taken them years to clean it up, whereas it took me a few months, but the users were able to start making new stuff right away and if they needed some old stuff, I could bump it up my priority list for cleanup/conversion.

This is essentially what happened with me right after I started in this role. I inherited a vault that was set up 15 years ago in the same manner you mention above (VAR created most of it). In the time since, things had barely changed within the vault and how it was used, but business processes had changed a lot in that time.

I went completely overhauled the workflows and revision process to match our system and the migration of old files to the new system was a huge headache. There is still data hanging out in the old workflows that I need to get to but 90% has been upgraded to the new workflow. The new system seems to be working better.

[Brian-M]

Not free in time or money, but PDM Standard to Pro is a well supported migration path.

Vault setup:
Keep it simple. e.g. Edit--> Review --> Approved --> Obsolete. You can add more workflow states later.

Turn on prevent duplicate filenames early. https://help.solidworks.com/2020/englis ... _names.htm

Yes, you can start with one project. Not a bad method to start. The trick comes when you try to migrate files (say in a second assembly), that have already been moved into the vault. Then get to know these tools: https://help.solidworks.com/2020/englis ... 38bd18#Pg0

PDM Pro or Standard aren't great for remote access. But they work ok on VPN if your assemblies are small.