When to Use Process Automation Technology

Thanks, Coy, for being here with us today to talk about when to automate with technology, and when not to.

Coy, before we get started, I want to know a little bit about yourself. I see that you are participating in the home gym movement with your new weight rack in the background.

Yeah. Most people call it a pull-up bar.

Pull-up bar in the background. But you're surviving quarantine and ready to teach us something new about automation.

Absolutely. I'm going to go ahead and get started here.

There's four main points we look for when we are thinking about automating a process and taking on work for a client.

Your tasks need to follow a certain pattern. A, B, C, D, in that order every time.

Tasks also might flow between humans and systems. You might have a process get started where some source data on a member needs to come in and that source data exists in one system. Instead of it being manually entered in the human task, we can pull it in automatically via our process automation software.

Additionally, you might need to maintain a log of what work you do. It's important to know when work gets started, when work gets finished and who's doing the work. A lot of times we'll see on client's sites, they might only get the end result. They had no clue when this process started and how many people looked at it and who it took to do the work.

Also, work might be regularly missed. So in a similar vein, if you don't know when work starts and you only know when it finishes, you don't really know if it took too long or what the definition of too long is.

It's important to have these process automation tools in place so we can define SOAs and keep track if those SOAs are missed or made.

But then there are times where you don't want to use process automation.

Yeah, absolutely. When not to use process automation. A lot of times people clients will think process automation is like a magic bullet, and it's not.

Some situations we run into is they'll say, "Our process is different every time." Or, "Sometimes it goes like this, or other times it goes like this."

What we mean by that is, you might say that, sometimes it starts with an email sent to this person. And another time someone starts an Excel document to keep track of the work. And sometimes it's a share point site where they have an internal process.

All these things are too disparate and they're not effective and they're not really a process. Sometimes people will say that they need the flexibility, "We need to change our process from time to time or start many different ways." The true process can have exception routes, but it doesn't change week to week or month to month.

Back to the magic bullet point, clients will say they need quick results. Sometimes they're in what they view as emergency situations and they'll say, "We need to know what the results are in a month." Or, "We need to have a new application out there in a few weeks." That's not really realistic with a high quality product and a high quality process automation implementation. It's a bigger involvement than just a couple weeks of development to develop a screen.

Along with that is in order to have an effective process automation endeavor, you need some cultural changes inside of your work place more often than not.

The users, one, are the most important group, the people that are actually going to be doing the work. They need to have buy in. You need buy in from them and they have to want to be using the new system.

If you have employees that are completely comfortable with the way that things work now and they don't understand why they're changing, they're not going to be involved and committed to making this process automation endeavor work. It's absolutely a team effort.

What that means is, with the user's buy in is they're going to need to provide feedback for the developers to make sure that they make every field that needs to be on the screen is there, and every validation and every integration in every process of the script, and you need the users to give that to you.

Another part of the process automation development is we have things called playbacks and sprints that are part of the agile methodology. This requires your user's work day, your employee's work day, to be available and they need to be giving feedback. Again, if they don't have buy in or if they say, "I show up at 8:00, I do my job and I leave at 5:00", that's not going to be good enough to make sure this process automation project works.

Lastly, we need executive sponsorship. If it's coming from the top that this is important and they want to see this succeed, you won't have any long term buy in. That is just never going to work for a product to be successful.

Let's take a second to talk a little bit about playbacks. What is playback methodology and how does it work?

In short, a playback methodology is developing some pieces of code that your users will use, showing it to the users and getting…