Skip to main content
All CollectionsSolution guidesUnderstand how the business operatesAnalyze and design customer journeys and business processes
Perform fit-gap analysis and capture complete business requirements and user stories
Perform fit-gap analysis and capture complete business requirements and user stories

Capturing business requirements and user stories against the business process diagrams

Updated over 2 months ago

You are reading a guide that explains how to build up your organization's Operational Knowledge. This article covers how to accomplish stage 2 in operational knowledge maturity scale.

What is Fit-Gap Analysis?

Fit-Gap Analysis is a methodology used to identify how well a system or solution fits a set of requirements and where the gaps are. It involves mapping out the entire customer experience or business processes to understand how well the current Salesforce Org configuration, or any solution for that matter, aligns with business needs.

  • Fit: Areas where the current system meets or exceeds requirements

  • Gap: Areas where the system falls short of requirements

Why is Fit-Gap Analysis Important?

Fit-Gap Analysis is crucial for any Salesforce Center of Excellence because it provides a structured approach to identifying needs and shortcomings. This is essential for prioritizing work items and ensuring that the Salesforce Org evolves in a way that is aligned with business objectives. It allows you to work towards:

  • Strategic Alignment: Business process mapping ensures that the processes you want to automate and support in Salesforce are in line with broader business goals.

  • End-to-end solutions: Fit-gap analysis encourages you to scope out the entire process and user journey, thus allowing you to solution against the full To-Be picture.

  • Full scope of stories: The ‘gaps’ identified through diagramming result in a complete scope of user stories, and no path is left forgotten. You end up delivering complete solutions.

What is Universal Process Notation (UPN)?

Universal Process Notation (UPN) is a straightforward yet robust diagramming technique used to capture a wide range of workflows. The foundation of UPN lies in its simplicity: a single type of building block that represents an activity, augmented by flowlines indicating sequence and connections between steps. Each block in a UPN diagram answers the key questions that define an activity within a flow:

  • What? (the activity itself)

  • When? (the timing or sequence)

  • Who? (the responsible party)

  • With what? (the resources or tools used)

  • Why? (the outcome or purpose)

This focus on capturing verifiable outcomes sets UPN apart, ensuring that each step within a process is purposeful and measurable​.

To learn the full notation and best practices with Universal Process Notation, read this guide.

Why is UPN essential for fit-gap analysis?

In order to do complete, detailed fit-gap analysis and identify all the requirements, you need to work against clear, detailed, well-scoped project documentation.

What truly sets apart UPN from other diagramming notations is the emphasis on capturing distinct, verifiable outcomes of each process step. More on that here.

Consider the UPN diagram below for configuring a quote:

It is clear, from every step, what the success criteria are, what features are used at each stage of the journey, who performs the action, and when. Therefore solution gaps become rather obvious when:

  • we don't have an existing solution (resource) to support a given process step

  • we had to create a custom process or automation

Implementation Guide

Prerequisites

Step 1A: Capture business requirement against both customer journey and business process steps

In Elements, a business requirement is a high-level statement outlining what the business needs to achieve its goals, focusing on the why and what aspects of a project or process. It typically reflects the broader objectives and desired outcomes for the organization.

If you use Elements to capture both your customer journeys and business process diagrams, then you should capture the business requirements in the following way:

  • First, against the customer journey step / experience that needs to be improved or implemented, capture the business requirement record stating what sort of experience the business wants to bring about, why, and how it will define success.

  • Then, open your business process map. Find the process diagram that will deliver that customer experience. Capture the same requirement against the relevant step in a process diagram.

When you have hierarchical diagrams, the question arises - at what level to capture the business requirement?

The general rule is that the business requirement is best captured NOT against the detailed business process, but against the parent activity in the diagram above.

For instance, the process for 'Processing customer enquiry' may involve a lot of detail, from routing and assignment rules, to preliminary investigative steps, concluding with notifying customer about how their issue will be processed. But the business requirement might be 'Capture and route cases to appropriate agents' and encompasses all of those steps.


Step 1B: Capture business requirement against business process steps only


If you used Elements to only capture your business processes, for instance to work on internal productivity improvements (automations to speed up the process, reduce mistakes, increase volume of sent emails, etc.), then simply capture the business requirement against the relevant step in the business process.

When you have hierarchical diagrams, the question arises - at what level to capture the business requirement?

The general rule is that the business requirement is best captured NOT against the detailed business process, but against the parent activity in the diagram above.

For instance, the process for 'Processing customer enquiry' may involve a lot of detail, from routing and assignment rules, to preliminary investigative steps, concluding with notifying customer about how their issue will be processed. But the business requirement might be 'Capture and route cases to appropriate agents' and encompasses all of those steps.


Step 2: Select and inspect child diagrams activity by activity

At this point you have captured the business requirement records against the high level steps in your business processes. They represent capabilities and business outcomes you wish to unlock.

But for detailed implementation you need to capture another asset: user stories.

In Elements, a story is a brief, user-centric description of a specific feature or functionality needed by a user to deliver a specific outcome.

Whereas business requirements are captured against the higher-level diagrams, where each step represents a wider business activity, stories are captured against child diagrams, which are more detailed and capture granular user experiences.

Step 3A: Capture user stories manually from activities

Click on the activity in the business process diagram. Then either from the context menu, or the right panel, select option to 'Add change'. From the menu select 'Story'.

Capture the desired story from the activity box. Capture:

  • what needs to happen?

  • why?

  • who is performing the activity?

  • what are the acceptance criteria for a solution to be considered fit for purpose?

It is worth noting that the UPN activity box, when captured correctly, mimics the format of a user story. That is why UPN has sometimes been referred to as 'visual story mapping'.

Step 3B: Capture user stories automatically with GPT

Pre-requisite: This capability is available with a separate add-on product called 'ElementsGPT'

Elements has capability to generate stories from business process diagrams drawn in UPN notation. It can save you and your team hours of tedious work, enforce standardization and improve the documentation quality passed to developers and admins.

However, the quality of the generated stories is proportionate to the quality of the diagrams. And if you are new to UPN, you first need to get used to the requirements of the notation.

First, get familiar with those two resources:

Then watch the quick tutorial below to learn how to get the most out of story generation:

Step 4: Review the captured scope with stakeholders

At this point you have desired business requirements captured against higher-level process diagrams, and user stories captured against the lower-level process diagrams. But depending on the scope of your project and number of diagrams in the single hierarchy, you might have captured a lot of changes to be made.

In order to review your work at-scale you can either:

  • Inspect processes activity-by-activity with the stakeholders. Just click on the activity box (while in view mode) one by one, and show the captured stories in the right panel.

  • Run a report titled 'User stories captured against this diagram' and then include all lower level diagrams in the scope of the report. We will generate a list of all user stories, with all standard and custom fields, with information which diagrams and process steps they are related to.


Step 5: Authorize To-Be scope of changes

Whether you are performing fit-gap analysis for the client (consulting engagement) or internal stakeholders, there are times when disagreements about scope and expectations will occur. This is especially common in large projects which can take months to complete and there is significant time delay between stakeholders participating in workshops and then receiving the solution months later.

In order to avoid unpleasant surprises, and more importantly to have a way of proving that what was delivered is what was agreed, you can use the authorization function within Elements.

This allows an editor on a diagram to specify who are the 'authorizers' across the diagrams, and then submit a diagram for authorization. An uneditable, view-only copy of the entire diagram hierarchy is created but with ALL the linked information (like stories and business requirements).

Authorizers can then review each diagram in detail, including raised changes. And if they agree with the scope of work, they can simply authorize the diagram. That leaves a permanent record that can be traced in the future.

Did this answer your question?