This might be something of a “vent”…As I’ve been working on our implementation I keep finding myself frustrated by trying to complete a set up of one thing only to discover that there is another thing that has to be set up first. I’ve looked at the implementation documentation, the user guides, etc…but I would LOVE a simple list of steps in order of what things need to be set up in order . I can’t seem to find such a creature… maybe I’ve just missed it? In test and Pilot I wasn’t AS concerned about it… but now I’m trying to get all the setups in Production and I’m petrified that I will miss something super important but also super simple or that I will inadvertently add something at the wrong time. I may also be moderately stressed by this whole process… I’m constantly between “I can’t do this” and “what have I done!?”
Not sure if the structure of the Implementation Guide has it but if you have DMT, the Migration Menu is a pretty good guideline.
I’ve been there. the week before going Live and I wanted to throw in the towel.
Best advice I can give is to make regular backups of the DB while doing various parts of the implementation. If you realize you did something wrong, “rolling back” to a previous point is much better than starting from scratch.
Also, most dependencies will just make you have to stop and do something else first. I can’t think of one where doing Y before doing X, results an any major problem. 99.9% of the time it just won’t let you do Y, until you’ve done X.
Other words of advice:
- Only enable things you absolutely need. Don’t create things for “potential future use”. Keep those possibilities in mind when laying out your “architecture”, but don’t add them just yet. An example would be Product Groups and Part Classes. It might seem desirable to set up every one you might ever want to use, even if just for reporting. But don’t you can add them later, but removing “unused ones” can become impossible.
- Throughly understand how the UOM Classes and UOM’s work. This is another area where you shouldn’t add UOM’s that you don’t use. Unless you really sell or buy, by the gross, don’t make a UOM for it.
Thanks Calvin! I learned very quickly about UOM and how easily they can screw you up. I was VERY careful when creating them in Pilot and Production!
Good to know on the dependencies; though if I could do them in order of what’s needed first it might save some sanity or lessen the gray hair. I end up having to go back multiple times because I get interrupted about every 5 minutes to address another issue somewhere else – I’m sure that NEVER happens to anyone else! 
This user group has been a wonderful resource !
AH! Hadn’t thought of that! Thank you!