Cuando un software no se usa o no mejora el trabajo, puede haber dificultades técnicas, falta de capacitación, datos poco confiables o acuerdos de gestión que nunca se definieron. No conviene atribuirlo automáticamente a la resistencia del equipo. Seguir una operación completa permite detectar dónde aparece la fricción y decidir si hace falta ajustar el proceso, la implementación o la herramienta.
- Tener un sistema disponible no equivale a usarlo para decidir.
- La duplicación de registros merece investigación, no una acusación automática.
- Una prueba pequeña debe verificar un resultado de trabajo, no solo accesos al software.
- Cambiar de herramienta puede ser necesario, pero conviene saber qué problema debe resolver la siguiente.
El dato está cargado, pero nadie confía del todo
Un cliente pregunta por su pedido. Comercial abre el sistema, encuentra una fecha y consulta por mensaje si sigue vigente. Operaciones responde que hubo un cambio. Administración conserva otra versión en una planilla.
La empresa tiene una herramienta nueva, pero para contestar sigue necesitando reconstruir la historia entre varias personas. La pregunta no es solamente por qué no actualizan el sistema. También es qué dato se considera válido, quién lo cambia y cómo se entera quien lo necesita.
Sin esas respuestas, cargar información puede convertirse en un trámite que se hace después del trabajo, no en una parte útil del trabajo.
El software no resuelve todas las decisiones anteriores
Una plataforma puede mostrar responsables, fechas y estados. Pero alguien tiene que acordar qué significa cada estado, quién se hace cargo del próximo paso y qué ocurre ante una excepción.
Si un pedido figura como terminado, ¿significa producido, entregado o aceptado por el cliente? Si dos áreas usan la misma palabra para situaciones diferentes, una pantalla compartida puede esconder la diferencia en lugar de resolverla.
El informe de la OECD sobre transformación digital de PyMEs identifica barreras como la interoperabilidad limitada, las brechas de habilidades y la falta de cultura de datos. Son cuestiones que conviene mirar junto con las funciones de la herramienta.
Seguir una operación, no discutir impresiones
Antes de reunir a todos para pedir más compromiso con el sistema, elegí una operación reciente. Puede ser una venta, una orden de trabajo o una solicitud de un cliente. Recorré qué pasó desde que empezó hasta que terminó.
¿Quién recibió la información? ¿Dónde la anotó? ¿Qué necesitaba la persona siguiente? ¿Qué tuvo que volver a preguntar? ¿Cuándo se actualizó el sistema? ¿Quién usó ese dato para decidir?
No hace falta buscar un caso excepcionalmente malo. Conviene uno habitual. El propósito es ver cómo se trabaja, no construir una demostración de que alguien incumplió.
Tal vez descubran un campo que exige un dato imposible de conocer al inicio. O que la actualización depende de una persona que recibe la información demasiado tarde. O, efectivamente, que existe una función técnica que no responde a la necesidad.
La planilla paralela puede estar contando algo
Que el equipo mantenga un registro por fuera no demuestra por sí solo que la herramienta sea mala ni que la gente no quiera cambiar. Ese registro puede estar resolviendo una necesidad que quedó afuera: una vista, un cálculo, una autorización o un dato que alguien necesita cada mañana.
Preguntá para qué existe antes de ordenar que lo eliminen. Después evaluá si esa necesidad puede resolverse de manera segura dentro del sistema o mediante una integración adecuada.
También puede ocurrir lo contrario: que el registro paralelo siga por costumbre aunque ya no aporte nada. La decisión debería surgir de revisar el uso, los riesgos y la información que se perdería, no de imponer una única herramienta como un fin en sí mismo.
Probar un recorrido antes de extender el cambio
Una prueba acotada puede ayudar a separar problemas. Elegí un tipo de operación, un grupo de personas y un período razonable. Acordá qué información debe quedar disponible, quién la registra y qué decisión se tomará con ella.
Por ejemplo, una distribuidora podría probar que los pedidos de una línea tengan un estado comprensible y actualizado antes de responder consultas.
La prueba tendría que incluir también qué hacer si el sistema falla, cómo informar una dificultad y cuándo revisar lo aprendido. Durante una transición puede ser necesario conservar controles anteriores. No los eliminen sin verificar dependencias, obligaciones y riesgos con quienes conocen la operación y la tecnología.
Medir el uso que importa
Contar accesos o capacitaciones puede mostrar actividad, pero no alcanza para saber si el trabajo mejoró. Una persona puede entrar todos los días y seguir resolviendo todo por otro canal.
Si el problema era que nadie conocía el estado de los pedidos, la evidencia relevante podría ser si ese dato está disponible y es consistente cuando se necesita. Si el problema era una doble carga, habría que comprobar qué duplicación se eliminó sin perder control.
Los OKRs pueden acompañar un cambio de este tipo si ya identificaron una mejora prioritaria. El objetivo no debería ser usar el software porque lo compramos, sino lograr una forma de trabajar más confiable. Configurar pantallas y capacitar son iniciativas. Los resultados clave describen la mejora observable, con una base inicial y metas acordadas.
En la distribuidora de la apertura, el resultado se juega cuando alguien puede contestar sobre un pedido sin reconstruirlo por mensajes.
Un OKR para confiar en el estado de los pedidos
Ejemplo ilustrativo para un ciclo de hasta 90 días: ajustá cifras y condiciones a la línea de base de tu empresa.
Objetivo: Que las áreas puedan confiar en el estado del pedido cuando necesitan responder o decidir.
Resultado clave 1: Pasar de 6 a 9 de cada 10 consultas habituales resueltas con información vigente del sistema, sin reconstruirla en canales paralelos.
Resultado clave 2: Reducir de 3 a 1 de cada 10 pedidos cuya información visible contradice el estado real al comprobarlo.
Iniciativa posible: Acordar el significado de los estados y quién actualiza cada cambio.
Evidencia y revisión: Contrastá una muestra de registros con pedidos reales y conservá las discrepancias para revisarlas. Los accesos al sistema no sustituyen esa prueba; tampoco se eliminan registros anteriores sin verificar sus dependencias.
Cambiar la herramienta también puede ser una buena decisión
No hay que defender una compra para siempre. Puede haber limitaciones técnicas, costos, riesgos de seguridad o incompatibilidades que justifiquen otra solución. Tampoco hay que insistir con un proceso incorrecto para adaptarlo a una herramienta.
La diferencia está en llegar a esa decisión con una necesidad clara. Qué debe poder hacer el sistema. Qué información necesita intercambiar. Qué capacidades tendrá el equipo para sostenerlo. Qué riesgos y condiciones debe revisar un especialista.
Antes de pedir otra demostración comercial, elegí una operación y reconstruí su recorrido. Quizá la próxima decisión sea cambiar de software. Quizá no. En ambos casos, vas a saber mejor qué estás intentando resolver.
Preguntas frecuentes
¿La falta de uso siempre es resistencia al cambio?
No. Puede haber dificultades de acceso, capacitación, diseño del proceso, calidad de datos o utilidad. También puede haber hábitos que revisar. Escuchar y observar una operación ayuda a distinguir esas causas posibles antes de pedir más disciplina o atribuir falta de compromiso.
¿Hay que eliminar WhatsApp y todas las planillas?
No por principio. Conviene definir qué información debe quedar registrada en un lugar confiable y qué canales sirven para conversar. Antes de retirar registros, revisá dependencias y controles. Una transición puede necesitar apoyos temporales, siempre que no vuelvan confuso cuál es el dato válido.
¿Cómo sabemos si la prueba funcionó?
Comparando el problema inicial con evidencia del trabajo: disponibilidad de información, errores de traspaso o necesidad de volver a cargar datos, según el caso. Definan esa evidencia antes de empezar. Una prueba no funciona solo porque las personas asistieron a la capacitación o iniciaron sesión.
