Documentar protocolos de intervención: guía para SAT

Documentar un protocolo de intervención no es escribir un manual corporativo de cien páginas que nadie va a abrir. Es dejar por escrito, en pasos cortos y consultables, cómo se resuelve una tarea concreta sobre una unidad concreta, para que cualquier técnico la ejecute igual que el veterano que la domina. Esa es la parte práctica de la gestión del conocimiento técnico en un SAT: sacar lo que saben tus mejores técnicos de su cabeza y ponerlo en un sistema. Y no hace falta parar la operación seis meses para conseguirlo.

El error habitual es querer documentarlo todo de golpe y en el formato equivocado. Se monta un proyecto enorme, se redactan procedimientos en Word que ocupan cuarenta páginas, y a los tres meses nadie los ha abierto porque en campo, con el equipo delante y el cliente esperando, nadie lee cuarenta páginas. La documentación que funciona se parece más a una ficha de taller que a un manual de calidad.

Este artículo es para el gerente o el responsable de operaciones que ya sabe que su conocimiento vive en tres o cuatro personas, probablemente porque ya ha sufrido la fuga de conocimiento técnico el día que uno de ellos se fue, y busca el plan concreto para documentarlo sin que se convierta en un proyecto eterno. Vamos por partes: por dónde empezar, qué meter en cada protocolo, en qué formato, cómo validarlo con el senior y cómo mantenerlo vivo.

Por qué la gestión del conocimiento técnico suena a proyecto imposible (y no lo es)

Cuando le dices a un gerente de SAT que tiene que documentar sus protocolos de intervención, lo primero que ve es un consultor externo, seis meses de reuniones y un clasificador que acabará cogiendo polvo. Y tiene motivos para desconfiar, porque así es como se ha hecho casi siempre y así es como casi siempre ha fracasado.

El proyecto imposible no es documentar. Es querer documentarlo todo, para todos los equipos, con el nivel de detalle de un manual de fabricante, antes de que sirva para nada. Planteado así, no termina nunca. El enfoque que sí funciona es el contrario: documentar poco, empezar por lo que más duele y que cada protocolo sea útil el mismo día que se escribe.

Mientras tanto, el coste de no tenerlo documentado se paga cada día en tiempo. Según el informe The Social Economy de McKinsey Global Institute (2012), un trabajador del conocimiento dedica cerca del 20% de su jornada, en torno a 1,8 horas diarias, a buscar información interna o a localizar al compañero que la tiene. En un SAT ese 20% no es un técnico en una oficina: es un técnico parado delante de un equipo, con el desplazamiento pagado y el cliente mirando el reloj.

Empieza por las unidades que más consultas generan, no por todo el catálogo

La primera decisión es la que más ahorra: no documentes por orden alfabético ni por catálogo completo. Documenta por dolor. En casi cualquier cartera de mantenimiento, un grupo pequeño de modelos concentra la mayor parte de las consultas y de las segundas visitas. Ataca ese grupo primero.

Para encontrarlo, mira dónde se van las llamadas al senior y qué averías se repiten. Si tu sistema registra las consultas, ya tienes el mapa. Si no lo registra, pregunta a los propios veteranos: te dirán en dos minutos cuáles son los 10 equipos que más quebraderos de cabeza dan en el día a día.

Como estimación de campo de Fluxput, basada en lo que vemos al trabajar con empresas del sector, documentar bien los protocolos de las 10 a 15 unidades más consultadas suele cubrir entre el 60% y el 80% de las consultas técnicas totales. Es el patrón de concentración habitual (tipo Pareto) en casi todos los catálogos de mantenimiento: pocos equipos, muchas dudas. Documentar esos primero es lo que convierte el proyecto en algo que da resultados en semanas, no en trimestres.

Qué debe contener un protocolo de intervención para ser útil en campo

Un protocolo de intervención es el procedimiento paso a paso para ejecutar una tarea técnica concreta sobre un tipo de equipo: una puesta en marcha, un preventivo trimestral o la reparación de una avería recurrente. Para que sirva en campo tiene que poder seguirlo un técnico de segundo año sin llamar a quien lo escribió.

Un protocolo útil no necesita ser largo, necesita ser completo en lo que importa. Por cada tarea documentada, estos son los datos que un técnico agradece tener delante:

• Los pasos, en el orden exacto en que se ejecutan, cortos y en imperativo, no en párrafos explicativos.
• Los valores de referencia: presiones, temperaturas, pares de apriete, lo que el técnico tiene que comprobar y contra qué número compararlo.
• Los consumibles y recambios que lleva la tarea, con su referencia real, para que no descubra en la instalación que le falta una pieza.
• Las averías habituales de ese equipo y cómo se diagnostican, que es justo el conocimiento tácito que hoy vive solo en la cabeza del veterano.
• Los avisos de seguridad y los pasos que no se pueden saltar, sobre todo en equipos con gases fluorados o riesgo eléctrico.

Lo que no debe contener es relleno. Nada de introducciones sobre la importancia del mantenimiento ni de teoría que el técnico ya sabe. El protocolo empieza en el primer paso que ejecuta y termina en el cierre de la intervención.

El formato importa: por qué un PDF de 40 páginas no es un protocolo consultable

Puedes tener el mejor contenido del mundo y que no lo use nadie, y casi siempre es un problema de formato. El técnico trabaja en el móvil, muchas veces con mala cobertura y con las manos ocupadas. Un PDF de cuarenta páginas en una carpeta compartida cumple sobre el papel, porque la información está ahí, y falla en la práctica, porque nadie va a buscar el paso 7 de la página 23 con el cliente delante.

La diferencia entre documentación y conocimiento accesible es justo esa: no es lo que tienes guardado, es lo que el técnico encuentra en el momento exacto en que lo necesita. Lo desarrollamos en la guía sobre qué es una base de conocimiento técnico y cómo se construye, pero la idea de fondo cabe en una frase: un protocolo que hay que buscar no es un protocolo consultable.

Esta es, en concreto, la función de Fluxput Bases: analiza los manuales técnicos que la empresa ya tiene, detecta automáticamente cada unidad del catálogo y estructura el protocolo de actuación por unidad, con pasos concretos, consumibles y valores de referencia, consultable desde el móvil en el momento de la intervención. No es un PDF que hay que abrir y rebuscar, es la ficha del equipo que tienes delante. Y como parte de un software de gestión de conocimiento técnico para SAT, ese protocolo queda enlazado a la orden de trabajo y al histórico del activo, no suelto en una carpeta.

Un detalle que marca la diferencia en el SAT: el protocolo puede vivir a dos niveles. A nivel de modelo de catálogo, sirve para cualquier unidad de ese tipo que te encuentres. A nivel de activo real, se enriquece con el histórico de esa instalación concreta: qué se hizo la última vez, qué pieza se cambió, qué particularidad tiene ese cliente. El mismo protocolo, con la memoria de la unidad encima.

Cómo validar un protocolo con el técnico senior sin que lo tome como una crítica

Aquí está la parte humana, y es la que más proyectos hunde. El conocimiento que quieres documentar está en la cabeza de tu mejor técnico, y ese técnico puede vivir la documentación como una amenaza: si escribo lo que sé, ¿para qué me necesitan? Si no resuelves esa duda, el senior colabora a medias y el protocolo sale incompleto.

Lo primero es cómo lo cuentas. Documentar el conocimiento del veterano no es reemplazarlo, es reconocer que su forma de trabajar es la buena y convertirla en el estándar de la casa. El senior deja de ser el que apaga fuegos por teléfono y pasa a ser el que define cómo se hacen las cosas. Es un ascenso de facto, no una sustitución.

En lo práctico, no le pidas que se siente a escribir, porque no lo va a hacer y no es su trabajo. Que ejecute la intervención como siempre y que alguien recoja lo que hace: con un audio mientras trabaja, con una plantilla corta que rellena otra persona o dejando que el sistema estructure lo que él dicta. El senior valida y corrige, no redacta desde cero. Revisar un borrador cuesta cinco minutos; escribir desde la página en blanco es una tarde que nunca encuentra.

Mantener los protocolos vivos: quién los actualiza y cuándo

Un protocolo documentado y luego abandonado es casi peor que no tenerlo, porque el técnico que se fía de un valor desactualizado comete un error con la confianza de quien cree que va bien. La documentación no es un proyecto con fecha de fin, es una rutina.

La regla que funciona es que el protocolo se actualice donde se genera el conocimiento nuevo: en el cierre de la intervención. Cuando un técnico resuelve una avería que no estaba documentada, o descubre que un valor de referencia ha cambiado, ese hallazgo tiene que poder incorporarse al protocolo sin abrir un ticket ni esperar a la reunión trimestral. Si actualizar cuesta, nadie actualiza.

El beneficio se nota sobre todo cuando entra gente nueva. Documentar los protocolos antes de incorporar a un técnico es lo que separa una curva de autonomía de meses de una de semanas: lo vimos en el caso de un SAT de climatización que redujo el onboarding de sus técnicos de 4 meses a 4 semanas apoyándose en protocolos consultables desde el móvil. Como estimación de campo de Fluxput, un técnico nuevo tarda de media entre 3 y 6 meses en ser autónomo cuando depende de preguntar a los veteranos, y unas pocas semanas cuando el conocimiento está documentado y a mano.

Y hay un motivo de negocio para no dejar morir los protocolos. La media del sector de servicios de campo ronda el 77% de first-time fix rate, según Service Council, lo que significa que cerca de una de cada cuatro intervenciones no se resuelve a la primera. Buena parte de esas segundas visitas son evitables: el técnico llegó sin el protocolo de una avería que alguien en la empresa ya sabía resolver. Cada protocolo vivo que documentas es una tanda de segundas visitas que dejas de pagar.

De la teoría al primer protocolo

Documentar protocolos no es un proyecto de calidad para lucir en una auditoría. Es la forma más barata de dejar de depender de que estén las personas correctas el día correcto. Empieza por los 10 equipos que más consultas generan, escribe en pasos cortos lo que hace tu mejor técnico, ponlo donde el técnico ya trabaja y actualízalo en cada cierre. Solo con eso, la mayoría de SAT resuelve el grueso de su dependencia de personas concretas.

Si quieres ver cómo quedaría tu conocimiento puesto en orden, pide una demo de Fluxput Bases y trae tus manuales: la forma más rápida de entender esto es ver el protocolo de una de tus unidades estructurado a partir de la documentación que ya tienes.