Future (to-be) processes using Promapp Process Variations

  • 30 April 2021
  • 2 replies
  • 40 views
J

Can I use process variations to manage current (as-is) and future (to-be) processes?

 

I was in a Nintex webinar the other day and I saw the demonstrator using a process with variations for current (as-is) and future (to-be). This wasn't the focus of the webinar however it got me thinking about how to efficiently manage as-is/to-be processes going forward.

 

I'm thinking of setting up the following to manage this - I'd love to hear people's thoughts/experiences on this:

  • Create process for the first time in Promapp (standard, current, and future variations)
  • Publish current variation when process is finalised, leaving the future process as draft
  • Everyone uses the published current variation
  • The process owners/experts work on developing the future variation until they're ready to implement it
  • This is where I still need to work out - Then either:
    1. Archive the current variation and then publish the future process (renamed current), or
    2. Update the current variation (copy text across from the future variation) and revert future variation to standard to start improvement piece again, or archive it and create new variation when improvement work is done again.

 

Is this feasible?  One thing I'm unsure of is why the demonstrator had three process variations: standard, current, and future. Why not have just the standard as the current process, with one variation being the future (as-is) process? I can imagine this has something to do with reverting to the standard or tracking changes or publications/viewing permissions maybe...

 

I'd love to hear your thoughts - how have you managed current/future processes in Promapp?

2 replies

Wesso
Userlevel 1

We haven't used the variations much as it seems like there's a lot of coordination required before we roll it out so we (our internal Promapp team) need to fully explore variations feature first.


 


But that said, I can comment that we currently have a separate Group/Folder in Promapp for any draft future 'to-be' processes. We have it this way because for us, the people working on the future state often involves people in projects and they may not necessarily need edit rights to the current processes so by having to-be processes in a separate Group have finer control over permissions. 


 


And on top of this, since these draft to-be's are mainly still in discussion, there will be a lot of changes to them (which may not end up being in the next as-is process), we do not want these changes to fill up the current as-is processes change log. 


 


Bear in mind, we only do this for big changes (e.g. changes to a whole department's way of working etc). If Process Owners/Experts want to explore and test things out on one of their processes, they can go ahead and make those draft changes on their process.


 


I hope that makes sense.


And if you do end up using variations, do share how you're going. I'm very keen to see how it can be used as well 🙂


 


Tags: @josieandrews 

Srinee
Userlevel 1
Badge +3
Hi - you are not alone.
We will be deviating as well as there is business value in our firm to use PVM in this way...current vs. future.
I am trialing this as we speak and differentiating designy type PVMs using the Process Title. Was even considering creating a custom Tag to indicate if PVM version is design/to-be process from the Standard.

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings