Lo que tu equipo de IT tiene que aportar de verdad a un programa de automatización

La respuesta corta: tu equipo de IT tiene que aportar cuatro cosas que ningún proveedor puede crear por sí solo: entornos que no sean producción pero se parezcan a ella, identidades de servicio con permisos acotados en cada sistema que toque la automatización, una vía de acceso a los datos ya aprobada por legal y seguridad, y una persona con nombre que pueda decidir sobre las tres anteriores. Todo lo demás —construcción, pruebas, monitorización, documentación, manuales operativos— puede recaer en el proveedor si así lo quieres. Esas cuatro cosas no, porque todas requieren a alguien dentro de tu organización con autoridad para conceder algo.

El coste en tiempo es más irregular de lo que la gente espera. La puesta en marcha inicial suele ser un puñado de sesiones de trabajo: una conversación de arquitectura, una sesión de identidad y acceso, un cuestionario de seguridad y un recorrido por los entornos. Después de eso, la implicación de IT cae a algo cercano al ruido de fondo: aprobar cambios, rotar credenciales y que te avisen cuando cambia un sistema de origen. Los programas que se atascan casi nunca se atascan por ingeniería. Se atascan porque nadie dentro de IT tenía autoridad para decir sí a una cuenta de servicio, o porque la revisión de seguridad empezó después de la construcción en lugar de antes.

Entornos: el bloqueo más habitual con diferencia

La automatización toca sistemas en secuencia, y no se puede probar esa secuencia con datos reales de forma responsable. Así que la primera petición es un entorno que no sea producción para cada sistema de la cadena: ERP, sistema de tickets, gestor documental, CRM, lo que sea que atraviese el flujo.

El problema honesto es que la mayoría de las organizaciones tienen un entorno de pruebas para uno o dos sistemas y nada para el resto. Existe un entorno de pruebas completo del ERP; el portal del proveedor que lo alimenta, no. Aquí es donde los programas pierden semanas en silencio, porque la carencia se descubre durante la construcción y no durante el alcance.

Lo que de verdad funciona:

• Inventaría los entornos antes de firmar el contrato de servicios, no después. Para cada sistema dentro del alcance: ¿existe una instancia que no sea producción, sus datos son representativos, y quién la actualiza?
• Acepta el acceso de solo lectura a producción como alternativa para los sistemas sin entorno de pruebas, junto con una regla estricta de que las escrituras solo van al entorno que no es producción hasta la puesta en marcha. Es un patrón legítimo, y los equipos de seguridad suelen aceptarlo cuando el límite es explícito.
• Decide quién es responsable de actualizar el entorno de pruebas. Un entorno de pruebas desactualizado produce una automatización que funciona de maravilla contra formas de datos que ya no existen.
• Consigue un entorno que se aproxime a la carga de producción si el proceso es de alto volumen. La lógica que funciona con diez registros y la que funciona con decenas de miles no es la misma lógica.

Si no puedes conseguir un entorno de pruebas utilizable para un sistema ni tampoco acceso de lectura, ese sistema no está listo para automatizarse. Dilo pronto y define el alcance en torno a eso, en lugar de construir sobre la esperanza.

Identidad y acceso: cuentas de servicio, no credenciales prestadas

Toda automatización necesita autenticarse como algo. La respuesta equivocada —y es extremadamente habitual— es ejecutar la automatización con las credenciales de un empleado concreto. Se rompe cuando esa persona se va, deja sin sentido el rastro de auditoría y mete el MFA de una persona en medio de un proceso desatendido.

Lo que IT tiene que aportar:

• Una identidad de servicio dedicada por sistema, con permisos acotados exactamente a las operaciones que realiza el flujo. No un rol de administrador "para ir tirando" que luego nadie recorta.
• Un método de autenticación que funcione sin supervisión: credenciales de cliente OAuth, autenticación por certificado, una identidad gestionada. Si un sistema solo admite MFA interactivo, señálalo pronto; hay formas de resolverlo, pero hay que diseñarlas, no improvisarlas.
• Un almacén de credenciales y una política de rotación. Decide dónde viven los secretos, quién puede leerlos y qué pasa el día de la rotación. Una automatización que muere en silencio cada noventa días es una fábrica de tickets de soporte.
• Decisiones sobre la ruta de red. IPs en lista blanca, VPN, endpoints privados o un intermediario dentro de tu perímetro. Suele ser el elemento con el plazo más largo porque cruza varios equipos.
• Una decisión sobre dónde se ejecuta la automatización: tu entorno cloud, tu infraestructura local o el entorno del proveedor. Esa única decisión determina la mayor parte de lo que preguntará la revisión de seguridad.

Acotar bien los permisos exige más trabajo por adelantado que conceder acceso amplio, y merece cada hora invertida. Es también la parte que la revisión de seguridad examinará con más dureza, así que hacerlo bien a la primera evita una vuelta atrás después. Nuestra propia postura y los controles con los que trabajamos están documentados en nuestra página de seguridad, que suele ser lo primero que entregamos a un equipo de seguridad.

Datos: forma, calidad y la vía legal

La automatización es tan buena como los datos que lee. El trabajo de IT aquí no es limpiar los datos —eso suele ser problema del responsable de negocio— sino dar un acceso honesto a ellos y una descripción honesta de los mismos.

• Muestras representativas, incluidos los casos feos. Los ejemplos limpios producen una automatización que solo gestiona ejemplos limpios. Queremos las facturas mal formadas, los registros con tres direcciones, los tickets donde alguien pegó un hilo de correo entero en un solo campo.
• Datos de volumen y forma: cuántos registros al día, cómo son los picos, cuántas variantes de cada tipo de documento existen en la práctica.
• Una decisión de clasificación. ¿El flujo toca datos personales, datos de salud, datos de pago o registros regulados? Eso determina la ubicación del procesamiento, la retención, el enmascarado y las reglas de registro, y hay que responderlo antes del diseño, no después.
• La vía legal para los datos que salgan de tu organización, si es que sale alguno. Un acuerdo de tratamiento de datos, una evaluación de riesgo del proveedor, a veces una evaluación de impacto sobre la privacidad. Esto va al ritmo de legal, no de ingeniería, así que ponlo en marcha en paralelo con la definición de alcance.

En los flujos con muchos documentos, esto importa más que cualquier otra cosa. El techo de precisión realista en la extracción de documentos y datos lo marca casi por completo lo variado y lo legible que sea el material de origen, y eso no se puede saber a partir de una descripción, solo de un conjunto de muestras.

Revisión de seguridad: en paralelo, no al final

El patrón que más tiempo desperdicia es el secuencial: definir el alcance, construir, y luego enviarlo a revisión de seguridad y descubrir que la arquitectura no es aceptable. La revisión de seguridad debería arrancar la misma semana que el diseño.

Cuenta con ejecutar alguna combinación de: un cuestionario de riesgo del proveedor, una revisión de arquitectura y flujo de datos, una revisión de la autenticación y del manejo de secretos, requisitos de registro y auditoría, y —según tu sector y la criticidad del sistema— una prueba de penetración o una revisión de código.

Lo que IT puede hacer para acortarla:

• Nombra al revisor de seguridad en el arranque e inclúyelo en la sesión de diseño. Una arquitectura diseñada con el revisor en la sala casi nunca suspende la revisión.
• Envía el cuestionario antes de que empiece la construcción. Los proveedores con programas serios los responden de forma rutinaria.
• Deja claro desde el principio lo innegociable: residencia de los datos, que no salgan datos de tu organización, una retención de registros concreta, proveedores de modelos aprobados. Son baratos de tener en cuenta en el diseño y caros de añadir después.
• Acuerda qué dispara una nueva revisión. Añadir un sistema al alcance probablemente sí. Cambiar un prompt o una regla de excepción probablemente no. Déjalo por escrito o cada cambio se convertirá en una negociación.

Gestión del cambio: la parte que decide si sobrevive

Una automatización no es un proyecto que termina. Es una pieza de software en producción que se apoya sobre sistemas que cambian sin pedirle permiso. IT es responsable de la interfaz entre ambos.

• Da de alta las automatizaciones en tu CMDB o catálogo de servicios con un responsable con nombre y una ruta de escalada. Si es invisible para tu equipo de operaciones, la romperá la primera actualización.
• Añade las dependencias de la automatización a la revisión de cambios de los sistemas de origen. La causa más habitual de rotura es un cambio rutinario en un sistema de origen del que nadie se dio cuenta de que tenía un consumidor.
• Decide dónde llegan las alertas —tu propia monitorización, la del proveedor, o ambas— y quién responde a las 2 de la madrugada, si es que alguien lo hace. Muchas automatizaciones de back office pueden esperar tranquilamente hasta la mañana. Decídelo de forma deliberada.
• Acuerda una vía de despliegue. De quién es la canalización (pipeline), quién aprueba en cada puerta, cómo es la reversión.
• Define la alternativa humana. Si la automatización cae durante un día, ¿qué hace la gente? Toda automatización necesita una respuesta, y "el equipo lo hace a mano" es perfectamente válida si el equipo todavía recuerda cómo hacerlo.

Qué se queda en IT y qué debería llevar el proveedor

La línea que mantenemos: IT concede y decide; el proveedor construye y opera. Si un proveedor le pide a tu equipo que escriba código de integración, depure sus excepciones o mantenga su infraestructura, el modelo operativo está mal planteado. Describimos cómo repartimos esto en la práctica en cómo trabajamos.

Cuando la respuesta es "todavía no hay que automatizar esto"

Algunos procesos no están listos, y empezar de todos modos cuesta más que esperar. Frena cuando:

• El proceso se está rediseñando activamente. Automatizar un flujo que va a cambiar en dos trimestres significa construirlo dos veces. Espera al rediseño y luego automatiza el resultado.
• El sistema de origen se va a sustituir. Las integraciones construidas contra un sistema que está de salida son trabajo desechable. Programa la automatización después de la migración.
• Nadie puede describir el proceso actual de principio a fin. Si tres personas dan tres versiones distintas de cómo se gestionan las excepciones, el proceso necesita documentarse antes de automatizarse.
• La única vía de acceso es extraer datos de una interfaz sin identificadores estables y sin previsión de API. Se puede hacer, y se rompe constantemente. Merece la pena para trabajo genuinamente de alto volumen; rara vez lo merece en otro caso.
• La calidad de los datos es mala y no tiene responsable. La automatización aplicada a datos malos produce malos resultados más rápido. Arregla el origen o acepta una ruta de excepciones pesada.
• IT no tiene capacidad para las sesiones de puesta en marcha en el próximo trimestre. Empezar una construcción que no puedes respaldar es una buena forma de acabar con un sistema sin dueño. Mejor esperar y hacerlo bien.

Ninguno de estos es un no definitivo. Son problemas de secuenciación. El error habitual es tratarlos como detalles que se resuelven durante la entrega, cuando en realidad son lo que determina si la entrega va a funcionar. Si estás valorando con qué proceso empezar, nuestra calculadora de valor es una forma razonable de comparar candidatos por esfuerzo y retorno antes de comprometer tiempo de IT, y nuestra página de la práctica de automatización de procesos explica en qué consiste el trabajo en sí.

Pasar por compras sin perder un trimestre

El retraso en compras es casi siempre trabajo que se podría paralelizar pero se ejecuta en serie. Pon en marcha la evaluación de riesgo del proveedor, el acuerdo de tratamiento de datos y el cuestionario de seguridad la misma semana en que empieza la definición de alcance; ninguno depende de que el diseño esté cerrado. Confirma quién da el visto bueno a una nueva cuenta de servicio y quién lo da a que salgan datos de tu organización; suelen ser personas distintas, y normalmente ninguna es el patrocinador del proyecto. Acota la primera fase lo bastante como para que pase la revisión como un único sistema delimitado y no como un compromiso de plataforma completa, y mantén el inventario de entornos delante del grupo como una lista viva con responsables y fechas con nombre. Cada elemento de esa lista es una dependencia dura, y los que no tienen un nombre al lado son los que se van a retrasar.

Si quieres una lista concreta para tu propio entorno en lugar de una genérica, repasaremos tus sistemas específicos, tu modelo de acceso y tu proceso de revisión, y te diremos qué necesitaríamos, qué no te pediríamos y dónde creemos que deberías esperar. Habla con nosotros y definiremos el alcance con tu equipo de IT presente desde el principio.

Preguntas que nos hacen sobre esto