Algunas ideas sobre los proyectos de automatización de tareas y operaciones de IT

Algunas ideas sobre los proyectos de automatización de tareas y operaciones de IT

En un mundo cada vez más digitalizado, las empresas dependen en gran medida de sus sistemas de TI para mantenerse operativas y competitivas. Sin embargo, con el aumento constante de las demandas del negocio, muchas empresas se enfrentan a desafíos en la gestión, el mantenimiento de sus infraestructuras de IT y de la entrega de servicios cada vez más rápido.

Una y otra vez tuve la oportunidad de ver cómo las iniciativas de automatización de tareas u operaciones de TI se morían por diferentes motivos sin importar el tipo de organización en las que se intentan desplegar.

La automatización de tareas y operaciones de IT se ha convertido en una herramienta clave para mejorar la eficiencia, reducir costos y minimizar errores. En este post, quiero explorar algunas ideas sobre cómo los proyectos de automatización de tareas y operaciones de IT pueden ayudar a las empresas a mejorar su rendimiento y mantenerse al día con los cambios tecnológicos en constante evolución.

Así mismo, quiero explorar algunas ideas para que estos proyectos lleguen a ver la luz y los resultados al negocio sean algo evidente.

¿Por qué fallan estos proyectos de automatización?

El principal motivo, al menos desde lo que vemos en Wetcom , es que se quiere hacer mucho en poco tiempo. Vemos como se quieren encarar proyectos demasiado grandes con un equipo de trabajo tan reducido o dedicado al día a día que es muy difícil que puedan llegar. Más adelante en el artículo vuelvo a hablar sobre los equipos de trabajo.

Este tipo de proyectos necesitan ser recorridos, ganar experiencia, es por esto que siendo optimistas muchas veces se prometen cosas que simplemente son inalcanzables. Generalmente esto pasa cuando no se tiene experiencia y no se sabe medir el esfuerzo requerido para la tarea. Una vez empiezan a no cumplirse las fechas de entrega los proyectos arrancan a naufragar.

No voy a negar que tener una linda consola desde la cual poder hacer autoservicio o desde la cual lanzar una automatización es siempre conveniente. Pero esto no debe demorar o frenar los proyectos de automatización. Tranquilamente se puede trabajar en los flujos de trabajo con herramientas que ya tenemos, como VMware Orchestrator, y una vez que tenemos una buena cantidad de automatizaciones podemos pensar en autoservicio.

No hace falta tener portales elegantes siempre.

¿Cómo enfocar estos proyectos?

Acá te dejo algunas ideas sobre cómo podrías enfocar estos proyectos:

Reducción de KPIs

Todo esto se trata de reducción de números, generalmente días o semanas, desde que alguien del negocio pide algo y el área de IT lo entrega.

Tenemos que arrancar desde un baseline, un número de referencia que nos permita entender desde dónde estamos arrancando. Entonces tomar métricas de cuánto demoramos entregar cada una de las cosas que nos pide el negocio para después priorizar el trabajo.

Una vez que tenemos los números a optimizar, tenemos que analizar cuáles son los que más demoran y priorizarlos por probabilidad de ocurrencia. Esto quiere decir que por más que algo nos tome algunas semanas de entregar pero nos lo piden una vez cada 3 años, lo mejor que podemos hacer es arrancar por automatizar algo que nos tome menos tiempo pero que nos lo solicitan más seguido.

Básicamente estamos analizando el impacto que va a tener para el negocio si logramos automatizar tal o cual cosa. A esto, más adelante, tenemos que cruzarlo con el esfuerzo que nos va a tomar desarrollar la automatización. Porque por más que algo al negocio le sirva tenerlo automatizado pero nos demora un año esta automatización es claramente una luz roja.

Una vez que tenemos claro lo que queremos automatizar tenemos que descomponerlo en piezas más chiquitas con la duración de cada una. Vamos con un ejemplo de que nos piden un nuevo servidor, podríamos verlo de la siguiente manera:

  • Creación de la máquina virtual (3 días)
  • Instalación del sistema operativo, parches y aplicaciones (3 días)
  • Colocación del servidor en el sistema CMDB (1 día)
  • Colocación del servidor en el ciclo de monitoreo (3 días)
  • Colocación del servidor en la rutina de respaldo (2 días)
  • Colocación del servidor en el sistema de antivirus (1 días)

Los números y las tareas son completamente aleatorios y se que varían de empresa en empresa por lo que no trates de compararlo con lo que tenes, solo tratá de seguir el ejemplo.

Por lo que vemos en los números desde que se toma el pedido de un nuevo servidor, este va pasando por diferentes equipos (cada uno con su SLA), tenemos que podríamos tardar unos 13 días en entregar la máquina. Esto siempre y cuando cada uno de los equipos cumpla con su SLA, sino los tiempos podrían ser mayores.

Una vez que tenemos la descomposición del pedido tenemos que priorizar las tareas que más se demoran o cuyos SLAs se rompen seguido. Una vez tenemos esto priorizado, hay que comenzar con la automatización de cada una de estas tareas e ir lanzando pequeñas automatizaciones que vayan comenzando a liberar trabajo.

La idea no es apuntar a automatizar todo inicialmente sino ir automatizando pequeñas cosas y luego ir uniendo esas pequeñas automatizaciones serán unidas por un workflow que podrá entregar el flujo completo de trabajo una vez cada una de las automatizaciones esté lista.

Una vez que tenemos terminado el flujo terminado, probado y documentado, recién ahí pasamos a analizar y descomponer el siguiente flujo de trabajo para automatizar. Nunca antes.

Esto le permitirá a tu equipo de trabajo tener una sensación de que cumplieron un objetivo y que pueden moverse al siguiente. Sino vivirán con una sensación de que nunca terminan nada y puede aparecer la desmotivación.

¿Cuánto demoramos?

Algo que siempre nos gusta analizar en Wetcom es cuánto nos va a demorar hacer tal o cual cosa que queremos automatizar. Por un lado para medir el esfuerzo de lo que queremos automatizar, y por el otro para analizar si hacer la tarea manualmente no nos serviría para capacitar a algún miembro del equipo.


Como comenté anteriormente, en Wetcom tenemos muchos programas de formación de talento que necesitan tareas manuales para aprender. Es por esto que muchas veces dejamos algunas tareas que se podrían automatizar para que los miembros con menos experiencia del equipo puedan hacer sus primeras armas.

Es algo de la naturaleza de lo que hacemos nosotros y no necesariamente tiene que reflejar la realidad de tu empresa u organización.

¿Qué se necesita para que estos proyectos prosperen?

Primero que nada estos proyectos necesitan un sponsor fuerte que entienda que probablemente mientras el proyecto esté en marcha algunos tiempos se demoren si es que no hay un equipo de trabajo dedicado a esto.

Si la opción de extender los tiempos más de lo que ya se extienden se necesita tener un equipo de trabajo dedicado a esto. O bien se contrata un proveedor que automatice las cosas, o se contrata un proveedor para que tome las tareas del día a día de tu equipo mientras tu gente hace las automatizaciones.

Cualquiera de las dos opciones son válidas, va a depender mucho del contexto en el que se encuentre tu equipo y del respaldo que puedas conseguir para llevar adelante el proyecto.

Espero que este post te haya ayudado a conocer un poco más sobre los proyectos de automatización. Es solo una introducción para que puedas saber cómo pensarlos, o cómo los pensamos en Wetcom, y que desde ahí puedas comenzar a hacerte una idea de cómo planear el tuyo.

Fue un artículo largo, gracias por leer.

Cambio y fuera.

Victor M. F.

Senior Cloud Architect / PO

1 año

Muy interesante, aunque también hay que automatizar los procesos de desarrollo de los programadores: compilacion, dependencias, empaquetado, todo el testing, etc… incluso en algunos casos (todavia muy incipientes) la propia codificacion…

Inicia sesión para ver o añadir un comentario.

Más artículos de Nicolas Solop

Otros usuarios han visto

Ver temas