title: "Diagnóstico de automatización: las 8 preguntas que hacemos antes de proponer nada" slug: diagnostico-automatizacion-que-analizar excerpt: "La mayoría de proyectos de automatización que fracasan no fracasan por la tecnología. Fracasan porque nadie analizó el proceso antes de empezar. Estas son las 8 preguntas que hacemos en cada proyecto, en orden, antes de tocar ninguna herramienta." category: automatizacion tags: [automatizacion, diagnostico, metodologia, n8n, procesos] author: Flexum date: 2026-06-15

Diagnóstico de automatización: las 8 preguntas que hacemos antes de proponer nada

La conversación sobre automatización suele empezar en el lugar equivocado. El cliente nos describe el proceso que quiere automatizar, nosotros empezamos a pensar en qué herramientas usar, y dos semanas después estamos configurando un flujo de n8n para algo que, con un poco más de análisis previo, habríamos descubierto que no debería automatizarse todavía o que podría simplificarse antes de automatizarse.

La mayoría de proyectos de automatización que fracasan no fracasan por problemas tecnológicos. Fracasan porque nadie analizó el proceso primero.

Por qué los diagnósticos estándar fallan

El diagnóstico típico empieza con "¿qué herramientas usáis ahora?". Es la pregunta equivocada. Las herramientas son irrelevantes hasta saber qué problema real existe. Empezar por las herramientas sesga todo el análisis hacia las integraciones disponibles en lugar de hacia el valor real que puede generar la automatización.

La pregunta correcta es mucho más aburrida: cuántas veces, cuánto tiempo, quién lo hace, qué sale mal, con qué frecuencia cambia, de dónde vienen los datos, qué pasa si falla, quién lo mantiene.

Son 8 preguntas. Las hacemos en ese orden en todos los proyectos. No las reordenamos según lo que el cliente quiera escuchar.

Las 8 preguntas

1. ¿Cuántas veces por semana ocurre esta tarea?

El volumen es el primer filtro. Una tarea que ocurre 3 veces por semana raramente justifica el coste y la complejidad de automatizarla, a menos que el coste de cada error sea excepcionalmente alto.

La regla orientativa que usamos: menos de 10 veces por semana, la automatización rara vez tiene sentido puro en términos de ahorro de tiempo. Puede tener sentido por reducción de errores, pero eso lo determina la pregunta 4. Si el volumen es bajo y el coste por error también es bajo, la respuesta honesta es que no merece la pena.

Por encima de 50 veces por semana, la automatización casi siempre tiene sentido económico aunque solo se automatice el 60% del proceso.

2. ¿Cuánto tiempo lleva cada vez?

Volumen × tiempo = horas semanales totales dedicadas a esa tarea. Eso es el techo máximo del ahorro posible. Si alguien pasa 12 horas semanales en algo, automatizarlo hasta el 80% libera casi 10 horas. Si alguien pasa 45 minutos semanales, automatizarlo libera 36 minutos.

La variabilidad del tiempo también importa. Si la tarea siempre lleva entre 10 y 15 minutos es un proceso estable. Si a veces lleva 5 minutos y a veces lleva 2 horas, esa variabilidad es una señal de que el proceso tiene bifurcaciones complejas o excepciones frecuentes que no están documentadas. Alta variabilidad = más complejidad de automatización = más coste.

3. ¿Quién la hace y cuál es su coste por hora?

Esta pregunta tiene dos funciones. La primera es calcular el valor económico del tiempo liberado: el ahorro en euros por semana, no solo en horas. La segunda es detectar un problema organizativo que hay que resolver antes de automatizar.

Si la persona que hace esa tarea 20 veces por semana es el director general, el primer problema no es técnico. Es que el director general está haciendo trabajo administrativo. La automatización puede ser parte de la solución, pero primero hay que preguntarse por qué no la hace otra persona. Automatizar un proceso mal asignado es construir sobre una base rota.

El coste horario también determina la rentabilidad del proyecto. Una automatización que libera 5 horas semanales de un perfil técnico senior y otra que libera 5 horas semanales de un perfil administrativo tienen retornos muy diferentes.

4. ¿Cuántos errores se producen y qué cuesta cada error?

Esta es la pregunta más importante para los procesos de bajo volumen. Un proceso que ocurre 5 veces por semana no justifica automatización por ahorro de tiempo. Pero si cada error en ese proceso cuesta 2.000 euros en penalizaciones contractuales o en trabajo de corrección, y la tasa de error manual es del 10%, el coste esperado de los errores es 1.000 euros por semana. Eso justifica casi cualquier automatización.

La fórmula es: tasa de error × coste por error = coste esperado semanal de errores. Si ese número es alto, la automatización tiene valor aunque el volumen sea bajo.

La pregunta sobre el coste por error también incluye los errores que no cuestan dinero directo pero cuestan confianza del cliente, reputación o relaciones comerciales. Son más difíciles de cuantificar pero igualmente reales.

5. ¿Con qué frecuencia cambia el proceso?

Un proceso que cambia cada 3 meses no debería automatizarse todavía. Cada cambio en el proceso requiere modificar la automatización, y si la automatización está mal documentada o quien la mantiene no está disponible, el resultado es un flujo que funciona según las reglas de hace 6 meses aplicadas a un proceso que ya es diferente.

La señal de que un proceso está listo para automatizar es la estabilidad: lleva al menos 6 meses funcionando de la misma manera, y no hay cambios relevantes previstos en los próximos 6 meses.

Si el proceso es inestable porque está en proceso de rediseño o porque la empresa está creciendo y el proceso aún no está maduro, la recomendación es esperar. Estabilizar primero, automatizar después. El coste de automatizar un proceso que luego cambia es mayor que el coste de no haberlo automatizado.

6. ¿Hay una fuente de datos limpia y estructurada?

La automatización necesita datos. Si los datos que alimentan el proceso están en emails con distintos formatos, en hojas de cálculo editadas por varias personas, en PDFs sin estructura o en la cabeza de la persona que hace la tarea, la automatización no puede funcionar sin resolver primero el problema de los datos.

"Fuente de datos limpia" significa: un sistema único donde los datos entran de forma consistente, con el mismo formato, sin duplicados frecuentes, con los campos necesarios siempre presentes.

Si la respuesta a esta pregunta es "más o menos" o "depende", hay trabajo previo que hacer antes de automatizar. Construir un formulario de entrada de datos, estandarizar un proceso de registro, crear una base de datos que centralice la información dispersa. Ese trabajo previo tiene valor independientemente de la automatización posterior.

7. ¿Qué pasa si la automatización falla?

Esta pregunta distingue dos tipos de fallos con consecuencias muy diferentes.

Fallo silencioso: la automatización no ejecuta el paso esperado, pero nadie se da cuenta inmediatamente. Un email que no se envía, un registro que no se crea en el CRM, una alerta que no llega. El daño es real pero detectado con retraso.

Fallo activo: la automatización ejecuta una acción incorrecta con consecuencias difícilmente reversibles. Un reembolso enviado a quien no correspondía, un email enviado a la lista equivocada, un pedido cancelado que debería haberse procesado.

Los fallos silenciosos son molestos pero manejables. Los fallos activos con consecuencias irreversibles necesitan una capa de validación humana antes de que la automatización ejecute la acción crítica. No como excepción, sino como parte del diseño del sistema.

Si la respuesta a "qué pasa si falla" es "nada muy grave, se corrige fácil", la automatización puede ser más agresiva. Si la respuesta incluye "podríamos perder datos de clientes", "podríamos incumplir un contrato" o "podríamos tener un problema regulatorio", el diseño del flujo tiene que ser conservador con validaciones explícitas en los puntos críticos.

8. ¿Hay alguien que pueda mantenerlo?

Una automatización no es un proyecto que se entrega y se olvida. Los sistemas de los que depende cambian sus APIs, las condiciones del negocio evolucionan, aparecen casos nuevos que el flujo no contemplaba. Alguien tiene que estar disponible para hacer esas modificaciones.

Si la empresa no tiene capacidad técnica interna para mantener flujos de n8n o para hacer cambios básicos en un workflow, el diseño tiene que ser más simple, mejor documentado, con alertas claras cuando algo falla, y con un acuerdo de mantenimiento externo si el proceso es crítico.

No es una razón para no automatizar. Es una restricción de diseño. Un flujo más simple y bien documentado que el equipo puede modificar vale más que un flujo sofisticado que se convierte en una caja negra.

Cómo priorizar con las respuestas

Una vez respondidas las 8 preguntas, tenemos suficiente información para puntuar cada proceso candidato en 5 dimensiones: volumen, tiempo total dedicado, coste de errores, estabilidad del proceso y calidad de la fuente de datos.

Los procesos con puntuación alta en todas las dimensiones son candidatos claros para automatizar primero. Los procesos con puntuación alta en impacto (volumen × tiempo × coste de errores) pero baja en viabilidad (estabilidad baja, datos sucios) son candidatos para los que primero hay que resolver los requisitos previos.

Los procesos con impacto bajo, independientemente de su viabilidad técnica, no deberían automatizarse. El coste de diseñar, implementar y mantener una automatización de bajo impacto supera el beneficio incluso cuando es técnicamente sencilla.

La matriz de decisión

La forma más práctica de visualizar las respuestas es una matriz de dos ejes: impacto potencial (alto/bajo) en el eje vertical y viabilidad técnica actual (alta/baja) en el horizontal.

Alto impacto + alta viabilidad: implementar primero, aquí está el ROI más claro y más rápido.

Alto impacto + baja viabilidad: los requisitos previos bloquean la implementación. El trabajo ahora es resolver esos requisitos: limpiar datos, estabilizar el proceso, crear la fuente de datos. Una vez resueltos, pasan al cuadrante anterior.

Bajo impacto + alta viabilidad: tentadores porque son técnicamente fáciles, pero el retorno no justifica el esfuerzo. No automatizar.

Bajo impacto + baja viabilidad: descartar completamente.

Cuando algo que parecía automatizable no lo es

Sucede en todos los proyectos: hay un proceso que sobre el papel parece perfecto para automatizar, pero las 8 preguntas revelan un bloqueo real. El proceso cambia demasiado frecuentemente. Los datos son demasiado inconsistentes. El fallo activo tendría consecuencias que no queremos asumir sin validación humana.

La recomendación honesta en esos casos es no automatizar todavía. No porque no sea posible técnicamente, sino porque el coste de hacerlo mal supera el coste de esperar.

Un proyecto de automatización fallido tiene costes reales: el coste de implementación, el coste de los errores que genera mientras falla, el coste del tiempo dedicado a arreglarlo, y el coste en términos de confianza interna en el equipo hacia los sistemas automatizados. Ese último coste es el más difícil de recuperar.

Las 8 preguntas existen para evitar construir sobre cimientos rotos. No son un procedimiento burocrático. Son la diferencia entre una automatización que funciona durante años y una que se abandona en tres meses.