Select Page

Inability to understand the difference between the job responsibilities of a BA and BSA can add significant resource risk to a CRM project. In order to understand this further let’s explore the difference between a BA and BSA. Difference between BA and BSA- A person in the role of Business analyst (BA) works with the business to gather business requirements for the project.

This person does not necessarily need to know the system and more specifically Salesforce in a CRM implementation. A person in the business system analyst role knows the business requirements and converts them into system requirements which can then be given to the developers.

A business systems analyst is a specialist on Salesforce who works on system requirements. Business systems analyst interfaces with business and business analysts to convert business requirements into system requirements. Business analyst usually works on the implementation side while BA may be working with the business on initiatives other than implementations.

Let’s understand this further by the help of this example:

Scenario- Implementation of Salesforce service cloud- Case Management and requirement gathering for Case life cycle

BA gathers following requirements for the scenario 

Req1–> Three types of cases to be created

Req 2–> The statuses are New, Investigate, diagnose, correct, Closure

Req3 –> Case to be submitted for an approval process before it can be closed

Req4–> Case needs to be accessed by multiple groups of users

Now, let’s see the how the above requirements can be converted into system requirements by a BSA who is well aware of Salesforce and has multiple certifications

Req 1–> Three types of cases to be created – Additional questions asked by BSA

  • Do they have same fields?
  • Are they accessed by the same set of users?
  • What is the default status when they are created?
  • What are the required fields to create the case?
  • Who does the case  gets assigned to upon creation?
  • Is there any email notification on the creation of the case?
  • Is there any alert on the creation of the case?
  • Does any other field gets populated on its own on the creation of the case?

So, the BSA additionally qualifies Req No 1 given by BA. This should be added to the requirement description and acceptance criterion of the user story which deals with the creation of the case.

Req 2 –> The statuses are New, Investigate, diagnose, correct, Closure  -Additional questions asked are

  • Is there a requirement of a Path (Visual flow) on the case?
  • Is there any path guidance required to guide the user through the case life cycle?
  • what are the checks required for the users to move the case from one status to another?
  • what are the check required upon case closure?
  • Can user jump statuses and what are the conditions for the same?
  • Who can change the statuses of the case?

There are many other questions which can be asked and system requirements can be drafted accordingly:

Why it is important to align BSA and BA in their respective roles?

Many times, a BA is mistaken for a BSA and the above example is a testimony of how requirements can be left incomplete with this misalignment. This can have a very negative impact on the project schedule putting the project in danger. In a nutshell here are the reasons why a BSA is required and should not be mistaken for a BA on a Salesforce CRM project.

  • Requirement translation into system requirements
  • Communication with the developers
  • Adherence to the time schedule of the project
  • Effectiveness in agile operations
  • Aid in solution development

I hope that I am able to communicate the difference between BA and BSA and the importance of not misaligning BA and  BSA positions and the subsequent impact on a CRM implementation.

I hope you have enjoyed the blog. Please keep sharing, commenting and liking as it will keep me motivated to write.