La planilla en la sombra: cómo una copia de respaldo se convierte en el sistema real
Una planilla de respaldo tarda unas doce semanas en volverse el sistema real. El costo de corregirlo depende de la semana en que alguien lo mira.
Cristian Pereyra
Co-fundador · Ingeniería
Un mes después del lanzamiento, alguien del equipo sigue manteniendo su planilla vieja. No lo dice en la reunión de seguimiento, y cuando se le pregunta contesta que la usa por las dudas.
Esa planilla no es un problema de disciplina. Es un recorrido de doce semanas que ya arrancó, y que casi siempre termina igual.
¿Cómo pasa una planilla de copia a sistema real?
En seis pasos, y ninguno parece grave por separado.
Semana 1. Alguien exporta los datos para tener una copia, por las dudas. El dato vive en el sistema. La planilla es una copia y nada más.
Semana 3. Un día de mucho trabajo, un caso se anota solo en la planilla y nadie lo pasa al sistema. El dato empieza a vivir en los dos lados, y ya no dicen exactamente lo mismo.
Semana 5. El equipo empieza a consultar la planilla, porque está más actualizada. Para las preguntas del día a día, la planilla ya es la fuente.
Semana 8. El reporte semanal se arma desde la planilla, porque el del sistema no cierra. La información con la que se toman decisiones sale de ahí.
Semana 12. Los casos nuevos entran primero en la planilla. El sistema se completa después, cuando alguien tiene tiempo.
Mes 6. El sistema es una interfaz apoyada sobre una planilla, y el equipo tiene razón en no confiar en él, porque efectivamente está incompleto.
Nadie decidió nunca crear un sistema paralelo. Cada paso fue razonable en el día en que pasó.
Recorrido ilustrativo
Doce semanas de una planilla de respaldo
¿En qué semana alguien lo mira?
Alguien exporta los datos para tener una copia, por las dudas.
El dato vive en el sistema. La planilla es una copia y nada más.
Un día de mucho trabajo, un caso se anota solo en la planilla y nadie lo pasa al sistema.
El dato empieza a vivir en los dos lados, y ya no dicen exactamente lo mismo.
El equipo empieza a consultar la planilla, porque está más actualizada que el sistema.
Para las preguntas del día a día, la planilla ya es la fuente.
El reporte semanal se arma desde la planilla, porque el del sistema no cierra.
La información con la que se toman decisiones sale de la planilla.
Los casos nuevos entran primero en la planilla. El sistema se completa después, cuando alguien tiene tiempo.
El sistema quedó atrás y se llena por obligación, no por uso.
El sistema es una interfaz apoyada sobre una planilla, y el equipo tiene razón en no confiar en él.
El proyecto se sigue pagando y la planilla es la operación real.
No hay arreglo, hay reinicio
A esta altura no se corrige un desvío, se vuelve a implementar. Y la segunda vez es más difícil que la primera, porque el equipo ya tiene la experiencia de que el sistema anterior no funcionó, aunque el que no funcionó haya sido el acompañamiento.
El costo según la semana en que alguien mira
- Semana 2: Una conversación de diez minutos. La planilla todavía es una copia: no tiene ningún dato que el sistema no tenga. Alcanza con entender por qué existe, resolver el caso que la persona no puede resolver en el sistema, y acordar una fecha para apagarla. No hay nada que recuperar.
- Semana 6: La conversación, más un rato de trabajo manual. Ya hay casos que viven solo en la planilla, así que además de hablar hay que pasarlos al sistema y resolver el campo que el sistema no cubría. Sigue siendo trabajo de días, y el equipo todavía no dejó de usar el sistema.
- Semana 12: Hay que reconstruir antes de poder arreglar. Hay que reconstruir el estado real de los casos abiertos, decidir cuál de las dos fuentes manda, y volver a entrenar al equipo. Lo más caro no es el trabajo: es que el sistema perdió credibilidad, y eso no se recupera migrando datos.
- Nadie lo mira: No hay arreglo, hay reinicio. A esta altura no se corrige un desvío, se vuelve a implementar. Y la segunda vez es más difícil que la primera, porque el equipo ya tiene la experiencia de que el sistema anterior no funcionó, aunque el que no funcionó haya sido el acompañamiento.
El recorrido es ilustrativo y describe el patrón que se repite, no la medición de un cliente. Las semanas exactas varían con cada equipo, el orden de los pasos casi nunca.
¿Por qué la semana en que alguien mira decide el costo?
Porque lo que cambia no es el recorrido, que es siempre el mismo, sino el punto donde se corta.
En la semana 2 la planilla todavía es una copia: no tiene ningún dato que el sistema no tenga. Alcanza con entender por qué existe, resolver el caso que la persona no puede resolver en el sistema, y acordar una fecha para apagarla. Son diez minutos de conversación y no hay nada que recuperar.
En la semana 6 ya hay casos que viven solo ahí. A la conversación se le suma pasar esos casos al sistema y cubrir el campo que faltaba. Es trabajo de días, y el equipo todavía no dejó de usar el sistema.
En la semana 12 hay que reconstruir el estado real de los casos abiertos, decidir cuál de las dos fuentes manda y volver a entrenar al equipo. Lo más caro no es ese trabajo: es que el sistema perdió credibilidad, y eso no se recupera migrando datos.
Si nadie mira nunca, no hay corrección, hay reinicio. Y la segunda implementación es más difícil que la primera, porque el equipo ya tiene la experiencia de que la anterior no funcionó, aunque lo que no funcionó haya sido el acompañamiento.
¿Por qué aparece el respaldo?
Porque es una póliza de seguro, y nadie confía en un sistema nuevo por decreto. La persona que armó ese archivo hace tres años sabe exactamente qué pasa cuando algo se pierde ahí adentro, y todavía no sabe qué pasa cuando algo se pierde en el sistema nuevo.
Mantenerlo cuesta poco las primeras semanas. Son dos minutos por caso, y compra tranquilidad. Nadie decide crear un sistema paralelo: decide no soltar el que le funcionaba.
¿Cómo se ve antes de que alguien lo diga?
Hay cuatro cosas que pasan antes de que el tema llegue a una reunión.
Alguien pide un export completo para tener una copia. Hay campos del sistema que nadie completa, y son justo los que alguien anota en otro lado. Las preguntas del equipo se contestan sin que nadie abra el sistema, porque la respuesta la tiene una persona a mano. Y aparece un archivo compartido con el nombre del proceso y una fecha en el título.
Ninguna de las cuatro es una queja. Por eso no llegan a la reunión de seguimiento, donde todo el mundo dice que viene bien.
¿Qué no hay que hacer cuando aparece?
Prohibirla. Es el reflejo más común y el peor, porque saca la señal de la superficie sin resolver el motivo, y la próxima versión del respaldo va a estar en un archivo personal donde nadie la ve.
Una planilla en la sombra dice una de dos cosas, y las dos son útiles: o esa persona no fue entrenada en su caso concreto, o el sistema no cubre su caso concreto. La primera se arregla en una hora. La segunda es un pedido de producto que llegó gratis, y en general es real: alguien encontró el borde del diseño antes que nosotros.
El guion de la conversación cuando aparece la planilla
Cinco preguntas, en orden, con lo que hay que escuchar en cada respuesta.
- ¿Qué información va a la planilla y no va al sistema? Si la respuesta es "lo mismo", todavía es una copia. Si aparece un campo propio, ahí está el hueco del sistema.
- ¿Hubo alguna vez en que el sistema no tuvo la respuesta? Buscar el episodio concreto, no la opinión general. El respaldo casi siempre nace de un caso puntual que salió mal.
- Si mañana no se pudiera abrir la planilla, ¿qué se pierde? La respuesta dice si ya hay datos que viven solo ahí, que es lo que separa una charla de diez minutos de un proyecto.
- ¿Quién más la mira? Si la consulta alguien más del equipo, dejó de ser un respaldo personal y ya es la fuente de consulta del grupo.
- ¿Qué tendría que pasar para dejar de mantenerla? Es la única pregunta que produce una fecha de apagado, y sin fecha los dos caminos conviven para siempre.
¿Qué se mira en vez de la satisfacción?
Qué porcentaje de los casos del proceso pasó por el sistema. No cuántos casos hubo, ni si la gente dice que le gusta, que es una pregunta que casi siempre se contesta que sí.
A una persona le puede parecer excelente el sistema y no usarlo, y esas dos cosas conviven sin contradicción durante meses si nadie mira el número.
¿Qué se hace en la semana uno para que no aparezca?
Tres cosas, y las tres son de gestión y no de producto.
Entrenar por rol y no por herramienta, para que nadie se siente dos horas a mirar funciones que no va a tocar. Decir quién arregla qué y en cuánto tiempo, porque el respaldo nace del miedo a quedarse sin salida. Y poner fecha de apagado del camino viejo, comunicada antes de arrancar. Sin fecha de apagado, los dos caminos conviven para siempre, y el nuevo pierde por goleada porque el viejo ya sabe funcionar.
Nosotros nos quedamos mirando el uso todo el primer mes en vez de desaparecer al día siguiente del entrenamiento. No es generosidad: es que la diferencia entre la semana 2 y la semana 12 es la diferencia entre una charla y una reimplementación.
¿Cuántas de las planillas que hoy conviven con un sistema arrancaron como respaldo temporal? La respuesta suele ser todas.
Preguntas frecuentes
¿Cómo se sabe si el equipo está usando el sistema de verdad?
Mirando qué porcentaje de los casos del proceso pasó por ahí, no cuánta gente entró ni qué opina. Entrar todos los días y trabajar por fuera es perfectamente posible, y es el patrón más común de baja adopción.
¿Es mala señal que alguien mantenga una copia de los datos?
Durante las primeras semanas no, es esperable. Se vuelve mala señal cuando esa copia empieza a recibir datos que el sistema no tiene, porque ahí dejó de ser una copia y pasó a ser una fuente.
¿Se puede arreglar cuando la planilla ya es la fuente del equipo?
Sí, pero deja de ser una conversación y pasa a ser un proyecto: reconstruir el estado real de los casos, decidir qué fuente manda y volver a entrenar. Por eso conviene mirarlo en la semana dos y no en el trimestre.
Cristian Pereyra · Co-fundador · Ingeniería, StudioChat
¿Querés ver agentes así trabajando para tu equipo?
Hablemos ahora