Cómo definir políticas técnicas según el tipo de cliente en un MSP

La tecnología suele excitar la imaginación con escenarios utópicos, como una automatización total al estilo Star Trek o, para el tema que nos ocupa, la estandarización. Así, cuando los MSP deciden (por fin) poner en orden sus operaciones, anhelan un único modelo técnico aplicable a todos los clientes. Pero el sueño choca contra la realidad en el minuto uno y la realidad siempre gana. Entonces, nos damos cuenta de que tratar igual a clientes distintos es homogeneizar mal en lugar de estandarizar.
Y genera tanto ruido como el caos que pretendíamos eliminar.
Cuando estandarizamos, tendemos a intentar borrar diferencias, pero la clave es agrupar bien las que se parecen para construir marcos repetibles.
Por eso el primer paso de una buena estandarización en un MSP es segmentar adecuadamente, de modo que vamos a profundizar en cómo homogeneizar las operaciones sin que el precio supere al beneficio.

Por qué tratar a todos los clientes de la misma forma genera problemas

Cuando aplicamos la misma política técnica a una gestoría de barrio con cinco personas y al hospital de la comarca, ese modelo único falla por los dos extremos a la vez, el peor tipo de incendio.
Por el extremo superior erramos al sobre-monitorizar a los clientes sencillos con el mismo arsenal de chequeos, umbrales y comprobaciones cada diez segundos que merece una infraestructura crítica. Estamos cogiendo el Ferrari para ir a Mercadona y el resultado es un tsunami de avisos irrelevantes. Ahí descubrimos que el exceso de alertas es como el exceso actual de anuncios, la forma más rápida de condicionar a un equipo a ignorar avisos, incluidos los que importan.
Por abajo nos quedamos cortos con los clientes críticos. Las políticas pensadas para no ahogar en irrelevancia al pequeño cliente son demasiado laxas para quien no puede permitirse ni dos minutos de caída. Aquí la cuestión es la falta de cobertura y es mucho peor que el ruido, porque el disgusto se nota tarde y, cuando acudimos, el tumor ha hecho metástasis y tenemos un problema grave.
Y entre esos dos extremos también se queda a vivir una factura silenciosa que pagamos en forma de:

• Consumo innecesario de tiempo, yendo tras falsos positivos con el cazamariposas por entornos que no lo necesitaban.
• Dificultad para justificar el servicio y su coste, porque cuando todos los clientes pagan lo mismo, el crítico siente que paga de más y el sencillo que no recibe nada especial. Y aunque trabajemos en IT con silicio y cables, los sentimientos del cliente mandan.
• Una merma de eficiencia operativa que crece con cada cliente nuevo que conseguimos, en lugar de diluirse, como sería lo esperado con una buena estandarización.

El modelo único, en definitiva, es tan cómodo de dibujar en la pizarra como carísimo de operar en la trinchera cotidiana.

Qué variables sirven para segmentar clientes en un MSP

Entonces, ¿cómo enfocamos la estandarización? Ya hice spoiler de que el primer paso es la segmentación y aquí por fin hay una buena noticia, no hace falta inventarse las categorías a ojo.
Existen criterios objetivos que permiten una segmentación de clientes MSP profesional y útil, como:

• Criticidad del negocio: ¿qué pasa, de verdad, si su sistema se cae una hora? La asesoría puede dedicarse a otras cosas o aprovechar para un café, pero el hospital no, como tampoco un e-commerce cuando amanece el Black Friday.
• Tamaño del entorno: ¿tenemos un jardín de diez endpoints o una selva de tres mil? El volumen cambia las reglas del juego y es factor clave en la segmentación.
• Madurez técnica: ¿tiene nuestro cliente un equipo propio que comprende lo que monitorizamos o somos su único departamento de IT y la tecnología le parece magia?
• Obligaciones de seguridad o compliance: un cliente sujeto a normativa draconiana, como una empresa dentro de un sector considerado estratégico por ley, no admite las mismas políticas de retención o auditoría que la zapatería de la esquina.
• Complejidad de la infraestructura: porque gestionaremos entornos homogéneos como una llanura (ojalá), pero también arquitecturas híbridas con nube, virtualización y media docena de tecnologías peleando a codazos por los recursos.
• Tipo de servicio contratado: la ley última del territorio es lo que haya firmado, así que lo que el cliente nos ha comprado marca, lógicamente, hasta dónde llega nuestra responsabilidad.
• Nivel de disponibilidad esperado, que casi siempre acaba escrito en un SLA (Service Level Agreement) y conviene respetar, porque más abajo también suelen estar escritas las penalizaciones por incumplimiento.

En definitiva, la Primera Directiva de Star Trek, por la cual la Flota Estelar no interviene igual en todos los mundos. Su actuación viene dada por el grado de desarrollo de cada civilización, ya que aplicar la misma receta a una cultura preindustrial y a otra capaz de doblar el espacio tiene consecuencias funestas cada dos episodios.
Nuestra segmentación de clientes debe ser igual y ojalá el criterio pudiera ser nuestra comodidad implantando lo mismo para todos, pero la madurez y el contexto real de cada cliente mandan.

Qué políticas técnicas suelen necesitar adaptación por tipología

En la vida real no podemos segmentar cada detalle y, por higiene operativa (y cordura del equipo), hay decisiones que conviene mantener idénticas para todos.
Pero hay una serie de políticas técnicas que sí deberemos adaptar necesariamente según el tipo de cliente en un MSP.
Son aquellas donde un modelo único nos causaría más dolor e incluyen:

• Las políticas de monitorización MSP: es decir, qué se vigila y con qué profundidad en cada entorno. Esto es imposible de unificar, así que mejor no molestarse en intentarlo y segmentar bien desde el principio.
• Los umbrales de alerta, que en un cliente crítico deben saltar antes y en uno sencillo solo cuando hay motivo real.
• La frecuencia de comprobaciones, porque los parámetros de una tienda de tres personas probablemente no necesitarán medirse al segundo.
• El reporting, que para un cliente técnico será detallado y para un gerente, un resumen legible que no le parezca un jeroglífico.
• Las automatizaciones permitidas, ya que no en todos los entornos podemos (no debemos más bien) dejar que el sistema actúe solo.
• Las ventanas de mantenimiento, ya que estarán condicionadas por la actividad y el horario de cada negocio.
• El escalado y la respuesta ante incidencias, que deben estar alineados con la criticidad y el SLA que hayamos firmado.

La moraleja es que, mientras que la lógica operativa puede ser la misma para clientes diversos, los parámetros que le otorgan su forma final deben estar adaptados.
De hecho, confundir lógica con parámetros es el origen de demasiados líos en estandarización.

Cómo estandarizar sin crear una excepción distinta por cliente

Llegamos al quid de la cuestión, porque entre el modelo único idéntico y que «cada cliente es un copo de nieve especial» hay un término medio en el que vive la estandarización MSP que funciona.
Este punto de equilibrio toma la forma de estandarizar por grupos.
La casilla uno es definir tiers o grupos operativos, un puñado reducido de categorías que constituyen los famosos service tiers de un MSP, en los que encajan clientes con necesidades parecidas.
Deberíamos tener entre tres y cinco como mucho.
Una vez definidos los grupos, construimos sobre ellos plantillas por tipología, que son políticas técnicas completas y validadas, listas para desplegar.
Y donde la plantilla no llega, parametrizamos.
Con eso tenemos lo mejor de los dos mundos. La lógica del tier es común y el valor concreto del umbral, ventana de mantenimiento o destinatario del informe se lee de la configuración personalizada de cada cliente.
Así alcanzamos el equilibrio entre uniformidad y flexibilidad, con una misma columna vertebral, pero distintos ajustes finos.
Esta es, por cierto, la diferencia entre estandarizar servicios de verdad y acumular scripts artesanales que solo entiende quien los escribió.
A partir de ahí, la palabra clave es disciplina, la cual implementamos…

• Limitando las excepciones. Una puntual es un parche necesario, vale, pero veinte excepciones son un nuevo tier mal disfrazado que conviene formalizar o eliminar.
• Documentando las reglas comunes, para que el conocimiento viva en el sistema y no en las poco fiables neuronas del técnico de guardia al que la competencia está tentando.
• Revisando el encaje real de cada cliente periódicamente, porque los clientes crecen, cambian y, a veces, hasta se mudan de grupo sin avisar.
• No dejando que el ansia de venta destruya la operación estándar. La temida frase: «Es que a este cliente le prometimos algo especial» por parte del equipo comercial, es el agujero por el que se desangran muchas operaciones MSP perfectamente diseñadas.

Pero bien hecho, esto es lo que permite operar cientos de clientes con el mismo equipo técnico sin morir en el intento.

Los errores más frecuentes al diseñar políticas por tipología

IT es una mazmorra de Dungeons & Dragons, el camino está lleno de trampas y, cuando se trata del diseño de políticas en un MSP, la mayoría nacen de pasarnos de listos.
En nuestra experiencia de varias décadas ya desde la creación de Pandora, los errores que más hemos visto repetirse son:

• Crear demasiadas categorías. Si tenemos un tier por cada cliente hemos creado el mismo caos de siempre con otro nombre y eso no sirve de nada, recordemos la disciplina del párrafo anterior.
• Personalizar demasiado pronto, antes de saber si esa necesidad especial es real o un capricho que se evapora en tres meses.
• No revisar la rentabilidad operativa de cada tier. Hay grupos que dan más trabajo del que facturan y eso hay que detectarlo antes de que la herida desangre la cuenta de resultados.
• Arrastrar políticas heredadas sin criterio, como configuraciones que nadie recuerda por qué están ahí, pero todos temen tocar.
• Mezclar requisitos comerciales con operativos. O dicho de otra manera, meter en la misma caja lo que vendimos y lo que tiene sentido técnicamente. Cualquiera con una mínima experiencia en IT sabe que cualquier parecido de la utopía de venta con la realidad técnica es mera coincidencia, así que hemos de controlar muy bien esa vía de tren, para que el marketing no nos descarrile el trabajo con promesas que no valen nada, como en la canción.
• No adaptar alertas y automatizaciones al contexto, dejando que un tier herede el ruido de otro, que no se parece en nada.

Estos tropiezos son primos de los que ya describí al hablar de los errores al automatizar procesos en un MSP y casi siempre se resumen en una dolencia llamada exceso de complejidad disfrazado de rigor.

Qué cambia cuando un MSP segmenta sus políticas con criterio

Cuando la operación multicliente de un MSP deja de tratar a todos igual y empieza a agrupar contextos parecidos, el cambio se nota rápido (para bien) y en efectos concretos como:

• Más coherencia operativa: dado que el mismo tipo de cliente recibe el mismo tipo de servicio, esté quien esté a los mandos del servicio ese turno.
• Menos ruido, porque cada tier alerta de lo que le corresponde sin crear bullicio con lo que en realidad sobra.
• Mejor alineación entre servicio y criticidad: consiguiendo el equilibrio entre egos y billeteras porque el cliente crítico recibe lo que paga y el más sencillo no paga por lo que no necesita.
• Automatización más segura, al permitir que el sistema actúe solo donde el contexto lo admite y no en todas partes por igual, configurando una cosa mientras desconfigura cien.
• Mejor reutilización de plantillas, que podremos desplegar en clientes nuevos similares con apenas unos retoques.
• Escalabilidad real, esa en la que gestionar mil dispositivos no cuesta mil veces más que gestionar uno.

Cómo ayuda Pandora FMS a aplicar políticas técnicas por tipo de cliente

No sé si queda algún rincón en IT donde la estrategia adecuada, como la que hemos desglosado, se puede implementar en la práctica sin herramientas profesionales. Hace mucho que dejamos de ser artesanos y aquí es donde Pandora FMS y Pandora SIEM hacen que el modelo de tiers pueda convertirse en una realidad práctica en lugar de quedarse en PowerPoint.
Para empezar, porque nos permite trabajar con plantillas y políticas reutilizables, la columna principal de la estrategia.
Así, definimos la lógica de cada tier una vez y se aplica a todos los clientes que encajan en ese grupo, heredando la configuración de forma automática.
Esa segmentación por grupos es nativa, de modo que cada contrato conseguido y cada tier viven ordenados y aislados, con la parametrización por cliente que permite ajustar umbrales o ventanas, sin alterar la estructura ni romper la plantilla base.
Y por encima de todo eso sobrevuela una monitorización de la infraestructura centralizada, un águila capaz de ver a su presa a kilómetros desde nuestra Metaconsola. Ella es el ansiado single pane of glass con el que contemplar toda la operación multicliente, sin saltar de consola en consola y cumpliendo nuestras fantasías de dominación.
Junto a eso tenemos:

• Dashboards e informes adaptables al perfil de cada cliente.
• Control de eventos y alertas afinadas por tier.
• Una capa de seguridad con Pandora SIEM para quienes arrastran obligaciones de compliance (que el cliente sencillo ni se plantea ni necesita).

En definitiva, justo lo necesario que ha sido probado en clientes y operaciones reales, para detectar incidencias antes de que impacten al cliente y reducir las horas de soporte sin afectar al SLA.
Recapitulemos lo fundamental.
La realidad es que un MSP no escala tratando a todos sus clientes de la misma forma, aunque no sea muy diplomático decirlo.
La llave del crecimiento real tiene forma de agrupación de contextos que se parecen y aplicación de políticas repetibles, que respeten sus diferencias reales sin multiplicar excepciones.
Estandarizar de forma óptima es domesticar la variedad sin eliminarla y sin dejar que esta nos arrastre como un caballo desbocado. Es pasar del caos artesanal donde cada cliente es un mundo (bonita e impracticable filosofía) a un puñado de marcos claros donde cada cliente tiene su sitio.
Así ascenderemos al Olimpo de los MSP que sobreviven sin sumar desastres hasta que no quedan manos para remediarlos.