This column is by leadership and growth expert David Haigh
“This takes way too long David – why don’t we just automate it?”
I love Information Technology. It’s incredible. It allows for instantaneous capture and distribution of data. It democratizes insights. It levels the playing field. It unleashes people to spend time doing value-added stuff, just like the steam engine and interchangeable parts boosted productivity during the industrial revolution.
But just like the enhancements brought by the industrial revolution, using IT to automate tasks carries with it a big caveat.
One of the best examples of this happened when I was tackling, for the first of many times, a business planning process. Business planning is a fascinating process. It touches every part of an organization. It brings you closer to your customers and suppliers. It lets you capture your operating assumptions, model scenarios, project the future, embed your strategy into your financial plan and figure out the growth you’ll deliver.
We had an opportunity to automate a big part of this process – all of the financial templates. We stood at a cross-roads at the start of the project – do we go shop around for off-the-shelf software packages that promised huge productivity improvements – or do we stand back and examine the process first?
Many of our leaders were on the side of going with software first. Our employees were loaded down with the extra work of planning, on top of their day job. All of the granularity that our planning process required involved lengthy analyses, all done manually, and then re-run when there was an assumption change. Everyone was crying for help.
Perhaps ironically, it was our CIO who stepped up into the fray and said, “no, we need to start with the process”. He was met with amazement, and confused looks.
“Why on earth would we want to do that?” he was asked.
“Because I don’t want to invest in automating a process that is broken. Define, map, and fix the process first, and then I’ll automate it”.
Simple as that. I was brought in to help facilitate the discussion…and we found all kinds of interesting quirks. Some departments started out of step from others, causing rework of assumptions. The plans were invariably reworked at the end of the process to meet the “real” business plan target – which was actually known at the start of the process. Management would request multiple changes as scenario plans – creating huge churn and over-burden. Bias and accuracy of the plan weren’t considered. Many of the charts and analytics were tedious and set up as “one-off” analyses could be standardized and save employees hundreds of hours. Currency assumptions took hours to execute, and had to synchronized manually across a dozen spreadsheets, which usually resulted in errors.
With that in hand, that process work enabled our IT team to find the right solution that would solve those problems and support our process. Their solution brought the flexibility we needed, but with enough standardization to eliminate duplication and rework. When assumptions changed, analysts could change one key figure and see the outcome across the business.
We ended up using that process work more than once – each time a new automation was suggested, we went back to that process map to capture the changes and understand why the process was set up in the first place like that. Employees felt like they could own their part of the process and be successful improving it.
So if you’re looking to automate, start with the process…and the problem you’re trying to solve. When you start getting good at it, build in Autonomation – automation with the human touch. Not only does it reduce non-value added time, but it eliminates and detects the errors in your process and tells you when something’s going wrong. It’s a much better approach than starting with automation and then spending your time cleaning up the issues it invariably multiplies.
Most importantly – realize that while the tool enables the process, it doesn’t fix defects. Automating doesn’t change the behaviours that cause issues in the first place – management not realizing the downstream impacts of reporting requests, ignoring error, not following standard work – that requires good old-fashioned Lean Thinking.
Disclaimer: This is a curated post. The statements, opinions and data contained in these publications are solely those of the individual authors and contributors and not of iamwire and the editor(s). This article was originally published here.