Cooperativa eléctrica con 65.000 socios: tres sistemas en uno
Un caso anonimizado de Cuyo: cómo se cambiaron tres sistemas heredados por un stack abierto en 9 meses. Lo que costó, lo que duró y lo que casi sale mal.
Eran las 6:14 de un lunes y Sebastián, gerente de sistemas de una cooperativa eléctrica del oeste argentino, recibió por tercera vez el mismo mensaje: el servidor de cobranzas no se hablaba con el de facturación. La consecuencia bajaba al mostrador en horas: socios con saldo cancelado pero marcados como deudores, intimaciones automáticas saliendo a clientes que ya habían pagado. La cooperativa atiende cerca de 65.000 socios, distribuye electricidad y opera además internet de banda ancha. La planilla de problemas se la pasó al directorio sin sorpresa. La sorpresa fue la propuesta que llevó como salida.
El escenario, en cifras de FACE y FEDECOBA
En Argentina hay alrededor de 600 cooperativas eléctricas que sirven a casi dos millones de usuarios y a una población cercana a ocho millones de habitantes, según FACE. FEDECOBA, la federación bonaerense, agrupa 143 cooperativas con 500.000 usuarios de electricidad y 145.000 de agua potable. El sector es enorme y, sobre todo, viejo: muchos sistemas de gestión administrativa siguen siendo los mismos que se compraron entre 1996 y 2008. SQL Server 2005, FoxPro, Clipper. Bases que sobrevivieron tres versiones de Windows Server y dos jefaturas de IT.
La cooperativa de Sebastián tenía tres sistemas separados — facturación, cobranzas y atención al socio — que conversaban por archivos planos exportados a la madrugada. Cuando uno fallaba el lunes, los otros dos arrancaban con datos del viernes. Es el problema clásico de cualquier organización con software propietario heredado: cada caja entiende solo su propio idioma, y los traductores nocturnos se rompen tarde.
Por qué "comprar el ERP grande" no era la salida
La consultora que primero llamaron propuso lo obvio: SAP Business One. Cotización: 220.000 USD de implementación, licencias por usuario, dos años de proyecto. Para una cooperativa donde el resultado del ejercicio se mide en margen sobre tarifa regulada por el ente provincial, esa cifra no se discutía: se descartaba en la primera reunión.
La segunda propuesta fue irse a un SaaS específico para cooperativas. Más barato en abono, pero con dos problemas serios: el padrón de socios — incluyendo los datos históricos de consumo desde 2003 — quedaba en servidores fuera del país y, peor, fuera del control de la asamblea. En cooperativismo eso es una línea roja. Los socios son dueños de sus datos, no usuarios de una plataforma. Una asamblea puede revocar un proveedor; no puede revocar un term-of-service que firmó IT sin avisar.
La salida con stack abierto
Lo que se armó tomó nueve meses y se construyó sobre cuatro piezas. La primera, PostgreSQL 17 como base única — todos los sistemas pasaron a leer y escribir en el mismo motor, sin exportaciones nocturnas. La segunda, Odoo 18 Community con módulos de la comunidad (OCA) para gestión administrativa, contable y de socios. La tercera, FreePBX y Asterisk para el conmutador del call center — reemplazando una central propietaria con licencias por extensión que costaban más que los sueldos de los operadores. La cuarta, n8n para los flujos entre el sistema de medición remota — telemetría de medidores — y la facturación.
Costo total del proyecto: alrededor de 38.000 USD en horas de integración. Costo operativo mensual: 420 USD entre VPS, dominio, certificados y backup en S3-compatible. La diferencia con SAP B1 no era marginal — era de orden de magnitud. Es el tipo de proyecto que en Ultima Milla preferimos hacer en etapas: primero la base única, después los flujos, recién al final la migración del telefónico. Cada etapa entrega valor antes de empezar la siguiente. Si el directorio cambia a mitad de proyecto — cosa que pasa en cooperativas con asambleas anuales — lo construido sigue funcionando.
Tres "sí, pero" antes de copiar este caso
Sí, pero esto requiere que la cooperativa tenga al menos un IT interno serio. Si el área de sistemas es una persona part-time que también arregla las impresoras, este proyecto la entierra en la primera semana. Hay que sumar a alguien con perfil de DBA o contratar un MSP con SLA mensual. Sin eso, la base única de Postgres se convierte en el cuello de botella único — y el riesgo concentrado en un solo punto es peor que el caos descentralizado anterior.
Sí, pero la localización fiscal y de servicios públicos no viene "lista". Hay que ajustar Odoo a las particularidades del cuadro tarifario que dicta cada ente provincial — EPRE en Mendoza, OCEBA en Buenos Aires, ERSEP en Córdoba, ENRE a nivel nacional. Eso suma entre 6 y 10 semanas al proyecto, y no se puede saltear. La buena noticia es que se hace una vez y queda como módulo reutilizable para otras cooperativas de la misma provincia.
Sí, pero el cambio de central telefónica es político además de técnico. Los empleados del call center estaban acostumbrados a una herramienta — y, sobre todo, los supervisores miraban un tablero específico para evaluar a los operadores. FreePBX permite reproducir todo eso, pero el cambio cultural es real y conviene capacitar antes de migrar, no después. La gente perdona errores técnicos; no perdona perder el control de su propio trabajo de un día para el otro.
El sistema corre desde hace siete meses. Las intimaciones cruzadas dejaron de salir el primer mes. El directorio cuestionó el costo del proyecto antes de aprobarlo y dejó de cuestionarlo el día que el ahorro mensual igualó la cuota del préstamo que se tomó para hacerlo. Sebastián, ahora, mira el tablero a las 6:14 de la mañana solo cuando suena la alarma. La mayoría de los lunes, no suena.