El primer paso importa: cómo elegir tu primer proyecto de automatización.

Misión: Automatizar lo desconocido

En la Flota Estelar, nadie quiere ser el oficial de ingeniería que rompe todo en su primer día.

El teniente recién asignado, entusiasmado por demostrar su valía, decide automatizar la calibración de los sensores de largo alcance. Pero no consulta a nadie, sube su script al núcleo de control y… sin quererlo, deja a la nave ciega justo cuando entra en una anomalía gravitacional.

No fue malicia. Fue puro entusiasmo sin contexto.

Afortunadamente, el capitán no ordena su traslado a una colonia minera. En cambio, lo manda a entrenar con la ingeniera jefe: una veterana que ya vio más reinicios forzados que amaneceres en Risa.

— “Automatizar no es solo escribir código, teniente”, le dice. — “Es entender qué parte del sistema podés tocar, cuál no, y sobre todo: por qué importa eso.”

Juntos, revisan el catálogo de tareas repetitivas. Eligen una pequeña, aislada, pero importante: reinicializar las secuencias de diagnóstico de los replicadores. Una hora después, la tripulación disfruta de café caliente servido más rápido que nunca.

Ese día, el teniente no salvó la nave. Pero ganó la confianza del equipo. Y ese fue el verdadero comienzo de su misión.

Introducción

En el artículo anterior hablábamos de tener una visión estratégica para encarar la automatización de IT a nivel empresa, y los elementos principales de esa estrategia. También te hablamos de los 3 pilares: Procesos, Personas y Tecnología.

La Tecnología la presentamos en el primer capítulo de la serie: Ansible.

Hoy toca hablar de otros pilares importantes que son los Procesos, sobre todo los primeros procesos a automatizar, que van a marcar el tono del resto del camino: como se trabaja, con quién, qué se prioriza y que nivel de calidad se espera. También vamos a hablar de las Personas, con el enfoque en quienes van a elegir esos primeros procesos.

Si se eligen bien los proyectos, se acelera la adopción y se generan aliados. Por el contrario, si se elige mal, se genera rechazo, frustración o la percepción de “esto no sirve”.

Por eso le vamos a dedicar un artículo entero, para ayudarte a elegir los primeros proyectos que funcionen, entusiasmen y sumen valor.

Criterios para elegir un buen primer caso

¿Qué características deben tener los procesos candidatos? Te voy a presentar un marco sencillo, pero efectivo, las 4S (Sencillo, Seguro, Sostenible, Significativo):

Sencillo: técnicamente simple, sin dependencias complejas.

Sencillo no significa trivial. Un proceso sencillo es uno que está bien documentado, todos los pasos están definidos claramente y sus parámetros están establecidos para cada ambiente.

Seguro: no arriesga entornos críticos, fácil de probar y revertir. Si bien Ansible tiene mecanismos de salvaguarda antes de hacer cambios, es bueno que las primeras pruebas se puedan hacer en ambientes no productivos, y que sea fácilmente trasladables a ambientes productivos (idealmente cambiando solo parámetros vía variables) o que se puedan deshacer estos cambios fácilmente.

Sostenible: se puede mantener y extender fácilmente.

El ideal es que podamos usar módulos de Ansible para todos los pasos del proceso. Eso hace que el automatismo sea legible, y fácilmente sustentable, además de que podemos aprovechar una importante propiedad de la mayoría de los módulos de Ansible: la idempotencia.

Significativo: ahorra tiempo o resuelve una molestia real (visible para otros). Para que un proceso sea significativo, debe tener impacto para el negocio, más que para IT.

Candidatos que suelen fracasar

• Procesos muy complejos o con demasiados sistemas involucrados.
• Casos sin dueño claro o sin usuarios dispuestos a colaborar.
• Automatizar algo que ya está por desaparecer o ser reemplazado.

Ejemplos de buenos primeros pasos

• Despliegue de una aplicación web en ambiente de pruebas.
• Automatizar actualizaciones de seguridad.
• Provisión de cuentas de usuario en un entorno controlado.
• Backups automatizados de archivos de configuración.

Dos de estos casos los usamos en un proyecto de adopción de automatización. Uno fue el despliegue de una aplicación web (Java Enterprise en JBoss) que interesaba poder delegar a los desarrolladores para que actualizaran ambiente de test o desarrollo. El proceso estaba bien claro y había un referente del proceso, y el valor para el negocio era agilizar el trabajo de los desarrolladores y liberar al equipo de infraestructura de una tarea tediosa que no generaba valor.

El otro caso fue el aprovisionamiento de cuentas de usuario, que incluía también la configuración de teléfonos IP y accesos en distintos servicios. En este caso, el problema era que al tener varios pasos alguno se pasaba por alto al momento de ingresar un nuevo funcionario a la organización y eso generaba demoras y reclamos al equipo de IT.

¿Quién debería elegir los primeros procesos a automatizar?

Automatizar no es apretar un botón. Tampoco es una decisión que pueda tomar una sola persona desde su escritorio. Si queremos que los primeros pasos con Ansible generen impacto real y no se queden en una prueba de laboratorio, necesitamos que las personas correctas estén involucradas desde el principio.

¿Quiénes deberían participar?

• El consultor experto en Ansible: alguien con experiencia y conocimiento para aplicar la automatización con Ansible en distintos dominios. Este consultor además dirigirá los talleres necesarios, enseñará las mejores prácticas, y sobre todo, ayudará a seleccionar, entre todos los candidatos, cuáles son los mejores para comenzar.
• Alguien del equipo técnico: que tenga conocimiento de Ansible o esté dispuesto a aprenderlo. Idealmente, alguien que ya haya trabajado con shell scripts o tareas repetitivas y vea en Ansible una forma más estructurada y escalable de automatizar.
• Una persona del área funcional u operativa: que entienda el proceso como se hace hoy, con sus excepciones, atajos y dolores reales.
• Un referente de negocio o líder de área: que pueda conectar el esfuerzo con prioridades más amplias: reducir tiempos, liberar al equipo de tareas repetitivas o mejorar la trazabilidad.

¿Cómo deberían trabajar?

• Sesión de descubrimiento. Revisar procesos actuales, identificar tareas manuales, entender los sistemas involucrados. Preguntar: ¿esto se puede hacer con Ansible? ¿Hay módulos disponibles? ¿La tarea es lo suficientemente predecible como para declararla en YAML?
• Lenguaje común. No todos tienen que escribir playbooks. Pero todos deben entender qué se gana si automatizamos ese proceso con Ansible, qué riesgos evitamos, y cómo vamos a validar que funciona.

¿Por qué es importante este punto?

Porque Ansible no es mágico, pero bien usado, puede dar resultados rápidos, sostenibles y visibles. Y si el primer proceso se elige mal, no solo falla la automatización: se pierde confianza. La automatización con Ansible, para algunos de tus colaboradores va a implicar cambiar la forma de trabajar. Sin éxitos rápidos y consistentes, lo que vas a obtener es resistencia, en vez de colaboración.

Llamado a la acción

Como el teniente de la Flota, lo importante no es impresionar con fuegos artificiales, sino empezar con algo simple que funcione y construir confianza.

¿Ya hiciste tu primer proyecto? ¿Cómo resultó? Y si no, ¿Querés ayuda para identificar tu primer proyecto? Podemos charlarlo. A veces, el mejor primer paso es una buena conversación.

En nuestro próximo encuentro terminaremos la serie hablando del tercer pilar, las personas, y como generar una cultura de automatización, y derribar los silos organizacionales.