If you want to become more efficient you should automate your processes, right? Yes, but…not so fast, Tiger. Make sure you’re not “automating broken.”
While technology has opened up many opportunities for speed and efficiency over the years, the potential gains are easily wiped out by weak, inefficient and unsustainable process. Having a good grip on your processes before implementing automation or technology solutions is a must.
I recall working with a wonderful team at a previous organization, where we designed, implemented and supported process automation. Other teams would come forward for support on designing, testing and implementing automation solutions for their information technology activities and we always encourage them to first run and prove out the process manually, before creating any automation. The suggestion wasn’t always embraced, but to this day, my motto still holds true:
Make sure your process works properly before you attempt automation. If your process is broken and you automate it, you’re just wasting time and money automating “broken.”
This is a tried and true approach to adopt when your organization is considering tools, technology or automation to increase efficiency or save time and resources.
Something as straight-forward as testing login credentials before trying to automate the function, when untested, can cause hours of wasted effort for multiple human resources.
I recall an occasion where too much time and energy was wasted in trying to setup an initial process automation.
I recall an occasion in which our team was asked to automate a technical process. As it were, the login credentials needed to execute part of the automation were provided to us by another team. We checked to see if the credentials were verified and if the scripts to be automated had been tested using those credentials (this was part of our automation request form) and we were assured that all was in order and pre-tested.
After setting up and initializing the script, we proceeded with testing. Error. We tried again. Error.
Error message? It wasn’t an obvious error but it was suggesting something about a password update.
We double-checked and triple-checked the credentials and ran it again. Same error. What is going on?? We verified the credentials with the other team and attempted to rerun the script. Error.
We couldn’t figure out what was wrong after receiving repeated login credential errors resulting in testing failures.
We asked the other team to join us on a conference call to investigate the issue together.
As it turns out, the initial credentials to login were accurate, however, when the credentials are first used to login to this particular system, the user is immediately asked to change the password before proceeding any further. It was this activity that was holding up the automation.
When the credentials were initially setup, nobody had tested the login manually. If it had been tested, the user would have been notified to change the password upon the initial sign-in, the password would have been changed and then we would have been provided the credentials.
I do not believe there was anything underhanded in this scenario, nor do I feel there was any intent to deceive. I truly believe the system administrator setup the credentials and, having no reason to believe they wouldn’t work, sent the credentials through immediately, and without first testing them. Whether you would call this oversight, overconfidence or sloppiness, the end result remains the same:
If the login credentials had first been tested manually and proven to be working properly, it would have saved much wasted time and effort.
Please do not make the same mistakes in your automation journey. Take the time to fully-understand the process and ensure it runs properly, manually, before attempting automation.
I guarantee this philosophy will save you time, money and frustration.
Automating processes is an amazing way to improve efficiency, quality and productivity. It truly, truly is. And, the results can be amazingly wonderful once you get past the initial hurdles and operational hiccups. Once you’ve successfully-transitioned to an approach of automation, you’ll never look back. Why would you, when you’ve reached the process-driven promised land?
Have feedback and other suggestions? Leave a comment and share your opinion on what has or hasn’t worked for you and we’ll all be more efficient together as a community.
Your Friendly Neighbourhood Process Consultant