Getty Images/iStockphoto
Top 3 enterprise automation myths CIOs should know
Business automation offers organizations a number of potential benefits. But first, IT leaders should separate the facts from the myths.
Enterprise automation -- under multiple marketing-driven variations on the theme, such as hyperautomation -- is once again a major focus for corporate leadership, especially CIOs. Not only will IT be managing the tools and their integration into other systems, but IT's activities will also be a big focus for ongoing automation efforts.
As the vendor feeding frenzy around automation ramps up, CIOs need to understand the realities of automation and its limits, why discipline is still important and why scripts won't go away.
Here are three common myths about automating business processes and a look at what's really true.
Myth 1: IT gets to pick the engine of enterprise automation
The point of enterprise automation is that it is not just about or for IT.
IT likely didn't choose the ERP or CRM system, and IT won't be the one to choose the automation tools. Leaders from other lines of business will be the ones to select the low-code or no-code tool that IT will be charged with implementing. They'll make their choices with IT's input but not to suit IT's preferences. IT should not expect that its preferences regarding various guardrails on the development process will necessarily trump other business lines' preferences concerning ease of use.
CIOs must carefully explain why features that make the tool safer and more sustainable should be requirements, not just bonus or optional features.
Myth 2: Low-code/no-code tools eliminate the need for education and discipline
The recent iterations of low-code/no-code systems certainly can do more than earlier generations to put guardrails around the work of citizen developers. These systems can do this without crippling the developers' ability to create automations. But these tools don't obviate the need for education on how to use them or discipline in their use.
IT won't need to march cohorts of businessfolk through a six-week boot camp, as earlier generations did, to initiate them into the mysteries of SQL. But technologists will still need to set up multiple channels of support for learning. This can take a number of forms, from full in-person classroom handholding, as pandemic conditions allow, to expert chat guidance in Slack, Teams or Glip.
Having multiple channels for learning about business automation is important because learning styles vary by individual, as do learning speeds. Those group chat channels will also seed the process of lateral education and peers teaching each other. Collaborative learning often turns out to be the primary means of spreading specific tool knowledge. It also fosters the willingness to actually dive in and start automating business processes.
Myth 3: Enterprise automation will eradicate scripting
No magical business automation engine talks to everything, especially everything in the arena of network and security appliances.
Engineers, analysts, operations specialists and administrators will continue ad hoc automation using the old-fashioned method -- writing scripts. Even when a broader automation platform is in place, an IT shop of any size will generate scripts in PowerShell, PERL, Python or a number of other platforms and most likely, in several of them.
To raise the maturity level of these kinds of scripting operations, IT leaders should make sure there is some discipline applied to the situation. Specifically, they need to push for the following guardrails:
Code management. A repository with a check-in and check-out feature and version control helps prevent confusion about which version of a script is correct and up to date. This is especially important for scripts used frequently, regularly or cyclically, for example, monthly, quarterly or annually.
A common tool set. A single platform or, at least, a well-defined set of tools enables folks to cross-train enough to be able to understand each other's code. This means they can modify others' code to deal with changes in the environment or in the process the script is supposed to automate.
Common coding standards such as these also better enable the original script creator to come back to their own work and modify it months or years after creating it.
Change management. IT staff should follow normal change management procedures for script changes, especially when a script drives a critical business process. Anyone who wants to modify a script used to manage production systems should have a stated reason, a targeted use date for the new version and a rollback plan should there be an unforeseen problem.
When IT teams view enterprise automation in a clear-eyed manner, they'll be more likely to create a successful rollout and be more satisfied with the process.
