Blazing a New Process Mapping Trail
A New Trailhead
Salesforce introduced the Business Process Mapping Trailhead module, covering a broader and deeper context than Process Mapping for Business Analysts. The new module connects business analysis with solution architecture through process mapping. It takes a deeper dive into creating process diagrams, guiding a business analyst or architect on the relationships between process steps, inputs, outputs, and resources. The trail also covers the purpose and scope of a process map and stakeholder engagement.
Stakeholder understanding of processes through insightful process maps starts at “Business Process Mapping.”
Solution Architecture Needs Business Analysis
The Understand the Value of Business Analysis unit highlights the need for business analysis as a prerequisite for strong solution architecture. Business analysts determine an organization's solution requirements, resolving ambiguities along the way. This reduces reworks later in the solution development process.
Requirements specify the outcomes desired from a solution. Processes fulfill most of these outcomes. Development stakeholders need to understand these processes to:
Inform the data model
Determine performance considerations and metrics to collect
Identify where business processes can change to improve solution performance
Process maps provide a single source of truth about an organization's processes. When a business analyst hands off a process map to a solution architect, it advances development to the design stage with a thorough understanding of the organization's processes.
A Fresh Look at Universal Process Notation
“Business Process Mapping” illustrates process mapping with universal process notation (UPN), a simple yet powerful diagramming technique.
The Understand Universal Process Notation unit contrasts flowcharts with universal process notation. A flowchart shows a process flow, emphasizing decisions and little else. Each step in a UPN process map answers the essential question:
Who does what, when, why, and how?
A process map consists of process diagrams, each showing steps represented as activity boxes. An activity box contains:
A label specifying the activity - what happens in the step does
One or more resources
Who or what performs the activity
An optional RASCI tag showing a human resource’s role in the activity
Responsible: performs the activity
Accountable: has Yes/No/Veto power over the activity
Supporting: supports the Responsible person in executing the activity
Consulted: provides feedback and can contribute to the activity
Informed: needs to know of the activity
An optional link drilling down to another diagram showing how the activity works
Arrows connect activity boxes on a diagram, showing the process flow. The model below shows an activity box with an input arrow triggering the activity and an output arrow showing why the activity happens:
Drill-downs link activity boxes to diagrams, connecting them in a hierarchy forming the process map.
Five UPN Principles
“Understand Universal Process Notation” concludes with five principles for creating process maps:
Aim for no more than 8–10 activity boxes on a screen.
You can drill down from an activity box to the next level of detail.
You can attach supporting information to an activity box.
Access rights determine who can view and edit the diagram.
You can see change history at the diagram level.
When a diagram exceeds 8-10 steps, it can become difficult for stakeholders to follow. Drilling down can reduce a diagram’s steps. Purposeful Architect will cover reducing steps for process diagram clarity and stakeholder engagement in a future article.
Linking information to an activity box makes reviewing the diagram more productive. A stakeholder can get supporting information with a click instead of searching around for documents.
Access rights manage who can edit vs. who can view a process map. Typically, a small number of qualified people edit the map to control map changes. Editors continuously update a process map as new requirements and other changes emerge. Maintaining a change history keeps track of who made what changes to the map’s diagrams.
Scoping a Map
The Create a Business Process Map unit outlines what to do before creating a process map.
First, determine and agree on the final outcome or purpose of the top-level process, answering its “why” question. Next, identify the input or event that initiates the process - the answer to its “when” question. The initiation and outcome define the execution scope of the process - its beginning and end. The steps between answer the “what happens” question.
The “Create a Business Process Map” unit makes the point:
It’s better to think about a business process in terms of its input and outcome rather than the application it takes place in.
Engage the Stakeholders
Answer the “‘who” question by identifying all roles to participate in the process. Each role should have at least one representative stakeholder.
Not all stakeholders need to participate in all mapping sessions. Lower-level processes become more specialized and detailed, requiring only stakeholders who represent the process resources. This makes the best use of stakeholders’ time.
Map for Success
The “Prepare to Create Your First Process Map” section starts with a Practice topic suggesting mapping a process outside of work, especially when process mapping for the first time. Making breakfast is a good test case to learn process mapping, as long as breakfast consists of more than an energy bar.
When introducing process mapping to an organization for the first time, start with a low-risk process having:
A narrow scope
A small number of stakeholders
Clear metrics
Success with a pilot map demonstrates the usefulness of process mapping, increasing the chances of adoption for larger processes.
The unit concludes with the three key questions:
What is the audience and scope for the map?
What’s the background, training, and experience of the audience?
Is the process for internal use, or will you share it with customers?
What level of detail is required?
How can you define each step so that it starts with a verb and has clear inputs and outputs?
Which resources (people, systems, other) are engaged in [each] step?
Clearing the Path with an Example
“Business Process Mapping” concludes with the unit See Business Process Mapping in Practice.
The top-level diagram, Lead to Revenue, shows a process converting an incoming lead into a customer and closing a revenue opportunity.
The top-level diagram’s first step drills down to a second-level diagram, Progress Lead. The second-level diagram shows the initial processing of the incoming lead, determining if it should be assigned to sales, maintained in a campaign, or discarded as a duplicate.
The first step of Progress Lead drills down to the third-level diagram, Create Lead. It shows the lead creation process based on the lead source, then creates a privacy record.
The example asks a good question, “How many levels to drill down?” It depends on several factors:
Complexity - Add enough levels of detail to remove all ambiguity.
Regulatory - If a process has compliance obligations, it needs to be very specific.
User Expertise - The less experienced the staff who are following the (new) process, the more prescriptive the processes need to be.
A Worthwhile Journey
This annotated process diagram shows the steps to prepare for creating a map:
The “Product Owner” resource is the organization’s person responsible for the solution. He or she works closely with the development stakeholders to define the scope and engage the other stakeholders.
Once the business analyst and product owner have defined the scope, selected stakeholders, and an area to map, they can organize a process mapping workshop.
The Process Mapping in Practice section advocates for live workshops as “far more effective than completing questionnaires or conducting individual interviews.” While a live workshop may seem like a lot of work, its benefits make it worth the effort:
A live workshop builds consensus in a group and generates ideas and quick wins for improving the process.
Because you’re developing the process diagram live in the workshop, you don’t need to interpret notes or photos of whiteboards when you get back to your desk to build the process diagrams.
It’s easier to get everyone to agree and sign off when participants see the process being developed and have a chance to give input.
As process mapping drills down into more detailed and specialized diagrams, smaller meetings with the subject matter experts makes mapping more efficient. In the Lead to Revenue example, all stakeholders would participate in creating the top-level and second-level diagrams. The third-level diagram Create Lead focuses on initially handling an incoming lead before it goes to sales. Only marketing stakeholders need to work on that diagram and its drill-down diagrams.
A successful process mapping workshop ultimately results in an unambiguous process map understood by all stakeholders. Each process diagram in the map has at most ten steps, making it easier for stakeholders to follow. Where necessary, steps link to supporting documentation. The best process maps keep stakeholders focused on the process rather than navigation and tracking down supporting information.
Salesforce has blazed a new trail into process mapping, going further into making process maps easy for stakeholders to follow and highlighting their benefits to architects and business analysts.