[et_pb_section fb_built=\u00bb1″ admin_label=\u00bbSection\u00bb _builder_version=\u00bb4.22.0″ _module_preset=\u00bbdefault\u00bb custom_margin=\u00bb0px||0px||false|false\u00bb custom_padding=\u00bb0px||0px||false|false\u00bb locked=\u00bboff\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_row column_structure=\u00bb1_4,3_4″ _builder_version=\u00bb4.27.0″ _module_preset=\u00bbdefault\u00bb custom_padding=\u00bb50px||||false|false\u00bb custom_css_main_element=\u00bbz-index:0!important;\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_column type=\u00bb1_4″ disabled_on=\u00bbon|on|off\u00bb _builder_version=\u00bb4.22.0″ _module_preset=\u00bbdefault\u00bb custom_padding=\u00bb||||false|false\u00bb sticky_position=\u00bbtop\u00bb sticky_offset_top=\u00bb100px\u00bb sticky_limit_bottom=\u00bbsection\u00bb motion_trigger_start=\u00bbtop\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_text admin_label=\u00bbindice\u00bb _builder_version=\u00bb4.27.5″ _module_preset=\u00bbdefault\u00bb custom_margin=\u00bb||0px||false|false\u00bb custom_padding=\u00bb||14px||false|false\u00bb link_option_url=\u00bb#1″ global_colors_info=\u00bb{}\u00bb]<\/p>\n
Secciones<\/strong><\/p>\n [\/et_pb_text][\/et_pb_column][et_pb_column type=\u00bb3_4″ _builder_version=\u00bb4.27.0″ _module_preset=\u00bbdefault\u00bb custom_css_main_element=\u00bbz-index:0!important;\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_text admin_label=\u00bbseccion\u00bb module_id=\u00bb1″ module_class=\u00bbittopicscontent\u00bb _builder_version=\u00bb4.27.5″ _module_preset=\u00bbdefault\u00bb z_index=\u00bb0″ custom_margin=\u00bb0px||0px||true|false\u00bb custom_padding=\u00bb0px||0px||false|false\u00bb custom_css_main_element=\u00bbfont-family:%22Pandora-Light%22;\u00bb locked=\u00bboff\u00bb global_colors_info=\u00bb{}\u00bb]Crecer duele, como titulaba aquella serie de Kirk Cameron que solo recordamos los m\u00e1s viejos del lugar. Es una de esas verdades (la del crecimiento, no la de la vejez) que nadie menciona en las reuniones de estrategia, llenas de gr\u00e1ficos ascendentes y brindis al sol por los nuevos clientes. Pero en la trinchera de un Managed Service Provider (MSP), el crecimiento incontrolado parece m\u00e1s una asfixia lenta que una victoria<\/strong>. Existe un punto de inflexi\u00f3n en el ciclo vital de todo proveedor de servicios. Al principio, el \u00abmodo h\u00e9roe\u00bb funciona. Tienes a un par de t\u00e9cnicos geniales que saben de memoria la contrase\u00f1a del firewall del cliente A y las tarjetas perforadas del System\/370 que el cliente B no desenchufa desde el 78. As\u00ed, el servicio es personal, r\u00e1pido… y artesanal. Operar a escala es la capacidad de desacoplar el crecimiento de clientes (e ingresos) de los costes operativos<\/strong>. Pero sobre todo, implica esa tranquilidad que viene de que la mayor\u00eda de errores se han resuelto porque no se han producido en primer lugar gracias a una gesti\u00f3n proactiva y predictiva<\/strong>.<\/p>\n Es f\u00e1cil predicar desde el p\u00falpito de la teor\u00eda, lo s\u00e9, pero en la pr\u00e1ctica, escalar no es un camino cuesta abajo y tropezaremos con algunas minas<\/Strong>, algunas de las cuales habremos sembrado nosotros mismos. La adrenalina es muy adictiva y hay una cierta satisfacci\u00f3n inmediata en apagar un fuego. El cliente te lo agradece si eres r\u00e1pido, te sientes \u00fatil, has usado tus habilidades y demostrado al mando medio que la IA le sustituir\u00e1 a \u00e9l antes que a ti en el trabajo. \u00abPreg\u00fantale a Luis, que es el que sabe c\u00f3mo va eso\u00bb. Un monitor para redes, otro para backups, alguien tiene un Excel para las contrase\u00f1as infringiendo mil regulaciones y el software de ticketing es un Open Source que ya no se mantiene, porque el anterior CTO pens\u00f3 que ahorrar\u00edamos. Decir que s\u00ed a cada capricho de cada cliente es una estrategia comercial tentadora al principio, incluso v\u00e1lida, pero resulta desastrosa en lo operativo y financiero a largo plazo<\/Strong>. Cuando Homer Simpson es contratado por Hank Scorpio para optimizar sus operaciones de dominaci\u00f3n del mundo, su estrategia principal es decirle a los t\u00e9cnicos si pueden hacer m\u00e1s r\u00e1pido lo que sea que est\u00e1n haciendo. La \u00fanica incidencia<\/a> buena es la que nunca llega a abrirse como ticket. \u00daltimamente se ha popularizado la estrategia de productizaci\u00f3n de servicios y debemos tomar algunas notas de esta filosof\u00eda de negocio. La automatizaci\u00f3n no es moda, sino un juego basado en identificar tareas repetitivas de bajo valor<\/Strong> (limpieza de discos, reinicio de servicios, despliegue de parches…) y que las hagan las m\u00e1quinas<\/Strong>. Las herramientas de monitoreo y gesti\u00f3n<\/a> marcan toda la diferencia, pero no necesitamos la que tenga m\u00e1s lucecitas, sino las dise\u00f1adas para MSP que permitan f\u00e1cilmente la gesti\u00f3n multicliente<\/strong>. Ya no es cuesti\u00f3n de que no puedes gestionar lo que no puedes medir, es que tambi\u00e9n se deteriora como esa habitaci\u00f3n en la que nunca entras. Detallar todos los pasos hacia esa eficiencia operativa<\/a> convertir\u00eda este art\u00edculo en El Se\u00f1or de los Anillos. Una operaci\u00f3n a escala no debe ser una isla, sino estar conectada por vasos comunicantes con el resto de la estrategia t\u00e9cnica y sus vertientes de:<\/p>\n\n
\nDesde arriba, la canci\u00f3n es la de siempre: \u00abNo pasa nada, si conseguimos diez clientes nuevos, contratamos a dos t\u00e9cnicos m\u00e1s\u00bb. Pero la vida no funciona con cuentas tan sencillas y el crecimiento implica, necesariamente, caos impredecible y no lineal.
\nLo que con cinco clientes resulta una peque\u00f1a molestia (\u00abJavier tiene que revisar y reiniciar manualmente sus servicios cada d\u00eda, porque el usuario es la mayor fuerza destructora del universo\u00bb), con cincuenta clientes es empujar colina arriba la piedra de S\u00edsifo.
\nEscalar un MSP no consiste en acumular m\u00e1s personas<\/strong> en la batalla del Service Desk como en la Edad Media. Se trata de cambiar las reglas del juego para que el volumen de trabajo no dependa de la cantidad de activos gestionados<\/Strong>.
\nSi para duplicar facturaci\u00f3n necesitamos duplicar personal, no tenemos un negocio escalable, sino una consultora encubierta que, tarde o temprano, devorar\u00e1 su margen.<\/p>\nEl problema real del crecimiento en los MSP<\/h2>\n
\nPero llega el \u00e9xito, causa habitual de muerte en muchas iniciativas, porque eso trae m\u00e1s tickets, alertas y urgencias.
\nDe pronto, el \u00abmodo h\u00e9roe\u00bb es el cuello de botella<\/strong>.
\nEsos t\u00e9cnicos brillantes no tienen tiempo de implementar mejoras, desperdiciando su conocimiento superior en achicar agua. Adem\u00e1s, dicho conocimiento queda confinado en sus cabezas, pasando de ser genios a puntos de fallo.
\nSi Javier se pone enfermo, el cliente B entra en p\u00e1nico y ni en IBM saben ya hablar System\/370.
\nLos MSP suelen caer derribados por dise\u00f1os operativos mediocres<\/Strong>, no por falta de talento.
\nEso se debe a que operan bajo un modelo de soporte reactivo<\/Strong> y esperan a que algo se rompa para arreglarlo. A peque\u00f1a escala es manejable, a gran escala un hara-kiri.
\nCrecer sin cambiar la operativa es la forma m\u00e1s r\u00e1pida de destruir la reputaci\u00f3n que nos permiti\u00f3 crecer en primer lugar.<\/p>\nQu\u00e9 significa realmente operar un MSP a escala<\/h2>\n
\nO para que se entienda: Poder gestionar cien clientes con (casi) el mismo esfuerzo con el que gestionas diez.
\nEsa es la definici\u00f3n del mundo ideal, pero en el real la esencia es la misma, que la escala de los ingresos y clientes sea mucho mayor que la de los recursos adicionales para satisfacerlos y cumplir los SLA<\/a>.
\nEso no se consigue con magia, sino con ingenier\u00eda de procesos.
\nUna operaci\u00f3n escalable se reconoce por la calma y el silencio<\/strong>.
\nSi entramos en el NOC (Network Operations Center) de un MSP que escala bien, no veremos gente corriendo con extintores, alarmas gritando o ingenieros con un tel\u00e9fono en cada oreja, preguntando si ha probado a apagar y encender de nuevo.
\nVeremos paneles de control, m\u00e9tricas de tendencias y t\u00e9cnicos trabajando en proyectos de mejora para aumentar a\u00fan m\u00e1s esa escala, su propia satisfacci\u00f3n y la del cliente.
\nLa escalabilidad real implica evolucionar desde la artesan\u00eda a la industria<\/Strong> y:<\/p>\n\n
Cu\u00e1les son los principales frenos a la escalabilidad operativa<\/h2>\n
\nPara esquivarlas, he aqu\u00ed patrones que se repiten en MSP estancados:<\/p>\n1. El culto al soporte reactivo<\/h3>\n
\nPero vivir de la adrenalina quema y vivir reaccionando impide la prevenci\u00f3n<\/strong>.
\nSi nuestro equipo pasa el 80% del tiempo reaccionando hoy, nadie est\u00e1 construyendo una infraestructura que evite esos incendios ma\u00f1ana.<\/p>\n2. La dependencia del conocimiento personal y los genios de siempre<\/h3>\n
\nHe ah\u00ed la sentencia de muerte de la escalabilidad y otra gota que colma el vaso de Luis que, entre marr\u00f3n y marr\u00f3n, actualiza el curr\u00edculum.
\nSi el conocimiento no est\u00e1 en una Wiki o Base de Conocimiento actualizada y completa, tendremos rotaci\u00f3n de personal a Warp 8 y que la formaci\u00f3n de los nuevos sea eterna.<\/p>\n3. Herramientas fragmentadas<\/h3>\n
\nLa ausencia de una \u00abfuente \u00fanica de verdad\u00bb obliga a los t\u00e9cnicos a saltar entre consolas, perdiendo contexto y tiempo en cada cambio.
\nSin visi\u00f3n centralizada, la automatizaci\u00f3n es imposible.<\/Strong><\/p>\n4. Falta de estandarizaci\u00f3n (el s\u00edndrome del \u00abtraje a medida\u00bb)<\/h3>\n
\nSi cada cliente tiene una configuraci\u00f3n de backup distinta y una pol\u00edtica de seguridad \u00fanica, estaremos gestionando excepciones constantemente sin poder automatizar nada<\/Strong>.<\/p>\nLos pilares de una operaci\u00f3n MSP a escala<\/h2>\n
\nEstos aprietan los dientes y se afanan, pero esa estrategia dura cinco minutos.
\nPara salir del ciclo de reactividad y construir una operaci\u00f3n capaz de crecer, debemos conseguir:<\/p>\n1. Una reducci\u00f3n del soporte reactivo implementando detecci\u00f3n temprana<\/h3>\n
\nLa monitorizaci\u00f3n moderna no debe limitarse a decirnos si un servidor est\u00e1 ca\u00eddo (algo f\u00e1cil que siempre llega tarde), debe avisarnos cuando los patrones de uso indiquen que se va a caer<\/strong> en dos horas.
\nDetectar la degradaci\u00f3n del servicio antes que el cliente es la \u00fanica forma de proteger los SLA<\/Strong> y la salud card\u00edaca del equipo.<\/p>\n2. Estandarizaci\u00f3n t\u00e9cnica y de procesos<\/h3>\n
\nIdealmente, tendr\u00edamos que vender productos, no proyectos, ya que los primeros escalan por naturaleza, mientras que los segundos no.
\nDefinir un stack tecnol\u00f3gico est\u00e1ndar y unas pol\u00edticas de configuraci\u00f3n base <\/Strong>para todos los clientes permite scripts y procesos de mantenimiento que sirven para 500 m\u00e1quinas igual que para 5.
\nLa estandarizaci\u00f3n es el prerrequisito de la automatizaci\u00f3n, tomando tambi\u00e9n nota de c\u00f3mo lo hacen McDonalds y Burger King.
\nEstos tienen tan estandarizados sus procesos, que el hecho de que alguien se vaya y lo sustituya un novato no cambia el sabor de las patatas, porque estas siempre se hacen igual. El nuevo solo tiene que seguir pasos ya definidos conforme a las mejores pr\u00e1cticas.<\/p>\n3. Automatizaci\u00f3n con impacto real<\/h3>\n
\nEsa automatizaci\u00f3n tiene un impacto medible: horas de t\u00e9cnico liberadas<\/Strong>.
\nSi un bot basado en un LLM bien entrenado puede resolver el 30% de los tickets sencillos de nivel 1, escalaremos un 30% sin contratar a nadie.<\/p>\n4. Herramientas adaptadas, no solo modernas<\/h3>\n
\nLa segregaci\u00f3n de datos, los permisos granulares y la capacidad de aplicar pol\u00edticas globales o espec\u00edficas por cliente son funciones cr\u00edticas para no perder el control si escalamos de 10 a 100.<\/p>\n5. Medici\u00f3n continua y obsesiva<\/h3>\n
\nEso s\u00ed, hay que medir las cosas correctas, no las que acarician el ego<\/Strong>.
\nNo importa cu\u00e1ntos tickets cerremos, importa cu\u00e1ntos recibimos por endpoint. Igual que importa el tiempo medio de resoluci\u00f3n (MTTR) real y la rentabilidad por cliente.
\nUna operaci\u00f3n a escala se gobierna con datos, no con sensaciones<\/strong>. O vibes, como est\u00e1 de moda ahora.<\/p>\nEl camino hacia la eficiencia operativa<\/h2>\n
\nPor eso, hemos creado un cluster de contenidos, tratando en detalle las \u00e1reas clave donde se juega la batalla de la escalabilidad en un MSP y que tratan sobre c\u00f3mo:<\/p>\n\n
La escalabilidad y su relaci\u00f3n con otros \u00e1mbitos clave del MSP<\/h2>\n
\n