Soluciones a Medida

Cuándo el software estándar deja de encajar

La mayoría de las necesidades de una empresa industrial se resuelven bien con software estándar. Contabilidad, nóminas, CRM: son procesos parecidos en casi cualquier sector, y los productos que los cubren llevan décadas madurando. El problema aparece en la capa operativa, donde cada planta es distinta. La secuencia de un tratamiento térmico, el control de calidad de una línea de envasado o la trazabilidad de un lote con reprocesos no se parecen entre fábricas, y ahí los productos genéricos empiezan a pedir peajes: campos que no existen, flujos forzados, hojas de cálculo paralelas para tapar los huecos.

Hay señales claras de que el estándar se ha quedado corto. La primera es la proliferación de Excel alrededor del sistema oficial: si el turno de noche apunta datos en una hoja porque el software no contempla su caso, el proceso real ya vive fuera del sistema. La segunda es la personalización excesiva de un producto cerrado, que sale cara de mantener y se rompe con cada actualización. La tercera es tener los datos capturados pero no poder explotarlos, porque el producto los guarda en un formato pensado para sus pantallas, no para tus preguntas.

El desarrollo de software industrial a medida no es la respuesta por defecto a estas señales, pero sí una opción que conviene evaluar con criterio en lugar de descartarla por miedo al mantenimiento o abrazarla por frustración con el proveedor actual.

Build vs buy: criterios para decidir sin dogmas

La decisión entre construir y comprar se toma mal cuando se plantea en abstracto. Bien planteada, es una comparación proceso a proceso. Estos son los criterios que usamos para ordenarla:

• Diferenciación del proceso. Si el proceso es igual que el de tu competencia, compra. Si es parte de lo que te hace competitivo, un producto genérico te obligará a operar como todos los demás.
• Coste total, no licencia. El estándar suma licencias, consultoría de implantación, personalizaciones y migraciones futuras. El a medida suma desarrollo, mantenimiento y evolución. La comparación honesta pone ambos costes a cinco años vista.
• Grado de encaje real. Una regla práctica: si el producto estándar cubre el proceso con configuración razonable, compra. Si necesitas modificar su código o rodearlo de hojas de cálculo, el encaje no existe y lo pagarás cada mes.
• Dependencia del proveedor. Con un producto cerrado, tu roadmap es el suyo. Con software propio, el ritmo de evolución lo marcas tú, a cambio de asumir la responsabilidad del mantenimiento.
• Alcance acotado. El a medida funciona cuando resuelve un problema concreto y delimitado. Replicar un ERP entero a medida es un error casi siempre.

En la práctica, la respuesta suele ser híbrida: sistemas estándar para lo genérico y desarrollos a medida para los huecos donde la operación real no cabe en ningún producto. Esa frontera se dibuja mejor tras un diagnóstico operacional que documente los procesos y sus datos antes de hablar de tecnología.

Construir sobre los datos de planta, no junto a ellos

Un software a medida que ignora los datos que la planta ya genera nace cojo. La materia prima está en los autómatas, en los registros de calidad, en el ERP y en los partes de producción. El diseño correcto empieza por inventariar esas fuentes: qué señales existen, con qué frecuencia se capturan, quién las mantiene y qué fiabilidad tienen.

Esto tiene consecuencias de arquitectura. La solución no debería crear su propio silo de datos, sino leer de las fuentes existentes a través de interfaces definidas: OPC UA o MQTT hacia el nivel de máquina, API o base de datos intermedia hacia el ERP. Cuando los sistemas de planta no se hablan entre sí, ese trabajo previo de conexión es un proyecto en sí mismo; lo tratamos en la solución de interoperabilidad industrial. Un ejemplo típico: un cuadro de seguimiento de OEE a medida solo aporta valor si las paradas se registran con causa y las velocidades de ciclo vienen de la máquina, no de una estimación. Si esos datos no existen todavía, el proyecto de software debe incluir cómo capturarlos, o el resultado será una pantalla bonita sobre números dudosos.

También conviene decidir pronto qué datos son de referencia y cuáles son copias. Cada duplicado sin dueño es una discrepancia futura entre lo que dice el sistema y lo que dice la planta.

Cómo se diseña una solución que no se convierta en legacy

El miedo más razonable ante un desarrollo a medida es heredar un sistema que nadie sabe tocar. Es un riesgo real, pero no inevitable: el legacy es consecuencia de decisiones de diseño, y esas decisiones se pueden tomar bien desde el principio.

Las que más pesan:

• Interfaces explícitas. La solución habla con el ERP, con la captura de planta y con los usuarios a través de contratos documentados. Si mañana cambia el ERP, se reescribe el conector, no el sistema.
• Dependencias aburridas. Tecnologías establecidas, con comunidad y ciclo de soporte largo, antes que el framework de moda. En un entorno industrial, un stack predecible vale más que uno brillante.
• Propiedad del código y del conocimiento. El código, la documentación y los accesos son del cliente. El traspaso de conocimiento a su equipo forma parte del proyecto, no es un extra al final.
• Alcance que cabe en una cabeza. Sistemas pequeños y componibles, cada uno con una responsabilidad clara, en lugar de una aplicación monolítica que crece hasta que nadie la entiende entera.
• Plan de vida, no solo de entrega. Desde el diseño se define quién mantiene, cómo se despliegan cambios y cada cuánto se revisan dependencias. Un sistema sin plan de mantenimiento es legacy con fecha programada.

Del problema al sistema en producción

Nuestro punto de partida nunca es la tecnología, sino la realidad específica de tu empresa, sector y operación. El trabajo arranca entendiendo el proceso sobre el terreno: quién hace qué, con qué datos y dónde duele. De ahí sale una definición de alcance honesta, que a veces concluye que la mejor solución es un producto estándar bien implantado, o que antes del software hay que resolver un problema de proceso; en ese caso el camino pasa por la mejora de procesos, no por el desarrollo.

Cuando el desarrollo a medida es la respuesta, el proyecto avanza por entregas cortas que se prueban en planta con usuarios reales. Un primer corte funcional temprano permite corregir el rumbo con feedback de quien lo va a usar en el turno, que es donde se detectan los supuestos equivocados. La entrega final incluye documentación, formación del equipo y un acuerdo claro sobre mantenimiento y evolución. El objetivo no es que dependas de nosotros, sino que el sistema siga siendo tuyo, comprensible y modificable, dentro de cinco años.

Si estás valorando por dónde empezar, el conjunto de servicios de consultoría industrial de Captia cubre desde el diagnóstico inicial hasta la implantación, y este servicio de soluciones a medida es la pieza que entra en juego cuando el análisis concluye que ningún producto del mercado encaja con tu operación.