For planning, we always need to take into consideration how long it takes a bot to run. My idea will be to create multiple processes, but very simple ones. I mean, multiple automations, but simple ones. Not to create one very complex and time demanding automation, but to create multiple, simple ones. And this will help you to better place the schedule during the week, for example. And the other thing is that the processes that don’t need the results to be visible as soon as possible could be run during outside whttps://open.spotify.com/episode/6FcpwXIOswpCRSdxb26OLM?si=kAwInuWkSTawqkX7B8NJrworking hours. In the middle of the night for example. But of course, it’s different from the business expectations. In Accounts Receivable, we have some processes that we need to close them or react much, much faster than with other processes in different businesses.
So, the answer is with planning. We should plan exactly what we want. I think that we should first do a draft. And then go back and re-test. Because what I saw and what I could experiment, and I was joining the team when the RPA already started so I did not take part in the first phase, but the main prerequisites of some bots were just not valid after four, five, six, seven months. So, yes, scheduling, planning, but then go back before launching the bots and re-validate all the steps.
With a smart scheduling you can utilize more of the robot used. Less IDs, less licenses, and that’s how the scheduling can help.
First of all, to understand the logic behind each process. I guess most of our issues are coming from misunderstandings, unclear SDDs. That’s why you have wrong results. If the SDD is written quite clear and understandable, it will be easier and better for business and for IT as well. Difficult to understand code, unclear SDD, these kinds of things, should be taken care of from the beginning. To make sure that quality is assured for these kinds of documents. For SDD and for code. If it’s done well from the beginning, I believe you can save a number of issues after production.
It really depends how it’s scheduled. I mean, this is something which is mostly done by a human, so if the scheduling is done in a way that it’s not efficient, then the production won’t be efficient. It really depends on the skills of the scheduler, how it’s scheduled. And I think this is something which cannot be done via RPA or such things, these are almost soft skills like the ones we use at customer service. I don’t know how you do it in IT, but I think this is comparable to the soft skills we have at customer service. And I think this is more on the human part, again, soft skills.
I always suggest for the business to ask themselves when are they supposed to have this or that job and they can always suggest when they are doing that so that’s how you improve with scheduling. Oh yes, and you don’t have to start it manually.
There are many ways to improve efficiency by better planning. There are many examples. So, if you talk about efficiency, less cost and more outcome, if I am right about that, you can plan to utilize the resource more effectively, for example you need to plan to minimize idle time of the resource. So, when you plan to use someone’s time for the implementation, you will not want them to sit there idle or doing nothing, right? So, you need to plan carefully between the multiple resources you have in the project or the team. So that you have a good work assignment, process, so that when someone is free or have free time, they can use their idle time to something else or some more process in the queue without keeping them waiting. That can be a better task planning or assignment process, it can be Agile process, you can utilize Scrum or Kanban board to help on that so that you have visibility on people’s workload. Yeah, that’s one example.
Again, this is something related to process. If everything is mapped at the initial phase correctly and if there is a clear picture on what amount of workload it will take from a developer to start the development of this script, and what could go wrong, and at which stage of the development for testing, then it should be quite ok, and I believe these kinds of initial mappings or planning, if done in an efficient way, with close involvement of the actual people processing the manual workaround, the operational teams having to perform this and that activity, because there can be, let’s say, one key business contact that needs to communicate to the developer about twenty processes, but if it’s not the contact that runs the manual transaction or the manual workaround, there can be something in the picture that comes right after implementing the robot, and when it gets to the actual people using on a day-to-day basis that specific robot, so that’s planning in terms of IT side, but planning in case also of the business. Maybe the responsibilities here have to be very clear in terms of what is mapped by the developer side, what is mapped by the business side, so this is to be aligned to what it should be, what is actually is. I think it should be covered by both developers and business.
Intelligent Automation Product Owner 