Getty Images/iStockphoto

Tres principales mitos de automatización empresarial que los CIO deben conocer

La automatización empresarial ofrece a las organizaciones una serie de beneficios potenciales. Pero, primero, los responsables de TI deben separar los hechos de los mitos.

La automatización empresarial –bajo múltiples variantes impulsadas por el márketing, como la hiperautomatización– vuelve a ser un foco de atención importante para la dirección de las empresas, especialmente para los CIO. No solo el departamento de TI gestionará las herramientas y su integración en otros sistemas, sino que las actividades del departamento de TI también serán un gran foco de atención para los esfuerzos de automatización en curso.

A medida que aumenta el frenesí de los proveedores en torno a la automatización, los CIO deben comprender las realidades de la automatización y sus límites, por qué la disciplina sigue siendo importante y por qué los scripts no desaparecerán.

He aquí tres mitos comunes sobre la automatización de los procesos de negocio y una mirada a lo que es realmente cierto.

Mito 1: TI elige el motor de la automatización empresarial

El objetivo de la automatización de la empresa es que no se trata solo de TI o para TI.

Es probable que el departamento de TI no haya elegido el sistema ERP o CRM, y no será el que elija las herramientas de automatización. Los líderes de otras líneas de negocio serán quienes seleccionen la herramienta de bajo código o sin código que TI se encargará de implementar. Harán sus elecciones con la aportación de TI, pero no para adaptarse a sus preferencias. El departamento de TI no debe esperar que sus preferencias en cuanto a los diversos controles del proceso de desarrollo se impongan necesariamente a las preferencias de otras líneas de negocio en cuanto a la facilidad de uso.

Los directores de informática deben explicar cuidadosamente por qué las características que hacen que la herramienta sea más segura y sostenible deben ser requisitos, y no solo características adicionales u opcionales.

Mito 2: Las herramientas de bajo código/sin código eliminan la necesidad de educación y disciplina

Las recientes iteraciones de los sistemas de bajo código/sin código pueden hacer más que las generaciones anteriores para poner barreras al trabajo de los desarrolladores ciudadanos. Estos sistemas pueden hacer esto sin paralizar la capacidad de los desarrolladores para crear automatizaciones. Pero estas herramientas no obvian la necesidad de educar sobre cómo utilizarlas o la disciplina en su uso.

El departamento de TI no tendrá que hacer desfilar a cohortes de empresarios por un campo de entrenamiento de seis semanas, como hacían las generaciones anteriores, para iniciarlos en los misterios de SQL. Pero los tecnólogos seguirán necesitando establecer múltiples canales de apoyo para el aprendizaje. Esto puede adoptar diversas formas, desde la asistencia a clases presenciales, si las condiciones de la pandemia lo permiten, hasta la orientación por chat de expertos en Slack, Teams o Glip.

Disponer de varios canales para aprender sobre la automatización empresarial es importante porque los estilos de aprendizaje varían según la persona, al igual que las velocidades de aprendizaje. Esos canales de chat grupales también sembrarán el proceso de educación lateral y de compañeros que se enseñan unos a otros. El aprendizaje colaborativo suele ser el principal medio de difusión de conocimientos sobre herramientas específicas. También fomenta la voluntad de sumergirse realmente en la automatización de los procesos empresariales.

Mito 3: La automatización empresarial erradicará el scripting

No existe un motor mágico de automatización empresarial que hable con todo, sobre todo en el ámbito de los dispositivos de red y seguridad.

Los ingenieros, analistas, especialistas en operaciones y administradores continuarán con la automatización ad hoc utilizando el método antiguo: escribir scripts. Incluso cuando exista una plataforma de automatización más amplia, una tienda de TI de cualquier tamaño generará scripts en PowerShell, PERL, Python o en otras plataformas y, muy probablemente, en varias de ellas.

Para elevar el nivel de madurez de este tipo de operaciones de scripting, los responsables de TI deben asegurarse de que se aplica cierta disciplina a la situación. En concreto, tienen que impulsar los siguientes barandales:

Gestión del código. Un repositorio con función de check-in y check-out y control de versiones ayuda a evitar la confusión sobre qué versión de un script es correcta y está actualizada. Esto es especialmente importante para las secuencias de comandos que se utilizan con frecuencia, regularmente o cíclicamente, por ejemplo, mensual, trimestral o anualmente.

Un conjunto de herramientas comunes. Una plataforma única o, al menos, un conjunto de herramientas bien definidas permite a la gente cruzar sus conocimientos para poder entender el código de los demás. Esto significa que pueden modificar el código de los demás para hacer frente a los cambios en el entorno o en el proceso que el script debe automatizar.

Estos estándares de codificación comunes también permiten al creador original del script volver a su propio trabajo y modificarlo meses o años después de haberlo creado.

Gestión de cambios. El personal de TI debe seguir los procedimientos normales de gestión de cambios para las modificaciones de los scripts, especialmente cuando un script impulsa un proceso empresarial crítico. Cualquiera que quiera modificar un script utilizado para gestionar los sistemas de producción debe tener una razón declarada, una fecha de uso prevista para la nueva versión y un plan de reversión en caso de que haya un problema imprevisto.

Cuando los equipos de TI ven la automatización de la empresa de una manera clara, es más probable que creen un despliegue exitoso y estén más satisfechos con el proceso.

Investigue más sobre Inteligencia artificial y automatización

ComputerWeekly.com.br
Close