1. Creating Visual Process Maps

2.2 Creating Visual Process Maps
LOs: [2b]
A process map is a visual description of how work moves from one step to the next. It helps you see the current workflow clearly before you try to improve it, because a process that feels simple in your head can hide delays, handoffs, and repeated decisions when you write it out.
As you saw in 2.1, you first need to identify repetitive and error-prone tasks. Building on that work, a process map shows where those tasks appear in the workflow and how each step connects to the next. This makes it easier to compare the current state of the process, which is how the work happens now, with the future state, which is how you want the work to happen after automation.
A good process map usually shows the order of steps, the person or tool responsible for each step, and the point where a decision changes the path. Even a simple map can reveal that a task is delayed because one person must wait for another person to finish a separate step. Once you can see that pattern, you can think more clearly about where automation can remove friction.
The course materials point to common automation flows such as moving data between applications and using conditional logic. Those examples make process mapping practical because you can draw the sequence of actions before you build it. For instance, if information must move from one form to a second system and then trigger a follow-up message, a process map helps you show both the current manual path and the future automated path.
Process maps do not need to be complex to be useful. The goal is to make the work visible so you can discuss it, improve it, and test whether your planned automation matches the real process.
As you read, consider how a process map can help you notice steps, decisions, or handoffs that are easy to miss when you only describe a workflow in words.
Attribution
Title | Author | Source | License
PRDV000 Unit Readings | Saylor Academy | https://learn.saylor.org/ | CC BY 4.0

OUTPUT LICENSE: CC BY 4.0

## 2.2 Creating Visual Process Maps
LOs: [2b]
A process map is a visual diagram that shows the steps in a workflow from start to finish. It helps you see how work actually moves, where decisions happen, and where delays or handoffs occur. When you can see a process clearly, you can improve it before you automate it.
As you saw in 2.1 when identifying repetitive and error-prone work, not every task should move straight into automation. A process map helps you test whether a process is stable enough to automate and whether the current way of working already contains unnecessary steps. Mapping also helps you compare the current state of a workflow, meaning how the process works now, with a future state, meaning how you want it to work after improvement or automation.
A useful process map includes the trigger that starts the work, the steps that follow, the person or system responsible for each step, and the points where a decision changes the path. For example, if a marketing assistant receives a form submission, checks whether the lead is complete, and then sends the lead to sales, a process map can show each action in order. If missing data causes the lead to pause for review, that decision point should appear in the map.
A visual map is helpful because different people often describe the same workflow in different ways. One person may remember the main steps, while another remembers the exceptions. By drawing the process, you create a shared view that makes discussion easier and helps you spot gaps. That is especially useful when a process involves more than one person or more than one application.
As you read this section, think about one workflow you know well and ask how it looks in its current state, what the future state should be, and where the biggest handoffs or delays appear.
2.2: Creating Visual Process Maps
This reading supports Unit Learning Outcome 2b.
A process map is a simple visual showing how work moves from one step to the next. You use it to understand what happens now, and you use it again to design a better way for the work to happen later. As you saw in 2.1 when you identified repetitive tasks in your work, spotting repeated activity is only the first step; mapping the process helps you see where that work starts, where it slows down, and where it may not need to happen at all.
Why process maps matter
A current-state map shows the workflow as it exists now. It helps you see the real path of a task, not the path you think it follows. A future-state map shows the workflow you want after improvement. It lets you plan changes before you build an automation, so you do not automate a bad process.
Current state: the workflow as it happens now
Example: An online request form goes to a shared inbox, then a team member copies the details into a spreadsheet, and then a manager reviews it.
Best Use: Use this when you want to understand delays, handoffs, and duplicate work.
Limitation: People often describe the process as it should work, not as it actually works.
Future state: the workflow after improvement
Example: The same request form sends data directly to a database, and the manager only reviews cases that need approval.
Best Use: Use this when you want to reduce manual steps or remove unnecessary approvals.
Limitation: A future-state map can fail if it ignores policy, staff workload, or tool limits.
How to build a simple process map
Start with a clear beginning and end. Then list each step in order. Keep each step short and specific. If a task passes from one person or system to another, draw that handoff clearly. If a decision changes the path, mark it as a decision point.
Step 1: Define the scope
Example: You may map only one task, such as onboarding a new client, instead of an entire department.
Best Use: Use a narrow scope when you want a map that is easy to understand and improve.
Limitation: A scope that is too narrow can hide upstream or downstream problems.
Step 2: List the actors
Example: The actors might include a customer, a team member, a manager, and a software system.
Best Use: Use actors when a task moves between people and tools.
Limitation: If you leave out one actor, the map may look simpler than the real workflow.
Step 3: Show decisions and handoffs
Example: If a form is complete, it moves forward; if it is missing information, it returns to the sender.
Best Use: Use decision points when a rule changes what happens next.
Limitation: Too many decision points can make the map hard to read.
In a small business, a process map can reveal that an invoice is checked by three people before payment, even though only one review is needed. In a school office, a map may show that a student request moves through email, a spreadsheet, and a printed form before anyone acts on it. In both cases, the map makes hidden work visible, which helps you decide what to keep, what to simplify, and what to automate.
From current state to future state
When you compare the two maps, ask what must stay, what can move, and what can disappear. A good future-state map is not just faster. It is also clearer, easier to follow, and more reliable for the people who use it.
Job-ready Tip: Start with one workflow
When you practice process mapping for work, begin with one task that happens often and causes confusion. A simple map is easier to review with a team, and it gives you a strong base for later automation design.
As you read this section, ask yourself: if you mapped one repeated task from your own work or study life, which step would you remove, which step would you keep, and how would the future-state map make the process easier to follow?
Sources / Further reading
(Authored by Saylor Academy, CC BY 4.0)
Estimated reading time: 6 minutes
2.2: Creating Visual Process Maps (covers 2a, 2b, 2c, 2d)

Callback before_footer in local_aigrade component should be migrated to new hook callback for core\hook\output\before_footer_html_generation
  • line 7225 of /lib/moodlelib.php: call to debugging()
  • line 7292 of /lib/moodlelib.php: call to {closure}()
  • line 71 of /lib/classes/hook/output/before_footer_html_generation.php: call to get_plugins_with_function()
  • line 987 of /lib/classes/output/core_renderer.php: call to core\hook\output\before_footer_html_generation->process_legacy_callbacks()
  • line 154 of /mod/book/view.php: call to core\output\core_renderer->footer()