Salesforce Discovery is a journey of definition, starting with the big picture and working towards more granular degrees of detail to correctly and completely articulate the needs of the business. A thorough Discovery phase lays the foundation for a successful solution design that meets the business requirements and delivers a high degree of value.
A well-formed Discovery process has multiple phases, including setting a vision for success, defining the operational structure of the business, defining the business rules, articulating business processes, and defining functional and nonfunctional requirements.
Discovering the business structure is all about setting context. In this article, we’ll discuss how Business Analysts can discover systems and stakeholders to understand the operational structure of the business – setting the appropriate context to move into more detailed discovery phases.
We’ll unpack how to map:
- The business units or departments.
- The stakeholders involved in the business and their reporting lines.
- The technological landscape of the business.
- The high-level functional areas that your design should support.
Defining the Business Units
Defining the business units, or departments, that constitute a company is an important but often overlooked step in the discovery process. Think of the business units as the skeleton of the organization, giving form and structure to its operations.
Understanding the various units and how they interact with one another is an important context-setting step that will help your team understand which departments your Salesforce solution should service and what other areas of the business might be impacted.
Business unit definition can be simple and straightforward. Consider asking questions like:
- What departments exist in your organization?
- What responsibilities does each department own?
- How do these departments work with each other?
- How could these departments work together more effectively?
- (How) do these departments already use Salesforce?
Unearthing areas of overlap between units can help to enhance value delivery by ensuring that Salesforce features are supporting the business as broadly as possible. The output of this initial step should be a simple structural map of the business that defines each business unit, including its purpose and basic interactions:
Mapping Stakeholders
With the departmental structure of the business mapped, it’s time to move on to the people who make it all happen. Persona mapping is a common exercise in Salesforce discovery processes aimed at representing the needs of users in a simplistic, approachable way.
Personas should be broader than job titles or distinct roles. For example, you may have a Consultant persona that is representative of Junior Consultant, Associate Consultant, Consultant, and Senior Consultant roles in a company. Personas should articulate at a minimum:
- A common, unified purpose.
- Key actions/responsibilities taken (or to be taken) in Salesforce.
- Pain points to solve.
Remember that your personas will be referenced in your user stories to indicate who a business requirement should service. Developing a clear set of personas that stays with your org across its development lifecycle can help to ensure that solutions stay user-centric. You can find a persona mapping template here.
Developing an organogram is the next step in developing a conceptual framework representing the people in an organization. An organogram represents different roles in the company and their reporting lines. Your organogram can reference personas, but may need to be more granular (by representing actual roles/titles) to be able to delineate reporting and managerial lines. Your organogram should also indicate the business unit (or department) that each of the roles resides within.
A clear organogram serves multiple functions, including:
- Helping the technical team understand the various roles and their interactions.
- Identifying decision-makers, users, and super users in each business unit.
- Demonstrating reporting lines (i.e., that can be used to design a Role hierarchy).
While drafting your organogram, it is useful to ask the following questions:
- Who does this role report to?
- Does this role have any subordinate roles?
- Should this role’s manager be able to see/manage their data?
- Should this role’s subordinates be able to see/manage their data?
Understanding the Systems Landscape
In a complex tech world, it’s becoming increasingly rare for a company to use Salesforce in isolation. Understanding an organization’s full technological landscape is critical in developing a well-rounded knowledge of how a Salesforce solution you deliver contributes to their overarching tech strategy.
Developing a system landscape diagram helps to answer questions like:
- What systems does the company use and why?
- Where does data originate?
- How does data move into Salesforce?
- What functions does Salesforce service (and not service) for the company?
- What applications, products, and third-party tools does the company use to enhance Salesforce’s OOB features?
- What integrations exist, and how/when does data move in and out of Salesforce?
Tip: The Salesforce Architect website contains many useful templates, including a template for a System Landscape Diagram.
For organizations with complex data management strategies, or data warehouses/lakes, it can be helpful to annotate your system landscape diagrams with notes on how and when data flows from system to system and where data is mastered (where the “golden record” lives).
When developing your system landscape diagram, you can consider asking the following questions:
- What system(s) do you use to manage your finances?
- What system(s) do you use to manage your operations?
- What system(s) do you use to manage your sales?
- What system(s) support your marketing efforts (i.e. Email Service Providers)?
- Where do you store your client information and/or files?
- On what platform(s) do(es) your team communicate?
- What business intelligence systems are in place? How do you report on your performance?
- How is Salesforce currently being used, if at all, to support your business?
- How and when is data moved between systems?
Setting the Stage for Solutions: Defining Epics
With the relevant context of the business articulated, Business Analysts can begin to articulate the high-level functional areas that the intended to-be solution should support. These requirement “containers” are often referred to as epics.
Epics provide a high-level scaffolding under which more granular requirements (i.e., user stories) can be defined so that they stay organized and are easier to manage through the delivery lifecycle. Your epics should group your user stories by topic or category (i.e., Financial Management, Impact Reporting, Sales, Service Delivery, etc.). When drafting your user stories, be sure to reference which epic they support.
Summary
Defining the business structure is an important step in conducting a thorough, top-down Discovery process. Defining the operational structure of the business includes articulating the various business units, or departments; capturing the various roles and personas (and their interactions); understanding how Salesforce fits into the company’s broader technological landscape, and capturing the key functional areas the solution should support.
Remember that once the structure of the business is defined, Discovery teams can move on to defining the “business rules”—the key entities, entity relationships, and data ownership and visibility patterns that drive business operations.
