A question came up in the Salesforce community that I have been thinking about recently. The question goes like this:
“Hi All, I am onboarding new org where I will be acting as a BA and need to submit a request for areas I want to review i.e. documentation? Does anyone have any suggestions as regards good questions to ask? Heres what I have so far– Business Analyst
Can we setup a shadowing session to understand your workflows.
Can we get access to your JIRA board
What known issues are you working with and what are the workarounds
Can we get a glossary or data dictionary list of your terms
Who are the key stakeholders who manage systems that integrate to Salesforce?
Do you have an org chart?
My answer back was – short- and incomplete, “as a Business Analyst, my questions are all about Business to start out with. why are you using it and what is important to the business should be the first steps.”
I have had a chance to think about it some more and I want to write some additional words to explain what I am thinking and why. As a Business Analyst for many years, and as a Salesforce Admin/Analyst/Architect, now Consultant, I see where I would hope we can go as an ecosystem to make the process better. The assumption is that the NEED for any Salesforce Analyst, Salesforce Architect, or Salesforce Consultant at an org is BECAUSE changes are needed, from business process to technical functionality, or to stakeholder’s communicated desires.
Some background first:
I am currently preparing to take my CBAP certification, and just finished reviewing the Strategy Analysis section of the BABOK.
Also, I am on the long journey to becoming a Salesforce CTA, and have been going through the prep for the Board Review process.
First, let’s look at the Business Analyst side, and the description of Strategy Analysis, which is one of the main Knowledge Areas of Business Analyst Work (according to the IIBA in the Business Analysis Body of Knowledge (BABOK)). Strategy defines the most effective way for an enterprise to reach a desired goal and objective. Strategy Analysis describes the business analysis work to collaborate with stakeholders in order to identify a need of strategic or tactical importance (aka, the business need), enable the enterprise to address that need, and align for the change.
As part of Strategy Analysis, the BA is asked to lead the Definition of the Change Strategy, where you develop and assess solution approaches, and then select the recommended approach.
A change strategy clearly describes the nature of the change in terms of:
• context of the change,
• identified alternative change strategies,
• justification for why a particular change strategy is the best approach,
• investment and resources required to work to the future state,
• how the enterprise will realize value after the solution is delivered,
• key stakeholders in the change, and
• transition states along the way.
– (taken from IIBA BABOK v3)
That is a lot of responsibility for a BA, right – RIGHT! BAs are not just for “gathering requirements” (which is a term we need to abolish, as if requirements were daisies out in the garden ready to pick…) . BAs are responsible for understanding the business domain, it’s stakeholders, their goals, and dissecting the true needs of the organization. BAs should be able to recommend, justify and drive forward meaningful changes based on Analytical Thinking and Troubleshooting, Communication and Interaction Skills, Knowledge of Tools and Technology and use of hundreds of Techniques that BAs use and become masters of throughout their career.
Now, let’s look at the Salesforce CTA role. According to the Trailhead website: “The Salesforce Technical Architect (CTA) credential is the pinnacle certification for those who demonstrate the knowledge, skills, and capabilities to design and build high-performance technical solutions on the Salesforce platform across all areas of domain expertise.”
According to descriptions of what a CTA does “Candidates must possess broad knowledge across multiple platforms in all domains. The CTA assesses customer requirements and architecture in order to design secure, high-performance technical solutions. Candidates must design a recommended architecture solution based on clients needs and must explain and justify why and how they will build the solution.”
I have bolded key words in the paragraph above that match up directly with those indicated in the job description of a Business Analyst doing Enterprise Strategic Analysis. THEY ARE THE SAME THING!! (ssshhhh, don’t let this secret out.)
When considering the description of a CTA above, who do you believe is the most critical person a CTA will try to team up with at a customer site? In my mind it is the resident Business Analyst. The CTA goal is to take the customer needs and turn those into a recommended architectural solution.
A good CTA should be able to handle the technical side of the equation, but who is going to be their partner on who really owns the business domain? As we discussed above, it is the Business Analyst that owns this realm.
Let me propose a solution of the list of questions and assets that will help the BA be prepared to meet with and collaborate with the CTA as the Salesforce project begin. When I look at CTA Practice Scenarios, it appears to me to be what I would want to see at a new customer engagement. In my perfect world, a good engagement would include a Business Analyst and a Salesforce Architect working together. The BA would build the following for the Architect, and the Architect would return with Architectural designs, diagrams, and suggested solutions.
Project Discovery Doc – Draft v1
• A high level Business Vision/Mission Statement,
• Describe what the business does. Define the Business Goal(s).
• Description of Internal Employees and External Employees, and their functional groups. (define their business capabilities)
• Descriptions of External Clients (customers) in functional groups if applicable (define their business capabilities)
• Descriptions of External Partners, if applicable (define their business capabilities)
(Specific numbers for the questions above are important)
• What systems are used today
• Explain back end processes used today (long explanations are better)
• What external integrations are used today
• How do end customers interact with organizations systems/business processes today
• How are new customers acquired? (what channels? what methods?)
• How many new customers are acquired in a month?
• Walk through the customer qualification process.
• What is the customer retention process
• What is customer service process like? (Who services your products/customers?) explain process in detail.
• How/when do you get paid?
• When does finance/accounting get involved?
• When does the CEO/CIO/COO/CMO/CFO get involved in your processes?
• Complicated logistics processes are described step by step (a, b, c, d)
• Legacy systems that need to be replaced are indicated
• Legacy systems that cannot be moved (for legal, regulatory, logistics reasons)
• APIs used are noted, along with numbers of usage daily/weekly/monthly
• How employees login to the network or authenticate to work
It is important to have a Business understanding of a Future Goal. This is NOT the same as a Solution. Architectural Solutions will be defined later, based on the Needs and the Vision of the Business Stakeholders. Defining the Future State is answering the business objectives that this solution will achieve.
The Future State will answer questions like “Why are we doing this?” and “What will this change?”, NOT “How we will change it.”
The Future State should ensure that you are asking for a solution that solves the right problem. The Future State also explains the boundaries of the proposed changes, as well as the potential value expected.
BAs use the following Techniques to build out this Future State area of the document, with the assistance of Key Stakeholders:
• Competitive Analysis
• Process Analysis
• Risk Analysis
• Root Cause Analysis
• Survey or Questionnaire
• SWOT Analysis
• How much data do you use today?
• Where is the data located today
• How long do you retain your data before archiving or purging it?
• Is your data subject to legally defined personal data (PII) laws, (such as GDPR, CALOPPA, CCPA, PIPEDA, Australia Privacy Act, etc)?
• Do you store Credit Cards/financial tracking data? Explain your privacy policies around security on these pieces of data.
• Do you store electronic files (PDF, etc)? What are the sizes and counts and how do you use them?
• Document all security rules (Who can see what/Who can do what) for both Internal Stakeholders and External Consumers of Data/Systems.
• Business Department makeup: Regional ownership? / Role based hierarchy?
• Do you have Account-based Hierarchy? (Acme Widgets owned by Acme Worldwide, etc)
• Describe existing reports (show examples) of what users/managers/execs currently use.
• What are the main business KPIs, metrics you wish to track? What does these KPIs mean to your business leaders?
• Do you have any external-facing reports for partners or customers? How do you deliver them?
• Languages used in the organization.
• Regional/global deployment areas? How do you ship your products and updates to products?
• Technical/development standards at organization (development lifecycle, standardized tools, deployment plans, deployment methodology prefs)
• Training methods at organization
• Testing methods at organization
• Regulatory/compliance requirements at organization
• Internal Governance systems: CoE, PMO, Steering Committee, Product Owners
• External Governance & Compliance Systems: This can be a HUGE area for both Business Analysts and Salesforce Architects. These can be industry/vertical specific, but can have an impact on your solution design and how you communicate and store information about your customers, These are areas such as, but not limited to:
• FINRA and Sarbanes Oxley (SOX) – protection from accounting errors and fraudulent practices in enterprises, and to improve the accuracy of corporate disclosures.
• HIPAA – protect sensitive patient health information from being disclosed without the patient’s consent or knowledge.
• GLBA – requires financial institutions to explain how they share and protect their customers’ private information.
• TOGAF– provides an approach for designing, planning, implementing, and governing an enterprise information technology architecture. Many organizations require compliance with TOGAF when building architectural designs.
• DODD-FRANK – strict regulations on lenders and banks in an effort to protect consumers.
to be continued….