Evaluación Comparativa entre N8N y Procesos Manuales para la Automatización de Procesos en un Proveedor de Servicios de Internet en Ecuador

Comparative Evaluation between N8N and Manual Processes for the Automation of Processes in an Internet Service Provider in Ecuador

Julio Javier Villares Jimenez1*

Autores

Damar Alejandra Taylor Vivanco1,2

Jorge Luis Vinueza-Martínez3

1 Universidad Estatal de Milagro, Facultad de Posgrado, Milagro, Guayas, Ecuador.

2 Instituto Superior Tecnológico Bolívar Madero Vargas, Machala, El Oro, Ecuador.

3 Universidad Estatal de Milagro, Facultad Ciencias e Ingeniería, Milagro, Guayas, Ecuador.

*Autor para correspondencia

Comó citar el artículo:

Villares Jimenez, J. J., Taylor Vivanco, D. A. & Vinueza-Martínez, J. L. (2026). Evaluación Comparativa entre N8N y Procesos Manuales para la Automatización de Procesos en un Proveedor de Servicios de Internet en Ecuador. Informática y Sistemas, 10(2), 161-183. https://doi.org/10.33936/isrtic.v10i2.8608

Enviado: 25/07/2026

Aceptado: 27/08/2026

Publicado: 07/09/2026

dtaylorv@unemi.edu.ec

jvinuezam@unemi.edu.ec

jvillaresj@unemi.edu.ec

Resumen

La automatización de procesos internos en Proveedores de Servicios de Internet (ISP) es un factor determinante para mejorar la eficiencia operativa y reducir errores humanos, en organizaciones dependientes de tareas manuales y repetitivas, en el presente estudio se evalúa comparativamente los procesos manuales, frente a la implementación de N8N en tres procesos internos críticos de un ISP ecuatoriano con presencia en varias ciudades del país, mediante un enfoque cuantitativo-descriptivo con diseño comparativo no experimental, aplicado a 28 colaboradores de seis áreas funcionales bajo un diseño censal. Los procesos manuales presentaron tiempos de ejecución entre 45 y 120 minutos, tasas de error de entre el 30% y el 60% según el proceso, y una media de percepción de usabilidad de 1.76 sobre 5, mientras que N8N redujo los tiempos de ejecución en más del 97% y elevó la usabilidad a 4.27, además de incrementar la tasa de éxito operativo en los tres procesos evaluados. La prueba Z de proporciones confirmó que la satisfacción alta hacia N8N es superior al 80% con Z=5.92 y p<.001, mientras el proceso manual resultó inferior a ese umbral con Z=-18.59 y p<.001, el análisis del esfuerzo tecnológico y el costo de oportunidad mostró que el beneficio temporal obtenido compensa la inversión técnica requerida, especialmente en los procesos de ejecución diaria, con ello, se logró una reducción de más del 97% en los tiempos de ejecución y una satisfacción superior al 80% de aceptación estadística, demostrando que N8N es una alternativa viable y sostenible para ISPs medianos.

Palabras clave: Automatización de procesos; N8N; Eficiencia operativa; Proveedor de Servicios de Internet; Low-Code.

Abstract

The automation of internal processes in Internet Service Providers (ISPs) is a key factor in improving operational efficiency and reducing human error in organisations dependent on manual and repetitive tasks. This study evaluates the implementation of N8N in three critical internal processes of an Ecuadorian ISP with a presence in several cities in the country, comparing manual processes with the implementation of N8N. A quantitative-descriptive approach with a non-experimental comparative design was applied to 28 employees from six functional areas under a census design. Manual processes took between 45 and 120 minutes to complete, had error rates of between 30% and 60%, depending on the process, and had an average perceived usability score of 1.76 out of 5. Meanwhile, N8N reduced execution times by more than 97% and increased the usability score to 4.27, as well as raising the operational success rate in the three processes evaluated. The Z-test for proportions confirmed that satisfaction with N8N is above 80% with Z=5.92 and p<.001, while the manual process was below that threshold with Z=-18.59 and p<.001. The analysis of technological effort and opportunity cost showed that the temporary benefit obtained compensates for the required technical investment, especially in daily processes. Thus, a reduction of over 97% in execution times and a satisfaction level above 80% was achieved, demonstrating that N8N is a viable and sustainable alternative for medium-sized ISPs.

Keywords: Process automation; N8N; Operational efficiency; Internet Service Provider; Low-Code.

161

1. Introducción

La transformación digital no consiste únicamente en sustituir herramientas tradicionales por tecnologías más recientes, como sostiene Vial (2019), estos procesos implican una reconfiguración profunda de las estructuras, estrategias y formas de creación de valor dentro de las organizaciones, por ello, también exige reconsiderar cómo se administra el tiempo, se distribuye el conocimiento y se asignan responsabilidades en los procesos. En esta línea, Syed et al. (2020) señalan que las tareas repetitivas y basadas en reglas pueden automatizarse para reducir cargas operativas y aprovechar de manera más eficiente las capacidades humanas, entendiendo que automatizar redefine la participación de las personas en el proceso, por otro lado, Raisch & Krakowski (2021) sostienen que la tecnología puede complementar el trabajo humano, sin reemplazar la interpretación, la creatividad y el juicio profesional para las decisiones que no se pueden reducir a procedimientos mecánicos.

Esta necesidad se nota sobre todo en sectores técnicamente complejos, donde la continuidad del servicio depende de la velocidad y la precisión con que se ejecutan las operaciones, y de que cada paso quede registrado. La transformación digital empuja a estas organizaciones a dejar atrás procedimientos fragmentados y avanzar hacia procesos sistematizados, medibles y verificables (W. L. Huang et al., 2024). Por esta razón, la automatización se ha consolidado como una estrategia relevante para incrementar la eficiencia operativa, reducir errores y fortalecer la capacidad de respuesta institucional (Gómez Gandía et al., 2024). La evidencia procedente en diferentes sectores, tales como financiero, sanitario y tecnológico demuestra que la incorporación de automatización robótica de procesos Robotic Process Automation (RPA) y de soluciones low-code/no-code puede generar reducciones sustanciales en los tiempos de procesamiento y en la carga asociada a las tareas manuales (Curty et al., 2023).

En este contexto, el paradigma low-code cambia la relación entre el conocimiento técnico y la creación de soluciones informáticas. Estas plataformas arman flujos automatizados combinando nodos, reglas y eventos en una interfaz visual, por lo que casi nunca hace falta programar a un nivel avanzado (Ajimati et al., 2025). Esto reduce la barrera técnica para construir integraciones complejas entre sistemas, de modo que equipos sin formación especializada en desarrollo pueden integrar aplicaciones, bases de datos, interfaces de programación de aplicaciones (API) y otros servicios heterogéneos (Shi et al., 2025).

Sin embargo, la relevancia de una tecnología no puede determinarse únicamente por sus posibilidades teóricas, sino por su capacidad para resolver problemas concretos, funcionar en condiciones reales y producir mejoras verificables, un principio que cobra relevancia en los ISP, pues estos operan bajo acuerdos de nivel de servicio (SLA) que exigen continuidad operativa y respuesta oportuna a incidentes (Rejeb & Keogh, 2021). A diferencia de sectores más estables, los ISP gestionan de forma simultánea infraestructura distribuida, soporte técnico en tiempo real, cumplimiento ante la Agencia de Regulación y Control de las Telecomunicaciones (ARCOTEL) en Ecuador, y talento humano en múltiples sucursales (Katsonis et al., 2018).

Pese a esta complejidad, la evidencia empírica sobre automatización de procesos internos en ISP latinoamericanos continúa siendo limitada. Larios Soldevilla & Atoche Socola (2023) documentaron RPA en telecomunicaciones sudamericanas y banca, con mejoras contables limitadas a grandes corporaciones, este enfoque deja en segundo plano a los ISP medianos. Annarelli et al. (2022) y Malik et al. (2021) coinciden en que el posicionamiento estratégico de la automatización robótica fortalece la resiliencia organizacional incluso en empresas de tamaño mediano, sin que hasta el momento existan herramientas específicas evaluadas para este segmento en economías emergentes. Incluso cuando aparece un estudio centrado en un ISP regional, como el de Pflughoeft et al. (2025) sobre predicción de abandono de clientes en un proveedor de acceso inalámbrico fijo en Estados Unidos, el foco sigue estando en la analítica comercial y no en la eficiencia de los procesos operativos internos, que es precisamente el vacío que aborda este estudio.

La investigación analiza el caso de un ISP ecuatoriano con más de trece años de trayectoria, presencia en siete ciudades del país y un datacenter propio. La organización atiende aproximadamente 68 mil clientes activos entre los segmentos residencial y corporativo, con una plantilla cercana a los 300 empleados, conformada por una infraestructura que combina fibra óptica propia, servidores in-house y servicios en la nube, y su portafolio incluye desde conectividad dedicada hasta ciberseguridad y streaming, lo que lo sitúa como un operador de tamaño mediano con una base tecnológica y comercial diversificada. El diagnóstico inicial encontró que varias áreas trabajaban con procesos manuales y repetitivos, con pocas integraciones e ingresos de datos que carecían de mecanismos de sincronización automática, las incidencias no contaban con trazabilidad formal, la verificación de logs no estaba sistematizada, los reportes consumían entre 10 y 15 horas semanales de personal administrativo, y la mensajería interna se manejaba de forma informal. Esto se traducía en pérdidas de tiempo, errores de transcripción, datos duplicados, fallas en la auditoría y una baja capacidad de respuesta ante eventos críticos: la tasa de error iba de 30% a 60%, con ciclos de ejecución de entre 45 y 120 minutos, la diferencia es notable si se compara con automatizaciones recientes en el sector público ecuatoriano, donde operaciones que antes tomaban minutos ahora se resuelven en segundos (Tenecela Tocto et al., 2026).

Para Moreno (2025) N8N es una plataforma de automatización basada en workflows, pensada para integrar sistemas, APIs y servicios sin necesidad de programación compleja. A diferencia de las soluciones RPA tradicionales, la plataforma puede desplegarse en servidores administrados por la propia organización, incorpora mecanismos de autenticación OAuth2, control de acceso por roles (RBAC) y orquestación de eventos internos o externos. Estas características responden a dos de las preocupaciones más relevantes en la adopción de plataformas low-code: la interoperabilidad entre sistemas y la seguridad de los datos procesados (Shi et al., 2025). En consecuencia, su pertinencia no radica únicamente en la facilidad para construir automatizaciones, sino en la posibilidad de gobernar, supervisar y auditar los flujos implementados.

La arquitectura orientada a eventos de N8N resulta especialmente adecuada para el entorno de los ISP, donde la utilidad de la información suele depender del momento en que esta es detectada y comunicada. En la gestión de redes, detectar a tiempo eventos críticos, como la pérdida de paquetes por congestión, es determinante para mantener la continuidad del servicio (He et al., 2025). Mientras un procedimiento manual depende de la disponibilidad, atención y experiencia del operador, un flujo automatizado puede ejecutar validaciones, registrar resultados y generar alertas bajo reglas previamente definidas (Cascais Brás et al., 2025).

La revisión de la literatura reciente, incluida la revisión sistemática desarrollada por Ajimati et al. (2025) sobre la adopción de tecnologías low-code/no-code, permite identificar investigaciones sobre RPA, automatización cognitiva, integración de sistemas y experiencia del usuario. Por otro lado, el análisis de los estudios realizados evidenció una ausencia de automatizaciones relacionadas con procesos internos de los ISPs en Latinoamérica dentro de su entorno productivo. En la Tabla 1 se presentan los hallazgos identificados, aportes y las limitaciones que mantienen la literatura con relación al problema abordado.

Los estudios revisados coinciden en algo: la automatización en los ISP latinoamericanos sigue siendo fragmentada. Ni siquiera las propuestas más recientes sobre automatización cognitiva superan este límite, manteniéndose en lo conceptual y no aportan evidencia empírica en entornos productivos reales (Patrício et al., 2025). De ahí surgen tres dimensiones que sustentan la originalidad de este estudio:

• Gap 1 Especificidad tecnológica: La primera brecha es de carácter tecnológico, donde Curty et al. (2023) destacan los beneficios de las plataformas low-code/no-code, y algo similar plantea Moreno (2025) sobre la flexibilidad, soberanía de datos y arquitectura modular de N8N, siendo ambos estudios un enfoque más general o técnico-conceptual, a diferencia de Kokina et al. (2026) donde sí analizan la gobernanza de RPA, pero no comparan empíricamente N8N con los procesos manuales a partir de datos de campo y métricas cuantitativas sometidas a análisis estadístico inferencial.

• Gap 2 Especificidad sectorial: En este apartado la literatura de automatización se concentra en los sectores financiero (F. Huang & Vasarhelyi, 2019; Kokina et al., 2026), de salud (Barra et al., 2025) y público, así como en grandes corporaciones de telecomunicaciones y banca (Larios Soldevilla & Atoche Socola, 2023), pero el análisis en ISP medianos de América Latina continúan siendo un segmento poco estudiado, a pesar de ser actores esenciales para la conectividad y la inclusión digital, y de sostener el desarrollo económico de territorios que los grandes operadores no siempre atienden.

• Gap 3 Especificidad metodológica y geográfica: Entre los estudios revisados no se identificó una investigación que combine simultáneamente una comparación cuantitativa entre procesos manuales y automatizados, la medición censal de la percepción de usabilidad mediante una escala Likert, el análisis inferencial mediante una prueba de hipótesis para proporciones y la evaluación de calidad del software en el contexto específico de un ISP ecuatoriano mediano.

En este contexto el presente estudio responde de forma concreta a las tres brechas identificadas previamente, y se enfoca en medir con datos de campo, cuánto cambia realmente el desempeño de N8N frente al proceso manual, de igual forma atiende la sectorial poniendo como objeto de estudio a un ISP mediano, un segmento que la literatura apenas menciona, y resuelve la metodológica combinando en un mismo diseño la comparación cuantitativa, la medición censal de usabilidad, la prueba de hipótesis para proporciones y la evaluación experta de calidad de software, todo aplicado a un ISP ecuatoriano.

Las tres brechas, en conjunto, hacen de este estudio un aporte original al tema de la automatización en telecomunicaciones latinoamericanas, para abordarlas, se planteó una evaluación comparativa empírica entre procesos manuales y N8N en tres procesos críticos de un ISP ecuatoriano, con el objetivo de medir la eficiencia operativa y la reducción de errores que genera la automatización, a través de indicadores de tiempo de ejecución, tasa de éxito operativo y percepción de usabilidad.

A partir de este propósito, el estudio persigue tres objetivos específicos, siendo el primero que se centra en determinar en qué medida la implementación de N8N mejora la eficiencia operativa y reduce la tasa de errores en la gestión de procesos internos del ISP, en comparación con la ejecución manual de dichos procesos; otro objetivo busca cuantificar el impacto de N8N sobre los tiempos de ejecución, la tasa de errores, la percepción de usabilidad y el esfuerzo tecnológico requerido en los flujos de trabajo internos del ISP, frente a su equivalente manual, y por último se busca establecer en qué grado la arquitectura de N8N permite escalar y adaptar los flujos de automatización ante la crecimiento demanda operativa y cambios regulatorios o tecnológicos propios del sector de telecomunicaciones ecuatoriano, y qué nivel de calidad de software perciben los expertos técnicos en sus características funcionales, operativas y de seguridad.

Cada objetivo aborda una brecha específica, donde el primero examina el impacto diferencial de la automatización sobre la eficiencia y la confiabilidad operativa, luego el segundo traduce dicho impacto en indicadores observables y cuantificables, y el tercero amplía el análisis hacia la sostenibilidad técnica de la solución, su capacidad de adaptación y la valoración de su calidad conforme a las características derivadas de la norma ISO/IEC 9126 (International Organization for Standardization [ISO], 2001). De esta manera, el estudio articula la dimensión operativa, la experiencia de los usuarios y la evaluación técnica de la plataforma, evitando reducir la automatización a una simple comparación de velocidades.

El presente artículo continua su estructura con la sección 2 que aborda la metodología, el enfoque, la población, los procesos elegidos y los instrumentos usados, seguidamente se indica la sección 3 con los resultados, los tiempos, la tasa de éxito, la usabilidad, el análisis inferencial, la evaluación de calidad de software y el costo de oportunidad tecnológico de la automatización, por último la sección 4, discute esos hallazgos a la luz del marco teórico y reúne las conclusiones, las limitaciones y las líneas para investigación futura.

2. Materiales y Métodos

2.1 Enfoque metodológico

El presente estudio adoptó un enfoque cuantitativo-descriptivo con diseño comparativo no experimental, orientado a contrastar el desempeño de los procesos manuales frente a N8N en tres procesos críticos de un ISP ecuatoriano. Este diseño es pertinente para observar el comportamiento bajo condiciones naturales de operación, sin que el investigador manipule variables independientes (Hernández Sampieri et al., 2014), el estudio es de tipo aplicado, con utilidad práctica inmediata para la organización.

El marco de evaluación se basó en el modelo Goal-Question-Metric (GQM) propuesto por (Basili & Weiss, 1984): (a) Objetivo (Goal): impacto diferencial de N8N en la eficiencia operativa; (b) Pregunta (Question): ¿cuánto se reduce el tiempo y la tasa de errores, y cómo perciben los colaboradores la usabilidad?; y (c) Métrica (Metric): tiempo de ejecución, porcentaje de éxito y percepción Likert 1–5 (Gavrila Gavrila et al., 2023). Cuatro referencias corresponden a marcos metodológicos y normativos sin sustituto reciente de uso equivalente: el modelo GQM de Basili y Weiss (1984), la norma ISO/IEC 9126 (2001) que sustenta el instrumento de calidad de software, el trabajo de Streiner (2003) sobre el Alfa de Cronbach, y Walpole et al. (2012) como referencia estadística para la prueba Z.

2.2 Población y muestra

La población de referencia estuvo conformada por 28 colaboradores: Gerencia General (n = 1), Personas y Cultura (n = 4), Infraestructura (n = 12), Networking y Service Delivery (n = 4), Seguridad de la Información (n = 1) y Tecnología y Analítica de Datos (n = 6). Al tratarse de una población finita, conocida y de tamaño reducido, se optó directamente por un muestreo censal aplicando el instrumento a la totalidad de los 28 colaboradores, sin necesidad de estimar un tamaño muestral mediante fórmula, con ello, el censo elimina el sesgo de muestreo propio de procedimientos aleatorios y maximiza la representatividad (Hernández Sampieri et al., 2014), lo que provocó que la tasa de respuesta fuese del 100% (28/28).

Para evaluar la escalabilidad y la calidad de software se aplicó adicionalmente una evaluación basada en la norma ISO/IEC 9126 a seis expertos del área de Tecnología y Analítica de Datos del ISP, donde los participantes fueron seleccionados por su experiencia en desarrollo, verificación, validación y puesta en producción de sistemas institucionales, así como por su conocimiento de los requisitos de seguridad, confiabilidad y adaptación tecnológica propios del ecosistema de la organización, y entendiendo que esta evaluación fue independiente del instrumento censal aplicado a los 28 colaboradores acorde al diseño detallado en 2.4.

Los seis expertos convocados representan la totalidad del personal del área de Tecnología y Analítica de Datos del ISP, por eso, esta evaluación también es un censo, no una muestra, donde no se trata de seis personas elegidas de un grupo más amplio, sino de todo el equipo técnico especializado que tiene la organización para este tipo de valoración. Sumar más evaluadores habría significado traer personal externo al ISP, y eso habría roto el criterio que sostiene la Tabla 11: el conocimiento profundo del entorno productivo evaluado.

2.3 Selección y descripción de los procesos evaluados

La selección de los tres procesos emergió de un diagnóstico interno según frecuencia de ejecución, tiempo demandado, incidencia en la continuidad del servicio, tasa de errores y viabilidad técnica, criterios consistentes con el marco de 32 criterios de selección de procesos candidatos a RPA validado mediante Delphi (Farinha et al., 2024). Un criterio transversal fue el alcance multidepartamental; BioTime involucra datos de todas las áreas, HetrixTools afecta la comunicación organizacional, y SSH impacta la conectividad, como se observa en la Tabla 2.

En esta primera revisión se miraron varios procesos candidatos a automatizar, como el monitoreo de infraestructura, gestión de incidentes, respaldos, administración de sistemas, generación de reportes, entre otros, de ahí se priorizaron BioTime, HetrixTools y SSH, por dos razones, primero, a diferencia del resto de candidatos, que son más autosuficientes, estos tres dependen de algo externo; BioTime del sistema biométrico, HetrixTools del servicio de monitoreo y del proveedor de correo para el deslistamiento, y SSH de los propios equipos de red. Segundo, su criticidad operativa es mayor que la del resto; BioTime afecta la nómina y el cumplimiento laboral, HetrixTools compromete la reputación y disponibilidad del servicio frente a listas negras, y SSH sostiene la conectividad de red, esta combinación de dependencias externas y alta criticidad fue lo que los puso por delante de procesos igualmente manuales, pero más independientes o menos críticos. Como respaldo complementario de esta priorización, se construyó una matriz de puntuación ponderada adaptada de los criterios y pesos de Farinha et al. (2024), disponible en el repositorio de datos del estudio, en la que BioTime, HetrixTools y SSH se ubicaron entre los procesos con mayor puntaje frente a los demás candidatos evaluados (Villares Jimenez et al., 2026).

De los tres procesos, HetrixTools es el que guarda la relación más directa con el marco regulatorio, como el verificar la reputación de las IPs y documentar cada incidente conecta con los parámetros de calidad de la Resolución 216-09-CONATEL-2009 (CONATEL, 2009), entre ellos el tiempo promedio de reparación de averías efectivas, que no debe superar las 24 horas, y con el reporte periódico que ARCOTEL exige a través del sistema SIETEL, BioTime y SSH no tienen una exigencia normativa tan directa, cabe destacar, ARCOTEL no exige usar N8N ni HetrixTools en particular, solo regula los niveles de calidad y continuidad del servicio.

2.4 Variables e instrumentos de medición

La variable independiente fue el tipo de enfoque operativo: proceso manual versus proceso automatizado con N8N (workflow low-code basado en nodos). La variable dependiente fue la eficiencia operativa, medida mediante tiempo de ejecución, tasa de éxito operativo y percepción de usabilidad. La Tabla 3 presenta la operacionalización completa.

Para la medición de la percepción de usabilidad se diseñó un instrumento de diez ítems en escala Likert (1 al 5), estructurado en dos secciones; la Sección A midió la experiencia con el proceso manual en los ítems 1 al 5, mientras que la Sección B se enfocó en el proceso automatizado con N8N en los ítems 6 al10. La Tabla 4 detalla la composición del instrumento.

El instrumento de percepción de usabilidad fue sometido a un proceso de validación de contenido mediante juicio de expertos, el tutor de tesis revisó los ítems propuestos, sugirió ajustes de redacción, verificó su alineación con los objetivos de la investigación y avaló la versión final antes de su aplicación a los 28 colaboradores, mientras que los investigadores complementaron esta validación con una prueba piloto de carácter técnico-funcional, ingresando respuestas de prueba y ajustando la visualización del formulario antes de enviarlo a la muestra censal. Para la medición de la confiabilidad interna del instrumento se calculó el Alfa de Cronbach por separado en cada sección, dado el carácter comparativo del diseño en la Sección A del proceso manual dio α = 0.556, y en la Sección B con N8N, apenas llegó a α = 0.030, ambos por debajo del umbral mínimo aceptable de 0.70, esta baja fiabilidad se explica por homogeneidad de varianza, en ambas secciones las respuestas se concentraron en un extremo de la escala, algo que no afecta la dirección ni la magnitud de la diferencia encontrada entre los dos enfoques (Streiner, 2003).

Para operacionalizar la calidad de software se diseñó un segundo instrumento basado en la norma ISO/IEC 9126 (2001), con dos sustituciones; Portabilidad por escalabilidad, es decir la capacidad de incorporar nuevos procesos sin rediseñar la arquitectura (Ajimati et al., 2025); y mantenibilidad por seguridad, dado que los flujos gestionan credenciales OAuth2, tokens de API, claves SSH y datos biométricos, gestión de accesos, protección de APIs y cifrado de datos (Mora Chavez et al., 2025), las cuatro características restantes se reinterpretaron para workflows, y en conjunto el instrumento integra 15 criterios: 3 corresponden a funcionalidad, 3 pertenecen a confiabilidad, 3 se atribuyen a usabilidad, 2 a eficiencia, 2 a seguridad y 2 a escalabilidad, el enunciado completo de cada criterio, junto con las calificaciones individuales de los seis expertos está disponible en el repositorio de datos del estudio (Villares Jimenez et al., 2026).

Como dimensión complementaria se incorporó el esfuerzo tecnológico asociado a la automatización, considerando las horas aproximadas destinadas al diseño e implementación inicial, el mantenimiento ordinario y el tiempo operativo recuperado mediante cada flujo. A partir de estos valores se definió un indicador de Costo de Oportunidad Tecnológico (COT): la relación porcentual entre las horas técnicas requeridas para sostener la automatización y las horas operativas ahorradas durante un horizonte anual. Con este indicador se ponderó el beneficio temporal frente a la carga técnica generada por cada solución.

2.5 Implementación de flujos automatizados en N8N

Dado que los tres procesos carecían de flujos formalizados previos, el diseño de los workflows en N8N partió desde cero, con base en los requisitos de la Fase 1. La plataforma se desplegó sobre una instancia de N8N Community Edition v1.93.0, ejecutada en un servidor virtual con Windows Server 2022, dentro de una infraestructura de virtualización soportada por VMware ESXi 7.0 Update 3g (build 20328353, arquitectura x86_64), el acceso se realizó mediante una dirección IP privada dentro de la red corporativa del ISP con autenticación OAuth2 y control de acceso por roles (RBAC), lo que garantizó seguridad y trazabilidad completa, las especificaciones de CPU, memoria RAM y almacenamiento asignadas a la máquina virtual no estuvieron disponibles durante el período de documentación, por lo que no se incorporaron como variables del entorno experimental, la Tabla 5 sintetiza las características técnicas de los tres flujos.

2.5.1 Flujo BioTime – Reporte automatizado de multas por timbrado (P1)

BioTime automatiza el cálculo y reporte mensual de descuentos de nómina por ausencias y atrasos en el registro biométrico, mediante ocho nodos secuenciales: un Schedule Trigger programa la ejecución mensual, eliminando la intervención humana; Generate Token obtiene credenciales de autenticación mediante solicitud POST a la API REST de BioTime; Get Punches extrae los registros de timbrado del período mediante solicitud GET; Split Out normaliza y estructura los registros por colaborador; Calc_No_Punch cuantifica ausencias y registros fuera de horario; Calc_SumTotal consolida el monto de multa de cada colaborador (ID, nombre, apellido, cargo); Convert to File genera el reporte en formato XLSX; y Send Email lo envía automáticamente a Talento Humano sin intervención manual (Figura 1).

2.5.2 Flujo HetrixTools – Monitoreo automatizado de listas negras de IPs (P2)

HetrixTools automatiza la verificación diaria del estado reputacional de las IPs públicas frente a listas negras internacionales, en el proceso manual, el analista de Seguridad de la Información ingresaba individualmente cada IPv4 en el portal de HetrixTools, identificaba visualmente si registraba alguna infracción y, de ser así, contactaba telefónicamente al proveedor de correo para iniciar el deslistamiento, sin registro estructurado del evento, el flujo se conecta directamente con la API de HetrixTools y consulta a la vez todas las IPs públicas del ISP, un nodo Split separa los resultados por dirección IP, y un nodo de decisión revisa si esa IP aparece en alguna lista negra, si la encuentra, genera automáticamente una notificación a Seguridad de la Información con el detalle de la IP y las acciones correctivas recomendadas (ver Figura 2), lo que deja mejor rastro que la gestión manual de incidentes.

2.5.3 Flujo SSH – Monitoreo interactivo de interfaces y potencias ópticas de red (P3)

SSH automatiza la verificación del estado operativo de los equipos de red desde el campo, proceso que en su modalidad manual exigía la coordinación entre el técnico de campo y el personal del NOC, el flujo opera mediante nodos secuenciales (Figura 3), un nodo de validación de IP confirma la accesibilidad del equipo ingresado por el técnico de campo, el nodo SSH establece la conexión y ejecuta show interface status para obtener el estado completo de las interfaces, un nodo de integración con IA extrae los campos port, name y status de las interfaces conectadas estructurándolos para su presentación, y un nodo de consulta interactiva permite que el técnico seleccione después las interfaces que quiere examinar con mayor detalle, en base a esa selección, el nodo de reporte ejecuta show interfaces transceiver details y retorna las potencias ópticas listas para el reporte final, esto elimina la dependencia del NOC para consultas de primer nivel y libera al personal especializado para tareas de mayor complejidad (Chen et al., 2024).

2.6 Procedimiento de recolección de datos

El proceso metodológico se estructuró en cinco fases secuenciales que garantizaron condiciones de comparación equivalentes y reproducibles entre los enfoques manual y automatizado, para efecto de verificación, los datos se encuentran disponibles en un repositorio digital (Villares Jimenez et al., 2026).

La Figura 4 sintetiza este diseño y la relación temporal entre fases, siguiendo un proceso secuencial e iterativo bajo condiciones reales de operación, las Fases 1 y 2 comparten la misma ventana de dos semanas, mientras el levantamiento documenta el proceso manual de forma cualitativa, tales como entradas, salidas, actores y dependencias, la medición de la línea base registra en paralelo los indicadores cuantitativos que alimentan la Tabla 6, tiempos y éxito medidos sobre las mismas diez ejecuciones observadas por proceso, con esos requisitos ya documentados, la Fase 3 diseña e implementa los tres flujos en N8N sobre el entorno productivo del ISP, definiendo triggers, nodos, integraciones, reglas de negocio y scripts, mediante ciclos de ejecución, observación y ajuste hasta alcanzar un comportamiento estable, tras aproximadamente cinco meses de operación normal, la Fase 4 recolecta una semana de datos post-automatización a partir de los logs de la plataforma y aplica la encuesta de usabilidad a los 28 colaboradores, la Fase 5 cierra el proceso con el análisis estadístico comparativo entre ambos enfoques, mediante prueba Z para una proporción y recodificación Likert de satisfacción alta o baja.

2.6.1 Fase 1. Levantamiento y documentación de procesos manuales

Con el propósito de establecer una línea base objetiva, se hizo un relevamiento mediante análisis documental y observación directa durante dos semanas de operación normal, sin intervenir en los flujos existentes; de cada proceso se documentaron las entradas, salidas, actores y dependencias sistémicas, así como los recursos humanos involucrados en su ejecución (Tabla 6), el procedimiento con el que se midieron esos tiempos de ejecución y esa tasa de error se describe en la Fase 2.

El análisis del estado manual evidenció la ausencia de flujos formalizados: los procesos se ejecutaban de forma no sistematizada, dependían del conocimiento tácito de cada operador y no dejaban documentación ni registros de auditoría, esto coincide con los patrones de ineficiencia que Katsonis et al. (2018) ya habían identificado en ISPs medianos.

2.6.2 Fase 2. Medición de la línea base manual

Durante el período de levantamiento (Fase 1, dos semanas), cada proceso se registró en sus ejecuciones sucesivas bajo condiciones de producción normal, los tiempos de ejecución se calcularon como media de diez observaciones por proceso (Tabla 6), medidas por cronometría directa, la tasa de éxito operativo, en cambio, se determinó con un subconjunto de diez ejecuciones observadas directamente por proceso. Se consideró fallida toda ejecución que necesitara intervención adicional, corrección posterior o reprocesamiento de datos, ese tamaño de submuestra (n = 10) fue un criterio metodológico propio del estudio, que buscó equilibrar la observación directa y sistemática de cada ejecución con la viabilidad de medir en un entorno de producción real.

2.6.3 Fase 3. Implementación de flujos automatizados

Con base en los requisitos de la Fase 1, se diseñaron e implementaron los tres flujos N8N descritos en el punto 2.5, sobre el entorno productivo del ISP y bajo supervisión de Tecnología y Analítica de Datos, garantizando condiciones equivalentes al proceso manual. El diseño definió eventos de activación, nodos, integraciones, validaciones, reglas de negocio y scripts para automatizar las actividades previamente manuales, y el desarrollo fue incremental, cada versión funcional se incorporó al entorno productivo, se revisaron sus ejecuciones y se realizaron ajustes según los eventos observados.

En BioTime se identificaron dificultades de conexión con la API, alto volumen de registros, datos nulos y problemas de SMTP o del archivo XLSX, estas incidencias se redujeron progresivamente al ajustar las validaciones del flujo, pero no desaparecieron por completo, según la Tabla 8 del punto 3.2, persistieron durante la semana de medición post-automatización (Fase 4). En HetrixTools, las incidencias fueron de límites y disponibilidad de la API, certificados y cambios en las respuestas; en SSH, de conectividad, credenciales, Telegram y tiempos de Gemini, estos ajustes redujeron la frecuencia de fallos frente a las primeras semanas, aunque, según la Tabla 8, ningún flujo alcanzó el 100% de éxito ni tras cinco meses de operación.

2.6.4 Fase 4. Implementación operativa y recolección de datos post-automatización

Al momento de recolectar los datos, los tres flujos ya llevaban unos cinco meses operando con normalidad en el ISP, incorporados a las actividades diarias del personal; se seleccionó una semana de observación para extraer del historial de logs de N8N los tiempos de ejecución y los registros necesarios para compararlos con los procesos manuales. Para cada proceso se analizaron diez ejecuciones, calculando tiempo promedio, desviación estándar e intervalo de confianza del 95 % mediante distribución t de Student, para la tasa de éxito, ese mismo subconjunto de diez ejecuciones por flujo se evaluó con el criterio de fallo de la línea base (error de origen técnico que no completara el resultado esperado), clasificando además la causa observada para diferenciar problemas internos del flujo de aquellos originados por servicios o infraestructura externa. Al concluir la recolección, se aplicó el instrumento de usabilidad a los 28 colaboradores, lo que cubrió la totalidad de la población censal (Hernández Sampieri et al., 2014), buscando una valoración basada en una experiencia sostenida de uso y no en una primera impresión de la herramienta.

2.6.5 Fase 5. Análisis comparativo

Para el contraste estadístico se aplicó una prueba de hipótesis para una proporción mediante el estadístico Z, cada respuesta Likert se recodificó en una variable dicotómica (satisfacción alta versus baja), cuyo conteo sigue una distribución Binomial aproximable a la normal al cumplirse n·p0 ≥ 5 y n·(1−p0) ≥ 5 (Walpole et al., 2012), el estadístico se calculó independientemente para la Sección A y B, contra un umbral de aceptación del 80% (α = 0.05). El Alfa de Cronbach, la prueba Z y los promedios de la evaluación ISO/IEC 9126 (2.4, 3.5) se calcularon en Microsoft Excel mediante fórmulas nativas, siguiendo las expresiones estadísticas de Walpole et al. (2012) para la prueba Z.

2.7 Consideraciones éticas

La investigación respetó en todo momento la confidencialidad, el anonimato y el consentimiento informado de los participantes, quienes colaboraron de forma voluntaria y con datos usados únicamente para fines académicos, por tal motivo, se omite el nombre del ISP (Hernández Sampieri et al., 2014), no se solicitó aprobación de un comité de ética institucional porque el estudio no implicó intervención clínica ni biomédica, se trató de observar procesos operativos existentes y aplicar una encuesta Likert anónima al personal administrativo y técnico adulto, los registros biométricos de timbrado del flujo BioTime son datos que el ISP ya recolectaba para nómina, no información generada para esta investigación.

3. Resultados y discusión

Esta sección presenta los hallazgos obtenidos a partir de los instrumentos descritos en la sección de Métodos (2.4-2.6), organizados según los objetivos que orientan el estudio, y los interpreta a la luz de la literatura del marco teórico, los apartados 3.1 a 3.5 reportan los resultados de eficiencia operativa y reducción de errores (tiempos de ejecución, tasa de éxito operativo, percepción de usabilidad y el análisis inferencial mediante prueba de hipótesis para proporciones), junto con los resultados de escalabilidad y calidad de software, los apartados 3.6 a 3.10 discuten estos hallazgos frente al marco teórico y sus implicaciones para la automatización en ISPs medianos latinoamericanos, el apartado 3.11 cierra la sección con el análisis del esfuerzo tecnológico y el costo de oportunidad de cada flujo, presentando en conjunto sus resultados e interpretación.

3.1 Tiempos de ejecución

La Tabla 7 compara el tiempo promedio de ejecución de cada proceso bajo el enfoque manual con el correspondiente flujo automatizado en N8N. Los tiempos de los flujos automatizados se obtuvieron del historial de logs de la plataforma durante la semana seleccionada para la observación y recolección de datos, cuando las automatizaciones llevaban aproximadamente cinco meses operando en el entorno productivo del ISP (Fase 4, 2.6).

La Tabla 7 muestra una reducción sustancial y consistente en los tiempos de ejecución de los tres procesos automatizados; BioTime pasó de 90 minutos a 125 segundos con una desviación estándar de 4.08s, IC95% ± 2.92s y una reducción del 97.7%, HetrixTools disminuyó de 120 minutos a 29.8 segundos con una dispersión de 2.30s, IC95% ± 1.65s y la mayor reducción relativa de 99.6%, mientras que SSH pasó de 45 minutos a 62.5 segundos, con 3.03s de desviación, IC95% ± 2.17s y una reducción del 97.7%. La baja dispersión observada en los tres flujos indica que los tiempos se mantuvieron próximos a sus respectivas medias, lo que respalda la estabilidad de la mejora temporal registrada, estos tiempos corresponden a ejecuciones completadas en un solo intento, sin reintentos automáticos que pudieran inflar artificialmente la reducción reportada, los casos con fallas de origen técnico se contabilizaron aparte, en la tasa de éxito operativo.

3.2 Tasa de éxito operativo

La Tabla 8 contrasta la tasa de éxito observada en el proceso manual (línea base, Tabla 6) con la tasa de éxito registrada en diez ejecuciones del flujo automatizado por proceso (Fase 2 y Fase 4, 2.6). La tasa de éxito de la línea base manual se obtuvo como complemento de la tasa de error documentada en la Tabla 6 (tasa de éxito = 1 − tasa de error).

Estos resultados evidencian que la automatización mejoró la tasa de éxito en los tres procesos evaluados, BioTime pasó de 50% a 70%, HetrixTools de 70% a 90% y SSH de 40% a 80%, este último fue el que más mejoró, al reducir la dependencia de la coordinación entre el técnico de campo y el personal del NOC, los fallos registrados en N8N no estuvieron asociados principalmente con la lógica del flujo, sino con dependencias externas; en BioTime, la conexión con la API, el volumen de datos, los registros nulos y el archivo XLSX, en HetrixTools; los límites o disponibilidad de la API y cambios en sus respuestas, y en SSH; la conectividad, las credenciales, Telegram y tiempos de espera de Gemini. La mejora observada es, ante todo, una disminución de riesgo, bajan los errores por intervención manual y ganan peso los fallos de integración, conectividad y disponibilidad externa que el propio flujo permite detectar, registrar y corregir.

La Figura 5 traza el mecanismo detrás de esa mejora, parte del problema central del diagnóstico con baja eficiencia y alta tasa de error en los procesos manuales del ISP, lo desagrega en los síntomas por proceso y conecta cada síntoma con su causa raíz manual y el mecanismo de N8N que la resuelve, el resultado conjunto es menor tiempo de ejecución, mayor tasa de éxito operativo, trazabilidad completa y reducción de errores humanos, a diferencia de los fallos mencionados antes, que persisten por depender de servicios externos, esta trazabilidad recoge las causas de error propias del proceso manual, que N8N sí elimina de raíz.

3.3 Percepción de usabilidad

El instrumento Likert de diez ítems (Tabla 4, 2.4) fue aplicado a los 28 colaboradores. La Tabla 9 presenta la media y la desviación estándar por ítem, agrupadas en la Sección A (proceso manual, ítems 1–5) y la Sección B (flujo N8N, ítems 6–10).

La Sección A (proceso manual) obtuvo una media general de 1.76 (DE = 0.73), mientras que la Sección B (flujo N8N) obtuvo una media general de 4.27 (DE = 0.69). A nivel de ítem, la mayor diferencia entre enfoques se observó en el ítem de eficiencia en tiempo (1.43 frente a 4.46; diferencia de 3.03 puntos), consistente con los hallazgos de reducción de tiempo reportados en 3.1. El ítem de confianza en los resultados tuvo la menor diferencia (2.11 frente a 4.32; 2.21 puntos), y fue además el único cuya media en el proceso manual superó el valor mínimo de la escala. La Figura 6 representa gráficamente esta comparación por ítem.

La fiabilidad del instrumento, estimada mediante el Alfa de Cronbach, fue α = 0.556 para la Sección A y α = 0.030 para la Sección B, ambos valores se ubican por debajo del umbral mínimamente aceptable, refleja α ≥ 0.70, para investigación exploratoria, esta baja fiabilidad interna no refleja inconsistencia en las respuestas individuales, sino un efecto de homogeneidad de varianza, las respuestas de la Sección B se concentraron mayoritariamente en las categorías “alto” y “muy alto” con una desviación estándar entre 0.58 y 0.79, y las de la Sección A, en las categorías “muy bajo” y “bajo”, con una desviación estándar entre 0.50 y 0.85, lo que reduce artificialmente la varianza total entre sujetos y, con ello, el coeficiente Alfa, sin que esto invalide la dirección ni la magnitud de la diferencia observada entre ambos enfoques (Streiner, 2003).

3.4 Análisis inferencial: prueba de hipótesis para proporciones

Para establecer si cada enfoque alcanza una proporción de satisfacción estadísticamente superior al umbral mínimo de aceptación (80%), se aplicó una prueba de hipótesis para una proporción mediante el estadístico Z, calculado de forma independiente por sección. Las respuestas se recodificaron en dos categorías: satisfacción alta (Moderado, Alto, Muy alto) y satisfacción baja (Muy bajo, Bajo), con el mismo criterio empleado en el cálculo del Alfa de Cronbach (3.3). La hipótesis nula planteó que la proporción de satisfacción alta es inferior al 80%, frente a la alternativa de que la iguala o supera:

H0: p < 0.80 H0: p ≥ 0.80

Antes de aplicar la prueba, se verificó la condición de aproximación normal a la distribución binomial subyacente a cada ensayo Bernoulli (Walpole et al., 2012): n·p0 = 140 × 0.80 = 112 ≥ 5, y n·(1−p0) = 140 × 0.20 = 28 ≥ 5, lo que confirma la validez del estadístico Z para ambas secciones. El estadístico de prueba se calculó como Z0 = (p̂ − p0) / √[p0(1−p0)/n], y se contrastó contra el valor crítico Zₐ = 1.645 (α = 0.05, prueba unilateral derecha).

La Tabla 10 presenta la distribución de las 140 respuestas de cada sección (28 colaboradores × 5 ítems) recodificadas en las dos categorías de satisfacción, junto con los resultados de la prueba de hipótesis para proporciones y la decisión estadística correspondiente.

Para la Sección B, el estadístico calculado Z0 = 5.92 superó ampliamente el valor crítico Zₐ = 1.645, p < .001, por lo que se rechaza H0 en favor de H0, la proporción de colaboradores con satisfacción alta respecto al flujo automatizado es estadísticamente superior al 80%, este resultado es consistente con la proporción observada de p̂ = 1.00, dado que ninguna de las 140 respuestas de la Sección B se ubicó en las categorías Muy bajo o Bajo, (Tabla 10, sección 3.4), en la Sección A, el resultado es justo el contrario, el estadístico calculado Z0 = -18.59 se ubica muy por debajo del valor crítico, por lo que no se rechaza H0, y la proporción de satisfacción alta respecto al proceso manual con p̂ = 0.17, resulta estadísticamente inferior al umbral del 80%, la comparación de ambos resultados permite concluir, con un nivel de confianza del 95%, que N8N es el enfoque operativo superior en términos de satisfacción percibida por los colaboradores.

3.5 Resultados sobre escalabilidad y calidad de software

Para evaluar la escalabilidad y la calidad de software se aplicó la norma ISO/IEC 9126 a seis expertos del área de Tecnología y Analítica de Datos del ISP. Los participantes fueron seleccionados por su experiencia en el desarrollo, verificación y validación de sistemas destinados al entorno productivo, y por su conocimiento de los criterios técnicos necesarios para garantizar soluciones confiables, seguras y compatibles con el ecosistema tecnológico institucional.

La norma fue adaptada al objeto de estudio mediante dos sustituciones justificadas: Portabilidad se reemplazó por Escalabilidad, entendida como la capacidad de incorporar nuevos procesos automatizados y adaptaciones regulatorias sin rediseñar la arquitectura existente (Ajimati et al., 2025), y Mantenibilidad se reemplazó por Seguridad, dado que los flujos gestionan credenciales OAuth2, tokens de API, claves SSH y datos biométricos del personal, justo el tipo de activo que la gestión de accesos y la protección de APIs buscan resguardar en cualquier despliegue tecnológico en la nube (Mora Chavez et al., 2025). Las cuatro características restantes: Funcionalidad, Confiabilidad, Usabilidad y Eficiencia, se conservaron reinterpretadas para el contexto de workflows. El instrumento de 15 criterios, valorados en escala Likert de 1 (deficiente) a 5 (excelente), se describe en la sección 2.4.

Los resultados revelan un nivel de calidad global excelente, promedio de 4.73 sobre 5 y 94.62% (Figura 7), la funcionalidad y seguridad obtuvieron la valoración más alta con 4.83 y 96.67%, esto confirma que los flujos responden correctamente a las solicitudes operativas y protegen bien los activos de información sensibles, escalabilidad obtuvo 4.75 con 95%, el hallazgo central en materia de escalabilidad regulatoria, los expertos consideran viable extender el entorno N8N hacia nuevos procesos y adaptarlo ante cambios regulatorios del sector, incluidas eventuales resoluciones de la ARCOTEL, confiabilidad, con 4.72 y 94.44%, y usabilidad con 4.67 y 93.33% reflejan la disponibilidad consistente de la plataforma y la facilidad con que el equipo de Tecnología y Analítica de Datos administra los flujos (Curty et al., 2023), la eficiencia registró la valoración más baja, aunque igualmente excelente con 4.58 y 91.67%, los expertos señalaron el consumo de recursos de BioTime como punto de optimización ante el crecimiento del volumen de registros biométricos, algo que sigue siendo un margen de mejora y no un problema actual.

Que las seis características se ubiquen en el rango excelente confirma que la arquitectura de N8N es escalable y de calidad adecuada: ofrece una base tecnológica sólida y segura, capaz de extenderse hacia otros procesos del ISP con garantías de sostenibilidad técnica a largo plazo.

3.6 Interpretación de los tiempos de ejecución

Los tiempos que arrojó N8N (29.8 segundos en el Flujo HetrixTools y 125 segundos en el Flujo BioTime) van en la misma dirección de lo reportado por W. L. Huang et al. (2024) en procesos hospitalarios y Larios Soldevilla & Atoche Socola (2023) en telecomunicaciones sudamericanas: la automatización reduce tiempos operativos de forma sustancial, y esto no parece depender del sector, este estudio extiende esa evidencia a procesos administrativos y de seguridad de la información, con una reducción superior al 97% en los tres flujos, esta magnitud coincide con lo que reportan Tenecela Tocto et al. (2026) al automatizar un proceso administrativo del sector público ecuatoriano con la arquitectura de microservicios, lo que sugiere que la ganancia de eficiencia depende menos de la tecnología específica que de eliminar la captura manual de datos.

La explicación de por qué el flujo HetrixTools redujo más, con 99.6% que los otros dos está en la arquitectura, no en la eficacia, debido que consulta una API externa de forma simultánea, mientras que BioTime procesa secuencialmente un volumen alto de datos biométricos, lo cual es coherente con la caracterización de N8N como una orquestación por triggers y nodos (Moreno, 2025), esto esulta interesante, eso sí, BioTime y SSH terminarán con la misma reducción de 97.7%, pese a operar bajo lógicas completamente distintas, esto sugiere que el techo de eficiencia de N8N está más determinado por los pasos que no se pueden automatizar que por la complejidad del proceso de partida.

3.7 Interpretación de la tasa de éxito operativo

Ni el Flujo BioTime (70%) ni el Flujo SSH (80%) llegaron al 100% de éxito operativo, y eso tiene una explicación clara: ambos siguen dependiendo de fuentes externas o de intervención humana en algún punto, y la automatización no elimina esa variabilidad por completo. Este hallazgo respalda lo que plantean Kokina et al. (2026), quienes, a partir de entrevistas a profesionales de automatización, señalan que el diseño de los mecanismos de gobernanza de RPA cumple un papel determinante en su desempeño, sin que esto elimine del todo la variabilidad introducida por integraciones externas dinámicas.

El caso del Flujo SSH es el más ilustrativo. Su línea base dependía de que el técnico de campo y el personal del Centro de Operaciones de Red coordinaran en tiempo real, una fuente de error más organizacional que técnica, y por eso registró el mayor avance relativo (+40 puntos porcentuales). La automatización redujo esa dependencia, pero no la eliminó del todo: el flujo conserva un nodo de consulta interactiva, precisamente porque persisten los desafíos de colaboración multiservidor que documenta Chen et al. (2024).

3.8 Interpretación de la usabilidad percibida y de la prueba de hipótesis para proporciones

Que la proporción de colaboradores con satisfacción alta hacia N8N sea estadísticamente superior al 80%, Z=5.92, p<.001, confirma una adopción ampliamente favorable y coincide con lo ya reportado, Ajimati et al. (2025) señalan la facilidad de uso como determinante en la adopción de plataformas low-code, y Filgueiras et al. (2022) reportan mejoras de satisfacción similares al reemplazar procesos manuales, el modelo de aceptación de RPA en el sector público de Vollenberg et al. (2024) va en la misma línea, identifica la operabilidad y la facilidad de implementación como factores determinantes en la aceptación de la tecnología.

La ausencia de respuestas en las categorías de satisfacción baja debe leerse con cautela por la elevada homogeneidad de las valoraciones, este resultado se explica por los cinco meses que los flujos llevaban funcionando en producción con uso diario del personal del ISP; la encuesta, aplicada en ese punto, capturó la percepción de un personal ya experimentado con la plataforma. la baja fiabilidad de la Sección B con α = 0.030 se relaciona con la escasa variabilidad de las respuestas, lo que exige leer su consistencia interna con cautela, aunque la dirección del hallazgo sigue siendo favorable.

3.9 Interpretación de la escalabilidad y la calidad de software (ISO/IEC 9126)

La puntuación de Escalabilidad es 4.75 sobre 5 con 95%, es el dato más relevante de esta sección, lo mismo que confirma que la arquitectura de N8N admite nuevos flujos ante cambios regulatorios sin rediseñar la infraestructura existente, lo que coincide con Annarelli et al. (2022) sobre la adaptabilidad tecnológica como factor crítico de resiliencia organizacional en economías emergentes., esto se refleja en el propio Flujo HetrixTools, reducir su ciclo de verificación de 120 minutos a 29.8 segundo (Tabla 7), deja margen de sobra frente a las 24 horas que exige la Resolución 216-09-CONATEL-2009 para reparar averías, y el registro automático de cada consulta respalda el reporte periódico vía SIETEL, justo el ajuste regulatorio que los expertos calificaron como viable, la Seguridad, con 4.83 sobre 5, también es relevante, la plataforma maneja credenciales OAuth2 y datos biométricos, y gestionar esos accesos desde el diseño del flujo es lo que la literatura sobre seguridad en entornos de nube identifica como prioritario (Mora Chavez et al., 2025).

Conviene acotar el alcance de esta evaluación, proviene de un ejercicio interno, hecho por la totalidad del equipo técnico del propio ISP, no de un panel externo ni de una muestra más amplia de la industria, los evaluadores son quienes mejor conocen el entorno productivo evaluado, así que la valoración tiene sentido, de todas maneras, el nivel “excelente” obtenido difícilmente puede generalizarse más allá de este caso particular, las seis características quedaron en el rango excelente, eficiencia fue la más baja de todas con 4.58 sobre 5 y 91.67%, pero sin dejar de ser excelente, la solidez funcional y la seguridad de N8N ya están resueltas porque el margen de mejora real está en optimizar recursos computacionales frente al crecimiento del volumen de datos.

3.10 Esfuerzo tecnológico, costo de oportunidad y sostenibilidad operativa

La reducción del tiempo de ejecución es una ventaja relevante, pero no cubre todo el costo de automatizar un proceso, los tres flujos los desarrolló uno de los investigadores, ingeniero en sistemas con experiencia previa en herramientas tecnológicas y configuración de servidores, quien antes de empezar cursó 40 horas de automatización en N8N, repartidas en jornadas de 10 horas semanales durante un mes de formación, un gasto único y no recurrente, fue lo que se optó hacia la edición Community de N8N, que a diferencia de las versiones en la nube se despliega en servidor propio y exige saber configurarlo, justo el perfil técnico que ya tenía el equipo investigador, gracias a esto, construir cada flujo tomó entre tres y cuatro horas diarias durante una o dos semanas según su complejidad; HetrixTools requirió aproximadamente una semana, BioTime una semana y media, y SSH, por integrar conexiones de red, Telegram y un componente de inteligencia artificial, cerca de dos semanas, en horas por persona equivale de 15 a 20, 22.5 a 30 y 30 a 40 respectivamente, sin contar el costo fijo de la formación inicial.

La edición seleccionada no tuvo un costo por licenciamiento por lo que, la inversión real está en el tiempo dedicado a aprender la herramienta, diseñar cada flujo, corregirlo durante los primeros meses y mantenerlo después, algo que se estima en hasta una hora mensual por flujo, con estas cifras se calculó el Costo de Oportunidad Tecnológico (COT), la relación entre las horas invertidas en implementar y mantener cada flujo y, las horas operativas que ese mismo flujo recupera en un año.

HetrixTools presenta el balance más favorable, con 525.8 horas recuperadas al año y un COT de apenas 5-6 %, porque depende de una sola integración externa (su API) con reglas condicionales ya validadas. La dependencia de BioTime también es media, pero por otra razón, concentra su complejidad en el procesamiento interno de datos, scripts en Python y generación del XLSX, que el propio equipo puede corregir sin depender de terceros, aun así, su frecuencia mensual limita el ahorro anual y explica su COT más alto de 196% a 239%. SSH es el caso de dependencia alta, este requiere que tres servicios externos; SSH, Telegram e inteligencia artificial, funcionen simultáneamente, lo que eleva su deuda técnica y su esfuerzo de implementación (30-40 h), aunque también recupera un volumen alto de horas al año, 193.4 h y un COT 22-27%.

Para ponderar el beneficio temporal frente a la deuda técnica que genera cada flujo, con base en la carga de mantenimiento y el riesgo de fallo por integraciones externas, HetrixTools resulta el flujo más recomendable para que otro ISP mediano inicie su adopción de N8N, en cambio, SSH, exige monitoreo más cercano de sus tres dependencias, y BioTime, pese a su alta reducción por ejecución, recupera la inversión más lentamente por su baja frecuencia de uso. La viabilidad de N8N para un ISP mediano no depende solo del tiempo ahorrado por ejecución, sino también pesan la curva de aprendizaje, el esfuerzo técnico y la complejidad de mantenimiento de cada flujo.

Este análisis no incluye una comparación de costos frente a soluciones RPA corporativas licenciadas, lo que excede su alcance, pero representa una línea de investigación futura relevante.

3.11 Implicaciones prácticas para ISPs medianos latinoamericanos

Todo esto, visto en conjunto deja una idea central, el cambiar los procesos manuales por flujos de N8N no solo ahorra tiempo, también mejora la confiabilidad justo donde antes dependía de que varias personas coordinaran o de manejar grandes volúmenes de datos, sube la usabilidad percibida por los colaboradores, y deja una base tecnológica que calificó como excelente en las seis dimensiones evaluadas. Para los ISPs medianos latinoamericanos, un segmento del que prácticamente no hay evidencia empírica en la literatura sobre automatización con low-code (Larios Soldevilla & Atoche Socola, 2023), estos resultados muestran una alternativa viable frente al RPA corporativo, cuya inversión suele ser considerablemente mayor (Curty et al., 2023).

El tiempo que se le devuelve al personal técnico y administrativo encaja con lo que plantean Shi et al. (2025) sobre cómo el low-code reduce la barrera de entrada para construir integraciones complejas frente al desarrollo tradicional, y refuerza la idea de extender este enfoque a otros procesos internos es viable si la organización cuenta con personal de perfil técnico similar o invierte en formarlo. Esta magnitud de mejora tampoco parece ser exclusiva del low-code, en el sector público ecuatoriano, digitalizar un proceso administrativo de talento humano con arquitectura de microservicios y patrón hexagonal redujo el tiempo de registro de una solicitud de unos diez minutos a menos de 1.5 segundos, una mejora superior al 99.7% (Tenecela Tocto et al., 2026), esto indica que la automatización reduce tiempos de forma consistente, sin importar la arquitectura de fondo, pero no que el low-code sustituya al desarrollo tradicional. Su aporte real está en resolver con agilidad y rapidez tareas cotidianas, repetitivas y de alta dependencia operativa, como las tres evaluadas en este estudio, sin necesidad de construir un sistema a medida desde cero, para procesos más complejos o con requisitos específicos de la organización, como el caso de Tenecela Tocto et al. (2026), el desarrollo tradicional sigue siendo una alternativa igualmente válida, o incluso preferible.

4. Conclusiones

N8N mejoró notablemente el desempeño de los tres procesos críticos evaluados, reduciendo la dependencia de la intervención humana constante en cada ejecución. Para comprobarlo, la herramienta se evaluó en cuatro frentes complementarios: tiempo y éxito operativo, percepción de los colaboradores, calidad de software y esfuerzo tecnológico.

Los tiempos de ejecución del proceso manual, documentados en la línea base de la fase 1, se compararon con los del flujo automatizado, registrados durante una semana de observación una vez que los flujos ya llevaban cinco meses en producción, en fase 4, bajaron más de 97% en los tres procesos; 97.7% en BioTime y SSH, 99.6% en HetrixTools, con una dispersión baja, desviación estandar entre 2.30 y 4.08 segundos, que respalda la estabilidad de esa mejora, la tasa de éxito operativo también subió en los tres casos: 20 puntos porcentuales en BioTime y HetrixTools, 40 en SSH. El análisis de causa raíz fue revelador debido a que los fallos de los flujos de N8N en producción no vinieron de su lógica interna, sino de dependencias externas, como la disponibilidad de APIs, conexión SSH, respuestas de Telegram, N8N no eliminó los fallos por disponibilidad externa, pero sí redujo los errores por intervención manual, trasladó el origen del problema hacia condiciones que ahora pueden monitorearse y corregirse de forma sistemática.

Sobre la percepción de los 28 colaboradores, tanto la encuesta de usabilidad como la medición de tiempos que compara la Tabla 7 se aplicaron cuando los flujos ya llevaban cinco meses operando en producción, no en sus primeras semanas, ese margen de espera tuvo un propósito claro, captar el comportamiento ya estabilizado del flujo y la experiencia de un personal para quien la herramienta ya forma parte de su trabajo diario, en lugar de medir tiempos todavía inestables o recoger una primera impresión que pudiera sobrevalorar o subestimar la herramienta por su novedad, la valoración media pasó de 1.76 en el proceso manual a 4.27 con N8N, la prueba Z de proporciones confirmó esa diferencia, como la satisfacción alta con la plataforma superó de forma significativa el umbral del 80%, Z = 5.92; p < .001, mientras que la del proceso manual quedó muy por debajo de ese nivel, Z = −18.59; p < .001, el personal, en suma, ya adoptó la herramienta como parte de sus tareas diarias, es decir, le reconoce valor práctico y muestra poca resistencia al cambio.

Seis expertos en tecnología evaluaron además los tres flujos con la norma ISO/IEC 9126 adaptada a plataformas workflow, en seis características; funcionalidad, confiabilidad, usabilidad, eficiencia, seguridad y escalabilidad, el promedio general llegó a 4.73 sobre 5, y un 94.62% de cumplimiento. Funcionalidad y seguridad sacaron la nota más alta 4.83 y 96.67%, lo que respalda que la plataforma puede manejar con confianza información sensible del ISP, escalabilidad, por su parte, llegó a 4.75, los expertos consideran viable extender la arquitectura de N8N a nuevos procesos y adaptarla ante cambios regulatorios sin rediseñarla por completo, que era precisamente la capacidad que este objetivo buscaba verificar.

Un último criterio, centrado en el esfuerzo tecnológico y el costo de oportunidad, completó el beneficio de esta herramienta, la conveniencia de automatizar con N8N no depende solo del tiempo ahorrado por ejecución, sino también de la frecuencia de uso y del número de dependencias externas de cada flujo, bajo ese criterio, HetrixTools resultó el más eficiente en costo de oportunidad, mientras que BioTime, pese a su alta reducción porcentual de tiempo, mostró el retorno más lento por su frecuencia mensual.

El estudio avanza en cerrar los tres vacíos que planteaba el marco teórico, aunque conviene ajustar su alcance, se trata de un caso único, y sus resultados no pueden generalizarse sin nuevas réplicas, en lo tecnológico, indicadores cuantitativos del desempeño real de N8N frente a procesos manuales, algo que la literatura sobre low-code no había hecho más allá de lo teórico, en lo sectorial, reduce la brecha al poner la mirada en los ISP medianos de América Latina, un segmento casi ausente en la literatura revisada, concentrada en grandes corporaciones y en los sectores financiero o de salud, en lo metodológico, combina en un solo diseño una comparación cuantitativa, la medición de usabilidad con instrumento censal, el análisis inferencial mediante prueba de hipótesis para proporciones y la evaluación experta de calidad de software con una norma adaptada a plataformas workflow, algo sin antecedentes directos en la literatura revisada, esta propuesta puede servir de referencia metodológica, y de punto de partida, para replicar o extender el estudio en otros proveedores de la región.

Limitaciones del estudio y líneas futuras de investigación

Es pertinente precisar el alcance real de estos hallazgos, los resultados corresponden al análisis de procesos internos en distintas áreas de un único ISP ecuatoriano de tamaño mediano, con una población de 28 colaboradores, esa delimitación permitió entender a fondo las condiciones normativas, operativas y tecnológicas del caso estudiado, pero restringe qué tanto se pueden generalizar estos hallazgos hacia proveedores con otra estructura, otras capacidades técnicas u otras dinámicas institucionales, el valor del estudio está, entonces, en la evidencia que arrojó sobre sus propios procesos internos, más que en representar a todos los ISP.

El momento elegido para medir los tiempos de ejecución fue una vez que los flujos ya llevaban cinco meses operando, y respondió a dos criterios; para ese punto, los colaboradores ya estaban familiarizados con la herramienta, y los flujos habían recibido sus últimas mejoras, esperar hasta entonces permitió evitar una automatización todavía inestable y capturar su comportamiento real, con la herramienta ya incorporada al trabajo diario del personal, dentro de esa ventana solo se dispone de una semana de observación, la dispersión reducida entre las diez ejecuciones por proceso respalda la consistencia del flujo durante esos días, pero dice poco sobre lo que podría ocurrir frente a un pico de demanda, una interrupción externa o un aumento sostenido en el volumen de datos.

La encuesta de usabilidad se aplicó una sola vez, con dos secciones que permitieron a cada colaborador comparar directamente su experiencia con el proceso manual y con N8N en un mismo momento, con ambos enfoques ya vividos y el tiempo suficiente para formarse una percepción sólida de cada uno, esta comparación de antes y después encuentra respaldo en el propio diseño del estudio, el diagnóstico documentado en la Fase 1 ya había identificado antes de introducir N8N las mismas dificultades que los colaboradores señalan en la Sección A del instrumento, los tiempos de ejecución elevados, tasas de error de hasta el 60 % y ausencia de trazabilidad formal, según la Tabla 6, que la percepción recogida meses después coincida con ese levantamiento inicial confirma que la valoración de la Sección A refleja un problema real y documentado, no una simple impresión posterior a la llegada de N8N, un diseño explícito de antes y después, una medición justo antes de introducir N8N y otra con el flujo ya consolidado, permitiría contrastar de forma más directa cómo evolucionó esa percepción a lo largo del proceso de adopción.

Los seis expertos que evaluaron la calidad del software pertenecen al área de Tecnología y Analítica de Datos, personal que en su labor cotidiana desarrolla, verifica y valida sistemas antes de entrar a producción y mientras están funcionando, por conocer de cerca el funcionamiento interno del ISP, pudieron valorar la funcionalidad, confiabilidad, usabilidad, eficiencia, seguridad y escalabilidad de los flujos con criterio técnico especializado, sin embargo, al ser todos de la misma organización, la evaluación refleja sobre todo las necesidades y condiciones tecnológicas de ese ISP en particular, por lo que traer expertos externos permitiría comparar estos resultados con otros entornos y sumar más variedad del criterio técnico.

La consistencia interna del instrumento de percepción de usabilidad también tiene un problema que conviene señalar, el Alfa de Cronbach resultó bajo en ambas secciones, con α = 0.556 en la manual, α = 0.030 en la de N8N, y aunque esto se explica por la homogeneidad de las respuestas dentro de cada sección y no invalida la dirección del hallazgo, sí limita la confiabilidad interna del instrumento tal como fue aplicado, a esto se suma que la encuesta se administró cuando los flujos de N8N ya llevaban cinco meses en producción, lo que pudo introducir un sesgo de familiaridad, los colaboradores ya acostumbrados a la herramienta tienden a valorarla mejor que si la hubieran evaluado en sus primeras semanas de uso. Futuras investigaciones podrían mitigar ambos problemas empleando instrumentos validados y ampliamente probados, como la System Usability Scale (SUS), que tiene normas de interpretación ya establecidas y no depende de una escala construida ad hoc para el estudio.

Las mediciones de tiempos y de tasa de éxito, tanto en la línea base manual (Fases 1-2) como en la fase post-automatización (Fase 4), fueron realizadas por un único observador (el investigador), sin un segundo evaluador independiente que permitiera contrastar la consistencia de los criterios de clasificación aplicados, si bien el criterio de fallo se mantuvo constante entre ambas fases, no puede descartarse cierto grado de subjetividad en la clasificación de casos límite, ese riesgo propio de cualquier diseño de observador único, se podría reducir incorporando un segundo evaluador y calculando un índice de concordancia entre observadores.

Estas limitaciones dejan varias puertas abiertas para seguir investigando, una de ellas es alargar la ventana de observación a meses o trimestres, con más ejecuciones registradas para ver si la estacionalidad, la demanda o el crecimiento del volumen de operaciones cambian los resultados, otra es replicar el diseño en ISP medianos de Ecuador y de países como Colombia, Perú o Bolivia, esta comparación permitiría saber si la brecha sectorial identificada es propia del contexto ecuatoriano o se repite en otros proveedores latinoamericanos de conectividad.3

Dado que la escalabilidad regulatoria es uno de los ejes centrales de este estudio, también sería relevante desarrollar un estudio longitudinal que mida el esfuerzo técnico requerido para adaptar los flujos de N8N ante una disposición concreta de la ARCOTEL, en la presente investigación, esa capacidad se valoró mediante el criterio de expertos, una evaluación posterior permitiría observarla directamente durante un proceso real de modificación normativa y determinar los recursos, tiempos y ajustes necesarios.

El flujo SSH, con Gemini interpretando las salidas de línea de comandos, deja abierta una pregunta: ¿hasta qué punto conviene darles más autonomía a estos agentes sin perder el control que hoy da la consulta interactiva con el técnico?, esa misma lógica podría extenderse a otros procesos del ISP, como facturación, incorporación de clientes, gestión de incidencias o generación de reportes, para comprobar si los beneficios se mantienen en operaciones distintas.

Agradecimientos

Los autores agradecen al ISP que facilitó el acceso a sus procesos internos y a su personal para este estudio, así como a los 28 colaboradores y a los seis expertos técnicos que participaron voluntariamente en las mediciones y evaluaciones aquí reportadas. También agradecen el acompañamiento metodológico que recibieron durante la investigación.

Contribución de los autores

Julio Javier Villares Jimenez: Conceptualización, Metodología, Curación de datos, Análisis formal, Investigación, Software, Validación, Visualización, Redacción- borrador original del artículo, Redacción- revisión y edición del artículo. Damar Alejandra Taylor Vivanco: Conceptualización, Metodología, Curación de datos, Análisis formal, Investigación, Validación, Visualización, Redacción- borrador original del artículo, Redacción- revisión y edición del artículo. Jorge Luis Vinueza-Martínez: Supervisión, Redacción- revisión y edición del artículo.

Conflictos de interés

Los autores declaran no tener ningún conflicto de interés en relación con el presente artículo.

Referencias bibliográficas

Ajimati, M. O., Carroll, N., & Maher, M. (2025). Adoption of low-code and no-code development: A systematic literature review and future research agenda. Journal of Systems a nd Software, 222, 112300. https://doi.org/10.1016/J.JSS.2024.112300

Annarelli, A., Palombi, G., Nonino, F., & Sobczak, A. (2022). Robotic process automation as a digital transformation tool for increasing organizational resilience in Polish enterprises. Sustainability, 14(3), 1333. https://doi.org/10.3390/SU14031333

Barra, F. L., Rodella, G., Costa, A., Scalogna, A., Carenzo, L., Monzani, A., & Corte, F. Della. (2025). From prompt to platform: an agentic AI workflow for healthcare simulation scenario design. Advances in Simulation, 10(1), 29. https://doi.org/10.1186/S41077-025-00357-Z

Basili, V. R., & Weiss, D. M. (1984). A methodology for collecting valid software engineering data. IEEE Transactions on Software Engineering, SE-10(6), 728–738. https://doi.org/10.1109/TSE.1984.5010301

Cascais Brás, J., Pereira, R. F., Melo, M., Bianchi, I. S., & Ribeiro, R. (2025). Balancing business, IT, and human capital: RPA integration and governance dynamics. Information, 16(9), 793. https://doi.org/10.3390/INFO16090793

Chen, Y., Ran, F., Jin, X., Liu, H., & Wang, Z. (2024). Robust service deployment for edge computing in industrial internet with joint profit awareness and multi-server collaboration. The Journal of Supercomputing, 81(1), 84. https://doi.org/10.1007/S11227-024-06609-5

Consejo Nacional de Telecomunicaciones [CONATEL]. (2009). Resolución 216-09-CONATEL-2009: Parámetros de calidad del servicio de valor agregado de Internet. Registro Oficial No. 30, 21 de septiembre de 2009. https://megatel.ec/docs/Normas-de-Calidad.pdf

Curty, S., Härer, F., & Fill, H. G. (2023). Design of blockchain-based applications using model-driven engineering and low-code/no-code platforms: A structured literature review. Software and Systems Modeling, 22(6), 1857–1895. https://doi.org/10.1007/S10270-023-01109-1

Farinha, D., Pereira, R., & Almeida, R. (2024). A framework to support robotic process automation. Journal of Information Technology, 39(1), 149–166. https://doi.org/10.1177/02683962231165066

Filgueiras, L. V. L., Corrêa, P. L. P., Alves-Souza, S. N., Teodoro, S. M., Silva, M. S. P. da, Encinas Quille, R. V., & Demuner, V. R. de S. (2022). Working with robotic process automation: User experience after 18 months of adoption. Frontiers in Computer Science, 4, 936146. https://doi.org/10.3389/fcomp.2022.936146

Gavrila Gavrila, S., Blanco González-Tejero, C., Gómez Gandía, J. A., & de Lucas Ancillo, A. (2023). The impact of automation and optimization on customer experience: A consumer perspective. Humanities and Social Sciences Communications, 10(1), 877. https://doi.org/10.1057/S41599-023-02389-0

Gómez Gandía, J. A., Gavrila Gavrila, S., de Lucas Ancillo, A., & del Val Núñez, M. T. (2024). RPA as a challenge beyond technology: Self-learning and attitude needed for successful RPA implementation in the workplace. Journal of the Knowledge Economy, 15(4), 19628–19655. https://doi.org/10.1007/S13132-024-01865-5

He, X., He, Z., Li, W., Liu, G., & Wei, X. (2025). Framework for real-time monitoring of packet loss caused by network congestion. IEEE Transactions on Network and Service Management, 22(6), 5775–5787. https://doi.org/10.1109/TNSM.2025.3578056

Hernández Sampieri, R., Fernández Collado, C., & Baptista Lucio, M. D. P. (2014). Metodología de la investigación (6th ed.). McGraw Hill España.

Huang, F., & Vasarhelyi, M. A. (2019). Applying robotic process automation (RPA) in auditing: A framework. International Journal of Accounting Information Systems, 35, 100433. https://doi.org/10.1016/J.ACCINF.2019.100433

Huang, W. L., Liao, S. L., Huang, H. L., Su, Y. X., Jerng, J. S., Lu, C. Y., Ho, W. S., & Xu, J. R. (2024). A case study of lean digital transformation through robotic process automation in healthcare. Scientific Reports, 14(1), 14626. https://doi.org/10.1038/S41598-024-65715-9

International Organization for Standardization [ISO]. (2001). Software engineering — Product quality — Part 1: Quality model (ISO/IEC 9126-1). https://www.iso.org/standard/22749.html

Katsonis, N., Sfakianakis, M., & Myloni, B. (2018). Strategic development and business process automation networks in Greek tele-companies. Journal for International Business and Entrepreneurship Development, 11(1), 40–52. https://doi.org/10.1504/JIBED.2018.090039

Kokina, J., Langmann, C., & Weiser, M. (2026). Navigating the RPA governance landscape: Evidence from the field. International Journal of Accounting Information Systems, 57, 100784. https://doi.org/10.1016/J.ACCINF.2026.100784

Larios Soldevilla, O. A., & Atoche Socola, C. J. (2023). La automatización robótica de procesos y su relación con la operatividad de los procesos contables en las empresas de telecomunicaciones y banca en los países de Argentina, Chile, Colombia y Perú en el año 2021. Contabilidad y Negocios, 18(35), 67–95. https://doi.org/10.18800/contabilidad.202301.001

Malik, P. K., Sharma, R., Singh, R., Gehlot, A., Satapathy, S. C., Alnumay, W. S., Pelusi, D., Ghosh, U., & Nayak, J. (2021). Industrial internet of things and its applications in Industry 4.0: State of the art. Computer Communications, 166, 125–139. https://doi.org/10.1016/J.COMCOM.2020.11.016

Mora Chavez, Y. J., Fernández Gonzalez, R. B., Honores Tapia, J. A., & Valarezo Pardo, M. R. (2025). Buenas prácticas de seguridad para la implementación de inteligencia artificial en entornos de computación en la nube. Informática y Sistemas, 9(2), 152–163. https://doi.org/10.33936/isrtic.v9i2.7687

Moreno, M. S. (2025). Automatización inteligente para procesos correctos: N8N como motor de eficiencia digital. Innovación y Software, 6(2), 58–73. https://doi.org/10.48168/innosoft.s24.a321

Patrício, L., Varela, L., Silveira, Z., Felgueiras, C., & Pereira, F. (2025). A framework for integrating robotic process automation with artificial intelligence applied to Industry 5.0. Applied Sciences, 15(13), 7402. https://doi.org/10.3390/APP15137402

Pflughoeft, K. A., Butz, N. T., & Corbley, A. (2025). Customer churn prediction for fixed wireless access: The case of a regional internet service provider. Telecommunications Policy, 49(4), 102929. https://doi.org/10.1016/J.TELPOL.2025.102929

Raisch, S., & Krakowski, S. (2021). Artificial intelligence and management: The automation–augmentation paradox. Academy of Management Review, 46(1), 192–210. https://doi.org/10.5465/AMR.2018.0072

Rejeb, A., & Keogh, J. G. (2021). 5G networks in the value chain. Wireless Personal Communications, 117(2), 1577–1599. https://doi.org/10.1007/S11277-020-07936-5

Shi, Z., Dong, J., & Gan, Y. (2025). Democratizing digital transformation: A multisector study of low-code adoption patterns, limitations, and emerging paradigms. Applied Sciences, 15(12), 6481. https://doi.org/10.3390/APP15126481

Streiner, D. L. (2003). Starting at the beginning: An introduction to coefficient alpha and internal consistency. Journal of Personality Assessment, 80(1), 99–103. https://doi.org/10.1207/S15327752JPA8001_18

Syed, R., Suriadi, S., Adams, M., Bandara, W., Leemans, S. J. J., Ouyang, C., ter Hofstede, A. H. M., van de Weerd, I., Wynn, M. T., & Reijers, H. A. (2020). Robotic process automation: Contemporary themes and challenges. Computers in Industry, 115, 103162. https://doi.org/10.1016/J.COMPIND.2019.103162

Tenecela Tocto, B. P., Zuñiga Iñiguez, K. J., Mazón Olivo, B. E., & Taylor Vivanco, D. A. (2026). Arquitectura hexagonal y microservicios para la digitalización de procesos administrativos en una institución pública: Caso de gestión de vacaciones y permisos. Informática y Sistemas, 10(1), 79–97. https://doi.org/10.33936/ISRTIC.V10I1.8441

Vial, G. (2019). Understanding digital transformation: A review and a research agenda. The Journal of Strategic Information Systems, 28(2), 118–144. https://doi.org/10.1016/J.JSIS.2019.01.003

Vollenberg, C., Hackl, J., Matthies, B., & Coners, A. (2024). Acceptance of RPA in public sector institutions. Journal of Organizational Computing and Electronic Commerce, 34(4), 400–418. https://doi.org/10.1080/10919392.2024.2365446

Walpole, R. E., Myers, R. H., Myers, S. L., & Ye, K. (2012). Probabilidad y estadística para ingeniería y ciencias (9th ed.). Pearson.

Villares Jimenez, J. J., Taylor Vivanco, D. A., & Vinueza-Martinez, J. (2026). Evaluación Comparativa entre N8N y Procesos Manuales para la Automatización de Procesos en un Proveedor de Servicios de Internet en Ecuador. Zenodo. https://doi.org/10.5281/zenodo.22136281

162

Tabla 1. Análisis de estudios previos en temáticas de automatización de procesos en diferentes sectores.

Fuente: Los autores

Autor(es) y año	Sector / Contexto	Tecnología evaluada	Metodología	Hallazgos principales	Gap respecto al presente estudio
F. Huang & Vasarhelyi (2019)	Auditoría / Estados Unidos	RPA aplicado a auditoría	Propuesta de framework + proyecto piloto, proceso de confirmación	RPA que libera a los auditores de tareas repetitivas para enfocarse en juicio experto.	Aplica la misma idea de liberar personal de tareas repetitivas, esta vez medida con una comparativa estadística.
Annarelli et al. (2022)	Diversos sectores / Polonia	RPA como herramienta de transformación digital	Cuantitativo MCA + cualitativo entrevistas	El posicionamiento estratégico de RPA incrementa la resiliencia organizacional en empresas medianas.	Perfil de empresa mediana cercano al del ISP, que en este caso se somete a indicadores concretos de tiempo y éxito operativo.
Filgueiras et al. (2022)	Automatización de procesos / Internacional	RPA	Estudio longitudinal de experiencia de usuario cualitativo por 18 meses	RPA reduce carga operativa e impulsa el desarrollo profesional, pese a la poca visibilidad en la gestión de los robots.	No aborda desempeño cuantitativo, vacío que se cubre con métricas de tiempos y errores en un ISP mediano.
Curty et al. (2023)	Desarrollo de software y Transversal	Plataformas low-code/no-code (LCNC)	Revisión sistemática de literatura	LCNC reduce barreras técnicas y democratiza el desarrollo con relevancia creciente en integración de sistemas.	Valida desde la teoría los beneficios del low-code, y el estudio del ISP los comprueba en un entorno real.
Larios Soldevilla & Atoche Socola (2023)	Telecomunicaciones y banca / Latinoamérica	RPA en herramientas corporativas	Correlacional / Revisión	RPA mejora la operatividad de procesos contables en grandes corporaciones de telecomunicaciones.	Confirma la relevancia de evaluar RPA en telecomunicaciones, aunque limitada a grandes corporaciones, un enfoque que este trabajo traslada a los ISP medianos.
W. L. Huang et al. (2024)	Salud / Asia (Taiwán)	Lean Digital + RPA	Estudio de caso - DMAIC Lean Six Sigma	Automatización reduce el tiempo de proceso en 380 minutos y mejora la eficiencia del 69% al 95.5% en reclamaciones de gastos médicos.	Confirma que la automatización reduce tiempos de proceso; esa misma lógica se traslada, en este caso, a un ISP.
Vollenberg et al. (2024)	Sector público / Alemania	RPA	Estudio cualitativo (teoría fundamentada, entrevistas funcionarios públicos)	La aceptación de RPA depende de la facilidad de uso percibida, aunque en la práctica resulta menos simple de lo que asume la literatura.	La aceptación depende de percepciones subjetivas más allá del desempeño real, algo que este estudio contrasta con métricas objetivas de tiempo, éxito operativo y usabilidad.
Barra et al. (2025)	Salud / Internacional	Agentes cognitivos de IA	Estudio de caso de flujos clínicos	Agentes automatizados coordinan sistemas heterogéneos y reducen tiempos de procesamiento mejorando precisión.	Los agentes clínicos del estudio redujeron tiempos y mejoraron precisión, algo similar que se observa en los procesos del ISP.
Moreno (2025)	Desarrollo de software / Transversal	Comparativa técnica de N8N con Zapier y Make	Análisis comparativo técnico y conceptual	N8N ofrece mayor flexibilidad, control de datos y soberanía tecnológica frente a Zapier y Make, por su arquitectura modular de triggers y nodos.	N8N supera a Make y Zapier en soberanía de datos, flexibilidad y arquitectura modular, pero esa ventaja no había sido probada en campo, algo que este estudio la aplica en un ISP de la región.
Patrício et al. (2025)	Industria 5.0 / Transversal	RPA-IA en Automatización Cognitiva	Conceptual / Revisión sistemática (PICO)	La integración de IA en RPA mejora la toma de decisiones cognitiva y habilita la colaboración humano y máquina.	Aporta un marco teórico sólido pero conceptual, donde la discusión se traslada aquí a evidencia empírica, con datos de campo y percepción de usabilidad en un entorno real.
Kokina et al. (2026)	Empresas de EE. UU. y Europa	Multisector, RPA (Robotic Process Automation)	Estudio cualitativo - 19 entrevistas a 24 profesionales en 16 empresas	La gobernanza de RPA influye significativamente en el desempeño de la automatización.	Documenta la gobernanza como factor de desempeño de forma cualitativa; se añaden métricas de tiempo, usabilidad y éxito operativo.
Tenecela Tocto et al. (2026)	Sector público / Ecuador (talento humano)	Arquitectura hexagonal + microservicios (desarrollo a medida, sin plataforma low-code)	As-Is/To-Be + Extreme Programmingvalidación funcional, de rendimiento y evaluación ISO/IEC 25010	Redujo el tiempo de registro de una solicitud de 10 minutos a menos de 1.5 segundos logrando una mejora superior al 99.7%, con evaluación de expertos en TI superior a 4.4/5 en calidad de software.	Referencia comparativa en Ecuador con arquitectura hexagonal y de microservicios, donde sus resultados contextualizan las mejoras de N8N frente a los procesos manuales del ISP.

163

Nota. Términos implementados en la revisión literaria: LCNC = Low-Code/No-Code; RPA = Robotic Process Automation; SEM = Structural Equation Modelling; ISP = Internet Service Provider.

164

165

166

Código	Nombre del flujo	Área responsable	Frecuencia	Descripción del proceso manual
P1	BioTime - Reporte de multas por timbrado	Tecnología y Analítica de Datos / Talento Humano	Mensual	Descarga manual de registros biométricos desde BioTime, consolidación en hojas de cálculo y cálculo manual de multas por ausencias y atrasos para generar reporte de descuentos de nómina.
P2	HetrixTools -Monitoreo de listas negras de IPs	Seguridad de la Información	Diaria	Verificación manual de las IPs públicas del ISP en el portal HetrixTools, identificación individual de infracciones en listas negras y gestión de las solicitudes de deslistamiento con el proveedor de correo.
P3	SSH -Monitoreo de interfaces y potencias ópticas de red	Infraestructura / Networking y Service Delivery	Según demanda diaria	El técnico de campo contacta a personal del Centro de Operaciones de Red (NOC) para validar remotamente el estado del enlace, se conecta por SSH a cada equipo para ejecutar los comandos necesarios y elabora un reporte sin registro estructurado.

Nota. P1 = Flujo BioTime; P2 = Flujo HetrixTools; P3 = Flujo SSH. Los nombres de los flujos corresponden a la denominación interna adoptada en la implementación de N8N.

Nota. Los valores de referencia son los registros de línea base de la Fase 1.

Tabla 2. Procesos manuales seleccionados para evaluación comparativa.

Fuente: Los autores

Tabla 3. Operacionalización de variables, indicadores e instrumentos de medición.

Fuente: Los autores

Variable	Indicador	Instrumento	Valores de referencia
Independiente	Tipo de enfoque operativo: proceso manual vs. N8N	Observación directa y registro de ejecuciones	Categórica: manual / automatizado
Dependiente – Tiempo de ejecución	Tiempo promedio por ciclo (min/seg)	Cronómetro manual (proceso manual); historial de logs de N8N (proceso automatizado)	P1: 90 min; P2: 120 min; P3: 45 min (línea base manual)
Dependiente – Tasa de éxito operativo	% de ejecuciones completadas sin errores ni intervención adicional	Registro de observación directa (n = 10 ejecuciones por proceso en cada enfoque)	P1: 50%; P2: 70%; P3: 40% (línea base manual)
Dependiente – Percepción de usabilidad	Valoración del colaborador sobre facilidad, claridad y confianza en el proceso	Encuesta Likert 1–5 aplicada a los 28 colaboradores (diseño censal); α por sección	Sección A (manual): μ = 1.76; Sección B (N8N): μ = 4.27

Tabla 4. Estructura del instrumento de percepción de usabilidad (escala Likert 1–5).

Fuente: Los autores

Ítem	Descriptor	Sección	Indicador objetivo
1	Facilidad para ejecutar el proceso sin cometer errores	A – Proceso manual	Tiempo, complejidad operativa
2	Claridad en los pasos a seguir durante la ejecución	A – Proceso manual	Complejidad operativa
3	Frecuencia con la que ocurren errores durante la ejecución	A – Proceso manual	Tasa de error
4	Confianza en los resultados obtenidos al finalizar el proceso	A – Proceso manual	Tasa de éxito
5	Necesidad de intervención adicional para corregir el proceso	A – Proceso manual	Autonomía del proceso
6	Facilidad de uso de los flujos automatizados en N8N	B – Flujo N8N	Usabilidad
7	Claridad y comprensión de los flujos automatizados	B – Flujo N8N	Comprensión del flujo
8	Confianza en los resultados generados por N8N	B – Flujo N8N	Tasa de éxito
9	Reducción del tiempo percibida con N8N respecto al proceso manual	B – Flujo N8N	Eficiencia temporal
10	Disposición a utilizar N8N para automatizar otros procesos	B – Flujo N8N	Escalabilidad percibida

167

Nota. La escala de valoración de la encuesta comprende cinco niveles: del 1 al 5 correspondientes a totalmente en desacuerdo, en desacuerdo, ni de acuerdo ni en desacuerdo, de acuerdo y totalmente de acuerdo.

168

Tabla 5. Características técnicas de los flujos automatizados en N8N.

Fuente: Los autores

Proceso	Nodos principales	Integraciones	Función automatizada central
P1. BioTime	8 nodos secuenciales: Schedule Trigger, Generate Token, Get Punches, Split Out, Calc_No_Punch, Calc_SumTotal, Convert to File, Send Email.	OAuth2, correo electrónico SMTP hacia asistente de Talento Humano.	El flujo se conecta a BioTime, extrae los registros de timbrado, calcula ausencias y atrasos, con estos datos genera un reporte XLSX con ID, nombre, cargo y monto de multa por colaborador, y lo envía automáticamente.
P2. HetrixTools	Nodos de consulta API, Split, nodo de decisión condicional y nodo de notificación.	API HetrixTools para la verificación de blacklists IPv4, canal de notificación a equipo de Seguridad de la Información.	Este segundo flujo revisa cada IP pública del ISP, segmenta los resultados y comprueba si alguna aparece en una blacklist, si la encuentra, notifica al equipo con el detalle de la IP afectada y el motivo de la infracción.
P3. SSH	Nodos de validación de IP, SSH, integración con módulo de inteligencia artificial, nodo de consulta interactiva y nodo de reporte.	Protocolo SSH a equipos de red, Gemini para interpretación de salidas CLI.	En el tercer caso, se valida la IP y el equipo, se conecta por SSH y corre show interface status, la Inteligencia Artificial lee los campos port, name, status, pregunta al técnico qué interfaz revisar y con esta información ejecuta show interfaces transceiver details para traer las potencias ópticas.

Nota. OAuth2 = Open Authorization 2.0; RBAC = Role-Based Access Control; SSH = Secure Shell; SMTP = Simple Mail Transfer Protocol; XLSX = formato Microsoft Excel; CLI = Command Line Interface; IA = Inteligencia Artificial.

Figura 1. Flujo automatizado en N8N para el reporte de multas por timbrado biométrico – Flujo BioTime (P1).

Fuente: Los autores.

169

Figura 2. Flujo automatizado en N8N para el monitoreo de listas negras de IPs – Flujo HetrixTools (P2).

Fuente: Los autores.

Figura 3. Flujo automatizado en N8N para el monitoreo interactivo de interfaces y potencias ópticas – Flujo SSH (P3).

Fuente: Los autores.

170

Figura 4. Diseño metodológico del estudio realizado

Fuente: Los autores.

Tabla 6. Cómo operaban los procesos manuales y métricas de línea base.

Fuente: Los autores

Proceso	Entradas	Salidas	Actores	Tiempo (min)	Pasos manuales	Tasa error
P1. BioTime / Multas por timbrado	Registros de timbrado biométrico exportados de BioTime.	Reporte xlsx de multas por colaborador (ID, nombre, cargo, monto).	1 a 2 personas	90	10	50%
P2. HetrixTools / Blacklist IPv4	IPs públicas del ISP para verificación en bases de datos de listas negras.	Informe de IPs en blacklist, con detalle de infracción y notificación a Seguridad.	1 a 2 personas	120	5 a 7	30%
P3. SSH / Interfaces y potencias ópticas	IP del equipo de red y tipo de dispositivo, según lo solicitado por el técnico de campo.	Estado de las interfaces y potencias ópticas del punto consultado.	2 personas (técnico campo y NOC)	45	10	60%

Nota. Los tiempos son el promedio de diez ejecuciones registradas en las dos semanas de levantamiento, la tasa de error es el porcentaje de esas ejecuciones que necesitó corrección o se tuvo que reprocesar.

171

172

Tabla 7. Comparación de tiempos de ejecución: proceso manual versus N8N.

Fuente: Los autores

Nota. El tiempo con N8N es el promedio de diez observaciones tomadas del historial de logs durante la semana de pruebas (Fase 4). La reducción se calculó restando el tiempo con N8N al tiempo manual y dividiendo ese resultado entre el tiempo manual, multiplicado por 100.

Tabla 8. Tasa de éxito operativo, comparativa de proceso manual versus N8N (10 ejecuciones).

Fuente: Los autores

Nota. La tasa de éxito N8N se determinó mediante observación directa de diez ejecuciones por flujo, se clasificó como fallida toda ejecución que registrara error de origen técnico, la dependencia de API externa, tiempo de espera y validación humana incompleta sin completar el resultado esperado.

Proceso	Éxito manual (%)	Éxito N8N (%)	Fallos N8N	Variación (pp)	Causas observadas
P1. BioTime	50%	70%	3/10	+20	API, volumen/paginación, datos nulos, XLSX/SMTP.
P2. HetrixTools	70%	90%	1/10	+20	Rate limit/API, endpoint, certificados, estructura/paginación.
P3. SSH	40%	80%	2/10	+40	SSH, credenciales de acceso, Telegram, timeout de IA.

Proceso	Tiempo manual (min)	Tiempo N8N (seg)	Tiempo N8N (min)	DE (seg)	IC95% (± seg)	Reducción (%)
P1 – Flujo BioTime	90	125.0	2.08	4.08	2.92	97.7%
P2 – Flujo HetrixTools	120	29.8	0.50	2.30	1.65	99.6%
P3 – Flujo SSH	45	62.5	1.04	3.03	2.17	97.7%

173

Ítem	Descriptor	Sección	Media	DE
1 / 6	Claridad del proceso	A / B	1.57 / 4.04	0.63 / 0.58
2 / 7	Eficiencia en tiempo	A / B	1.43 / 4.46	0.50 / 0.64
3 / 8	Confianza en los resultados	A / B	2.11 / 4.32	0.79 / 0.72
4 / 9	Detección y corrección de errores	A / B	1.86 / 4.32	0.85 / 0.67
5 / 10	Satisfacción general	A / B	1.82 / 4.21	0.67 / 0.79
Total	Media general	A / B	1.76 / 4.27	0.73 / 0.69

Figura 5. Análisis de causa raíz y trazabilidad de la mitigación con N8N por proceso evaluado.

Fuente: Los autores.

Tabla 9. Estadística descriptiva del instrumento de percepción de usabilidad por ítem (n=28).

Fuente: Los autores

Nota. Escala Likert 1 (totalmente en desacuerdo) a 5 (totalmente de acuerdo). DE = desviación estándar.

174

Figura 6. Comparación de medias por ítem del instrumento de percepción de usabilidad: proceso manual (Sección A) versus flujo automatizado con N8N (Sección B).

Fuente: Los autores.

Tabla 10. Distribución de respuestas por nivel de satisfacción, prueba de hipótesis para proporciones y decisión, por sección.

Fuente: Los autores

Nota. Moderado, Alto y Muy alto se agruparon como satisfacción alta; Muy bajo y Bajo, como baja. Se calculó Z0 = (p̂ − p0)/√[p0(1−p0)/n], con p̂ = x/n y p0 = 0.80, rechazando H0 si Z0 > 1.645, α = 0.05, unilateral derecha.

Sección	Satisfacción baja (n)	Satisfacción alta (n)	p̂	Z calculado	Z crítico (α=0.05)	Decisión
A – Manual	116	24	0.1714	-18.59	1.645	No se rechaza H0
B – N8N	0	140	1.0000	5.92	1.645	Se rechaza H0

175

Nota. La sumatoria es el total de las valoraciones que los 6 expertos dieron a los criterios de cada característica, el instrumento tiene 15 criterios repartidos de forma distinta entre las características (sección 2.4). Promedio es igual a sumatoria sobre la cantidad de expertos por la cantidad de criterios de la característica. Porcentaje de cumplimiento es igual a promedio sobre cinco por cien. Escala del uno al cinco, desde deficiente hasta excelente respectivamente.

Tabla 11. Resultados de la evaluación de calidad de flujos N8N según norma ISO/IEC 9126 (2001) adaptada (n = 6 expertos).

Fuente: Los autores

Figura 7. Cumplimiento de la evaluación de calidad ISO/IEC 9126 adaptada por característica de los flujos N8N (n = 6 expertos).

Fuente: Los autores.

176

Característica	N° de encuestados	Sumatoria	Promedio	Porcentaje de cumplimiento	Nivel de calidad
Funcionalidad	6	87	4.83	96.67%	Excelente
Confiabilidad	6	85	4.72	94.44%	Excelente
Usabilidad	6	84	4.67	93.33%	Excelente
Eficiencia	6	55	4.58	91.67%	Excelente
Seguridad	6	58	4.83	96.67%	Excelente
Escalabilidad	6	57	4.75	95.00%	Excelente
Promedio total		426	4.73	94.62%	Excelente

177

Tabla 12. Relación entre beneficio temporal y esfuerzo tecnológico de los flujos N8N

Fuente: Los autores

Nota: en los procesos de uso diario se consideró una ejecución por día durante 22 días laborables al mes, y el COT se estimó como (horas de implementación + mantenimiento anual) / horas operativas recuperadas anualmente × 100, la fila “Dependencia técnica” no incluye las 40 horas de formación inicial, es un costo único, compartido por igual entre los tres flujos.

178

Indicador	BioTime	HetrixTools	SSH
Tiempo manual	90 min	120 min	45 min
Tiempo N8N	2.08 min	0.50 min	1.04 min
Ahorro por ejecución	87.92 min	119.50 min	43.96 min
Frecuencia considerada	Mensual	Diaria	Diaria
Ahorro operativo anual aprox.	17.6 h	525.8 h	193.4 h
Implementación inicial aprox.	22.5 h - 30 h	15–20 h	30–40 h
Mantenimiento ordinario estimado	12 horas al año	12 horas al año	12 horas al año
COT anual aprox.	196% a 239%	5% a 6%	22% a 27 %
Dependencia técnica	Media	Media	Alta
Balance temporal–técnico	Medio a largo plazo	Muy favorable	Favorable

179

180

181

182

183