Business process automation. How to begin?
22.06.2020 - Read in 9 min.
Lower costs, higher quality, larger number of satisfied and properly served customers. Higher motivation of employees. There are numerous reasons to reach for business process automation and optimisation.
Lower costs, higher quality, larger number of satisfied and properly served customers. Higher motivation of employees. And consequently, better competitive position on the market and higher value of the company. There are numerous reasons to reach for business process automation and optimisation.
However, if you’re reading this text, I assume that I don’t need to list them here. You have probably found a justification for automation at your company, and now you want to know how to begin in order to safely complete the process.
What challenges will you face? How to tackle transformation and succeed?
Prior to selecting a business process engine, think about overcoming reluctance to changes
Automation brings the highest benefits in situations where the scale effect occurs, i.e. where multiple different processes are handled (from sales to service), or many process instances are present (here, an instance means e.g. handling a single customer complaint or activating a service on a subscriber’s account).
Ironically, the repetitiveness and transparency of processes, which usually serves as the basis for work effectiveness in large organisations, can also be a burden on the path to innovativeness. Habits and routines are the greatest enemy. After several years of working in the same way, we tend to fall into routine, which makes us less vigilant. In case of manual work, repetitive actions make us more prone to errors. This is one of the first areas where you can benefit from automation.
However, before you begin thinking about which technology you should choose, or which process should be automated first:
1. Find allies.
Think about people who will benefit from the deployment and should be open to innovations, and who have the influence to make sure that your initiative gets the green light. Together, your voices will resonate better, and the point is to be louder than the voices protecting the status quo, openly sabotage, or delay the change.
2. Start gathering data from your organisation.
Many companies do not keep records and do not realise how many times a given process is conducted during a month, how much time it needs, and how much money it costs. For instance, an insurance company does not know how long it takes on average to settle a claim and what consumes the time, or an online store that does not know how much time it takes to handle an average complaint or return. With this data in hand, it’s easier to prepare a reliable business case, thanks to which the sponsors can see the actual value of the project. Also, it will be easier to select the first process to be automated. Sometimes, all you need is to ask the analysts with access to corporate data warehouse the right question, and sometimes you’ll need to dig deeper or make the organisation begin gathering data in the first place, which then can be used to produce process load statistics.
3. Collect business cases on the market.
Innovative sectors are full of successful deployments that can be useful in building support for your idea throughout the organisation. Look beyond your category—some issues, such as shortening the time required for handling complaints or activating services, are universal. You can find them in almost every situation where multiple clients have to be effectively served. Even if your company comes from the industrial age (e.g. supplies electricity or provides waste management services), but considers innovations in customer service processes, you can use cases from other widely digitalised sectors like e.g. banking.
What does that look like in practice? Here’s what Magdalena Borek-Dwojak, Digital & Customer Experience Director at innogy Polska, had to say:
“Every year, tens of thousands of customers contact us, asking to transfer ownership of meters in their newly purchased or inherited apartments. Even though the process itself is quite complicated, we wanted to make sure that it is quick and intuitive to our customers. After deploying automation, we’re pleased to see good statistics and positive feedback from our customers, as this proves that we managed to correctly identify burdens for our customers and the potential of the solution. Importantly, the project also facilitates the work of Customer Service employees, if the customer decides to stick to the traditional channel instead of choosing the przejmijlicznik.innogy.pl portal.”
Use the BPMN 2.0 notation, user story mapping and proto-personas to avoid the Tower of Babel Syndrome
When undergoing digital transformation, many companies find it difficult to clarify their business expectations or requirements to IT departments of external IT vendors. You can read about typical deployment scenarios and pitfalls to avoid in the article: “Using Camunda BPM integration for business process automation”.
The root cause of such misunderstandings is the lack of a common language. To deal with that, you may use one of the below methods to achieve a common, unified understanding of a business issue and expected operations of the system.
basic user portraits (with no detailed demography or psychography, but with clearly identified user goals), thanks to which you can answer the question of who the intended recipient of the process automation system is. It is a good practice to personify not only human recipients, but also systems that will use your solution. You’ll be amazed by how listing the intended end-users alone will allow you to organise and complement the knowledge of those engaged in building the application.
2. User story mapping.
This modern method of workshop works allows business stakeholders, analysts, and developers to come up with a commonly understood narration. You’ll need one or two working days, a free wall, and a lot of post-its or an electronic solution like Miro for distance work, and finally a person to run the workshop. Each user story is written down on a separate post-it and placed in a narration cycle—left to right—to form a kind of a map on the wall. This will provide you a quick answer to the question of what goals the users want to achieve.
3. Mapping processes using BPMN 2.0 .
If you have a map of user stories or initial drafts/diagrams of processes, it’s a good idea to hold workshops for developers and the business. Participants will use a limited number of BPMN 2.0 symbols to prepare process models at the strategic level. Such models don’t specify technical details, but rather provide a deep understanding of all the steps in a process, what the main path looks like, as well as available alternatives.
“In the older approach, process models were created by business analysts in a cascaded way, based on the input provided by the business, and then forwarded for implementation. Today, a much more common method is to tackle and describe issues as a team, since business has the domain knowledge (market expectations, user expectations, etc.), and IT has the technical knowledge (limitations and possibilities of the necessity to integrate with third-party systems). The role of analysts keeps evolving. They still help with locating and identifying edge cases and other tasks, but they no longer act as intermediaries who communicate business needs to IT. A close cooperation of business and IT makes realising goals much easier.”– says Artur Śpiewak, IT Project Manager in Artgeist, a company that automates processes that involve production and customer service.
Three steps to successful deployment of business process automation
According to Jakob Freund and Bernd Rücker, experienced consultants, authors of Real-Life BPMN and the masterminds behind Camunda BPM, deploying business process automation is easier once you split it into three steps.
1. Choosing the right PoC (Proof of Concept) candidate
Preparing a PoC is the equivalent of “playing in a sandbox”. A PoC’s purpose is to prove that you can use the chosen technology to “roughly” meet the organisation’s needs—in this case, to support a single process in its simplest version. Therefore, a PoC product here would be the process run in a test environment without releasing it to real customers on a large scale. Within the scope of a PoC, the selected process is mapped, its model is prepared on the strategic level, and its operational layer is supported. This involves connecting the selected business process engine with other systems within the organisation, so the process visualised as a BPMN diagram can be actually implemented and start working.
A good PoC candidate should meet at least two of the following criteria:
- The process should not be overly complicated (it should include few or no sub-processes).
- The process should not reference too many existing systems within the organisation (modern engines let you freely connect using REST API or a data bus, so a PoC is rarely supposed to check all the BPM engine integration options available—usually all you need is a connection with one or two key systems that the process management tool will communicate with).
At the PoC stage, the goal is to connect the business process engine with the remaining systems in the organisation, so that the process visualised in the form of a BPMN diagram can be implemented and put into operation.
PoC is also the time to evaluate various technologies to identify the one that will match the specific needs and the technological stack of your organisation in the best possible way. By selecting an open source software, you can quickly check the value of the product without the time-consuming licensing process.
“Being able to quickly and easily get to grips with all of the capabilities of a BPM suite in your owne environment is paramount to getting the right understanding for features. So I find that Camunda being open source ensures firstly that people get to experience the full power of the engine on their own terms and secondly have the freedom to experience how it integrates in their own stack.”
– says Niall Deehan, Developer Advocate for Camunda BPM
2. Building support for the deployment—Lighthouse Project
Similar to how a lighthouse signals ships to help them safely reach the port, the first successful production deployment of a process helps you build support for large-scale process automation within an organisation.
The key requirement that the process chosen for the initial production deployment should meet is the potential gain from choosing that specific process over others.
The ideal case would be a process that is performed repeatedly every day, time-consuming and costly to maintain, automation of which would make it shorter and lower the cost of its single instance.
One example of such a process is complaint and return handling. If a company does that manually, the time to resolve each request is usually long, and there can be mistakes that force the company to send additional documentation or explain the situation twice. Customers perceive that as low quality of service (negative impact on customer experience).
Automating this process lowers the cost of handling each request, speeds up resolution time, and boosts the consumer NPS (Net Promoter Score). As a result, the costs get lower, and brand trust and equity grow.
A business case that clearly shows this significant impact of automation on operating results and creating competitive advantage can be easily defended at any decision-makers’ meeting, gaining support for automation of other processes.
3. Large-scale automation
The key to large-scale automation is combining technical readiness with engagement of stakeholders in different business domains.
As the saying goes, “success has many fathers”. Therefore, it’s best to start with publicising the success of the Lighthouse project deployed in the previous step. Once that’s done, the initial resistance to change usually goes away, and more people within the organisation start supporting the idea of automation.
Building a PoC can take 2–3 weeks. A Lighthouse project is usually deployed after 3 months. Large-scale automation, however, is a never ending endeavour. More and more diverse processes (from various domains) are implemented over time, and more stakeholders join. Further optimisation drives better and better results for all process types, and process models can be easily updated thanks to process engine flexibility. This lets the business keep up with the ever-evolving market requirements and stakeholder expectations.
The number of managed process instances increases dramatically at that point, so it’s good to have a well-thought-out strategy for integrating the BPM engine into existing IT solutions in the company at the beginning of that stage, as well as the idea about how to build an internal competency center around the process automation domain.
To do all of that efficiently, it’s best to find the right partner who is not only familiar with the technology but also has practical experience in sharing know-how within organisations.
RST plays that role. We are the first certified Camunda BPM partner in Poland, and we are also experienced in building, developing, and maintaining highly-scalable IT systems.