How do you innovate or experiment with new or alternative ways of automating your processes?

The identification of pain points doesn't have to start with a blank canvas. A good starting point is to scan through feedbacks from customer surveys, help desk tickets and continuous improvement logs to detect patterns and volumes. The data harvested can act as additional input or amplifiers of pain points during process discovery activities, interviews etc.

Always check whether additional individuals or teams perform the same task or process when assessing an opportunity. Some of the best automation use cases are hiding in plain sight because many other individuals and/or teams are essentially completing the same work as others but are unaware they're doing so. In such cases, standardize the process as much as possible first. Standardization will allow your automation yield significantly higher ROI: you will impact more people, gain more efficiency, and your automation will require less development and maintenance.

Unlocking Innovation Through Data-Driven Automation Data-driven insights are the catalyst for revolutionizing automation. By analyzing data: Predict trends and demands, enabling proactive automation solutions. Identify process bottlenecks for targeted automation. Personalize customer experiences to enhance efficiency. Implement real-time quality control for consistent excellence. Optimize resource allocation and reduce costs. Gain deep customer insights for engagement and retention. Automate compliance and risk management for agility. Establish feedback loops to fine-tune automation. Track performance metrics for continuous improvement. Incorporate data into your automation strategy for an innovative edge that drives efficiency and growth.

First you need to identify the problems your employees are experiencing. Automating for automation’s sake may have no benefit. Feedback, as well as requirements gathering from project stakeholders, and surveys about “the worst part of your job processes” can gather the problems your teams are facing. Do not ask for solutions, just ask what the problems are. The next step will be to identify where the data required for these processes is, and where it lives/will live.

Process mapping, as well as process mining works quite well for larger organizations. However, smaller organizations can get some quick gains with smaller scale analysis, usually using interviews. Talking to middle managers is a good way to find areas where their teams struggle, as well as tasks that their team members either complain about, or have trouble completing on time/within budget, etc. Automating such tasks is not only a nice way to pick the low hanging fruit and thus get some ROI that justifies further investments. It also works very well for internal marketing of automation within the organization - when people notice that painful tasks can be automated, they come up with further ideas of what to automate.

But not too much. A lot of organizations will stumble at this point wanting to make the perfect decision, when in reality, most products will do, and the time spent making a perfect decision could have been used towards implementation. Best practice; decide the following: 1) Required (must haves) 2) Good to have 3) Nice to have Decide how many applications you are going to review before hand (so you don't review 32, like I have seen before). Decide how you are going to choose 1. Maybe 1 person looks at and analyzes 5-10, and brings 3 to the decision committee with their thoughts on pros/cons, and the committee chooses 1. Be fast, be distinct, and be structured. This will save a ton of time and let you focus efforts on implementation.

The important thing here is to make sure that the cost of the solution is not the major factor when making the decision. The major factors should be how well the solution corresponds to the requirements of the business, as well as how easy it is to get started, how many experts are available in the market (both for hire, as well as for purchasing services from), feedback from other users, etc. It is also not absolutely necessary to stick to a single tool. A lot of organizations worldwide actually go with a multi-tool approach, using the tools most appropriate for the specific tasks at hand.

Rather than dive into tools, or RPA, right away when analyzing a new business process or an existing one that employees identify as problematic, I prefer to step back and approach this more holistically. The problem with a tools based approach is your employees may end up trying to shoehorn themselves and their process into the tool, to fit the tool. This does not lead to a healthy or engaged process and workforce. Instead our approach is to take the process and not aim for the quick win, that will come later, but an engineering approach. Cut anything and everything away from it and design a new process that is minimal and fits your organization and how it functions. Aim for engagement and employee happiness, not what they ask for.

Start small. You will always learn a lot along the way. Do spend some time to think ahead and engineer, but you will never get everything right until you are into it. Build a minimal MVP that can act as a framework for future iteration. Put the focus on worker experience, and organizational efficiency. Keep in mind you will want to come back and iterate, and make your MVP open for this, but also accept that you may keep this MVP permanently if organization priorities change.

It is very important to have a separate independent environment for testing, whenever possible. This is so that mistakes in development or bad data provided as input does not cause issues in live operations. If possible, try to make sure that your test environment is isolated from production. See if your ERP/accounting/CRM or other systems that you are trying to integrate with, support having a test database/environment. Use a separate machine to run anything that has to run on a desktop. Use data that is similar to live data, but is not actually real. The important thing here is to make sure that the environment is as similar to the production environment as possible, but is still separated and does not affect production in any way.

What I would like to emphasize here is how important metrics are. However, they should in fact be set before you even start implementing any solutions. It should be a part of the overall strategy when starting an automation/improvement initiative. The metrics should be aligned with the goals that the organization is trying to achieve. Then, when the solution is implemented, these metrics can be used to evaluate whether or not the goals have been achieved. This is the only real way to quantitatively very whether or not the initiative was an actual success or not. It also helps learn from any mistakes made and then prepare better for further projects and initiatives.

This is something very basic that comes from any project management doctrine. The project should be documented, any learnings should be made available and public (at least to the relevant stakeholders), so they can be used in further projects. This will not only help succeed in more projects in the future, but it will also help market the idea of process improvement and automation to the organization, so that further projects actually happen.

A strong governance is a must have to keep a focus on continuous improvement and integration with successive process changes done elsewhere to ensure efficiency gains are not lost over time. Ensuring governance will also spread knowledge to a wider audience which in turn can help identify future risks and opportunities.

Understand the bottleneck and redundant part of the existing process that should be optimised to be efficient and secure. Process discovery can be one of the options to understand existing processes and come up with more efficient choices, other options can be process mining and task mining that can give a holistic view of the existing process and highlight bottlenecks.

A very important topic that hasn't been touched in this article is proper change management. It clearly is broad enough to deserve an article on its own, but it must at least be mentioned. Every party affected by the initiative must be informed appropriately about what the organization is doing and why. This must be done well in advance of the implementation itself. This is necessary, because when it's not done, people may actually reject changes due to fears of the unknown. They may sabotage the initiative, provide false negative feedback, or simply not use the new tools/methods provided. Any process improvement and/or automation initiative can easily come to a halt very quickly if people are not properly informed of the goals behind it.