Digital Exchange

 View Only
last person joined: yesterday 

This community is a place to discuss Blue Prism DX assets and development.

  • 1.  Digital Worker/Bot Utilization

    Posted 9 days ago
    How are customers measuring utilization of their digital workers/bots?  Looking to determine how much capacity a resource has available to support additional work or if a resource is under-utilized.
    Thank you.

    ------------------------------
    Eileen Markey
    Production Mgmt
    Metlife
    America/New_York
    ------------------------------


  • 2.  RE: Digital Worker/Bot Utilization

    Posted 4 days ago
    Hey Eileen, I hope you are doing well.

    To measure utilization, our customers will generally use the built in data within the Blue Prism client. If you go to the "Analytics" tab and then the "Tile Library", you will have a few options here to add tiles to your dashboard to see resource utilization. Some helpful ones could be "Workforce availability" and "Daily Utilization summary".

    I hope that helps!

    ------------------------------
    Jacob Clary
    Customer Support Engineer
    Blue Prism
    ------------------------------



  • 3.  RE: Digital Worker/Bot Utilization

    Posted 3 days ago

    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
    ------------------------------



  • 4.  RE: Digital Worker/Bot Utilization

    Posted 3 days ago
    This is very helpful! Thank you Christian

    The information contained in this message may be CONFIDENTIAL and is for the intended addressee only.  Any unauthorized use, dissemination of the information, or copying of this message is prohibited.  If you are not the intended addressee, please notify the sender immediately and delete this message.






  • 5.  RE: Digital Worker/Bot Utilization

    Posted 2 days ago
    I think there are a few steps to take:

    1.  What is your definition of fully utilized,  what is the maximum utilization you can expect in your company?  Does your organization have main system down times when robots cannot work,  do you have working hours SLAs where the majority of robot work needs to be performed,   do you have customer peak times where the majority of robot work is done.   There is a lot of business needs and constraints that impact the maximum utilization you could ever expect for your robots,  to not account for that in how you report utilization might make the robots look more poorly utilized then they are.

    2.  What measure for utilization makes sense for your organization.  Hours worked,  % of uptime working, etc??  If you are actually more interested in savings and benefits than robot utilization then you might be more interested in FTE equivalent and how much human equivalent work is being done by the robot rather than how many hours the robot was working.

    3.  How do you get the MI you need out of the Blue Prism robots.   There is the Data Gateways functionality to get the Blue Prism data you need into a safely reportable repository.  I also know many customers poke MI out of the robots from the built Blue Prism solutions themselves to a location picked up by your main reporting or MI toolset.  So a robot might poke a data item when it starts and stops working,  for each case worked,  and for specific case types.  That might be a cleaner solution for you to use than trying to manhandle the BP data blob that was not designed with your specific MI requirements in mind.


Welcome to the Blue Prism Digital Exchange Community!

The Blue Prism Digital Exchange is a "shop window" for new and emerging technologies—a platform that puts powerful RPA and AI capabilities into the hands of business leaders. Users can find and apply pre-built AI capabilities, in the form of downloadable integrations and Visual Business Objects (VBOs), to automated processes. These assets connect and integrate Digital Workers, existing systems and processes to Blue Prism's technology partners, creating a solid foundation of AI-enabled Intelligent Automation that's scalable and sustainable.

Blue Prism Digital ExchangeDX Asset IdeasContact DX Support

FAQs

The Blue Prism Digital Exchange (DX) is an online marketplace where businesses can instantly access, apply and share pre-built AI, cognitive and advanced RPA technologies from best-in-class providers. These assets easily connect to existing digital workers, systems and processes to enhance automation capabilities.
The Digital Exchange is free to all users. Most of the content on the DX is free to download but there are some submissions that do have a cost associated. The submissions with a cost are advertised on the asset card and profile. No unwanted costs will be applied to any users.
You can visit and browse the Digital Exchange here. If you would like to consume or download any material it is necessary to create an account on the Blue Prism Portal first.
Everyone can access the Digital Exchange and consume the assets on it. If you would like to contribute to the marketplace it is necessary that you create an account and sign up as a partner.