[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]En el episodio \u00abThe Trouble with Tribbles\u00bb de la serie original de Star Trek, la tripulaci\u00f3n del Enterprise descubre que unas peque\u00f1as y adorables criaturas peludas se reproducen como conejos, desbordando cualquier capacidad de gesti\u00f3n. Enseguida aparecen por todas partes, colapsando sistemas y poniendo de los nervios incluso a Spock. No es dif\u00edcil ver la analog\u00eda con un MSP<\/a> que crece con nuevos clientes, pero no cambia su forma de funcionar<\/Strong>. La respuesta autom\u00e1tica ante el crecimiento suele ser contratar m\u00e1s personal. Es comprensible porque es una acci\u00f3n instintiva, predecible y, sobre todo, no exige la incomodidad de replantearnos c\u00f3mo hacemos las cosas<\/Strong>. A nadie le gusta mirarse en el espejo y darse cuenta de que debe cambiar la forma de hacer las cosas<\/Strong>, pero si queremos escalar las operaciones, no hay otro remedio<\/Strong>. Y ahora que conocemos al enemigo, pasemos a lo importante, la pr\u00e1ctica. Vayamos por pasos.<\/p>\n Si hay un principio que separa a los MSP que escalan de los que no, es la estandarizaci\u00f3n. No como eslogan de Powerpoint, sino como condici\u00f3n operativa previa a cualquier otra mejora<\/strong> en esa manera de hacer las cosas. La estandarizaci\u00f3n no elimina la flexibilidad<\/Strong>, define una l\u00f3gica com\u00fan con par\u00e1metros personalizables por cliente. La automatizaci\u00f3n sin estandarizaci\u00f3n es potencia sin control: libera mucha energ\u00eda, pero en todas las direcciones, lo que no permite avanzar en ninguna. Con una base estandarizada, tendremos una categor\u00eda de tareas que no deber\u00edan tocar manos humanas, como por ejemplo:<\/p>\n Todo aquello que tiene una l\u00f3gica predecible y un resultado conocido es candidato a la automatizaci\u00f3n<\/strong>. Tras estandarizar y automatizar es hora de gestionar el ruido para seguir escalando las operaciones de nuestro MSP sin necesidad de m\u00e1s t\u00e9cnicos. La gesti\u00f3n de eventos<\/a> debe orientarse a la tendencia y al impacto, no al evento aislado<\/Strong>. En las guerras antiguas, el problema era la comunicaci\u00f3n. Mensajeros que corr\u00edan de ac\u00e1 para all\u00e1 desde distintas partes de la batalla llevando y trayendo \u00f3rdenes bajo fuego enemigo que, cuando se ejecutaban (en caso de llegar, claro), ya estaban obsoletas. Idealmente, esto significa un dashboard global, pero que permita hacer zoom y bajar al detalle de un cliente espec\u00edfico sin cambiar de herramienta<\/Strong>. No debemos valorar la eficiencia operativa<\/a> de un MSP con m\u00e9tricas como tickets cerrados u horas de t\u00e9cnico facturadas. Eso es seguir midiendo el pasado, cuando tenemos que evaluar si los cambios en nuestra forma de operar est\u00e1n produciendo mejoras o, simplemente, absorbemos m\u00e1s carga con el mismo caos. Pandora FMS se dise\u00f1\u00f3 entendiendo el problema operativo del MSP desde dentro porque lo sufrimos<\/strong>. Porque lo vivimos, porque venimos de esas trincheras en el barro, no de las alturas te\u00f3ricas donde todo suena bien. En el n\u00facleo de todo ello est\u00e1 la capacidad de correlaci\u00f3n de eventos de Pandora FMS y la de predicci\u00f3n basada en tendencias<\/strong>, que permiten detectar incidencias<\/A> antes de que impacten en el cliente, convirtiendo el soporte reactivo<\/a> en una operaci\u00f3n realmente proactiva. Habla con el equipo de ventas, pide presupuesto, o resuelve tus dudas sobre nuestras licencias<\/p>\n \u00bb content_phone=\u00bb<\/p>\n Habla con el equipo de ventas, resuelve tus dudas sobre nuestras licencias o pide presupuesto<\/p>\n \u00bb content_last_edited=\u00bbon|tablet\u00bb _builder_version=\u00bb4.22.0″ _module_preset=\u00bbdefault\u00bb header_2_font_size=\u00bb2em\u00bb text_orientation=\u00bbcenter\u00bb module_alignment=\u00bbleft\u00bb custom_margin=\u00bb0px||20px||false|false\u00bb custom_padding=\u00bb0px||0px||true|false\u00bb global_colors_info=\u00bb{}\u00bb]<\/p>\n Habla con el equipo de ventas, pide presupuesto, [\/et_pb_text][et_pb_code _builder_version=\u00bb4.27.4″ _module_preset=\u00bbdefault\u00bb width=\u00bb200px\u00bb module_alignment=\u00bbcenter\u00bb custom_margin=\u00bb40px||0px||false|false\u00bb custom_padding=\u00bb0px||0px||true|false\u00bb locked=\u00bboff\u00bb global_colors_info=\u00bb{}\u00bb]<\/p>\n\n
\nLos tickets se reproducen como tribbles, los t\u00e9cnicos gestionan con la lengua fuera y lo que al principio era adorable (por el crecimiento de facturaci\u00f3n) enseguida muta a una crisis de gesti\u00f3n sin salida aparente.<\/p>\nPor qu\u00e9 escalar un MSP no consiste en contratar m\u00e1s t\u00e9cnicos<\/h2>\n
\nSi tenemos veinte clientes nuevos y contratamos a un par de t\u00e9cnicos, la ecuaci\u00f3n parece cuadrada, diez para cada uno. Hasta que la realidad se empe\u00f1a en no ser lineal<\/Strong> y los m\u00e1rgenes se estrechan como esas paredes trampa de las pel\u00edculas, que se cierran sobre nosotros.
\nY no quiero sacar a pasear t\u00e9rminos de Econom\u00eda como a veces hago, pero estas soluciones que consisten en meter m\u00e1s componentes en un sistema que no cambia produce enseguida rendimientos decrecientes<\/Strong>.
\nPorque la clave y la restricci\u00f3n no suelen estar en la falta de personal, sino en el modelo operativo<\/Strong>.
\nEn las herramientas desconectadas entre s\u00ed, las tareas manuales que no nos hemos molestado en automatizar, el aluvi\u00f3n de alertas descontextualizadas que nadie filtra, la falta de est\u00e1ndares que obliga a tratar cada cliente como si fuera el primero…
\nA\u00f1adir t\u00e9cnicos sin corregir esas disfunciones solo escala el caos<\/Strong>, haci\u00e9ndolo m\u00e1s caro sin convertirlo en m\u00e1s eficiente.<\/p>\nQu\u00e9 impide operar cientos de clientes con el mismo equipo<\/h2>\n
\nEn nuestra experiencia, estos son los obst\u00e1culos m\u00e1s habituales en la operativa de un MSP que impiden escalar las operaciones de manera \u00f3ptima. Deber\u00edamos examinar honestamente cu\u00e1ntos nos suenan familiares.<\/p>\n\n
Estandarizaci\u00f3n: La piedra angular de la escalabilidad en un MSP<\/h3>\n
\nEste es el primer paso a aplicar en la pr\u00e1ctica<\/strong>.
\nNo podemos operar cientos de clientes con eficiencia si cada t\u00e9cnico hace la guerra por su cuenta. La variabilidad destruye la posibilidad de automatizar, documentar, formar y\/o predecir<\/strong>. Convierte cada incidencia en un caso \u00fanico y cada t\u00e9cnico en un especialista imprescindible con su particular libro de trucos.
\nY el d\u00eda que decide marcharse, se lleva consigo meses de conocimiento intransferible<\/strong>.
\nEstandarizar servicios<\/A> significa construir un cat\u00e1logo homog\u00e9neo con:<\/p>\n\n
\nAs\u00ed, la inevitable diversidad operativa real se gestiona dentro de un marco controlado<\/strong> y auditable.<\/p>\nLa automatizaci\u00f3n y reducci\u00f3n del trabajo manual<\/h3>\n
\nPor eso:<\/p>\n\n
\n
\nEl impacto de estandarizar y automatizar se mide en horas de t\u00e9cnico liberadas<\/strong>.
\nSi la monitorizaci\u00f3n de infraestructura<\/a> es capaz de detectar que un servicio cojea, reiniciarlo, verificar que ha recuperado su funcionamiento normal y cerrar la incidencia sin intervenci\u00f3n humana, el cliente no percibe degradaci\u00f3n. As\u00ed, el SLA se cumple y el t\u00e9cnico que antes hac\u00eda eso dedica su tiempo a fingir que trabaja en algo importante.
\nEse es el camino real para reducir las horas de soporte sin sacrificar los compromisos contractuales<\/a>.<\/p>\nReducir el ruido y mejorar la priorizaci\u00f3n<\/h3>\n
\nUn sistema que grita alerta en cada variaci\u00f3n de CPU, pico de memoria o latencia moment\u00e1nea condiciona a los t\u00e9cnicos a ignorar el panel por culpa de todo ese ruido.
\nEso es lo contrario de lo que necesitamos porque protagonizamos el cuento de Pedro y el lobo versi\u00f3n IT: Cuando llega el fallo real, nadie est\u00e1 mirando<\/Strong>.
\nOperar cientos de clientes con eficiencia exige trabajar por excepci\u00f3n, no por volumen<\/strong> de avisos, para as\u00ed reducir falsos positivos y alertas innecesarias. Para ello, debemos meter mano al sistema de alertas en nuestra monitorizaci\u00f3n, aplicando buenas pr\u00e1cticas como:<\/p>\n\n
\nAs\u00ed, un pico de CPU durante un backup nocturno no merece atenci\u00f3n humana, es normal. Una degradaci\u00f3n progresiva del rendimiento de un servidor de producci\u00f3n durante tres d\u00edas consecutivos hay que mirarla, aunque ning\u00fan umbral est\u00e1tico la haya marcado todav\u00eda.<\/p>\nVisibilidad centralizada para m\u00faltiples clientes<\/h3>\n
\nGestionar a escala sin visibilidad centralizada es ser esos generales del pasado, visualizando el campo de batalla lleno de humo desde puestos de mando separados, sin comunicaci\u00f3n entre ellos y con planos distintos para cada sector (cliente) de la guerra diaria.
\nPosible t\u00e9cnicamente hablando, pero una cat\u00e1strofe anunciada en la pr\u00e1ctica.
\nUn NOC<\/a> funcional para un MSP necesita monitorizaci\u00f3n TI<\/A> centralizada, un punto de control \u00fanico que permita ver el estado de todos los clientes desde una sola consola, con:<\/p>\n\n
\nCon eso, obtendremos una visi\u00f3n consolidada de disponibilidad, eventos activos, inventario y tendencias de rendimiento.
\nSin ese Palantir que permita observar cada rinc\u00f3n de nuestra Tierra Media IT particular, cada cambio de contexto entre clientes consume tiempo, carga cognitiva y aumenta el riesgo de que algo importante pase desapercibido.
\nY ahora que ya sabemos qu\u00e9 hacer y en qu\u00e9 orden, \u00bfC\u00f3mo sabemos si lo estamos implementando bien?
\nMidiendo<\/strong>.<\/p>\nQu\u00e9 m\u00e9tricas indican que un MSP est\u00e1 escalando bien<\/h2>\n
\nPara averiguar si la optimizaci\u00f3n de nuestras operaciones sigue un buen rumbo podemos emplear m\u00e9tricas como:<\/p>\n\n
C\u00f3mo ayuda Pandora FMS a operar cientos de clientes con el mismo equipo<\/h2>\n
\nPor eso no creamos una herramienta de monitorizaci\u00f3n gen\u00e9rica adaptada a posteriori, sino algo que aliviara nuestro propio dolor y que compartimos porque pensamos que pod\u00eda aliviar el de otros<\/strong>.
\nEsa diferencia de origen se traduce en funcionalidades que responden directamente a los retos de la escala con m\u00faltiples clientes<\/strong>.
\nAs\u00ed, la monitorizaci\u00f3n MSP<\/A> con Pandora FMS se construye sobre:<\/p>\n\n
\nEvitar que ese soporte reactivo consuma el margen y el tiempo del equipo es uno de nuestros objetivos centrales que durante el dise\u00f1o y el desarrollo continuo de la herramienta.
\nY luego est\u00e1 el omnipresente tema de la seguridad, claro.
\nPara ella, Pandora SIEM complementa este escenario<\/strong> en los entornos donde dicha seguridad operativa forma parte del servicio, aportando tambi\u00e9n correlaci\u00f3n de eventos de seguridad y visibilidad unificada<\/strong> en entornos h\u00edbridos y heterog\u00e9neos.
\nLa visi\u00f3n consolidada (paneles por cliente, vista multicliente, reporting autom\u00e1tico…) permite que un equipo de tama\u00f1o razonable no colapse ante el crecimiento, sino que lo gestione con calma y datos<\/strong>, no con estr\u00e9s y (m\u00e1s) caf\u00e9ina.
\nComo hemos visto, un MSP escala cuando convierte su operaci\u00f3n en un sistema repetible, automatizable y medible, no cuando alista legiones de ingenieros nuevos que no caben en los s\u00f3tanos en los que los encerramos a pan y agua.
\nPero eso precisa cambios en la forma de actuar<\/strong>, algo a lo que no debemos resistirnos, sino implementar siguiendo los pasos del mapa dibujado aqu\u00ed.
\nAs\u00ed, gestionar cientos de clientes con el mismo equipo t\u00e9cnico no es un truco, ni promesa de vendedor.
\nEs el resultado inevitable de construir una operaci\u00f3n que funciona como un reloj suizo.
\nQuien entiende eso deja de buscar t\u00e9cnicos dispuestos a apretar los dientes y empieza a buscar sistemas capaces de hacer m\u00e1s. Ah\u00ed radica la diferencia entre un MSP que crece y uno que simplemente engorda.[\/et_pb_text][et_pb_button button_url=\u00bb@ET-DC@eyJkeW5hbWljIjp0cnVlLCJjb250ZW50IjoicG9zdF9saW5rX3VybF9wYWdlIiwic2V0dGluZ3MiOnsicG9zdF9pZCI6IjM2MjI3MCJ9fQ==@\u00bb button_text=\u00bb\u2190 Regresar a IT Topics\u00bb button_alignment=\u00bbleft\u00bb _builder_version=\u00bb4.22.0″ _dynamic_attributes=\u00bbbutton_url\u00bb _module_preset=\u00bbdefault\u00bb custom_button=\u00bbon\u00bb button_text_size=\u00bb1em\u00bb button_text_color=\u00bb#0C312F\u00bb button_bg_color=\u00bb#FFFFFF\u00bb button_bg_color_gradient_direction=\u00bb90deg\u00bb button_bg_color_gradient_stops=\u00bb#82B92E 0%|#3CB92E 100%\u00bb button_bg_color_gradient_start=\u00bb#82B92E\u00bb button_bg_color_gradient_end=\u00bb#3CB92E\u00bb button_border_width=\u00bb1px\u00bb button_border_color=\u00bb#eaeaea\u00bb button_border_radius=\u00bb100px\u00bb button_use_icon=\u00bboff\u00bb z_index=\u00bb0″ custom_margin=\u00bb60px||0px||false|false\u00bb custom_padding=\u00bb10px|50px|10px|50px|true|true\u00bb custom_padding_tablet=\u00bb\u00bb custom_padding_phone=\u00bb10px|20px|10px|20px|true|true\u00bb custom_padding_last_edited=\u00bbon|phone\u00bb custom_css_main_element=\u00bbright:0!important;||font-family:%22Pandora-Bold%22!important;\u00bb global_module=\u00bb367749″ locked=\u00bboff\u00bb global_colors_info=\u00bb{}\u00bb button_bg_color__hover_enabled=\u00bbon|desktop\u00bb button_bg_color_gradient_start__hover=\u00bb#eaeaea\u00bb button_bg_color_gradient_end__hover=\u00bb#f4f4f4″ button_bg_color__hover=\u00bb#eaeaea\u00bb button_bg_enable_color__hover=\u00bbon\u00bb button_bg_use_color_gradient__hover=\u00bbon\u00bb button_bg_color_gradient_stops__hover=\u00bb#eaeaea 0%|#f4f4f4 100%\u00bb][\/et_pb_button][\/et_pb_column][\/et_pb_row][\/et_pb_section][et_pb_section fb_built=\u00bb1″ custom_padding_last_edited=\u00bbon|desktop\u00bb admin_label=\u00bbFinal CTA\u00bb _builder_version=\u00bb4.27.0″ _module_preset=\u00bbdefault\u00bb background_color=\u00bb#161327″ use_background_color_gradient=\u00bbon\u00bb background_color_gradient_stops=\u00bbrgba(22,19,39,0.5) 17%|rgba(22,19,39,0.5) 100%\u00bb background_color_gradient_overlays_image=\u00bbon\u00bb background_image=\u00bbhttps:\/\/pandorafms.com\/wp-content\/uploads\/2023\/12\/banner-contacta-it-topics.webp\u00bb background_size=\u00bbcustom\u00bb background_image_width=\u00bb121%\u00bb background_image_height=\u00bb192%\u00bb background_position=\u00bbtop_left\u00bb z_index=\u00bb1″ max_width=\u00bb1080px\u00bb max_width_tablet=\u00bb98%\u00bb max_width_phone=\u00bb98%\u00bb max_width_last_edited=\u00bbon|tablet\u00bb module_alignment=\u00bbcenter\u00bb custom_margin=\u00bb80px||80px||true|false\u00bb custom_padding=\u00bb40px|20px|120px|20px|false|true\u00bb custom_padding_tablet=\u00bb40px|0px|120px|0px|false|true\u00bb custom_padding_phone=\u00bb40px|0px|120px|0px|false|true\u00bb scroll_scaling=\u00bb40|55|85|100|100%|120%|100%\u00bb motion_trigger_start=\u00bbtop\u00bb background_last_edited=\u00bbon|phone\u00bb background_size_tablet=\u00bbcover\u00bb background_size_phone=\u00bbcover\u00bb background_position_phone=\u00bbtop_center\u00bb border_radii=\u00bboff|20px|20px|20px|20px\u00bb border_color_all=\u00bb#ffffff\u00bb box_shadow_style=\u00bbpreset1″ box_shadow_vertical=\u00bb0px\u00bb box_shadow_blur=\u00bb80px\u00bb box_shadow_color=\u00bb#506da0″ global_module=\u00bb367449″ saved_tabs=\u00bball\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_row use_custom_gutter=\u00bbon\u00bb gutter_width=\u00bb2″ make_equal=\u00bbon\u00bb _builder_version=\u00bb4.22.0″ _module_preset=\u00bbdefault\u00bb max_width=\u00bb750px\u00bb module_alignment=\u00bbcenter\u00bb custom_margin=\u00bb0px||0px||true|false\u00bb custom_padding=\u00bb0px|0px|0px|0px|true|true\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_column type=\u00bb4_4″ _builder_version=\u00bb4.22.0″ _module_preset=\u00bbdefault\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_text content_tablet=\u00bb<\/p>\n
o resuelve tus dudas sobre nuestras licencias<\/p>\n