01 De dónde sale cada uno
Las tres siglas dominan las conversaciones de software en infraestructura crítica y casi nadie las separa con limpieza. Las tres aparecieron en momentos históricos distintos, resolviendo problemas distintos, y cada una arrastra su pasado.
El BMS nace en los 80 con los protocolos propietarios de control de edificios — pneumatic, después digital, después BACnet y Modbus. Su trabajo era hacer que un edificio prendiera y apagara cosas en respuesta a sensores. Cuando un data center se pensaba como un edificio especial, el BMS bastaba.
El DCIM aparece a finales de los 2000 cuando los data centers crecieron lo suficiente como para que el inventario en Excel ya no funcionara. Eran herramientas para inventariar racks, rastrear capacidad de espacio/energía/red y registrar cambios. La promesa era integrar también el lado eléctrico y térmico del BMS y entregar una vista unificada. La realidad fue más modesta.
El ERP es el más viejo y el más genérico. SAP, Oracle y compañía vienen del mundo manufacturero y financiero. En infraestructura, el ERP se ocupa de contratos, órdenes de compra, mantenimientos preventivos calendarizados, gestión de proveedores y reportes de costo. Técnicamente no toca un sensor en su vida.
02 BMS: el sistema nervioso del edificio
Un BMS moderno de data center tiene tres responsabilidades claras: leer sensores (temperatura, humedad, presión diferencial, corriente, kWh, estado de válvulas, posición de dampers), actuar sobre el equipo de enfriamiento, eléctrico y de respaldo, y alertar cuando algo sale de rango. Todo eso a frecuencias de segundos a minutos, con redundancia y con un audit log de quién cambió qué.
Qué espera un BMS de un data center mexicano
- Multi-protocolo de verdad: BACnet/IP, BACnet MS/TP, Modbus TCP, Modbus RTU, SNMP v2/v3, OPC UA. La realidad del mercado mexicano es que un sitio puede tener seis marcas distintas de equipo crítico, cada una hablando su propio dialecto.
- Setpoints versionados con bitácora. Cualquier cambio de un setpoint debe quedar registrado con usuario, hora, valor anterior y motivo.
- Esquema de redundancia activo-pasivo a nivel del controlador maestro, no solo del servidor de visualización.
- Latencia de alarmas debajo de los 5 segundos punto a punto. Si una alarma térmica tarda dos minutos en llegar al guardia, no sirve para operar.
Lo que un BMS no hace bien
Un BMS no sabe quién es el cliente del rack 42 ni con qué SLA está comprometido. No sabe cuándo vence la garantía del chiller principal, ni qué orden de compra tiene abierta su contratista de mantenimiento. No sabe que la última vez que el CRAH-3 se cambió de filtros fue hace 47 días. Esa información vive afuera.
03 DCIM: inventario, capacidad y bitácora
El DCIM es el que tradicionalmente se vende como "el cerebro del data center", y aquí vale ser muy honestos: ese cerebro casi siempre fue un catálogo. Las funciones que cualquier DCIM serio entrega son inventario de racks y equipos, planeación de capacidad de espacio, energía y enfriamiento, gestión de cambios (workflow para mover servidores), mapa de conectividad y reporte ejecutivo.
Donde los DCIM tradicionales fallan en la práctica es en la integración bidireccional con el BMS. Muchos leen datos del BMS por SNMP cada cinco minutos y los pintan en un mapa de calor, pero no escriben al BMS, no participan en lógica de control y no tienen audit log compatible con un BMS de misión crítica.
El caso útil del DCIM
Donde un DCIM sí aporta valor real es en operación de colocation, donde la pregunta "cuánta capacidad me queda en MW por sala" es de negocio. Y en sitios grandes con cientos de racks donde el inventario en hoja de cálculo deja de escalar. En un edge data center de 200 kW, instalar un DCIM completo suele ser sobreingeniería.
04 ERP: contratos, órdenes y costos
El ERP es el sistema donde viven las cosas que la dirección financiera necesita: contratos con clientes y proveedores, órdenes de compra, órdenes de trabajo, mantenimientos preventivos calendarizados, refacciones en almacén, facturación y conciliación. Para infraestructura crítica, los módulos relevantes son CMMS (mantenimiento), inventario, compras y a veces gestión documental para garantías.
En la práctica del mercado mexicano, el ERP suele ser SAP en operadores grandes, Oracle en banca, Odoo o NetSuite en operadores medianos, y Excel con macros en operadores chicos. Eso no es un juicio — es la realidad. El problema no es cuál ERP usan, es que el ERP está desconectado del BMS y del DCIM.
El síntoma clásico
Un chiller se alarma a las 03:14 y el BMS lo registra. A las 03:18 el guardia abre un ticket. A las 09:00 del lunes el ticket se transcribe a una orden de trabajo en el ERP. El técnico llega el martes y se da cuenta que la refacción no está en almacén porque no hay vínculo entre la alarma y el inventario de partes. Esa friccion de 36 horas y tres transcripciones manuales es lo que cuesta — en SLA, en HVAC operado fuera de banda y en riesgo térmico acumulado.
05 La tabla comparativa honesta
| Capacidad | BMS | DCIM | ERP |
|---|
| Lectura de sensores físicos | Sí, nativo | Indirecto vía BMS | No |
| Actuación sobre equipo | Sí, con audit log | Limitada | No |
| Inventario de activos y racks | Limitado a equipo crítico | Sí, núcleo del sistema | Sí (financiero) |
| Capacidad libre por sala | No | Sí | No |
| Órdenes de trabajo y CMMS | No | Básico | Sí, núcleo |
| Contratos y SLA por cliente | No | Limitado | Sí |
| Refacciones en almacén | No | No | Sí |
| Reporte de costos por sitio/cliente | No | Limitado | Sí |
| Frecuencia de datos | Segundos | Minutos | Diaria/horaria |
El cuadro deja ver lo obvio: las tres herramientas son complementarias por diseño. El problema histotérico es que viven en silos de proveedores distintos, con bases de datos distintas, modelos de identidad distintos y ventanas de mantenimiento distintas.
06 Lo que pasa en las costuras
El 80 % del dolor operativo en sitios mexicanos no está dentro del BMS, ni dentro del DCIM, ni dentro del ERP. Está en las costuras. Hay tres costuras típicas:
BMS ↔ DCIM
El BMS sabe que el rack 17 está consumiendo 5.2 kW. El DCIM sabe que el rack 17 está rentado a Cliente X con un compromiso de 6 kW. Si la integración existe, se puede facturar consumo real y planear capacidad. Si no existe, se factura por contrato sin saber que Cliente X está al 87 % de su límite y va a saturar el branch circuit.
BMS ↔ ERP
El BMS detecta una alarma de filtro saturado en CRAH-3. El ERP debe generar automáticamente una orden de trabajo, asignar técnico, verificar inventario de filtros, agendar visita y cerrar el ciclo cuando la pieza se cambió y el BMS confirma que el delta-P volvió al rango. Si esa cadena no está automatizada, el operador la lleva en la cabeza y la cabeza falla a las 3 de la mañana.
DCIM ↔ ERP
La planeación de capacidad del DCIM tiene que reconciliarse con los contratos del ERP para saber cuánto puedo vender. Si las dos cifras viven en silos, el comercial vende capacidad que el sitio no tiene y el operador descubre el problema cuando el contrato ya está firmado.
07 Por qué tiene sentido una plataforma única
La tesis técnica detrás de Vertiko es simple de enunciar y costosa de ejecutar: las tres capas comparten suficientes entidades —sitio, sala, rack, equipo crítico, técnico, contrato, alarma— como para que tenga sentido construirlas sobre una sola base de datos con una sola identidad de usuario y un solo audit log. Eso no es una integración: es un diseño unificado.
Las ventajas concretas son tres:
- Cero pérdida en transcripción. La alarma que dispara el BMS es la misma entidad que la orden de trabajo del ERP. No hay copia y pega entre sistemas.
- Un solo modelo de permisos. Un técnico tiene permiso para ver el BMS de su sitio, las órdenes de su equipo en ERP y el inventario de racks de DCIM en una sola sesión.
- Audit log inmutable end-to-end. Para ISO 27001 y para auditoría de SLA, poder trazar desde la decisión de cambiar un setpoint hasta la factura del cliente sin huecos es ahorro real.
El argumento que más convence al CFO
El argumento puramente técnico de la plataforma unificada no es lo que mueve la decisión; lo que la mueve es la cuenta de licencias acumuladas. Un operador con tres sitios medianos pagando licencias separadas de BMS (por punto de control), DCIM (por rack gestionado) y CMMS (por usuario) llega típicamente a una factura anual de software comparable al sueldo de dos ingenieros senior. Cuando ese mismo operador suma los costos de mantenimiento de tres integraciones bidireccionales construidas a mano, la cuenta sube otro 30-50 %. La plataforma unificada no se vende en el ROI inmediato; se vende en la TCO de tres a cinco años.
Cuándo NO conviene una plataforma unificada
Para ser técnicamente honestos: hay escenarios donde lo correcto es mantener separados los tres sistemas. Operadores con SAP profundamente arraigado en finanzas y con compliance regulado en SOX que requieren el ERP global, suelen no querer mover el ERP. En estos casos la plataforma unificada cubre BMS y DCIM, y se integra con el ERP existente por API. El criterio no es ideológico — es dónde están las costuras más costosas.
El factor cultural que rara vez se discute
Cambiar de stack de tres proveedores a una plataforma única requiere que los equipos de Facility, IT y Finanzas conversen distinto. En muchas operaciones mexicanas el Facility Manager habla con su integrador de BMS de hace 12 años; IT habla con SAP; Finanzas no habla con ninguno. Una plataforma unificada obliga a estos tres a sentarse en la misma mesa de gobernanza. Eso es virtud y obstaculo en partes iguales: sin la voluntad de hacerlo, el proyecto fracasa por razón no técnica.
El criterio práctico. Si su operación tiene menos de 3 sitios y menos de 200 racks, probablemente no necesita DCIM completo y puede vivir con un BMS sólido más CMMS. Si tiene más de 5 sitios o entra al juego de colocation, la pregunta deja de ser "BMS o DCIM" y se vuelve "qué integración y bajo qué modelo de datos". Ahí es donde una plataforma unificada gana al stack de tres proveedores.
¿Operas infraestructura crítica?
Cuéntanos qué corres en una llamada técnica de 30 minutos sin slides. Diagnóstico, no demo.
Agenda llamada técnica →