People often start automating processes before gaining an in-depth understanding of the processes they are automating. They’ll dive into the automation tools and start connecting services and automating the processes. They might ask questions as they go, and figure things out as they go along.
This creates quite a few problems, which I’ll outline below. It’s always better to map out the processes you are going to automate before you start building the automation.
Problems with not mapping out processes first
Building automations without a decent process map is like a builder building a house without the architectural drawings. Without a blueprint, it’s pretty easy to go wrong. Here are a few of the issues I’ve seen with building automations without a process map.
Issues with current processes are hidden
Without seeing the processes in mapped out in front of you, you can’t see what the issues are with the existing process. So you might end up automating something that is fundamentally a broken process.
Less scope to improve the process
You have less scope to improve the process. You’ll end up automating the manual processes as they exist. Furthermore, you maybe be able to make tweaks, but it will be far harder to dramatically improve them if you can’t see them mapped out.
Lack of buy in from the rest of the business
It’s harder to get buy-in from others in your business. Talking about a process in meetings is not the same thing as having it properly defined on (virtual) paper. Mapping it out makes it more concrete, and easier for most people to conceptualise.
It also means that you can discuss the process with various team members and stakeholders, and identify any wholes in the process and areas for improvement. Doing this before starting the process of building the automating will save a lot of time and head aches.
It enables you to get crystal clear about what you are automating, and get agreement from various stakeholders before the automating building starts.
Burning more time
When you jump straight to the building phase, you are flying blind. You’ll end up making mistakes that need to be rectified. This takes up more time than if it was properly mapped out first.
While mapping out processes up front does take time, but it saves time overall. Once the processes are mapped out and agreed, it because the automating building process a lot smoother and faster to implement.
No evaluation of the tools
Without a process map, people often end up using the same automation tools they have used before. After all, it’s worked before, so why won’t it work this time?
One of the benefits of mapping out processes is that you can see how your systems connect, how data flows and how workflows can be refined and automated. You can then evaluate the tools to use to automate the processes after you have a much clearer understand of what the processes are and what needs to be automating. This will help you build a list of criteria to evaluate the various tools with, and these criteria are the exact context of your business processes.
Map out processes first
All of these problems can be negated when you map out the processes first.
By mapping out the process first, you will start to see where things can be improved. And what can be streamlined and automated.
It also gives your team and wider business a chance to talk openly about the current process. They can talk about what works well, what doesn’t and what can be done different. This is all vital information to understand before the process of building starts. They can provide additional insights, including on any future strategies that might impact the processes.
It gives you the space to figure out what the automated process should be before getting stuck in the specific automation and integration tools (or code, if it is a coded solution).
Often there will be more than one way to solve the problem with an automated process. Mapping it out first enables you to show the different options, and you’ll then be able to highlight the pros and cons of each option.
You may even discover entirely different processes along the way that can really help you. For example, I recently built an automated process to integrate event booking platforms with a client’s email marketing system. I identified a new way to track people who register, and attend events in a new activity database in the email marketing tool. This opened up a whole new world of possibilities for the client. This included the ability to automatically follow up with people who register but don’t attend, send thank you emails to those that do attend, and have each to reach analytics on registrations vs attendance.
It saves time and money. Mapping out processes in flow chart tools (I love Whimsical for this) is a much quicker experience then building out. You can even map it out when on a call with relevant stakeholders. It’s generally a fluid experience, you can move things around and really get to grips with you are doing, without distractions. This makes the building process far quicker and smoother. In the end, the time saved in the building phase saves money over all.
Wrapping up
People often dive into building out automations without mapping out the processes first. This brings many problems, including:
- Issues with current processes are hidden
- Less scope to improve the process
- Lack of buy in from the rest of the business
- Burning more time
- No evaluation of the tools
When you map out processes before building the automations, you can negate these problems. You’ll benefit from:
- See what can be improved
- Talk openly about current processes with your team
- Space to figure out what your processes should be before automating them
- Identifying different options to solve the problem
- Save time and money
If you like the sound of mapping out your processes, but need help making it happen, I offer this as part of my Automation Strategy service.