Now, I am a BA. My role of doing the routine operational work is no more there. Now I am in to the mode of asking questions. So, what are the questions I should be asking? How am I supposed to interpret the answers? How do I build my knowledge on the process based on these answers? How can I contribute to the improvement of the process? These are few questions, which came to my mind when I started this role.
Note that I am writing this article more from technology and banking point of view. However, I will try to generalize the same in future articles.
I had joined a technology organization after working for many years in banks, however was still supporting a bank as a business analyst on behalf of this technology organization. As I mentioned earlier, my understanding on the role of a BA who is working for a Bank is to ask questions so as to analyze the process happening around the bank and provide solutions for the process improvements, either technological improvements or operational process improvements. With this understanding, I started working for the technology organization; however things were slightly different out there. When you are part of a technology team from the bank, your main goal becomes providing solutions towards enhancing the systems that are being supported by the technology teams or support for enhancement of the systems used or developed for the Bank, either it is in house (built by the bank’s technology team) or it is an external system (supported by another technology organization). So, the questions you ask shouldn’t be restricted only to improve the process followed in banks, but also should be from the supported systems point of view, i.e., those questions should also be more from technology point of view whether such process enhancements are feasible from the existing system point of view or not. This would be quite challenging, as you are not only acting the roles of a business analyst in asking questions to analyze the processes alone, but also understand the systems used so that you can translate the business requirements in to functional specifications for the understanding of the developers to enhance the system. Confusing? Or Interesting!!!
To avoid confusion, if any :), let us see understand the difference in the activities performed by the business analysts in these banking and technology sectors. Let us say,the Bank uses two different systems Alpha & Beta for one of its processes, Alpha being an external application supported by a technology organization & Beta being an in-house application developed by the technology team of the bank. Also, assume Oliver is a business analyst who is working for the Bank, Mark is a business analyst working for the technology organization & Bob is a business analyst who is working for the technology team of the bank.
For Oliver, since working for the bank directly as a business analyst, his role is more to understand the business process and provide process improvement ideas, so he creates requirements that need to satisfy the business needs on behalf of the bank, the documentation created for this purpose termed as Business Requirements. Note that he will not be concentrating on whether for the process enhancements, which systems need to be enhanced. He will more be interested on how those business requirements can be put in place for business efficiency, so he will wish to see the end results by testing those requirements. So, the questions he will be asking business will be more from this point of view of whether the suggestions he is providing to enhancing the process, results in business benefits.
The roles of Mark & Bob would be the same from their respective applications support point of view; i.e. they need to analyze those business requirements given by Oliver and come up with solutions for enhancing their respective systems Beta & Alpha. So, what they will do is translate those business requirements in to the language in which developers can understand and enhance their respective systems according to the requirements, the document which is created for this purpose is generally termed as Functional requirements. For this, they need to understand the business requirements thoroughly, until they are very clear so that they can provide solutions on how the requirements can be fit in to their systems. How they understand the business requirements, is again by asking questions, but these questions would be more not only from business point of view, but also from technology point of view, like whether the business process enhancement suggested really helps business or not? How much efforts required for them to enhance the system? Will that enhancement really be worth to do?, the results of these questions, rather the answer to these questions will result in identifying the impact to their respective systems and the supporting stake holders, if any, which is being termed as “Impact analysis” or “Functional Impact Analysis”. They also need to support the development team in terms of testing the requirements before them handing over the product to Oliver for him to test the final output. This testing done by the testers, with the support from Mark & Bob, is termed as SIT (system integration testing, performed by technology with the help of technology BAs) and the testing done by Oliver along with the end users to ensure that the final output meets the business requirements which was given initially is termed as UAT (User acceptance Testing, as Oliver is the business representative, who is acting on behalf of the user). Also, note that the roles of Mark & Bob will slightly vary depending on the respective systems they support.
I think I have introduced more terms now to make it more confusing, relax, its simple. So, what you think? Are we done with all the roles and responsibilities of the BAs!!! No, please wait for the next article to come, as we have a long way to go :) …