Rentas: los expedientes confirman que la puesta en marcha del Gen Nómade fracasó

Investigación Ecos Mendocinos

SAGA GEN NÓMADE | NOTA 2 DE 3 Por Néstor Bethencourt

Filas, demoras y malestar vecinal fueron apenas la parte visible del problema. La documentación interna revela módulos sin migrar, planes de pago inutilizables, saldos erróneos y una base de datos que el municipio no controlaba del todo.

Esta es la segunda entrega de la saga sobre el sistema informático Gen Nómade en Guaymallén. En la primera, Ecos Mendocinos mostró cómo Calvente presentó como novedad un sistema que ya venía contratado y pagado desde mediados de 2025.

En enero, el caos en Rentas parecía una postal de temporada. Vecinos esperando, atención mínima, trámites frenados y un sistema que no respondía como prometían. Pero los expedientes muestran que aquello no fue un mal debut ni una transición incómoda. Fue algo más serio: una puesta en marcha fallida.

Lo que en la calle se veía como demora, adentro aparecía escrito con otra crudeza. La propia Dirección de Rentas dejó asentado que, desde el 5 de enero de 2026, comenzó a trabajar con el nuevo sistema, pero que los resultados “no fueron los esperados”. Y esa frase, leída junto con el resto del expediente, funciona casi como una puerta de entrada a un problema mucho más profundo.

Porque el sistema informático Gen Nómade no llegó a Rentas con todo listo. Llegó con tareas en proceso, con piezas todavía en desarrollo y con una promesa ya incumplida: la de estar operativo al 100% el 2 de enero de 2026. La propia empresa reconoció después que no pudo cumplir ese compromiso inicial. O sea: el sistema arrancó tarde, arrancó mal y arrancó sin la solidez que se había prometido.

Ahí aparece la primera clave de esta segunda entrega. Lo de Rentas no fue un accidente aislado. Fue el lugar donde el expediente dejó más a la vista que la modernización venía mal armada. Si la nota anterior mostró la distancia entre el discurso de Calvente y la cronología interna, ésta muestra otra cosa: por qué el golpe más visible se sintió en Rentas y por qué no podía salir bien así como llegó.

Módulos que faltaban y un sistema que no terminaba de llegar

La auditoría interna no deja demasiado margen para el maquillaje. En esa actuación se informó que Padrones, Comercio y Defunciones no se migraron en su totalidad. Y todavía más fuerte: los módulos de Apremios, Deudores Varios y Tránsito nunca fueron migrados. Es decir, partes esenciales del funcionamiento de Rentas directamente no estaban donde tenían que estar.

La cosa no termina ahí. También se dejó asentado que la función de planes de pago no pudo ser utilizada y que la cuenta corriente migrada arrojó saldos incorrectos en su totalidad. Eso pega justo en el corazón del área. Porque Rentas no vive de slogans de modernización. Vive de liquidaciones, deuda, pagos, boletas y regularización de contribuyentes. Si ahí falla el sistema, no falla un detalle: falla el vínculo entre el municipio y quien tiene que pagarle.

En paralelo a estas dificultades operativas, aparece un elemento relevante desde el punto de vista administrativo. La implementación del sistema fue impulsada desde la Dirección de Innovación y Atención al Vecino, área que luego intervino en la validación de su funcionamiento en etapas posteriores. El director a cargo, Pablo Raddi, participó tanto en la instancia técnica previa como en la certificación de las prestaciones, en un esquema donde la misma estructura administrativa concentró funciones clave en el proceso.

Los propios expedientes del segundo semestre de 2025 ayudan a entender por qué pasó esto. Mientras se emitían conformidades y pagos, seguían figurando trabajos sobre migración de deuda de ejercicios anteriores, análisis de estructura de tablas de Infogov, planes de pago, cuenta corriente y otras tareas críticas todavía en proceso. En otras palabras, el sistema se empujó hacia enero sin que varios componentes sensibles estuvieran plenamente resueltos.

Eso explica por qué el vecino vio desorden. Porque antes hubo una implementación a medio armar.

Rentas quiso migrar, pero el municipio no tenía el mapa completo de sus propios datos

Acá está uno de los puntos más graves de toda la saga. En los expedientes vinculados a Rentas, el propio municipio reconoció que no disponía del detalle de las relaciones entre bases de datos, que no contaba con la documentación técnica interna del diseño de Infogov y que tampoco tenía el diccionario de datos del sistema anterior. Dicho de forma simple: Guaymallén quiso mudar una parte crítica de su información sin tener plenamente bajo control el plano técnico de su propia casa.

La empresa, lejos de esquivar ese punto, también lo usó como explicación. En su diagnóstico dijo que faltaban definiciones, coordinación, documentación estructural y condiciones objetivas para una migración segura. Eso no absuelve a Nómade. Pero sí deja planteado algo peor para el municipio: que el problema no era sólo el software nuevo, sino el escaso dominio interno sobre la arquitectura de los datos viejos.

Y acá aparece la dimensión política real del desastre. Porque cuando una administración pierde control sobre el diccionario de sus datos, no pierde sólo comodidad. Pierde autonomía. Empieza a depender de terceros para entender, reconstruir o validar su propia información. Y si eso pasa en Rentas, el problema ya no es técnico. Es de poder.

Más de 4.000 personas mal cargadas y 555.878 cuentas sin número de boleto

El expediente no sólo habla de falta de documentación. También habla de inconsistencias concretas. La empresa informó que existían más de 4.000 personas cargadas de forma diferente, muchas veces por errores o variaciones en el dígito verificador del CUIT. Eso implicaba aplicar criterios no estandarizados y resolver casos con lógica artesanal, justamente en un proceso que se suponía diseñado para ordenar y automatizar.

Pero el dato más brutal es otro. En el análisis de las tablas se detectaron 555.878 cuentas corrientes sin número de boleto asociado. Eso significa, en términos simples, que una parte gigantesca de la base no estaba pudiendo vincular correctamente deuda y pago. Y al lado de esa cifra aparecieron otros problemas igual de inquietantes: boletos sin relación clara, facilidades de pago en cero y lógicas de búsqueda rotas dentro de los planes de pago.

Eso ya no se parece a una dificultad de adaptación. Se parece más bien a una base herida, trasladada sin garantías suficientes de consistencia y después empujada a producción como si bastara con cruzar los dedos.

El pasado también quedó recortado

Hay otro detalle que ayuda a medir la magnitud del problema. Durante el análisis inicial, no aparecían boletos ni pagos anteriores a 2018. Después se informó que existía otra base con información más antigua, vinculada a migraciones del sistema Civitas. O sea: la historia completa no estaba clara ni disponible desde el arranque del trabajo.

Ese punto no es un tecnicismo más. En Rentas, el pasado importa. Importa para seguir deuda, entender pagos, reconstruir movimientos y hasta discutir prescripción. Si la historia queda cortada, la trazabilidad también se corta. Y cuando la trazabilidad se rompe, el sistema ya no sólo falla hacia adelante. También empieza a oscurecer hacia atrás.

La empresa terminó pidiendo suspender

La escena final de este capítulo también quedó escrita. En su informe de enero, Nómade concluyó que correspondía suspender la implementación de geN Rentas. Dijo que no estaban dadas las condiciones organizacionales, técnicas y operativas mínimas para garantizar una finalización correcta y segura del proceso. La frase importa porque blanquea algo que en la calle ya se notaba: el sistema no estaba en condiciones de sostenerse como si nada pasara.

Visto así, el caos de enero deja de parecer una anécdota. Lo que el vecino sufrió en la ventanilla aparece ahora como la consecuencia visible de una migración incompleta, una base inestable y una implementación que quiso correr más rápido de lo que su propia estructura permitía.

La crisis en Rentas no fue un episodio menor ni un simple desajuste de verano. Fue el punto donde quedaron al desnudo las grietas de una implementación apurada, una migración incompleta y un municipio que quiso modernizarse sin tener plenamente bajo control la memoria técnica de sus propios datos.

En la tercera entrega, la historia sale de Rentas y se mete en zonas todavía más sensibles: Tesorería, Contaduría, Patrimonio y pagos. Porque el sistema informático Gen Nómade no sólo complicó la atención al vecino. También empezó a dejar huella en fondos, balances y bienes públicos.

Esta saga empezó acá

En la primera entrega, Ecos Mendocinos mostró cómo Marcos Calvente presentó como novedad un sistema que Guaymallén ya había adjudicado, pagado y empujado desde 2025.

Leé la primera nota:
Calvente presentó como novedad un sistema que Guaymallén ya pagaba desde 2025

Antecedentes publicados

El caos visible en Rentas ya había sido advertido en enero por Ecos Mendocinos, cuando todavía no se conocía la dimensión completa del problema interno.

Leé también:

Modernización o viveza por duplicado en Guaymallén. Raddi no la vio
Caos en Rentas Guaymallén: UTMs, filas y mantenimiento
En Rentas Guaymallén volvieron al sistema viejo

Lo que sigue

En la tercera entrega, la historia sale de Rentas y entra en zonas todavía más sensibles: Tesorería, Contaduría, Patrimonio y el reclamo del proveedor por falta de pago.

Aclaración documental:
Ecos Mendocinos conserva copia de los expedientes, notas internas y actuaciones citadas en esta investigación.

Detrás de cada expediente hay una decisión de poder. Y detrás de cada nota hay horas de trabajo independiente. Si quiere apoyar a Ecos Mendocinos, puede colaborar y compartir esta investigación.