Licitación facility management: requisitos y puntuación paso a paso

Quedan dos semanas para publicar el pliego. El documento que heredó es la plantilla que usó compras hace años para contratar limpieza y mantenimiento: cláusulas de uniformidad, frecuencias de barrido, penalizaciones por retraso en partes de trabajo. Ahora tiene que adaptarla para contratar una plataforma de datos de ocupación y tráfico que alimentará decisiones de renta, seguridad y mantenimiento en todo el portafolio, y nadie en el comité ha redactado antes un requisito técnico que un abogado pueda defender. Este artículo trata exactamente de eso: cómo escribir los requisitos y el esquema de puntuación de una licitación facility management cuando lo que se compra es software, no horas de servicio. Si todavía está definiendo qué funciones necesita, la guía completa de software de operaciones inmobiliarias cubre esa fase previa; aquí asumimos que ya sabe lo que quiere y necesita ponerlo por escrito de forma que los proveedores no puedan esquivarlo.

Estructura de plantilla para una licitación facility management

Un pliego para software de operaciones de edificios funciona mejor con siete bloques fijos. El orden importa: los proveedores leen el documento buscando qué pueden omitir, y una estructura numerada les obliga a responder punto por punto.

• 1. Contexto operativo: número y tipo de activos, entradas por activo, sistemas actuales (BI, ERP, POS, CRM) con versión, y las decisiones concretas que tomará con los datos. Sin este bloque, cada proveedor dimensiona la propuesta a su conveniencia.
• 2. Requisitos obligatorios: criterios de exclusión. Quien no los cumple queda fuera antes de la puntuación.
• 3. Requisitos valorables: lo que diferencia propuestas y recibe puntos.
• 4. Garantías y SLA: precisión mínima contractual, disponibilidad, tiempos de respuesta de soporte y penalizaciones.
• 5. Modelo económico: plantilla de precios que el proveedor debe rellenar con el mismo desglose, a escala de portafolio completo, no solo del piloto.
• 6. Condiciones de salida: propiedad de los datos, formato de exportación y plazo de entrega al terminar el contrato.
• 7. Formato de respuesta y calendario: extensión máxima, matriz de cumplimiento a rellenar, fechas de preguntas, demo y adjudicación.

Cómo redactar un requisito que no admite respuesta vaga

La mayoría de los requisitos que fallan en una licitación fallan por redacción. "El sistema debe integrarse con nuestro BI" recibirá un "Cumple" de todos los licitadores, y ninguno estará mintiendo. Un requisito útil tiene cuatro elementos: la capacidad concreta, la condición en la que debe cumplirse, la evidencia que el proveedor debe aportar y el método con el que usted lo verificará.

Compare las dos versiones del mismo requisito de precisión. Versión débil: "Alta precisión de conteo". Versión defendible: "El proveedor garantizará contractualmente una precisión mínima del 96% en el conteo de entradas, verificada mediante conteo manual de contraste de al menos una hora en cada entrada del piloto. Deberá indicar el rendimiento típico esperado y las condiciones de iluminación, distribución y comportamiento de visitantes bajo las cuales lo alcanza". Un proveedor serio responderá con un mínimo firmado y un rango típico del 98 al 99% cuando las condiciones lo permiten. Un proveedor que responda con un 99% plano y sin condiciones acaba de revelar que no ha leído el requisito o que no ha instalado sensores en un atrio con luz natural.

Aplique la misma lógica al resto de los bloques críticos:

• Integración: exija el nombre de los conectores existentes para sus sistemas concretos, una referencia de cliente que los use en producción y el diccionario de datos. Las plataformas con una capa de integración dedicada, como VemFusion, pueden documentar esto sin proyecto a medida; pida que lo demuestren con su propio esquema de datos durante la demo.
• Independencia de hardware: pregunte si el software acepta sensores de distintos fabricantes y si puede incorporar dispositivos ya instalados en activos adquiridos. Pida la lista de modelos soportados.
• Hosting: si gestiona activos para fondos, especifique si requiere nube privada como obligatorio y exija el sobrecoste desglosado en el bloque económico.
• Exportación de datos: "acceso vía dashboard" no es exportación. Pida un fichero de ejemplo adjunto a la propuesta.

La matriz de puntuación: pesos, escala y evidencia por criterio

Puntúe únicamente lo que puede comprobar con documentos, referencias o pruebas. Una distribución que ha funcionado en licitaciones de portafolios medianos asigna 30% a garantías contractuales, 25% a integración demostrada, 20% a coste total a tres años, 15% a independencia tecnológica y 10% a experiencia en su tipo de activo. Ajuste los pesos a su contexto, pero mantenga la regla: ningún criterio basado en "impresión de la demo".

Para cada criterio, defina una escala de cuatro niveles con descripciones escritas antes de abrir las ofertas. Por ejemplo, en integración: 0 puntos si solo ofrece API genérica; 1 si presenta conector documentado sin referencia; 2 si aporta referencia verificable con un sistema equivalente al suyo; 3 si la demostración con sus datos reales funciona durante la fase de evaluación. Las descripciones escritas de antemano eliminan la discusión posterior sobre por qué un evaluador puntuó 2 y otro 3.

El bloque de coste merece una plantilla propia. Pida que todos los licitadores rellenen las mismas filas: licencia anual por volumen de activos, hardware por entrada, instalación por ubicación incluyendo cableado donde no haya PoE, calibración inicial, recalibraciones tras reformas, formación y soporte. Añada una fila que casi nadie incluye: quién coordina permisos de inquilinos, trabajos nocturnos y aprobación del seguro del edificio, y quién asume el coste si un inquilino retrasa el acceso. La respuesta a esa fila distingue a quien ha instalado en un centro comercial operativo de quien solo ha vendido licencias.

Proceso de evaluación: demo guionizada y piloto con condiciones heredadas

Prohíba la demo libre. Entregue a cada finalista el mismo guion: cargar un conjunto de datos suyo, mostrar la exportación en el formato exigido, enseñar el flujo hacia su BI y simular una incidencia de soporte. Lo que no está en el guion no puntúa. En la misma fase, llame a las referencias con tres preguntas fijas: qué prometieron que no cumplieron, cuánto tardó la integración real y cuántas visitas de recalibración hubo el primer año.

Finalmente, escriba en el pliego que el piloto se ejecutará en el activo más difícil del portafolio, no en el mejor, y que precios y condiciones del piloto se trasladan íntegramente al despliegue completo. Quien acepta esta cláusula sin fricción tiene base de clientes y trayectoria para sostenerla.

Preguntas frecuentes

¿Cuántos requisitos obligatorios debe tener el pliego? Los menos posibles y todos excluyentes de verdad. Si un criterio no justifica descartar a un buen proveedor, pertenece al bloque valorable, no al obligatorio. Entre cinco y diez suele bastar para software de operaciones de edificios.

¿Debo fijar un presupuesto máximo en la licitación? Es preferible fijar la plantilla de desglose y el horizonte de tres años en lugar de una cifra tope. Un tope invita a que todos oferten justo por debajo recortando partidas invisibles como recalibraciones o soporte.

¿Qué hago si ningún proveedor acepta la garantía de precisión firmada? Revise si la redacción define condiciones de verificación realistas, porque un mínimo del 96% con método de contraste claro es asumible para proveedores con experiencia. Si sigue sin haber firmantes, el problema está en la lista de invitados, no en el requisito.

Si está redactando el pliego y quiere contrastar la redacción de requisitos, la escala de puntuación o la plantilla de costes antes de publicarlo, hable con el equipo de Vemco Group en vemcogroup.com/contact-us: revisamos su borrador y le indicamos qué cláusulas quedan abiertas a interpretación.