Are you planning a new Service 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 Service and is also often referred to as (process) flowchart, business flow diagram or workflow model/diagram. It helps with depicting the steps of a 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 BRYTER module 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 manager for a Service built with BRYTER to become more effective. The clearer and detailed the process map, the clearer your next steps of prototyping and developing your solution will become. A process map also helps highlighting 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 Service into different modules and if or how many databases and data views you require.
How to create a process map (general)
You can create a 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 a Service 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 represent 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 stabase, 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 outout from a process step.
In BRYTER, this would most likely be any type of input node (these could also be reresented 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:
This process mapping approach can also be used for BRYTER Services - especially Services containing several modules and databases as explained below.
How to create a process map for a BRYTER Service
Services like an HR Absence Tool or a Client Due Diligence (CDD) Assistant require several modules and require case databases to be set up. They also cater to several different stakeholders. In the HR Absence Tool, both employees and their line managers use different modules to raise vacation requests which are subsequently approved or rejected while all inputs and decisions are stored in a case database. Similarly, a Client Due Diligence Assistant could be used by a General Counsel (GC), the Due Diligence team, and a business user or assistant who starts with an initial assessment of a potential client.
To illustrate the required components of this Service, we suggest using the following symbols and create a high-level process map that displays the case databases, modules and the stakeholders using them in a swimlane diagram:
Symbol or shape
|Type or name||How and when to use|
|BRYTER Module||This symbol represents a standalone BRYTER module. This module can be connected to another module or generates or reads gathered information out of a database or|
|BRYTER Case database||This symbol represents a BRYTER case database.|
|BRYTER Data views||This symbol represents a BRYTER data view that is derived from a case database.|
In the CDD example, the business user or assistant uses a first module that helps to understand which type of CDD check is required for client XYZ. Based on this initial result, the case for client XYZ is either
- completed (simplified CDD check sufficient)
- prompts the business user to an enhanced CDD check in a separate module
- escalates the case to the Legal team if an escalated CDD check is necessary
- informs the General Counsel if any Red Flags have been detected and escalates the case to the GC for further assessment in a separate module.
While all these modules and the steps required within are completed, the gathered data flows into two separate case databases:
- one case database is used to gather all cases and contained data can be updated by all stakeholders
- one case database only contains red flag cases and can only be updated by the General Counsel
The starting point thus differs across the stakeholders but generally starts with the business user starting the first module and CDD check for a new case. It ends with either the result of the first assessment, the escalated check and guidance or the red flag report.
The steps and modules above could be depicted as follows - including some additional data views so GCs and the Legal Team can easily keep track of all cases - in a very high-level process map. The black arrows are used to explain how different modules are connected whereas the blue arrows indicate the direction information or values or flowing into or from case databases:
💡 Before sketching your process map, ensure that you know where the process starts and ends. How (and by whom) is the process triggered and how does the last step look like?
💡 Start with a very high-level, simple process map. For a Service with several modules, concentrate only on the sequence of the modules and how they might be connected with databases or redirect results.
💡 The process map is not your final BRYTER module! Keep it as lightweight as possible by only leaving in the necessary details. You do not need to include every email action or inputs. Focus rather on the parts in your modules that represent the key 'junctions' and lead to very different outcomes (next steps/modules/documents/guidance)
💡 Think about all the stakeholders that are involved in the process. Consider using a swimlane process map to clearly show which modules or steps in the module will be used by whom.