El flujo puede estar funcionando, pero si el equipo no lo ha asumido el trabajo sigue sobre una sola persona. En esta lección rellena la lista de traspaso: roles, permisos, apoyo de la primera semana, la puerta única para los problemas y poner por escrito las reglas que quedan en la cabeza.
Las lecciones anteriores montaron el sistema: se eligió la tarea, se escribió el proceso, se definieron los datos, se eligió la herramienta, se montó el flujo, se conectaron los sistemas y se decidieron las excepciones. Esta lección trata de las personas que van a usar el sistema.
La diferencia está aquí: el flujo puede estar funcionando, pero si el equipo no lo ha asumido, el trabajo sigue sobre una sola persona. Cuando esa persona se va de vacaciones la automatización sigue funcionando y las decisiones de su borde se detienen. El traspaso es también compartir esas decisiones.
Requisitos: un flujo en marcha y el registro de excepciones de la séptima lección. Sin registro, la mitad de las decisiones por traspasar no está escrita.
La automatización no quita el trabajo, le cambia la forma. Los pasos que se repiten pasan al lado del sistema; la decisión, la excepción y hablar con el cliente se quedan del lado de las personas.
Cuando este cambio no está escrito, el equipo intenta hacer dos cosas a la vez: sigue llevando el trabajo manual antiguo y además vigila el sistema nuevo. La carga no baja, se dobla. La lista de traspaso existe justo para adelantarse a eso.
Disparar, crear registros, mover datos, recordar. El trabajo cuyos pasos están escritos y que corre con reglas.
Decisión, excepción, hablar con el cliente y repasar con la vista lo que el sistema produjo. Esto no mengua, se vuelve visible.
Pasar la lista de espera, mirar los avisos, rellenar el registro. Este trabajo también necesita dueño, si no nadie lo hace.
La lista cabe en una página y cada fila describe a una persona o un rol. Las cuatro columnas corresponden a las cuatro preguntas del traspaso; cuando una columna queda vacía, a esa persona se le ha traspasado el sistema a medias.
Rellenar la lista antes del traspaso es distinto de rellenarla después. Rellenada antes, los permisos que faltan y el trabajo sin dueño salen sobre el papel; rellenada después, se descubren uno a uno durante la primera semana.
La cuarta columna es la que hace funcionar la lista. Si queda vacía, cada cual pregunta a una persona distinta y la misma pregunta se responde varias veces.
El traspaso se escribe por rol y no por nombre, porque las personas cambian y los roles quedan. Para cada rol se listan las pantallas que ese rol toca de verdad; la pantalla que no toca no entra en la lista.
Esta distinción también cambia la formación: en lugar de enseñar todo a todos, a cada rol se le enseña su propia pantalla. La pantalla que no se enseñó acaba en la puerta de todos modos cuando luego da problemas.
Cuando la lista está completa, cada pantalla del sistema tiene un dueño. Una pantalla sin dueño se convierte en la pantalla que nadie mira al final del primer mes.
El permiso da problemas en las dos direcciones. Dado estrecho, el trabajo se para y todos acuden a la misma persona; dado ancho, un cambio hecho sin querer no se puede deshacer.
El criterio es este: ¿qué tiene que ver y qué tiene que cambiar este rol para llevar su trabajo? Donde basta con ver, no se da el permiso de cambiar. La fila de acceso de la sexta lección baja aquí al nivel de la persona.
Poder abrir el registro y la lista. Para la mayoría de los roles basta para llevar el trabajo y no produce un resultado que no se pueda deshacer.
Abrir registros, actualizarlos, pasar la lista de espera. Cuando se escribe quién puede cambiar qué campo, la discusión termina.
Parar el flujo, cambiar una regla, abrir un usuario nuevo. Un permiso que se mantiene estrecho y se escribe con nombre.
El traspaso no termina con una reunión. La primera semana es la semana en que el sistema trabaja junto al equipo, y esa semana alguien tiene que estar al lado.
Estar al lado no es hacer el trabajo por ellos; es responder cuando preguntan y, cuando no preguntan, repasar los primeros días con la vista. Cuando el nombre de quien está al lado está escrito, el equipo no duda en preguntar.
Las preguntas que se hacen son la entrada del registro de excepciones. Si la misma pregunta llegó tres veces, lo que falta no es la persona sino la regla sin escribir.
Es la fila del traspaso que más se salta. Cuando el equipo se topa con un problema, ¿acude a quien montó el sistema, al responsable o al proveedor? Sin escribir, cada cual llama a una puerta distinta y el mismo problema se cuenta varias veces.
Puerta única no significa amontonar los problemas en una persona. La puerta es donde el problema que llega se clasifica y se pasa al sitio correcto: ¿pregunta de uso, excepción o avería de verdad?
Del tipo "¿desde dónde hacía esto?". Va a quien apoya en la primera semana y la respuesta se añade a la nota de formación.
Situación que la regla no cubre. Va al dueño del registro, se decide y se abre una fila.
El sistema funciona mal a pesar de lo escrito. Se estrecha con la lista de diagnóstico y luego va al lado que lo montó.
El camino más corto para explicar el sistema al equipo es mostrarlo sobre sus propios registros y luego hacer que lo hagan ellos. La explicación sola se olvida en el primer registro real.
El registro usado en la muestra conviene que sea real pero con resultado reversible. Un registro de prueba es el que se reconoce por su nombre y se limpia después.
La salida de la muestra no es un documento sino el segundo registro que la persona completó sola. El documento sirve al lado de ese registro.
La resistencia no suele ser contra la tecnología sino contra la incertidumbre. Bajo las frases "¿me quitará el trabajo?", "¿qué pasa si me equivoco?", "lo de antes era más rápido" hay tres preguntas sin responder.
Un traspaso hecho sin hablar de esto puede acabar con el sistema sin usar, a un lado. Que el sistema exista no significa que se use.
Cuando se escribe qué pasos asumió la automatización y qué trabajo queda en las personas, la inquietud se vuelve una lista concreta.
Baja cuando se muestra la vuelta atrás. Quien sabe cómo se corrige un registro equivocado no rehúye el sistema.
Si el camino antiguo sigue abierto, el nuevo no se usa. Si el respaldo manual se deja abierto a propósito, se escribe en qué caso se usa.
En todo equipo hay reglas que no están en el sistema: a qué cliente se le devuelve la llamada antes, qué solicitud espera, en qué caso se coge el teléfono. Suelen estar en la cabeza de una sola persona.
El traspaso es el mejor momento para hacer visible ese saber, porque en la primera semana las preguntas llegan solas. Escribir la respuesta sale más barato que responder la misma pregunta una segunda vez.
Cuando este paso se completa, el traspaso cubre no solo las pantallas sino las decisiones. Ese es el traspaso de verdad.
La misma prueba de traspaso que se hizo en la segunda lección para el mapa de proceso se hace aquí para el sistema. El criterio es el mismo: ¿lo escrito funciona sin la persona que lo escribió?
Para la prueba, quien montó el sistema se aparta un día y el equipo lleva el trabajo por su cuenta. Las preguntas que se hacen y los sitios donde se atascan son la salida de la prueba.
Pasar la prueba una vez no da el traspaso por terminado; obtener el mismo resultado una segunda vez sí. La primera vez hay una parte de suerte.
La oficina eligió una tarea piloto, escribió su proceso, definió sus datos, eligió su herramienta, montó el flujo, conectó los sistemas y abrió el registro de excepciones. Hasta ahora una sola persona usaba el sistema: la responsable de la oficina.
En el traspaso se definen dos roles: la responsable de oficina y los asesores de campo. Como las pantallas y los permisos de los dos roles son distintos, la lista se abre en dos filas.
Fila de la responsable de oficina: usa las pantallas de lista de solicitudes, lista de espera y registro de excepciones. El permiso se escribe como abrir registros, actualizarlos y pasar la lista de espera; el permiso de parar el flujo no se da. El apoyo de la primera semana es quien montó el sistema, con la dirección de la oficina como suplente.
Fila del asesor de campo: solo ve sus propias solicitudes y escribe el resultado de la cita. El permiso de ver es amplio, el de cambiar se limita a un solo campo. Como esta distinción se escribe desde el primer día, la discusión de "tocar sin querer la solicitud de otro" no llega a abrirse.
El arreglo de la primera semana se monta así: cada mañana se pasa la lista de espera, por la tarde se revisan los avisos y las preguntas van a una nota. Durante la semana llegan doce preguntas; nueve se clasifican como preguntas de uso, dos como excepciones y una como avería de verdad.
Tres preguntas repetidas se llevan al mapa de proceso como reglas: "qué se hace cuando el teléfono está vacío", "a qué registro va el segundo mensaje de la misma persona" y "dónde espera el registro cuando se cancela una cita". Las tres eran reglas que estaban en la cabeza; el traspaso las pone por escrito.
En la prueba de traspaso de la segunda semana la oficina completa el día sin preguntar a quien lo montó. El único paso donde se atascan es la pantalla de informes, y la lista de pasos de ese paso se escribe el mismo día.
Esta semana abra la lista de traspaso y escriba una fila por cada rol que vaya a usar el sistema. No hace falta esperar a un montaje nuevo; traspasar un flujo que ya corre usa la misma lista.
Descargar la lista de traspaso (xlsx) · una lista de una página con las columnas quién usa qué, qué permiso, quién acompaña la primera semana y adónde ir si algo falla; la demostración, las preguntas de la primera semana y la prueba de traspaso también están dentro.
Los de abajo no vienen del sistema sino de un traspaso hecho a medias. Lo que comparten es esto: ninguno se ve en el sistema como una avería.
Se hace una presentación y el traspaso se da por hecho. En el primer registro real empiezan las preguntas y no hay nadie al lado.
Por comodidad se da permiso amplio a todo el mundo. Tampoco se puede saber quién hizo el cambio sin querer.
El camino manual antiguo no se cierra y no se escribe ninguna regla. En un día difícil el equipo vuelve a él y el sistema queda a medio usar.
La misma pregunta se hace a tres personas tres veces. La respuesta se produce de nuevo cada vez y a veces sale distinta.
Trabajo nuevo como pasar la lista de espera o mirar los avisos no se escribe a nadie. Al cabo de un tiempo no lo hace nadie.
Solo una persona sabe usar el sistema. Cuando se va de vacaciones las decisiones se paran y el trabajo no avanza aunque la automatización corra.
Si al terminar la semana de traspaso se puede responder a cada punto de esta lista, el traspaso cuenta como montado.
Términos que salen en las conversaciones de traspaso. Llamar al rol y al permiso siempre igual mantiene la lista legible también el segundo mes.
En esta lección entregó el sistema a las personas: escribió roles y permisos, montó la rutina de la primera semana, nombró la puerta única y puso por escrito las reglas que vivían en una cabeza. La lección que viene trata de medir el resultado y de hacer crecer lo construido.
Si quiere seguir con las lecciones publicadas, viene el módulo que lleva con un registro las excepciones del borde del flujo.
El registro de excepciones, la vía de aviso y la medición que hace visible el fallo silencioso.
El mapa de proceso y la prueba de traspaso. La prueba de aquí es aquella prueba aplicada al sistema.
La sección de formación completa y los módulos añadidos después.
Si quiere que rellenemos juntos la lista de traspaso, escríbanos y sacamos los roles.
Solicitar Presupuesto por WhatsApp