Por qué su software no está funcionando (y no es culpa del software)
Compró el sistema, pagó la licencia, instaló el tablero... y seis meses después todo se usa igual que antes, solo que con más pantallas. Si esto le suena, el problema casi nunca es la herramienta: son las cuatro decisiones que la rodean y que nadie tomó.
Es una escena que se repite en miles de empresas: un director compra un sistema —CRM, CMMS, ERP— convencido por la demostración, y meses después el sistema está instalado pero la operación no cambió. Los vendedores multiplican ventas igual que antes, los técnicos registran igual que antes, y el tablero nuevo acumula polvo virtual. La tentación es culpar al software. La evidencia dice otra cosa: el software casi nunca es el problema. Son decisiones alrededor de él que nadie tomó.
Comprar la herramienta sin definir qué cambia es comprar decoración
El software cambia la operación cuando viene con una respuesta a esta pregunta: '¿qué se deja de hacer y qué se hace diferente?'. Si la respuesta es 'ahora registramos todo en el sistema', no hay cambio: hay una tarea extra. El CRM funciona cuando redefine cómo se da seguimiento, no cuando solo digitaliza lo que ya se hacía. El CMMS funciona cuando cambia el mantenimiento de reactivo a planificado. Si nadie definió qué cambia, el sistema es una versión más cara de lo anterior.
El software no se adopta solo: necesita alguien que responda
Todo sistema tiene un momento de fricción: un campo que confunde, un flujo que no calza, una semana donde el equipo aduce falta de tiempo. En esa semana se decide todo. Si hay alguien que responde las dudas, ajusta el sistema y explica el 'por qué', la adopción sobrevive. Si no lo hay, el equipo abandona y regresa a lo cómodo. El software no se adopta solo: se adopta con un responsable que lo defiende los primeros meses. La mayoría de los proyectos sin dueño muere exactamente ahí.
El dato vacío es el asesino silencioso
Un sistema nace muerto cuando se llena con datos vacíos: campos sin completar, registros a medias, clientes sin historial. El equipo lo intuye de inmediato y saca dos conclusiones: 'esto es una pantalla más que llenar' y 'no me sirve para nada'. La primera semana de captura define la percepción para siempre. Por eso la implementación seria no empieza enseñando el software: empieza cargando los datos correctos y definiendo qué se captura con calidad. Un sistema con datos malos no es neutro: es peor que no tener sistema, porque además de inútil genera desconfianza.
Medir la adopción: si el tablero no se consulta, no existió
Hay una métrica que los proveedores no muestran en la demostración: el uso real después de seis meses. ¿Cuántos registros entran por semana? ¿Cuántos usuarios lo abren a diario? ¿El gerente consulta el tablero o sigue preguntando a su equipo por teléfono? Si el número de uso es bajo, el proyecto fracasó aunque el contrato se haya pagado. Medir la adopción es incómodo porque obliga a admitir el fracaso a tiempo —y es exactamente por eso que vale la pena: a los tres meses aún se corrige; a los seis, el sistema ya es otra cosa decorativa.
La resistencia no es pereza: es falta de respuesta al 'para qué'
Cuando un técnico o un vendedor se resiste al sistema nuevo, el dueño suele leerlo como terquedad. La evidencia sobre gestión del cambio lee otra cosa: la resistencia aparece cuando nadie explicó qué gana la persona. El sistema nuevo le pide al técnico registrar más cosas y le devuelve... nada visible. El que se resiste no es perezoso: es racional. El sistema cambia cuando la persona que lo usa obtiene un beneficio claro —trabajo más fácil, información a la mano, menos papeleo. Si el 'para qué' de cada usuario no se diseñó, la resistencia se llama sentido común.
La regla de oro: el sistema que no se usa no es culpa del sistema
Antes de culpar al software, haga estas cuatro preguntas: ¿se definió qué cambia en la operación? ¿Hay alguien que responda por la adopción? ¿Los datos se capturan con calidad desde el día uno? ¿Cada usuario tiene un 'para qué' claro? Si alguna falla, ahí está el problema —y es corregible sin comprar nada nuevo. El software viejo se puede rescatar tomando las decisiones que no se tomaron. Es más barato y más honesto que buscar la siguiente herramienta que resolverá 'de verdad' lo que tampoco resolvimos esta vez.