This article will help:
👤 if you are an author or project manager tasked with building complex applications
📶 if you are looking for a beginner to intermediate level introduction to the topic of process mapping
🔠 if you are in phase 🇩 Map processes of the BRYTER ABC
ℹ️ if you want to understand HOW, WHY, and WHEN to use create a process map and WHO should be involved (author, project manager, and subject matter expert)
Are you planning a new use case and feel like you would benefit from an overview of the workflow or process you would like to automate? Process mapping can help you!
What is process mapping?
A process map helps you describe the flow of your existing processes and tasks associated with your use case idea. Process maps are also often referred to as (process) flowcharts, business flow diagrams, or workflow models/diagrams. It helps with depicting the steps of work activity and shows who and what is involved or how data is flowing, i.e. is data collected, is data transformed or transmitted to a specific stakeholder and how is the data outputted.
When mapping a process - on paper or with a tool - the creator of the map draws a box for every step or action and connects them with arrows to indicate the direction and/or condition of the next process step.
Why is process mapping useful?
Process mapping allows authors or project managers to get a better sense of the use case idea and will require heavy involvement from the idea giver or subject matter expert. The clearer and more detailed the process map, the clearer your next steps of prototyping and developing your solution will become. A process map also helps highlight which improvements could be made to the status quo and indicates which people are involved at which step. With a process map, you can save time building your prototypes because the setup is clearer and you understand how to slice your Application into different modules and if or how many databases and data views you require.
When would you map processes?
Whenever you start a new project based on a new use case idea where several stakeholders are involved and when you are unsure where to start prototyping in BRYTER or how to best approach your use case idea.
Who is involved when mapping processes?
If the author or project manager is not simultaneously the person who came up with the use case idea, subject matter experts should be involved. This could be a lawyer who suggested the idea or an assistant or anyone tasked with the responsibility to oversee the entire process or the quality of the final delivery to the end-user. This subject matter expert is usually best suited to talk the project manager through each phase, task, or exchange of information required.
How to create a process map (general)
You can create the first draft of a process map with pen and paper, using Powerpoint or one of many diagram or whiteboard online tools (Miro, Mural, Visio, Lucidchart, diagrams.net, and many more). Elements or steps in a process are represented with a specific symbol or visual depiction such as a rectangle to indicate an activity or process or a diamond shape to represent a decision that needs to be made. There are a handful of commonly used symbols that are explained below and some additional visual representations of how you could use BRYTER symbols to create an Application map including modules, case databases, and data views.
The below shapes are commonly used symbols in a process map:
|
Symbol or shape |
Type or name | How and when to use |
 |
Rectangle/Step/Activity | This symbol represents a certain step or an activity within the process. In BRYTER, this could represent an entire module or |
 |
Decision | This symbol represents a decision that has to be made between process steps and is used when there are several branches or a 'fork' in the process. |
 |
Start/End/Result | This symbol indicates either the start of a module or the end. In BRYTER, this would be likely reflected with a result node. |
 |
Arrow/Connector | This symbol is used to connect two steps ot a step and a decision. It represent also the direction of the flow or the direction of data passed through. |
 |
Document | This symbol typically represents a document or data/information that can be read by people. In BRYTER, this would most likely be a document creation node. |
 |
Multiple documents | This symbol represents a set of documents. |
 |
Database or Storage | This symbol indicates where the data of your flowchart steps are stored. In this representation of a database or storage, data can be accessed in any order. In BRYTER, this would most likely be an integrated external database or a case database. |
 |
Data (input or output) | This symbol shows the inputs and output from a process step. In BRYTER, this would most likely be any type of input node (these could also be represented with the manual input symbol) or a database action node. |
Using these steps, you can draft a process map or simple flowchart, for example for the steps and decisions required to make a coffee:
| Process map or flow chart | Description |
 |
This example illustrates some of the symbols above:
|
💡Best practices
Depict the start and end point
Define the trigger that sets off the entire process: What happens or what must happen at the very beginning. Clarify in which environment (Where) and how your process would usually begin. Is the trigger typically an incoming email in your Outlook, a phone call, or a signed contractual agreement in an eSignature tool?
Now, skip to the very end and define which outcome/output actually concludes the process. Figuring out what the final result should look like and how it will be delivered to the end-user, for example as a downloadable report in PDF format, as a redirect to another website, or as a data view, can be very useful to depict the steps required that lead to this outcome or output.
List all participants/stakeholders
Make a list of all people or stakeholders who are involved in the entire process or at some point in between and need to provide input, confirm steps, or be informed. Mark stakeholders as internal, external, or belonging to different teams.
This will help when you are planning a swimlane diagram or later when you blueprint your application to find out how to manage access to modules or data views.
Break the “in between down” in smaller steps
After you have defined the framework, the starting and ending point along with the main participants of the process, it's time to map the "in between". You can start either from the starting point and depict which steps are typically required in between the start trigger and the final result or you deduce the steps that lead to the final outcome and end point of the process.
At this stage, focus only on the "typical" process steps or scenario, i.e. which steps are required in 80% of all cases. Outliers can be mapped at a later stage or the Subject Matter Expert might decide to exclude these cases altogether and rather guide the end-user to take advantage of an individual consultation.
Include data flows and documents
After all steps are mapped, you can now define which information is necessary to continue from each step to the next. This exercise can also Is some information required at a later stage? Which information needs to be pulled into a document or final report?
❗️Pitfalls to avoid when you start to map your process
Focusing too early on exceptions and errors
One of the most common errors is diving into improving a process before you have finished mapping it. Participants often want to dive into exceptions to the rules and forget about the bigger picture and workflow.
Not including all participants in the process
Always remember that the best people to tell you what steps are required or which issues are typically faced are the ones who use this process or are part of it. They are also the people who have the most at stake.
Avoiding the messy sketch
It‘s okay if the first process map looks temporary and sketchy – people will feel more okay about adjusting and changing it later.
Not collecting examples and document
Don‘t forget to collect examples of all documents associated with the process. These could be forms, policies, checklists, templates, FAQs, and any document or file that is typically used during the process.