Hello everyone.
This is a chance to understand how many bots developers use per project, irrespective of the kind of project. All comments welcome.
(Please vote only for projects that have been successfully deployed and where the bots are live in production)
what do you mean by âbotsâ? I think the term âbotâ is sometimes thrown around loosely. In terms of RPA, it typically means the automated user that runs a process/project, and is pretty much a user but just automated. Essentially, it is the user profile used to create a login session on a machine to execute a process.
By that definition, I truly believe that if you are using more than 1 robot to execute the same process/project, then you are doing it wrong and creating a messy robot environment. But, thatâs just my opinion. A project should be placed in one framework to handle all error handling and process performance, therefore only needing one robot to run successfully and completely.
However, if by âbotsâ you are meaning âworkflowsâ, then yes this can fluctuate depending on the complexity of the process. And, ideally, the majority of the workflows called within the project (ie navigating and using Web portals or applications) should be placed in a pool of re-usable workflows or libraries, therefore providing to future projects for much faster and simpler development and testing phases.
My last project used like 22-24 workflows, most of which were designed for re-usability. But, like I mentioned, my projects will usually use one robot. Except in the case of my last project, we broke it up into 2 sub-processes that can run freely simultaneously, so it used 2 robots.
Hi @ClaytonM,
Thanks for the detailed insight. By bot, I meant an individual UiRobot.exe.
I agree that all my projects so far too have also not exceeded two robots. However, what happens when the volume of the transactions increases manifold? Similar to increasing the number of employees who perform the task, here in automation, we will need to deploy multiple robots executing the same process, right?
Good point. I suppose using the Queues would be a good option if you have that available. However, letâs say you have 2 robots and 2 different processes⌠whatâs the difference between running both processes on each robot, or splitting the volume of both between the two? Technically, itâs the same thing. Although, the benefit of Queues is that if one robot is performing better than the other, it will run more items from the total volume and be more efficient overall.
So, then I guess it would depend on how much volume and how many robots you have available to use. - it would make sense to utilize as many robots as possible in this case. But, at the same time, you do not want to use every robot for a process; otherwise, other processes need to wait until it is finished (for example, using like 8 of 10 instead of 10 of 10).
But, I understand where you are getting at now. I think most of our volume comes in smaller amounts per day. Occasionally, we will have a large amount, though, which does take more hours to complete and we do so in parts if needed. Once Queues are utilized more often, I think this will become easier, though.
And yes, I am talking about processes that involve orchestrator queues only.
For example let us assume, we have two bots. First bot(Dispatcher) reads a WorkItem ID from all the incoming emails and uploads it to an Orchestrator queue. The second bot(Performer) fetches the ID from the queue and marks it as âCompleted taskâ in a web based tool. And we get a million such emails a day.
In this case, in order to complete all the tasks quickly, there is no other option than to simply multiply the number of Dispatcher and Performer robots, right?
Hi @ClaytonM
You said that, you developed 22-24 work flows in your last project. May I know the duration of that project? How many transactions did it process per hour or per day? And how many times did you have to run the bot per day?
Thank you
@divakar.reddy That particular process which was deployed almost a year ago, runs in two sub-processes that do not rely on the other and can run at any time at the same time.
First sub-process will do 650 items in about 1-2 hours which happens once every 1 or 2 weeks - most days, it does about 50 items taking 10-20mins. However, it attempts to do the same items again for a week to pick up anything that failed, so the sub-process generally runs 1 hour every day.
Second sub-process will do about 50 items per day and takes about 30 minutes. Many days it will do the same items again until it can find the documents that are needed for the item to complete. The time to complete depends on how many documents are available to complete the item.
Both will fix itself and attempt the items that failed previously and isnât a huge priority that it runs every morning, so they only run once a day. We have other processes where we schedule to run twice a day, just to keep the data reliable, updated and processed for the user, in case the first run failed for whatever reason (like server issues)⌠but this particular one just wasnât that necessary.
Thank you so much @ClaytonM. This gives me a clear cut idea on transaction hours and bot scheduling. Very few people, explain like this. It would definitely cost you considerable amount of time. Thank you so much once again