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.
Why run a process discovery workshop?
Running a process discovery workshop is absolutely fundamental because automating a process without fully understanding its "As-Is" state can lead to costly failures and inefficiencies.
By thoroughly examining how things are done today, uncovering gaps, inefficiencies, and pain points, the team gains crucial insight into the current challenges.
This understanding provides a solid, informed foundation for designing an optimized "To-Be" state, ensuring that automation addresses real issues rather than reinforcing flawed or inconsistent processes, reducing the risk of misalignment and rework.
When to run a discovery workshop?
A business process discovery workshop is highly recommended when an organization or a team:
Does not have any formalized documentation on how they perform their function
All new employees are onboarded through observing/ following existing team members
Different members of the team have different ways of doing their job
All of these are signs of the lack of standardized approach to performing a job. And any attempt to customize and configure systems to support those business functions will ultimately fail, because you cannot automate or streamline something which isn't standardized.
Prerequisites
Understanding of UPN diagramming methodology
Process-led-change product license
Implementation guide
Step 1: Gather business stakeholders
The first step is to gather the right business stakeholders in the room. This should include all the key people who perform a given business function. For instance, if you are mapping the sales process, you should get the sales team, and not members of other functions like finance or marketing.
If your organization is very large, and a business function has dozens or hundreds of employees performing the same job, then you should focus on key managers who are closest to the day-to-day operations.
For discovery workshops, it is recommended to avoid just relying on a single senior manager for a business function. That is because they tend to have a view of 'what should be happening', which is often different from reality on the ground.
Since the purpose of the workshop is to discover the current 'As-Is' process with all its inefficiencies, the workshop participants should primarily be people who are involved in day-to-day execution of the job.
If you have identified owners and stakeholders on key capabilities and metadata, you can run a stakeholder report in your metadata dictionary to produce a list of initial stakeholders.
Step 2: Define a scope
The success of a discovery workshop relies on establishing very clear scope of the discovery.
For instance, trying to discover the 'entire' sales process in one session may be too ambitious of an exercise. It would require mapping out multiple processes, from lead qualification, opportunity development, to forecasting, upsell identification, and many others. This could easily lead to multiple topics and threads being followed at a time.
Instead, specify very clear trigger and outcome, start and end point for the process you wish to discover. You should put two flowlines on the canvas that clearly articulate the start and end point of the process in focus.
That will help focus the conversation with the stakeholders. It will also allow you to rule which discussions are on topic and out of focus during the session.
Step 3: Establish and communicate workshop rules
Running a successful discovery workshop requires abiding by very clear rules of engagement. These rules should be outlined in the invitation email and at the beginning of the workshop.
Here are our recommended rules:
Everyone's input is welcome
One at a time talking
Silence = agreement
Map 'happy route' first
Watch the video from Calvaria, one of our partners, that articulates all of these rules in a live workshop setting:
Step 4: Choose a scenario
The #1 challenge in a process discovery workshop is the 'our processes are too complex to capture as a linear diagram'.
First, you can assure participants that diagrams don't have to be linear. Secondly, in most cases the processes are not as complex and scenarios that different from each other as it seems!
The best approach is first to:
List all the different scenarios as different 'inputs':
Agree to take one, ideally the simplest 'happy path' scenario first to map out.
Once you are done, you can take another scenario and reflect with the group how the baseline process changes with this new condition.
Step 5: Create the empty boxes (seriously!)
Empty page can be intimidating. People often don't know where to start talking through their process. Furthermore, there is a tendency to go straight into explaining the sequence of steps someone takes through the process. That can lead to 'tunnel vision' and focusing on just one set of activities.
Instead, start by creating a bunch of empty activity boxes on the screen (at least 12) and ask your participants to list all the activities or tasks they do, irrespective of sequence or who does them.
Why start with empty boxes?
Weirdly, people often forget about all the activities that they perform in scope of a job. They remember thinks they do daily or weekly very well, but forget activities they only do occasionally.
For instance, if most cases going through a support process are fairly simple, then service agents would likely remember all the steps they perform regularly around them. But if a complex case only happens once in a while, and requires a different set of steps, this is likely to be missed.
Psychologically, people will feel inclined to fill out all the boxes on the screen. The first 5 to 10 will come very naturally and quickly to participants. And you will see the struggle and fall silent after a while. It is good to embrace the silence and keep probing participants about 'what else?' they tend to do in scope of the process.
You will discover that despite the challenge, at least a few non-obvious activities will be listed after a while.
If people cannot think of anything else they do within few minutes, you can delete the unfilled boxes and move on to next step.
Step 6: Document Why? outcomes
The most powerful and challenging aspect of mapping good UPN diagrams is capturing clear, distinct, and verifiable outcomes on activities.
For the process to reveal useful and actionable information, we need to understand not only what happens, but why? Consider the example below:
It is common for people to think of outcomes as past-tense of the activity itself, e.g. 'Log a case' -> 'Case created'. But that does not reveal to us the business value of why do it in the first place (are we just logging cases for case-sake?) nor what are the success criteria of doing so.
Challenge your workshop participants with following questions to help reveal the clear, distinct, and verifiable outcomes:
What would happen if we didn't do the activity? What would we lose?
How would I know that Sean performed that activity? What would be the proof?
What's the difference between performing this activity well and poorly? What would be the difference in the final result?
Step 7: Order the activities
At this point you should have a series of unconnected, active verb-based activities with clear, distinct and verifiable outcomes.
Ask the participants to now order them in a sequence. What happens first? What happens next? Connect the outcomes to the boxes to create a connected, sequential diagram.
It is possible that some activities are done in parallel or follow OR logic (e.g. if case is urgent, we do X, if it isn't we do Y). In that case, consider these diagramming rules in UPN.
Review of AND / OR logic mapping
Review of AND / OR logic mapping
One of the most common questions we hear is 'where is the decision diamond?' In flowcharts, it is a symbol that represents a decision point or a question that needs to be answered. UPN supports only one shape, hence there is no diamond. So what now?
An activity can have multiple flowlines coming out of it.
If those flowlines have different origin points (they do not overlap), it represents different outcomes and different paths a process can follow.
An activity can have multiple flowlines coming out of it.
If those flowlines originate from the same point, it represents the same outcome and parallel paths the process will follow. In this case, the same outcome triggers 3 different subsequent activities simultaneously
An activity can have multiple flowlines coming into it.
If those flowlines come at different target points, it represents separate triggers for an activity. In this case, any of the 3 flowlines represents an input that on its own is enough to start the next step.
An activity can have multiple flowlines coming into it.
If those flowlines all arrive at the same target point, it represents multiple necessary conditions for an activity to start. In this case, all 3 activities must be successfully performed for the next activity to begin
Step 8: Document Who? and How?
Now that you have a very good backbone of your business process flow, ask the participants to specify who actually is involved in those process steps. This is where you add resources to the process activities.
While the focus is primarily on Who is responsible for performing the activity?, you should also consider adjacent roles, like:
Who is consulted?
Who needs to be informed?
Who needs to authorize this decision?
This information is rarely considered in the beginning, as stakeholders focus on what they do, but this questioning can reveal a lot of additional stakeholders and implied communication activities.
Read more on RASCI responsibility matrix here.
While you are capturing the resources on activities, you should also ask 'How are you performing those activities?' The focus is on discovering systems (Salesforce, Gainsight, LinkedIn, Spreadsheet etc.) and specific features (Opportunity object, Account object etc.) utilized for each activity.
The result should be a diagram that looks somewhat like this:
Tip: consider recess
While you can continue your discovery workshop beyond this point, our experience suggests that discovering and mapping out a single process with a group of stakeholders is likely to take anything between 1 to 2 hours. At this point, most participants will be already tired.
Taking a break will allow you, and other participants, to regain energy but also will give you an opportunity to consider cleaning up your process and organizing it for better clarity.
Step 9: Organize boxes together into categories and create child diagrams
Remember the rule
UPN diagrams should be understandable to anyone reading them, even if the creator isn't there to explain it.
The idea behind UPN notation has always been to produce diagrams that are understandable to any audience, without the need for training or legend into meaning of different shapes or colors.
Psychological research also tells us that the more complex the picture, the more variables people are presented with, the more confused they become.
At this point in your discovery workshop, chances are that the diagram you have captured with all the activities and outcomes could be fairly extensive. Like the one below:
With 25 activity boxes on the screen, the diagram, while laid-out sequentially, is too big to read at once. Users cannot comprehend it without zooming in extensively, and in a live-workshop setting, where you might need to share your screen or present it using a projector, the diagram will be too large to read from the back of the room.
Try to organize and group activities that are related to each other. For instance, select all activities that use the same object or system and send them to a separate child diagram.
If all activities are done in a single system, and even on the same object, look out for delineation events. For instance, you might capture all activities related to initial case assessment, before escalation, as a separate diagram, and activities that happen after escalation as another.
Tip
Business process diagrams are most readable on a screen when there is no more than 8-12 activity boxes on the screen.
The result should be a cleaned-up, hierarchically organized set of diagrams that looks somewhat like this:
Step 10: Capture sentiment, pain points, opportunities for improvement
At this point you have captured the As-Is business process, for a given scenario, in its entirety. Now is the time for analysis!
Encourage your workshop participants to comment on what works and doesn't work about the process. There are two ways you can do that:
Capture ideas as post-it notes
You can encourage workshop participants to leave post-it notes around the diagram to highlight their paint points and ideas for improvement.
You have to agree on the methodology, like use of color. For instance, red for pain points, green for ideas or different color for each person.
Once everyone has added their sticky notes, you can filter them on the screen to only show post-it notes added by specific person, of specific color, or specific tag.
Capture structured feedback with data tables
Custom data tables can be attached to each step in the process, enabling the structured capture of detailed information, such as pain points, ideas for improvement, and expected business KPIs. These tables also function as smart, contextual surveys, allowing workshop participants to provide input in a structured manner.
Tip: You can either capture data table records in a live-worksop setting OR ask participants to fill it out asynchronously in their own time.
Proposed data tables:
Data table for capturing pain points
Data table for capturing pain points
Pain Point Description (Text)
Purpose: Provides a brief description of the pain point to clearly understand the issue.
Impact (Picklist)
Purpose: Captures the severity of the pain point on the business.
Values: Low, Medium, High
Frequency (Picklist)
Purpose: Indicates how often the pain point occurs to help prioritize resolutions.
Values: Rarely, Occasionally, Frequently
Employee Feedback (Text)
Purpose: Direct comments from employees regarding the pain point, offering insight into the issue's nature.
Priority (Picklist)
Purpose: Helps to prioritize the pain points based on urgency and impact.
Values: Low, Medium, High
Data table for capturing ideas
Data table for capturing ideas
Idea Description (Text)
Purpose: Provides a brief summary of the improvement idea, allowing employees to suggest what a better process or solution would look like.
Expected Impact (Picklist)
Purpose: Captures the perceived positive impact of the idea from the employee's perspective, helping prioritize which ideas might be most beneficial.
Values: Low, Medium, High
Employee Suggestion (Picklist)
Purpose: Identifies whether the idea was suggested by employees or management, ensuring transparency about the source of ideas.
Values: Employee, Management
Step 11: Map out another scenario
At this point you have completed a full capture and analysis of the As-Is business process for a given scenario. But remember, there are 'other' paths that might still need to be captured.
Review the other scenarios that were noted in the beginning. Encourage the participants to go through the captured process and reflect on how and where the process changes.
Example: you mapped out and analyzed the process for capturing and analyzing customer cases that are auto-scored as standard priority. You can then look at cases which are logged as high-priority and reflect if any step in the process is any different.
In case of differences, you can:
Add additional, conditional steps in the process
Add notes to activity boxes to provide some explanation and clarification on the subtleties between handling case type A and case type B