Understanding the importance of the SA role
Robotic process automation (RPA) is also nowadays one of the mainstream functions of IT. So, as with other IT functions, RPA also has to have an SA as a role. But the question arises: Do we need an SA? This question has a straightforward answer, and that is: Yes! What are the valid reasons for having an SA as a role? How would we justify this role? To answer this question, we need to understand the responsibilities of an SA.
An SA is a person who is a problem solver and specializes in identifying processes that are good candidates for RPA. This person knows the ins and outs of the underlying technology, its strengths and weaknesses, and how to overcome them. An SA for RPA has extensive knowledge about the core function and automation and is a master in finding solutions, be they technical or non-technical. They understand the other IT functions and how to amalgamate them to find a viable solution for a problem. An SA is known as a jack of all trades and a master of solution design. They can be a master of other traits, such as programming, networking, infrastructure, and so on.
Having an SA on your team will give you the peace of mind to find the best solution and not the easiest solution for the problem. A good SA will approach a problem with integrity, customer focus, and frugality. They also possess some ethical and moral responsibilities. Knowing that your SA will do what is best for the processes, people, and company makes this role invaluable. An SA is also responsible for evaluating the potential of an RPA project, its limitations, and its efficacy. If something can be automated, that doesn’t mean it should be. Based on this principle, an SA can weed out processes that seem to be a good fit but are not a good fit.
For example, let’s assume you have a team working on an RPA project. There is no SA available, and the responsibility to find the best solution and technology is the responsibility of the developers. As developers are also tasked to deliver the code on time, they tend to get biased in selecting a solution that is easy and fast to develop. An easy solution is not always the best solution and is prone to introducing future issues. To avoid this, the responsibility of selecting the technology and the best solution should be decoupled and should be given to an SA. They also bring along thought leadership, which is needed to bring people, processes, and technology together.
An SA will do regress research and will try to find the best solution. They will evaluate the solutions based on future scalability, manageability, and maintainability. A proper evaluation should be done as to whether an SA is required or not based on the team’s capability and experience in design, development, and delivery. However, note that an SA can be a costly affair. Their cost can add to the budget, but not having an SA engaged in the initial stage can be costly in the long run. You need a person who can challenge the status quo. They question the team and provide guidance with respect to design principles and development standards, and can avoid cutting corners. In relation to what we discussed about the importance of the SA role, let us now look into the various ways in which an SA can bridge the gap and how they are able to help the team and project to succeed.
