Another alternative is to create a separate "Experimental" part numbering system. This is definitely old school, but my former company had an old accountant's ledger that you would write the next sequential number, a description, project, etc. You would use this number until a final decision is made as to which alternative is to move into production.
I am not suggesting that you find an old ledger, but a similar process could be created in Enterprise. We had many departments, so each had their own prefix. I think ours was EXD-#####.
I have also been considering this...
the question on this is how to make it easy for the user (through a menu option) to put the final design back as the original without having to copy it outside the vault?
We are faced with the same dilemma. A new design might require using existing parts but they may need to be modified for the new design. The new design might be a year or two in the making before its finally released. These modified parts can't just be checked out and changed as all the existing production assemblies would show the "what if" changes that are occuring to the existing part as its being redesigned. The part also may under ECO changes as the existing designs are further refined for manufacturing and field changes.
The users currently work outside the system. We haven't yet implemented the practice but we are considering just having them copy the production file to their project and work on it there. Then when is finally reasy for release, we'll have to validate that the original hasn't ungone a revision or change since the copy was created, then just over write the production copy with it. I think this is better than them working outside the system and have some files in and some out.
That is a tough one. I haven't found any solution I love. The one I recommend is to remove the read only flag as described here:(http://www.3dvision.com/wordpress/index.php/2010/12/27/what-if-workflow-workaround/)
Though if you have a design cycle as long as Jason Capriotti mentions (one or two years) I wouldn't do it...that is a long time without backups.
Nice info but...
This would be worse for us than working outside the vault. Working outside the vault the files can be stored on a network drive which is backed up. Working this way would mean working in the local vault (On the C:\ drive) and it is not backed up... It also does not cater for multiple concurrent "what if" scenarios.
I have come up with a method that works for me. (Currently still testing but it's looking good!)
- A Dispatch script prompts for a "Branch" name and then copies the file to that "Branch". (e.g. "original filename.branch.sldprt")
- The Dispatch script also sets the "Branch" variable on the datacard of the copied file to the Branch name. The "Branch" variable will help to control the file within the workflow and to ensure that a branched file cannot be released to Tooling or Production.
- The branched files will kept in the same folder as the original for now to simplify the next step...
- A second Dispatch script is used to copy a branched file back over the top of the original (tests will be done on filename, etc) and set the "Branch" variable back to "Main". ("Main" will never be allowed as a branch name)
Assemblies will also be able to be branched but they will not be able to be merged back - any broken mates in the original assemblies will be fixed after merging back the changed files.
Drawings - I have not decided on... the idea of branches is for design exploration.
I hope others will find my investigation and process ideas helpful.
PS. If this all sounds a little PTCish that is because I worked with their software for more than 10 years...