Process automation is a must in today’s world, where everyone is trying to convert over to the digital world. Digital processes don’t sleep or take breaks, they perform various actions, make decisions and streamline your processes to be efficient.
But, if process automation is not done right, it can also lead to disaster. Some mistakes are costlier than others. There are many stories of these in history. One of these stories is the Boing 737 Max. An automated Maneuvering Characteristics Augmentation System (MCAS) used in Boeing’s new 737 Max 8 aircraft led to two major air disasters and 346 casualties in the space of just 5 months between October 2018 and March 2019. A very costly mistake when human lives are involved.
Here's a real example in technology from one of our customers. Our customer hired a consultant to setup and automate their cloud environment. The automation process involved deploying a new virtual machine into their cloud environment after all the validation and approvals were done. The consultant who did this did exactly what the process was suppose to do, but made one little mistake. Instead of creating the virtual machine only within the local cloud, every virtual machine that was created also created a copy within all global data centers of the cloud. So, when the company was expecting a cloud bill for $100k/month, they were getting a $1M/month bill. So, in this case process did mostly what it needed to do, but at the end when it deployed, it deployed the virtual machine based on a wrong configuration and costed the organization more cloud fees than expected.
As some of these mistakes are very costly, it can lose lives or even bankrupt organizations. In processes such as these, there should be much more rigorous levels of approval and testing to make sure there are no costly mistakes. So, what are the Top 5 mistakes?
Using the wrong people
In order to be successful in Business Process Management, you need 2 things. Domain experts and information technology (IT) experts, it’s a marriage between the domain experts and IT. The reason being, domain experts know the domain and the manual process well, but don’t know how to automate or the technology. IT knows the tools and technology, but don’t know the domain or the manual process well. So, its very important to have the right team and the resources to be successful in automation.
Even with the domain experts, for example the Research scientist might know the manual Change Control process very well, since they have done and filled many paperwork for the Change Control process. Even though the Research scientist may know the process well, they will not know how to automate the process using a Low code/No code platform. Process automation is designed for business analysis, they are able play the middle man between the process owner and IT and use BPM tools to automate the process. So, make sure you have the right people to automate your process.
Designing the process around the tool
Most BPM tools will do this, they will make you build the process around the walls of the tool. The reason for this is because of the architecture of the tool, and this also leads to many limitations of the tool. The tool likes to be its own ecosystem, where everything is inside the tool. Where you have to automate your process according to their process.
There’s only 1 tool currently in the market that let’s you build the processes the way you want it, and its FlowWright. FlowWright is designed to sit on the side of your Enterprise systems and be on the driver’s seat driving your processes across your Enterprise systems.
This is the same model between McDonalds and Burger King. McDonald’s burger comes with what ever it comes with, but the Burger King burger can be customized to how you want it. When it comes to BPM, FlowWright let’s you automate the process using your way.
Always design the process around the people who will be using it.
Not integrating with other platforms
This is one of the biggest issues we see in process automation. In some BPM tools this is very difficult to perform given the lack of integration with other systems. With open workflow systems such as FlowWright, you can easily do this using integration services.
Other Systems such as Enterprise software systems are very good what they do, so why not use them. For example, even though FlowWright has PDF conversion functions, customer might have a PDF conversion tool that is specific to their forms and data, an example would be Adlib PDF. Our Kansas Department of Transportation uses a custom FlowWright step to PDF their form data. FlowWright makes a call to the PDF system, it performs the PDF at some point, and notifies FlowWright to continue processing the workflow. We also call this Asynchronous workflow processing in FlowWright, where FlowWright makes a call to another system to perform the work and waits for a callback to continue processing.
One of the good examples of not integrating with other platforms is, recently we saw a customer generating a complex report generation within FlowWright, and emailing that report out to users. But the customer also had an Enterprise reporting solution that was generating the same report and more. Customer was able to change the process easily and make a REST API call to the Enterprise reporting solution to generate the report. By integrating and making other systems perform the work also puts less stress on the workflow system. But also, you can have increase performance and efficiency by running multiple jobs in parallel within other Enterprise systems. So, always integrate and offload work to other systems to perform.
Not testing the process enough
Testing is very important, even though you are working with workflow steps that are fully tested, testing your overall process is very important. Most of our customer have 3 environments, development, QA/Validation and production. Build and test your process within the development environment, test the process with test data. Once testing is completed, promote the process to QA and Production environment. It’s also very important to perform QA and Production testing, the test data could be very different. In many cases, testing at Development and QA level is enough to prove that the process is designed properly, but the real test is the Production level testing.
Conclusion
Above are some of the mistakes that we see our customers make when automating manual processes to digital automated processes. I am sure, there’s plenty more. Always use good process design practices and the right resources to automate the process.