I am relatively new to RPA industry as a developer of 2 years, my current company has several bots in place now but little process framework, documentation, etc. There are license keys, VM, user credentials, all sitting in various messy Excel files and we are doing everything very “agile” but probably too much so.
I believe some of our bots are not ideal for RPA even, such as a bot which takes a database extract file, transforms the data, then outputs to a cleaned file. I’m not sure if RPA is best suited in some scenarios like this.
I am looking to revamp our team setup, document everything correctly, and improve the way we do things overall but I’m not quite sure where to start. I’d love to know how other companies would implement RPA correctly? Are there any resources out there or template files to help with managing our team/pipeline of projects etc? I’d love to know what best practice is and totally revamp the way we are currently doing things.
Some of the areas of concern I have is data security, Config files sitting in network folders for bots which contain usernames/passwords, and we often share the generic user account so others can login to the VM and run the bot. (no orchestrator…) I want to move away from doing this as sharing generic accounts is a big risk. We also don’t have a concrete way of planning our pipeline of projects and scheduling things correctly. Sometimes projects will stall, we prioritise another, and before we know it our pipeline is no longer reflective of the current targets.
I realise this is a vague and broad topic. Any help appreciated. I’m blessed and cursed that I’m the only technical member of the team so hopefully I can revamp things so we can establish strong RPA framework and are ready for new staff in future.
It’s good to have the Re-Framework even the process are not dealing with Queues, The licenses keys should sit inside a repository where there has some people access. User Credentials should encrypt with some key and later decrypt to open files
Even this small process, If this is more frequent and it’s saving lot of time, then it is a RPA suited scenario only
If you are identifying the RPA Case it’s better to have a couple of documents like PDD and then after the development SDD is to maintain
Being the only technical member of the team will be crucial one to handle all the stuffs
But on the other way you will get an opportunity to know about everything and on how to manage it
Taking that positive note let’s pitch in one step at a time
First always have a repository to manage all the documents, installers, Process backup
It’s highly important to have a repository
It can be a azure devops or a shared drive or windows server
So find a possible way to get any of these and get the files and docs stored in a structured manner
I would suggest to have a azure devops or a windows server to host your rpa environment
That’s absolutely right
Never use a user specific account and always have a bot specific account
Say for example you have three bots each one assigned with one process then try to have three bot accounts in windows server
So that if any wants they need to login with bot account only and not through their user credential
And in maintaining config files, assets, credentials it is always good to follow a standard way of approach
Like have SNOW system for your team so that if any changes or updates has to be done with config file or asset or credential we need to have a track of it in a system which will help you when you have audit of your team
service now is suggested because we won’t be track what change is happening o tissue orchestrator as AUDIT option in orchestrator is only for its entities and not for the process or process related file changes
Always stick to best practice of using input files
And finally on revamping
First find the process which has less decision making, less involvement of multiple applications and the application involved in the process has its own automation feature and does need of RPA much
It’s not only for the already existing process but also consider when you are getting to a new process
Check the above criteria’s and then decide whether to implement rpa on top of it or not
So once after finding them for the existing one, prioritise them and keep in order
Find the one which has high FTE in return and keep them running and remove the one which has very less return
Discuss with the business team who came up with that process and ask them to find the right team to automate those process with the parent application itself
Then we will now have filtered and most needed automations
Check whether it has all the required process related documents like PDD, SDD
If not prepare them and have it saved in a repository
When you are taking up the next process make sure you are following this design model
We all have been there. Standardizing a messed up system is really a crucial topic.
Firstly you need to setup a protocol to assess the legacy bot and analyze their efficiency, as you mentioned you might need to discard few bots.
The analysis depends on the business, what affect the bot has, time saved and the ROI for each robot.
I assume legacy bots were developed and deployed earlier, but Licenses cost are revamped too and hence ROI calculation is a must to do now.
Once you have the process coming in the positive ROI side, then you should standardize the process → this include building it in a better framework and also consulting business to have any more changes/improvement in that. You may suggest few improvements too.
I’d say your main issue raised here is that you aren’t using Orchestrator.
For an enterprise solution I’d personally say that its required. You need it for logging and management.
It, for example, will completely solve your issues saving credentials by using assets. I’m guessing you aren’t using Libraries, at least not very effectively if you cannot publish them to the Orchestrator either. If you are deploying them locally great, but its not ideal.
You mention you work ‘Agile’, but its sounds like you aren’t so much. If your project is blocked then the items can go in the backlog, you leave them there and pick them up when they are unblocked, its a Product Owners responsibility to get them unblocked and if they aren’t prioritizing it then the project was never that important and can be dropped. Its not your problem to worry about as a developer. Report where you are blocked and move on to the next items to work on.
The things I’d look at in terms of scaling up, outside of adding Orchestrator, is:
Documentation - Get this clear for anyone using or developing with the bot
Error logging - This is crucial and IMO, the ‘best practice’ from UiPath is of a poor level. They recommend logging the exception message and source. Its nonsense, log the entire error. Serialize it and log everything, all the parts of the exception are useful, don’t make it harder on yourself by only logging a small part.
Version control, you don’t mention version control but if you have none then, oooof. Get some asap.
Start with the UiPath framework, its a good starting point to get you in the habit of dividing up parts of the process, and thinking about what kind of process it is.
Make sure bots are split up. If your bots are big and complex, working with multiple applications etc, split them up. Bots are best when they are small and re-useable. It makes them easier to maintain and understand. If you have a complex process with multiple moving parts then chain those bots together instead of putting everything in one big monster bot.
If I think of more I’ll post but there is a start.
All the responses by Forum members are good insights and I also pick up some pointers from them. You may want to consider read up on the two articles from
Which I hope will give you additional insights. Sometimes the issues may not be just want you can physically see but maybe abstract. I hope you can also uncover the why besides the what and how.
Anil_G
ashokkarale
jinal.shah
Gautham_Pattabiraman
postwick
chandreshsinh.jadeja
vrdabberu
Ajay_Mishra
sven.wullum1
Vyshnavi_Nalumachu