La mayoría de los sistemas se vuelven irritantes mucho antes de que alguien se plantee seriamente reemplazarlos. Una aprobación que tarda un día más de lo necesario puede seguir formando parte de la vida normal durante años. La gente cuenta con el retraso cuando hace planes, y los empleados nuevos aprenden a hacer lo mismo. Aprendemos la extraña secuencia de clics o añadimos diez minutos a una tarea porque diez minutos es más fácil que reconstruir lo que haya creado el problema. Una vez que nos hemos adaptado, podemos dejar de mencionar la molestia aunque sigamos dedicando tiempo a manejarla.
De vez en cuando, alguien se harta y trata de cambiarlo. Una empleada escribe un script para evitar hacer el mismo trabajo manual cada tarde. Puede que solo le funcione a ella, pero un esfuerzo parecido en otra parte de la empresa sugiere que otras personas están chocando con la misma limitación. Cuando esos intentos siguen apareciendo de forma independiente, tenemos algo más que investigar que la frustración de una persona con una herramienta.
La gente empieza a cambiar un sistema antes de que el sistema cambie oficialmente
La empleada que automatiza parte de su trabajo probablemente no esté intentando rediseñar la empresa. Necesita superar la tarea que tiene delante, y su solución reflejará eso. Un equipo en otra parte puede enfrentarse al mismo problema abandonando una parte del proceso oficial. Han respondido de forma distinta, pero ambos han decidido que continuar como se les indicó les cuesta demasiado tiempo.
Los clientes toman decisiones parecidas. Una empresa puede dirigirlos a un servicio en línea, mientras ellos aprenden que llamar por teléfono resuelve las cosas más rápido. La empresa puede seguir promocionando la vía en línea sin entender por qué la gente la evita, o examinar las llamadas para averiguar qué sigue sin permitirles hacer el sitio web.
Una petición inusual aporta poca base para cambiar un servicio. Las solicitudes repetidas de la misma excepción merecen una mirada más atenta, especialmente cuando la gente ha empezado a encontrar sus propias formas de conseguirla. Lo que se trataba como un caso límite puede representar ya suficiente trabajo como para que haya que reconsiderar el proceso original.
La forma antigua puede sobrevivir exigiendo más a todos los que la rodean
Un proceso puede ser cada vez más difícil de mantener y seguir produciendo resultados aceptables. Los clientes esperan una respuesta más rápida de lo que la operación existente puede ofrecer, así que el personal compensa la diferencia manualmente. El cliente recibe una respuesta, y puede que no haya ninguna razón inmediata para que alguien fuera del equipo pregunte cómo ocurrió.
Gestionar excepciones de esta manera puede ser sensato. Reconstruir una plataforma porque falta un campo sería absurdo, y rediseñar un proceso entero por un puñado de casos inusuales podría crear más trabajo del que elimina. Una comprobación manual puede ser una solución perfectamente adecuada durante años.
La dificultad aparece cuando esas adaptaciones se acumulan sin que nadie revise su coste combinado. Cinco minutos extra pasan a formar parte de la tarea, luego alguien dedica el viernes a conciliar dos fuentes. Al final, una empleada con experiencia está haciendo una cantidad impresionante de trabajo para producir el resultado que todos suponen que el sistema ya produce.
La empresa puede seguir pareciendo saludable. Su panel puede mostrar que los pedidos se completan a tiempo sin mostrar cuántas veces intervienen los empleados para que eso ocurra. A medida que aumenta ese trabajo, un rediseño que antes parecía demasiado caro puede empezar a merecer la pena. Hay que saber cuánto esfuerzo requiere el arreglo actual para poder hacer una comparación útil.
Los años anteriores a un gran avance suelen ser desordenados
Las historias de innovación se vuelven mucho más limpias después de que alguien tiene éxito. Una vez que el reemplazo funciona, el sistema antiguo parece obviamente obsoleto y resulta fácil explicar qué querían los clientes desde el principio. Los intentos anteriores suelen recibir menos atención, especialmente cuando eran incómodos de usar o fracasaron comercialmente.
Puede haber un largo periodo en el que todos estén de acuerdo en que algo resulta molesto y nadie haya encontrado una forma suficientemente buena de dejar de hacerlo. Los clientes se quejan del sistema antiguo y después se niegan a cambiar porque la alternativa resuelve una irritación pero introduce otras tres. Puede gustarles lo bastante la nueva función como para probarla y aun así necesitar algo que el servicio antiguo hace mejor.
Un intento fallido todavía puede enseñar algo útil al siguiente equipo. Las personas que probaron un servicio nuevo quizá puedan explicar con precisión qué las hizo volver al anterior. Eso es más útil que saber que no les gustaba el servicio antiguo, porque indica qué debe conservar un reemplazo además de qué necesita mejorar.
Las condiciones alrededor del problema también pueden cambiar entre intentos. Un producto que requería capacidad informática cara hace varios años puede resultar ahora asequible de operar. Otra empresa puede construir algo parecido a la versión que fracasó, pero ofrecerlo a un precio que los clientes pagarán. Varias empresas pueden pasar años intentando eliminar la misma restricción antes de que una encuentre la manera de hacer viable el servicio.
La adopción puede acabar avanzando lo bastante rápido para que el cambio parezca repentino. Una organización puede haber absorbido años de fricción creciente mediante trabajo adicional antes de que exista una alternativa viable. La velocidad del cambio final nos dice poco sobre cuánto tiempo llevaba la gente intentando hacerlo posible.
La fricción también puede significar simplemente que algo es malo
Sería peligroso tratar cada experiencia difícil como evidencia de que se aproxima un cambio mayor. Muchos fundadores se han convencido de que la resistencia de los clientes demuestra que son visionarios cuando, en realidad, los clientes les estaban diciendo correctamente que el producto era desagradable de usar. La dificultad para usar algo es una razón para investigarlo, sin garantía de que la investigación revele nada más que un mal diseño.
También hay sistemas que la gente odia y que sobreviven durante generaciones. Las personas que sufren el problema pueden tener muy poco poder para cambiarlo. Un arreglo puede seguir siendo rentable para quienes lo controlan incluso cuando usarlo es miserable, y la frustración por sí sola no cambiará su incentivo para mantenerlo.
Me importa más lo que la gente empieza a hacer en respuesta y si sus intentos están cambiando. Que varios departamentos construyan de forma independiente versiones de la misma capacidad que falta nos da una razón para examinar esa capacidad. No nos dice si una versión compartida funcionaría, ni si alguien la usaría una vez que existiera. Una solución improvisada que la gente sigue usando pese a sus limitaciones ofrece una evidencia distinta de una que probaron y abandonaron. Ambas pueden ayudar a explicar qué necesitan, incluido por qué un reemplazo aparentemente razonable no ha sido suficiente para convencerlos de cambiar.
La tensión cambia cuando las alternativas se vuelven más fáciles
Una fricción que ha existido durante décadas puede resultar mucho más difícil de justificar cuando baja el coste de evitarla. Un proceso manual que la gente toleraba cuando la automatización requería un proyecto de software de seis meses se ve de otra manera cuando una empleada puede construir una herramienta útil en una tarde. Esa herramienta todavía puede necesitar un trabajo considerable antes de que otras personas puedan depender de ella con seguridad, pero la empleada ha demostrado que al menos una parte de la tarea puede hacerse de otra forma.
Los clientes reconsideran molestias conocidas por razones parecidas. Puede que aceptaran una espera larga porque todos los proveedores disponibles tardaban aproximadamente lo mismo. Un competidor que ofrece un servicio más rápido les da una opción que antes no tenían. El proveedor existente no se ha vuelto más lento, pero ahora los clientes tienen una razón nueva para irse.
Eso también cambia la decisión para la empresa. Mejorar el servicio quizá antes parecía demasiado caro para justificarlo. Perder clientes frente a alguien que ya ha hecho la mejora cambia el coste de dejar las cosas como están. Un trabajo que seguía posponiéndose puede volverse urgente sin que la queja subyacente haya cambiado en absoluto.
El cambio final todavía puede tardar años. No existe una forma fiable de medir la frustración y declarar que un gran avance está a seis meses. Sí podemos, sin embargo, examinar si los intentos sucesivos están resolviendo los problemas que derrotaron a los anteriores y si ahora más personas pueden permitirse probarlos.
Esto forma parte de lo que queremos decir con Anticipate
En ShanVic, Anticipate incluye examinar cambios como estos antes de que una empresa haya decidido una respuesta. Queremos entender qué intenta hacer la gente y por qué el arreglo existente lo dificulta. Las quejas ayudan a identificar dónde mirar; los esfuerzos que la gente hace para rodear un problema nos dan más detalle sobre lo que necesita.
También necesitamos entender cómo mantiene la organización en marcha el arreglo actual. Un proceso que parece estable puede requerir mucha más intervención que hace un año. Saber dónde se va ese trabajo adicional ayuda a determinar si bastaría una reparación normal o si la empresa está compensando repetidamente una limitación que nunca ha abordado.
A menudo, una reparación será suficiente. Cambiar un proceso de aprobación puede resolver el retraso que la gente estaba sorteando, sin necesidad de un proyecto mayor. No hay beneficio en tratar cada procedimiento irritante como el comienzo de una transformación de la industria.
Cuando los intentos siguen repitiéndose, queremos saber qué ha conseguido cada uno y por qué no ha sido suficiente. Una alternativa demasiado cara el año pasado puede ser práctica ahora. Una que ahorra tiempo a los empleados aún puede crear problemas para los clientes. Esos detalles ayudan a una empresa a decidir qué probar y qué tendría que mejorar antes de poder depender del resultado.
No tenemos que esperar a que un reemplazo sea ampliamente aceptado para participar en su desarrollo. Puede valer la pena probar un enfoque incompleto cuando podemos explicar qué ha cambiado desde que fracasaron intentos anteriores. La prueba nos da una manera de averiguar si ese cambio es suficiente.