This content has been marked as final. Show 4 replies
A few things I can think of:
- Stick with a revision scheme. I know that most companies have a set revision scheme that won't change, but if you're growing and going to be doing any migration, pick one and stick with it.
- Try not to use configurations if you can avoid it. As seen in recent posts, PDMWE can play havoc with your sanity as far as configurations goes.
- For each department that is going to use PDMWE in any capacity,
ask them what they would like to see from it and document it.
Whether or not if you know the software can do what they want,
write it down. You'll be more prepared managing your workflows if
you understand what it is each department wants. You'll also have
simpler workflows when you remember to use workflow links. Our ECN
process has been evolving for over a year now due to this. If I had
known what I do now after all that time, I would have started
differently. I started big, but now realise that if I would have
started small, we would be where we want to be months ago.
Writing down what people want will also allow you to have a greater impact on the development of the software as there are limited users providing feedback.
- Create a group called 'All users' and have the software add people automatically to this group. Even if you never use it, you'll be glad you created it when you do need it.
- Use groups of users. Working with groups is a heck of a lot easier than dealing with individuals.
- Pay attention to file types and those that you don't want duplicate filenames for.
- If you have controlled documents (and I am sure you do) make sure one can not check out a file in a "finished" state when other users (i.e. vendors) can see a file in that state. A user shouldn't be able to check out a drawing in a Approved/Released/Controlled state if a another user is going to be looking at that drawing. It's better to hear that he can't see the file than the part came in wrong because he sent the old drawing to the vendor.
- When you have a your production vault set up and you're happy with it, create a copy of it to another vault as a sandbox. It will ease your mind knowing that any playing you're doing with a vault isn't going to mess with production work.
- If you have someone in your company familiar with .NET and SQL, introduce them to the API early. While PDMWE can do most tasks, having someone on board that can work with it on a 'deeper' level will help if the need arises. Especially when integrating with an ERP or MRP system or generating reports. (Use the sandbox for dev work.)
- Delete variables you'll never use. Do this early on. It helps when generating reports and doing dev work.
- Don't allow state changes without entering comments. Even I hate it, but it forces users to tell why they are changing state on a file. It will help when viewing history on a file.
- Don't rush your implementation. Take your time.
This is what I can think of for now. Some may disagree on some points.
Does your implemantation plan involve geographically separate Engineering centers?
Building on Lee's first item on sticking to a "set" revision scheme.
If yes, will they share or re-use each others model geometry?
If yes, do there Engineering groups use a uniform/common part number scheme to identify your products?
If your sharing model data via a single central PDMWE vault make sure you pay attention to network between center A & B.
Obviously these only apply if the answer to the first question is yes.
Why would you have a group called "all users"
the only thing I can think of is for notifications to send to all.
That's the main reason. Notifications sent to everyone, as well as adding or removing access to directories helps when one can set permissions on everyone in one shot.
Basically if you ever need to change a global permission level (workflows, directory access, etc,) it comes in handy when you actually have a global permission. Creating an 'All users' group permits that.