SUMI Agendar demo

Lecturas

¿Cómo tomar lecturas donde el cliente no te deja instalar nada en su red?

·8 min de lectura

Todo distribuidor de impresión administrada tiene un porcentaje de su parque que el monitoreo remoto no alcanza. No es un caso raro: es una parte estable del negocio, y merece un procedimiento en vez de una excepción mensual.

Por qué hay equipos que no se pueden monitorear

Conviene empezar por aceptar que las razones del cliente suelen ser buenas:

  • Política de seguridad que prohíbe software de terceros en la red corporativa.
  • Red segmentada: las impresoras viven en un segmento sin salida a internet, a propósito.
  • Un área de sistemas con su propio proceso, que no autoriza instalaciones sin pasar por él.
  • La decisión se toma en otra ciudad, en un corporativo que no tiene contacto contigo.
  • Equipos sueltos en sitios sin red, o conectados por USB a una sola computadora.

Ninguna se va a mover porque insistas. Lo que sí está en tus manos es que esos equipos no dejen de facturarse bien.

Las vías que quedan

VíaCuándo aplicaQué cuesta
El equipo se reporta solo Si su firmware puede enviar el contador sin software extra Configurarlo una vez, con permiso del área de sistemas
Captura en campo Siempre: el técnico ya va al sitio Disciplina y una forma de no equivocarse de equipo
Carga por lote Cuando el cliente o su sistemas exporta un archivo Acordar el formato una vez y validarlo al cargar
Recepción desde la plataforma del cliente Cuando el cliente ya monitorea con su propia herramienta Que su plataforma pueda enviar datos; la cuenta es de él

La cuarta vía es la más desaprovechada y suele ser la mejor: si el cliente ya tiene una plataforma de monitoreo, los datos ya existen. Nadie tiene que instalar nada nuevo — sólo hay que dejar que esa plataforma los mande. Y como la cuenta es del cliente, el permiso también es suyo, que es justo lo que su política de seguridad quería proteger.

La trampa: estimar la página faltante

Cuando falta la lectura de un equipo, la salida rápida es estimarla con el promedio de los meses anteriores. Funciona una vez. El problema aparece después:

  1. La estimación se factura y queda registrada como si fuera una lectura real. Nadie que abra el expediente seis meses después va a distinguirlas.
  2. Llega la lectura verdadera y no coincide con la estimada. El consumo del periodo siguiente sale deformado: si estimaste de más, sale negativo; si estimaste de menos, sale inflado.
  3. El error se arrastra. Cada periodo parte del anterior, así que un arranque equivocado ensucia toda la cadena hacia adelante hasta que alguien la corrige a mano.

Si hay que estimar —a veces el cliente lo acuerda así—, la regla mínima es que la estimación quede marcada como estimación y se regularice contra la lectura real en cuanto aparezca. Un dato inventado que se ve igual que uno medido es peor que un hueco declarado.

El control que de verdad hace falta

Aquí hay un detalle que se pasa por alto y cuesta caro: un equipo que deja de reportar no genera ningún registro. No hay error, no hay alerta, no hay línea en ninguna bitácora. Simplemente deja de aparecer.

Por eso el control útil no es «avísame si llega un dato raro» —eso vigila lo que sí llegó—, sino «dime qué equipos llevan más de X días sin reportar». Es la única forma de que el silencio se note.

La consecuencia práctica: ese reporte hay que mirarlo antes del corte, no durante el cierre. Un equipo detectado tres días antes se resuelve con una llamada; detectado el día de facturar, se resuelve estimando.

Mezclar fuentes: se puede, con dos reglas

Un parque real termina con lecturas entrando por varias vías a la vez, y eso está bien. Sólo pide dos cosas:

  • Que cada lectura guarde de dónde vino y cuándo. Sin eso, el día que un número se discuta con un cliente no hay forma de defenderlo.
  • Que haya una regla explícita de cuál gana cuando dos fuentes reportan el mismo equipo. Si no la escribes, la regla de facto es «gana la última que entró», y la última no siempre es la correcta: una captura manual tecleada el martes puede pisar la lectura automática del miércoles.

Preguntas frecuentes

¿Qué se hace cuando el cliente no deja instalar un agente de monitoreo en su red?

Quedan cuatro vías: que el propio equipo envíe su contador si su firmware lo permite, que el técnico capture la lectura en sitio, cargar por lote el archivo que el cliente o su área de sistemas exporta, y recibir los datos desde la plataforma de monitoreo que el cliente ya tenga. Lo importante es registrar por cuál entró cada lectura.

¿Por qué un cliente se niega a instalar un agente?

Casi nunca es capricho. Las razones habituales son política de seguridad corporativa que prohíbe software de terceros, una red segmentada donde las impresoras no tienen salida a internet, un área de sistemas que no autoriza instalaciones sin su propio proceso, o un corporativo que decide desde otra ciudad. Son razones legítimas y no se van a mover porque insistas.

¿Se puede estimar la lectura de un equipo que no reportó?

Se puede, y es la peor opción. Una estimación se convierte en un número facturado que nadie distingue de una lectura real, y cuando llega la lectura verdadera el siguiente periodo sale descuadrado. Si hay que estimar por acuerdo con el cliente, la estimación debe quedar marcada como tal y regularizarse contra la lectura real.

¿Qué pasa si un equipo deja de reportar a mitad del periodo?

Lo primero es que alguien se entere, y eso es más difícil de lo que parece: un equipo que deja de mandar datos no genera ningún registro, simplemente desaparece del reporte. Por eso el control útil no es «avísame si llega algo raro», sino «avísame qué equipos llevan más de X días sin reportar».

¿Conviene mezclar varias fuentes de lectura?

Sí, es lo normal en un parque real, y por eso cada lectura debe guardar de dónde vino y cuándo. Cuando dos fuentes reportan el mismo equipo hace falta una regla explícita de cuál gana; si no la hay, gana la última que entró, que no siempre es la correcta.

Esto es lo que SUMI hace todos los días.

En una demo de 30 minutos lo vemos con tu operación: tus contratos, tus lecturas y tu cierre de mes.

Seguir leyendo

¿Por qué dejaron de llegar las lecturas? Cuando el cliente apaga SNMP v1 y v2 por seguridad El área de sistemas de tu cliente desactiva SNMP v1 y v2c por una razón buena, no te avisa porque para ellos es una tarea de seguridad, y tú te enteras el día del corte. No deja de imprimir: deja de cobrarse. Qué pedirles y qué hacer con los equipos que no soportan v3. ¿Se puede cambiar de ERP sin perder el histórico de lecturas? Sí, y el histórico es lo primero que hay que mover, no lo último: una lectura sola no significa nada, sólo vale contra la anterior. En qué orden migra cada cosa y qué no se puede recuperar después. ¿Qué cuesta de verdad un contrato MPS? Cómo calcular la rentabilidad por equipo Los seis componentes del costo real de atender una máquina, los tres errores que hacen que el margen se vea mejor de lo que es, y por qué el estado de resultados nunca te va a decir qué equipo pierde dinero.