Bridging the gap

Now that we have established the importance of having an SA in your team, let’s talk about one of the most important functions an SA plays in the life cycle of an RPA journey—bridging the gap.

You might be thinking, what does bridging the gap mean? The phrase is self-explanatory, but to give it some context, we will use a scenario as an example.

Let’s say you are an SA and have been invited onto an introductory call by the client. The client has their subject-matter expert (SME) walk you through the current process, for which they want you to develop a solution. After listening to the SME for 15-20 minutes, you realize that there will be a need for a mechanism to read the PDF files used in the process as they are scanned images’ PDFs. Currently, as humans are doing the process manually, they don’t feel the need for any other technology other than just looking at the PDF and extracting the information.

In this scenario, there is a gap that you have identified, and you might have already started thinking about how to approach this problem. In your mind, you know that you will need optical character recognition (OCR) to solve the problem. You were about to spill the beans when you were interrupted by the vice president (VP) of IT. He said, Just so you know, we try to solve a problem not tactically, but more strategically. What he meant was for you to think of a solution that is not only used for RPA but something that can also be used as an enterprise-wide solution such as OCR, which can be leveraged in other applications and solutions as well. It can also become a service that can be called in future automation as well.

After you understood what the VP meant, you realized that the gap has increased, and you now have to come out of the RPA box and think like an integrator who will bridge the gap. In this scenario, you have the job of not only coming up with a viable solution but also bringing all the necessary teams together to turn that viable concept into a real functional solution implemented in production. This is what is not written in the job description, and neither will anyone tell you that it is your responsibility. But it is assumed that you already know what needs to be done as you are the SA.

Though it seems and looks like it is fairly simple, the task has multiple action items. You need to design the solution and do a proof of concept (POC). Then, you need to identify all the processes, people, and technology you will need to make this solution a reality. After your POC is approved, you will have to identify all those teams that are needed for this mini-project of yours.

This brings us to a very important point, and that is: an SA should possess knowledge of not only programming and technology but also networks, security, infrastructure, and industry standards. Having this knowledge will help you define the infrastructure needed for the solutions—for example, What kind of security should be in place? What kind of infrastructure is needed?; so on and so forth.

That is why I can’t emphasize enough that an SA should be a jack of all trades. An SA should be up to date with the current technologies and should have enough knowledge to have a serious discussion with the other teams so that they can understand the requirements and recommend the right course of action. It also helps to know the client technology stack so that you can easily and efficiently design the solution based on what is already available in-house rather than go on a shopping spree.

Frugality should be one of the strongest traits of an SA. You, as an SA, are hired to do the job using the tools and technologies available. Anyone can google and say that XYZ vendor has a product that we are looking for and that we can go and buy off the shelf. Well, that costs a lot of money, and everyone knows that there is always a readily available product on the market. But you are hired so that they don’t have to invest in something new and still end up owning it. So, always try to find a solution that is economical. It’s not that SAs don’t use or suggest self-solutions, but that is only when there is a dire need for it for a faster go-to-market (GTM) strategy and budget is not a constraint. We will talk about this in detail in the Design principles section of Chapter 5, Designing a Framework for Consistency and Resiliency.