Cómo es realmente el desarrollo de software a medida para fabricantes: fases, riesgos y métricas de éxito

Solo el 29% de los proyectos de software se entregan a tiempo, dentro de presupuesto y con las funcionalidades acordadas, según el CHAOS Report del Standish Group (2024). En entornos industriales —donde conviven PLCs de 2003, protocolos propietarios y equipos de OT que priorizan la disponibilidad de planta sobre cualquier otra cosa— las probabilidades de fracaso son aún mayores. Este artículo recorre las fases reales de un proyecto de desarrollo de software a medida para fabricantes, los siete puntos de decisión donde los proyectos mueren, y los costes ocultos que destruyen el ROI antes de que el sistema entre en producción.

Por qué fracasan más proyectos de software industrial de los que admite el sector

La tecnología rara vez es la causa del fracaso: los proyectos de software industrial mueren por problemas de personas y proceso, no por complejidad técnica.

Los datos del Standish Group (2024) son contundentes: sobre una muestra de más de 50.000 proyectos, solo el 29% se considera exitoso. El 52% se entrega tarde, por encima de presupuesto o con funcionalidades recortadas, y el 19% se cancela antes de completarse.

Lo que llama la atención es que la falla tecnológica aparece en último lugar entre las causas identificadas. Un estudio de J.L. Partners (2024) con 481 ingenieros de software encontró que los proyectos con requisitos documentados antes de empezar el desarrollo eran un 97% más propensos a tener éxito que los que no los tenían.

Aquí aparece la primera tensión relevante: el mismo estudio de J.L. Partners encontró que los proyectos con especificación previa eran un 50% más propensos a tener éxito, lo que contradice la ortodoxia Agile de “iterar primero y definir después”. El Standish Group, por su parte, indica un 64% de éxito en proyectos Agile frente al 49% en Waterfall. Las fuentes no están de acuerdo, y en un entorno OT donde un parche no planificado puede detener una línea de producción, la tensión entre agilidad y especificación previa tiene consecuencias físicas, no solo metodológicas.

Los datos sectoriales añaden contexto: el scope creep provoca que el 52% de los proyectos a medida superen sus plazos; los problemas de integración con sistemas heredados afectan al 55%; y el 45% de los proyectos superan el presupuesto en un 50% o más.

El diagnóstico más preciso sobre dónde vive el problema en contextos industriales lo articula Globental (2026): “Una fábrica con un ERP y una planta digitalizada sigue teniendo el mismo agujero: entre lo que el sistema administrativo registra y lo que ocurre en la línea, cubierto con formularios en papel, hojas de cálculo y una persona tecleando al final del turno. Ese gap es donde vive el software industrial a medida. No reemplaza al ERP ni al control de máquina. Los conecta.”

El problema de raíz: capturar requisitos cuando ingeniería de proceso e IT hablan idiomas distintos

El mayor riesgo en la fase de requisitos no es que falten funcionalidades —es que el ingeniero de proceso, el responsable de IT y el jefe de planta describen el mismo problema con tres vocabularios incompatibles, y nadie lo detecta hasta que el sistema está a medias.

El ISC2 (2024) lo describe con precisión: los profesionales de IT son “poco familiarizados con las realidades OT como PLCs, sistemas de seguridad, modelos de mantenimiento de proveedores y restricciones de tiempo de inactividad”, mientras que los ingenieros de OT tienen “exposición limitada a riesgos de identidad, modelado de amenazas o expectativas modernas de gobernanza”. Esta brecha cultural es el freno más subestimado para capturar el valor real de la convergencia IT/OT, que BCG (2024) estima en aproximadamente 60.000 millones de dólares a nivel global.

Cómo estructurar el taller de requisitos para que no fracase

Lo que hemos comprobado que funciona en la práctica es separar físicamente las sesiones de captura de requisitos antes de juntarlos:

Sesión 1 (solo OT/proceso): El output es un diagrama de flujo de proceso con los puntos de dato necesarios, sus tolerancias, las condiciones de alarma y los criterios de calidad no negociables. El lenguaje es P&ID, lógica de escalera y OEE, no APIs.

Sesión 2 (solo IT/sistemas): El output es el modelo de datos, la superficie de API, los requisitos de seguridad y la arquitectura de integración con sistemas existentes. El lenguaje es endpoints, latencia y roles de usuario, no presiones de proceso.

Sesión conjunta: Se presentan ambos outputs y se construye un registro explícito de conflictos —con su resolución documentada y firmada por ambas partes. Este registro es el documento vivo que previene las disputas de alcance seis meses después.

Nota: este formato de tres sesiones es juicio de ingeniería basado en práctica de convergencia IT/OT; no existe una fuente primaria que lo valide específicamente como estándar.

En un proyecto de inspección que construimos —Mapper, nuestra plataforma de inspección en la nube— el momento crítico no fue el desarrollo, sino la reconciliación entre los requisitos de exactitud metrológica del ingeniero de inspección y la preferencia del equipo de IT por una arquitectura API-first que priorizaba la velocidad de ingesta sobre la precisión de timestamp. Resolverlo en papel, antes de escribir código, evitó al menos dos iteraciones completas de la capa de datos.

Integración con PLCs, SCADA y sensores: la arqueología de protocolos que nadie presupuesta

Antes de escribir una línea de código, hay que saber exactamente qué protocolos hablan las máquinas —porque descubrirlo a mitad del desarrollo es la causa más frecuente de sobrecostes en proyectos de desarrollo de software a medida para entornos industriales.

FlowFuse (marzo 2026) documenta que Modbus sigue dominando a nivel de dispositivo de campo, incluso en equipos nuevos instalados como primera opción deliberada. OPC UA está creciendo, pero su adopción se concentra en sistemas SCADA, integraciones MES y gateways IT/OT —no en PLCs a nivel de campo. Una instalación industrial típica habla simultáneamente Modbus RTU, Modbus TCP, Profibus DP, HART, EtherNet/IP, OPC DA clásico y dialectos propietarios. PLC Construction (2026) confirma que Modbus RTU, DH+, Profibus y DF1 son los protocolos más frecuentes en proyectos de integración SCADA, y todos requieren traducción a OPC-UA para alimentar capas de datos modernas.

Tabla de referencia: compatibilidad de gateways OPC-UA con PLCs comunes

Estimaciones basadas en experiencia de proyecto; sin fuente primaria verificable para España 2025–2026. Tratar como orientativas.

El patrón de riesgo que más veces hemos visto materializarse es el problema de los 10.000 tags: un driver de protocolo que funciona perfectamente en laboratorio con 50 tags se degrada o falla bajo la carga de producción real con 10.000 tags activos, especialmente cuando la red de campo tiene ruido eléctrico o jitter no planificado. La regla práctica es siempre hacer un load-test del driver contra el número real de tags antes de aprobar la integración.

Nuestro trabajo en el software de inspección de radiación para Enusa Industrias ilustra la dimensión adicional que aparece en entornos OT regulados: además de la complejidad de protocolos, el software debe cumplir con requisitos de trazabilidad y seguridad funcional que afectan directamente a la arquitectura de integración desde el primer día, no como añadido posterior.

El marco de 7 puertas de decisión para desarrollo de software a medida industrial

Lo que no existe en la literatura disponible es un marco de decisión calibrado específicamente para entornos industriales —uno que nombre los puntos exactos donde un proyecto debería pausarse, validarse o cancelarse antes de que la siguiente fase consuma presupuesto sobre una base inestable. Este es el aporte central de este artículo.

Cada puerta (gate) tiene criterios de entrada, criterios de salida y el modo de fallo específico que previene.

Gate 0 — Verificación de madurez del proceso (antes de cualquier trabajo de requisitos)

Criterios de salida: El proceso actual está documentado, es estable y medible. No “lo arreglaremos en el software”.

Modo de fallo que previene: Automatizar un proceso inmaduro. Si el proceso está poco desarrollado, el software implementa los procesos equivocados —y después del despliegue, el equipo culpa al software de un problema que era del proceso.

Gate 1 — Inventario de activos y protocolos (antes de cerrar requisitos)

Criterios de salida: Cada fuente de datos inventariada con: marca/modelo, versión de firmware, protocolo, tasa de actualización de datos y confirmación de si el fabricante permite acceso de lectura por terceros.

Modo de fallo que previene: Descubrir a mitad del proyecto que un PLC de 2003 habla un dialecto propietario sobre enlace serie. Presupuestar al menos un protocolo inesperado es una regla práctica razonable —los datos del sector indican que la integración con sistemas heredados desafía al 55% de los proyectos.

Gate 2 — Firma trilateral de requisitos (antes del diseño de arquitectura)

Criterios de salida: Documento de requisitos firmado por (a) ingeniero de proceso/OT, (b) responsable de IT/sistemas, Y (c) jefe de planta/operaciones —con un registro explícito de conflictos que muestra cómo se resolvieron las discrepancias.

Modo de fallo que previene: Requisitos poco claros y comunicación deficiente, que el Standish Group (2024) identifica como las causas principales de fracaso. Un documento firmado por los tres perfiles es el mecanismo de prevención más eficaz y el más frecuentemente omitido.

Gate 3 — Prueba de concepto de integración (antes del sprint de desarrollo completo)

Criterios de salida: Al menos una lectura de dato en vivo desde el protocolo más complejo u obsoleto, entregada a la capa de datos objetivo, con métricas de latencia y calidad de dato documentadas. Load-test contra el número real de tags.

Modo de fallo que previene: El problema de los 10.000 tags. Descubrir incompatibilidad de protocolo después de tres meses de desarrollo. El coste de referencia: hardware de gateway 500–3.000 €/unidad; ingeniería de integración 40–120 horas por familia de protocolo (juicio de ingeniería).

Gate 4 — Congelación de alcance y activación del control de cambios (al inicio del primer sprint)

Criterios de salida: Proceso formal de control de cambios activo. Cualquier nuevo requisito después de este gate requiere una evaluación de impacto escrita (tiempo + coste + riesgo) antes de ser aceptado.

Modo de fallo que previene: El scope creep, que según los datos disponibles causa que el 52% de los proyectos a medida superen sus plazos. En entornos industriales, el driver específico es que los ingenieros de proceso descubren nuevos puntos de dato que “necesitan” en cuanto ven el sistema funcionando —lo cual es comprensible, pero debe canalizarse a través de un proceso formal.

Gate 5 — Validación escalonada en entorno OT (antes del despliegue en producción)

Criterios de salida: Período de ejecución en paralelo completado (el nuevo sistema corre simultáneamente con el proceso existente, sus salidas se comparan) con una delta documentada inferior al umbral acordado. Ventana de corte programada durante una parada de mantenimiento planificada.

Modo de fallo que previene: El coste de corrección post-lanzamiento, que según el CISQ (citado por Capgemini, 2025) puede ser hasta 30 veces mayor que en la fase de diseño. La revisión IEC 62443-2-1:2024 actualiza los requisitos de programa de seguridad para propietarios de activos OT por primera vez desde 2010; cualquier plan de validación debe reflejar esta jerarquía: seguridad primero, disponibilidad segundo, integridad tercero —el inverso de la mayoría de los marcos IT.

Gate 6 — Preparación para la gestión del cambio y adopción (antes del sign-off de go-live)

Criterios de salida: Todos los operadores de turno formados y evaluados; SOPs actualizados; un “propietario del sistema” designado en el lado del cliente para la gobernanza continua; plan de soporte para los primeros 30 días acordado.

Modo de fallo que previene: Software que se convierte en “shelf-ware”. Implementar nuevas herramientas “debe ir acompañado de gestión del cambio y ajustes de proceso —sin formación adecuada y voluntad de los equipos operativos, los nuevos productos se vuelven ineficaces” (Artefact, 2025). Para una operación de 40 operarios por turno, la formación y reescritura de SOPs puede añadir un 15–25% al coste total del proyecto. Estimación de ingeniería; sin fuente primaria verificable para España.

Los costes ocultos que destruyen el ROI antes del primer turno

Los proyectos de desarrollo de software a medida para fabricantes tienen una estructura de costes ocultos que rara vez aparece en los presupuestos iniciales.

Soporte de protocolos heredados: Cada protocolo propietario adicional añade 40–120 horas de ingeniería y 500–3.000 € en hardware de gateway. Los proyectos descubren habitualmente 2–3 protocolos inesperados durante Gate 1.

Deuda técnica de integración: Los desarrolladores dedican de media el 22% de su tiempo a resolver problemas relacionados con bugs y deuda técnica. En software industrial, esta deuda se manifiesta como adaptadores de protocolo frágiles que se rompen con actualizaciones de firmware de PLCs —actualizaciones que el fabricante realiza sin consultar al equipo de software.

Cumplimiento regulatorio: El 28% de los proyectos de desarrollo a medida sufren retrasos por cumplimiento regulatorio. En contextos industriales, esto incluye IEC 62443, NIS2 (que nombra IEC 62443 como estándar reconocido para seguridad OT), e ISO 13849/IEC 62061 para maquinaria con funciones de seguridad. Estos requisitos deben entrar en la arquitectura desde Gate 2, no como añadido en la fase de validación.

Rangos de coste orientativos y mantenimiento anual (España, 2025–2026)

Todas las cifras son juicio de ingeniería basado en observación de mercado; sin fuente primaria verificable para España.

El mantenimiento de software convencional se estima en el 15–20% del coste de desarrollo inicial por año. Con soporte de protocolos heredados, este porcentaje sube al 20–30% (juicio de ingeniería). Ignorar esta partida en el business case inicial es el error más frecuente que convierte un proyecto rentable en un coste recurrente no planificado.

Métricas de éxito que realmente importan en entornos industriales

Un proyecto de desarrollo de software a medida en un entorno de fabricación no se evalúa solo con las métricas clásicas de software. Las métricas que realmente importan al jefe de planta son:

• OEE antes/después: Si el software conecta datos de máquina con decisiones de operación, el OEE debería moverse en los primeros 90 días de uso real. Si no se mueve, el proyecto no está aportando valor operativo.
• Tiempo de ciclo de informe: ¿Cuánto tardaba generar el informe de turno antes? ¿Cuánto tarda ahora? Esta métrica es fácil de medir y directamente visible para los operarios.
• Tasa de adopción por turno: ¿Qué porcentaje de operarios usa el sistema activamente en cada turno? Una tasa por debajo del 70% a los 60 días de go-live es señal de alerta de gestión del cambio fallida.
• Número de incidencias de integración por mes: Rastrea la estabilidad de los adaptadores de protocolo. Un número creciente indica deuda técnica acumulándose.
• Coste de corrección post-lanzamiento vs. presupuesto de mantenimiento: Si el coste de corrección supera el 30% del presupuesto de mantenimiento anual en el primer año, hay problemas de calidad que Gate 5 no detectó.

El 62% de las empresas manufactureras españolas tienen al menos un nivel básico de digitalización, por debajo de la media europea del 68,3% (Eurostat, 2024). El 34,8% de las empresas industriales españolas fueron innovadoras en 2022–2024, frente a una media nacional del 27,3% (INE, 2024) —lo que sugiere que el sector industrial lidera en intención pero aún tiene margen significativo en ejecución. Medir el ROI real con métricas operativas concretas es lo que convierte esa intención en ventaja competitiva sostenible.

Lecturas relacionadas

• Software a medida para industria — la decisión en cinco filtros: desarrollar, comprar o no tocarlo.
• Automatización de procesos industriales — cómo elegir el primer proceso a automatizar y cuáles dejar en manual.
• Maedcore — Soluciones Digitales — qué construimos en esta área.

Fuentes

• CHAOS Report on IT Project Outcomes — OpenCommons (síntesis de datos Standish Group), 2025
• 268% Higher Failure Rates for Agile Software Projects, Study Finds — Engprax / J.L. Partners, 2024
• Custom Software Development Industry Statistics: Market Data Report 2026 — Gitnux, 2026
• Custom Software Development Statistics 2026: 40+ Data Points — Raftlabs (citando Standish Group CHAOS Report 2024), 2026
• Desarrollo de software industrial de próxima generación: IA aplicada — Capgemini España (citando datos CISQ), 2025
• Software a medida para industria: guía 2026 — Globental, 2026
• Why OPC UA Is Not Replacing Modbus (Yet) — FlowFuse, marzo 2026
• Common SCADA Integration Challenges and How to Solve Them — PLC Construction, 2026
• Converging IT and OT Will Boost Industrial Tech Value — Boston Consulting Group, 2024
• IT/OT Convergence — ISC2, agosto 2024
• IT/OT Convergence: The path to industrial excellence — Artefact, 2025
• IEC 62443 Compliance Guide (ICS/OT) — Breach Craft (citando IEC 62443-2-1:2024), 2026
• Digitalización de PYMEs en España 2026: Estadísticas por Sector y Tamaño — 10Code / ONTSI, INE, Eurostat, 2026
• Digitalización industrial: incentivos fiscales y programas de ayuda — Tecnocim Innova (citando INE 2024, Eurostat 2024), 2026
• Software de Inspección de Radiación para Enusa Industrias — Maedcore