Automation is the part everyone wants to fund. Standardization is the part everyone wants to skip. That ordering is exactly backwards, and it is why so many automation projects deliver speed without delivering value.
Automation amplifies whatever it finds
A process is a set of decisions and steps. Automate it and you do not improve those decisions; you accelerate them. If the underlying process is clean, you get scale. If it is full of exceptions, undocumented judgment, and "well, it depends," you get those same flaws executed faster and at higher volume, now buried inside code where no one can see them.
This is the quiet trap. The mess used to be visible because a human paused, frowned, and worked around it. Automate that human away and the workaround becomes invisible, baked in, and far harder to fix. You have not removed the problem. You have industrialized it.
If three people run the same process three different ways, you do not have a process to automate. You have three, and a decision you have been avoiding.
Standardization is the unglamorous prerequisite
Standardizing first means agreeing how the work is actually done, once, before a line of code is written. It means surfacing the exceptions and deciding which are real and which are habit. It is slow, political, and produces nothing you can demo. It is also where the value lives.
I find that the act of standardizing often delivers most of the benefit on its own. When everyone runs the process the same way, errors drop and cycle time falls before automation enters the picture. Automation then compounds a gain that already exists, rather than freezing a problem in place.
So when someone asks how soon you can automate a process, the honest first answer is a question: which version of it? Get to one clean answer, then automate. A fast mess is still a mess. It just arrives sooner.