3 Considerations Before You Automate or Adjust Automation

“Practice does not make perfect. Perfect practice makes perfect.” —Vince Lombardi

This was a quote from my high school band teacher (oh, and Vince Lombardi.) I understood it then and I understand it even better now—A bad approach will yield bad results. With our incredible leaps in technology and process management, automation has become a very hot topic. Every company is or should be looking for ways to automate as many process areas as possible. When executed correctly automation can lower labor costs, increase productivity, raise customer satisfaction, and provide a clear understanding of how a specific process operates for continual service improvement. When executed incorrectly, every single one of these benefits is instead turned into their counterpart detriments. Labor costs increase, productivity drops, customer satisfaction drops, and knowledge about the process becomes unclear.

How do we avoid this?

It’s actually pretty clear. Know what to automate, why it is being automated, and how you plan to handle the automation. While these seem like simple concepts, many times organizations don’t look deeply enough into them and end up with more trouble than they were expecting. Let’s look at them:

1. What Are We Going to Automate?

Not every process area should be automated, and not every process section can be automated. We cannot automate areas or processes that require an input that is conditional on unforeseeable situations. Take a password reset for instance; A ticket is opened, the customer is recorded, the password is reset, and the ticket is closed. Organizations can now use customer-facing password reset tools to avoid this need altogether. However, every Service Desk will receive the occasional call about it. So, this is an opportunity to create a macro, function, stored procedure, or whatever the tool may call it to click a button and create the ticket, classify it, have the customer auto-filled, a description pre-populated, and mark it as closed with the appropriate closure code. This is possible as it is repeatable and reliable. The same cannot be said about a “blank screen” incident or a “need a computer” request. Those are completely dependent on the situation and may require actions that are specific to that instance, and we may not be able to plan for every occurrence. If an organization’s password resets (for some reason) required approval, then the pre-approval section could become automatable, but the post-approval actions could have their separate automation and the approval process would be its process.

Remember the caveat mentioned before, “…conditional on unforeseeable situations”. If we can determine the criteria for each situation (this is key) and store it in an easily referenceable place, we can then automate if the information is available. Keep in mind that, for this to be successful, we must remember to look at each criterion and their respective actions should we ever change even a single criterion or subsequent action, as they may overlap or interfere with each other. 

2. Why Are We Automating This?

The answer to that one sounds almost comical in its simplicity. “Why, fewer button clicks and interaction of course!” Wrong. There are always other concerns that must be addressed when automating. One example is reporting needs. While there are others that an organization may concern themselves with, this should always be at the top of the list.

Example: A project manager went to a developer and requested a process be added that would allow a purchasing tool to be able to receive an order and close all the related line items on that order. The developer creates it. When the project manager clicks the button to receive, it indeed makes the entire part of that process faster. Every line item is closed, and the manager didn’t have to go through them one at a time. Then the manager realizes that it never decremented the order from the stock room, and there was no tracking that showed assets related to the purchase order.

In the above example, there were not enough details given to the developer to properly automate the process section. That’s why this question is so important and not as simple as it might seem. In fact, they were automating this process so that the manager did not have to close all the line items individually in addition to being able to report on which assets were fulfilled from which purchase request and so stock was controlled via the system, not an individual stock person. Painstakingly specific details about the purpose of the automation are needed to properly implement the automation. Which leads into…

3. How Are We Going to Automate This?

Given that we now know the complete purpose of the automaton and what exactly is being automated, we can decide how the automation will take place. Apart from what tools to use, we should also focus on specific interactions. If one of the purposes is to make the process faster to complete for a password reset, we may not want to implement a button that can be clicked that will ask “Who is the customer”, followed by “What password are they trying to reset?”, followed by another that says “Please describe the password reset”, and yet another that says “Please provide a close description”. This almost certainly won’t improve the speed at all if the technician or customer must answer the same amount of questions, or close to it, as they would normally. Automation should focus on ensuring that the minimum amount of input is being requested while providing generic answers for the non-reporting data. By that, I mean that in anything where “close enough” is acceptable, “close enough” should be used. This is also where we want to watch out for user error. Make sure that there are a few places for free-form text and places to cancel as possible. If we do need places to cancel the process, we need to ensure that we have not made changes to existing data that might leave an asset or other record orphaned or modified unnecessarily.

As stated at the beginning, all these questions seem simple, but assumptions and less than stellar documentation/details can be the downfall of the entire process. If successfully implemented, you will have a process that can be easily modified and expanded upon and a good template for how to roll out automation across other objects as well.


About the Author
Thomas Scheel is a consultant with over four years of Cherwell configuration experience. He has implemented Cherwell across multiple industries and continued with many clients on specialized customizations. He was a speaker at the 2017 Cherwell Global Conference and a Cherwell Certified Instructor.

By Thomas Scheel | January 10th, 2020 | 0 Comments