Pull to refresh

Business Process Management Part 2. How to

Level of difficultyEasy
Reading time12 min

This article is written in a how-to style. It is based on my personal experience and opinions, so it may omit some steps that are common in BPM practice but that I have not encountered in my work. The topic is broad, and each section deserves a separate article. Therefore, if you are interested in a specific topic, please comment, and I will prepare a more detailed description.

1. Gather a team

First you need a team to work on the BPM task. It’s often called a process office. A process office can be organized as a matrix structure, which is a type of organizational structure that combines functional and project-based reporting lines. In a matrix structure, employees are assigned to both a functional department and a project team, with dual reporting lines to both their functional manager and their project manager. 

To be effective in a matrix-structured process office, the team must establish clear roles and responsibilities, as well as effective communication channels. The team assigned on the task should have the following roles:

  • Process Owner: This person is responsible for understanding the current process, identifying areas of improvement, and defining AS IS and TO BE process flows

  • Business Analyst/Process Designer: This person will work with the Process Owner to map out the process flow, identify bottlenecks, and suggest areas for improvement. They will also be responsible for defining the requirements for the automated system if required

If you want to automate particular functions or the entire process, you will need the following roles to be involved:

  • Responsible user: This person will represent the end-users of the process being automated. They will provide feedback on the usability of the automation solution, suggest additional requirements, and help with user testing

  • System architect: This person will be responsible for designing the technical architecture of the automation solution. They will choose the appropriate technology stack, design the system architecture, and ensure that the automation solution is scalable and maintainable

  • Product lead/analyst: This person will be responsible for defining the product vision of the software where particular step or the whole process is automated, creating a product roadmap, and prioritizing the features for the automation solution. They will also work with the development team to ensure that the product is delivered on time and within budget and with implementation team to support software deployment and roll out

  • Data engineer: This person will be responsible for designing the data architecture for the automation solution. They will ensure that the data is collected, processed, and stored in a secure and efficient manner. Also they also they will work on data quality assurance

  • Implementation team: This team will be responsible for process implementation as well as testing and deploying the automated solution

2. Set the rules 

When the team is ready it’s time to set some rules. This step is often omitted, and the team starts creating BP flow charts straight away. However, it is crucial to establish some rules to achieve a consistent result. Otherwise, you risk ending up with a collection of diagrams designed in different styles and levels of detail stored in different places, as each person on the team has their own experience and vision of modeling. The following things should be agreed upon before modeling begins:

  • Notation

  • Modeling convention

  • Business process storage

  • AS IS and TO BE versions

2.1. Notation 

For modeling, you can choose any notation that you are familiar with, but the most popular ones are BPMN and EPC.

In my opinion, EPC is better perceived by businesses, and top-level diagrams are more convenient to coordinate in EPC. EPC also has a process landscape diagram that can serve as an entry point for all business processes. Additionally, on a detailed level, EPC allows you to show both the responsible role and the software system supporting the function in one diagram, while the standard BPMN notation would require creating two separate diagrams for this purpose.

BPMN, on the other hand, is convenient for describing low-level processes. Some systems, such as Camunda, allow you to automate processes described in BPMN notation, and BPMN is also more compact. In my experience, you can combine the two notations by using EPC for high-level diagrams and BPMN for low-level (execution level) processes.

2.2. Modelling convention

The Business Process Modeling Convention (BPMC) refers to a set of standards, rules, and guidelines for creating business process models. The aim of BPMC is to ensure that process models are consistent, clear, and easy to understand by defining a common language and structure for process modeling. BPMC provides a framework for consistent and effective process modeling within an organization.

To establish a set of guidelines and standards for creating business process models that are clear, consistent, and easy to understand, here are some examples of what could be included in a BPMC:

  • Notation: The BPMC should specify the notation or modeling language to be used in creating process models

  • Naming conventions: The BPMC should provide guidelines for naming process elements such as activities, events, and gateways to ensure consistency and clarity

  • Level of detail: The BPMC should specify the level of detail that process models should contain, depending on the intended audience and purpose of the model

  • Modeling techniques: The BPMC should define modeling techniques such as types of diagrams that should be used for each level of process detail as well as primitives (pictograms) to be used on diagrams

  • Best practices: The BPMC should establish best practices for creating process models, such as the use of clear and concise language, avoidance of ambiguity, and the inclusion of relevant details

2.3. Storage

There should be a storage space for business process diagrams. This can either be a storage provided by specific software used for business process design and management or self-organized folders in a shared space. However, there should be one designated storage space, and it should be well-organized to facilitate easy search for particular processes.

2.4. AS IS and TO BE versions

The current way of doing things serves as the starting point for process modelling by creating AS-IS flow charts. If you are satisfied with the current state of your processes, you can stop at this stage. However, it is also possible to envision how things should be. In this case, you can use your AS-IS diagrams and adjust them accordingly or fully redesign the process to create a TO-BE state.

Some companies even skip the AS-IS stage and start directly designing TO-BE models. In my opinion, this is a risky approach. Without AS-IS flow charts, there is no basis for designing a transition plan from the current state to the desired state. Therefore, I would recommend creating both AS-IS and TO-BE models before proceeding with process improvement or redesign.

3. Create business process flow charts

When the team is ready it’s time to document business processes. First - create business process flow charts.

3.1. Use top down approach 

Begin with a top-level process map that includes all end-to-end (e2e) processes of interest for tracing and automating. The process map will serve as an entry point for process analysts. When adding a new e2e process to the process map, it should be checked to ensure that it has not already been included to avoid duplication. The same should be done for all detailed processes in corresponding domains.

Example of a process map:

For each e2e process from the top level process map create high level flow chart. Describe end to end (e2e) processes as a whole, in order to understand how automation will integrate into the current work. Also it will show which functions are currently left manual and might be automated later. Then gradually descend to details for each function.

Example of high level process flow chart:

3.2. Proceed with detailed diagrams

Detailed business process diagram is basically a sequence of functions to be completed with all possible scenarios (not only the happy path should be covered). Complete the following steps:

1.     Determine the functions involved in the process. A function can be an elementary action or a set of actions (a sub-process) that can be detailed later. It is also important to model the order of executing functions, logic and rules including any decision points, branching paths, and conditional logic to understand which functions can be executed sequentially or in parallel and events preceding and following function execution. 

2.     Identify input data required to perform the function and resulting output data

3.     Determine who is responsible for the performance of the function

4.     Identify automated functions, add automated systems supporting the function

3.3. Add all necessary details

Each function should be defined with the following artifacts:

  • Condition to start: This is the condition that must be met to begin the execution of the function. If it is simply the completion of the previous function, the event may be omitted

  • Role: This refers to the role of the person who will be performing the function

  • Input data: This is the data that is required to perform the function

  • Output data: This refers to the data that is produced as a result of the function execution

  • System: This refers to the automated system that supports the execution of the function. If the function is manual, this artifact can be omitted

Example of detailed flow chart:

3.4. Agree flow charts with process owners

The business process flow charts that have been created should be reviewed and agreed upon with the business process owner and the performers of individual functions. This involves a final review of the flow charts to ensure that they accurately reflect the process and that any necessary revisions have been made based on feedback and input from the process owners and other stakeholders.

During this final review, a comprehensive examination of the flow chart should be conducted, including all steps, decision points, and any relevant documentation or information. Any remaining questions or concerns should be addressed and resolved to the satisfaction of all parties involved. Once everyone is in agreement, the flow chart should be considered final and ready for implementation.

3.5. Implement standards

If you have several teams working on the same business process differently, it may be necessary to implement a new standard. An implementation team should prepare training materials and conduct a series of master classes to introduce the new standard of work.

When deciding on the time of the new standards implementation, consider whether automation is planned. If so, it may be worthwhile to wait until it is complete and then introduce workflow changes.

3.6. Get first benefits

After the flow charts are ready and agreed upon, you can start benefiting by sharing the work standards among the teams and using them to streamline the onboarding process for new employees. This can significantly reduce the time and amount of communication required for onboarding.

4 Automate business processes or particular steps 

If a company is operating, it is likely that some of its core functions are already automated in some software systems. However, there may be opportunities to further optimize these processes. By analyzing process flow charts you can identify which steps should be also automated or moved from one software to another to streamline the process and increase productivity.

For example, flow charts may reveal that a particular process involves a lot of manual data entry or duplication of effort. In these cases, automation can be used to reduce the amount of time and resources required to complete the process. Similarly, flow charts may highlight areas where there are gaps in the process or where certain steps are not well-defined. By addressing these issues, organizations can streamline their operations and improve the quality of their output.

Another key benefit of using business process flow charts is that they can help to identify opportunities to move processes from one software system to another. For example, if a particular step in the process requires complex calculations or data analysis, a specialized software system may be required to handle this task efficiently. By identifying these requirements early in the process, organizations can choose the most appropriate software systems and avoid wasting time and resources on systems that are not well-suited to their needs.

4.1. Create use case description 

Process analyst prepares a use case description for each process and function to be automated and links the corresponding process diagram to the wiki page. As soon as the software to support the feature is defined, they provide it to the Product Manager and/or analyst from the corresponding Product Development team.

4.2. Create requirements for data sets

The process analyst prepares a set of input/output data for each function to be automated, as well as a set of entities and their properties to be affected when the task is completed. They then provide this data to the data quality team.

The data quality team then prepares a data set structure description and quality check rules.

4.3. Decide on the software

Once the functions for automation have been identified, it is necessary to decide which software to use for the automation process. It is possible to use the existing software systems in the company's landscape for this purpose. If there is no suitable software already in use, then new software might need to be implemented or developed. In either case, the help of a solution architect or another person who is familiar with the company's software landscape is necessary to determine the best approach.

If the decision is made to implement the automation feature in the currently used software, the feature needs to be added to the appropriate product backlog and managed by the responsible product manager and analyst.

4.4. Develop the feature

The product manager is responsible for ensuring that the feature is included in the product backlog and scheduling the corresponding tasks. The analyst from the product development team prepares the business and system specifications for the development team to work on. Finally, the product development team is responsible for developing the feature based on the provided specifications.

4.5. Consider process orchestration software

There are plenty of various BPM software now. They can be used not only to automate business processes but also to orchestrate e2e process which steps automation is distributed in several different software systems. Such system can integrate with those systems checking status of each step and allow to overview in which status is the particular instance of the process, helps to create analytic data (practically logs that can be further analyzed) of the process performance and push (notify) responsible personal if required. There is an example with Camunda but there’re many other similar software you can check.

To use Camunda for process automation when you already have software for particular steps automation, you can follow these general steps:

  • Map out the process flow in built-in BPMN modeller: Use Camunda's modeling and design tools to map out the process flow for the end-to-end business process, including the steps that are already automated using separate software systems

  • Integrate the existing software systems: Use Camunda's integration capabilities to connect the separate software systems that are already being used for particular steps automation to the overall end-to-end process

  • Define the process logic: Use Camunda's visual process editor to define the logic and rules for the end-to-end process, including any decision points, branching paths, and conditional logic

  • Automate the process: Use Camunda's workflow engine to orchestrate the end-to-end business process, including the steps that are already automated using separate software systems

  • Monitor and optimize the process: Use Camunda's monitoring and analytics capabilities to track the performance of the automated process and identify areas for optimization and improvement

5. Monitor and assess business process performance

Process analyst along with process owner should Identify metrics to be monitored. Here are common metrics that can be tracked:

  • Cycle time: The time it takes for a step and/or the whole process to be completed, from start to finish

  • Processing time: The time it takes for a process to be completed, excluding any waiting time or delays

  • Productivity: The number of steps (tasks) completed per hour, day, or week

  • Quality: The percentage of steps completed correctly, without errors (e.g. in terms of data quality)

Same metrics might be measured for each particular person performing the process.

These metrics should be monitored for the entire process, as well as for specific steps within a business process. Special attention should be paid to outliers. Tracking them you can gain insights into the performance of each step and identify areas for improvement or optimisation. These metrics can also help to identify bottlenecks or areas of inefficiency within a process, and to make data-driven decisions to improve overall process performance.

Here is a link to a good article with examples of common process metrics and its visualization https://getnave.com/blog/kanban-metrics/.

6. Optimize Business processes

6.1.       Introduce changes

Optimizing business processes is an iterative process that involves several key steps:

  • Analyze data: Collect data from your business process monitoring dashboard and analyze it to identify areas of inefficiency or bottlenecks. Look for patterns and trends that may indicate a need for optimization

  • Set performance targets: Based on your analysis of the data, set performance targets for each key performance indicator (KPI) that you want to optimize. These targets should be specific, measurable, achievable, relevant, and time-bound (SMART)

  • Identify root causes: Identify the root causes of any inefficiencies or bottlenecks that you have identified. These may include problems with technology, people, or processes

  • Develop and test solutions: Develop and test potential solutions to address the root causes of the inefficiencies or bottlenecks. These may include changes to technology, processes, or training for employees

  • Implement solutions: Implement the solutions that you have developed and monitor their effectiveness using your business process monitoring dashboard. Be sure to document any changes that are made

6.2       Adjust automation if required

Don't forget to sync your software with business process changes.

6.3.      Implement changes

Don't forget to implement your business process and software updates. An implementation team should prepare training materials and conduct a series of master classes to introduce the new standard of work each time processes and/or software are updated.

Total votes 3: ↑2 and ↓1+1