La transformación digital es un problema de operaciones, no de software
La cifra del 70 % de fracasos que aparece en toda presentación de transformación no tiene fuente verificada. Los estudios que sí midieron señalan la responsabilidad del proceso y el objetivo sin definir.
Contenido
Actualizado el 5 de junio de 2024 — se añadieron datos de 2023 sobre fatiga de cambio y su efecto en la secuencia.
Los programas de transformación digital rara vez fracasan por haber elegido mal la plataforma. Fracasan porque nadie responde del proceso que el software debe ejecutar y porque el objetivo nunca se escribió como cifra. BCG estudió 895 transformaciones y encontró que el 30 % alcanzó sus objetivos. El resto se quedó corto.
Puntos clave
- La cifra del "70 % de transformaciones fallidas" procede de un artículo de Harvard Business Review de mayo-junio de 2000 que la afirma sin cita, muestra ni método.
- Una revisión de 2011 en Journal of Change Management analizó cinco apariciones publicadas de esa cifra y no halló evidencia empírica válida ni fiable que la respalde.
- El estudio de BCG de octubre de 2020 sobre 895 transformaciones digitales situó el 30 % en la win zone, el 44 % en la worry zone y el 26 % en la woe zone.
- Cinco de los seis factores de éxito de BCG describen operaciones; solo el sexto es una decisión de plataforma, y BCG plantea incluso ese desde negocio.
De dónde sale la cifra del 70 % de fracasos
Todas las presentaciones de transformación la citan; casi ninguna cita un estudio. El rastro acaba en "Cracking the Code of Change", Harvard Business Review, mayo-junio de 2000. Ahí Michael Beer y Nitin Nohria afirman que alrededor del 70 % de las iniciativas de cambio fracasa. No hay datos, muestra ni método.
Michael Beer y Nitin Nohria afirman que "the brutal fact is that about 70% of all change initiatives fail" en Cracking the Code of Change, Harvard Business Review, mayo-junio de 2000. El artículo no ofrece muestra, método ni cita para esa cifra.
Mark Hughes puso la afirmación a prueba en lugar de repetirla, y no encontró nada debajo.
Mark Hughes revisó cinco fuentes publicadas de la tasa del 70 % de fracaso en el cambio. Concluyó que no existe "valid and reliable empirical evidence to support such a narrative" (Journal of Change Management, 11(4), 451–464, 2011).
Una tasa de fracaso sin método detrás no indica qué hacer distinto. Solo le pide miedo a un comité de dirección.
Qué encontraron los estudios que sí midieron
En octubre de 2020 BCG publicó resultados de 895 transformaciones digitales: 70 programas que había acompañado y 825 directivos encuestados. Situó el 30 % en la win zone, el 44 % en la worry zone y el 26 % en la woe zone.
El titular queda cerca de la cifra folclórica, pero la forma es distinta. La mayoría de programas no se derrumbó: generó valor y no llegó al objetivo con el que se aprobó. Eso es gobernanza, no software.
BCG nombró además seis factores y reportó que abordar los seis llevaba las probabilidades cerca del 80 %, mientras abordar tres o cuatro no las movía. Cinco son operativos: estrategia cuantificada, compromiso de liderazgo hasta los mandos intermedios, talento, gobernanza ágil y seguimiento contra resultados definidos. El sexto, una plataforma modular de datos y tecnología, BCG lo describe como dirigido por negocio.
La responsabilidad es la variable, no el proveedor
En el número de mayo-junio de 1995 de Harvard Business Review, John Kotter analizó más de 100 compañías que intentaban una transformación mayor. Bastante más de la mitad fracasó en la primera fase — instalar la urgencia — mucho antes de elegir sistema. Veintiséis años después, las preguntas que deciden si un proyecto fracasa se siguen haciendo tras firmar el contrato.
El patrón se repite en los briefs que recibimos. Una empresa compra un CRM para un proceso comercial que nadie ha escrito, o un CMS para una cadena de aprobación sin aprobador. La herramienta codifica esa ambigüedad y la vuelve permanente.
La pregunta que anticipa el resultado no es qué plataforma, sino quién decide cuando el proceso y la herramienta se contradicen. Si la respuesta es un comité, gana el proceso antiguo por inercia y la plataforma queda como una capa de reporting en la que nadie confía.
Escribe el objetivo como cifra antes de la lista corta
Antes de hablar con proveedores deberían existir cuatro líneas en una página: el proceso que cambia, quién responde de él, la métrica base de hoy y el objetivo con su fecha de medición. Es lo que hace utilizable un brief, y sustituir la lista de deseos por criterios de decisión cambia lo que un proveedor propone y lo que un consejo aprueba. La selección pasa a ser un problema de restricciones y no de preferencias, que es la forma honesta de elegir entre Jamstack y WordPress.
Qué cambió en esta actualización
El lado operativo del argumento ya tiene cifra. Una investigación de Gartner publicada en Harvard Business Review en mayo de 2023 encontró que la disposición de los empleados a apoyar el cambio cayó al 43 % en 2022, desde el 74 % de 2016. El empleado medio absorbió ese año 10 cambios planificados, frente a dos en 2016. La secuencia forma parte del diseño. Cuatro programas a la vez acumulan fatiga en lugar de repartir riesgo, una restricción que también marcó los primeros despliegues de IA generativa en producción.
Preguntas frecuentes
¿Es cierto que fracasa el 70 % de las transformaciones digitales?
La cifra no tiene fuente empírica verificada. Aparece sin cita en Harvard Business Review en 2000 y una revisión de 2011 en Journal of Change Management no halló evidencia fiable detrás. El estudio de BCG de 2020 sobre 895 transformaciones encontró que el 30 % cumplió sus objetivos, con método declarado.
¿Cuál es la causa más frecuente de que fracase una transformación?
Los estudios medidos apuntan a operaciones antes que a tecnología. Cinco de los seis factores de BCG hablan de estrategia, liderazgo, talento, gobernanza y seguimiento. Kotter encontró en 1995 que bastante más de la mitad fracasaba en la fase de urgencia, antes de elegir sistema.
¿Cómo se escribe un objetivo de transformación que un consejo acepte?
Nombra el proceso, quién responde, la línea base de hoy, el objetivo y la fecha de medición. Cinco datos en una página. Un consejo puede aprobar o rechazar eso. No puede evaluar "modernizar el stack", porque ningún estado del mundo termina esa frase.
El orden que importa
Escribe el objetivo antes del RFP, nombra un responsable único antes del kickoff y lanza un programa cada vez. La selección de software es la última decisión de la secuencia, no la primera. A los seis meses se sabrá si la métrica base se movió, y si nadie puede decir cuál era, eso ya es el hallazgo.
