Odoo 18 y PostgreSQL 17: la licencia fantasma del ERP
Un ERP abierto no se mide por el precio del servidor sino por las reglas que conserva. Odoo 18 y PostgreSQL 17 permiten salir del abono por usuario con cuidado.
La licencia fantasma del ERP aparece cuando nadie recuerda qué usuario la pidió, pero todos saben que se paga todos los meses. En una concesionaria sobre la Ruta 40, el jefe de compras mira una notebook Lenovo con una calcomanía de repuestos y encuentra doce accesos activos para gente que ya no aprueba órdenes. Odoo publica planes desde USD 31,10 por usuario al mes en modalidad estándar; multiplicado por áreas y años, el abono deja de ser detalle y empieza a dictar procesos.
La próxima factura va a cobrar la desorganización
Odoo 18 tiene documentación oficial para administración, desarrollo y operación, y su modelo ORM trabaja sobre PostgreSQL. PostgreSQL 17, por su parte, sumó mejoras en VACUUM, SQL/JSON y rendimiento de consultas, según sus notas de lanzamiento. La cifra que conviene mirar no es sólo el precio de la suscripción: en la encuesta 2024 de Stack Overflow, PostgreSQL fue usado por 48,7% de los desarrolladores y quedó como la base más popular por segundo año consecutivo.
La intuición gerencial dice que un ERP resuelve el desorden porque pone pantallas nuevas. La evidencia diaria dice que las pantallas nuevas sólo ordenan lo que alguien modeló bien. Si compras, stock, ventas y administración no comparten reglas de estado, el sistema termina replicando el pasillo: una orden aprobada en un módulo, pendiente en otro y discutida por WhatsApp.
La factura no castiga el software; castiga el permiso mal pensado.
La pregunta incómoda para una pyme mendocina no es si Odoo sirve. La pregunta es qué parte del negocio merece código propio, qué parte puede vivir con módulos estándar y qué parte debe quedar fuera hasta que madure. La sección siguiente empieza donde suelen empezar los problemas: la solución obvia.
La nube comercial falla cuando compra calma
La respuesta evidente es pagar más usuarios, contratar el plan con más opciones o migrar todo a una nube cerrada con soporte. Puede funcionar, pero no corrige el síntoma central si la empresa no sabe quién crea productos, quién cambia precios, quién cierra inventario y quién puede reabrir una factura. El antagonista es el proveedor de licencias muertas: no rompe nada, sólo cobra por cada silla que el miedo deja encendida.
En la concesionaria, la escena social se entiende por objetos: café de estación de servicio en vaso térmico, llaveros de camioneta sobre el escritorio y una impresora láser que escupe remitos con la esquina doblada. Un dedo pasa por la lista de usuarios y se detiene en el nombre de un vendedor que renunció en enero. El sistema no mintió; la organización le enseñó a olvidar. Ahora viene la parte que sí se puede diseñar.
La salida abierta empieza por el modelo de datos
Una arquitectura razonable combina Odoo 18 Community o Enterprise según alcance, PostgreSQL 17 como base, backups diarios probados, un reverse proxy como Caddy o Nginx, monitoreo con Zabbix o Prometheus y un tablero separado para indicadores. Para una pyme de 12 usuarios internos, el plan estándar de Odoo Online ronda USD 373 mensuales antes de impuestos; a $1.415 por dólar, son unos ARS 528.000 al mes. Una instalación propia con soporte local puede bajar infraestructura a USD 80-180 mensuales, pero sube la responsabilidad técnica y exige horas de mantenimiento.
El tiempo realista para una primera etapa no es un fin de semana: 6 a 10 semanas si se incluyen relevamiento, migración mínima, perfiles, capacitación y un cierre de inventario asistido. La tentación de cargar todos los históricos desde 2012 debe resistirse. Primero se modelan productos, listas, permisos y flujos vivos; después se decide qué archivo viejo merece entrar. En trabajos de infraestructura y sistemas propios, UMSA suele separar el dato operativo del dato de archivo para que el pasado no trabe la operación nueva.
El nombre del fenómeno es licencia fantasma porque parece barata hasta que ocupa una silla vacía. La tecnología abierta no la elimina por magia; obliga a contarla. El capítulo que falta es el de los límites.
Antes de copiarlo, mirá las tres grietas
Primer riesgo: confundir abierto con gratis. El código puede no cobrar licencia, pero sí cobra criterio, backups y alguien que responda cuando cae el servidor. Segundo: subestimar localización fiscal. Facturación, retenciones, percepciones y reportes argentinos requieren revisión fina; un módulo mal adaptado puede salir más caro que un abono. Tercero: sobreadaptar. Cada campo pedido por un gerente puede convertirse en deuda técnica si no existe una regla de negocio estable.
La prueba mínima es dura: tomar diez compras, diez ventas y un ajuste de stock; pasarlos por el flujo propuesto; cerrar el día; restaurar un backup en otro servidor. Si el equipo no puede repetir esa secuencia sin llamar al implementador, todavía no compró independencia. Compró una promesa con contraseña.