We are going live with EPDM soon. Here is my primary engineering workflow for models, drawings, and other revision controlled documents.
Can I get some feedback from you guys? Thanks much!!
I typically like to have a different loop for Revisions, this gives me the flexability to see how many files are under Revision vs. New Files.
I know there are additional ways to do this, but having the 2 process helps me out.
Additionally, I can tie a Set Revision off of the initial WIP to get files set to the correct Revision, when it is a legacy file or from a different source.
I am a fan of the 2 processes..
Kip Speck CEPA
At a glance the states and transitions look okay, however, for documentation purposes you might want to add a bit of detail.
I have attached one of my workflows to illustrate. (I'm still using 2012, hence the different UI look).
This will help understand how you revisions will increment, what actions take place on various transitions, etc.
Good idea. Thanks for sharing your workflow!
I wish the actual Workflow Editor allowed that kind of detail to be included in a workflow definition. IMHO, the clumsy and ham-fisted workflow editor interface is the most glaring and egregious weakness in EPDM. Would that the programmers should put even a tiny bit of effort into cleaning up this primitive and amateurish interface...
Attached is what I created for our Users for reference. It is a clean vertion of our actual Workflow, which is fully paperless.
I suggested an enhancement in this area...feel free to submit an enhancement request
I can't open the file...I thought is was flash, but, it errors out when I try to open it...
Drag and drop it into Internet explorer or firefox and hit go. It works then.
Joy, it's Flash document it can be played in IE or other browsers.
Yeah, I figured it out earlier...
That is nice looking what program did you make that in?
After an ECO is Assigned, is there really a difference between Work in Progress and Change in Progress? If a document in Change in Progress is linked to one in Work In Progress, it will progress through the transitions together so why distinguish? Why not go from ECO Requested back to WIP and eliminate a few states.
Can files be changed at the "ECO requested" state? If so, the "Cancel ECO" will bypass the approval process.
Excellent this is exactly the feedback I was hoping for.
Good point on the separate loops. Our VAR did it this way with 2 loops, as is the default EPDM workflow. I don't see a reason for this though.. Will consult with VAR.
No, not planning on allowing changes except for WIP states. Thanks for checking me.
As for the Cancel ECO, how do you plan on dealing with the Versions that were created since it was last Released?
Inevadably, the engineerirs will send files to Under Revision (ECO) and after sever aversions have been made, prior to releasing the file, decide to cancel the EC.
When an ECO is cancelled you will need to handle getting the files "Rolled Back" to the Released State,
I too have decided 2 loops is better. Mostly because I don't want released parts to be deleted. They need to be obsoleted but still available to view. If they go back to the pre-release WIP, where designers have delete permission, then the parts could be deleted.
There are probably workarounds to that, but 2 loops is easy.
Cancel ECO now goes to a state requesting rollback.
I benefited a lot from this forum discussion so I thought I'd give back to it with another workflow sample. I would also appreciate any comments on my draft workflow. I’m testing it in a sandbox vault.
One thing I've done differently is try to simplify the terminology. I was thinking of the user experience, and I get confused looking at workflows that use subtle variations to indicate different transitions/states. I’m sure one can get used to it but we will have some infrequent users. So I used the same name for transition and state when possible – I’m still playing with that. Transitions I put "->" after each name to make it easier to differentiate. I also tried to keep State names short to easily fit in the column view.
Regarding above discussion on separate path for new files and changing files - I decided to go with one because: 1) it makes for fewer states (which I've heard are easier to add than they are to remove). 2) I don't have anything different I want to do if I had two paths (except maybe the prevent delete of released files issue that Terry pointed out). I do see that two paths might be better for reporting, give more info on when files pass through a state – but I don’t know how to make a custom report yet so that is just theoretical.
In our process Sub-Rev is similar to Admin Change or Quick Change or to minor revisions I've seen mentioned elsewhere - it comes back to Released state with the same revision letter on it. Non-EC path is for lots of things that don’t need a formal Engineering Change Order (which we document in ERP), but it still has the benefits of using Revisions. For example: Mfg Engineering fixtures (solidworks), internal engineering specifications (.doc), reference pdf, prototypes (solidworks). I’ll separate the Non-EC path to make the main workflow more simple, and because I notice the user can see what workflow name the current version is in.
One thing I have questions about is canceling EC, and how much I need to set up to make that happen correctly. Instead of Rollback (which I guess deletes the Versions you specify), it seems like there should be a way to take the old Released Revision and make it the newest Version again (then the wrong turn is preserved if we want to go back to it)?
Terry Raymond – I’d really like to see how your workflow turned out now that you have been using it for a while. Can you post it again?
Protip: If you number your transition names, you can control the order in which they appear on they context menu.
Ah cool. I imagine you locally number them, based on how many transitions are leaving a State (so you reuse numbers)? ...and some users don't see some transitions, so you make the transition with the most users the number 1?
Yes. One through X based on how many transitions leave the state. Which transition gets which number is a matter of choice. Most common, most users, etc.
Hey nice ideas with the arrow & numbers... I might steal that! Here are my current workflows.
One thing I have in my workflow is a 'Recall' transition to go along with my Approve and Reject transitions. The idea is that if you submit something for approval, you can recall it in the event that you discover a problem before the approver gets a chance to look at it.
We self-reject. =) Far too often...
Another update on how my workflow turned out. Nothing revolutionary here, but I thought it migth be helpful to someone to see where a little more work got me. I'm still accepting ideas too. [[original March 24, edited April 15, 2014]]
Main CAD+EC workflow. I run CAD and my EC parent item (an Excel workbook with drawings Pasted as References) thru this workflow.
I realized I could make transition from Released to Edit the same transition name "Edit (EC Required) >" as from Simple.Non-EC Edit to Edit, so EC parent item can pull drawings out of Released state.
Starting out I'm leaving most permissions pretty open. I could have put in more steps and states, but I can always add more later.
Simple, non-cad (Excel and Word specs and procedures mostly):
Legacy Workflow. Not sure if others do it the same, but I have it use the Revision mapped (or typed) on the data card to update the Database Revision:
Transistion into this workflow picks up a SourceState variable, so it knows which path to use to automatically get out.
Now if I can get email notifications to work... and my pdf auto task is not generating good pdf drawings, balloons missing and stuff (per VAR this should be fixed when we have both EPDM and SolidWorks on 2014)...
So for all interested, here is how my workflow turned out. Many thanks for all the helpful input. This community is a fantastic resource.
Retrieving data ...