ERP a medida para una productora de eventos

El reto

Una productora de eventos no es un negocio con un solo flujo de trabajo: son varias áreas técnicas operando en paralelo —sonido, iluminación, video, estructura, energía, transporte, producción— cada una con su inventario, su personal y sus tiempos, y todas obligadas a converger en el mismo evento.

Eso genera tres problemas que ninguna herramienta genérica resuelve bien:

• El inventario se dispersa. Cada área sabe qué tiene, pero nadie sabe qué salió hacia un evento concreto ni qué falta por volver.
• Asignar personal es planificación, no una lista. Cada persona asignada a un área de un evento genera una pauta, y esas pautas son las que después determinan la nómina. Si el calendario y la nómina viven separados, tarde o temprano dicen cosas distintas.
• Auditar al que audita. En una operación donde se mueve inventario caro y se calculan pagos, la pregunta incómoda no es quién vigila a los técnicos, sino quién vigila a administración.

Hay además una restricción de contexto que descarta media docena de soluciones de catálogo: esto opera en Venezuela. La conexión se cae. La luz se va. Un sistema que solo funciona en línea deja a un equipo parado en medio del montaje.

Del punto de partida solo queda una constancia escrita, y está en el código del propio actualizador: los instaladores se llevaban a mano a cada equipo, sin que nadie supiera con certeza quién tenía qué versión. Es un detalle pequeño que describe bien el momento — una operación creciendo más rápido que las herramientas que la sostenían.

La solución

Construimos un ERP interno completo: una API propia, una aplicación de escritorio para el trabajo diario y una aplicación móvil para el equipo en campo, organizado alrededor de las áreas técnicas y de tres roles transversales — Administración, Control de Eventos y Supervisión.

Lo que resuelve el sistema

• Inventario por área con entradas, salidas, ajustes y traslados. En la app móvil cada salida se ata a un evento del calendario, de modo que todas las áreas que participan quedan vinculadas a él.
• Calendario → pautas → nómina. Cada persona asignada genera una pauta; las pautas alimentan Control de Eventos, el ranking interno y el cálculo de nómina por tarifa. La hoja matriz y la nómina comparten el mismo cálculo a propósito, para que sea imposible que muestren cifras distintas del mismo mes.
• Bases de datos de clientes, personal y proveedores, con ficha, cargo, área y asistencia.
• Incidencias y sanciones por área, que llegan a Administración y generan reporte automáticamente.
• Repuestos y servicios para las áreas que mantienen equipo propio, cada una con su inventario e historial.
• Proveedores, deuda, licencias y vencimientos con aviso anticipado configurable.
• Presupuestos ligados a cliente y evento, que continúan hacia la facturación sin volver a teclear nada.
• Calendario de servicios, independiente del de pautas, para el trabajo que no encaja en un evento.
• Dashboard con el estado de la operación en una sola pantalla, mostrando a cada rol únicamente lo que le corresponde ver.
• Asistente de IA sobre los datos del sistema, con los mismos permisos por rol que el resto de la aplicación.

Las dos decisiones que sostienen todo lo demás

1. Supervisión vigila a Administración, y no ve dinero. El rol de supervisor no pertenece a ninguna área: ve la bitácora completa — incluido lo que hacen los administradores — y deliberadamente no accede a montos, nómina ni clientes. El comentario en el código lo dice sin rodeos: «un vigilante con acceso al dinero sería más riesgo, no menos». En el otro sentido, Administración no puede consultar esa bitácora: quien es auditado no decide qué se guarda.

2. La escritura sobrevive a los cortes. Si se va la conexión a mitad de una operación, lo pendiente se guarda y se reenvía solo al volver — y esa escritura no se ejecuta dos veces. Registrar por duplicado la salida de un equipo sería peor que no registrarla. Es la diferencia entre una aplicación pensada para una conexión real y una pensada para una demostración.

El resultado

El sistema está en uso diario. Cada área trabaja sobre el mismo calendario y el mismo inventario; la nómina y la hoja matriz salen del mismo cálculo, así que no pueden contradecirse; y una caída de conexión ya no detiene el trabajo en el sitio del evento.

Por acuerdo con el cliente no publicamos sus cifras de operación ni el detalle técnico del sistema. Son sus datos, no nuestro material de venta — y describir en abierto cómo está construido por dentro solo le facilita el trabajo a quien quiera atacarlo. Si estás evaluando algo parecido y necesitas ver el detalle para decidir, lo enseñamos en una llamada.

Que un caso de estudio no enseñe las tripas del sistema de un cliente debería ser lo normal. Si algún día trabajamos contigo, tus datos y tu arquitectura van a recibir exactamente el mismo trato.

Stack utilizado

A grandes rasgos, y sin entrar en versiones ni en topología de infraestructura:

• Backend propio en Python sobre base de datos relacional
• Aplicaciones nativas de escritorio y móvil desde una misma base de código
• Autenticación con control de acceso por rol aplicado en cada capa
• Asistente de IA conectado a los datos del sistema, con permisos por rol
• Infraestructura propia del cliente, sin licencias por usuario ni dependencia de plataformas de terceros