RFP para software CMMS: cómo escribir un pliego que se pueda comparar
Cómo escribir un RFP de software CMMS: requisitos verificables, obligatorios y puntuables, criterios de aceptación y matriz de evaluación de propuestas.
La planilla comparativa está terminada. Cinco columnas, una por proveedor, y casi todas las filas con la misma palabra: Cumple. El comité se reúne, mira el cuadro y descubre que lo único que quedó distinto entre las propuestas es el número de la última fila. La decisión se toma por precio, no porque alguien haya decidido que el precio era el criterio, sino porque el documento que se envió no produjo ninguna otra diferencia.
Ese resultado se define mucho antes, en la redacción del pliego. Un RFP de software CMMS —o pliego técnico, o bases y condiciones, según el país y el tipo de organización— no sirve para enumerar funcionalidades. Sirve para generar diferencias observables entre proveedores que, en el papel, hacen todos lo mismo.
Un requisito que todos los proveedores pueden responder con un “sí” no es un requisito: es una fila de la planilla.
Este artículo trata sobre cómo se escribe ese documento: qué secciones necesita, cómo formular un requisito para que la respuesta sea verificable, qué separa un obligatorio de un puntuable, qué pedir en el bloque técnico que Compras no suele redactar, y cómo evaluar las respuestas. Lo que el sistema tiene que hacer para tu operación es un trabajo previo y distinto: se resuelve relevando el proceso, no redactando el pliego.
Cuándo un CMMS justifica un RFP y cuándo no
Un proceso formal de licitación agrega entre seis y doce semanas al calendario y consume horas de Mantenimiento, IT, Compras y Legales. En operaciones donde una sola persona decide y firma, ese esfuerzo no mejora la elección: la mejora se consigue con dos o tres demostraciones bien preparadas y una comparación económica ordenada.
El documento formal se justifica cuando existe más de un interesado con poder de veto y ninguno controla el criterio del otro.
Si ninguna de esas condiciones aplica, conviene ir directo a comparar propuestas y dejar el esfuerzo de redacción para la etapa de contrato. Los criterios generales para elegir un CMMS/GMAO cubren ese camino más corto.
Qué tiene que estar resuelto antes de escribir la primera línea
Los anexos son lo que vuelve comparables las propuestas. Sin ellos, cada proveedor dimensiona el proyecto según lo que imagina y después nadie entiende por qué un número duplica al otro.
Cantidad de equipos a gestionar, niveles de la estructura y criterio de criticidad si existe. No hace falta el maestro depurado, sí el orden de magnitud y la forma de la jerarquía técnica de la planta.
Órdenes de trabajo por mes, proporción entre correctivo y preventivo, cantidad de solicitudes y de rutinas activas. Sin este dato, ningún proveedor puede estimar esfuerzo de configuración ni dimensionar el rendimiento.
Técnicos que cargan trabajo, supervisores, planners, personal de pañol, solicitantes que solo reportan fallas, contratistas y perfiles de solo lectura. Es la variable que más mueve la cotización.
ERP y su versión, sistema de compras, plataforma de identidad corporativa, herramienta de tableros. Qué dato nace en cada sistema y con qué frecuencia debería sincronizarse.
Cobertura de datos en planta, zonas sin señal, dispositivos disponibles, política de acceso a internet en la red industrial y requisitos de seguridad informática.
El anexo de datos merece atención particular. Un pliego que exige “migración completa del historial” sin decir de cuántas fuentes, en qué formato y con qué calidad, garantiza que las cotizaciones de migración no se puedan comparar. El checklist de datos mínimos para implementar un CMMS sirve para acotar qué se migra de verdad. La definición previa de qué necesita tu operación es una etapa distinta y anterior: si todavía no está cerrada, conviene resolverla antes de redactar, no dentro del pliego.
Las secciones mínimas del documento
Los pliegos de CMMS publicados por organismos públicos —que quedan disponibles como documentos completos, con su matriz de ponderación incluida— muestran una estructura bastante estable. Esta es la versión mínima que sostiene una comparación seria en una operación industrial.
| Sección | Para qué sirve | Error frecuente |
|---|---|---|
| Contexto y alcance | Describe la operación, las plantas incluidas y qué queda fuera del proyecto | Describir la empresa y no la operación de mantenimiento |
| Requisitos obligatorios | Condiciones excluyentes, evaluadas como cumple o no cumple | Cargar aquí toda la lista funcional y dejar sin proveedores el proceso |
| Requisitos puntuables | Capacidades que se puntúan y producen la diferencia entre propuestas | Redactarlos como features y no como escenarios operativos |
| Requisitos técnicos | Arquitectura, seguridad, accesos, integración, disponibilidad y datos | Omitirlos porque IT entró tarde al proceso |
| Servicios | Implementación, migración, capacitación, soporte y gestión de cambios | Pedir "capacitación" sin decir a cuántas personas ni en qué formato |
| Criterios de aceptación | Cómo se va a comprobar cada requisito antes de firmar | No incluir la sección y aceptar la planilla de respuestas como verificación |
| Evaluación y ponderación | Pesos por bloque y escala de puntuación, publicados de antemano | Definir los pesos después de leer las propuestas |
| Formato de respuesta | Estructura obligatoria, anexo económico y límites de extensión | Recibir cinco presentaciones comerciales con formatos distintos |
| Cronograma y consultas | Plazos, ventana de preguntas y reglas de comunicación | Responder preguntas a un proveedor y no compartir la respuesta con el resto |
Cómo se escribe un requisito que se puede verificar
Un requisito verificable tiene tres partes: un escenario operativo, un dato concreto y la evidencia que se espera recibir. Los tres importan. “Gestión de órdenes de trabajo” no describe nada que un proveedor pueda dejar de cumplir. “Cerrar una OT correctiva desde el celular, sin señal, registrando horas, repuestos, checklist y dos fotos” describe una situación que sucede en la sala de máquinas y que no todos los productos resuelven igual.
| Bloque | Requisito que no diferencia | Requisito verificable |
|---|---|---|
| Órdenes de trabajo | El sistema debe permitir la gestión de órdenes de trabajo. | Debe permitir cerrar una OT correctiva registrando horas por técnico, repuestos consumidos, checklist de tareas y al menos dos fotos, con todo imputado al activo intervenido. Evidencia: cierre en vivo de una OT creada por el evaluador durante la sesión. |
| Trabajo en campo | Debe contar con aplicación móvil. | Un técnico debe poder abrir su OT asignada, completar el checklist y adjuntar fotos sin conexión de datos, y sincronizar al recuperar señal sin perder el registro ni duplicarlo. Evidencia: prueba con el dispositivo en modo avión durante la demostración. |
| Activos | Debe permitir jerarquía de activos. | Debe soportar al menos cuatro niveles (planta, línea, equipo, componente), permitir reubicar un equipo conservando su historial completo y mostrar costo acumulado en cualquier nivel de la estructura. Evidencia: mover un activo en vivo y mostrar el historial después del movimiento. |
| Repuestos | Debe gestionar el inventario de repuestos. | La salida de un repuesto de pañol debe imputarse a la OT y al activo, descontar stock y quedar reflejada en el costo del equipo sin una carga manual adicional. Evidencia: captura del movimiento y del costo resultante en la ficha del activo. |
| Permisos | Debe contar con perfiles y permisos configurables. | Un supervisor de una planta no debe poder editar ni cerrar OT de otra planta, pero sí consultar sus indicadores. Evidencia: demostración con dos usuarios de prueba durante la sesión. |
| Reportes | Debe generar reportes e indicadores. | Debe exportar el detalle de OT cerradas de un periodo con activo, tipo de trabajo, horas, repuestos y fechas, en un archivo que se pueda cruzar en una herramienta de tableros sin retrabajo manual. Evidencia: archivo exportado durante la evaluación. |
La columna de evidencia es la que cambia el comportamiento del proveedor. Cuando un requisito indica cómo se va a comprobar, responder “sí” deja de ser gratis: alguien va a pedir la demostración. Los criterios para juzgar si el trabajo offline realmente importa en tu planta están en cuándo importa una app móvil con operación offline, y el recorrido completo de una OT en el flujo del sistema de órdenes de trabajo.
Obligatorio o puntuable: la decisión que más caro sale
Cada requisito obligatorio elimina proveedores antes de que nadie lea su propuesta. Eso lo vuelve una herramienta cara y poco reversible.
La regla práctica: solo es obligatorio aquello cuya ausencia cancela el proyecto. Todo lo demás se puntúa. Un obligatorio redactado alrededor de una forma particular de implementación —“debe contar con módulo propio de compras”, cuando lo que se necesita es que el pedido de repuestos llegue al ERP— deja afuera productos que resuelven el mismo problema por otro camino, y nadie se entera porque esas propuestas ni siquiera se abren.
La señal de alarma es clara: si en la revisión interna nadie puede describir qué pasa operativamente si ese requisito falta, no era un obligatorio.
Requisitos funcionales: qué nivel de detalle corresponde a cada bloque
La tentación es listar todo. El resultado es un anexo de doscientas filas que nadie puntúa con criterio y que los proveedores completan en modo automático.
Conviene un tratamiento desparejo y deliberado: detalle fino en los tres o cuatro bloques donde se juega la operación, y una línea por bloque en el resto.
Requisitos técnicos y no funcionales
Es el bloque que más se omite y el que más caro sale después, porque IT suele entrar al proceso cuando el pliego ya salió. También es el que casi no aparece en las plantillas de RFP que circulan en español.
| Ítem | Qué preguntar | Qué evidencia pedir |
|---|---|---|
| Despliegue | Modalidad ofrecida, región donde residen los datos, opciones de nube dedicada u on-premise | Documento de arquitectura del proveedor |
| Disponibilidad | Compromiso de servicio, ventanas de mantenimiento programado, aviso previo de actualizaciones | Texto contractual del SLA, no una afirmación comercial |
| Backup y recuperación | Frecuencia de copias, retención, tiempo objetivo de recuperación, quién puede solicitar una restauración | Procedimiento documentado |
| Accesos | Método de autenticación, integración con el directorio corporativo, cómo se da de baja a una persona que deja la empresa | Demostración de un alta y una baja |
| Integración | Qué interfaces existen, en qué dirección, con qué frecuencia y quién es responsable cuando la conexión falla | Documentación de la API accesible durante la evaluación |
| Ambiente de pruebas | Si existe un entorno separado, si está incluido y cómo se refrescan sus datos | Acceso al ambiente durante la prueba de aceptación |
| Rendimiento | Comportamiento con el volumen real declarado en el anexo, no con una base vacía | Prueba con un conjunto de datos del tamaño esperado |
| Salida de datos | Formato, alcance y plazo de entrega de la información al terminar el contrato | Cláusula escrita, no una respuesta afirmativa en la planilla |
La pregunta sobre despliegue conviene formularla sin cerrar el mercado de antemano: exigir on-premise por política cuando nadie revisó si la política aplica a este caso elimina buena parte de la oferta. Los criterios para decidirlo están en CMMS en la nube frente a on-premise. Dos ítems de esa tabla merecen una aclaración de alcance: el reparto funcional de datos entre el CMMS y el ERP —qué maestro vive en cada sistema— y la gestión de identidades corporativas son definiciones de diseño previas al llamado. En el pliego entra el requisito y la evidencia que lo comprueba, no la discusión técnica que hay detrás.
Migración, propiedad y salida de los datos
Se pide en el pliego porque después no se negocia. Una vez firmado, la conversación sobre exportación de datos ocurre en el peor momento posible.
Conviene exigir cuatro definiciones: de qué fuentes se migra, quién depura los registros antes de la carga, cuántas cargas de prueba están incluidas y qué se considera una carga aceptada. La cuarta es la que evita la discusión clásica de la semana previa al arranque. El impacto económico de cada una de esas decisiones está desarrollado en qué incluye el costo total de un CMMS.
Requisitos de servicio: implementación, capacitación y soporte
El software se elige en la demostración; el proyecto se gana o se pierde en estos tres puntos. Conviene pedir que el plan de implementación sea un entregable de la propuesta, no una promesa.
La estrategia para sostener la operación durante la transición es un tema del proyecto, no del pliego, y está desarrollada en implementar un CMMS sin frenar la operación. Para dimensionar la partida de formación, el plan de capacitación por roles sirve de referencia sobre qué se le puede exigir a un proveedor.
Criterios de aceptación: de “cumple” a “lo demostró con mis datos”
Esta sección es la que convierte el pliego en una herramienta de verificación. Declara, antes de recibir propuestas, cómo se va a comprobar lo que los proveedores respondan.
La verificación tiene tres niveles de exigencia creciente, y conviene usar los tres sobre poblaciones distintas de requisitos: demostración guionada para el grueso de los funcionales, prueba con datos propios para los diez o doce requisitos que definen la decisión, y piloto acotado solo si el proyecto lo justifica por tamaño.
La demostración guionada merece un detalle: el guion lo escribe el comprador, no el proveedor. Una sesión donde el vendedor elige el recorrido muestra el producto en su mejor forma y no distingue a nadie. Los criterios para armar ese guion están en qué probar en una demo de software CMMS.
La matriz de evaluación: cómo se puntúa y cómo se desempata
Los pesos se publican en el pliego y se definen antes de recibir la primera propuesta. Definirlos después convierte la evaluación en una justificación de la decisión ya tomada.
Este reparto es un ejemplo para adaptar, no una referencia del sector. Los pesos reales dependen de qué se juega en cada operación: una planta con técnicos que nunca vuelven a la oficina debería cargar más peso en el bloque de campo que una operación de facility con todo el personal conectado.
| Bloque | Peso de ejemplo | Qué se puntúa |
|---|---|---|
| Requisitos funcionales puntuables | 35 | Cobertura de los escenarios operativos declarados, con la evidencia mostrada durante la verificación |
| Técnico e integración | 20 | Arquitectura, accesos, API, ambiente de pruebas y condiciones de salida de datos |
| Servicios del proyecto | 15 | Plan de implementación, capacitación, soporte y esfuerzo declarado del cliente |
| Verificación demostrada | 10 | Resultado de la sesión guionada y de la prueba con datos propios |
| Propuesta económica | 20 | Anexo con estructura fija, evaluado sobre el mismo periodo para todos |
La escala de puntuación necesita significado escrito. “Del 1 al 5” sin definición produce evaluadores que puntúan en rangos distintos y un promedio que no dice nada. Tres niveles bien definidos —no cubre, cubre con configuración, cubre de forma nativa y demostrada— suelen ordenar mejor que cinco niveles ambiguos.
Para los empates, conviene fijar el criterio de desempate en el mismo pliego. Si dos propuestas quedan a menos de tres puntos, la referencia útil no es el precio: es el resultado de la prueba con datos propios y las referencias verificables de clientes del mismo tamaño y sector. El anexo económico merece la misma disciplina que el resto del documento: partidas fijas y el mismo periodo de evaluación para todas las ofertas.
Cronograma, formato de respuesta y reglas de consulta
Es la sección más aburrida del documento y la que más determina si las propuestas van a ser comparables.
Requisitos que conviene no pedir
Buena parte de los pliegos de CMMS se arman sobre plantillas genéricas que en realidad describen sistemas EAM corporativos. Esos requisitos no son incorrectos, pero pertenecen a otro alcance: inflan la evaluación, empujan la cotización hacia arriba y obligan al comité a puntuar funciones que nadie va a usar. Las diferencias de alcance entre un CMMS y un EAM explican de dónde vienen.
Dejá tu email y te mandamos las nueve secciones con el criterio de aceptación que corresponde a cada bloque.
Al enviar tu email aceptás nuestra Política de Privacidad.
El control más simple sobre un borrador terminado es leer la planilla de requisitos imaginando que sos el proveedor. Si podés responder “sí” a cuarenta filas seguidas sin abrir el producto, el documento todavía no está listo para salir: falta la columna de evidencia y falta decidir qué se va a verificar con datos propios.
¿Ya tenés un borrador del pliego?
Podemos revisarlo y señalarte qué requisitos no van a diferenciar a ningún proveedor y cuáles necesitan un criterio de aceptación antes de salir a licitar.
