The Business Analyst skill set is centered around communication, problem-solving, requirement evocation, and documentation. These skills are no less important in the delivery function of robotics process automation (RPA). The cycle of RPA leverages the skills of the business analyst in specific ways. Each heading organizes an environment of complexity that the business analyst must keep from chaos.
Communication is critical for the many types of meetings you convene and conduct as a business analyst. Convening requires that you communicate the purpose and agenda in ways that get the right people to the table. You want to convey that the meeting requires their active participation. Do this by specifically connecting items in the agenda to the expertise offered by each individual attendee. Make personal requests to individuals based on the number of responsibilities they have. The busier they are, the more personal the requests should be communicated.
Conducting meetings requires a focus on the agenda. Well-formed agendas are outcome oriented. Many have adopted the request for next steps, but outcome orientation also requires assignment of tasks to attendees. Because each attendee has been invited because of their expertise, assignment relates task directly to the ability to perform the request. This prior thought ensures that meetings move forward methodically and productively.
Problem Solving. Business Analysts are problem solvers. Throughout the RPA process, the business analyst is tasked with observing, documenting, and updating communications of solutions. But they are not tasked with coming up with this on their own. The BA can leverage the expertise and insight of Subject Matter Experts (SMEs) and others who know the process inside and out. In this way, problem-solving becomes more of a bridge making and interpretation task. Often, bridges are required between departments or processes that have been siloed. Interpretations are needed to enable different sectors of an organization or disparate business processes to create a common language.
Requirement Evocation. Requirement evocation is a fancy way to say that the business analyst is a master interviewer. The BA must get knowledge out of the heads of workers and SMEs an into documentation that others can comprehend. With RPA, that information must be distilled to its least common denominator to support simple and increasingly complex automation. Multiple interviews, clarifications, and iterations may be required. Each iteration requires the BA to engage the interviewee in productive communication. This requires genuine interest and an ability to connect authentically.
Documentation. The Process Definition Document (PDD) is a critical early step in RPA. Every effort must be made to ensure that the document is accurate, comprehensive, and adaptable. If a PDD is to fail, the failure is most likely revealed in the Testing Phase of the RPA life cycle. Corrections required at this point will cause the process to stop while the documentation is updated.
Accuracy. After the manual process analysis, the BA is required to document all process steps in the PDD. The main purpose of a PDD is to describe the as-is manual process that is to be automated with has much keystroke details as possible.
Comprehensive. The Tester and often a client Subject Matter Expert (SME) will be employed to implement scenarios in a test environment. Scenarios are based on normal functioning parameters and typical usage in a manual context. It makes sense then, that the BA would at least float some mock scenarios from the perspective of his/her role and the context expected in the tests.
Adaptable. Much of the need for adaptability comes as a result of any failures or vulnerabilities revealed in the mock scenarios. Additional adaptability may come with a shift in perspective away from typical operation to mock user scenarios. These scenarios simulate the typical ways that a user may interact with the process. Understanding that user is most often perform tasks that have worked for them in the past, these mock user scenarios are most useful when process expects users to perform a task outside their normal expectation or habits.
