ERP

Desarrollo full-stack · Backend · TFC de DAM Software empresarial TFC de DAM · En producción Spring Boot · React · Electron

Trabajo Fin de Ciclo: ERP a medida para digitalizar la operativa diaria de un taller de tapicería artesanal.

01 — Contexto

Un negocio real gestionado a mano

El taller gestionaba presupuestos, pedidos y materiales con Excel, papel y memoria. Cada encargo cambia según mueble, tela, relleno y horas de mano de obra.

Eso generaba errores en cotizaciones, poca trazabilidad y mucho tiempo en tareas administrativas repetitivas. El problema no era falta de software genérico, sino la lógica específica del negocio.

02 — Problema

Qué necesitaba el negocio

Cotizar bien Presupuestos con reglas variables según tipo de trabajo, materiales y tiempos.

Seguir pedidos Estados visibles para todo el taller y menos dependencia de la memoria del equipo.

Centralizar datos Clientes, telas y consumos asociados a cada proyecto en un solo sitio.

03 — Solución

Qué resuelve el ERP

Presupuestos Reglas según tipo de trabajo, materiales y tiempos. Menos cálculo manual y menos errores.

Producción Estados del encargo visibles para todo el taller. Saber en qué fase está cada trabajo.

Clientes Histórico de clientes, telas y consumos asociados a cada proyecto.

Uso diario No es un mockup: lo usa el negocio en su operativa real.

04 — Arquitectura

Cómo está montado

Backend

API REST con Spring Boot Entidades JPA: clientes, pedidos, materiales Lógica de negocio en capa de servicios PostgreSQL como persistencia

Frontend

React con vistas por área operativa Electron como app de escritorio Formularios para presupuestos y pedidos Consumo de API REST tipado

No muestro capturas inventadas del ERP. Las ilustraciones genéricas de arquitectura no representan la interfaz real, así que preferí no usarlas como si fueran pantallas del producto.

05 — Resultado

Impacto en el negocio

El ERP reduce errores en presupuestos, da trazabilidad a los pedidos y centraliza la información que antes estaba repartida entre Excel y papel. El criterio fue priorizar lo que el taller usa cada día frente a funcionalidades que solo lucen bien en un diagrama.

06 — Aprendizajes

Qué me llevé del proyecto

Pensar en dominio, no en CRUD

Modelar las reglas de un negocio real obliga a entender el dominio. Cada excepción del taller se convierte en una regla de software.

Priorizar lo que se usa cada día

Aprendí a dar prioridad a lo que el usuario usa a diario frente a funcionalidades que solo existen bien en un diagrama.

Backend con consecuencias reales

Un error en un presupuesto no es un bug de clase: afecta a un cliente y a la operativa del negocio. Eso cambia cómo diseño validaciones, modelos y flujos.

Volver a proyectos