Answering Automation - Project Planning Questions
In this series, we set out to answer some common strategic and project questions about Automation. In the previous blog posts, we’ve talked about what automation is, and how to decide what functions and processes should be automated. Now we are going to tackle project planning questions, or issues that come up once you the target of automation is chosen, such as:Where do you start?
How far do you go?
How do you know when you are done (at least for the moment)?
Previously, we’ve talked about some broad concepts, but these questions are a little more narrow and practical.
Let’s dig in!
Where do I start?
With automation, you always want to start by understanding the process you are automating. You need to be able to describe what happens at each stage of the process, either by building out a flow chart or by building out detailed user stories. You need to get a big picture of what the final process is like, without any automation or human judgment.
The biggest stumbling block to automation is that the process isn’t defined, or is defined poorly. When we map out processes with customers, we identify that steps of a process aren’t documented, or aren’t understood. To automate the process, you need to dig in and make sure everyone impacted by the automation has their needs represented in the process, and that all stakeholders agree on the outcome of the manually ran process.
Another trend is that of human judgment; a person operating a process will apply their best reasoning based on their experience, knowledge, and general understanding of the desires of the business and IT. Opinions are not repeatable, and this also means that the process will function differently with other people manning it. To automate it so that technology is operating the process, we need to make sure that all decision criteria gets documented, and the paths taken have clearly defined criteria.
Once you have all of this, you need to select a tool for automation. Azure Automation and Orchestrator are both great tools that run off of PowerShell, and allow for advanced Runbook automation; we use these the most, and they have built-in hooks into a lot of different technologies.
Which brings us to the final step of getting started; taking the process map you have, you need to identify what technologies you will be automating in, and which ones have your information that is required to make the process work.
Apps, which are off the shelf items that automate a process or function.
If you remember back in the first article in this series, we discussed three types of automation:
Integrations, which connect two or more apps.
Runbooks, which are more custom and top down.
When you are identifying the technologies, you also need to identify which types of automation you are going to use to automate which parts of your process maps.
Once this is all identified, you are ready to figure out how far you should go.
How far do I go?
Now that you have the Big Picture worked out, how do you know how far to go? More specifically, how much can you bite off at a time?
What is the biggest reason for the automation?
The answer is to look at the map you have made and look back at the sheet you filled out in determining what you should automate.
- Was it the time?
- The cost?
- The inaccuracy?
- Customer feedback?
- The level of manual involvement?
Select one or two of these as your primary factors.
With that in mind, look at the process and ask yourself, “What is the least amount of work I can do to reduce my pressing factors?” Tag the specific functions that contribute to your important factors, and define those as your
Phase 1, then continue out to identify a Phase 2, Phase 3, and so on – and when you think you have your steps mapped out to answer the important factor completely, then you should stop. Take your Phase 1 that is as far as you need to go.
When am I done?
The short, complete answer is never; as you can see from the previous answer, you can envision a lot of different phases for one set of pressing factors, and that establishes a long road in front of you.
But realistically, completing one phase is enough to be done for the time being. Then you want to start again, and identify if your important factors need to change – maybe your Phase 1 delivered enough value to answer the important factors, and you need to go and look at other factors and solve them. Or maybe you need to go to your Phase 2 because there is still a time/cost/satisfaction issue.
Ultimately, the goal is to identify value you can deliver, deliver it, and then reassess and determine what value you should deliver next. If these instructions are beginning to sound familiar, that is a good thing! That is the basis of both Agile Development and the ITIL Guide to Service Management and should be a guiding process in all parts of IT.
If you have any automation questions or comments please leave them in the form below and we would be happy to answer them, or contact us today!
Want to learn more about Business Process Automation?
Check out our blog post:
"Understanding the Power of PowerApps."
Download our free Getting Started with Business Process Automation Infographic
Posted by Brandon Stephenson
Brandon Stephenson is the Service Management & Automation Practice Lead working out of KiZAN’s Cincinnati office. His technical specialties are System Center Service Manager and System Center Orchestrator. He also has a deep experience with using ITIL to deliver practical IT Service Management solutions.