Software técnico, programas de cálculo y análisis avanzado de datos.

La situación. Una empresa proyecta por encargo componentes cuyo dimensionado exige comprobaciones normativas. Desde hace más de veinte años el trabajo pasa por un software de cálculo escrito en casa, sobre una plataforma de desarrollo que ya no tiene soporte, con formatos de archivo propietarios que nunca se documentaron. El programa funciona, pero nadie puede modificarlo con una seguridad razonable. Y las especificaciones no existen: las reglas viven dentro del código y en la experiencia de un solo proyectista.

Qué se ha hecho. Los requisitos no se han recopilado: se han reconstruido. El trabajo lee en paralelo tres fuentes — el código fuente, el archivo de los proyectos realmente ejecutados y las indicaciones de la oficina técnica — y las hace chocar entre sí: cada regla extraída del código se contrasta con los datos y se lleva al experto; cada indicación del experto se verifica en el código. Ninguna afirmación se acepta por confianza, ni la del experto ni la del código; lo que no es verificable se declara como tal, en lugar de quedar implícito.

Qué ha cambiado. La empresa ha dejado de depender de un saber que existía en un solo sitio. Lo que era tácito se ha convertido en un documento discutible y, junto con el mapa del sistema, ha salido la lista de las incongruencias que ya nadie tenía modo de ver, incluidas las divergencias entre lo que prescribe el manual y lo que ejecuta el programa.

La situación. Una organización recibe las peticiones por correo, en forma libre, escritas por personas distintas. Cada expediente exige datos precisos, algunos verificables solo cruzando varias informaciones, y produce documentos oficiales sobre modelos fijos. El tiempo cualificado se va en el transporte de los datos: releer, pedir el dato que falta, esperar, volver a copiar los mismos campos en varios documentos, reclamar a quien tiene que completar su parte. El cuello de botella no es la decisión: es el transporte.

Qué se ha hecho. Un asistente vigila la bandeja. Lee el mensaje, extrae los datos, los comprueba contra las condiciones de la organización y responde explicando en lenguaje corriente qué dato falta y en qué forma se necesita, en lugar de devolver un formulario vacío. Por encima trabaja un gestor que conoce el ciclo de vida del expediente: cuántas veces se ha pedido ya el mismo dato, si quien debe completar su parte ha respondido en los días previstos, si el solicitante ya tiene un expediente abierto. Tras un número declarado de intercambios infructuosos el expediente se congela, en lugar de alimentar un intercambio infinito.

Qué ha cambiado. Cuando el expediente está completo, los documentos oficiales salen ya rellenados sobre los modelos de la organización, con los campos poblados por los datos validados. El tiempo cualificado vuelve a la valoración de fondo, que es la única parte que de verdad pedía a una persona experta.

La situación. Cuando una empresa envía equipos a las instalaciones de los clientes, el plan semanal nace de decenas de restricciones que se estorban: direcciones dispersas en un territorio amplio, franjas horarias impuestas por los clientes, prioridades comerciales y plazos legales, duraciones que cambian con el tipo de prestación, equipos que no son intercambiables. Hecho a mano el plan sale siempre practicable pero nunca eficiente, y falta el término de comparación para darse cuenta.

Qué se ha hecho. El problema se formula como problema de ruta con ventanas temporales y se resuelve con un motor de optimización. Un primer nivel reparte las intervenciones entre los días, equilibrando la capacidad de los equipos y colocando primero las más onerosas. Un segundo resuelve cada jornada como ruta sobre varios vehículos, con los tiempos de recorrido reales tomados de un servicio viario y las ventanas horarias tratadas como restricciones que no se pueden violar.

Qué ha cambiado. El responsable recibe un plan listo para usar: rutas en el mapa, calendario diario por unidad, kilómetros, horas de conducción y saturación de los equipos. Y el mismo plan se regenera en pocos segundos cuando cambia una restricción, que es la parte que hace falta de inmediato, cuando alguien falla.

La situación. Reconocer a partir de una foto los artículos de un catálogo que cambia cada día sale caro si cada sede tiene que recoger y clasificar a mano las fotografías primero. Eso es lo que hace prohibitivos los plazos de activación de las soluciones tradicionales en este tipo de servicio.

Qué se ha hecho. El enfoque alternativo es describir el catálogo en lugar de mostrarlo. Las referencias del día se cargan en forma declarativa — nombre, categoría, descripción amplia, ingredientes, cantidades — y un modelo multimodal generalista reconoce a partir de esas descripciones, no de un archivo de imágenes etiquetadas. El sistema gestiona también las referencias compuestas, con coeficientes de ración, de modo que los valores sigan siendo correctos cuando en una misma elección conviven medias raciones de productos distintos.

Qué ha cambiado. Activar una sede nueva significa cargar su catálogo. No hace falta hardware dedicado: se usa el teléfono de la persona, sin tótems ni lectores. Y el coste escala con el tráfico, en lugar de ser el coste fijo de un puesto que hay que mantener también cuando pasan diez personas.

La situación. Quien responde de la formación obligatoria de decenas o cientos de personas mantiene el estado en hojas de cálculo que envejecen con cada contratación y con cada cambio de puesto. El riesgo no es teórico: es enterarse de un vencimiento superado durante una inspección, con lo que eso implica en materia de seguridad en el trabajo.

Qué se ha hecho. El problema no es calcular una fecha. Es tener juntos padrones, historial de cursos y reglas de periodicidad distintas por rol y por actividad, y calcular para cada persona y para cada obligación un estado entre cuatro: válido, a punto de caducar dentro del umbral, caducado, nunca realizado. De ahí salen la matriz formativa legible de un vistazo, los recordatorios en registro formal y el informe periódico.

Qué ha cambiado. Cuando la matriz existe, el trabajo pasa a ser programar los cursos en lugar de reconstruir el estado. Los datos personales permanecen en el servidor de la organización: ningún envío a servicios externos, obtenido como restricción de arquitectura y no como declaración de intenciones.