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.
