Top 10 IT Automation Mistakes & How To Avoid Them
Top 10 IT Automation Mistakes & How To Avoid Them
Introduction
Over the years, Kelverion has seen it all, from excessive employee-wide automated messaging to connecting
systems with people. We’ve seen many automation projects fail to achieve their potential or even grind to a halt completely, and the reasons for these IT automation mistakes are shockingly common.
With automation’s huge business benefits, committing some of these blunders has proved to be career limiting. Kelverion is often asked to step in and help a company get their automation projects back on track.
Here is Kelverion’s countdown of the top 10 IT automation mistakes and guidance on avoiding these blunders in your IT automation initiatives, enabling you to be your company’s automation hero.
10. Not having a test environment
Having a test environment seems pretty obvious to anyone in IT, but we often see companies implementing automation with only a production system; this is a big IT automation mistake.
The automation was initially only configured for a single use-case or was not considered critical, and the belief was that no testing methodology was justified.
Corners were cut, and money was saved; however, the result is that complex multi-system processes have become business-critical running.
At the same time, new automation topics and trial projects are being executed on the same platform.
In our experience, we’ve witnessed this result in production data being deleted or in one case, a faulty test runbook ending up in a runaway memory leak that took the whole automation system offline.
A successful automation implementation will grow from the first use-case into other areas, delivering more and more benefits. Plan for success and have a test environment in use from day one.
9. Lack of error handling
Kelverion is regularly asked to review and comment on automations built by customers. One of the top issues is that thought has only gone into designing the automated process and forming the required tasks. This assumes everything will happen correctly and follow the ‘happy path’.
The problem with this IT automation mistake is that part of the process could fail. Some of the reasons for errors are:
- Receiving the wrong inputs
- The user already exists
- There are no licenses available to assign to the new user
If no error handling is included in the runbook and there is a failure, IT will only be notified when a user flags that they didn’t get what they requested. As a result, a detailed debug exercise has to be conducted manually. Investing time now to capture errors and report them will save hours of heartache in the future. This also makes processes more reliable and easier to support.
8. Repeating yourself by not making things modular
An IT automation mistake we often encounter when reviewing automation deployments is a lack of planning.
The first process is developed, and then the next and so on. This lack of forethought means that everything is considered in isolation, and elements like service desk interaction are built directly into each automated process; rather than identifying many processes that need to interact with the service desk.
These tasks should be modularized so they can be reused.
In this example, each process builds indirect interaction with a service desk, duplicating effort each time. When the target system changes, new inputs or an API are needed, and every process must be updated.
With a bit of deliberation, hours can be saved by having a module to reuse so that when the target changes, only the module needs updating, not every process.
7. Limiting yourself to the automation available within an existing tool
Where companies fail to get the benefits of automation, this is often due to limiting themselves to an existing tool’s capabilities without considering the greater need. For example, when an organization looks to automate, for example, the new employee hiring at a basic level, this typically involves creating a user in Active Directory and doing some Active Directory group work. It’s possible to become fixated on these basic Active Directory parts of the user creation without thinking about the whole process because that’s what the tool can do.
The result is completing the other steps in the process manually. What about these other steps that are needed:
- Office 365 licenses
- Microsoft Teams account
- Phone setup
- Adding the user to Salesforce
- Setting up the VPN
- Ordering a mobile phone and PC
The outcome is a nightmarish mish-mash of part-automated steps and lots of manual intervention! The desire to automate is there, but be careful not to make the IT automation mistake of becoming blinkered around the capabilities of an existing tool and ensure all process steps are covered with automation.
6. Driving everything from your service desk catalogue offering
For automation to succeed, a simple way for users to view a list of tasks they can request, which can then be fulfilled automatically, must be provided.
Most service desks have a built-in service catalogue offering, but we regularly work with companies whose automation plans have stalled because of the service desk catalogue.
- This is usually because every service offering takes a lot of development time in the service desk;
- Integrating with and into the service desk to get the request is very complex because of how the service desk was designed;
- The service desk team is already stretched developing and supporting the base service desk capability, and the service catalogue development is a task too far.
- End users find the service desk wildly complex to use. ITSM’s are increasingly big beasts which need to be used regularly to understand the navigation.
Numerous companies making successful inroads on their automation journey have moved to a simpler Self-Servicecapability, outside the Service Desk, in something dedicated to automation.
This platform is then integrated back into the Service Desk at a base layer to raise standard incidents or changes and record what has been requested. This enables the Service Desk to keep its ServiceManagement role without the service catalogue overhead
5. Not using supported integrations
Connecting to other enterprise management systems is vital to automate processes when looking at any automation tool or technique. Therefore it’s essential to find out how many integrations are available and, crucially, if they are vendors supported.
Ready-built supported integrations keep costs down and makes automation quick to implement. Also, the likelihood of discovering bugs or snags in the integration purchased is reduced, as it will already be deployed in production elsewhere.
Sometimes employees create custom-built integrations, believing this will save their organization money. The downside is that these integrations take longer to produce and are without a proven track record. Increasingly, APIs are changing rapidly, particularly in Service Desks; if an integration is built in-house, the responsibility to maintain it lies with your organization. This is without taking into account other complexities that might ensue if the vendor decides to implement two-factor authentication in their API.
Some systems wrap other API calls with pseudo code to remove the need to learn the API programming syntax. However, a detailed understanding of how the individual API calls work is needed to use the functionality.
Many systems promote a suite of ‘community-built’ integrations which can be used. The danger with these is that the author is unknown, and there’s little indication of how well these integrations are developed or if they are being maintained. Using a solution like this would also run the risk that if it fails, often there isn’t anyone to call on for help and support. So, it’s important to judge integration needs when embarking on an automation project.
4.Doing it the hard way because it’s interesting
An automation project often starts with a senior technologist investigating automation options. Techies can be partial to looking for the technology that is believed to be the most interesting or appeals to their particular skill set, whether it’s development, coding, or something else.
This results in choosing a solution that is right for them as an individual but may not be something the rest of the business can drive or adopt.
Equally, what we’ve seen when looking at how to build an automated process are suggestions like, “oh, it would be good if we could connect into this, and maybe that,” and very quickly, the focus is shifted to delivering the best and perfect process, rather than what’s actually going to be practical for end users.
For example, one customer Kelverionworked with used Slack for their internal chat and messaging, and someone suggested the automation could send a Slack message when a server being patched has an error.
This makes perfect sense, but this swiftly escalated into:
“Wouldn’t it be a good idea if we send a Slack message before patching so that everybody knows the servers are goingto be patched?”
And then:
“Ohh, we should give them a countdown.”
Which culminated in sending Slack messages to everybody about all the servers that are to be patched:
- Eight hours before it happened
- Four hours before it happened
- One hour before it happened
- If there was an error
- After the patching to confirm the completion
When this was deployed, the recipients of these Slack communications were bombarded with messages that weren’t needed (or even wanted).
The feedback was that the team just needed to be told once. And even then, this wasn’t needed because the patching cycle always took place on the 3rd Wednesday of the month, so the conclusion was to notify recipients if there was an error for them to action/investigate.
The danger with planning is making automation hard because it’s more interesting; remember to put logic around it and be sensible.
Automation tools and technologies are necessary, but their implementation must be supportable.
To keep things as simple as possible, consider:
- Do we need to do all these steps in the process?
- Do users need to know a task will take place (now that it’s automated)?
- Or do we only care when it doesn’t happen?
Keep things just simple enough and no harder.
3. Using a tool without pre-built content
Automation tools are like a box ofLego™; anything can be built if the user knows how.
Many automation platforms are provided as a blank canvas, and it’s up to the user to create something (and, in some cases, figure out how to).
For this reason, be sure to enquire if the automation tool being investigated comes with ready-built content, i.e. a set of instructions on how to build something with all this Lego™, or even more desirable, a set of pre-built Lego™models which can be deployed,extended and adapted to the needs ofthe organization.
Ready-built content saves the user from reinventing the wheel and making the same mistakes as others did when they first started. Plus, this approach is rapid, allowing an organization to get the benefit of automation immediately.
2. Scripting your automation
When automation platforms were first created in 2005/2006, writing scripts for automated tasks was time-consuming and difficult to maintain and support.
Since then, Kelverion has worked with several companies struggling to extend the breadth of their automated processes or achieve automation benefits. More often than not, this is because the direction of their automation strategy was either writing scripts or using an automation tool that uses a code-based approach.
Various automation tools are available in the market, some of which utilize a custom pseudo programming language for building automation. While these languages may provide a slightly more supportable solution compared to basic scripting, they do not necessarily make the adoption or development process easier. In fact, they often require users to learn an entirely new skill set, adding complexity to the automation implementation.
On the other hand, certain service desks claim to offer native automation capabilities but primarily rely on executing actions from built-in workflows that ultimately run scripts.
This means that even though the user interface may be within the service desk environment, scripting remains the dominant method for automation. In contrast, other automation tools provide a graphical authoring approach.
This image-based methodology utilizes forms population and eliminates the need for advanced coding knowledge. With this approach, creating an automation runbook becomes simpler, and ongoing support becomes easier.
Understanding and debugging errors in a no-code approach doesn’t require extensive coding expertise, making the process more accessible to a broad range of team members.
This “no code” approach empowers those who deeply understand the processes to build automation. These individuals, often referred to as “CitizenDevelopers,” can therefore take ownership of automating workflow without having to rely on developers to interpret their requirements. This saves time and ensures the automation aligns closely with the intended goals.
Embracing citizen developers helps drive digital transformation in the business.
By adopting a no-code/low-code approach, organizations can leverage the expertise of their existing team and streamline the automation development process. It eliminates the need for extensive coding knowledge, making automation accessible to a wider audience and promotes efficiency and accuracy in automation implementation.
1.Not considering the bigger picture
The biggest IT automation mistake we encounter is not considering the bigger picture. The primary obstacle for organizations when attempting to leverage the benefits of automation or expand their reach is the lack of initial strategic planning. During the early stages of automation implementation, organizations often fail to consider the broader strategic vision of what could be achieved through automation.
It’s not unusual for businesses to become fixated on automating a single use-case or process and opt for a tool that exclusively caters to that specific area. For instance, Kelverion is assisting a company initially focused on automating Virtual Machine (VM)provisioning within its virtualinfrastructure. This firm acquired a toolthat purportedly offered broader automation capabilities but they soon discovered its limitations.
The tool performed well for provisioningVMs on a specific vendor platform but proved excessively complex for other tasks.
Kelverion is now working with this company to explore alternative automation technologies that can address all their use-cases while still accommodating
VM provisioning. Therefore, when seeking automation vendors, it is advisable to seek out IT process automation tools capable of automating beyond a single use-case.
Companies need to adopt a long-term perspective to maximize the benefits of automation. It should not be treated as a one-off sprint but as an ongoing journey to drive business advancement. Organizations should seek IT process automation tools that extend beyond one use-case to overcome the challenges above effectively.
Summary
In the past, numerous companies have experienced failures in their automation efforts, as they often approached it with a single objective in mind. However, today, the adoption of automation has gained momentum due to the push for digital transformation and its compelling advantages in terms of productivity, agility, and cost savings.
Organizations must recognize that it is not a matter of “if” but “when” they embark on their automation journey.
By viewing automation as a transformative process to revolutionize service delivery and allocate key resources to higher-value projects, companies can overcome past failures and reap the benefits of automation.
It is essential to consider the broader requirements and involve other departments in identifying areas that can be streamlined. Automation can potentially eliminate tasks that teams are eager to eradicate, creating opportunities for growth and innovation.
About Kelverion
Experts in Cloud, On-Premise and Hybrid automation, Kelverion provide solutions and integrations that remove the manual process tying up IT staff; transforming the productivity, efficiency, and supportability of IT automation. Our products utilise and enhance the power of Microsoft Azure and System Center Orchestrator.
Working closely alongside Microsoft we have developed our integrations and automation solutions to help bridge the gap between Microsoft’s automation platforms and third-party systems, in the process building key alliance partnerships with multiple vendors to ensure our products are fully certified.
Since 2010, Kelverion has expanded to become a global company, with offices now in the UK, Canada, and the US. Through this, we are able to offer and support products and professional services engagements to enterprise-level organisations no matter where they are.
There’s a smarter approach to IT Service Management
Get in touch to find out more
info@kelverion.com | US Tel: +1 289 801 0559 | UK Tel: +44 203 875 8035
Contents
Introduction
Not having a test environment
Lack of error handling
Repeating yourself by not making things modular
Limiting yourself to the automation available within an existing tool
Driving everything from your service desk catalogue offering
Not using supported integrations
Doing it the hard way because it’s interesting
Using a tool without pre-built content
Scripting your automation
Not considering the bigger picture
Summary
About Kelverion
Download Guide
