Formación y soporte industrial: SLAs operativos de verdad

La formación y el soporte industrial son la mitad invisible de cualquier proyecto de software de empresa: el ERP, la herramienta interna o la integración que hoy funciona bien es la que alguien mantiene, explica y repara cuando falla. Aquí encontrarás qué es un SLA operativo de verdad, cómo se definen tiempos de respuesta y resolución, qué severidades tienen sentido en un entorno de planta y cómo montar una formación por rol que la gente use de verdad.

Por qué el software vive de su soporte

Un sistema de gestión no se compra: se convive con él durante años. La puesta en marcha ocupa unos meses; la operación, una década. Y sin embargo casi toda la atención comercial, técnica y presupuestaria se concentra en la primera fase. El resultado es conocido: implantaciones correctas que se degradan porque nadie responde a las incidencias en un plazo razonable, porque los usuarios nuevos aprenden por imitación de los veteranos (con sus vicios incluidos) o porque la documentación se quedó congelada en la versión de hace tres años.

En un entorno industrial esta degradación tiene un coste directo. Si el ERP no deja confirmar una orden de fabricación, la planta no para, pero empieza a trabajar fuera del sistema: albaranes en papel, consumos apuntados en una libreta, regularizaciones el viernes. Cada hora que el sistema está caído o bloqueado genera deuda de datos que alguien tendrá que pagar después. Por eso el contrato de soporte no es un anexo administrativo: es la pieza que decide si la inversión inicial conserva su valor.

La tesis de esta guía es simple: un buen soporte se puede especificar, medir y exigir, igual que se especifica una máquina. La herramienta para hacerlo es el SLA operativo. Y su complemento imprescindible es la formación continua, porque una parte enorme de los tickets de soporte no son fallos del software, sino síntomas de usuarios que no saben usarlo.

Qué es un SLA operativo (y qué no lo es)

SLA significa Service Level Agreement, acuerdo de nivel de servicio: el documento que fija qué servicio se presta, con qué plazos, en qué horario y qué pasa cuando no se cumple. Hasta ahí la teoría. En la práctica circulan muchos documentos llamados SLA que no comprometen nada verificable.

Un SLA es operativo cuando cumple tres condiciones:

1. Es medible sin discusión. Los plazos se cuentan desde un evento registrado (la apertura del ticket) hasta otro evento registrado (la primera respuesta cualificada, la resolución). Si medir el cumplimiento exige interpretar, no hay SLA: hay una declaración de intenciones.
2. Distingue severidades con criterios objetivos. No basta con decir "incidencias críticas en 4 horas". Hay que definir qué convierte una incidencia en crítica, con ejemplos concretos del negocio del cliente, para que proveedor y cliente clasifiquen igual el mismo caso.
3. Tiene consecuencias. Un plazo sin penalización, mecanismo de escalado o derecho de revisión es una sugerencia. No hace falta que la consecuencia sea económica; a menudo un escalado automático a un responsable con nombre y apellidos funciona mejor que una penalización que nadie reclama.

Lo que no es un SLA operativo: la frase "soporte 24/7" sin plazos, el "tiempo medio de respuesta" sin percentil (una media se maquilla con muchos tickets triviales), o el clásico "haremos nuestros mejores esfuerzos". Ninguna de esas fórmulas permite saber, un martes a las 10:00 con la facturación bloqueada, cuándo va a atenderte alguien.

Tiempo de respuesta vs tiempo de resolución

Es la confusión más rentable del sector, y conviene deshacerla antes de firmar nada. Son dos compromisos distintos:

• Tiempo de respuesta: cuánto tarda una persona cualificada en hacerse cargo del ticket. No un acuse de recibo automático: alguien que ha leído el caso, lo ha clasificado y ha empezado a trabajar o ha pedido la información que falta.
• Tiempo de resolución: cuánto tarda el problema en estar resuelto o, como mínimo, en tener una solución provisional que devuelva la operativa (workaround), con la corrección definitiva planificada.

Muchos contratos solo comprometen el primero. El proveedor responde en 30 minutos con un "estamos en ello" y el SLA queda formalmente cumplido aunque la incidencia siga abierta dos semanas. Un SLA serio compromete ambos, y en resolución acepta un matiz razonable: para defectos complejos, el compromiso firme es el workaround en plazo, y la corrección de raíz va a una versión con fecha. Es un matiz honesto, porque nadie puede garantizar que cualquier bug se corrige de raíz en 8 horas; lo que sí se puede garantizar es que la planta no se queda bloqueada.

Un tercer plazo aparece en los contratos maduros: el tiempo de diagnóstico, el momento en que el proveedor comunica qué está pasando, a qué se debe y qué plan tiene. Para el responsable de operaciones, saber a qué atenerse a las 2 horas vale casi tanto como la resolución misma, porque le permite decidir si activa el procedimiento manual de contingencia o espera.

Severidades con ejemplos de planta

La clasificación por severidad es el corazón del SLA, y donde más se falla. La clave es definir cada nivel por su impacto en la operación, no por la emoción de quien abre el ticket. Una tabla de referencia para un entorno industrial con ERP y herramientas de gestión:

Dos observaciones sobre esta tabla. Primera: los plazos concretos dependen del contrato y del precio; lo importante es la estructura, no los números exactos. Segunda: la definición de S1 debe escribirse con los procesos reales del cliente delante. "Crítico" en una planta que expide a diario no es lo mismo que en una ingeniería que factura por hitos. Un SLA copiado de plantilla clasifica mal desde el primer día.

Conviene pactar también el mecanismo de reclasificación: quién decide la severidad final cuando cliente y proveedor discrepan, y cómo se registra el cambio. Sin este mecanismo, la discusión sobre si algo "era S1 o S2" envenena la relación más que la incidencia misma.

Anatomía de un SLA que se puede cumplir

Además de severidades y plazos, un SLA operativo completo especifica al menos estos elementos:

• Horario de cobertura por severidad. Es razonable que S1 tenga horario ampliado y S3 solo horario de oficina. Lo que no es razonable es que el horario no esté escrito.
• Canal único de entrada. Un sistema de tickets con registro de fecha y hora. El WhatsApp al técnico de confianza es cómodo hasta que ese técnico está de vacaciones y nadie sabe qué se le pidió.
• Cadena de escalado con nombres. Si el plazo de respuesta se incumple, el ticket sube automáticamente a un responsable identificado. El escalado no es un castigo: es la garantía de que ningún caso se queda huérfano.
• Obligaciones del cliente. Los plazos se suspenden mientras el proveedor espera información que solo el cliente puede dar. Explicitarlo protege a las dos partes y obliga al cliente a designar interlocutores que respondan.
• Informe periódico de servicio. Un resumen mensual o trimestral con tickets abiertos y cerrados, cumplimiento de plazos por severidad y recurrencias. Es la materia prima de la reunión de seguimiento y del apartado de formación que viene después: los tickets repetidos señalan dónde falta formar.
• Ventanas de mantenimiento y gestión de versiones. Cuándo se actualiza, con qué preaviso, cómo se prueba antes de tocar producción y cómo se revierte si algo sale mal.

Un apunte sobre las penalizaciones: funcionan mejor como mecanismo de revisión que como fuente de ingresos. Un esquema habitual y sano es acumular incumplimientos medidos y, a partir de cierto umbral, activar un derecho de revisión de condiciones o de salida anticipada. El objetivo del SLA no es cobrar multas: es que el servicio funcione.

Formación de usuarios que funciona: por rol y en el puesto

La formación típica de una implantación es una sesión de cuatro horas para todos los usuarios, en sala, dos semanas antes del arranque, con el proyector enseñando pantallas que aún cambiarán. Tres meses después nadie recuerda nada y el soporte se llena de consultas básicas. Este modelo falla por tres razones concretas, y cada una tiene remedio.

Formar por rol, no por sistema

El operario de almacén necesita dominar cinco pantallas y las necesita dominar a ciegas. Al responsable de compras le hacen falta otras ocho, y a administración, otras distintas. La sesión genérica que recorre "todo el sistema" no sirve a ninguno: aburre a cada asistente con el 80 % que no le afecta y pasa deprisa por el 20 % que sí. La formación eficaz se diseña por rol: qué hace esta persona un lunes cualquiera, en qué orden, y qué hace cuando algo se sale del guion (una devolución, un ajuste de inventario, un pedido urgente sin stock). Los casos raros merecen más tiempo que los frecuentes, porque los frecuentes se aprenden solos con la práctica.

Formar en el puesto, con datos reales

Una cosa es ver cómo se registra un consumo en un proyector y otra registrarlo con guantes, en la pantalla táctil de la planta, con el material delante. La formación en el puesto de trabajo, con el entorno de pruebas cargado con artículos, clientes y órdenes reales de la empresa, produce retención que la sala no consigue. Y tiene un efecto secundario valioso: al recorrer el proceso real aparecen los huecos que el diseño no contempló, cuando todavía es barato corregirlos.

Formar cerca del arranque y repetir después

La curva del olvido no perdona: lo aprendido y no practicado se pierde en semanas. La formación inicial debe pegarse al arranque, y el plan no acaba ahí. Las piezas que sostienen el conocimiento a largo plazo son otras: figuras de usuario clave por área (la persona de referencia que absorbe el 90 % de las dudas de sus compañeros antes de que lleguen a ticket), sesiones de refuerzo al mes y a los tres meses centradas en los errores que el soporte está viendo de verdad, y formación de incorporación para cada persona nueva, porque la rotación es el mecanismo silencioso por el que una organización desaprende su propio sistema.

Documentación viva: la que se consulta de verdad

El manual de usuario de 200 páginas entregado en PDF al cierre del proyecto tiene un destino conocido: una carpeta que nadie abre. No porque documentar sea inútil, sino porque ese formato no responde a cómo la gente busca ayuda: en el momento del problema, con una pregunta concreta, y con prisa.

La documentación que sí se usa comparte unos rasgos:

• Granular y orientada a tarea. "Cómo registrar una devolución de cliente" en una página corta con capturas, no el capítulo 7 del manual. Cada página responde una pregunta.
• Buscable y accesible desde el puesto. Una base de conocimiento en la intranet o en el propio sistema, no un archivo en el disco de alguien. Si encontrar la respuesta cuesta más de un minuto, el usuario abre un ticket o, peor, improvisa.
• Con propietario y fecha. Cada documento tiene un responsable de mantenerlo y una fecha de última revisión visible. La documentación sin dueño se desactualiza en silencio, y una instrucción obsoleta es peor que ninguna: enseña el procedimiento equivocado con apariencia de oficial.
• Alimentada por el soporte. Este es el circuito que la mantiene viva: cada consulta S4 repetida es una página de documentación que falta. El informe periódico del SLA señala las recurrencias; el plan de formación y la base de conocimiento las absorben. Soporte, formación y documentación no son tres servicios: son tres caras del mismo ciclo.

Para procedimientos de planta funciona especialmente bien el formato de instrucción operativa de una página (qué hago, en qué orden, qué compruebo antes de cerrar) plastificada o fijada junto al puesto, y el vídeo corto de dos minutos para procesos con mucha interfaz. Ambos envejecen, así que ambos necesitan dueño.

El coste de la infra-formación

La formación se recorta con facilidad porque su coste es visible y su beneficio, difuso. Conviene hacer el ejercicio contrario: poner delante lo que cuesta no formar. Los mecanismos son cuatro, y todos aparecen en cualquier implantación que haya escatimado aquí:

1. Soporte inflado. Una parte sustancial de los tickets de cualquier sistema de gestión son consultas de uso, no defectos. Cada una consume tiempo del usuario que la abre, del técnico que la responde y del compañero al que se pregunta antes. Es el coste más fácil de medir: basta clasificar los tickets de un trimestre y contar cuántos habrían desaparecido con formación o documentación.
2. Datos malos. El usuario que no entiende un campo lo rellena de cualquier manera o lo deja vacío. Meses después, el informe de márgenes no cuadra, el MRP propone compras absurdas y la dirección deja de fiarse del sistema. La limpieza de datos retrospectiva cuesta un múltiplo de la formación que la habría evitado.
3. Sistemas paralelos. Quien no domina la herramienta se refugia en Excel. Primero como apoyo, luego como registro real, y el sistema oficial pasa a rellenarse a posteriori, tarde y mal. Cuando la implantación "no ha cuajado", con frecuencia lo que no cuajó fue la formación.
4. Infrautilización. La empresa pagó licencias y consultoría de un sistema del que usa una fracción, mientras los procesos que el software ya resuelve se siguen haciendo a mano. Es el coste más silencioso: no genera tickets, solo hace que la inversión rinda menos de lo que debería año tras año.

Visto así, el presupuesto de formación no compite con el de soporte: lo reduce. Un plan de formación continua bien dirigido (por los datos del propio soporte) es la palanca más barata para bajar el volumen de tickets y subir la calidad del dato.

Ejemplo trabajado: incidencia en un ERP de planta

Para ver cómo encajan las piezas, sigamos una incidencia plausible de principio a fin. Martes, 9:40. En una empresa de fabricación, la persona de expediciones intenta validar los albaranes del día y el sistema devuelve un error. Hay dos camiones citados a las 12:00.

1. 9:42. Apertura. El usuario clave de logística abre un ticket por el canal pactado: descripción, captura del error, número de albarán afectado. Marca severidad propuesta S1: expediciones paradas, camiones esperando. El reloj del SLA arranca aquí, con registro objetivo.
2. 10:05. Respuesta cualificada. Dentro del plazo de S1 (45 minutos en este contrato), un técnico confirma la clasificación S1, reproduce el error en el entorno de pruebas y pide un dato que falta. Nada de acuses automáticos: el caso está en manos de alguien que lo entiende.
3. 10:50. Diagnóstico. El técnico comunica la causa: la última actualización cambió una validación y los albaranes con lotes mixtos ya no pasan. Propone un workaround (validar esos albaranes desde otra pantalla que no ejecuta la validación nueva) y lo prueba con el usuario clave por teléfono.
4. 11:15. Operativa recuperada. Expediciones valida los albaranes por la vía alternativa. Los camiones cargan a su hora. El ticket queda en estado "workaround aplicado": el SLA de resolución provisional de S1 se ha cumplido, pero el caso no se cierra.
5. Viernes. Corrección de raíz. El parche que corrige la validación entra en la ventana de mantenimiento pactada, probado antes en el entorno de pruebas. El ticket se cierra con la causa documentada.
6. Fin de mes. Ciclo de mejora. El informe de servicio recoge el caso: incumplimientos, ninguno; causa, regresión en actualización. Se acuerda añadir los albaranes de lotes mixtos a la batería de pruebas previa a cada actualización, y una página nueva en la base de conocimiento explica la pantalla alternativa. La incidencia deja el sistema mejor de lo que lo encontró.

Nada de lo anterior es heroico. Es lo que produce un SLA bien definido cuando se cumple: plazos que arrancan solos, severidad sin discusión, un workaround que prioriza la operación y un circuito que convierte cada incidencia en prevención y documentación.

Cómo evaluar el soporte de un proveedor antes de firmar

Todo lo anterior se puede verificar antes de contratar. Preguntas concretas que separan un soporte real de uno de folleto:

• Pide el documento de SLA y busca los tres elementos: plazos medibles por severidad, definiciones de severidad con ejemplos, y consecuencias del incumplimiento. Si falta alguno, pide que se añada; la resistencia a hacerlo ya es información.
• Pregunta si el compromiso es de respuesta, de resolución o de ambos, y cómo tratan el workaround en defectos complejos.
• Pide un informe de servicio real (anonimizado) de otro cliente. Quien mide su cumplimiento lo puede enseñar; quien no mide, no puede cumplir nada.
• Pregunta quién atiende: ¿el equipo que conoce tu instalación o una primera línea genérica que abre y cierra tickets? En sistemas personalizados, la distancia entre soporte y desarrollo se paga en cada diagnóstico.
• Pregunta por el plan de formación más allá del arranque: refuerzos, material por rol, formación de nuevas incorporaciones, y cómo usan los datos de soporte para dirigirla.
• Y una pregunta incómoda pero útil: ¿dan soporte a instalaciones que implantó otro proveedor? La respuesta describe su capacidad real de leer y mantener sistemas que no diseñaron ellos, que es exactamente lo que harán con el tuyo dentro de cinco años.

En Captia damos soporte y mantenimiento continuo de instalaciones de Odoo, incluidas las puestas en marcha por otros partners, y desarrollamos herramientas internas que nacen ya con su plan de soporte y documentación. La estructura de SLA descrita en esta guía es la que aplicamos en esos contratos.

Preguntas frecuentes sobre SLAs y formación industrial

Si quieres un contrato de soporte con plazos que se miden y una formación que reduce tickets en lugar de generarlos, en Captia trabajamos con esta estructura de SLA en implantaciones y mantenimientos de software de gestión. Cuéntanos tu caso y lo revisamos contigo.