De la Hoja de Cálculo al Dashboard: Una Historia de Adopción (y Resistencia)
Migrar de Excel a un dashboard suena sencillo. Hasta que el equipo lo boicotea en silencio. El problema nunca fue la hoja de cálculo: fue ignorar a quien la usaba.
Cada proyecto de "transformación digital" que fracasa comparte un rasgo en común. No es técnico ni presupuestario. Es un problema de personas que nadie quiso abordar hasta que fue demasiado tarde.
El patrón se repite con una precisión casi cómica. Dirección decide que "hay que modernizarse". Se contrata un proveedor. Se construye un dashboard con gráficos brillantes y KPIs en tiempo real. Se presenta al equipo en una reunión de 45 minutos. Y tres meses después, todos siguen usando el Excel de siempre.
El dashboard existe. Funciona. Técnicamente es superior en todos los sentidos. Pero nadie lo usa. Y la inversión se convierte en un recordatorio silencioso de que la tecnología, sin adopción, es chatarra cara.
Por qué Excel siempre gana (al principio)
Hay una razón por la que las hojas de cálculo dominan las operaciones de la mayoría de las PYMEs. No es ignorancia tecnológica. Excel tiene algo que casi ningún software corporativo replica bien: el usuario manda.
Cualquiera puede añadir una columna, cambiar un color, meter una fórmula o romper el formato sin pedir permiso a nadie. Sin tickets de soporte. Sin esperar al próximo sprint. Esa flexibilidad genera una sensación de propiedad que no se puede subestimar. Quien construyó esa hoja la siente suya. Conoce cada pestaña, cada celda con fórmula anidada, cada truco que la hace funcionar. Pedirle que la abandone es pedirle que renuncie a su herramienta y, de paso, a su estatus como "la persona que sabe cómo funciona esto".
Y luego está la confianza bruta. Esa hoja lleva años funcionando. Tiene errores, sí. Tiene limitaciones, también. Pero ha sobrevivido a auditorías, cierres de mes y crisis de último minuto. Es un animal imperfecto pero probado en combate.
Ignorar estas fuerzas es el primer error de todo proyecto de migración que acaba muerto.
Anatomía de un fracaso típico
El caso es compuesto, pero los ingredientes son reales. Una empresa de distribución con 40 empleados. Cinco personas en el equipo de operaciones gestionan pedidos, rutas de reparto e incidencias con un ecosistema de seis archivos Excel interconectados que solo dos personas entienden del todo.
Dirección contrata a una consultora para "digitalizar operaciones". Se construye un dashboard con Power BI conectado al ERP. Se configura una base de datos centralizada. Se automatizan reportes. Sobre el papel, el proyecto es impecable.
El día del lanzamiento, el equipo recibe una formación de dos horas. Se les dice que "a partir del lunes, todo se gestiona desde el nuevo sistema". Se retiran los accesos a las carpetas compartidas donde vivían los Excel.
Semana 1: Tres de cinco personas siguen usando copias locales de los Excel en sus escritorios.
Semana 3: El dashboard muestra datos incompletos porque nadie alimenta correctamente los campos obligatorios del nuevo sistema. Los informes de dirección salen con huecos.
Mes 2: El responsable de operaciones pide que le devuelvan "el Excel de rutas" porque el dashboard "no le deja hacer las cosas como antes". Dirección cede "temporalmente".
Mes 4: El dashboard se usa exclusivamente para las reuniones con dirección. El trabajo real sigue en Excel. Nadie lo dice en voz alta, pero todos lo saben.
Coste total: Licencias, desarrollo, consultoría, formación, tiempo perdido. Más de 60.000 euros. ROI: negativo.
Los tres errores que mataron el proyecto
1. Se diseñó para dirección, no para el usuario
El dashboard mostraba KPIs agregados perfectos para una reunión de comité. Pero el equipo de operaciones no necesitaba KPIs. Necesitaba ver pedidos pendientes, rutas asignadas e incidencias abiertas con la misma granularidad que su Excel les ofrecía.
Se construyó la herramienta para quien la aprobó, no para quien la iba a usar ocho horas al día.
2. Se eliminó el viejo sistema antes de que el nuevo demostrara ser mejor
Retirar el Excel el primer día fue un acto de imposición, no de migración. No se dio tiempo a que el equipo comparara, probara y descubriera por sí mismo las ventajas. Se les forzó al cambio y respondieron con la única herramienta que les quedaba: la resistencia pasiva.
3. Se confundió formación con adopción
Dos horas de formación enseñan dónde están los botones. No resuelven el miedo a perder control, la frustración cuando algo no funciona como se espera, ni la sensación de que alguien de fuera ha decidido cómo debes trabajar sin preguntarte primero.
La adopción no es un evento. Es un proceso que dura meses y requiere acompañamiento continuo.
Cómo se hace bien: ingeniería de la adopción
La migración que funciona invierte el orden. No empieza por la tecnología. Empieza por entender el flujo de trabajo actual y respetar la lógica que el equipo ha construido con el tiempo, aunque sea imperfecta.
Lo primero es cartografiar el Excel. Antes de diseñar nada, hay que sentarse con cada usuario y entender qué hace exactamente con la hoja. Qué columnas mira primero. Qué filtros aplica. Qué atajos ha inventado. Qué datos introduce a mano y cuáles copia de otro sitio. El Excel es un mapa del proceso real, no del proceso documentado.
Después, construir lo mínimo que sea claramente mejor. El nuevo sistema no tiene que replicar todo lo que hace el Excel. Tiene que hacer una cosa concreta de forma superior. La actualización automática de un dato que hoy se teclea a mano. Una vista consolidada que hoy requiere abrir tres pestañas. Algo tangible que el usuario experimente como mejora real en su día a día.
Lo que sigue es la coexistencia. Durante semanas o meses, el Excel y el nuevo sistema conviven. El equipo usa ambos. Cuando el nuevo sistema demuestra que es más fiable, más rápido o menos tedioso, el Excel pierde relevancia de forma natural. Nadie lo retira: simplemente deja de ser necesario.
Y por último, iterar con el equipo dentro. Los ajustes no se deciden en una sala de reuniones. Se deciden con el usuario delante de la pantalla, resolviendo fricciones concretas. "Este campo debería autocompletarse". "Necesito poder exportar esto a PDF para el transportista". "¿Por qué tengo que hacer tres clics para algo que antes era un Ctrl+C?". Cada una de esas quejas es un requisito de ingeniería disfrazado de resistencia.
El coste real de ignorar la adopción
Las empresas miden el coste de los proyectos tecnológicos en licencias, horas de desarrollo y hardware. Casi nunca miden el coste de la no-adopción.
Un sistema que se construye pero no se usa cuesta exactamente lo mismo que uno que funciona. Pero devuelve cero. Cada mes que el equipo mantiene el proceso manual en paralelo es un mes de duplicación de esfuerzo, datos inconsistentes entre sistemas y frustración acumulada que cristaliza en una frase demoledora: "Ya lo intentamos y no funcionó".
Esa frase mata el siguiente proyecto antes de empezar.
Cómo trabaja SAUCO en estos casos
En SAUCO, los proyectos de migración operativa empiezan siempre por el mismo punto: la trinchera.
Nuestros ingenieros FDE (Forward Deployed Engineers) se sientan con el equipo que ejecuta los procesos. No con el directivo que los describe en una presentación. Abren los Excel con ellos. Entienden las fórmulas, las macros, los colores que significan cosas que nadie ha documentado. Mapean el proceso real, con sus parches y sus atajos, porque ahí está la verdad operativa.
Después construimos lo mínimo que demuestra valor inmediato. No un dashboard completo con 15 vistas, sino la pieza que elimina la fricción que más duele. Y la ponemos en manos del equipo desde la primera semana, no después de tres meses de desarrollo en silencio.
La adopción no es un paso posterior a la entrega. Es parte del proceso de ingeniería. Si el equipo no lo usa, no hemos terminado. Si el equipo vuelve al Excel, es que nos hemos equivocado en algo y hay que corregirlo, no imponer el cambio.
Esa es la diferencia entre instalar software y transformar operaciones.
¿Tu equipo lleva años prometiendo dejar el Excel? Hablemos de cómo hacerlo sin que nadie vuelva a la hoja de cálculo.