Conocerás todas las piezas de tecnología que conviven en un centro y para qué sirve cada una, de modo que puedas gestionarlas como un sistema y no como cajas sueltas. El mapa que ordena el pilar y enlaza con el stack del Pilar 0.
Conocerás todas las piezas de tecnología que conviven en un centro y para qué sirve cada una, de modo que puedas gestionarlas como un sistema y no como cajas sueltas.
Del Pilar 5, donde cubriste la seguridad, salud y cumplimiento del centro.
Al mapa del stack tecnológico y a cómo supervisar IT sin ser técnico.
La tecnología de un centro se entiende mejor por capas. La capa de infraestructura de red (internet, router, switches, puntos de acceso wifi) es la base: si falla, falla todo lo demás. La capa de sistemas del edificio (control de accesos, sensores, gestión del edificio) automatiza y controla el espacio. La capa de software de gestión (el PMS, el CRM, la facturación, la app de comunidad) lleva el negocio. Y la capa de tecnología de miembro (AV de salas, impresión, wifi de invitados) es la que el usuario toca directamente.
Desde Operaciones, lo importante es saber qué es crítico y qué es accesorio en cada capa, y quién gestiona cada parte. Algunos sistemas son propios del operador (el PMS, la app) y los gestiona el equipo central; otros son del centro y se gestionan localmente; otros se externalizan a un proveedor de IT. Tener este mapa claro evita el caos de no saber a quién llamar cuando algo no funciona.
El rol del IT Manager —interno o un proveedor gestionado (MSP)— es mantener todo esto funcionando y seguro. Pero incluso cuando IT está externalizado, Operaciones es la interfaz local: quien detecta el problema, lo comunica, coordina la solución con el proveedor y responde ante el miembro. Por eso necesitas entender el stack aunque no lo administres tú.
Como la tecnología se externaliza con frecuencia a un MSP (Managed Service Provider, proveedor de servicios gestionados), una competencia clave de Operaciones es saber gestionar ese proveedor. Igual que cualquier otro proveedor (Pilar 4), el de IT necesita un contrato con SLAs claros: tiempos de respuesta ante incidencias, disponibilidad garantizada de los sistemas críticos, qué incluye el servicio y qué se factura aparte. Un MSP sin SLA bien definido deja al centro sin palancas cuando la red falla en el peor momento.
Gestionar al MSP exige un equilibrio: confiar en su criterio técnico, pero no quedar a ciegas. Operaciones debe entender lo suficiente para saber si la respuesta del proveedor es razonable, si los tiempos son adecuados y si las soluciones propuestas (sobre todo las que implican inversión) están justificadas. Aquí vuelve la idea del Pilar 1: el conocimiento técnico básico no es para hacer el trabajo del MSP, sino para supervisarlo con criterio.
Un punto crítico es la información y los accesos. El centro debe conservar el control de sus propios sistemas: las contraseñas maestras, la documentación de la red, los contratos con las operadoras. Un MSP que es el único que sabe cómo está montado todo crea una dependencia peligrosa (el riesgo del Pilar 1). Exigir documentación y conservar los accesos clave es lo que permite cambiar de proveedor si hace falta sin quedar atrapado.
Altas, bajas, contratos, datos y permisos.
Reservas, accesos, incidencias y ocupación.
La calidad del dato condiciona las decisiones.
Dentro del stack tecnológico, hay un sistema que merece atención especial porque es el corazón del negocio: el PMS (Property Management System) o software de gestión del centro. Es donde viven los miembros, los contratos, las reservas de salas, los accesos, la facturación y, a menudo, la app de comunidad. Aunque suele ser un sistema propio del operador y gestionado por el equipo central, Operaciones lo usa a diario y depende de él para casi todo.
Para Operaciones, conocer bien el PMS es clave porque muchas tareas operativas pasan por él: dar de alta y de baja accesos, gestionar reservas de salas, consultar datos de ocupación, registrar incidencias. Un uso fluido del PMS ahorra tiempo y evita errores; un uso a medias —datos mal introducidos, funciones desaprovechadas— genera problemas que luego cuesta deshacer. La calidad de los datos del PMS depende de que quien lo usa lo haga bien.
El PMS es también la fuente de buena parte de los datos de gestión que veremos en el Pilar 9. La ocupación, el uso de salas, las incidencias, la facturación: todo nace o se refleja en el PMS. Por eso su buen uso no es solo una cuestión operativa del día a día, sino la base de un reporting fiable y de decisiones bien fundamentadas. Un centro cuyo PMS está bien alimentado tiene una imagen clara de sí mismo; uno con datos desordenados navega a ciegas.
La tecnología es el área donde más fácil es quedar a merced de un proveedor, porque es la más técnica y la que muchos profesionales de Operaciones conocen menos. Un proveedor de IT poco escrupuloso puede inflar presupuestos, vender soluciones innecesarias o alargar problemas a quien no sabe distinguir lo razonable de lo abusivo. Por eso, entender lo justo de tecnología —sin ser experto— es una protección esencial.
No se trata de saber configurar una red, sino de entender los conceptos suficientes para hacer las preguntas correctas y valorar las respuestas: qué es crítico y qué no, qué SLA es razonable, si una solución propuesta es proporcionada al problema, si un presupuesto está en línea con el mercado. Este nivel de comprensión, que este bloque busca darte, es lo que te permite supervisar al proveedor de IT con criterio en lugar de aceptar lo que diga sin más.
La otra protección es conservar el control de la información clave: las contraseñas maestras, la documentación de los sistemas, los contratos con las operadoras. Un proveedor que es el único que sabe cómo está montado todo y que controla todos los accesos crea una dependencia peligrosa. Exigir documentación, mantener los accesos críticos en manos del centro y entender lo suficiente para poder cambiar de proveedor si hace falta son las salvaguardas que evitan que la tecnología, por desconocida, se convierta en un agujero de coste y de dependencia.