Vinod - Thursday, June 16, 2011 6:48 PM:
Folks,
We have a situation in a work flow where we need to step back a few activities so that it mimics a rework loop. This is required for a reason - we would like to make it similar to a reset of few activity votes/reviews rather than a loop-back .
Since the number of activity steps that we may go back can be a variable, there would be multiple combinations depending on the size of the process.
Any idea if there is a workaround for implementing this or is this workflow pattern supported ?
Thanks
Vinod
Brian - Friday, June 17, 2011 9:00 AM:
Hi Vinod,
Assuming you don't want to just vote to go to an earlier step (which would be easy) then what you are asking is probably a bit tricky to do.
I would have a "Rework" path leading to a dummy activity and run a server method of the onActivate of the activity to remove the unwanted steps.
Maybe by using Variables on the Vote where you select the Rework path you could nominate the Activity you want to go back to. Then delete the activities and votes etc between you and it. It would not be that easy to do unless the path between the activity you are returning to and the current one is fairly simple.
It seems like it would make more sense to just keep the history of the loop-back procedure. Then at least you can see what has happened and how many times you have had to go through the loops. This could be valuable information to try to refine the process in the long term.
Hope this helps.
Brian.
Vinod - Friday, July 1, 2011 5:33 PM:
Thanks for your reply Brian,
Often in process work flows there are re-work loop backs and also situations , where we want to move to a previous step under exceptional circumstances.
If the process flow is designed in a way that minimizes the combinations of such steps , it can very well be implemented with the current workflow capability.
Recording the loop back iterations would be useful for rework metrics and activity tracking.
But I am referring to a specific work flow pattern that is needed to support this requirement. Something like
e.g. A process has let's say 10 steps(activities) in sequence and I have just completed the 5th activity. I suddenly realize that I missed something in Activity 3 on which Activity 5 is dependent and want to step back to that and redo it. (The next step after activity 3 now can be activity 4 or Activity 5 depending on the process requirement of whether we need to redo all steps or jump back to the last completed step before the loop back)
I am looking at custom implementation ideas for this requirement by extending the current activity item type.
Brian - Friday, July 1, 2011 6:40 PM:
Hi Vinod,
To do what you are suggesting would be very difficult. You would have to allow for this "rewind" at each activity in the workflow and decide if you need to delete steps between then and now and then repeat them or to jump back, fix and then jump forward again.
The scenario you described where you realised that you missed some crucial information at an earlier step is really the key to what I think you need to do. Each step in the workflow should be checked to make sure that the information required for the next step is available before you accept the vote to that next step.
One of the key things with a workflow is that it is predictable and applies consistent logic each time you go through it. To help this you may need to implement consistency checks on the data as part of the "pre" methods for a workflow path.
If I had to actually do what you were proposing it would probably take me a day of effort (8 hours) just to figure out a way to do it that made sense and covered all the bases. I'm not sure how long it woud take to implement it and also not sure what might break in the standard workflow process. To implement standard consistency checks would be much simpler and are now built into release 9.3 for lifecycle promotions.
Hope this helps,
Brian.
Vinod - Thursday, July 14, 2011 4:21 PM:
Hi Brian,
I had just another thought on this topic. If we were to add an additional attribute to the activity which can be called as "Version" or " Revision" we can probably have several instances of the activity whenever we want to rollback. Activity would then behave like a real-object with a life cycle. This can be useful to get the full chronology of the workflow
In common ECN scenarios where we have activities like marking up drawings and Drafting, the process would happen with many iterations of marking up and drafting. If we were to update the status of the work flow as soon as we finished drafting , the next activity would be activated which is review.
Then there is a loop back possibility. But in some cases certain complexities become apparent only after a couple of iterations and the workflow would need to be rolled back to an activity further upstream. Long running processes that we are modeling have this behavior.
I am not sure if ARAS has the "State Machine" workflow modeling and execution capability where the control of the workflow lies totally with the executor and it is not restricted to a pre-defined sequence.
Brian - Saturday, July 16, 2011 9:58 AM:
Hi Vinod,
A state machine has states and transitions between states. You can only move from one state to another along a transition that is defined for the state machine. This is exactly the model that is described by either a workflow OR a lifecycle in Aras. You define the states/activities and the transitions/paths and then the user either Promotes (lifecycle) or Votes (workflow) to take you from one state/activity to another.
If you have a state machine that allows you to move from any state to any other state then you just have a lot of transitions defined. You can do this with a lifecycle.
The scenario you describe with a long running process that might require many iterations of drafting and review etc. is normal business. Aras Innovator comes with the Change Management processes defined in workflows allowing you to manage when an item can be changed. There is nothing to stop you also having a "Review Process" that operates when the Items are in an editable state (say Draft or Preliminary) to allow you to conduct other reviews as part of the change process. Depending on which of the change management processes you are using the review loop may already be built in.
If you think of the development process as a series of discrete iterative steps through the same simple workflow/lifecycle combination rather than a continuous process through one all encompassing workflow/lifecycle then I think you will see that Innovator is already set up to do it this way.
Consider:
I create a Part and two supporting Documents for that part. They are in Preliminary (Part) and Draft (Document) and stay that way until I decide that they are ready for "something" (say Prototype build). At this point I put them through a release process and we have a locked description of how the Part was defined at that point in time. Rev A is Released and we can't change anything about it.
The Part is built and comes back from the supplier. We realise that there are some things that need to change. We introduce an ECR and propose the change. No implementation work is done at this stage. Only investigations so that we can propose a suitable solution. It's a simple change so we don't need to involve many people at this point. There are no production impacts since the part is still only in the very early stages of use. The ECR is reviewed and approved. Now the ECN is raised and the actual change is made to the Part and its Documents. The ECN is finalised and Rev B is Released.
We now have all of the history and chronology of the initial design (Rev A, Generation 1 and maybe 2 and 3 depending on how many times the Part/Documents were locked, edited/saved unlocked), all of the Workflow Audit information (workflow signoffs) telling us who and when the Rev A Approval process was conducted by. The workflow Audit information for the ECR advising who proposed a solution, who approved it and when. All the ECN workflow audit information, who proposed the change actually be implemented and when and when the change was actually committed and approved as done. While in this Activity loop of the ECN (Update Documents and Review Documents) you will capture all of the changes taking place to the new Rev B records that are in the database. The Generation will increment to 4 and maybe 5 or 6 for each lock,save,unlock process.
So the Process you describe as wanting the state machine for looks to me to be exactly the process that already exists. You decide when to initiate new States via a change process workflow. You decide what path to take through the workflow (voting). The system records all the changes. If that isn't enough history on what has changed then you can add the actual field level edit history capabilities to find out exactly when particular fields were changed and by whom.
You say "in common ECN situation the marking up and drawing can happen many times". Yes. And you put it through a new ECN each time or you hold it in the "Update documents and Review Documents" loop for as long as it takes to reach the outcome you want. Each time you vote at the Review Documents stage to send it back to Update Documents you have the history that you are looking for.
Regards,
Brian.
