Muchos proyectos de software a medida en las fábricas no mueren por la codificación, sino por «requerimientos poco claros, alcance que cambia constantemente y nadie reconoce el sistema una vez puesto en producción». El departamento de ventas dice que quiere un seguimiento del progreso de las operaciones; el taller solicita la posibilidad de reasignar tareas; el área financiera exige alineación con los costos de las órdenes de trabajo; y el equipo de TI señala que aún no se ha congelado la lista de interfaces. Tres meses después de la puesta en marcha, en el taller siguen enviando fotos por WeChat y registrando el avance mediante Excel. Lo que realmente falta no es una lista de funciones, sino un camino ejecutable que abarque desde la congelación del alcance en , pasando por el diseño de la solución y su implementación hasta la fase de aceptación cerrada .
Problema empresarial: ¿por qué, aunque «esté terminado», no se utiliza?
Un dolor de cabeza común en la manufactura discreta es: se emite una orden de trabajo, pero no se ve el progreso de las operaciones; el jefe de turno reasigna tareas verbalmente, mientras el sistema sigue estancado en la etapa anterior; y cuando la inspección de calidad detecta un defecto, el cierre se realiza en papel, sin que coincidan los cálculos de costos. Los directivos compran software para visualizar el WIP (trabajo en proceso) real, pero si el proveedor factura según una «lista de módulos», incluirá en una sola fase el tablero de control, el registro de trabajos, el inventario y los costos, lo que hace que el alcance se expanda hasta el punto de resultar imposible de aceptar.
Otro tipo de fracaso ocurre cuando se toma el acta de la entrevista como especificación de requisitos . En el acta se anota «debe permitir ver el progreso», pero no se aclara cuál es el criterio para medir dicho progreso, cómo se registra el retrabajo ni quién tiene autoridad para reasignar tareas entre equipos. El desarrollo, tomando literalmente esa indicación, crea una página de listas, pero en el sitio real el sistema se traba en cuanto se intenta usar. Lo que el software puede resolver es convertir estas reglas en máquinas de estado y permisos ejecutables; lo que no puede solucionar es que, organizativamente, nadie esté dispuesto a congelar esas normas.
Existe también un costo oculto: mantener durante demasiado tiempo dos sistemas paralelos. Mientras el antiguo Excel sigue funcionando y el nuevo sistema aún no está completo, el personal opta por la vía más fácil, lo que deja los datos del sistema cada vez más desordenados y, finalmente, se concluye que «el sistema no funciona bien». Puede haber doble vía, pero es indispensable establecer claramente la fecha de desuso de los formularios antiguos y las reglas de conciliación; de lo contrario, la puesta en marcha solo significará añadir otra capa de presentación.
- Alcance poco claro: los objetivos de la primera fase se mezclan hasta convertirse en «toda la digitalización».
- Fallo en la recopilación de datos: el progreso sigue dependiendo de informes verbales, y el sistema apenas sirve como capa de visualización.
- Desfase en la aceptación: se verifica según el menú, pero no según los resultados reales del negocio.
- Doble vía fuera de control: los formularios antiguos siguen activos, mientras los nuevos carecen de propietario.
Cómo dividir el negocio: primero asegurar resultados verificables en la primera fase
Se recomienda fijar la primera fase en un resultado medible, por ejemplo: «el retraso en el registro de trabajos de las operaciones clave no superará los 30 minutos, y el planificador podrá comparar las órdenes de trabajo para identificar conjuntos completos y causas de bloqueos». El resto, como la optimización profunda del inventario, la distribución de costos y el panel de BI, se dejará para la segunda fase. La división del negocio puede seguir cuatro cadenas:
- Cadena de órdenes de trabajo : obtener las órdenes y definiciones de procesos del ERP/MES, y designar claramente a los responsables de los datos maestros.
- Cadena de registro de trabajos : quién escanea o selecciona en qué momento reporta la finalización, el retrabajo o la pausa.
- Cadena de anomalías : cómo gestionar la falta de materiales, la parada de equipos o la detención de calidad que bloquean a los siguientes procesos.
- Cadena de conciliación : cómo explicar las diferencias entre el avance registrado en el sistema y el inventario físico durante la liquidación diaria.
En cada cadena debe especificarse claramente los eventos desencadenantes, los roles responsables y los procedimientos de escalada ante retrasos . Si algo no se puede describir, significa que el negocio aún no está preparado para entrar al sistema; antes de iniciar el desarrollo, conviene realizar una preparación institucional, en lugar de avanzar directamente hacia la programación. La reunión de congelación del alcance debe formalizarse mediante un documento firmado: aquello que se incluya en la primera fase quedará registrado, mientras lo que no se incluya irá al pool de requerimientos; cualquier cambio deberá tramitarse mediante una solicitud de modificación y evaluarse en función del plazo estimado.
Cómo diseñar: roles, procesos y límites de datos
Durante la fase de diseño deben entregarse tres elementos, en lugar de un montón de bocetos: matriz de roles, máquina de estados e interfaz contractual. Los bocetos pueden completarse posteriormente, pero si faltan los tres primeros, cualquier interfaz será objeto de re-trabajo.
Roles y permisos
Es necesario distinguir al menos entre planificador, jefe de turno, operarios, inspectores de calidad, encargados de almacén y el personal directivo con acceso solo a lectura. Las reasignaciones y cancelaciones deben quedar registradas por dos personas; los operarios solo reportan desde su puesto; el planificador supervisa el bloqueo. Los permisos deben vincularse según «puesto + línea de producción», evitando cuentas universales. Las cuentas y las separaciones laborales deben integrarse en la lista de mantenimiento; de lo contrario, la deuda de permisos podría comprometer la confiabilidad de los datos.
Procesos y estados
Se recomienda simplificar los estados de las operaciones: pendiente de inicio, en proceso, pendiente de inspección, terminado, retrabajo y bloqueo. Los cambios de estado solo deben permitirse dentro de los límites legales; cualquier salto ilegal requiere justificarlo mediante un código específico. El tablero debe mostrar únicamente el resultado de la máquina de estados, prohibiéndose saltar directamente al cambio de estado sin pasar por el registro de trabajos. El retrabajo debe especificar claramente a qué operación regresa y si se genera una sub-orden, evitando que el progreso «parezca completado, pero en realidad retroceda».
Límites de datos y de interfaz
Los datos maestros (materiales, rutas de procesamiento, equipos) son mantenidos por el sistema fuente; los datos operativos (registro de trabajos, anomalías) se generan en el sistema del sitio. La interfaz debe adaptarse según el puesto: los operarios completan el registro con tres pulsaciones, el planificador revisa los bloqueos y los conjuntos completos, y la dirección observa la distribución de retrasos. No conviene trasladar todos los campos del ERP a la tablet del taller. Cuantos menos campos, más precisa será la recolección.
Cómo desarrollar e implementar: interfaces, recolección y aceptación
Se recomienda seguir este orden de desarrollo: sincronización de datos maestros → recolección de registros de trabajos → gestión de bloqueos por anomalías → consulta de alineación con las órdenes de trabajo → informe diario de conciliación. Las interfaces deben priorizar la idempotencia: para cambios en las órdenes de trabajo se usa un número de versión; para el registro de trabajos se emplea una clave única del negocio para evitar duplicados. El lado de recolección debe adaptarse a redes débiles: colas locales, reenvío y notificaciones de conflictos. El escaneo de dispositivos y la selección manual pueden coexistir, pero para cada instancia de operación solo debe existir un «evento autorizado de finalización».
Para las pruebas conjuntas es necesario preparar un «guion de datos sucios»: escaneos repetidos, interrupciones de red, cambios de proceso en medio de una orden de trabajo, reasignaciones entre turnos. Estos casos revelan las fallas de diseño mucho mejor que los casos ideales. En cuanto al rendimiento, las consultas del tablero deben dividirse por línea de producción, evitando escanear toda la planta en tiempo real.
La aceptación no debe basarse en marcar «puntos funcionales». En su lugar, utilice guiones de escenarios: emita una orden de trabajo real y complete todo el proceso de registro; provoque intencionalmente la falta de materiales para verificar el bloqueo en los niveles inferiores; tras una reasignación entre turnos, asegúrese de que el tablero coincida con la orden de trabajo; tome muestras de registros de trabajos y del inventario físico durante tres días, y verifique que la tasa de discrepancia esté por debajo del umbral acordado. Si no se alcanzan los estándares, no firme la aceptación final; solo firme la puesta en marcha condicional.
La entrega de documentación debe incluir: acta de congelación del alcance, explicación de la máquina de estados, lista de interfaces, matriz de permisos, registros de aceptación por escenarios, así como el plan de guardias de mantenimiento y los procedimientos de cambio. Sin estos documentos, el mantenimiento posterior se convertirá en una especie de arqueología verbal.
Conclusión: considere la entrega como «reglas ejecutables»
Desde los requerimientos hasta la puesta en producción, lo esencial no es acumular funciones, sino traducir las reglas implícitas del taller en lógica ejecutable y demostrar mediante la recolección y la aceptación que realmente están funcionando. Una sola cadena bien ejecutada vale más que diez menús incompletos. Si su fábrica está atrapada en el problema del progreso de las operaciones y la falta de alineación con las órdenes de trabajo, puede reducir el alcance de la primera fase siguiendo el camino descrito anteriormente y luego comenzar.
Shandong XYN Information Technology Co., Ltd. (XYN Tech) lleva años especializada en el desarrollo de software a medida para diversos sectores, desglosando el alcance, el diseño, la implementación y la aceptación en entregas concretas. Para obtener más información, visite Sobre nosotros.