1. El contexto: ¿puede una farmacéutica operar sin SCADA en 2026?
La respuesta incómoda es sí. Y no es un caso aislado.
España cuenta con 181 plantas farmacéuticas activas según el último estudio de Farmaindustria (2024), de las cuales 111 fabrican medicamentos de uso humano. El propio informe de Farmaindustria reconoce explícitamente que uno de los desafíos urgentes del sector es «la necesidad de impulsar la inversión en digitalización» — esto en 2025, no en 2010.
La exposición económica por deuda técnica legacy en el sector farmacéutico español se estima entre 700 y 1.500 millones de euros anuales. Eso no es un problema marginal: es sistémico.
¿Qué hace que una planta farmacéutica llegue a 2026 fabricando medicamentos para el mercado europeo sin un sistema SCADA integrado, con recetas en papel y con PLCs de hace 15 años sin soporte oficial? La respuesta no es incompetencia ni falta de recursos: es una combinación de tres factores que se retroalimentan y que se explican en la siguiente sección.
2. La deuda técnica legacy: el riesgo que no aparece en el balance
La deuda técnica legacy en industria batch es el coste acumulado de operar con sistemas de automatización, control de procesos y gestión de manufactura diseñados para una realidad regulatoria y tecnológica anterior. Incluye PLCs de generaciones pasadas con recetas hardcoded, sistemas MES sin integración IIoT, trazabilidad de lote incompleta y arquitecturas batch que no cumplen los estándares ISA-88 ni los requisitos normativos vigentes.
A diferencia de la deuda financiera, la deuda legacy crece silenciosamente sin aparecer en el balance, hasta que un incidente, una auditoría o un cambio regulatorio la hace visible de golpe. El ratio documentado en el sector europeo es claro:
¿Por qué persiste entonces? Por una combinación de tres factores:
Factor 1 — Inercia operativa
«Llevamos 15 años así y no ha pasado nada.» La frase más cara del sector. El problema no es que haya pasado algo: es que cada año que pasa sin actuar, el sistema se aleja más de los estándares vigentes, los técnicos que lo conocen se jubilan o se van, y el coste de una migración forzosa crece exponencialmente.
Factor 2 — Vendor lock-in estructural
El sistema fue diseñado hace 10-15 años por un integrador que tiene el código fuente, la documentación técnica y el conocimiento del sistema. Cambiar implica negociar desde una posición de debilidad con quien tiene el monopolio técnico. En muchos casos, el integrador original ha cambiado de propietario, de nombre o ha desaparecido, dejando a la planta con sistemas sin soporte real.
Factor 3 — Miedo fundado al riesgo de la migración
Nadie quiere ser el responsable de una parada de producción durante una modernización. Y sin metodología probada, ese miedo está completamente justificado. La buena noticia: la metodología existe, está probada y se describe en detalle en este artículo.
3. Por qué el integrador no puede auditarse a sí mismo
Antes de entrar en los detalles técnicos del proyecto, es necesario abordar una cuestión que se pasa por alto con demasiada frecuencia: ¿quién audita, supervisa y valida la implementación?
La respuesta habitual en muchas empresas es: el propio integrador. Y esto es un error estructural. Un integrador de sistemas, por muy competente y bien intencionado que sea, tiene un conflicto de interés objetivo cuando se le pide que audite su propio trabajo. No es una cuestión de honestidad: es una cuestión de alineamiento de incentivos.
El rol del consultor independiente en este proyecto fue triple:
- Auditoría objetiva e imparcial: el Quick Scan se realizó sin ningún interés comercial en la solución a implementar. El único objetivo era fotografiar la realidad tal como es e identificar todas las brechas.
- Supervisión técnica durante la implementación: con producción corriendo en paralelo en todo momento, actuando como director de obra técnico: verificando que el integrador implementaba exactamente lo definido en el diseño funcional y que la nomenclatura ISA-88 se respetaba en la configuración real.
- Validación independiente y defensa regulatoria: en el momento de la inspección (AEMPS, EMA, FDA), el consultor independiente puede documentar y defender el proceso con total objetividad ante el cliente, los laboratorios y el regulador.
4. Perfil de la empresa y situación de partida
La empresa protagonista es una CMO farmacéutica de capital español con más de 25 años de actividad, ubicada en el área metropolitana de Barcelona. Fabrica formas farmacéuticas sólidas orales (comprimidos, cápsulas, granulados), semisólidos (cremas y pomadas) y líquidos no estériles para cuatro laboratorios farmacéuticos: dos multinacionales europeas y dos laboratorios nacionales.
Con una plantilla de 92 personas y cuatro líneas de producción batch operando en dos turnos, la empresa había crecido de forma orgánica durante dos décadas, acumulando tecnología y procedimientos de manera desorganizada.
El detonante
Una inspección de la AEMPS levantó tres observaciones relacionadas con integridad de datos y trazabilidad de proceso, dos de ellas clasificadas como observaciones mayores bajo los criterios del Anexo 11 GMP. Uno de sus clientes principales amenazó con no renovar el contrato de fabricación si no se certificaba mejora documentada en menos de 12 meses.
Coste económico de la situación inicial
El Quick Scan cuantificó el impacto económico real de la deuda legacy:
| Categoría de ineficiencia | Coste anual estimado |
|---|---|
| Paradas no planificadas | 87.000 € |
| Retrabajos por error de receta | 42.000 € |
| Tiempo operario en registros manuales | 38.000 € |
| Gestión de incidencias GMP | 29.000 € |
| Cambios de producto (tiempo extra) | 35.000 € |
| Total ineficiencias | 231.000 €/año |
Esos 231.000 € anuales son el coste visible. El coste invisible — el riesgo de pérdida del contrato, el riesgo de sanción regulatoria y el riesgo reputacional — es un múltiplo de esa cifra.
5. Fase 0: Quick Scan — Fotografía objetiva de la realidad
El proyecto comenzó con un Quick Scan de dos semanas en planta, realizado íntegramente por el consultor independiente sin participación de ningún integrador ni proveedor de software.
Metodología del Quick Scan
- Entrevistas estructuradas con directora de operaciones, jefes de turno, operarios de línea, responsable de calidad y mantenimiento
- Revisión documental exhaustiva: SOPs, registros de lote, P&ID, documentación de PLCs, histórico de desviaciones GMP de los últimos 24 meses
- Observación directa en planta durante arranques de línea, cambios de producto y gestión de incidencias
- Inventario técnico completo de todos los activos de automatización: PLCs, HMIs, sensores, redes industriales
Hallazgos del Quick Scan
Nivel de automatización y control:
- Cuatro PLCs de distintos fabricantes: Siemens S7-300, Allen-Bradley CompactLogix, Schneider M340 y un Omron CJ2 con más de 14 años sin soporte oficial, sin ninguna capa de supervisión unificada
- Sin SCADA: todos los datos de proceso registrados manualmente en papel por el operario
- HMIs locales en cada línea, sin conectividad entre ellas ni con el MES
- Red industrial plana y sin segmentación, con riesgo OT evidente
Deuda legacy identificada:
- Recetas hardcoded en los PLCs por el integrador original hace ocho años, sin documentación funcional disponible — vendor lock-in total
- 23 versiones distintas de la misma receta en distintos soportes: papel, Excel, memoria del PLC, correos electrónicos. Sin trazabilidad de cuál era la versión vigente
- PLC Omron con 14 años de antigüedad sin soporte técnico: el riesgo legacy más crítico de la planta
- Documentación técnica incompleta o desactualizada en el 70% de los equipos
Trazabilidad y cumplimiento GMP:
- Trazabilidad por lote inferior al 65%
- Audit Trail inexistente a nivel de sistema
- Tres observaciones AEMPS, dos de ellas mayores
Principios de diseño de la hoja de ruta
- Estándar desde el primer día: ISA-88 para batch, ISA-95 para integración MES/ERP
- Eliminar el vendor lock-in estructuralmente: toda la lógica de recetas documentada independientemente del software
- Seguridad OT como requisito no negociable: red OT segmentada, cumplimiento NIS2
- Preparada para UNS/MQTT/Sparkplug B desde el primer tag: nomenclatura compatible con Unified Namespace desde el inicio
6. Fase 1: Modelado ISA-88 — El trabajo que nadie ve pero que lo determina todo
Esta fase duró cuatro semanas y se ejecutó exclusivamente en papel y herramientas de modelado, antes de tocar ningún PLC ni configurar ningún servidor. Es la fase que más frecuentemente se infravalora y la que, cuando se recorta, hace fallar el proyecto entero.
Modelo físico ISA-88
Jerarquía completa definida conforme al estándar:
Empresa → Planta → Área de proceso → Unidad de proceso → Módulo de equipo → Elemento de control
Unidades de proceso documentadas: mezcladores de alta cizalla, granuladores de lecho fluidizado, secadores, prensas de comprimidos (3 unidades), líneas de blistering (2 líneas), encapsuladoras y sistemas de pesaje de materias primas. Para cada unidad: módulos de equipo completos con válvulas, bombas, sensores, agitadores y sistemas CIP.
Modelo procedimental ISA-88
Conversión de las 23 versiones de receta en papel a recetas maestras estructuradas:
Fases estándar reutilizables definidas: carga de materias primas, mezclado en seco, adición de líquido granulante, granulación húmeda, secado, calibración, mezcla de lubricación, compresión, recubrimiento, encapsulado.
Nomenclatura de tags definida con la estructura:
7. Fase 2: Arquitectura del sistema SCADA y servidor OT
La instalación del servidor SCADA, la configuración de la red OT y la conexión de los PLCs se realizaron en paralelo con la producción, sin interferir en ningún momento con las líneas activas.
Capa de campo: conectividad OT
- Gateways OPC-UA instalados sobre los PLCs existentes para normalizar la comunicación heterogénea entre fabricantes
- Sustitución del PLC Omron CJ2 (14 años, sin soporte) por hardware actual, con migración supervisada por el consultor independiente
- Actualización de firmware de los PLCs restantes para habilitar OPC-UA Server nativo
Servidor SCADA OT: Ignition (Inductive Automation)
La selección de Ignition sobre otras alternativas (Wonderware/AVEVA, FactoryTalk, Citect) se basó en cuatro criterios:
- Arquitectura abierta: licenciamiento por servidor, no por tag — elimina vendor lock-in por puntos de datos
- Soporte nativo OPC-UA: conexión directa a todos los PLCs sin middleware adicional
- Preparación nativa para MQTT/Sparkplug B: el módulo MQTT Engine permite publicar al UNS broker sin reconfiguración
- Escalabilidad: el coste no crece linealmente con el tamaño de la instalación
Configuración del servidor: redundante activo/pasivo en hardware industrial en DMZ industrial segmentada; historian con resolución de 1 segundo; módulo batch conforme al modelo ISA-88 de Fase 1; gestión de alarmas conforme a ISA-18.2.
Red OT: segmentación y ciberseguridad (NIS2 / IEC 62443)
- Segmentación en VLANs por área de proceso, con reglas de firewall explícitas
- Firewall industrial entre red OT y red IT corporativa, con inspección profunda de paquetes industriales
- DMZ industrial donde reside el servidor SCADA
- VPN industrial con autenticación multifactor para acceso remoto
Integración SCADA ↔ MES conforme a ISA-95
- MES → SCADA: órdenes de producción en formato B2MML (receta, lote, materiales, parámetros)
- SCADA → MES: Batch Record electrónico (eBR) completo automático al finalizar cada lote
8. Fase 3: Shadowmode — 10 semanas de operación en paralelo
Esta es la fase más crítica del proyecto y la más frecuentemente subestimada. El shadowmode consiste en operar el nuevo SCADA en paralelo con el sistema actual durante 10 semanas completas, sin que el nuevo sistema tenga ningún control efectivo sobre los equipos. La planta produce con normalidad. El SCADA observa, registra y compara.
Por qué el shadowmode no es opcional
En este proyecto, el shadowmode detectó y resolvió antes del cutover:
| Categoría | Incidencias |
|---|---|
| Errores de configuración de tags | 34 |
| Desviaciones de sensor que requerían recalibración | 12 |
| Recetas con parámetros inconsistentes modelo ISA-88 vs. PLC | 8 |
| Total incidencias resueltas antes del cutover | 54 |
Sin el shadowmode, cada una de estas 54 incidencias se habría manifestado en producción real, generando como mínimo una desviación GMP.
Estructura de las 10 semanas
| Semanas | Actividad principal |
|---|---|
| 1-2 | Conexión de PLCs al SCADA. Validación de adquisición de datos (IQ): verificación de que cada tag se adquiere correctamente con unidades de ingeniería, límites y resolución correctos |
| 3-4 | Validación de recetas en shadow. Comparativa sistemática entre el eBR generado por el SCADA y el registro manual en papel, fase por fase, para cada producto |
| 5-6 | Pruebas de alarmas, interlocks de seguridad y gestión de excepciones (OQ parcial). Verificación de que cada condición de alarma activa la respuesta correcta |
| 7-8 | Formación intensiva del equipo de operaciones y calidad. Simulaciones de lote completo con presencia de operarios de turno. El equipo de calidad revisa y valida los primeros eBRs |
| 9 | Auditoría interna shadow: revisión completa y formal del eBR generado vs. registro en papel para una muestra representativa de lotes. Cierre formal de todas las incidencias |
| 10 | Preparación del cutover: checklist go/no-go, plan de contingencia documentado, ensayo general del procedimiento, revisión final con directora de operaciones y responsable de calidad |
9. Fase 4: Cutover — La única parada del proyecto (72 horas planificadas)
Al finalizar el shadowmode con el criterio de go/no-go superado y firmado, se ejecutó el cutover durante una parada programada de 72 horas, coordinada con los cuatro laboratorios clientes con semanas de antelación.
Plan de cutover hora por hora
- Viernes 18:00 — Inicio de parada: finalización del último lote, backup completo de todos los sistemas, reunión de arranque con el equipo técnico completo, verificación del plan de contingencia (rollback en menos de 4 horas si fuera necesario)
- Viernes 20:00 — Sábado 14:00 (18 h): activación del control SCADA sobre todos los PLCs, pruebas end-to-end en cada línea, validación PQ con lotes de prueba, primer eBR generado y validado por calidad, verificación de la integración SCADA ↔ MES
- Sábado 14:00 — Domingo 18:00 (28 h): producción real supervisada con presencia continua del consultor independiente y soporte técnico, monitorización intensiva comparada con históricos del shadowmode
- Domingo 18:00 — Lunes 06:00 (12 h): turno de noche supervisado, cierre de lotes con eBR validados, confirmación de go-live definitivo firmado por directora de operaciones, responsable de calidad y consultor independiente
- Lunes 06:00 — Producción normal con el nuevo sistema activo
10. Fase 5: Arquitectura preparada para UNS/MQTT/Sparkplug B
La decisión de diseñar la nomenclatura de tags conforme a ISA-88/ISA-95 desde el primer día no fue un capricho técnico: fue una decisión estratégica con implicaciones económicas directas.
El Unified Namespace (UNS) es la arquitectura que permite que cualquier sistema — SCADA, MES, ERP, Business Intelligence, Inteligencia Artificial — acceda a cualquier dato de planta de forma estandarizada, contextualizada y en tiempo real, sin integraciones punto a punto. MQTT/Sparkplug B es el protocolo que hace posible ese UNS en entornos industriales con requisitos GxP.
¿Por qué prepararse ahora si el UNS no se implementa todavía? Porque cambiar la arquitectura de tags una vez el sistema está en producción en un entorno GMP implica revalidación completa. Si la nomenclatura sigue desde el primer tag la estructura ISA-88/ISA-95, cuando llegue el momento del UNS broker, la migración es configuración, no rediseño.
Arquitectura UNS/MQTT/Sparkplug B prevista
El dato contextualizado como activo estratégico
Cada tag publicado en el UNS lleva contexto completo. La diferencia entre un dato contextualizado y uno sin contexto:
El segundo dato puede ser consumido, analizado y auditado por cualquier sistema, cualquier inspector y cualquier modelo de IA sin intermediación humana. Es el cimiento que la Inteligencia Artificial necesita para funcionar de forma conforme al Anexo 22 de la EMA.
11. Resultados a los primeros 6 meses
El sistema lleva activo desde finales de 2025. Los datos que siguen corresponden a los primeros 6 meses de operación real.
| KPI | Situación inicial | Primeros 6 meses | Mejora |
|---|---|---|---|
| Tiempo de cambio de producto | 4h 20min | 1h 45min | -60% |
| Errores de transcripción de receta | 8/mes | 0/mes | -100% |
| Trazabilidad completa por lote (eBR) | 65% | 99,4% | +34 puntos |
| Paradas no planificadas | 52 min/día | 13 min/día | -75% |
| Tiempo directora OPS en incidencias | 38% | 11% | -27 puntos |
| Auditorías internas sin observaciones | 0-1 / 6 m | 2 / 6 m | ×2 en 6 m |
| Coste acumulado ineficiencias | ~115.000 € | ~26.000 € | -78% |
| Observaciones AEMPS en inspección | 3 (2 mayores) | 0 | -100% |
| Vendor lock-in con integrador original | Total | Eliminado | ✓ |
| Costes acumulados a 6 meses. Ratios diarios/mensuales constantes desde la activación. ROI proyectado en menos de 14 meses basándose en datos del primer semestre. | |||
12. Cuatro lecciones que no encontrarás en ninguna norma
Desde el Quick Scan hasta el último día del shadowmode, la planta produjo con total normalidad. La única parada fue el cutover: 72 horas planificadas y controladas. No existe ninguna razón técnica ni metodológica para parar la producción durante el modelado, la instalación o las pruebas en paralelo. Si alguien te dice que necesita parar la planta para hacer el modelado ISA-88 o instalar el SCADA, estás ante una falta de metodología, no ante una necesidad técnica.
Cada año sin modernización no es un año neutral: es un año en que el coste de actuar aumenta, la distancia con los estándares vigentes se amplía y el riesgo regulatorio se acumula. El ratio 4:1 — cuatro euros de coste forzoso por cada euro de modernización diferida — es una realidad documentada en el sector europeo. La pregunta no es si modernizar, sino cuándo.
Las 10 semanas de operación en paralelo detectaron 54 incidencias antes de que afectaran a un solo lote real. El cutover fue tranquilo precisamente porque el shadowmode fue riguroso. La tranquilidad del cutover no es coincidencia: es el resultado directo de las semanas anteriores. Acortar el shadowmode para «ir más rápido» es el error más caro que puede cometer un proyecto de este tipo.
El integrador construye. El consultor independiente audita, supervisa y valida. Confundir estos dos roles es el error más frecuente y más costoso en proyectos GMP. La independencia del consultor no es un lujo: es la garantía de que el sistema cumple lo que dice cumplir, ante el cliente, ante los laboratorios y ante el regulador. El retorno económico de esa independencia se midió en este proyecto en cero observaciones en la primera inspección post-implementación.
Este caso se completó a finales de 2025. El nombre de la empresa se omite por acuerdo de confidencialidad. Todos los datos técnicos y económicos son reales y han sido validados con la dirección de la empresa.
Si reconoces en este caso la situación de tu planta, el primer paso es siempre el mismo: una fotografía objetiva de la realidad, sin compromiso con ninguna solución y sin conflicto de interés con ningún proveedor.
Para eso está el Quick Scan.
© 2026 Pablo Vázquez · Batchwise Consulting S.L. Reproducción permitida con atribución expresa al autor y enlace al artículo original en pablovazquez.tech.
