How can you identify IT processes that are best suited for automation?

Remember that the IT landscape is constantly evolving. What may not be suitable for automation today might become a strong candidate in the future as technology advances. Therefore, it's important to regularly review and update your automation strategy to take advantage of emerging opportunities.

Certainly, repetitive and predictable tasks are prime candidates for automation within Information Technology processes. These tasks follow consistent patterns, occur routinely, and have standardized workflows. Activities like routine backups, patching, provisioning, and monitoring that demonstrate regular, recurring patterns and require minimal human intervention or judgment are ideal contenders for automation. By implementing scripts such as Python, tools, or frameworks, these processes can be streamlined, optimizing efficiency and minimizing the potential for human error in routine operations and can save time.

At Akili, we advise clients to identify existing processes that have a combination of high frustration and high contribution to achieving short-term and medium-term goals. By addressing these first, clients reduce employee frustration while achieving organisational objectives.

Identifying processes within IT operations that are standardised and well-documented is crucial for successful automation; documentation and standardisation should be addressed and must come up to the first point. These processes adhere to established rules, policies, or best practices, featuring clear, detailed descriptions of their inputs, outputs, steps, and expected outcomes. Incident, change, and configuration management often fall into this category. Automating these processes through workflows, templates, or ticketing systems can improve efficiency and consistency, ensuring tasks are executed according to predefined protocols.

Following ITIL or some other workflow standard can help bring companies up to the next level where they can follow pre-existing models of best practices. Once the workflow is clearly defined, then teams can start working on "automating the boring parts".

I think this should be first point. Processes can be considered repeatable only when they are standardized and documented. and documentation is mapped to real world usage of a large timeframe and maximum diverse inputs. Only then a process should be considered for automation.

Automation is effective for IT processes that are measurable and testable, allowing performance tracking, validation, and verification. Processes like security scanning, compliance checking, and reporting often fall into this category and can be automated using metrics, alerts, or dashboards, enhancing accuracy and reliability.

If you dont have a way to test your automation and measure how it performs compare to current processes thats a problem. we do automation for optimization and we can only measure that when we can test it.

One of the key aspect is to find key measurable problem and write that problem in detail and divide it into smaller set of problem .Then,Identify which repetitive part can be automated and list the benefit corresponding to each use case.Never jump discussing about automation solution directly .

A note of caution. While you are attempting to focus on low-risk and high value, keep in mind to always have backups. a way to backtrace your steps and a plan to gradually introduce the automation. Step 1: prepare the automation solution. Step 2: Run it as a shadow to existing process. Step 3: Run it on a smaller percentage of workload and measure failures. Step 4: run it on all of workload but keep a few manual taskers to randomly validate the results. Step 5: full automation but with proper logs and backtracability in case of error. Step 6: Full reliance on automation. Each step should be a few weeks apart.

This strategy has always struck me as oxymoronic in the sense that we want the risk to be low while also producing a high result. Always treat low-risk automated procedures the same as high-risk ones. You won't become complacent in your deployment and cause an outage this way.

Always ask the team 'whats the risk' before attempting automation. And make sure to test in DEV first. If you don't have a reliable dev environment, considering creating that environment before focusing on automation. As automation can cause failures on a massive scale.

It is important to understand the process holistically and the current KPIS put in place, to measure the ROI. An optimum duration should be proposed for assessment and should include the various user perspectives such as the process owners, individual task owners, end users etc. The outcome of the assessment includes, recommended steps to address the questions on potential efficiencies.

In my opinion, this is the entrance gate to engineering an automation. Once you identify a process which you would like to potentially automate, walking its process from initiation to completion is key. Looking at upstream and downstream impacts, as well as points of input into the automation and where they are. A process CAN contain several automations, with an orchestration engine on top of it to navigate and invoke those automations in the proper order. Walking your process will identify consecutive and concurrent tasks to streamline and optimize delivery.

An 80% automated process today could be better than a 100% automated process with no foreseeable launch date. Look for an improvement on the current process instead of looking for a perfect solution. Adopt a continuous improvement methodology.

Let your consumers and data steer your automation exploration. Resist reductive perspectives by basing your goals on what seems technically or logistically achievable. Requiring a process to be totally defined, well documented, and low risk will greatly limit your ability to achieve meaningful impact. In my expirence, standardization and uniformity of process and product often come as a collaborative byproduct of the automation journey, rather than a prerequisite to it.

Automation may sound like a new term nowadays... but i have trying out several such tasks in early stages of my career... i was handling mozilla thunderbird support for a banking project and we observed huge spike in network traffic during the logoff time... then we found out that all the 260 users were sending their end-of-day report with huge attachments to their headoffice... then i installed a plugin that automates the email delivery at a specified time... this solved the bandwidth bottleneck scenario. I would consider automation as a user friendly solution and not as mandatory workaround for modern technological advances..