Qué relevar antes de pedir una cotización de CMMS

Llegan tres cotizaciones de CMMS y ninguna se puede poner al lado de la otra. Una contempla 12 usuarios y otra 40, porque un proveedor contó solo a los técnicos y el otro sumó a los operadores que reportan fallas. Una incluye la carga inicial de activos; la otra la deja como servicio aparte. La tercera asume una sola planta, aunque la segunda arranca el año que viene.

Ninguno de los tres proveedores se equivocó. Cotizaron lo que pudieron deducir de un correo de cuatro líneas.

Este artículo sirve para el momento en que la decisión de incorporar un sistema ya está tomada y todavía no se contactó a nadie. Si todavía estás definiendo qué tiene que resolver el software, el paso anterior son los criterios para evaluar un CMMS. Acá el foco es otro: qué información sobre tu propia operación tenés que tener cerrada para que todos los proveedores coticen el mismo alcance.

Son seis bloques: alcance, usuarios por perfil, volumen de trabajo, condiciones de campo e IT, estado de los datos, y plazos y decisión. Al final está el checklist para completarlos antes de mandar el pedido.

Los seis bloques que definen el alcance de una cotización

Cada bloque responde una pregunta que el proveedor va a contestar igual, con o sin tu información. La diferencia es si la respuesta sale de tu planta o de lo que el proveedor supone.

No todos los bloques mueven el precio de la licencia. El volumen de OT, por ejemplo, puede no cambiar lo que cobra un proveedor y, aun así, define cuántas horas de configuración y capacitación hacen falta. Por eso conviene declararlos todos aunque no sepas cómo los usa cada oferta.

Alcance: sitios, activos y hasta dónde llega la compra

La primera definición es el perímetro. Pensá en una planta de envasado con dos líneas de llenado, una sala de compresores y servicios generales: calderas, HVAC de oficinas, iluminación de playa de camiones. ¿Servicios generales entra en el sistema o sigue a cargo de otra área con su propio contratista? Si el pedido no lo dice, un proveedor lo incluye y otro no, y las dos propuestas describen compras distintas.

Lo mismo pasa con el crecimiento. Si hay una segunda planta en carpeta para dentro de un año, se declara ahora. Pasar de un sitio a varios cambia la estructura de permisos, la codificación de activos y la decisión de si cada planta conserva sus propios criterios de prioridad. Una propuesta pensada para un solo sitio puede no sostener eso sin reconfigurar.

El número de activos necesita una aclaración que casi nunca aparece: qué se cuenta como activo. Una línea de llenado puede figurar como un equipo o como sesenta componentes con plan y historial propios. Para el pedido, lo útil es contar los equipos mantenibles, es decir, los que van a tener OT, preventivo o historial asociado. La jerarquía de activos define ese nivel; si todavía no está resuelta, declaralo.

Algunos proveedores cobran según la cantidad de activos y otros no. En OTEX, los activos son ilimitados en todos los planes publicados, así que ese número no cambia la licencia. Sí cambia el trabajo de carga inicial: cada equipo hay que codificarlo, ubicarlo en la jerarquía y asociarlo a sus planes.

Usuarios por perfil: la variable que más deforma una comparación

“Usuario” no significa lo mismo en dos propuestas. Hay proveedores que cuentan usuarios nombrados, otros que separan por perfil y otros que no cuentan a quien solo reporta fallas. Si el pedido dice “unos 30 usuarios”, cada uno completa el resto con su propio criterio.

La salida es declarar personas por rol, aunque no sepas cómo cobra cada oferta:

La fila de solicitantes es la que más diferencia genera. En OTEX, los solicitantes son ilimitados en todos los planes; en otra propuesta pueden representar la mitad de las licencias. Con los perfiles separados, cada proveedor aplica su regla sobre la misma base y la comparación se sostiene. Cómo se traduce cada perfil en precio es otra discusión, y la resuelve cada propuesta.

Sumá una columna con el crecimiento previsto a 12 o 24 meses. Si en una segunda etapa los contratistas de HVAC van a cerrar sus OT en el sistema, esas personas tienen que aparecer en el pedido desde el principio, aunque no entren en el primer año.

Volumen de trabajo: OT por mes, preventivos, solicitudes y contratistas

El volumen dimensiona la implementación: cuántos tipos de OT configurar, cuántos planes preventivos cargar, cuánta capacitación necesita cada rol y cuánto se va a usar la app en campo. Las rutinas de alta frecuencia son las que más se subestiman. Una ronda diaria de inspección sobre 40 equipos genera del orden de 1.200 registros por mes. Si esa ronda va a hacerse en el sistema, el proveedor tiene que saberlo.

Cuando no hay un registro formal, el número se puede reconstruir con un método simple:

Con los preventivos, en este bloque importa la cantidad: cuántos planes activos hay y con qué frecuencias. Dónde están guardados y en qué estado se declara más adelante, en el bloque de datos.

Con los contratistas, declarar qué servicios tercerizás (grúas, instrumentación, HVAC, limpieza técnica) y si van a ejecutar dentro del sistema o solo recibir la OT. La diferencia cambia usuarios, permisos y la forma de validar cierres.

Condiciones de campo e IT que hay que declarar antes, no después

Estas condiciones son las que aparecen como adicionales cuando la propuesta ya fue aprobada. Este bloque no reabre ninguna decisión técnica: declara la que ya se tomó o dice que está pendiente.

La fila de zonas sin señal merece una recorrida con el supervisor, no una estimación desde la oficina. Un técnico que cierra la OT de una bomba centrífuga en el subsuelo y no puede registrar nada hasta volver al taller termina cargando de memoria al final del turno, si es que carga. Si todavía no está claro si el caso lo requiere, antes de escribir el pedido revisá cuándo el trabajo offline es un requisito real.

Con el alojamiento pasa algo parecido. Si IT todavía no tomó la decisión entre nube y on-premise, el pedido debería decirlo en esos términos: “modalidad a definir; se solicita cotizar ambas”. Así se evitan propuestas que asumen algo que después IT rechaza.

En alimentos y bebidas, el último renglón suele pesar más de lo que parece. Si la auditoría de inocuidad revisa registros de mantenimiento de equipos en contacto con producto, el pedido tiene que especificar qué registro se revisa, qué evidencia lo acompaña y quién lo firma. Esa información define cómo se configura el cierre de cada OT.

Estado real de los datos que ya tenés

Este bloque describe con qué información contás hoy. Qué datos necesita el sistema para arrancar es otra lista, la de los datos mínimos que el sistema necesita para arrancar. Para el pedido alcanza con declarar el estado actual, sin prometer que está limpio.

La diferencia tiene consecuencias. Pensá en un padrón de activos en Excel donde la misma bomba figura dos veces: una con el código de compras y otra con el TAG de planta. Ese padrón no se importa, se depura. Si el pedido dice “tenemos el listado de activos”, el proveedor cotiza una importación. Si dice “tenemos un listado con duplicados entre códigos de compras y TAG”, cotiza una depuración. Son trabajos distintos, con horas distintas, y la diferencia aparece en el primer mes de implementación.

Si una fuente no existe, escribilo así, sin rodeos. Un proveedor que sabe que no hay historial previo cotiza distinto de uno que cree que hay que migrar cinco años de registros.

Plazos, decisión y presupuesto: lo que casi nunca se escribe

“Lo antes posible” no es un plazo. El pedido necesita una fecha objetivo y, sobre todo, el motivo. En una planta de manufactura con parada anual en enero, esa ventana puede servir para cargar activos y planes sin presión de producción, o puede ser el peor momento, porque el equipo de mantenimiento está completo en la parada. Las dos lecturas llevan a cronogramas opuestos, y el proveedor no puede adivinar cuál aplica.

También hay que decir quién aprueba. Si la decisión pasa por compras corporativas, con alta de proveedor, formato de propuesta y cantidad mínima de cotizaciones, conviene saberlo antes de escribir el pedido y no cuando la propuesta ya circula con otro formato.

El presupuesto tiene un trade-off real. Declarar una banda permite que cada proveedor ajuste el alcance a lo posible, en lugar de mandar la oferta máxima o la mínima. No declararla preserva margen de negociación, pero aumenta la probabilidad de recibir propuestas que no se pueden comparar porque apuntan a operaciones de otro tamaño. Si no se declara un monto, al menos conviene aclarar la prioridad: arrancar con OT, activos y preventivos, o cubrir desde el inicio stock, integraciones y tableros.

Qué campos, si quedan vagos, obligan a re-cotizar

Del lado del proveedor, un campo vago se resuelve con un supuesto. La propuesta se arma sobre ese supuesto, y cuando la realidad aparece en el relevamiento técnico o en la implementación, hay que re-cotizar.

Cada campo vago se convierte en un supuesto del proveedor, y cada proveedor supone distinto.

Un pedido completo no garantiza propuestas idénticas, y tampoco debería. Lo que garantiza es que las diferencias entre propuestas respondan a lo que cada proveedor ofrece y no a lo que cada uno imaginó. Cuando las cotizaciones llegan, el siguiente paso es normalizar el alcance de dos propuestas antes de comparar números.

Checklist de relevamiento para pedir cotización

Qué hacer con el relevamiento antes de la primera reunión

Mandá el mismo documento a todos los proveedores, con el mismo plazo de respuesta. Si uno pide una aclaración, respondela a todos. Guardá la versión enviada: cuando lleguen las propuestas, es la referencia para detectar qué cotizó cada uno por fuera de lo pedido.

Lo que no sepas, declaralo como desconocido. “Cantidad de OT correctivas: sin registro, estimación pendiente” es información útil para el proveedor. Un número inventado no, porque genera una propuesta precisa sobre una base falsa.

El relevamiento también sirve después. Los flujos, perfiles y condiciones de campo que declaraste son el guion para lo que conviene probar en la demo: la demo debería mostrar tu alcance, no el recorrido estándar del proveedor. Para ver cómo encaja ese alcance en la oferta de OTEX, podés revisar los planes y el alcance de OTEX.