La frustración en la estabilización (y por qué el Cloud Mindset lo cambia todo)

En el post anterior hablamos de por qué SAP S/4HANA Cloud "no cumple expectativas" en algunos proyectos.

Hoy quiero ir al punto que más me ha costado ver en 18 años de proyectos.

No porque sea técnicamente complejo. Sino porque es humano.

El síndrome del "antes"

Hay una conversación que se repite casi siempre. La he escuchado en manufactura, en retail, en servicios financieros, en diferentes países, en proyectos de distintos tamaños.

"Antes bajaba esto a Excel, lo trabajaba y listo." "Antes el sistema me daba esto de otra forma." "Antes era más rápido."

Y lo que he aprendido después de muchas veces intentar contra-argumentar con lógica es esto:

No se trata de que el "antes" fuera mejor.

Se trata de que era conocido. Y lo conocido da certeza, da control, da comodidad.

El usuario que durante años descargaba a Excel, le daba formato, cruzaba columnas y generaba su reporte… estaba invirtiendo tiempo, esfuerzo y un buen margen de error en algo que hoy el sistema resuelve en tiempo real.

Pero como ese proceso era su proceso, lo percibe como eficiencia.

Y lo nuevo lo percibe como obstáculo.

Esa es la trampa. Y si no la entendemos, nos vamos a pasar el proyecto entero empujando contra una pared que no es tecnológica.

La operación es voraz. Siempre.

Esto hay que decirlo sin rodeos porque es una realidad que no vamos a cambiar:

La operación no espera. El cierre no espera. El cliente no espera.

Y cuando un usuario está entre resolver lo urgente y aprender lo nuevo… siempre va a ganar lo urgente.

He visto esto en proyectos donde la capacitación era excelente, los materiales estaban bien hechos y los tiempos eran razonables. Aun así, el usuario llegaba al go-live con el sistema teórico en la cabeza y el sistema real en las manos... y sin los dos integrados.

¿Qué funciona en la práctica?

Esto no se resuelve con más horas de entrenamiento. Se resuelve con una estrategia diferente:

Involucrar al usuario clave desde las fases tempranas, no como validador, sino como co-constructor. Que toque el sistema antes del go-live. Que se equivoque en ambiente de pruebas. Que llegue al día uno con cicatriz, no con teoría.

El Cloud Mindset: más cerca de lo que creemos

Aquí es donde la conversación cambia. Porque este no es un concepto abstracto de consultoría.

Lo vivimos todos los días.

Uber es la flota de taxis más grande del mundo sin tener un solo taxi. Airbnb es el portal de reservas más grande del mundo sin tener una sola propiedad.

Pero el ejemplo que uso en todas mis ponencias porque es el más honesto, el más cercano y el que nadie puede refutar es este:

Del mapa en papel al GPS.

Antes teníamos el mapa en la guantera. Se compraba en el puesto de revistas. Se actualizaba una vez al año. No te daba tráfico en tiempo real, no calculaba rutas alternas, no sabías cuándo ibas a llegar, no te avisaba del accidente ni del bache ni del peligro adelante.

Llegaron los GPS offline. Mejor, pero todavía rígidos.

Y después llegó Waze, Google Maps. Información en tiempo real. Recálculo dinámico. Inteligencia colectiva de millones de usuarios.

Hoy no sabemos a qué satélite nos conectamos. No auditamos si el dato es correcto. Pero después de que algunos —me incluyo definitivamente— perdimos tiempo por no hacerle caso a la aplicación… que ahora lo tomamos como ley.

Y llegamos en el tiempo exacto que calcula.

¿Entonces qué es el Cloud Mindset?

No es un concepto de consultoría ni una certificación. Es una mentalidad. Es la disposición de confiar en la tecnología antes de entenderla por completo, de soltar el control de cómo se hacían las cosas para abrazar cómo pueden hacerse mejor. Es dejar de preguntar "¿por qué cambiar?" y empezar a preguntar "¿qué gano si lo adopto?". El Cloud Mindset no niega la curva de aprendizaje, la asume. Y en lugar de resistirla, la convierte en ventaja.

La pregunta que hago siempre en mis sesiones con usuarios:

Si adoptaste esa tecnología para mejorar tu vida personal, ¿por qué te resistes a adoptarla en tu trabajo?

Generalmente hay silencio.

Y en ese silencio está la respuesta.

El rol del consultor en este momento

Aquí quiero citar algo que me dijo un directivo de un cliente hace algunos años, y que llevo conmigo en cada proyecto:

"A ti, DOSD TECH, te toca convencer a los usuarios de que usen la herramienta. A mí me toca obligarlos."

Esa frase define perfectamente la tensión.

Porque cuando llegamos al punto de obligar… la relación ya está desgastada. La confianza en el proyecto también. Y recuperar eso cuesta más energía, más tiempo y más recursos que haberlo trabajado desde el inicio.

Convencer siempre es preferible a obligar.

Pero convencer no es dar una buena presentación. Es construir confianza progresiva, demostrar valor temprano y acompañar al usuario en el momento donde más incómodo se siente: el inicio.

Lo que he visto que funciona:

Hacer demostraciones del sistema con los datos reales del cliente, no con datos genéricos de demo. Cuando el usuario ve su propia información en el nuevo sistema, algo cambia. La abstracción desaparece.

Identificar a los usuarios con más influencia informal, los que otros escuchan, y trabajarlos primero. Un usuario convencido que habla bien del sistema vale más que diez capacitaciones.

Celebrar los primeros logros. Un reporte generado en tiempo real que antes tomaba dos horas tiene que convertirse en un caso de éxito interno. No asumirlo. Comunicarlo.

La resistencia al cambio no es irracionalidad. Es autoprotección.

El usuario que se aferra al Excel no es un problema. Es alguien que encontró una forma de hacer su trabajo y no quiere perder esa certeza.

Nuestra labor es darle certeza nueva. No quitarle la vieja sin ofrecer algo mejor.

Y cuando eso se logra, cuando el usuario entiende que el nuevo sistema no vino a complicarle la vida sino a liberarle tiempo para cosas más importantes... la percepción cambia completamente.

En el siguiente artículo voy a hablar de algo que me parece crítico y que pocas veces se aborda desde el ángulo correcto:

La importancia de una buena estrategia de Change Management… vista desde el usuario que la recibe.

Porque hay mucha literatura sobre cómo diseñarla desde el lado consultor.

Pero muy poca sobre cómo se vive desde adentro.