Hi Eileen,
This is not a precise answer to your question - but is because we took a different approach to whole capacity/scheduling issue that you or others might find usefull.
To compat the limitations of the schedulerbased nature of BluePrism we've created a 'masterprocess' that activative all other processes (when neeeded) based on a set of paramaters (these can be unique per process) - most of our processes simply look for any pending cases, a 'kicker-email' or if the process have to run within a specificed period.
What we found out was that we didn't have any overall capacity issues - however we did have daily bottlenecks were we simply could not execute all of our processes as often (or fast) as we would like to. By creating the 'Masterprocess' this allowed us to group all of our processes into three major groups; Prioritized, not prioritized and down-prioritized. (We still run processes that are ot prioritized or down-prioritized - however only when there aren't any 'more important' processes should run)
Furthermore we have set limitations on any non-prioritized and down-prioritized processes in regards to how many cases they are allowed to process and maximum run-time (the first limit reached closes the process - if the process isn't completed before then..). With only two resources and just below 60 processes we are able to run all processes within a few minutes after the would run if we had no other processes sharing the same resource. More often than not - we are actually able to run the process within the minute of a kicker-email or the scheduled run time.
I think the biggest learning in our approach was a moved focus from capacity to bottle necks. Because we have 24 hours in the day, but only 8 hours in the average workday and almost every internal 'customer' wants their cases solved within that time frame (and most often "RIGHT NOW"). This is why we will not add resources based on an overall capacity evaluation - but rather when we aren't able to solve cases (run processes) within a given time frame. This might not be the best case for you, but it have been for us.
This is exemplified in that an overall capacity analysis that Jacob Clary talks about didn't reveal any capacity issues (hurray for 24 hours in the day) - but we had processes that could wait for periods upwards to two hours in a normal day.
And to answer to you precise question: almost all of our time critical is initiated by a kicker-email. If the imbox it cleared every few minutes we have additional capacity; if not we would have a look on our process prioritisation. There is plenty of hours in the day - if we are able to solve all the cases (or at least mark them as exceptions) in a given day we have enough capacity. Additionally we have a log that notes every time we activate a process, it shows plenty of idle time throughout the day.
------------------------------
Christian Rothmann
RPA Developer
Royal Greenland
Europe/Copenhagen
------------------------------
