SOP-1: Map Business Processes

 

REVISION HISTORY

Version	Modifier	Date	Comments
1.0	Matias Fontecilla	2020-08-20	First publication

 

Description and Scope #

Processes can be mapped and annotated in several ways; there are several types of symbols to chose from and there is seemingly no limit to the amount of information that can be annotated onto them. The following procedure offers guidance on how to create process maps in accordance with our organization’s BPM Standards, including which kind of information to capture and which shapes to use in which circumstances.

This process begins at the event of defining a process’ scope and ends when the process has been completely modeled.

Purpose #

Understanding process maps is an important skillset to have within our organization as they are the predominant tools we use to document and communicate our standard operating procedures.

These diagrams are to be used by all levels of the organization. It is therefore important to standardize our approach to minimize the time needed to train staff on how to read them and to ensure that all types of audiences can reap the maximum amount of benefits offered by maps.

Procedure #

Step 1: Define the Business Process and its Scope:

• Create a title of the business process: capture the whole process in the name to ensure the reader can visualize the business process when they read the title.
• Find under which Process Category and Group the Process would fit best into, and award it a unique ID.
• Define the process scope by deciding where the diagram of the process will start and stop. Within these boundaries (start and end points) is where the business process steps will live.
  • Setting boundaries will also help validate that the Process is indeed a Process and not Process Group, Category or otherwise.
  • It may also help gauge if the process is large enough in scope to be broken down into sub-processes.
• Provide a Description & scope as well as Purpose, much like those documented herein. This will be the reader’s first interaction with the documentation; it must concisely explain why the process exists and what to expect to gain from reading it.
• Determine the intended purpose & level of detail required. This will influence which kind of information to capture and whether to use a descriptive or analytical modeling approach.

Step 2: Identify the Business Process Objective and Owner:

• Define the business process objective: concisely describe why the process exists, what it is intended for, and which results can be expected from it.
• Identify the Business Process Owner: Owners are accountable for the process’ effectiveness and efficiency, are knowledgeable about major issues that must be resolved, and can make decisions with regards to standardizing, automating, and redesigning processes for improvement and compliance needs. They are also responsible for governing over the process, including approving any documentation such as process models.
  • Note: If the process’ scope is large and it has sub-processes, these may also require owners, which may be different than the owner assigned to the process.

Step 3: Map the process:

1. Use the symbols, rules and naming conventions provided in the tables below.
2. Remember that a Process map is more than documentation for one instance of the process. When using a descriptive approach, aim to map the scenarios that occur 80% of the time (the standard). The remaining information is known as exceptions, which can be documented within description fields.
3. The steps should be drawn from left to right in the order in which they are carried out.
4. Use a swim lane map as it neatly presents which roles, organizational units and/or systems are responsible for carrying out the steps.
5. Connect the symbols with lines and arrows (named transitions) to show the direction in which the process flows.
6. To maintain readability and clarity of the map, aim to have a maximum amount of 15 shapes on the map. More than that is an indicator that
   1. the process should be broken down into one or more sub-processes
   2. the process’ scope (start and end) should be reduced

• the level of detail should be reduced

1. Note that the development of flowcharts is an iterative process. A timeline for finalization should be ascertained based on subject matter expert availability, as well as complexity of the process. Do not become discouraged if a map needs to be rebuilt several times, process discovery is not a simple task.

 

 

The following table breaks down the scope of chosen mapping symbols, their descriptions, rules and standard naming conventions.

Symbol	Description	Rules and Naming Conventions
Task	·       An activity that does not have sub-divisions (worth modeling) and transforms a set of inputs into outputs. ·       Typically, only one participant is performing all micro-steps within it E.g. For the task ‘Make Coffee’, only a barista is needed to get a mug, pour coffee, and add milk & sugar. ·       Divergences in how the task is performed generally do not affect the flow of the process in terms of needing to involve other participants or using other tools. E.g. While milk and sugar are optional, the barista is still making coffee.	·       Must begin with an active verb ·       A process may either have at least one task or sub-process
Sub-Process	·       An activity that has sub-divisions and transforms a set of inputs into outputs. ·       Typically, more than one participant is involved in the tasks within it E.g. For the sub-process ‘Prepare breakfast’, the chef makes the food and the barista makes the coffee. ·       Divergences generally do affect the flow of the process in terms of needing to involve other participants or using other tools. E.g. If the customer consuming the breakfast does not want coffee, the barista is not required.   Note: Differences between tasks and sub-processes can be abstract. It is at the process modeler’s discretion to choose whether documenting information as a sub-process, a task or into a description field would add value to the reader, as opposed to documenting the detail in a text field accompanying a task.	·       Must begin with an active verb ·       A process may either have at least one task or sub-process
Exclusive Gateway	·       A gateway controls divergences of sequence flows in a process. ·       An ‘Exclusive’ type acts like an OR statement. E.g. In the ‘Prepare breakfast’ sub-process, an exclusive gateway would ask the question ‘Does the customer want coffee?’. At least two transitions would flow from this (Yes and No)	·       Must be worded as a question ·       Only include gateways if the divergences happen at least 20% of the time, otherwise they can be noted in the task’s procedure. ·       Must have at least two transitions flowing from it ·       Each transition must be labelled (e.g. Yes, No) with Inputs/Outputs ·       Their viewing / modeling settings must be set to Annotation
Parallel Gateway	·       A gateway controls divergences of sequence flows in a process. ·       A ‘Parallel’ type acts like an AND statement. ·       They are used to show that a series tasks can be performed in parallel rather than sequentially. E.g. In the ‘Prepare breakfast’ sub-process, a parallel gateway would demonstrate that the ‘Make food’ and ‘Make coffee’ tasks can start at the same time.	·       Must be worded as a question ·       Must have at least two transitions flowing from it ·       Transitions do not need to be labelled ·       Their viewing / modeling settings must be set to Annotation
Start Event	·       Indicates the process’ starting point. ·       Usually denotes the most common trigger point. E.g In the ‘Prepare breakfast’ sub-process, the start event would be ‘Customer wants breakfast’ ·       Can also denote less common triggers as secondary starts.	·       A process must have at least one. ·       Must be given a name consistent with what triggers the process. ·       Only include secondary starts if they occur at least 20% of the time. ·       Their viewing / modeling settings must be set to Annotation
End Event	·       Indicates the process’ ending point, ·       Usually denotes the desired result and can reverse the process’ name as its name. E.g In the ‘Prepare breakfast’ sub-process, the end event would be ‘Breakfast prepared’ ·       Can also denote a non-desired result.	·       A process must have at least one ·       Must be given a name consistent with the process’ results. ·       Only include non-desired results if they happen at least 20% of the time. ·       Their viewing / modeling settings must be set to Annotation
Inputs/Outputs	·       A label that adds context to transitions ·       Most commonly placed on transitions exiting Exclusive Gateways E.g. In the ‘Prepare breakfast’ sub-process, an exclusive gateway would ask the question ‘Does the customer want coffee?’. At least two transitions would flow from this, each labelled with an input/output (Yes and No) to help visualize which path handles which scenario.	·       Must be a concise as possible to minimize occupied real estate on the map. ·       Their viewing / modeling settings must be set to Annotation
Swimlanes	·       Identifies process participants that are responsible for one or more activities in the process ·       Participants can be Roles, Org. Units, or Assets (e.g. Apps, software, servers)   Note: Any need to create new roles, org units or assets must be communicated so that they can be added to the most appropriate section of their respective libraries and in alignment with our data governance standards.	·       Participants must be taken from standard reference libraries as much as possible.
Shortcuts	·       Shortcuts to a common and standard task or process. ·       Eliminates the need to recreate the activity from scratch, including any associations and descriptions they may contain ·       For Process Shortcuts, this also shortcuts to their maps, thus eliminating the need to remodel those as well.   Note: most definition tasks and sub-processes to these shortcuts are to be stored and maintained in a central location within the repository. Any additions should be communicated so that they can be added and reused by collaborators.

 

 

The following table breaks down the scope of chosen artefactual symbols that are linked to process maps. For each of these, their viewing / modeling settings must be set to ICON.

 

Symbol	Description
Asset	·       A system that is involved within a process ·       If it is responsible for performing a task (i.e. automation), It should be awarded a swim lane ·       If it is supporting a task (e.g. a user enters information into said system), it should be attached into the responsibilities section of the task as Support within the RACSI-VS settings   Note: Any need to create new assets must be communicated so that they can be added to the most appropriate section of their respective libraries and in alignment with our data governance standards.
Document	·       A document can either be a work instruction, a form or a record ·       A work instruction provides additional instructions on how to complete the task E.g. A user guide, training material, recipe, bill of materials, checklist, etc. ·       A form (paper or electronic) is required to be filled in (partially or completely) as part of the task E.g. A Purchase Order Form ·       A record is an example of a filled/completed form, which can guide the reader ·       Can be a physical document, URL, or Wiki page   Note: Any need to create new documents must be communicated so that they can be added to the most appropriate section of their respective libraries and in alignment with our data governance standards.
Description	·       Provides additional context for readers in rich text format. E.g. Notes, minor exceptions not worthy of a divergence in the process map, screenshots, etc.

 

 

 

Definitions #

Business Process: A series of activities, events and flows that transform inputs into a set of outputs.

Business Process Management: The management area that focusses on identifying, implementing, documenting, standardizing, improving, (re)designing, controlling, automating, and governing over business processes.

Process Modeling / Mapping: The technique used to discover and visualize a process to better understand its execution, interdependencies, effectiveness, controls, and risks. The breadth and depth of information included in process maps varies according to the goal of the modeling activity.

BPMN: BPMN, or Business Process Model and Notation, is a renowned modeling notation that is used around the world. It is the universal language for modeling processes in the BPM world, and is comprised of a large stencil of shapes, flows, and concepts that help describe, graphically visualize and automate processes.

Descriptive Process Modeling: This type of modeling defines the scope of the end-to-end business process at a level that managers and non-technical staff can easily understand. It keeps the map simple and reserves the process’ details as annotations or procedural content.

 

Figure: Recruit to Hire process using a Descriptive Modeling Approach.

Analytical Modeling Approach: This type of modeling describes the process in much more detail than a descriptive model would. It adds an extra layer of analytical content, such gateways and additional flows for divergences & convergences, events to depict additional milestones in the process, task types to depict whether a task is manual or automated, and even the inclusion of risks, controls, KPIs, data flows, and more.

Figure: Recruit to Hire process using an Analytical Modeling Approach. More flows are added to the process to depict divergences and convergences and rework loops.

Figure: Compute Smart Reader Data Process Map using an Analytical Modeling Approach. Data stores and transitions are added to show how data flows, and task types (icons on the top left of each task) are added to demonstrate types of task automation.

 

Process Framework: Represents the entirety of an organization’s processes. It has several levels of abstraction, thus providing views that speak to all levels of management. Process Frameworks are meant to be organizationally-agnostic, meaning that they should not change as a result of organizational restructurings.

Process Level: Processes come in multiple levels to accommodate all levels of the organization. Senior management is typically most interested in levels 1 and 2, which provide a more global view of how processes are managed, whereas front-line employees may prefer levels 3-5, which offer significantly more detail on how individual processes are conducted. Process modeling standards are therefore unique to each level being modeled.

 

Figure – Level definitions and examples.

Figure – Levels by Scope, Volume and Detail: While higher levels have a wider scope in terms of included activities, they offer less detail. There are also significantly fewer high-level process models than there are low-levels.

 

 

Process Universe (Level 0):

• Represents the root of the organization’s process framework, which is a series of Process Categories.
• Process Categories act as management areas, e.g. 7.0 Manage Human Resources, 12.0 Manage Business Capabilities, etc.
• The universe is not modeled; it is displayed as a series of “folders” (named Process Sets in EPC), each folder representing a process category.

Figure: Level 0 Example

Process Category (Level 1):

• Process Categories act as management areas that are relevant to any organization.
  • g. 7.0 Manage Human Resources, 12.0 Manage Business Capabilities
• They are organizationally agnostic, meaning that they should not shift as organizations restructure. While the ownership and responsibilities for these categories and their processes may change, the framework that these Categories form should not.
• Process categories classify major process groups, e.g. 7.2 Recruit, Source, and Hire employees, 9.3 Perform General Accounting & Reporting, etc.

 

Figure: Level 1 Example – Hierarchical and Graphical Views of the Develop and Manage Human Resources Process Category. The Chevrons (e.g. Manage Employee Development) represent process groups.

Process Group (Level 2):

• A Process Group represents one of many macro-activities applicable to a Process Category
  • g. Develop and 7.0 Manage Human Resources > 7.3 Manage Employee Development
• Shows the major business processes within a Process Group.
• The processes within this grouping can represented as standalone bins or organized as a high-level process map, depending on whether the processes are sequential or independent of one another.

 

Figure: Level 2 Example – Recruit, Source, and Select Employees. While most of the processes are linked, the Manage Applicant Information process is Standing Alone as it is a process that starts and stops independently of the others and is viewed as a process that supports the others.

 

Process / Subprocess (Level 3+):

• Depicts and sequences all activities, decision points, divergences and convergences, re-work loops, participating roles and systems, and more to capture exactly how it is executed.
• Processes may be broken down into sub-processes if they are very lengthy, complex in terms of breadth or depth, or if there is value in categorizing their activities into sub-sections.
• Sub-processes may be broken down further into more sub-processes. While this can continue indefinitely, it is generally advised not to go beyond Process>Sub-Process>Sub-Sub-Process.
  • g. for the process ‘Manage Incidents’, it may be broken down into several subprocesses such as ‘Identify Incident’, ‘Log and Categorize Incident’, ‘Assess Incident’, ‘Resolve Incident’, and so on. Any of these could have a map of their own if needed. Otherwise, they can be modeled as tasks.
• The modeling standards for processes are the same for sub-processes.
• Processes are best modeled when using BPMN, or Business Process Model and Notation.
• Process Maps can either be flat or organized in Swimlanes, which offer additional context on how the process flows from participant to participant, system to system, and more.

 

Figure: Level 3 Example – Permission Change Request Process Map using a Flat Map approach.

 

Figure: Level 3 Example – Permission Change Request Process Map using Swimlanes. The process shows two Swimlanes: Client End User and Client BPMS Admin. The process starts with the End User Submitting a Permission Change Request, flows to Admin, who performs some tasks, and the process ends back at the User lane.

 

 

Figure: Level 3 Example – Incident Management Process Map using Flatmap. The process is broken down into a series of Sub-Processes (denoted as a rectangle with a + sign at the bottom-center of the shape).

 

Process Modeler: This role is responsible for facilitating process modeling exercises. They ask open questions, encourage input, and model the process as the exercise unfolds.

SME / Subject Matter Expert: Subject Matter Experts are consulted during the process modeling exercises as they have deep knowledge on how a portion or the entirety of a process is conducted. They provide not only procedural information, but also key issues and suggestions.

Process Owner: The process owner is consulted during the process modeling exercises, specifically on the process’ overall design, objectives, KPIs, Risks and Controls. They are accountable for the process’ effectiveness and efficiency, are knowledgeable about major issues that must be resolved, and can make decisions with regards to standardizing, automating, and redesigning processes for improvement and compliance needs. They are also responsible for governing over the process, including approving any documentation such as process models.

Process Supplier: Process suppliers supply inputs that are required for the process to be executed. They are consulted during process modeling exercises as they provide input on how their own processes are conducted and on important interdependencies that influence the effectiveness and efficiency of the subject process.

Customer: Process customers consume the outputs of the subject process. They are consulted during process modeling exercises as they provide input on the quality of the process’ outputs and its overall effectiveness.

EPC: EPC, or the Enterprise Process Center, is a Business Process Management System. It is equipped with several capabilities, including the ability to graphically model processes. Processes must be modeled within this tool.