La forma más fácil de saber que un sistema se rompió es que dé error. Lo difícil es el sistema que funciona mal sin darlo: en pantalla todo parece correcto mientras la salida está silenciosamente equivocada. Esta lección trata de dónde mirar, y en qué orden, cuando eso ocurre.
Esta lección aborda el momento en que una automatización ya construida deja de comportarse como se esperaba. El objetivo es que encuentre el problema estrechándolo por orden y no adivinando, y que la corrección hallada quede firme. Una automatización se mantiene en pie cuando el diagnóstico deja de depender de quien construyó el sistema y pasa a ser una destreza de la propia empresa.
Al terminar tendrá un orden de diagnóstico, una ficha de avería rellenada y un paso de verificación que muestra que la corrección sirvió. Las intervenciones hechas sin estos tres suelen producir una segunda avería.
Requisito previo: el mapa de proceso de la primera lección. Esa es la expectativa escrita con la que compara mientras busca la avería.
La frase no funciona cubre tres situaciones distintas a la vez, y cada una se diagnostica desde otro punto de partida. Separar al comienzo de la conversación con qué tipo se enfrenta ya estrecha el área de búsqueda.
La automatización no corre en absoluto. El disparador no llega o cae en el primer paso. Es el tipo más fácil, porque el síntoma se ve y suele dejar rastro en el registro.
El flujo corre, genera registros, no levanta aviso; y aun así el resultado es erróneo. Es el tipo más caro, porque el error se acumula durante semanas y al notarlo hay que limpiar hacia atrás.
El resultado es correcto pero no llega a tiempo. Normalmente no hay una avería única sino carga acumulada o un paso recién añadido. Sin medición este tipo queda abierto a discusión.
Lo común a los tres es esto: mientras la expectativa no esté escrita, la avería no se puede definir. La frase esto no debería haber sido así no se convierte en diagnóstico sin un esto debería haber sido así puesto por escrito.
Una automatización rara vez se rompe con ruido. No da mensaje de error, nada se pone en rojo, el flujo se ve verde. Aun así la salida es errónea: el mensaje va a la persona equivocada, un campo queda vacío, un registro se abre dos veces, la fecha se escribe en otro formato.
El origen de una avería silenciosa suele ser la entrada cambiando de forma. Se abre un campo nuevo en el formulario, el portal empieza a mandar el teléfono de otra manera, un empleado rellena el campo distinto. La regla sigue igual, la entrada cambia, y el resultado se desliza en silencio.
El último punto es el que más pesa. En cuanto el equipo corrige una salida a mano, el sistema ya está roto; como nadie lo comunicó, la avería no entró en ningún registro.
Si algo que ayer funcionaba hoy no funciona, entremedias cambió algo. Es la primera pregunta del diagnóstico, y con ella se cierra la mayoría de las averías. En sistemas sin lista de cambios, la misma pregunta lleva horas.
El cambio no ocurre solo en el sistema. Ocurre también en el proceso, en las personas y en la entrada. Puede que un empleado se haya ido, que un portal haya renombrado un campo, que un proveedor haya renovado el formato de archivo. Empiece la búsqueda por esta lista, no por dentro del código.
El diagnóstico empieza cuando el síntoma queda escrito. No funciona no es un síntoma, es una sensación. El síntoma es esto: en qué registro, cuándo, qué se esperaba y qué ocurrió en su lugar. El área de búsqueda no se estrecha hasta que esos cuatro campos estén llenos.
Al escribir el síntoma, tome el resultado esperado del mapa de proceso de la primera lección. Si no hay mapa, se escribe ese primero; un diagnóstico hecho sin expectativa escrita se convierte en comparar la memoria de una persona con el comportamiento del sistema.
Las dos últimas preguntas marcan la dirección del diagnóstico. Si la avería está en un solo registro, el problema suele estar en la entrada; si está en todos, en la regla; si está en una parte, en la condición.
No arregle lo que no puede reproducir. Sin un ejemplo que repita la avería cuando quiera, tampoco puede demostrar si el cambio que hizo sirvió. Muchas averías que se creen resueltas son averías que ese día no se repitieron.
Reproducir significa pasar el mismo registro por un entorno de pruebas o con un ejemplo inofensivo. Si tiene que probar en el sistema vivo, elija un paso reversible y avise antes al equipo.
La vía más rápida para estrechar el área de búsqueda es cortar el flujo por la mitad. En un punto intermedio del flujo, ¿el dato está bien o mal? Si está bien, la avería está en la segunda mitad; si está mal, en la primera. Con cada corte, el área por revisar queda en la mitad.
Este método funciona al margen de la herramienta. Se hace la misma pregunta mirando la pantalla del registro, la tabla intermedia, el mensaje enviado o el registro que guarda el sistema: ¿llegó el dato correcto hasta aquí?
Escriba el resultado tras cada corte. Los cortes que no se escriben se repiten, y el diagnóstico se alarga por revisar los mismos sitios una segunda vez.
Una vez estrechada el área, sondee por orden las cinco partes de la primera lección. Las seis fuentes de abajo son las que más se encuentran en la práctica, y la mayoría de los diagnósticos se cierran dentro de ellas.
Puede que el suceso no llegara siquiera. La conexión pudo caerse, un permiso pudo caducar, una dirección pudo cambiar. Si no se creó registro, la avería está en la puerta del flujo, no dentro.
Es la fuente más frecuente. Un campo pudo renombrarse, una fecha puede llegar en otro formato, un cero inicial pudo caerse, un espacio o una mayúscula pueden diferir.
Puede haber aparecido una situación nueva que cae fuera de los caminos escritos. Los registros fuera de las condiciones suelen caer en silencio, porque no se escribió camino para ellos.
Una contraseña pudo cambiar, una clave pudo caducar, un usuario pudo borrarse. Estas averías empiezan de golpe un día y no avisan antes.
Dos pasos pudieron correr en orden equivocado, o uno pudo arrancar sin esperar el dato del otro. Las averías que salen en horas punta y no en horas tranquilas suelen estar aquí.
La otra parte pudo rechazarlo: un campo pasó a ser obligatorio, un límite se llenó, un formato fue rechazado. Cuando no se lee la respuesta que vuelve, esta avería queda muda.
No cambie varias cosas a la vez. Si hace dos cambios y el resultado mejora, cuál lo mejoró queda sin saberse; si empeora, cuál lo rompió queda sin saberse. En ese punto el diagnóstico vuelve a ser suposición.
Tras cada cambio, vuelva a pasar el ejemplo del paso dos. La verificación abarca tanto que la avería se haya ido como que no se haya roto otra cosa. Para eso, anote antes qué registros corrían bien.
Quitar la avería es la mitad del trabajo. La otra mitad es poner las marcas que impidan que la misma avería vuelva a formarse en silencio. Sin eso, el mismo diagnóstico se rehace desde cero unos meses después.
La firmeza viene de tres cosas: un aviso donde la avería se vería, una comprobación que sondee los límites de la entrada y una vía de excepción definida. Las tres viven dentro de la propia automatización y no piden un sistema aparte.
Trabajemos el método sobre una sola avería de principio a fin. El ejemplo corre sobre un flujo de ventas, aunque el orden es el mismo en cualquier flujo.
Síntoma: los clientes con solicitudes nuevas no reciben el correo de oferta. El equipo de ventas lo notó primero y dice que varios clientes llevaban la última semana esperando respuesta. Los registros parecen haberse creado.
Qué cambió: en las últimas dos semanas se añadió un campo nuevo al formulario y se hizo una actualización del lado del portal. Dos candidatos.
Reproducción: uno de los registros afectados se vuelve a pasar con la misma entrada. La avería se repite, así que hay un ejemplo medible en la mano.
Corte por la mitad: se mira la tabla intermedia del flujo. El registro está ahí, pero el campo del correo está vacío. La avería está entonces en la primera mitad, del lado de la entrada.
Cinco partes: se mira el formato de entrada. El campo nuevo del formulario ha renombrado el campo del correo. El flujo busca el nombre viejo, no lo encuentra, pasa un valor vacío y el paso del correo cae en silencio.
Un cambio y verificación: el flujo se corrige para leer el nombre de campo nuevo. Se vuelve a pasar el ejemplo de la avería y el correo sale. También se pasan dos registros que antes corrían bien, y siguen bien.
Firmeza: si el campo del correo está vacío, el flujo se detiene, el registro queda en espera y se avisa a la dirección. Se actualiza el nombre del campo en el mapa de proceso. El otro flujo que usa ese campo se sondea y se corrige también.
El diagnóstico no es una destreza que se aprenda el día en que sale la avería. Ensayado en un día tranquilo, está listo el día en que hace falta. Para eso está el ejercicio de abajo.
Todo flujo que pasa en silencio es un flujo que producirá una avería silenciosa más adelante. Este ejercicio saca a la superficie al menos uno en la mayoría de las empresas.
Descargar la lista de diagnóstico (xlsx) · la ficha de avería, qué cambió, partir el flujo en dos, la revisión de las cinco partes y los pasos de la corrección duradera.
Lo primero que se mira suele ser la regla, aunque la fuente más frecuente es la entrada. Si la regla no ha cambiado desde ayer, lo que cambió es más bien el dato que le llega.
Hacer dos cambios y mirar el resultado no termina el diagnóstico, lo emborrona. Qué cambio hizo qué queda sin saberse, y la corrección se vuelve irrepetible.
Una corrección hecha sobre una avería que no se puede repetir no se puede verificar. La avería queda invisible un tiempo y luego vuelve por el mismo sitio.
La mayoría de los flujos apunta en algún sitio lo que hizo. Un diagnóstico sin mirar el registro es suponer sin escuchar lo que dice el sistema.
Un síntoma pasado de boca en boca cambia en cada traspaso. Un síntoma sin escribir se convierte en un diagnóstico donde dos personas buscan dos averías distintas.
Una avería cerrada sin aviso ni comprobación vuelve de la misma forma. En su segunda visita el diagnóstico empieza de nuevo y la confianza se desgasta otra vez.
Antes de cerrar una avería, conviene poder decir sí a todos los puntos de abajo. Si falta un punto, la avería no está cerrada sino aplazada.
Los términos que aparecen en las conversaciones de diagnóstico. Cuando el equipo comparte vocabulario, traspasar una avería va más rápido.
En esta lección tratamos cómo estrechar una avería por orden y cómo dejar firme la corrección; ha visto que buena parte de las averías sale del lado de la entrada.
Los módulos restantes del plan se están preparando. Según se publican ocupan su lugar en el plan y aparecen en la página de formación.
El registro de excepciones, la vía de aviso y la medición que hace visible el fallo silencioso.
El diccionario de campos y las reglas de formato. La mayoría de las averías empieza en este lado.
La sección de formación completa y los módulos añadidos después.
Si sospecha que un sistema funciona mal en silencio, escríbanos y lo miramos juntos.
Solicitar Presupuesto por WhatsApp