-
Re: EPDM Rollback Task
I would not let them pull files from a state unless they know they are going to indeed make a change. You can create a new transition leg though to send it back... The rev should not change unless your rev it... Only the "version" would change.
-
Re: EPDM Rollback Task
I would have thought just creating a transition call "no change" or something would do the trick and have no actions on that transition. thus no revision would be bumped and it would only create a new version, not revision.
-
Re: EPDM Rollback Task
Hi Jacob, it sounds like your users are moving things out of "controlled" and making changes... even checking them in. Then, some point there after they decide they don't want those changes. Is that correct? So now you have 1 or more versions after the last revision that you don't want. My questions to you would be, what is the harm of putting the file back to the "controlled" state with leaving those versions in place (as Josh suggested).
-
Re: EPDM Rollback Task
actually, just thinking more about this, why not just use the roll back feature in the history?
-
Re: EPDM Rollback Task
This roll back feature enable a user to go back to particular version and clears the history till the roll backed version.
It doesn't roll back the state.
The best option would be to create a transition and take the file back to the required state back.
Thanks & Regards,
R.Vignesh-
Re: EPDM Rollback Task
R. Vignesh wrote:
This roll back feature enable a user to go back to particular version and clears the history till the roll backed version.
It doesn't roll back the state.
It actually does. Think of state as an attribute of the file - when rolled back, it regains the state it was in at the rolled back version.
-
Re: EPDM Rollback Task
I agree with the original post in that EPDM is lacking in this area. Rollback is overkill, and many Admins to not want to give their users that much power to destroy versions. So often Admins end up doing the rollbacks to save the time of a manual undo (it saves the users time, but it wastes the Admins time).
For a proper Undo, or Cancel EC action... What is needed is a transition action that will find the last Released, Revision stamped Version - take that and promote it to be the most current version, and check it in as you move back to the Released State. There is a record of what happened, the work is not lost, the versions with changes you considered are still there, but the released revision is restored.
EPDM does not have this. It can be done manually, but it would be difficult to have the system check that it is done correctly, and it is not fast if there are a lot of files. Currently we use both the Admin Rollback and the manual Re-Release technique, depending on the nature of the canceled EC.
-
Re: EPDM Rollback Task
There is an improved rollback add-in available from hawkridgesys.com. I have not tried it, but it sounds safer than the standard rollback. It does not do quite what I hoped for (preserve all versions while promoting the revision).
See Rollback to Last Revision tool HawkWare - Rollback to Last Revision
""""Rollback to Last Revision will remove all versions of a file up to the last time its revision was incremented."""
-
-
-
Re: EPDM Rollback Task
Rollback will do the trick and put the file back in its former "controlled" state. However, rollback deletes history (after rolled back version) and cannot be undone. I would use rollback only as a last result privilege of the admin.
use permissions to make sure files leave "controlled" state only by authorized users (groups), like the person who issues the ECO.
It's always a good idea for the admin to build some "escape routes" and "short-cut" transitions, permitted only to himself. this why you can send un changed files back to "controlled" with the same revision, and without the hassle of re-approving them by everyone.
Iftach
-
Re: EPDM Rollback Task
Hello Mr Iftach,
Say if i have Revision B which is rolled back to Revision A. Then it will remove the history of all the transitions and state change done between Revision A & B. Later increment the revision again, it won’t go to Rev C but go to Rev D instead. This is because the increment revision command does not take into account a roll back action in the workflow and it skips the revision counter you rolled back from.
Thanks & Regards,
R.Vignesh
-
Re: EPDM Rollback Task
Hey R.Vignesh,
Say if i have Revision B which is rolled back to Revision A. Then it will remove the history of all the transitions and state change done between Revision A & B.
Correct.
Later increment the revision again, it won’t go to Rev C but go to Rev D instead. This is because the increment revision command does not take into account a roll back action in the workflow and it skips the revision counter you rolled back from.
I wasn't sure, so I just tested it.
first image shows the history after 2 "increment revision" A to B , B to C :
second image shows history after rollback to A:
third image shows history after another increment revision:
It got it right.
Do you get a different result, or did I misunderstand the question?
best regards,
Iftach
-
Re: EPDM Rollback Task
I just checked this issue has been fixed in EPDM 2015.
Till 2014 the roll back didn't used to reset the revision counter.
I am still using EPDM 2014,that's why i was getting a different result.
Thanks & Regards,
R.Vignesh
-
Re: EPDM Rollback Task
I read this just yesterday, which may help explain what *some* are seeing/experiencing:
http://www.symsolutions.com/symblog/item/2015-what-s-new-in-epdm-part-3
More importantly, to Jacob, the suggestion Iftach made about the "escape route" (we call it a trap door) comes to mind.
With a Controlled document, aka "Released" or "Production", making a change should be triggered by an action. Many/Most requirements state that a locked down document only be available as Read-Only; therefore, when the document is to be changed, it moves out of Controlled due to said action. During the change, if the decision is abandoned, the workflow includes a "Cancelled" state and goes right back to Controlled.
-
-
-
Re: EPDM Rollback Task
Unfortunately, sometimes changes need to be abandoned after they've been started. Hopefully, it's the exception but it does happen. As the Admin, I will roll these back to the last released revision, before the files were put in a WIP state to be worked on. For a moment, the escape route sounded interesting - having a transition state that would put it back to a controlled state. But wouldn't that be putting the partially-modified files into the controlled state? Or is the transition state actually doing a roll back. Whatever's done, the files need to end up in exactly the condition they were in before they were taken out of the controlled state.
I've never encountered the revision counter reset issue. But then, we wouldn't roll back a revision, only things that are being worked on toward a new revision. In a production environment, a new revision only comes about through an approved ECO, so you can't just wave the wand and make it go away.
-
Re: EPDM Rollback Task
Hey Jim;
that's our exact scenario here. This whole thread has actually pushed me a bit - I didn't want to abandon "1/2 done edits" - so in addition to the escape route, those changes are in fact lost (on purpose).
You're not:
1. rolling back (In some workplaces, this is forbidden)
2. putting "1/2 done edits" back into the workflow. The changes were abandoned on purpose.
By the way, the EC approval (in our case) is done by a minimum of 7 authorized MGRs, and the vote moves it from Production to WIP. Like I said, we're very similar, as are most companies.
**I do want to add that during my test, I crashed my Development Vault, and it took an AE with programming knowledge to fix! HA - don't worry, this isn't the usual, I was a bonehead. When editing a workflow, don't stop midway and try to ESC. Funny, I'm trying to solve a "stop midway EC documents" issue; quite ironic.
MattP
-
Re: EPDM Rollback Task
We work a little differently here, in that we'll actually do work before the ECO and leave the files in a Waiting for Approval state until the ECO is approved. We may change that but for now it's probably a little more common for us to have things rolled back, though it's still not that common. All work is, indeed, lost when the rollback occurs. Either things move forward to release or they're not required and therefore eliminated. No mercy!
-
Re: EPDM Rollback Task
Jim;
Interesting! That was done here, too, and it was changed before I arrived. The engineering dept. saved a ton of time/effort with that small readjustment. I would prefer to not touch any documents until people have signed off the change. No need to disturb anything, and as I've stated, some places I've worked with heightened security or foolproof workflows have demanded that "nothing is touched until I have signatures!!" It isn't so strict here, it was simply a money saver. If you want some ammo for making that argument to do so, ask on here for comments, and certainly take the two I made above.
MattP
-
Re: EPDM Rollback Task
Weird, they approve the EC ahead of time? How can you know the details of the change before working on all the files? What will be the BOM changes? What exactly is your redesign of this part going to look like, etc?
-
Re: EPDM Rollback Task
Brian,
I've heard that many outfits, including military, will define and approve a change before making the actual edits. There can be some work/time/cost savings in doing so and there's been talk here about moving in that direction. But I struggle with the same questions you do.
Can a set of redlined BOMs and drawings adequately define the change, especially complex changes? Don't you need to manipulate models to understand the impact? And if so, do engineers then have to pack and go their files and work on them locally? What if more issues are found while doing the actual work - does the ECO have to be revised and re-approved? I'm having a hard time seeing this as a smoother, better way of doing things.
-
Re: EPDM Rollback Task
Hi Brian;
This is all done during the redline markup period. The more robust the redlines & markups & misc info ("prep"), the quicker the ECx moves through Approval #1; there are 2. Approval #2 reviews the ECx to make sure it stuck to it's initial direction and not a sly move or non-focused catch all. One HUGE complaint in the past had been "They provided hardly any tangible info regarding the change". If someone wants an ECx approved, they must provide documentation. If it's obvious, there will be many people behind the change. This isn't criminal court, mind you, but things aren't going to be changed on a whim either. Keep in mind, this happened before I arrived here. I just happen to think that this process is successful. .
As Jim points out, this is S.O.P in Military environments.
As with every situation, there are always exceptions. Where you may be critical, it actually improves the ECx; by which I mean, if the attention and detail find the need for model editing, perhaps FEA or Simulation, or the many other more cases of "physical editing" that will all go into Approval #1, then its a pretty significant ECx. Chances are, if Approval #1 is given, that type of work, most likely detailed and significant, is monetarily justified. Think about it in terms of $$, because 1/3 of the ECx Approval process involves financial directors, i.e. people whose a$$ is on the line for wasted or ill-spent decisions. In Military organizations, it's not only $$, it's accountability. So fear not, if the ECx is that serious that you guys building medical equipment or Rockets get nervous, maybe the process just isn't for you. Again, things in the forum are just opinions and shared information. I couldn't possibly apply everything I've read here over the years. I find what may work, try it on, and if it fits, I'll ask my coworkers what they think. This is Solidworks - if you don't know, there are 4 ways of doing something correctly
MattP
-
Re: EPDM Rollback Task
Matthew - I'm glad you think it is successful. But to me that sounds like just moving work around and calling it something else. And then you have a 2nd approval process?! That sounds like waste - no offense.
If someone credible says - "I think this is a serious problem" (they submit an ECR) why can't engineering investigate the change without a bunch of signatures? If you are military and they have extra bureaucracy then I guess you are stuck. The only time savings with pre-appoval occur when the EC is cancelled (which is a small percentage for us), otherwise I'm pretty sure it is a waste of time (but the details of every company are different)
"""""""""""" [Frank Watts, Engineering Documentation Control]
Avoid the temptation to add more information [to the ECR] than is shown. The more
information added, the higher the likelihood that you are trying to “preprocess”
an actual change. This is a mistake that many companies make. They
include or use the ECO form in order to include; disposition of materials,
effectivity, impacts, stock status, approvals, etc., etc.
. . .
Rule: Do not try to “preprocess” a request as a “what if we change.”
Reason: It will be a waste of time and energy even if the
redesign remains as requested, the time lapse will
require review of all prior work. The Cognizant
Engineer is also likely to design a different fix.
Rule: The request for change should contain just enough
information to allow the Cognizant Engineer to
make a decision as to whether or not there is a
problem that needs fixing, i.e., to take ownership of
the problem.
"""""""""""
-
Re: EPDM Rollback Task
Hey Brian;
one important aspect you forget; you and I and Frank and I never worked at the same companies. We'll just have to use our own experiences and history as success stories. In my case, this current ECx process had actually found success before I got here, I just adapted it digitally, which I continuously try to improve, if applicable.
Good insight tho - Thanks.
MattP
-
Re: EPDM Rollback Task
I did throw in a little parenthetical statement to try to be more humble You are right, I often see people on forums saying there is only one way to set up a process - but things are very different for a sheetmetal shop, or one-off shop, or whatever. So I try not to be like that.
-
-
-
-
-
-
-
-
Re: EPDM Rollback Task
Hi Jim,
Reading this again,I think in your case a manual roll-back is the only option. As you predicted, if a new version have been already saved, an "escape route" transition will only put the newer partly-modified version in the controlled state. A transition cannot rollback a file. I can't think of any way to automate this.
In my company this rarely happens, so I can easily deal with it manually.
This discussion got very interesting dealing with approval and changes process in general. As have been said, companies differ a lot in these things. and I don't think there is a generic "right" and "wrong" ways (although some advisors and book authors make a lot of money claiming there is). I think the EPDM admin is a key person when deciding on the company's policy. We covered some of the reasons here:
In my company, the R&D designers and engineers can't check-out or change state to an approved file. It is as if the file "belongs" to production department. Only production engineering can issue an ECO, and change state of an approved file, sending it to changes in the R&D department.
Of course, in order to issue the ECO in the first place, production would want to have an assessment of time and resources needed. Sometimes an assessment can be given based on experience, but sometimes R&D have to actually work on the file for a while to determine. EPDM doesn't have an out-of-the-box solution for this (at least I can't think of any), so the method we use is "copy tree", creating a copy of the file(s) in the designer's "sand-box" folder in the vault. He can then play around with the files and see what it will take to make the changes. These test copies are deleted later on. The disadvantage here is obvious: They may have to repeat the work on the real files after these are authorized for changes. However, usually it is no more then a few hours or a day of work at the most.
I wish EPDM would allow some kind of branching in the version history, or special states/revisions that solve this some how.
Iftach
-
Re: EPDM Rollback Task
Iftach,
"""""""
I wish EPDM would allow some kind of branching in the version history, or special states/revisions that solve this some how.
"""""""
Perhaps that would be better for your system. But it seems like existing functionality in EPDM can handle this. Consider changing your workflow to address the concerns but give R&D a little more flexibility. Your hands may be tied by outside rules, but if they are self imposed rules then that is unnecessary waste - several hours of someone's time seems significant. Also, I have seen cases where people say these are the unchanging rules, but it turns out the rules don't dictate at that level of detail, and there is some wiggle room.
I find the difference between business practices, and polishing our own, quite interesting. I'm sure you have thought about these things and you seem quite sharp, I'm just putting some ideas out there in case a different perspective helps. Looks like your team is in medical devices, so more regulations than us.
So anyway... Why can't R&D work on the original files? So what if they move a file out of an approved state? - with permissions set appropriately Production would still only see the approved copy. A version is just a copy managed by PDM; what you are doing in making outside copies sounds like bypassing some of the primary advantages of PDM. Production should of course be in the review process, and be able to see the changes once the EC gets going.
Regards, Brian
-
Re: EPDM Rollback Task
So anyway... Why can't R&D work on the original files? So what if they move a file out of an approved state? - with permissions set appropriately Production would still only see the approved copy.
Brian, I'm just curious - If you let R&D work with the original files and their actions aren't eventually implemented, don't you end up having to roll back anyway? The files no longer reflect the latest design state. I'm a doc control guy and want things orderly, so I also shudder at the thought of files being in some sort of WIP state when they're not necessarily on a mission, headed for the next revision. And then priorities change and the files get left there.... It just sounds to me like things could get real messy in a hurry.
I know some of this has to do with each company's own environment and rules. Our files stay in a released state unless they're actively being worked on. If they're needed for an ECO, they have to request that they be put into WIP per an ECO number and I put them in WIP for them, noting the ECO number in the transition comments. That leaves a path in case the files get forgotten, as they occasionally do.
Good discussion. It's interesting to get different perspectives sometimes.
-
Re: EPDM Rollback Task
Jim,
Well, for us it is not big problem because we don't cancel a lot of EC, and we only have 4 main SolidWorks users. But it is a good point... One part of dealing with it is having procedures in place for cancelling an EC. We do add EC number to all the data cards moved out of Released - makes finding them easy.
If one of us did find a file left in a WIP state it would be our responsibility to figure out if it is part of a live EC, and handle it appropriately. What happened is in history, and if there is no evidence to keep the unreleased version then it should be removed - and work proceed from the released version.
Part of our casual approach relates to the fact that a little over a year ago we had no PDM system, so what we are doing now is much better controlled. I did not want to restrict our users too much from things that were working fine. There is a balance between security and wasted time, and there is a point in most PDM systems where human vigilance is required - it is up to each group to decide how relaxed to be, and where to be most vigilant. Often the systems are more restrictive than they need to be (reference Kent Keller's SolidWorks World 2014 talk, called Avoiding Complexity).
Another issue, brought up by the original poster (I hope Jacob Picolet is getting something out of this big picture discussion that resulted), is EPDM should have better tools for dealing with reverting to the released Revision!
I'll quote myself above because I'm not sure link would work """""""[feb 20 10:33a] For a proper Undo, or Cancel EC action... What is needed is a transition action that will find the last Released, Revision stamped Version - take that and promote it to be the most current version, and check it in as you move back to the Released State. There is a record of what happened, the work is not lost, the versions with changes you considered are still there, but the released revision is restored."""""""""
I think this could be set up if Dispatch had a Get Newest Revision. But it only has some Get Version tools.
-
-
-
-
