Top RPA Business Analyst Interview Questions and Insights | UiPath Interview Questions Series

Hello everyone, and welcome back to my YouTube channel. My name is N Kadam, and today I'm actually creating a video. Uh, this series, I actually lost touch a long time ago. But yesterday, what happened is, one of my friends called me, and he was like, he was asking me questions about what would be the anticipated questions for a business analyst role. Now, we never actually thought about it, but yeah, I'm continuing a series of interview questions for RPA roles. Right? Those series, uh, or those videos which I actually uploaded as part of the series of interview questions, were actually quite good, and people responded that, you know, we want, uh, that series to be continued.

Now, today I'm picking up a role of, let's say, Automation Business Analyst, and you have at least four to five years of experience. Now, based on that level, what kind of questions should you expect from an interview? Okay, let's get started with that. Now, you know, usually UiPath's Business Analyst has a huge amount of responsibility. It's not only UiPath; it's any product, any RPA technology you talk about, right? Business Analyst has a huge responsibility when it comes to end-to-end project automation. Now, we usually underestimate this role, but this role has huge importance, and if you have a Business Analyst, your project success is obviously always high. That's why we require a Business Analyst in every single case.

Now, what kind of questions that people can actually ask you in interviews? Now, let's consider a business with an experience of at least four to five years of experience. Okay, let's get started. First sort of questions which I would ask is, do you have understanding or knowledge on the products of UiPath or on the platform of UiPath? Now, when you, when somebody asks you, what is UiPath's platform or a business automation platform, all you have to do is just go to the, you know, UiPath official website.com, right? And on this product, you know, you have a whole platform here, right? Which is Discover, Automate, and Operate. Now, if you can actually talk about Discover products, because Business Analyst usually works a lot with the Discover products side, which is Process Mining, Task Mining, Communications Mining, Idea Capture Management, which is basically your Automation Hub, right? And then, uh, on the Automate side, there are few questions, not so many questions, but again, on the Operate side, you might have a couple of questions such as, you know, around the real-time and trends analytics, which is nothing but the Insights, then Test Suite, then Orchestrator, Governance, and all of that.

Now, let's see one by one each question that what kind of questions might come up for a Business Analyst. Okay, so what are the products which comes under Discover phase? So the products that you know, right? Process Mining, Task Mining, Communications Mining, and Automation Hub. Now, if anyone asks you to explain these products on a high level, what would you say? Okay, so Process Mining, when it comes to Process Mining, basically, it's one of the products which extracts meaningful insights, right? And, uh, you can say a process flow from the logs data or the data which is a backend data of any ERP application. Now, all of the logs that are generated of these ERP applications, you provide as an input to the Process Mining, and Process Mining helps you to generate a huge amount of insights from this data. While the Task Mining is exactly the opposite thing; it works on the user interface. Now, Task Mining actually captures the UI interface and the function that your team is doing throughout the week, or let's say throughout the month. You record each and every action that they are doing on their computer, and then the model, there's a machine learning model behind the scenes which actually works and it generates that what kind of tasks can be automated and what are the insights at how much time they are spending to do certain processes, which process is repeated, and you know, what is the repetition also. It generates, like, a flow of workflows as well.

Now, Task Mining also has a version called Assisted Task Mining, which is nothing but your UiPath's basically the Task Capture, which was earlier called as Task Capture, but now it's basically Assisted Task Mining, right? And then Communications Mining. Now, Communications Mining is one of the NLP products of UiPath, which again extracts insights and information from your text-based information. Now, if you provide a huge amount of text communication, such as, let's say, a huge email dump or a huge service note text to Communications Mining, it can extract insightful information such as sentiments, such as, you know, entities from the data, key entities, right? And it can help you to categorize or classify that data. And lastly, Automation Hub. It's nothing but, as you know, it says that Automation Hub basically helps you to capture ideas, manage those ideas, and literally drive a huge end-to-end flow of idea management resources, right? Now, these are the four products of UiPath's Discover phase. Now, nobody will ask you to explain these products in depth, but they might ask you on a high level that what kind of products are these, right? You should be able to talk about them.

Next questions which you can actually expect in a Business Analyst interview is, uh, you know, what kind of, let's say, tools are there in the automation phase? Now, they might just ask you the question to check your knowledge about, do you have an idea on what kind of tools or what kind of applications, right? UiPath has in the automation phase. In the Automate phase, we have Document Understanding, UiPath Robots, Studio, Action Center, AI Center, right? Now, what are the different types of robots? So, on a high-level scale, there are two types of robots: Attended and Unattended. And then beyond, there are multiple types of robots based on the user consumption, right? So, Attended and Unattended, you should be able to explain the core difference of that. So, Attended robot is nothing but you can call it as an ad hoc execution robot. Now, when you actually want it, you run the execution, right? Or when you run the robots, that's called Attended execution. And the robots which helps you to run the processes when you want it on your machine, those robots are Attended robots, which sits on the user's laptop. While Unattended robots functions based on the triggers or schedules, right? Now, those triggers can be anything. It could be a time-based trigger, like given the fact that I want to run the robot at 5:00 PM, 6:00 PM every day, you know, in the evening. That's a time-based trigger. Another schedule is queue-based trigger. Now, queue-based trigger, it's like, if my orchestrator queue has enough amount of data, start the queue, start the robot, right? The next one is basically event-based triggers, like for example, if I have minimum 10 files in my SharePoint folder, start the automation. If I receive an email from some specific subject or from a specific sender, start the automation. If I have, let's say, enough amount of emails in my inbox, start automation. Let's say, now there's an API-based trigger. So, I create an API for my robot execution and I integrate it in the backend of my website, and let's say on click of a button or click of some request, the robot starts automatically in the backend. All of this, they work on an Unattended robot, and these Unattended robots work on VDI, right? Or it works on servers also. They connect to the server based on service-based type, right? Service connection type. Now, based on the service connection, they can actually function completely unattended without any human interaction. That is called Unattended execution, right? So, these are the two different types of robots on the highest scale level.

The next questions that might be asked to you is, what are the different types of implementation methodologies, right? Or can you talk about the stages of implementation methodology of any project? So, considering from UiPath's perspective, I've, okay, so if you are getting started with any new project, the implementation methodology stages would be: first, you have a kickoff; then, you have business case and technical validation; then, you have process analysis. After process analysis, you jump on to solution design. Once your solution design is done, then you actually start development and testing, and then post-development testing, you start UAT, user interface, user acceptance testing, right? And then you have hypercare, and finally, you have project closure. Now, each of these stages of implementation methodology, they have key roles, key tasks to be performed during each and every stage. That could be a question which can define your overall experience, that how well you are in business analysis, okay?

Now, to check the knowledge, what could be a question from an interview, right? So, an interviewer can ask a question that, you know, talk about implementation methodology, different stages, and what actually happens in those stages. Now, let's go through one by one, okay? The first stage is kickoff. In kickoff, usually the task performed is talking about environment infrastructure examination, right? Review of SOW, which is Statement of Work document, okay? Full form of SOW is Statement of Work, remember this one. Initiate a project readiness checklist and application access tracker, and make sure that you have an issue tracker also in the beginning. Now, that's the kickoff where infrastructure engineer, solution architect, and project manager are involved in this phase. There is no Business Analyst in the kickoff phase.

Now comes the part of business case and technical validation. In this phase, basically, Business Analyst comes into picture. In this phase, we perform the pre-analysis to validate the context and scope of the project, opportunity assessment of probable automations where Automation Hub comes into picture, development and validation of the business case documents. Now, that is very important. Now, once this stage is completed, the real stage comes into picture, which is the process analysis. Process analysis, here also, we require a Business Analyst, and solution architect, and project manager. Now, why this phase is very important? In this phase, the tasks which are performed are analyzing the "as-is" and "to-be" state, and how do you actually choose the process path, define your "to-be" state on a high level, I'm not talking about the deep level, okay? Just the high level, and develop the Process Design Document. Many majority of the companies which are the partner companies of UiPath on any RPA product, right? They have their first payment milestone on PDD level, which is the Process Design Document level, or Process Definition Document level. So, when you have a PDD completed, it's one of the biggest milestones of any RPA project, or sometimes we have the payment milestone on the solution design level, right? It's up to the team to team, company to company, how they charge it or how they plan their milestones. But yes, this phase is very important, which is called as process analysis. Here we also develop a UAT plan. Now, why would you say, why would we build a UAT plan in process analysis phase? But it's very important because before you begin, you have to define the scope, define the "as-is" state, and you have to tell the user that, okay, this is the plan of UAT, and this is what we will be actually checking during user acceptance testing. So, moving forward, when I jump into the Solution Design Document or designing the solution and going deep dive into the "to-be" state, I don't want that my client comes back to me and tells me that, okay, I want to add on this thing also, I want to change this thing also. It should not happen. So, that's where I develop UAT in the process analysis phase, okay?

Now, now comes the phase of solution design. In a solution design phase, again, Business Analyst is involved, right? Solution architect, definitely. There are automation developers also involved, and project managers involved. This stage is very important because in this stage, the main tasks performed are designing and developing the Solution Design Document. The SDD, we validate and populate the application access tracker and check if we have access to each and every application before we jump into the development. The next phase, right? Also, we prepare a technical testing plan properly in the solution design document level. Now, this is very important because at a solution design level, few companies have their payment milestone before they begin the development part. That's why this is one of the again, most important phase, right? Or most important milestone in a project. Why would a Business Analyst be involved in a Solution Design Document? Because Solution Design Document is purely designed based on the PDD, which is Process Definition Document. Now, if you say, why it is designed based on Process Definition Document? Because obviously, the Business Analyst has to capture keystroke level process on, uh, while, while it's actually the, while the PDD is actually being built, right? So, having a Business Analyst during the phase of designing the Solution Design Document is very crucial, very important.

Once you finalize the solution design document, during the development and testing phase, obviously, we don't require a Business Analyst. So, that's why nobody will ask you questions about that. However, just to know, in development and testing phase, solution architect, automation developers, project manager, those are in picture. Usually, we develop automation solutions using PDD and SDD both, right? Execute technical testing plans, we perform unit testing, we perform QA, right? We perform all the checks, data balancing, data testing, right? Load balancing, all of that. Once that is done, once we are in UAT, now again, Business Analyst comes into picture here. In UAT, user acceptance testing phase, in this phase, solution architect, BA, and project manager, all three of them come together, and they have to actually execute the UAT plan which they created earlier. Now, remember where did we create UAT plan? We created during process analysis phase, remember? Now, now we execute that UAT plan. Once we execute the UAT plan, we log all the deviations from expected outcomes, and we generate an issue and we fill up the issue tracker that we have.

Now, during development and testing plan, if you don't want that your user comes back to you and requests you to add on to the process, your PDD and SDD have to be very strong and have to be very perfect that whatever change comes later in the development phase or UAT phase, you have to make sure that either you raise a CR, which is a change request, or you mention that this is currently out of the scope of the document, which is very important. That's why we have the payment milestones on PDD and SDD level, right? Given that we also developed the runbook template during the UAT phase. Runbook template, few companies call it as a user manual, few companies call it as technical design document or runbooks, right? It's all depends on the definitions that few companies use.

Then, post that, we jump into the hypercare phase. Now, in hypercare phase, again, we don't require a Business Analyst because obviously, we do not want a Business Analyst to be involved into the deployments, CI/CD pipelines, all of that. But yes, Business Analyst is needed on and off. Now, we require solution architect, we require developer, project manager to perform migration of the process package libraries, production orchestrator, everything from development environment or UAT environment to production environment. Now, once you migrate all of the data, then you monitor, support the deployed solution, and then you do the knowledge transfer to the support team. That's happening during the hypercare phase. Post hypercare also, we still require a project closure because hypercare is not the end of the project. For project closure, we will again call out all the people, which is Business Analyst, Solution Architect, Developers, Project Manager, everyone, and we ensure that all the services which are aligned with the contract agreement are provided, document handover is done, knowledge transfer is completed, and we finally have a complete sign-off from the stakeholder, and we make sure that we hand over the entire project to the end user or stakeholders COE team. That's the implementation methodology, or that's the complete process of implementation, a complete lifecycle of implementation.

Now, there are multiple people who are involved in a team of implementation, right? And that's, you need to know all of these people. Now, the main question which comes is, now this question is a little tricky question, right? But you have to gauge this question from the interviewer, right? So, given your experience, let's say if your experience is two to four years or four to seven years, this question varies. That's why this question is a very important question. Question is, what do you think are the roles and responsibilities of a Business Analyst? Okay, first of all, let's start with this. Understand processes. So, understanding any process, it's not only RPA process, it could be a different process as well. You need to have a capability of talking about whether this is an automatable process, as automation, is this process for AI? Is this process for building a new application? Is this process for actually creating some new software? Is this process for creating, you know, a new ERP application, or is this like a conversational AI? You need to understand the process.

Second, gather and document all the requirements. Now, you need to gather all the details, document each and every requirement down to the minute level, okay? Which is very, very important from the perspective of a Business Analyst role. Develop the Process Design Document, the PDD. That's the role of a Business Analyst. Everybody knows that, and that's, you should not mention in your roles and responsibilities. Evaluate business case potential. Now, that is very important. We usually forget this point, which is evaluation of business case potential. So, Business Analyst has to evaluate business case potential and have to make sure that the, the evaluation phase is properly executed. Provide recommendations via thorough automation viability study. Is one of the biggest important points. Business Analyst is the one who will provide the recommendations via thorough automation check. So, automation viability study means whether this process is automatable or no, which I just talked about, right? During evaluation of a business case. Then maintain up-to-date business cases. You have to maintain the period document, all the business cases, and it's not only the current project that you're building, but it's all the projects where you have mentioned the PDD. If there is a change in the SDD, you also have to update that in the PDD. But actually, it goes in the other way. If you get any new change, right? Or new scope from the user, usually you update the PDD first, and then you update the SDD. That flow you need to remember.

Define processes down to the keystroke level is one of the key essentials of a Business Analyst. When I say down to the keystroke level, literally even to swap application, if you do Alt+Tab, if you actually go to that application, it has to be present on screen. You have to mention that in the document, right? Even if for some shortcut keyboards, you have some keyboard shortcuts, you have to mention those shortcuts also, so that while building the SDD, the solution architect has ample amount of idea what to do. Creating the test scenario documents for the UAT testing is also a role of a Business Analyst. Now, this might be shocking, but yes, few people have understanding that UAT test cases are supposed to be built by developers. No, UAT test cases are supposed to be built by a Business Analyst. Now, that is a very important role which we usually forget. Also, making sure that all the solution alignment with the currently captured requirements are perfect, and finally, managing the change request. Now, any CR which comes in, I just told you about it, right? If any CR comes in, you need to update PDD first, so that the SA can update the SDD later, right? For you, that is very important, and that happens because you have updated the PDD. And if your PDD is perfect, then you, you know, definitely don't have to change anything on the SDD level, right? Because if your PDD is perfect, SDD cannot be like 1.0.2. If your PDD is 1.0.1, the moment your PDD is updated, your SDD also should be updated at the same time. So, both have to update at the same time, correct? That's very important. Remember that. That is the actual roles and responsibilities of a Business Analyst in any project.

Now, usually, what is the implementation team involved? Now, this is another tricky question. It's out of the scope of your current role, but yes, you need to know how many people are involved when you are actually implementing a complete end-to-end project. So, Business Analyst, Project Manager, Infrastructure Engineer is very, very important, which we tend to forget, Solution Architect, Automation Developer, and Automation Developer Lead. Now, there could be a Senior Automation Developer, there could be a Lead. So, the Solution Architect actually has a mixed role, sometimes doing the lead role of automation development, sometimes doing the role of Project Manager, depends on again, company to company. But you need to have clarity on the different team members which you require as part of the implementation team, which is Business Analyst, Project Manager, Infrastructure Engineer, Solution Architect, and Automation Developer.

Now, another tricky question. Okay, now, what is the usual client team that you deal with when you have any RPA project? Now, again, if you haven't worked on a full-fledged project, you won't be able to answer this question. So, you have to be very calm and very smart while answering this question. Client team involves Engagement Sponsor, who is a person who manages everything, right? From kickoff to project closure, right? All those initial and end phases, who is the Engagement Sponsor? Then there is a Client Project Manager. So, just like your implementation team has a Project Manager, the client team also has a Project Manager, who manages all implementation side and who coordinates with the teams for project success, who works with the IT team to provide you all the hardware access, relevant software, you know, it's basically looking after all the SMEs, approval of the selection processes, deliverables, everything is managed by the client's Project Manager. Then there is a Process Owner, okay? And then there is a process. Difference between Process Owner and Process SME is a very important thing. So, Process Owner is basically the person who is familiar with the entire process. That person is actually the point of contact for general basic information, and the person who approves your PDD and your UAT plan is the Process Owner. While SME is basically a person who provides you the SOP, the Standard Operating Procedure for the selected process, who also collaborates with your Business Analyst and, you know, your IT developers to carry out UAT testing. But SME is not the Process Owner who owns the process, okay? SME is just the subject matter expert for that current process. And Client IT Team. Now, Client IT Team, which is the IT security, sometimes you call it IT Team, you call it IT Security Team, you call it different teams, right? But the end goal of this IT team is basically to provide all the application access, provision the robots, deploy these automations, integrate with the client system teams, provide you the integration services, provide you the accesses, Azure credentials, or whatnot, right? That's the IT security team. Then there is a Support Team. Support Team is the one where you will be doing the knowledge transfer, handing over the robots, handing over the runbook, right? Handle all the lock terms for all the project closure, and that's the job of a client-side support team. And finally, Automation Operation Manager. Now, sometimes Ops Manager is not required, but it's again, it depends on clients. They have Ops Manager. If Ops Manager is there, who maintains all the start, monitor automations, right? Maintains the user access allocation, reallocation, all of that, that's called the Ops Manager. So, that's a client-side team. Again, I'll repeat, if anyone asks you what is the usual client-side team and who do you deal with, so you have Engagement Sponsor, Client Project Manager, Process Owner, Process SME, Client's IT Team or IT Support Team or IT Security Team, then there is a Support Team, and then there is Client's Ops Manager, okay? Automation Ops Manager.

Now, this question is another tricky question, which is, what are the usual implementation challenges that you face while performing or while going through the entire project? Now, this question usually is asked to check the knowledge that actually have you worked as a Business Analyst, or you're just talking about based on your current experience or based on your, you know, learning part. This actually will give you a complete scope whether you have worked on real-time projects or no. Now, remember these keywords are crucial. So, while you're talking about the implementation challenges that you have faced, talk about solving common implementation challenges as expectation setting. Now, expectation setting is a keyword. Remember this keyword. Setting expectations is very important. I told you, right? PDD and SDD, they have proper payment milestones. Now, if you set wrong expectations in the initial phase during the sign-off, then your entire project goes to toss because your client can come back and they can say, okay, you never mentioned this as out of scope or in scope, and I can do it now, right? Because your documentation was weak. So, your documentation has to be very strong, and you have to set all the expectations in the very early phase, which is, and this happens usually in projects, it always happens. So, during your defined stage or kickoff stage, you have to set the expectations on what deliverables we are going to deliver, and the client should expect what kind of deliverables and when it will be delivered, what will be the final outcome. This is very important, which has to be maintained throughout during weekly status reports as a document.

Next, scope creep. If you have heard about this keyword, it's a very important keyword, okay? It's a very generally known in terms of RPA or any project development. If you have any common implementation challenge, then the biggest one is a scope creep. Scope creep is actually what we do is, we formally agree to deliver that this is what we are going to deliver as part of the engagement. We define the kickoff stage, finalize at the process analysis stage. But what happens is, during the development, the scope of the project is not properly defined, and what happens is that your scope, because you did not define your scope properly, right? There are changes, there are change requests which come continuously during the development phase. That's called as scope creep, right? It's one of the biggest challenges that every people, every team faces during the implementation of a project.

Third most important is unorganized UAT. Unorganized UAT can completely mess up your entire timeline of the project, and that's why it is one of the biggest challenges which usually happens. UAT times have to be fixed even before you are about to go and freeze the code. So, code freeze happens around the end of the development phase, while you're doing the final QA, right? Once your code freeze is beginning, you have to finalize UAT time with the client side because you have to get their time and actually find out the time for UAT. Otherwise, if the client does not give you time for UAT, your entire timeline mess completely goes to toss, right? Remember, anything can happen during UAT. You have to be very responsible during the UAT phase. Set the clear expectations that you signed off the UAT test cases during the initial phase, and those are the only test cases which we will actually go through. Don't add any surprise test cases at the end after development, that will cause you a huge trouble during this end phase, and that's why unorganized UAT is a big problem.

Now, access delays. That is a very common challenge. We start the kickoff, we start the business analysis, you know, PD definition, SDD definition, and usually, even post SDD development, we still don't have access to a couple of applications. So, if it's not your problem, if it's not your challenge, remember, make sure, make it a clarity with the product team, or sorry, with the client team that, see, access has to be given during this phase, and what time frame or what is the timeline which I have given you, it has to run with the access, with the assumption that I have access to all the applications that I need for development. If I don't have access to all the applications, do not start the timeline, otherwise it will impact on your timeline very badly. So, remember, your timeline is very crucial, right? Which is called also called as Gantt chart report. That report is impacted badly if your accesses are being delayed, right? So, very common issue happens with every project.

Again, customer availability. I told you, right? So, if your customer is not available for UAT, for kickoff, for business case, for sign-offs, it's a huge pressure from your, from your superior teams, from your CXO level teams, that you need to get sign-offs somehow. And then, because the customer is not available, your sign-offs are delayed, and then it impacts your project readiness also. It impacts on the project budget, right? Overall. So, sign-offs are very important, and customer availability is another crucial thing.

So, we have talked about a couple of interview questions. Now, let's talk about how do you actually, you know, basically look at. So, what are the different types of challenges that you find during any kind of a manual process? You have to mention manually, this is what is happening, and when we automate, now this is the process which can't be done exactly same to same in an automation manner, right? So, you have to remember what things can be done manually, which cannot be done automatically or using automation, right? It's very important.

Now, what can happen before even you begin with the automation implementation? That's another tricky question. What can happen? What does it mean by what can happen with my, you know, automation implementation phase even before it begins? A pre-automation activity which you have to perform, which literally, let's say, automation of a Business Analyst, which filters out the priority and probable automation candidates by leveraging unassisted task mining. You can use task mining against think that this particular process is not a piece of automation. You can literally, you know, filter it out even before you define the keys. Also, this task mining actually provides you the features which can talk about what things are in scope and what things can be automated, right?

Now, next question. This question is usually a question for people who are above experience of four to five years of experience, okay? And this question is another challenging question based on your experiences, which says, if you are a Business Analyst, what you are not supposed to do in a project? I mean, what is not a role of a Business Analyst? Now, this is again another question which will take you to all the false cycles, okay? Remember, often times, Business Analyst ends up doing all the tasks of a Project Manager or Scrum Master. But remember, Business Analyst is not a Scrum Master, Business Analyst is not a Project Manager. Remember that, that's very, very important. Sometimes, since you are, since once you become a Business Analyst, your project management skills are good, right? But that doesn't mean that you have to manage the entire project. So, if you are a Business Analyst, you are not a Project Manager. That's very important. Second, Project Manager should be the main point of communications for both internal and external communications. So, a Business Analyst is not the person for communication for internal cases, not always, okay? Only till SA, you don't go down to the developer level. Now, the Business Analyst should not manage, direct, or plan any kind of a Solution Architect documents. Business Analyst is only responsible to manage and direct and plan only PDD, Process Design Document, that's all. Process Definition Document, not SDD. Also, you cannot directly manage automation developers. You cannot directly give orders to developers or you cannot directly plan the next phase for automation developers. That's only supposed to be done by a Solution Architect. Okay? And finally, Business Analyst is not the person who should have the technical knowledge of implementation or deployment of the automations to the production. Do not get involved in that phase. The hypercare phase is completely to be managed by Solution Architect and Project Manager.

Okay, awesome. Now, with all these questions, I think you have clear clarity now on what is a Business Analyst, what it does, what this particular person does, what kind of places he is involved in, what kind of stages he is doing, right? All of this is very important. Next question, what is SOW? SOW is nothing but Statement of Work. Now, Statement of Work, or you can call it as Scope of Work also, right? SOW. This document specifies all the scope of the project, objectives, deliverables, timelines, milestones, and other essential details which are required for the project. Remember, if you are asked what is SOW, it's a very important question. It is not Business, it is not a PDD. SOW is totally different. SOW involves the following items: objective, scope of the work, deliverables, timelines, milestones, and other essential details. This document serves as an agreement between all the involved parties from the initial discussion. It outlines all the expectations and sets the responsibilities of each and every person during the entire journey of the project. So, that is a very crucial document. This document is prepared in case of collaboration between different companies for any interdepartmental references if you have. Now, SOW is also basically looks at the scope of the project, which is again defining the boundaries, limits within which something, within which your developer or your project will be operated. So, that is SOW.

Then, what is the Application Access Tracker? Now, Application Access Tracker is another document which is very important, which is created during SOW. It helps you to keep tabs on the systems and applications for any crucial, both automation developer during development and robots post automation. You have to make sure that the application is available. Now, this application tracker is not only for the development phase, it's also for UAT and production phase. So, you have to keep in mind considering all three phases and keep all of the access ready throughout the entire journey.

Then, there is an Issue Tracker. Issue Tracker is also part of the SOW. You have to remember that SOW has an Issue Tracker, which is used thoroughly till the end of the project deliverable, right? It maintains and has a transparency throughout the project. It compiles all the issues, every single thing which was faced during development, during UAT, during your SDD, every single thing, right? And it has to be a complete transparency within your internal team and with your customer also.

Now, what is, now the next question is, what happens, let's say, what happens in case of a technical validation stage? What is technical validation? Technical validation is nothing but basically a solution architect checking whether this particular task which you mentioned is technically possible or no. If not, the solution architect might ask you questions, right? So, you have to be ready for that, and that is very, very crucial, very important, which is called as technical validation.

Now, the questions about UiPath products which could be asked, which is about UiPath's Task Mining. Okay? Now, Task Mining has two different things. If you scroll down, you have benefits here, you have features of Task Mining, okay? You have use cases of Task Mining here, and you have a couple of resources of Task Mining also, right? Which you can actually read through. Task Mining is another important thing because there are two products: one is Assisted Task Mining, and another is Unassisted Task Mining. You need to learn about both of these products, what they do, what how their interface looks like, and what kind of, you know, UI it has. You have to go through the Task Mining product once, right? Before the interview.

Then, after the Task Mining, when you're looking at a Process Overview Document, which is basically more of like a, like a PDD, Process Overview Document, it gives you process restrictions, expected increase transaction volumes, stakeholders, your application virtual environment, every single detail it gives you about that, right? Now, it's again another document, important, but I know there are too many documentations, man, but it's very, very important.

Now comes the questions about complexity assessment. Now, how do you define whether a particular project or a process is low complex, medium complex, or high complex? There are various parameters to it. This question will be asked in an interview to a Business Analyst, also to a Solution Architect, also to a Senior Developer, also to a Program Manager or Project Manager. So, it's one of the questions which is kind of, you need to have numbers on, on the figure, right? Now, how do you talk about these numbers? Let's say, if you want to define a process as a low complex process, number of applications. So, what are the different parameters that can impact? Let's say, number of applications. If your applications are between 0 to 3, you can say it's a low complex process. If your applications are 3 to 5, you can say it's a medium complex process. If your applications are between 5 to 7, it can count as high complex process. Now, let's say, number of fields that you want to interact with. If the number of fields are 1 to 100, it is still a low complex process. Again, it depends totally on companies to companies, right? If your interactions of the fields are 100 to 200, it's medium complex process. And if you're interaction with the fields are above 200, it's complex process. Number of screens that you interact with. If your number of screens during a particular process is 0 to 10, again, yet it's a simple or a low complex process. If your number of screens are between 11 to 20, it is a high medium complex process. And if the number of screens are above 20, then it's high complex process. Number of scenarios or logical things or variations in a process. If number of scenarios in a process are more or less than three, it is still low complex and simple process. If the number of scenarios are between four to six, still medium complex. And above 7 to 8, high complex. Image-based automation, it's always high complex. Whenever there is computer vision or image automation involved, it's never low complex or never medium complex. It's always going to go for high complex because you cannot guarantee the automations, right? Then, number of input formats, again, 2 to 3 low, 3 to 5 medium complex, and 5 to 7 high complex. Then, if your project involves AI or Document Understanding or GenAI, definitely market is high complex because implementing Document Understanding, AI Center, or AI is not a simple solution. It's not a low complex or a medium complex process. It's usually high complex process. Okay, I hope you're clear on the complexity assessment.

Now, let's talk about prioritization and implementation phases of automation. Now, prioritization is a very important question, which, if you have heard about it, I mean, obviously, if you're a Business Analyst, you have heard about low-hanging fruit, quick win process, long-term improvements, must-do improvements. Now, if your complexity is low, benefits are high, it's a quick win project, correct? That's called quick win. If your complexity is low, benefits are also low, but you still can do it faster and show quick ROI, it's low-hanging fruit, which is literally like the lowest complexity, but you can still do the automation quickly and show the benefits. That's still called as low-hanging fruit. If your complexity is high and the benefits are also high, but it is a must-do improvement. And if your complexity is high and if your benefits are low, then it's a long-term project, so you just, you can put it for later when you can do it later, right? So, you need to prioritize your automations and you need to know this graph. This graph is available on one of the trainings of UiPath's Business Analysis. You can just go through that training and you can find that graph very easily there, okay?

Then you have to know about the Process Assessment Tool, which is a simple Microsoft Excel resource which allows you to go through the, you know, different types of technology, stakeholders, who is responsible for what. It's basically just the Process Assessment Tool which talks about stability, feasibility analysis, and all of that. You need to know about UiPath Automation Hub. So, there could be a couple of questions on the Automation Hub, right? We need to know about that. It's very important. It has a pure product capability of, you know, running a whole end-to-end project. So, just go through Automation Hub once. We will, I mean, I have actually done a whole series on that. You can watch the series and you can get more knowledge about Automation Hub there, right?

Then, let's talk about a few more questions on top of my mind. What can happen is, huh, what kind of questions can be there? Okay, questions, again, very important questions. What, what is the content of PDD? I forgot this question. Okay, what is the content of PDD? So, PDD has purpose of the automation, it has objectives of automation, it has key contact people, that who should contact, minimum prerequisite for the automation, uh, then process overview, applications used, as-is process map, detailed as-is process actions, detail as-is will have all the keystroke level, remember. Then you have a process map, you have input output descriptions, you need to have reporting, you need to have in scope of automation, what is in the scope, what is out of scope of automation, what are the known exceptions, unknown exceptions which might occur, change and improvement details, and, if you need any additional sources or additional documents to refer, those documents. So, these are all the points which should be there in the Process Design Document. Now, PDD is the one document which is built by a Business Analyst. So, this question is valid enough that what kind of content is there in the PDD, and that you must know as part of, as a, as a Business Analyst person.

Then, apart from that, again, on top of my mind, what kind of questions can come? Let's say, what kind of exceptions are there? So, there are known exceptions, unknown exceptions. Known exceptions are called as business exceptions. Unknown exceptions are called as system exceptions. That is the basic questions which could be asked for, like, initial entry-level Business Analyst role. What else? What could be the out-of-scope activity that, you know, that is there which cannot be automated? Like compliance request activities which are liable to a rapid change in future, templates or input that are not standardized at all, which is like completely unstructured activities which require human cognition, either you involve a human in that or just keep it out of the scope. Efforts to automate a specific activity which exceeds the gains, keep it out of the scope, majorly.

Then UAT. Again, UAT, you know that, right? It's the Business Analyst's job to manage the UAT, create UAT test cases. So, you need to know how a UAT test case looks like, what are the things that are there in UAT test cases, and what is the usual UAT plan, right? You have to build a UAT plan also for UAT plan, you need to build UAT test cases, complete testing plan, and issue tracker phase also, that what would you do in the case of UAT begins, right? Now, basically, in UAT phase, Business Analyst fits there, initially, and what Business Analyst does is, there are majority of responsibilities that Business Analyst does, right? Test closures, defect management, test executions, testing the defects, testing the strategy, right? These are a couple of responsibilities of a Business Analyst. You would say that not all of them, but yes, sometimes it is, right? Because Business Analyst is involved in all of these phases. Testing the strategy, designing the test cases, executing the test execution, I mean, not Business Analyst executes it, but yeah, he is involved in that field, right? Defect management and disclosure also.

Now, after all of that, the basic questions, very high-level questions, like process discovery. Process discovery is basically, you know, set of tools which you require to understand how business processes are executed. There is Process Mining, Task Mining, and, you know, Assisted Task Mining products of UiPath which you can use. Apart from all of this, there is a question which could be asked about what would you do in case of a continuous discovery? Continuous discovery is more of like a CI/CD, but CI/CD is meant for deployments after the development. But also, you have a continuous discovery phase as well. Continuous discovery phase is basically just discover, understand, and act on it, and it's in a loop. So, first is discover, second is understand the processes, third is act on it by streamlining, streamlining your processes, reengineering those automations, and again, start to discover more and more. You need to keep the loop of discovery of continuous discovery in automation companies because that gives you more and more projects in future, right?

H, we have talked about all the cases a lot, and what, so there could be questions about any specific domain that you have worked on. So, you might want to talk about like, I've worked with IT security team, accounting, procurement, sales. Talk about few automations of accounting, like accounts payable, accounts receivable, right? Record to report, expense management. In sales, we have order to cash, meter to cash, quote to order, account management. After sales, we have case management, customer service. For HR, we have hire to retire. Majority of the use cases. And all of these use cases, you should have on top of your mind immediately to answer because the expectation is that you have seen these use cases. And the biggest expectation is always from a Business Analyst that a Business Analyst should know the use cases depending upon the different domains and different companies that you deal with, right? H, so those are all the questions which comes on top of my mind. You should still go through Task Capture, Task Mining, what is Automation Hub, how it looks, look at the Task Mining product, look at the Process Mining product, not too deep, just on a high level. Understand these products, how they work, how they function. You need to have capability and questions and observations on Orchestrator, how Orchestrator works, what are the key features, right? So, there could be a question like, what are the key features of Orchestrator? You need to understand like scheduling the robots, automatic upload of all the logs and screenshots from the robots, central management of all the repositories, robot settings, assets, queues, credential management, everything is on the Orchestrator, and distribution of the workload, right? Those are the key features of Orchestrator.

Apart from that, basic concepts of Orchestrator, like robots, folders, packages, what are the jobs, what is the heartbeat mechanism, you need to have those on top of your mind. And finally, the questions could be around, you know, libraries or maybe templates. No, don't need to have too deep knowledge on that, but you just need to know that what kind of automations you can build, what are the different libraries, and what are the different templates that UiPath provides, and how they actually function. That's all on the high level, right? Nobody's going to ask you about the development activities or actions. But they can ask you questions about Orchestrator, so just be aware of that. And with that, I think we have covered a lot of points about Automation Business Analyst. Now, if you find this video helpful, do let me know. Like this video, share it with your colleagues if they are going through an interview for Business Analyst. And do take this course and certification also. This certification is very mandatory. It will give you good credentials that you are a certified Business Analyst, which is the UiPath Certified Professional Automation Business Analyst, right? So, there's Associate certification, then there is Analyst Professional certification. I have both of them. So, if you need to know more about it, do let me know. Reach me on LinkedIn. And I think so, that's all for today's video. Happy automation.