Sabían cuántas horas dedicaban pero no cuánto ganaban con cada proyecto

Resumen del caso

M.U. es una empresa industrial aragonesa que fabrica, repara y modifica moldes de acero para inyección de plástico, sobre todo para automoción y alimentación.

Contaba con un ERP a medida, Trello, hojas de cálculo y capacidad técnica propia; Marenza ayudó a separar los problemas, priorizó dos frentes (gestión de personal y rentabilidad por proyecto) y dejó definido un modelo de rentabilidad para llevar a aplicación.

01

Qué necesitaba resolver la empresa

M.U. reparte su actividad en tres líneas. La fabricación completa de moldes está externalizada en torno a un 80 %, porque exige una maquinaria que no siempre compensa mantener. La empresa se concentra en el control técnico, las reparaciones y modificaciones en taller y la asistencia en las instalaciones del cliente, donde aporta más conocimiento y obtiene más rentabilidad.

Disponía de un ERP desarrollado a medida, Trello, hojas de cálculo, documentos y aplicaciones auxiliares, además de capacidad interna para programar soluciones propias. Había herramientas y datos de ejecución, pero parte de la información del presupuesto no se conservaba de forma estructurada, lo que impedía compararla con el trabajo realizado.

El equipo llegó con cuatro ideas de automatización: controlar los proyectos subcontratados, organizar vacaciones y ausencias, analizar la rentabilidad de los trabajos y medir la eficiencia de los empleados para establecer incentivos. Abordar cada una con una herramienta nueva podría haber generado aplicaciones satélite alrededor de un ERP que ya concentraba buena parte de la operativa. Como resumió el propio equipo, tenían los ingredientes, pero había que decidir qué construir.

02

Cómo se abordó

Se revisó la operativa y se priorizaron dos frentes de trabajo: la gestión de personal y la rentabilidad por proyecto. El proceso se desarrolló en cuatro pasos:

Priorizar con tres criterios

Se revisó cómo se gestionaban los proyectos, los fichajes, los costes, las vacaciones y la comunicación con proveedores. Cada propuesta se valoró por su impacto, su dificultad técnica y su probabilidad de adopción.

El seguimiento de proyectos subcontratados, por ejemplo, se planteó al principio con una plataforma para proveedores. Se descartó obligarles a usar otro sistema y se diseñó una alternativa basada en los correos que ya enviaban. Era viable, pero se dejó detrás de necesidades con mayor impacto inmediato. El foco quedó en dos frentes: el portal de gestión de personal y el análisis de rentabilidad por proyecto.

Un portal del empleado para vacaciones, permisos y bajas

La gestión de ausencias había pasado de un calendario en la pared a una hoja de cálculo y después a Notion. El equipo interno comenzó a desarrollar una interfaz propia conectada con la base de datos, y durante el trabajo se fue revisando su estructura, el alojamiento de la información, los perfiles de acceso y el funcionamiento real.

La herramienta se organizó en tres vistas. Cada empleado consulta sus días disponibles y utilizados y envía solicitudes. Los responsables ven las próximas ausencias, la disponibilidad de sus equipos y las peticiones pendientes. Administración gestiona empleados, permisos y ajustes.

La rentabilidad como sistema medible

La segunda línea empezó como una herramienta para comparar horas presupuestadas y trabajadas y valorar la eficiencia de cada empleado. El análisis mostró que ese enfoque era insuficiente: un proyecto puede desviarse por una mala ejecución, pero también por un presupuesto incorrecto, materiales no contemplados o condiciones comerciales demasiado ajustadas.

Por eso el objetivo se amplió: medir la rentabilidad por proyecto y por cliente y localizar dónde se produce cada desviación. Se definieron los datos necesarios: horas previstas y reales, coste por empleado y por máquina, materiales directos, una estimación del consumo de almacén y el precio final facturado. También se planteó registrar en el ERP el desglose interno de horas presupuestadas sin mostrarlo al cliente.

Cambiar de enfoque cuando una herramienta bloquea

El equipo había conectado en Tableau las bases de datos de fichajes, pedidos y albaranes, pero no lograba construir la vista de rentabilidad. En lugar de seguir invirtiendo tiempo en una herramienta que frenaba el avance, se cambió el enfoque: construir primero la lógica del análisis en Excel, comprobar que los cálculos y comparaciones funcionan y trasladar después ese modelo a una aplicación con ayuda de inteligencia artificial.

Así el esfuerzo se concentra primero en definir bien el negocio y, solo después, en programarlo.

03

Resultados

El portal de personal quedó en funcionamiento. Para la rentabilidad, se definieron los datos y el modelo de análisis, junto con la ruta para validarlo en Excel y trasladarlo después a una aplicación.