Una excepción no es un accidente fuera del proceso, es la parte del proceso todavía no escrita. En esta lección abre el registro: qué hace el flujo cuando llega una entrada que la regla no cubre, qué avería lo detiene y cuál deja que siga, quién se entera y cómo la decisión llega al sistema.
En las lecciones anteriores se montó un flujo y se conectaron dos sistemas. En ambas, la excepción ocupaba una sola línea: la "vía de excepción" de la ficha de montaje, el "comportamiento ante un corte" del mapa de integración. Esta lección abre el trabajo que hay detrás de esas dos líneas. Qué hace el flujo cuando llega una entrada que la regla no cubre, quién se entera y dónde se escribe la decisión tomada.
La lección no propone eliminar las excepciones. Una excepción no es un accidente fuera del proceso, es la parte del proceso todavía no escrita. Escrita, se vuelve regla; sin escribir, obliga a decidir de nuevo cada vez.
Requisitos: el flujo de la quinta lección y el mapa de integración de la sexta. Sin flujo no hay excepciones; una excepción nace en el borde de un flujo que funciona.
Cuando se confunden, también se confunde el manejo. Una excepción es una situación que la regla no cubre: el sistema funciona bien pero no hay respuesta escrita para la entrada que encontró. Una avería es que el sistema funcione mal a pesar de lo escrito.
En la práctica la distinción se hace con una pregunta: al mirar el mapa, ¿está ahí la respuesta para esta situación? Si está y el sistema hizo otra cosa, es avería; si no está, excepción. Si el mismo suceso llega dos días seguidos, deja de ser excepción y pasa a ser regla que falta.
Una entrada o situación que la regla no cubre. El remedio es decidir; la decisión misma queda registrada, porque se preguntará una segunda vez.
Que el sistema actúe de otro modo donde hay regla escrita. El remedio es una corrección, y si la corrección se sostiene se prueba aparte.
Si la discusión "¿esto es excepción o avería?" se alarga, el mapa está poco claro en ese punto. La discusión se resuelve en el mapa, no en el sistema.
El registro cabe en una página y cada fila describe una excepción. Las cuatro columnas corresponden a las cuatro preguntas que se hacen cuando sale una excepción; cuando una columna queda vacía, esa excepción no lleva nada a la próxima ocasión.
La ganancia real de llevar el registro se ve en el segundo encuentro. La primera vez decidir cuesta tiempo; la segunda se aplica lo escrito en el registro y la discusión no se reabre.
La cuarta columna es la que mantiene vivo el registro. Si queda vacía, el registro se vuelve un archivo; si se rellena, el mapa de proceso crece solo.
La mayoría de los flujos se monta sobre la suposición de que la entrada llegará en la forma esperada. La entrada inesperada es donde esa suposición se rompe: el formulario se envía a medias, un campo que se creía obligatorio llega vacío, el sistema de origen cambia en silencio el formato de un campo.
Lo que comparten es que la mayoría no produce mensaje de error. El flujo sigue funcionando y sale un resultado producido con datos incompletos. Por eso la respuesta a la entrada inesperada se escribe en el lado de entrada del mapa, no en el de salida.
El registro existe pero parte de los campos está vacía. La decisión: se retiene el registro, se escribe tal cual, o se vuelve a preguntar a quien lo envió.
Si un campo tenido por obligatorio llega vacío, la obligación no se montó de verdad. La diferencia entre el diccionario de campos y el flujo sale aquí.
En el lado de origen cambia el formato de fecha o de teléfono. El flujo sigue leyendo como antes y el valor se rompe en silencio.
En la sexta lección se eligió la clave de deduplicación; esta lección trata los casos en que esa clave no sostiene. La misma persona escribe por segunda vez, el mismo formulario se envía dos veces, el mismo pedido entra por dos canales.
Un registro duplicado es un problema que crece en silencio: cada uno parece correcto por sí solo, y en el total el informe se hincha y al cliente se le contacta dos veces. Escribir la decisión de antemano sale más barato que limpiar después de que los registros existan.
La regla de deduplicación es una de las primeras filas del registro, porque aparece a menudo y su decisión se olvida con facilidad.
Detener el flujo en cada avería parece seguro pero detiene el trabajo; no detenerlo mantiene el trabajo en marcha pero agranda el resultado equivocado. La decisión se toma por avería y se escribe en el mapa.
El criterio es este: cuando este paso funciona mal, ¿se puede deshacer el resultado? Si se puede, el flujo puede seguir y el registro se marca. Si no se puede, el flujo se detiene y la persona que espera se entera.
Pasos cuyo resultado no se puede deshacer: un mensaje que sale, un pago, un borrado permanente. Donde hay duda se prefiere detener.
Situaciones que tocan un solo registro y se pueden deshacer. El registro se marca, el flujo sigue con los demás y los registros marcados se pasan al final del día.
El caso más difícil: parte del paso se ejecutó. Si no se escribió una vuelta atrás para esta posibilidad, el registro empieza a verse distinto en los dos sistemas.
Adónde va el aviso importa tanto como el aviso mismo. Un aviso que cae en un buzón compartido no suele ser trabajo de nadie; un canal que todos ven puede convertirse en un canal del que nadie responde.
La fila de aviso pide el nombre de una persona. Quién cubre mientras esa persona no está va en la misma fila, porque las excepciones no esperan a los días libres.
El texto del aviso también es parte de la decisión: si dice qué registro, en qué paso y por qué motivo se detuvo, quien mira puede decidir sin entrar al sistema.
El registro de averías es la única fuente que cuenta después lo que pasó. Puede estar dentro del flujo, en el diario de la propia herramienta o en una tabla aparte. Lo importante no es el sitio sino que se pueda buscar.
Leer el registro tiene su propio orden. Sin ese orden, lo que se mira suele ser la última línea, y la última línea casi siempre muestra el resultado, no la causa.
Qué registro, qué franja de tiempo. Sin identificador la búsqueda se lleva por la fecha y se ven también los registros vecinos.
Qué pasó paso a paso. Leer desde la primera desviación en lugar de desde la línea de resultado es lo que muestra la causa.
¿Venía el dato en la forma esperada? Buena parte de las averías sale aquí y el sistema resulta haber funcionado bien.
Todo flujo necesita una puerta de intervención manual: seguir un registro detenido, deshacer uno equivocado, pasar a mano la lista de espera. Sin puerta, la intervención se hace dentro de las herramientas y no deja rastro.
Una intervención es una excepción y se escribe en el registro. Si no se escribe nacen dos problemas: no se recuerda qué se hizo cuando la misma situación vuelve, y el resultado que produce el sistema deja de coincidir con el trabajo hecho a mano.
Que la intervención manual sea fácil no es debilidad del flujo sino su capacidad de sostenerse. Un flujo sin puerta se convierte en un proceso llevado a mano en la primera excepción.
La avería más cara es la que no da avería. El flujo se ve en verde, se crean registros, nadie recibe aviso; y el resultado producido es equivocado. Pasado con una frase en la sexta lección, este es el asunto de fondo del manejo de excepciones.
La fuente del fallo silencioso suele estar en el lado de entrada: un valor vacío cae al valor por defecto, un formato se interpreta mal, un emparejado se agarra a otro registro. Como el sistema funciona coherente por dentro, tampoco se anuncia.
Lo que comparten es esto: en todos el sistema dice "correcto". Por eso el fallo silencioso se caza con medición y no con aviso.
El camino para hacerlo visible pasa por no fiarse del informe del propio sistema. Hechas juntas, tres mediciones sacan a la superficie la mayoría de los fallos silenciosos.
Las tres se montan como costumbre semanal y se escribe quién las hace. Una medición sin dueño se abandona en la primera semana cargada.
Se compara el número de entradas con el de salidas. La diferencia muestra los registros que caen en silencio.
El mismo registro en los dos sistemas se abre uno al lado del otro. Mirar los campos clave basta, en lugar de campo por campo.
Se siguen de punta a punta unos registros al azar. Es observación más que medición; aquí se ven las desviaciones que el informe no muestra.
El resultado de la medición se escribe en el registro. También se escriben las semanas sin desviación, porque "mirado y limpio" es igualmente un dato.
No toda excepción se lleva al sistema. Una situación vista una vez queda registrada y espera; una que se repite se vuelve regla. Llevarla pronto enreda el flujo sin necesidad, llevarla tarde obliga a tomar la misma decisión una y otra vez.
El criterio es frecuencia y coste: si la misma excepción se repite, o incluso una sola vez produjo un resultado que no se pudo deshacer, se escribe una regla. Cuando la regla se escribe, también se actualizan el mapa de proceso y el diccionario de campos; si no, el mapa se queda por detrás de la realidad.
Cuando este paso se cierra, la excepción no desaparece, se vuelve regla. Así el registro se convierte en el diario de actualizaciones del mapa de proceso.
La oficina eligió una tarea piloto, escribió su proceso, sacó su diccionario de campos, eligió su herramienta, montó el primer flujo y conectó dos sistemas. Ahora el flujo funciona y en la primera semana llegan tres situaciones seguidas.
Ninguna de las tres está escrita en el mapa. La responsable de la oficina anota cada una en el registro y escribe la decisión; al final de la semana dos de las tres filas se han vuelto reglas.
Primera fila: en una consulta que llega del portal el campo de teléfono está vacío. Se decide que el registro no se escriba en la tabla de seguimiento y caiga en una lista de espera; la responsable pasa la lista al final del día. Cuando la misma situación se repite tres veces se convierte en regla y se lleva al mapa.
Segunda fila: la misma persona escribe desde dos anuncios distintos y en la tabla de seguimiento se abren dos registros. La decisión: la segunda consulta entra como nota bajo la misma persona. Como esta decisión es la mitad que faltaba de la regla de clave de la sexta lección, se lleva al sistema directamente.
Tercera fila: el portal cambia el formato del campo de fecha y las citas se desplazan un día. No hay mensaje de avería y los registros parecen válidos. La desviación no se caza en el recuento semanal sino en el muestreo: las fechas de dos registros elegidos al azar no cuadran con el anuncio. Se corrige la conversión de formato, los registros afectados se deshacen a mano y la intervención se escribe en el registro.
Al final de la semana la oficina nota que los avisos van a un buzón compartido y que nadie los mira. La fila de aviso se pasa a nombre de una persona y se escribe también quién cubre.
Dos de las tres filas se volvieron reglas, una quedó en observación. El valor del registro se ve aquí: no solo qué decisión se tomó, también cuál llegó al sistema queda anotado.
Esta semana abra el registro y escriba lo que ocurre en el borde de su flujo en marcha. No hace falta esperar una excepción nueva; cada intervención manual de las últimas dos semanas ya es una fila de excepción.
Descargar el registro de excepciones (xlsx) · un registro de una página con las columnas qué excepción, cuándo salió, cómo se decidió y si llegó al sistema; las secciones de aviso, intervención manual y medición semanal también están dentro.
Los de abajo no nacen de la excepción misma sino de que la excepción no se lleva. Lo que comparten es esto: ninguno se ve en el sistema como una avería.
La decisión se toma en una conversación y no queda anotada. Cuando la misma situación llega una segunda vez se decide otra cosa y dos registros reciben trato distinto.
Una desviación que toca un solo registro detiene todo el flujo. Al cabo de un tiempo los avisos se apagan y tampoco se ve la avería que sí detiene.
El aviso va a todos y nadie lo hace suyo. Un aviso que no se mira da el mismo resultado que un aviso que no se envió.
El registro se corrige a mano pero no se escribe quién hizo qué. Cuando el mismo registro vuelve a romperse la semana siguiente, la causa no se puede buscar.
La línea "todo correcto" no muestra el fallo silencioso. Hasta que no se monta la medición, un resultado equivocado pasa por bueno durante semanas.
Una situación vista una vez se añade al flujo como condición. El flujo se enreda un poco más con cada excepción y su mantenimiento se complica.
Si al terminar la primera semana del flujo se puede responder a cada punto de esta lista, el manejo de excepciones cuenta como montado.
Términos que salen en las conversaciones sobre excepciones. Dar el mismo significado a la misma palabra mantiene el registro legible también en la segunda semana.
En esta lección escribió el borde del flujo: distinguió excepción de avería, abrió el registro, definió las vías de aviso y de intervención manual e hizo visible el fallo silencioso mediante medición. Las lecciones que vienen tratan de meter al equipo en el proceso y de medir el resultado.
Si quiere seguir con las lecciones publicadas, viene el módulo que estrecha una avería por orden.
La ficha de avería, el método de partir en dos y una corrección duradera. El registro de esta lección lo alimenta.
El mapa de integración y el comportamiento ante un corte. Parte de estas excepciones nace allí.
La sección de formación completa y los módulos añadidos después.
Si quiere abrir el registro de excepciones juntos, escríbanos y rellenamos las primeras filas.
Solicitar Presupuesto por WhatsApp