Por qué fracasan las implantaciones tecnológicas (y cómo decidir mejor)

Índice

• Introducción: el problema que nadie te cuenta antes de firmar
• Parte 1: El mito que hay que desmontar primero
• Lo que dicen realmente los estudios (y lo que no dicen)
• Por qué las cifras de fracaso varían tanto según quién las publica
• La contradicción que nadie te cuenta: ni siquiera el estudio más citado del sector está libre de dudas
• Parte 2: La verdadera causa del fracaso no es la tecnología
• El orden en que se toman las decisiones importa más que las decisiones en sí
• Qué información necesitas antes de hablar con cualquier proveedor
• Los costes ocultos que nadie pone en la propuesta inicial
• Parte 3: Los actores que participan en la decisión (y por qué casi nunca se les escucha a todos)
• El mapa de expectativas que rara vez se dibuja
• Los actores que se incorporan demasiado tarde
• Los conflictos de expectativas más frecuentes
• Parte 4: Lo que enseñan seis décadas de metodología, aunque nadie las lea
• Los tres principios que sobreviven en todos los marcos
• Dónde discrepan los expertos (y por qué también importa)
• Parte 5: El Marco de las 3C — Claridad, Confianza, Continuidad
• Por qué la tecnología no aparece en el modelo
• Cómo aplicar el marco antes de pedir presupuesto
• Cómo aplicar el marco durante la implantación
• Cómo aplicar el marco después del arranque
• Parte 6: Qué cambia si aplicas todo esto
• Si eres quien decide comprar tecnología
• Si eres quien vende tecnología
• Preguntas que deberías hacerte antes de firmar nada
• Conclusión: la tecnología es la variable menos determinante
• Bibliografía completa

Introducción: el problema que nadie te cuenta antes de firmar

Si diriges una pyme de retail o de hostelería y en algún momento has evaluado cambiar tu sistema de punto de venta, tu ERP, o has considerado incorporar inteligencia artificial a tu negocio, probablemente te has hecho la pregunta equivocada. La pregunta que casi todo el mundo se hace primero es «¿qué software elegimos?». Y es comprensible, porque es la pregunta que los proveedores están deseando responder. Pero después de revisar en profundidad la evidencia disponible sobre cómo deciden realmente las organizaciones, cómo se comportan las personas implicadas, qué información hace falta antes de decidir, qué dicen los marcos metodológicos más consolidados del sector, y qué revelan los estudios más citados sobre fracaso tecnológico, la conclusión es incómoda pero útil: la elección del software es, con diferencia, la variable menos determinante de todas las que influyen en si un proyecto tecnológico termina funcionando o no.

Este artículo no habla de productos. No compara fabricantes. No te va a decir qué sistema comprar. Habla de algo mucho más valioso a largo plazo: cómo pensar antes de decidir, qué información necesitas reunir, quién debería participar en la conversación, y qué patrones se repiten —con una consistencia sorprendente— en los proyectos que funcionan y en los que no, independientemente del sector, el tamaño de la empresa o la tecnología elegida.

Parte 1: El mito que hay que desmontar primero

Lo que dicen realmente los estudios (y lo que no dicen)

Es casi imposible leer sobre transformación digital sin toparse con la cifra de que «el 70% de los proyectos de transformación digital fracasan». Se repite en artículos, en presentaciones comerciales, en publicaciones de LinkedIn. El problema es que esa cifra, tal y como se cita habitualmente, es engañosa.

McKinsey, en su investigación sobre transformaciones organizacionales, encontró que menos del 30% de las transformaciones logra mejorar el rendimiento de forma sostenida en el tiempo, y que esa cifra cae hasta apenas el 16% cuando se habla específicamente de transformación digital. Un dato interesante de ese mismo estudio, y que rara vez se menciona: las organizaciones con menos de 100 empleados tienen 2,7 veces más probabilidades de reportar una transformación digital exitosa que las organizaciones con más de 50.000 empleados. Si diriges una pyme, esto debería tranquilizarte: no necesitas los recursos de una multinacional para tener éxito. De hecho, la evidencia sugiere que tu tamaño juega a tu favor.[1]

Boston Consulting Group, por su parte, publicó en 2020 un estudio con una metodología distinta: analizó 825 ejecutivos y 70 proyectos de transformación propios, y concluyó que el 70% de las transformaciones digitales no alcanza sus objetivos completos. Pero aquí está el matiz que casi nunca se cuenta: de ese 70%, un 44% sí generó algo de valor real para la empresa, aunque no cumpliera todos los objetivos previstos, y solo un 26% no generó prácticamente ningún valor. No cumplir el 100% de lo prometido no es lo mismo que fracasar por completo, y tratar ambas cosas como sinónimos distorsiona por completo la conversación.[2]

Por qué las cifras de fracaso varían tanto según quién las publica

La cifra del «70% de fracaso» que circula de forma tan extendida es, en realidad, una mezcla imprecisa de dos estudios con definiciones de éxito completamente distintas: el criterio estricto de McKinsey (mejora de rendimiento sostenida) y el criterio más laxo de BCG (cumplimiento total de objetivos declarados). Cuando alguien combina ambas cifras en un único titular, está comparando peras con manzanas, y el resultado es un mito que suena alarmante pero que no describe con precisión ninguna realidad concreta.[3]

Esto no es un detalle menor. Si tú, como director, decides no acometer una modernización tecnológica porque «el 70% fracasa», estás tomando una decisión basada en una cifra que ningún estudio serio respalda tal y como se te ha presentado. La pregunta correcta no es «¿qué probabilidad tengo de fracasar?», sino «¿qué diferencia a las empresas que logran resultados de las que no?». Y esa pregunta sí tiene respuestas mucho más sólidas, como veremos más adelante.

En el terreno específico de la inteligencia artificial, las cifras son distintas y merecen su propio análisis. Gartner predijo en julio de 2024 que al menos el 30% de los proyectos de IA generativa serían abandonados tras la fase de prueba de concepto antes de finales de 2025, citando como causas la mala calidad de los datos, controles de riesgo inadecuados, coste creciente o falta de claridad sobre el valor de negocio. Lo interesante es lo que ocurrió después: en su revisión de 2026, Gartner confirmó que la cifra real de abandono superó el 50%, y añadió un quinto factor que no había contemplado en su predicción original: la falta de gestión del cambio. Esto es revelador por dos motivos. Primero, porque muestra que incluso las consultoras más reputadas del sector tienden a subestimar inicialmente el peso de los factores humanos frente a los técnicos. Segundo, porque confirma que la IA, específicamente, tiene una tasa de abandono estructuralmente mayor que otros proyectos tecnológicos: un estudio independiente de RAND Corporation, sin intereses comerciales directos en la venta de soluciones de IA, encontró que más del 80% de los proyectos de IA fracasan, aproximadamente el doble que en proyectos de TI convencionales.[4][5][6][7]

La contradicción que nadie te cuenta: ni siquiera el estudio más citado del sector está libre de dudas

Si has trabajado alguna vez cerca de un proyecto de software, es muy probable que hayas oído hablar del CHAOS Report, publicado por The Standish Group desde 1994 y basado en el análisis de más de 50.000 proyectos. Sus cifras muestran una evolución: la tasa de éxito de proyectos de software (entregados a tiempo, dentro de presupuesto y con el alcance acordado) pasó del 16,2% en 1994 al 31% en 2020, con un 50% de proyectos «desafiados» —con sobrecostes o retrasos— y un 19% cancelados por completo. Los tres factores de éxito que este informe cita de forma constante desde hace treinta años son la involucración del usuario, el apoyo real de la dirección ejecutiva y una declaración clara de requisitos.[8][9][10][11]

Pero hay algo que la mayoría de quienes citan el CHAOS Report no mencionan: existe una crítica académica rigurosa que cuestiona la validez metodológica de estas cifras. Un análisis publicado en CiteSeerX, basado en 12.187 previsiones reales de 1.741 proyectos con un valor conjunto de 1.059 millones de euros, concluye que las previsiones de coste y tiempo de los proyectos de TI están sistemáticamente sesgadas por motivos políticos internos dentro de las organizaciones, un sesgo que Standish no corrige en sus propios datos. No se trata de un matiz menor: es una crítica directa a la fiabilidad de la fuente más citada del sector para efectos de comparación (benchmarking).[12][13]

¿Por qué te contamos esto en un artículo pensado para ayudarte a decidir, y no para hacer una revisión académica? Porque si algo debes aprender de toda esta investigación es precisamente esto: desconfía de las cifras que se citan sin verificar su origen, incluso cuando provienen de fuentes aparentemente autorizadas. Y aplica ese mismo escepticismo cuando un proveedor te presente estadísticas de éxito de «otros clientes similares a ti» sin poder mostrarte metodología, muestra o fecha concreta.

Parte 2: La verdadera causa del fracaso no es la tecnología

El orden en que se toman las decisiones importa más que las decisiones en sí

Existe una hipótesis extendida en el sector: que la mayoría de los proyectos tecnológicos no fracasan porque el software elegido sea malo, sino porque las decisiones previas —antes incluso de hablar con ningún proveedor— se tomaron de forma insuficiente, incorrecta o en el orden equivocado. La evidencia disponible respalda esta hipótesis con matices importantes.

Los marcos metodológicos más consolidados del sector, desarrollados de forma completamente independiente entre sí, coinciden en algo llamativo: todos exigen justificar el valor de negocio del proyecto antes de definir su alcance técnico, y definir el alcance antes de ejecutar. PRINCE2 lo llama «justificación de negocio continua», exigiendo que se revise en cada fase del proyecto, no solo al principio. PMBOK, la guía de referencia del Project Management Institute en su séptima edición, eleva el «enfoque en el valor» a principio rector, insistiendo en que entregar algo técnicamente correcto no basta si ese algo no se traduce en un resultado real para el negocio. SAP Activate, la metodología oficial de implantación de SAP, estructura su primera fase, llamada «Discover» (Descubrir), específicamente en torno a formular el caso de negocio antes de tocar cualquier aspecto técnico.[14][15][16][17][18][19]

Esta convergencia entre metodologías que nada tienen que ver entre sí no es casualidad. Sugiere que la secuencia «por qué antes de qué antes de cómo» no es una preferencia de estilo, sino una regularidad empírica sobre lo que reduce el riesgo real de un proyecto.

Qué información necesitas antes de hablar con cualquier proveedor

Si el orden importa tanto, la siguiente pregunta lógica es: ¿qué información necesitas tener antes de dar ese primer paso? La respuesta, según la evidencia disponible, se organiza en unas pocas categorías imprescindibles.

Necesitas, en primer lugar, un mapa honesto de tus procesos actuales, con un responsable identificado para cada uno de ellos y con las excepciones operativas documentadas, no ignoradas. La literatura de ingeniería de requisitos es clara al respecto: entre el 12% y el 71% de los fracasos de proyectos de software se atribuyen a una elicitación de requisitos deficiente, y una cita ampliamente referenciada en este campo sitúa la captura imprecisa de requisitos como el factor principal detrás del fracaso del 90% de los grandes proyectos de software. Un defecto detectado en producción, cuando el proyecto ya está en marcha, cuesta entre 50 y 200 veces más de corregir que si se hubiera detectado durante esta fase inicial.[20][21]

Necesitas, en segundo lugar, una evaluación real de la calidad de tus propios datos: si son exactos, completos, consistentes, fiables y actuales, no una suposición optimista de que «nuestros datos están bien». Un estudio de caso realizado en una organización minorista, mediante entrevistas con especialistas técnicos, analistas de sistemas, gerentes y representantes de negocio, documenta que la exactitud, la inconsistencia, la comprensibilidad y la disponibilidad de la información afectan directamente indicadores tan concretos como el desperdicio, la disponibilidad de producto, las ventas y el cumplimiento de los proveedores. Existe además un marco internacional, la norma ISO 8000, que define de forma verificable qué constituye «calidad de datos» en términos sintácticos, semánticos y pragmáticos, y que puede servir como referencia auditable para saber si tu información es realmente suficiente para decidir.[22][23][24]

Necesitas, en tercer lugar, un presupuesto que incluya los costes que casi nunca aparecen en la propuesta inicial de un proveedor, algo que desarrollamos en el siguiente apartado.

Los costes ocultos que nadie pone en la propuesta inicial

Uno de los patrones más consistentes en toda la evidencia recopilada es que el coste real de una implantación tecnológica casi nunca coincide con el coste presupuestado inicialmente, y no por mala fe, sino porque existe una asimetría de información estructural entre quien vende tecnología y quien la compra. Un modelo de teoría de juegos aplicado a negociaciones B2B, validado con un caso real de la industria de automoción, formaliza matemáticamente por qué el proveedor tiene, casi siempre, más información sobre sus propios costes de producción y sobre el verdadero esfuerzo de implementación que el cliente. Esta ventaja informativa no desaparece por buena voluntad; solo se corrige parcialmente cuando el comprador negocia con transparencia contractual y con suficiente poder de negociación.[25]

A esto se suma un fenómeno bien documentado en la gestión de proyectos: el «scope creep», o desviación progresiva del alcance original. Cada pequeña adición al proyecto —»solo una integración más», «solo un informe adicional»— parece manejable de forma aislada, pero la suma de estas adiciones no rastreadas se convierte en lo que la literatura describe como un «drenaje invisible» de recursos, que ni el cliente ni el proveedor logran controlar si no existe visibilidad compartida en tiempo real. Un estudio reciente de Boston Consulting Group sobre programas tecnológicos a gran escala confirma la magnitud económica de este problema: un retraso de un año en un programa ERP de gran envergadura puede generar sobrecostes equivalentes al 0,5% de los ingresos anuales de la empresa, lo que en una organización de 50.000 millones de euros de facturación puede traducirse en hasta 250 millones de euros perdidos. Aunque tu empresa opere a una escala muy distinta, el principio se mantiene proporcionalmente: cada mes de retraso no gestionado tiene un coste real, no solo un coste de oportunidad abstracto.[26][27][28]

Otro coste sistemáticamente subestimado es el de las horas internas dedicadas al proyecto por tu propio equipo: tiempo de formación, tiempo de migración de datos, tiempo de adaptación de procesos. Ese tiempo no aparece en ninguna factura, pero es tan real como cualquier partida presupuestaria, y su ausencia en el cálculo inicial es una de las razones por las que muchos proyectos «cumplen presupuesto» sobre el papel mientras generan un desgaste organizativo que nadie había anticipado.

Parte 3: Los actores que participan en la decisión (y por qué casi nunca se les escucha a todos)

El mapa de expectativas que rara vez se dibuja

Cuando una empresa decide implantar una nueva tecnología, casi siempre se piensa en el proyecto como una relación entre dos partes: el cliente y el proveedor. La realidad es mucho más compleja, y esa simplificación es, en sí misma, una fuente frecuente de fracaso. En un proyecto tecnológico participan, como mínimo, la dirección general, la dirección financiera, el equipo de operaciones, el responsable de tecnología (si existe), el departamento de compras, el patrocinador funcional del proyecto, el responsable de implantación, el consultor o integrador, el equipo comercial del proveedor, los mandos intermedios, los empleados que usarán la herramienta a diario, los usuarios ocasionales, el cliente final de la empresa, el equipo de soporte posventa, los responsables de seguridad y cumplimiento normativo, y los propietarios del dato dentro de la organización.

Cada uno de estos actores vive el proyecto de forma distinta, tiene información distinta, teme cosas distintas y define el éxito de forma distinta. La dirección general suele temer el riesgo reputacional y la continuidad del negocio; la dirección financiera necesita distinguir una inversión sostenible de una mejora aparente, y suele descubrir demasiado tarde los costes de licencias, mantenimiento, integración, formación y salida que no aparecieron en la propuesta inicial; el equipo de operaciones detecta las fricciones reales antes que nadie, porque es quien convive con las excepciones, los picos de trabajo y los procedimientos alternativos que ninguna demo comercial contempla; y los empleados que usarán la herramienta cada día temen perder tiempo, autonomía, conocimiento acumulado o estabilidad, algo que rara vez se verbaliza abiertamente en las reuniones de decisión.

Los actores que se incorporan demasiado tarde

Uno de los hallazgos más consistentes es que ciertos actores se incorporan al proyecto sistemáticamente tarde, cuando su participación temprana habría evitado buena parte de los problemas posteriores. Los responsables de seguridad, privacidad y cumplimiento normativo suelen entrar en el proyecto cuando ya está prácticamente decidido, lo que genera fricciones evitables relacionadas con la protección de datos, la ubicación de los servidores o las obligaciones regulatorias que deberían haberse resuelto en la fase de diseño, no en la fase de firma. Los usuarios ocasionales o indirectos —quienes usan el sistema con poca frecuencia, desde ubicaciones distintas o en situaciones excepcionales— casi nunca participan en el diseño de la solución, que se piensa casi siempre para el usuario principal, y sufren después las consecuencias de un sistema que no contempló su forma de trabajar. Y los mandos intermedios, que son quienes en la práctica sostienen o bloquean la adopción diaria del cambio, suelen recibir la decisión ya tomada, sin haber participado en ella, lo que limita enormemente su capacidad real de defenderla ante sus equipos.

Los conflictos de expectativas más frecuentes

La convivencia de tantos actores con intereses distintos genera conflictos que se repiten de proyecto en proyecto, independientemente del sector o del tamaño de la empresa. La dirección general quiere rapidez, mientras que operaciones necesita tiempo para adaptar procesos reales sin interrumpir el servicio. El departamento financiero busca previsibilidad presupuestaria justo cuando el alcance del proyecto todavía es incierto. Compras prioriza el precio y las condiciones formales del contrato, mientras que los usuarios finales priorizan la facilidad de uso, algo que rara vez pesa lo suficiente en un proceso de licitación centrado en comparar tablas de funcionalidades. El equipo comercial del proveedor, sujeto a comisiones, cuotas trimestrales y objetivos de cierre, puede prometer plazos o funcionalidades que el equipo de implantación tendrá que reinterpretar después, generando fricción entre lo que se vendió y lo que realmente se puede entregar. Y, quizás el conflicto más silencioso de todos: una empresa puede mejorar su eficiencia interna de forma medible mientras, al mismo tiempo, deteriora sin darse cuenta la experiencia de su cliente final, algo que ningún indicador interno de productividad capturará hasta que ya sea demasiado tarde.

Parte 4: Lo que enseñan seis décadas de metodología, aunque nadie las lea

Los tres principios que sobreviven en todos los marcos

Existen decenas de marcos metodológicos internacionales para gestionar proyectos, gestionar el cambio organizacional y diseñar arquitecturas tecnológicas. Analizamos en profundidad seis de ellos, desarrollados por organizaciones completamente independientes entre sí —el Project Management Institute, AXELOS (creador de PRINCE2), Prosci, John Kotter, Amazon Web Services y SAP— y encontramos tres principios que se repiten en prácticamente todos, pese a que ninguno de estos organismos ha copiado al otro.

El primero es la justificación continua del valor de negocio, ya mencionada en la sección anterior. El segundo es la descomposición del proyecto en fases con puntos de control explícitos, en lugar de una ejecución continua sin revisión: PRINCE2 lo formaliza como «gestión por etapas», SAP Activate lo estructura en seis fases secuenciales con entregables verificables en cada una, y el proceso oficial de gestión del cambio de Prosci organiza su metodología en tres fases equivalentes. El tercero, y quizás el más relevante para este artículo, es que la adopción humana del cambio se trata como una condición de éxito que requiere gestión activa, no como una consecuencia automática de haber entregado un buen producto técnico. El principio número 12 de PMBOK 7 se llama literalmente «habilitar el cambio para alcanzar el estado futuro previsto», situando la gestión del cambio al mismo nivel de importancia que la propia entrega del proyecto. El modelo ADKAR de Prosci va todavía más lejos, argumentando que el cambio organizacional solo ocurre cuando cada persona afectada atraviesa individualmente cinco transiciones: consciencia de la necesidad de cambio, deseo de participar, conocimiento de cómo hacerlo, habilidad para ejecutarlo y refuerzo para sostenerlo. Y John Kotter, tras estudiar cien organizaciones en proceso de transformación, documentó que la mayoría de los intentos fallidos de cambio comparten los mismos errores de liderazgo: no crear suficiente urgencia inicial, no construir una coalición de personas influyentes más allá de la cúpula directiva, y no generar victorias visibles a corto plazo que sostengan la motivación durante procesos largos.[29][30][31][32][33][34][35][19][36][14]

Dónde discrepan los expertos (y por qué también importa)

No todo es consenso. Existe un debate legítimo, sin resolver, sobre cuánta estructura y prescripción necesita realmente un proyecto para tener éxito. El propio Project Management Institute, en 2021, tomó una decisión llamativa: abandonó los 49 procesos prescriptivos que definían su guía anterior y los sustituyó por 12 principios de comportamiento no prescriptivos, argumentando que los principios guían la conducta profesional mejor de lo que la dictan procesos rígidos. PRINCE2 y SAP Activate, en cambio, mantienen estructuras de fases y entregables obligatorios mucho más definidas. Esta discrepancia no es cosmética: refleja una tensión real dentro del propio sector sobre si el rigor viene de seguir un proceso o de aplicar principios con criterio, y esa misma tensión probablemente la vivirás tú al decidir cuánta metodología formal aplicar a tu propio proyecto, dependiendo de su escala y complejidad real.[37][16]

También conviene señalar que los marcos de arquitectura técnica, como el marco de buenas prácticas de AWS para entornos cloud, se centran exclusivamente en la calidad del sistema —seguridad, fiabilidad, rendimiento, coste y sostenibilidad— sin abordar en absoluto la dimensión humana de la adopción. Esto no es un defecto del marco, sino una cuestión de alcance: ningún marco lo cubre todo, y conviene saber qué pregunta responde cada uno antes de aplicarlo como si fuera universal.[38][39]

Parte 5: El Marco de las 3C — Claridad, Confianza, Continuidad

Toda la evidencia expuesta hasta ahora —los estudios de McKinsey y BCG, la literatura sobre calidad de datos y requisitos, el mapa de actores implicados, los principios comunes de seis marcos metodológicos internacionales— se puede organizar en un modelo sencillo, pensado para que puedas aplicarlo sin necesidad de volver a leer ningún informe. Lo llamamos el Marco de las 3C: Claridad, Confianza y Continuidad. No sustituye a la evidencia anterior; la organiza en un lenguaje operativo.

Por qué la tecnología no aparece en el modelo

La ausencia deliberada de la tecnología en este modelo es su característica más importante. La razón es que ninguna de las variables que realmente determinan el éxito de un proyecto —la calidad de la información disponible, el nivel de confianza entre las partes implicadas, la fuerza del liderazgo, el grado de resistencia al cambio, la forma de gestionar el riesgo y la dependencia del proveedor— depende del software elegido. Depende de cómo tu organización se prepara antes, durante y después de esa elección.

El modelo se puede dibujar como tres círculos concéntricos. En el centro está la Claridad: saber, antes de hablar con cualquier proveedor, qué problema se quiere resolver realmente, qué calidad tienen tus datos, cuánto estás dispuesto a gastar de verdad —incluyendo los costes ocultos descritos en la Parte 2— y quién en tu empresa se verá afectado por el cambio. Alrededor de la claridad está la Confianza: la consecuencia directa de haber tenido, o no, esa claridad inicial. Confianza de la dirección en el proyecto, del proveedor en el cliente, del empleado en el cambio, del cliente final en que el servicio no empeorará durante la transición. Y en el círculo exterior está la Continuidad: la capacidad real de tu organización de seguir sosteniendo el proyecto quando aparece el problema inevitable —porque siempre aparece—, algo que depende directamente de cuánta confianza se había acumulado antes de que ese problema llegara.

Esta cadena explica un patrón que aparece una y otra vez en la evidencia recopilada: la resistencia al cambio, el abandono de un proyecto o su fracaso formal no suelen ser la causa raíz del problema, sino el primer síntoma visible de que la claridad y la confianza ya habían fallado antes. Un proyecto con tecnología perfecta pero cero claridad inicial genera desconfianza en la primera sorpresa —un coste oculto, una integración que no funciona como se prometió— y pierde continuidad en el primer tropiezo serio. Un proyecto con tecnología mediocre pero con mucha claridad y confianza acumulada sobrevive a varios tropiezos, porque nadie dentro de la organización tiene motivos reales para abandonarlo a la primera dificultad.

Cómo aplicar el marco antes de pedir presupuesto

Antes de contactar con ningún proveedor, dedica tiempo a ganar claridad real, no aparente. Esto significa documentar tus procesos actuales con sus excepciones, no solo el proceso ideal; evaluar honestamente la calidad de tus datos existentes, en lugar de asumir que están mejor de lo que están; y calcular un presupuesto que incluya personalización, migración, formación y coste de salida, no solo la licencia inicial. Si no puedes resumir en una frase clara qué problema quieres resolver, qué datos tienes disponibles y cuánto puedes gastar de verdad, todavía no estás preparado para hablar con un proveedor, por muy atractiva que suene su propuesta comercial.

Cómo aplicar el marco durante la implantación

Durante la implantación, la confianza se construye o se destruye en tiempo real, y necesita visibilidad compartida entre cliente y proveedor: el estado real de la migración de datos, las desviaciones respecto al alcance acordado y el nivel de adopción por parte de cada colectivo dentro de tu empresa deben ser información viva, no un informe que se revisa una vez al mes. Pregúntate de forma explícita, y con la misma frecuencia con la que revisas tus ventas, quién dentro de tu organización confía menos en el proyecto hoy que hace un mes, y por qué. Es el indicador de alerta más temprano y fiable de que algo va a fallar, mucho antes de que aparezca en cualquier informe financiero o de plazos.

Cómo aplicar el marco después del arranque

La continuidad no se decide cuando aparece el problema; se decide antes de empezar. Si no has acordado de antemano quién dentro de tu organización sostiene el proyecto cuando surja una dificultad seria —un mando intermedio, un patrocinador con autoridad real, un responsable de datos con tiempo dedicado—, ya has decidido, sin saberlo, que el proyecto se abandonará a la primera señal de complicación. Después de la puesta en marcha, mide el retorno real frente al proyectado, documenta las incidencias heredadas de la implantación y compara el alcance final con el acordado al principio. Esa información, aunque el proyecto ya haya terminado, es la que te permitirá aplicar mejor el marco la próxima vez.

Parte 6: Qué cambia si aplicas todo esto

Si eres quien decide comprar tecnología

Deja de pedir presupuestos como primer paso. Construye primero tu propio mapa de procesos, datos y presupuesto real, antes de hablar con ningún proveedor, invirtiendo el orden que la evidencia identifica como la causa más documentada de sobrecostes posteriores. Deja de delegar la decisión exclusivamente en el departamento que la propone —sea tecnología, operaciones o finanzas— e incorpora explícitamente a los actores que con más frecuencia se ignoran: mandos intermedios, usuarios ocasionales, responsables de la calidad de tus propios datos. Y deja de valorar las propuestas comerciales principalmente por precio y por la lista de funcionalidades: valóralas por la claridad de las condiciones de salida, por la transparencia sobre los costes que normalmente quedan ocultos, y por la calidad de las preguntas que el proveedor te hace antes de presupuestar. Un buen proveedor pregunta más de lo que promete.

Si eres quien vende tecnología

Deja de tratar la propuesta comercial como el punto de partida de la relación con tu cliente. Exige, antes de presupuestar, la misma información que tu cliente necesita reunir: su mapa de procesos, la calidad real de sus datos, su presupuesto real. Deja de vender la «solución estándar» como si encajara automáticamente en cualquier organización, y haz explícito qué nivel de adaptación —no del software, sino de la propia empresa— es necesario para que tu promesa comercial sea sostenible en el tiempo. Y comparte de forma proactiva, antes de la firma y no después, las condiciones de salida y de portabilidad de los datos: la asimetría de información que existe estructuralmente entre proveedor y cliente se resuelve mejor con transparencia temprana que con gestión de expectativas tardía, cuando la confianza ya se ha deteriorado.

Preguntas que deberías hacerte antes de firmar nada

Antes de comprometerte con cualquier proyecto tecnológico, hazte estas preguntas con honestidad: ¿podemos describir nuestro proceso actual con el mismo nivel de detalle con el que describimos el proceso futuro que deseamos? ¿Hemos verificado la calidad real de nuestros datos, o simplemente asumimos que son mejores de lo que son? ¿El presupuesto que manejamos incluye personalización, migración, formación y coste de salida, o solo la licencia? ¿Sabemos qué personas dentro de la empresa van a resistirse al cambio y por qué motivo concreto, o lo estamos suponiendo de forma genérica? ¿Conocemos las dependencias críticas de terceros que podrían fallar durante o después de la implantación? ¿Hemos verificado de forma independiente las referencias que nos aporta el proveedor, o confiamos únicamente en su palabra? Y, quizás la más incómoda de todas: ¿existe alguna información que estamos evitando recoger porque tememos que complique o retrase una decisión que ya queremos tomar?

Conclusión: la tecnología es la variable menos determinante

Después de revisar en profundidad cómo deciden las empresas, qué esperan sus distintos actores, qué información necesitan reunir, qué enseñan las metodologías más consolidadas del sector y qué revela la evidencia disponible sobre éxito y fracaso, el hallazgo más importante es también el más contraintuitivo: la tecnología que elijas es, con diferencia, la variable menos determinante de todas las que influyen en el resultado de tu proyecto. Y sin embargo, es prácticamente la única en la que la mayoría de las organizaciones concentra su atención inicial.

La pregunta que de verdad importa no es «qué software elegimos», sino «qué tan preparados estamos, como organización, para sostener con información, con confianza y con liderazgo cualquier elección que hagamos». Si diriges una pyme de retail o de hostelería, esta es probablemente la ventaja más accesible que tienes frente a organizaciones mucho más grandes: no necesitas más presupuesto ni más departamentos para aplicar claridad, construir confianza y sostener la continuidad de un proyecto. Necesitas, sobre todo, criterio. Y el criterio, a diferencia del presupuesto, se puede desarrollar.

Bibliografía completa

McKinsey & Company. «Unlocking success in digital transformations.» McKinsey & Company. Documento oficial de investigación.[1]

McKinsey & Company. «Digital transformation: Improving the odds of success.» McKinsey & Company, 2019. Documento oficial de investigación.[40]

McKinsey & Company. «How to gain and sustain a competitive edge through transformation.» McKinsey & Company, 2023. Documento oficial de investigación.[41]

Boston Consulting Group. «Flipping the Odds of Digital Transformation Success.» BCG, 2020. Informe de consultora.[2]

Boston Consulting Group. «Most Large-Scale Tech Programs Fail: How to Succeed.» BCG, 2024. Informe de consultora.[28]

BCG Platinion. «Why 70% of Transformations Miss the Mark and How to Fix Them.» BCG Platinion, 2026. Análisis de consultora.[42]

Consultancy.com.au. «BCG: Only 1 in 3 digital transformation projects are successful.» 2021. Artículo periodístico especializado.[43]

Reliamag. «Do 70% of Digital Transformations Fail? Tracing the Number.» Reliamag, 2026. Análisis periodístico de fuentes primarias.[3]

Integrate.io. «50 Statistics Every Technology Leader Should Know in 2026.» Integrate.io, 2026. Recopilación de estadísticas del sector.[44]

Gartner. «Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept By End of 2025.» Gartner, comunicado de prensa, 2024.[6]

Gartner. «Why 50% of GenAI Projects Fail — And How to Beat the Odds.» Gartner, artículo oficial.[7]

Note.com. «50% of Generative AI Projects Have Disappeared.» 2026. Análisis basado en predicciones de Gartner.[5]

ConnectedPaths. «AI Project Failure Statistics – everything you need in 2026.» ConnectedPaths, 2026. Recopilación de estadísticas.[45]

HeyClarity. «The Real Reason 87 Percent Enterprise AI Projects Fail to Scale.» HeyClarity. Análisis de causas de fracaso en IA.[4]

LinkedIn (atribuido a Gartner). «Gartner: AI projects fail due to bad data management.» Publicación profesional con datos atribuidos a Gartner, 2025.[46]

MIT Sloan Management Review / ThoughtSpot. «Generative AI for Data and Analytics: How Early Adopters Are Reaping the Rewards.» MIT Sloan Management Review, 2024. Encuesta a 1.000 líderes de datos y negocio.[47]

The Standish Group. «CHAOS Report.» Serie histórica 1994-2020. Estudio de la industria del software.[9][48][10][49][50][11][51][52][8]

CiteSeerX. «The rise and fall of the Chaos report figures.» Estudio académico crítico sobre metodología del CHAOS Report.[13][12]

Scribd / Cercle de Discussion. «WhySDPMLecture1.» Recopilación académica de datos históricos de proyectos de software 2004-2012.[53]

LinkedIn (Bruno Freitas Braga). «Chaos Report: IT Project Success Rate Decreased.» Análisis profesional del CHAOS Report.[54]

University of Texas at Dallas. «The Standish Group Report CHAOS.» Documento académico de referencia, 1995.[51]

RockstarDeveloperUniversity. «Software Project Failure Statistics 2026: 40+ Stats.» 2026. Recopilación de estadísticas de la industria.[55]

Henny Portman. «Review CHAOS Report 2018.» Blog profesional especializado en gestión de proyectos, 2020.[52]

Semanticscholar (autor no identificado en snippet). «Exploring the Impact of Data Quality on Decision-Making.» Estudio académico.[56]

Jurnal Penerbit Daarul Huda. «Dampak Kualitas Data Terhadap Pengambilan Keputusan Bisnis.» Publicación académica regional (Indonesia).[57]

Universidad de Malakand (ICIC 2016). «Causes and Impact of Slipped/Misunderstood Requirements.» Actas de congreso académico.[20]

PMC (National Institutes of Health). «Overview of Data Quality: Examining the Dimensions.» PMC, 2023. Revisión académica revisada por pares.[58]

Journals.co.za. «Decision making in the context of business intelligence and data quality.» Estudio de caso en organización de retail.[22]

SciOpen. «Attribute of Big Data Analytics Quality Affecting Business Decision-Making Performance.» Journal of Systems and Computers, 2023. Estudio con encuesta a 382 profesionales.[59]

IISIT (International Institute for Science, Technology and Education). «Requirements Elicitation Problems: A Literature Analysis.» Davey, 2019 (referenciado). Revisión de literatura académica.[21]

Springer. «The Effects of Requirements Elicitation Issues on Software Project Performance: An Empirical Analysis.» Estudio empírico académico.[60]

Ejournal Arimbi. «Analisis Kualitas Data dan Dampaknya terhadap Pengambilan Keputusan.» Publicación académica regional (Indonesia).[61]

Universiteit Utrecht (ICS Archive). «BIDQI: The Business Impacts of Data Quality Interdependencies.» Reporte técnico académico, 2019.[62]

Springer. «Using error abstraction and classification to improve requirement quality: conclusions from a family of four empirical studies.» Empirical Software Engineering.[63]

Academia.edu. «A study on the software requirements elicitation issues: Its causes and effects.» 2018. Estudio académico.[64]

ACM Digital Library / IET Software. «Requirements elicitation techniques: a systematic literature review based on the maturity of the techniques.» Revisión sistemática de literatura.[65]

IDEAS/RePEc (Bodendorf, F.). «Information Asymmetry in Business-to-Business Negotiations.» Group Decision and Negotiation, 2022. Modelo de teoría de juegos validado con caso de la industria de automoción.[25]

DiVA Portal. «Minimizing Defects Originating from Elicitation, Analysis…» Tesis académica.[66]

Wikipedia. «ISO 8000.» Recurso de referencia general, 2008 (última consulta 2026).[67]

ISO (International Organization for Standardization). «ISO 8000-150:2022.» Documentación oficial de la norma.[68]

Datos.gob.es (Gobierno de España). «Technical Standards to achieve Data Quality.» Blog oficial de datos abiertos del Gobierno de España.[69]

Standards.iteh.ai. «ISO 8000-8:2015 – Data quality — Part 8.» Catálogo oficial de normas.[23]

Parseur. «ISO 8000 and Data Extraction – Building Reliable…» Blog especializado, 2025.[70]

Quality.arc42. «ISO 8000 — Data Quality.» Recurso técnico especializado, 2026.[24]

ISO. «ISO 8000-8:2015.» Documentación oficial de la norma.[71]

University of Arkansas at Little Rock (ICIQ 2017). «ISO 8000-61 Data Quality Management Standard.» Actas de congreso académico.[72]

ECCMA (Electronic Commerce Code Management Association). «What is ISO 8000?» Documentación oficial del organismo certificador, 2026.[73]

RMG. «The data quality management system (ISO8000).» Recurso profesional especializado, 2023.[74]

ESJ East-South Institute. «Analyzing Scope Creep Control in Information Technology…» Publicación académica.[26]

Robere.co.id. «ISO 8000-1 Data Quality Management for Digital Transformation.» Blog especializado, 2025.[75]

University of Maryland (EPM). «The Hidden Costs of Scope Creep: Why Your Projects Are Falling Behind.» Recurso académico de gestión de proyectos.[27]

LinkedIn Advice. «What are the key components of the ISO 8000 data quality standard?» Recurso profesional colaborativo, 2024.[76]

Data Quality Pro. «ISO 8000: A New International Standard for Data Quality.» Benson, P. (ISO 8000 Project Leader), 2009.[77]

Project Management Institute (PMI). «PMBOK Guide.» Documentación oficial, 2021.[78]

Alumni JNTUA. «PMBOK Guide 7th Edition.» Documento oficial en formato PDF.[79]

PMBOK.guide. «PMBOK 7 principles.» Recurso oficial de referencia sobre los 12 principios.[14]

Project Management Compass (Substack). «Inside PMBOK 7: The 12 Principles of Modern Project Management.» 2025.[80]

Scribd. «12 Principles of PMBOK 7th Ed PMP.» Documento compartido, 2026.[81]

Tegnum.edu.pe. «A Guide to the Project Management Body of Knowledge.» Documento académico oficial.[29]

Scribd. «PMBOK Guide 7th Edition (12 Principles).» Documento compartido, 2026.[82]

Prosci. «Proceso de 3 Fases de Prosci.» Documentación oficial de metodología de gestión del cambio.[30]

NILC (National Institute for Learning and Compliance). «PRINCE2 Principles.» Chapter 2, documento oficial, 2023.[15]

OnlinePMCourses. «Project Management Principles: Ultimate Guide to the Top 5 FAQs.» 2026.[37]

Techademy. «Project Management Principles: PMBOK 7 Guide.» 2026.[16]

Prosci. «El Modelo ADKAR de Prosci.» Documentación oficial del modelo de cambio individual.[31]

PRINCE2.com (EUR). «The 7 principles, practices and processes of PRINCE2.» AXELOS, 2014.[32]

PRINCE2.com (UK). «Understanding the seven principles in PRINCE2.» AXELOS, 2014.[17]

Scribd (Celeste SP Ng). «2022 Celeste PMBOK 7th Edition Principle.» Documento compartido, 2025.[83]

Kotter Inc. «The 8-Step Process for Leading Change.» Dr. John Kotter, documentación oficial, 2026.[33]

AWS (Amazon Web Services). «AWS Well-Architected Framework.» Documentación oficial, 2022.[84]

AWS. «Framework AWS Well-Architected.» Documentación oficial en PDF (italiano).[85]

AWS. «The pillars of the framework – AWS Well-Architected Framework.» Documentación oficial.[38]

AWS. «AWS Well-Architected – Build secure, efficient cloud applications.» Documentación oficial, 2026.[39]

SAP. «SAP Activate | Accelerate SAP Cloud ERP Deployment.» Documentación oficial, 2026. [18]

Connecticut State Department of Education (portal.ct.gov). «John Kotter’s Eight Step Change Model.» Recurso educativo institucional.[34]

AWS (es_es). «Los pilares del marco – AWS Well-Architected Framework.» Documentación oficial en español.[86]

SAP (Germany). «SAP Activate | Beschleunigter Umstieg auf SAP Cloud ERP.» Documentación oficial en alemán, 2026. [87]

AWS (es). «AWS Well-Architected: Desarrolle aplicaciones seguras.» Documentación oficial en español, 2026.[88]

YouTube. «Kotter’s 8-Step Change Model Explained.» Vídeo educativo, 2021.[89]

Rework.com. «Kotter’s 8-Step Change Model Explained (With Examples).» Recurso profesional, 2026.[35]

SAP Learning. «Utilizing the SAP Activate Implementation Methodology and SAP Cloud ALM.» Curso oficial de SAP, 2024.[19]

SAP (Spain). «SAP Activate | Acelere la implementación de SAP Cloud ERP.» Documentación oficial en español, 2026. [36]

BiteSize Learning. «Kotter’s 8-Step change model, explained.» Recurso educativo, 2024.[90]