Challenges and Results
Challenges
- A success rate of just 64.4%: more than one in three runs failed, and rerunning the bot until it succeeded had become routine
- This single bot accounted for 43% of total run time, so its instability affected operations as a whole
- It also made up 48% of all runs, and every failure forced staff to rerun it
Results
- Refactoring raised the run success rate from 64.4% to 80%
- Earned the client's confidence in stable operation, leading to a decision to introduce new RPA for another task in the same department
Before
A process that only succeeded after several attempts
This core RPA bot had been designed and built by another vendor. Because many tasks had been packed into a single bot, it placed a heavy load on the execution environment, and failures caused by the environment were frequent. The bot rarely succeeded on the first run and had to be rerun several times before the work was finally done. On site, this unstable state had come to be accepted as normal operation.
What could not be overlooked was that this bot accounted for about 43% of total run time and about 48% of all runs. Because it carried so much weight in overall operations, its instability had a correspondingly large impact.
Figure: Unstable runs and their impact on overall operations
Redesign
Refactoring with a focus on stability and efficiency
ITSO began by preparing semiannual usage reports to measure where load and failures were occurring and how often. This visibility made the root cause clear: frequent failures caused by the execution environment.
Based on these findings, ITSO refactored the existing bot into two separate functions. The first bot automatically refers to information in the system and generates XML files for system updates. The second automatically uploads specified PDF files to the system and, at the same time, sets older existing PDFs to private.
The redesign of both bots focused on two priorities: stability and efficiency. Because the heavy execution environment was causing frequent failures, ITSO strengthened error handling and made active use of the latest UiPath features, rebuilding the bots to withstand temporary instability in the environment.
Particular attention went to making reruns safe when processing fails partway through. Even if some reruns remain unavoidable, the bots are designed so that they can be safely run again as many times as needed, without unintended effects on the system or data.
Figure: The two redesigned bots and the two priorities behind them
After
Success rate up from 64.4% to about 80%, a 16-point improvement
As a result of the refactoring, the run success rate rose from 64.4% to 78.1%, an improvement of 13.7 points. The numbers reflect how strengthened error handling and greater stability addressed the root cause: frequent failures caused by the execution environment.
Beyond the numbers, the project also earned the client’s trust in stable operation itself. Satisfied with the results, the client decided to introduce new RPA for another task as well, opening the way to the next phase of work.
Figure: Run success rate before and after refactoring
If your organization is struggling with an unstable RPA bot built by another vendor, or your staff are constantly rerunning it after every failure, we hope this case offers useful insights.