Las implantaciones de sistemas ERP suelen acabar por encima del presupuesto. El patrón es habitual: la dirección aprueba la inversión con previsiones optimistas, el proyecto arranca con impulso y, entre la configuración y la puesta en producción, los costes se desbordan. Los directores de proyecto más eficaces saben que la mayoría de los fallos presupuestarios no son cálculos financieros erróneos, sino fallos de planificación camuflados como problemas de coste.
La raíz suele estar en la distancia entre lo que los implicados imaginan que requiere una implantación y lo que el trabajo realmente exige. Finanzas espera informes impecables desde el primer día. Operaciones quiere flujos más ágiles al instante. Comercial reclama trazabilidad total del cliente. IT pretende eliminar sistemas redundantes en una sola fase. Cada expectativa puede ser razonable por separado, pero juntas generan un alcance que ningún presupuesto realista soporta sin decisiones estratégicas sobre prioridades y secuenciación.
Los gestores de proyecto que controlan el gasto piensan de otra manera. Tratan la estimación inicial como una hipótesis que hay que validar contra la operativa real. Hacen preguntas incómodas desde el principio. Separan lo que la organización necesita de lo que desea. Construyen presupuestos que reflejan la verdadera envergadura del trabajo, no la versión simplificada que aparece en las primeras conversaciones con proveedores. Y, sobre todo, entienden que controlar costes exige disciplina de alcance, de gobernanza y la firmeza para defender los límites de cada fase, incluso cuando hay presión para incorporar más funcionalidades.
Por qué la mayoría de presupuestos fallan antes de empezar a configurar
Muchos problemas de presupuesto aparecen ya en la fase de planificación, incluso antes de que se haga una sola configuración. La estimación inicial suele centrarse en licencias y una cifra orientativa de servicios según número de usuarios o tamaño de la empresa. Ese enfoque falla porque pasa por alto las variables que realmente determinan la complejidad y el coste de la implantación.
Los costes de un ERP vienen marcados por decisiones sobre volumen y calidad de migración de datos, cuántos procesos se rediseñan, requisitos de integración con sistemas existentes, necesidades de personalización, profundidad de la formación y capacidad interna para participar en pruebas y validaciones. Si estos factores no se consideran desde el principio, surgen luego como ampliaciones de alcance, órdenes de cambio o prolongaciones de plazo que encarecen el proyecto.
En muchas empresas en Madrid, Barcelona, Valencia o en el País Vasco, los responsables descubren el verdadero alcance después de arrancar: el partner comienza a preguntar por filiales, flujos de aprobación, jerarquías de reporting y la calidad de los datos. Para entonces el presupuesto aprobado ya está fijado, y el equipo debe absorber trabajo adicional, recortar alcance en otras áreas o pedir más financiación justificando por qué la estimación original no era realista.
El modelo de presupuesto en cuatro capas para proyectos ERP
Una forma más eficaz de planificar separa la inversión total en cuatro capas con características y necesidades de planificación distintas. Este modelo, que llamamos Marco de inversión por capas, ayuda a elaborar presupuestos que cubren todo el trabajo de implantación y permiten ver con claridad en qué se gasta el dinero.
Capa 1: plataforma y licencias
Aquí entra la suscripción base del software, las licencias por tipos de usuario, los módulos esenciales y los entornos adicionales para pruebas, formación o desarrollo. Los costes de plataforma suelen ser los más previsibles porque responden a tarifas públicas, aunque con frecuencia se subestima la necesidad de tipos de usuario adicionales o módulos que salen a la luz cuando se mapean procesos en detalle.
Capa 2: servicios de implantación
Es donde reside la mayor parte de la inversión inicial: talleres de descubrimiento, diseño de la solución, configuración, puesta en marcha de flujos, ejecución de migraciones, apoyo en pruebas, formación y asistencia del go-live. Para la mayoría de organizaciones esta capa es el mayor coste y la más vulnerable a la expansión de alcance. Por ejemplo, los precios de implantación varían mucho según cuántos procesos haya que rediseñar, cuánta programación a medida se requiera y cuántas iteraciones de prueba se necesiten antes del visto bueno.
Capa 3: integraciones y trabajo sobre datos
Abarca conectar el ERP con otros sistemas, limpiar y preparar datos heredados para la migración, construir informes o cuadros a medida, desarrollar extensiones necesarias y cubrir requisitos de cumplimiento o localización (IVA, SII, adaptaciones para comunidades autónomas, etc.). Estos costes suelen subestimarse porque dependen del estado de los datos y de la complejidad del ecosistema tecnológico existente. No es raro descubrir que datos que parecían limpios requieren una limpieza extensa o que integraciones aparentemente sencillas chocan con limitaciones de API o necesidad de middleware.
Capa 4: adopción y estabilización
Incluye gestión del cambio, formación de usuarios, creación de documentación, programas de superusuarios, resolución post-go-live y el tiempo que necesitan dedicar líderes y dueños de proceso durante todo el proyecto. También contempla la caída de productividad habitual tras el go-live mientras los equipos se adaptan a nuevos flujos. Muchos tratan estos costes como periféricos, pero influyen directamente en si el ERP aporta valor o se convierte en fuente de frustración.
Cuando presentas el presupuesto con este modelo de cuatro capas, los interlocutores visualizan mejor a dónde va el dinero y por qué. La conversación cambia de "¿por qué cuesta tanto?" a "¿qué capas podemos optimizar sin comprometer resultados?", y ese cambio de enfoque suele marcar la diferencia entre un presupuesto que se mantiene y otro que necesita varias revisiones.
Conceptos erróneos que provocan desbordes
Algunos mitos persistentes sobre los proyectos ERP conducen directamente a problemas de presupuesto. Identificarlos a tiempo permite corregir la dirección antes de firmar compromisos.
Mito: el número de usuarios es lo que más encarece. Aunque las licencias crecen con los usuarios, la complejidad de implantación viene marcada por factores operativos. Una empresa con 15 usuarios repartidos en varias sociedades, gestión de almacén, reglas de reconocimiento de ingresos y varias divisas afrontará costes mucho mayores que otra con 50 usuarios y una sola entidad y facturación sencilla. La complejidad, no la plantilla, determina el esfuerzo.
Mito: el proveedor lo hace todo. El proveedor aporta la plataforma, pero el éxito depende mucho de la implicación interna. Los responsables de proceso deben documentar flujos actuales, validar configuraciones, participar en ciclos de prueba y decidir sobre excepciones. Si se subestima el compromiso de tiempo interno, los proyectos se atascan, se alargan y se encarecen.
Mito: todo debe activarse el primer día. Creer que un lanzamiento exitoso implica activar todos los módulos desde el inicio crea alcances inmanejables. Una implantación por fases suele dar mejores resultados: primero la funcionalidad crítica estabilizada y luego añadir complejidad. Aun así, muchas organizaciones resisten hacerlo porque quieren acceder de inmediato a capacidades avanzadas, aunque su personal no esté preparado para usarlas eficazmente.
Mito: los costes ocultos son sorpresas inevitables. La mayoría de los llamados costes ocultos son decisiones aplazadas que no se abordaron en la planificación. La migración de datos no se encarece por arte de magia; se encarece porque nadie evaluó la calidad de los datos antes de firmar. Las integraciones a medida no son sorpresas; son el resultado previsible de no inventariar los sistemas existentes pronto. Gestionar el alcance significa sacar estas decisiones a la luz durante la planificación, no descubrirlas durante la ejecución.
Cómo la estrategia de despliegue afecta al control del presupuesto
La palanca más potente para gestionar el presupuesto es la estrategia de despliegue. Las organizaciones que implantan por fases y con disciplina controlan mejor los costes, logran adopción más suave y tienen mayor satisfacción a largo plazo que las que optan por lanzamientos masivos.
Un enfoque por fases suele seguir este esquema. La fase primero se centra en la base operativa: gestión financiera, reporting esencial, procesamiento de transacciones y los flujos mínimos para cerrar contabilidad y cumplir con obligaciones fiscales y de reporting (por ejemplo, SII si aplica). Esta fase establece el sistema de registro y demuestra que la plataforma aguanta la operativa diaria.
La segunda fase es de estabilización, no de expansión. Tras el go-live se completa al menos un ciclo de cierre financiero, se identifican puntos de fricción que solo aparecen en uso real, se corrigen brechas de adopción y se optimizan configuraciones según la retroalimentación de usuarios. Esta fase a menudo se omite o se acelera, pero es crítica para adquirir confianza antes de añadir complejidad.
La tercera fase introduce expansión: módulos adicionales, automatizaciones avanzadas, analítica más profunda y mejoras que aumentan la eficiencia pero no son imprescindibles para operar. Para entonces la organización ya ha desarrollado buenas prácticas de gestión del ERP y absorbe funcionalidad extra sin desestabilizar procesos clave.
Esta secuencia reduce costes al limitar el alcance que hay que configurar, probar y formar en la implantación inicial. También baja el riesgo al asegurar que lo crítico funciona bien antes de destinar recursos a funcionalidades secundarias. Responsables en empresas de Sevilla, Bilbao o Valencia que adoptan fases reportan menos crisis post-go-live, menor resistencia de usuarios y previsiones presupuestarias más ajustadas.
La evaluación de preparación: un marco práctico
Para evaluar si la planificación es suficiente y el presupuesto puede ser realista, proponemos la Evaluación de preparación ERP, un marco que examina seis dimensiones del proyecto. Cada dimensión tiene una puntuación de 1 a 3 y la suma indica si puedes seguir adelante, necesitas preparación focalizada o conviene pausar para cerrar brechas críticas.
Dimensión 1: definición de alcance
- Puntuación 3: existen mapas de proceso detallados, los módulos se priorizan por fases, lo imprescindible está separado de lo deseable y el alcance de la fase 1 está firmado por los responsables.
- Puntuación 2: el alcance general está definido, pero los límites de fase no están claros y algunos stakeholders esperan características no incluidas formalmente.
- Puntuación 1: el alcance está en términos generales sin documentación de procesos ni secuenciación clara.
Dimensión 2: preparación de datos
- Puntuación 3: se han inventariado las fuentes de datos, los problemas de calidad están documentados, el alcance de migración está definido y hay un plan de limpieza con responsables.
- Puntuación 2: se conocen las fuentes de datos, pero no se ha evaluado su calidad ni existe plan de limpieza formal.
- Puntuación 1: se asume que la migración será sencilla sin evaluación detallada de volumen, calidad o transformaciones necesarias.
Dimensión 3: mapeo de integraciones
- Puntuación 3: todos los sistemas a conectar están documentados, se han definido métodos de integración, se ha comprobado la disponibilidad de APIs y hay responsables asignados por integración.
- Puntuación 2: las integraciones clave están identificadas, pero no se ha validado la viabilidad técnica.
- Puntuación 1: las necesidades de integración se han tratado de forma general sin evaluación técnica detallada.
Dimensión 4: capacidad interna
- Puntuación 3: los dueños de proceso han reservado tiempo para el proyecto, existen planes de relevo para roles críticos y los patrocinadores ejecutivos participan activamente.
- Puntuación 2: los responsables conocen el proyecto, pero no han formalizado compromisos de tiempo.
- Puntuación 1: el proyecto se percibe como una iniciativa de IT con escasa implicación del área de negocio.
Dimensión 5: gestión del cambio
- Puntuación 3: hay plan de gestión del cambio, enfoque formativo definido por grupo de usuario, cadencia de comunicación establecida y red de superusuarios identificada.
- Puntuación 2: la formación está planificada, pero las actividades de cambio no están desarrolladas.
- Puntuación 1: se asume que el cambio ocurrirá de forma natural o se deja para el final.
Dimensión 6: estructura de gobernanza
- Puntuación 3: los derechos de decisión están documentados, hay comité de dirección con reuniones regulares, proceso de control de cambios establecido y rutas de escalado claras.
- Puntuación 2: existe un equipo de proyecto, pero la autoridad de decisión y el control de cambios son informales.
- Puntuación 1: la gobernanza no está definida y las decisiones se toman de forma reactiva.
Una puntuación de 15 o más indica que la organización está bien posicionada para presupuestar y ejecutar con realismo. Entre 10 y 14 conviene cerrar gaps específicos antes de firmar. Por debajo de 10, queda trabajo de planificación crítico; avanzar así implica alto riesgo de sobrecostes y conflictos de alcance.
Aplicación práctica: un escenario
Imagina una consultora de servicios profesionales de tamaño medio en Barcelona que va a sustituir su sistema financiero heredado por un ERP moderno. La dirección aprueba un presupuesto preliminar basado en la propuesta de un proveedor que asume una implantación de seis meses centrada en finanzas y contabilidad de proyectos.
El gestor del proyecto aplica la Evaluación de preparación y obtiene estas puntuaciones: alcance 2 porque, aunque se identifican los módulos centrales, varios responsables esperan funciones no incluidas; preparación de datos 1 porque nadie ha evaluado la calidad de los datos de clientes y proyectos; integraciones 2 porque saben que hay que conectar el sistema de seguimiento de tiempos y el CRM, pero no han validado APIs; capacidad interna 2 porque los responsables están informados pero no han destinado tiempo formal; gestión del cambio 1 porque hay formación prevista pero no hay estrategia de adopción; gobernanza 2 porque existe un equipo pero sin derechos claros.
La puntuación total es 10, lo que indica riesgo alto si siguen adelante. El gestor recomienda un sprint de planificación de cuatro semanas para: realizar una evaluación de calidad de datos con IT y finanzas, documentar con detalle el alcance por fases y conseguir la firma de los responsables, y establecer gobernanza formal con derechos de decisión y control de cambios.
Ese trabajo de planificación retrasa el inicio formal, pero mejora mucho la precisión del presupuesto. La evaluación de datos revela que el 30% de los registros de proyecto tienen información de facturación incompleta y deben corregirse antes de migrar, lo que añade dos semanas y costes adicionales. La definición de alcance deja claro que dos departamentos esperaban informes a medida no contemplados, lo que obliga a revisar la propuesta. La gobernanza evita que peticiones adicionales se integren informalmente durante la ejecución.
Invertir cuatro semanas en preparación evita probablemente un retraso de tres meses y un sobregiro del 40% durante la ejecución. Esto resume por qué los proyectos ERP se salen de presupuesto y qué hacen distinto los gestores eficaces: consideran que el tiempo de planificación no es tiempo perdido y usan marcos estructurados para detectar fallos antes de que se conviertan en crisis.
Medir el éxito más allá del go-live
No basta con que el sistema entre en producción a tiempo y dentro del presupuesto; hay que comprobar si la implantación mejora la operativa. Los gestores eficaces definen métricas de éxito en tres horizontes: inmediato, a corto plazo y sostenido.
Métricas inmediatas (primeros 30 días): comprobar que las transacciones críticas se procesan bien, que el cierre financiero puede hacerse con el nuevo sistema, que los informes esenciales están disponibles y que el volumen de incidencias es asumible.
Métricas a corto plazo (90 días): medir mejora de tiempos de proceso, eliminación de trabajos manuales, aumento de la adopción y capacidad para completar cierres sin escaladas. Indican si el ERP cumple su propuesta de valor principal.
Métricas sostenidas (6–12 meses): evaluar precisión del reporting financiero, mayor visibilidad operativa, capacidad del sistema para soportar crecimiento sin grandes reesfuerzos y ajuste del coste total de propiedad con lo proyectado. Determinan si la inversión estuvo justificada.
Definir estas métricas en la planificación crea responsabilidad sobre los resultados y evita que, tras el go-live, IT declare el proyecto terminado mientras el negocio sigue sin percibir valor.
La gobernanza protege el presupuesto
Una gobernanza sólida separa proyectos ERP que mantienen el presupuesto de los que derivan en desbordes. La gobernanza da la estructura para tomar decisiones, gestionar cambios y mantener la rendición de cuentas durante todo el ciclo del proyecto.
Una buena gobernanza incluye un comité de dirección con representación ejecutiva que se reúne regularmente para revisar avance, resolver decisiones escaladas y asegurar alineación con la estrategia. Este comité debe tener autoridad para aprobar cambios de alcance, reasignar recursos y ajustar plazos cuando haga falta.
Un proceso de control de cambios documenta, evalúa el impacto en coste y plazo y requiere aprobación antes de empezar a trabajar. No impide el cambio; evita cambios descontrolados que erosionan el presupuesto sin aportar valor. Cuando se solicita una nueva funcionalidad, el proceso obliga a debatir compensaciones: qué se retrasa o qué hay que descartar, o qué presupuesto adicional se necesita.
Los derechos de decisión claros eliminan la ambigüedad que provoca retrasos y retrabajos. El modelo de gobernanza especifica quién aprueba diseños de proceso, quién firma pruebas, quién autoriza migraciones y quién da la orden final de puesta en producción. Sin esa claridad las decisiones se revisitan una y otra vez, consumiendo presupuesto y tiempo.
Un registro de riesgos e incidencias mantenido por el gestor del proyecto saca los problemas a la luz y los sigue hasta su resolución. Se revisa en cada reunión del comité, lo que evita que los riesgos se conviertan en crisis antes de que la dirección los conozca. Muchos sobrecostes se podrían haber evitado si los riesgos detectados tempranamente se hubieran atendido a tiempo.
Construir un caso de negocio que refleje la realidad de la implantación
El caso de negocio debe sustentarse en supuestos realistas sobre lo que el sistema entregará y cuándo. Los casos demasiado optimistas crean expectativas que minan el proyecto incluso cuando la ejecución es correcta.
Un buen caso de negocio separa beneficios por fases, indicando qué mejoras llegarán tras el go-live y cuáles dependen de fases posteriores o de adopción que requiere tiempo. Por ejemplo, el reporting financiero puede mejorar en los primeros 30 días, mientras que las ganancias operativas pueden tardar un trimestre mientras los equipos se acostumbran a nuevos flujos.
También debe documentar los supuestos del presupuesto: alcance de la fase 1, estado de los datos, disponibilidad de recursos internos, número de integraciones y nivel de personalización. Si los supuestos cambian, el caso de negocio se actualiza para mantener la transparencia con las partes interesadas.
Incluir una sección de riesgos muestra que la dirección ha pensado en lo que puede fallar y en las medidas de mitigación. Riesgos habituales: problemas de calidad de datos que requieren limpieza, salida de personal clave durante la implantación, integraciones más complejas de lo previsto y adopción más lenta de lo planeado. Reconocer estos riesgos de entrada genera credibilidad y prepara al equipo para ajustar el plan si es necesario.
Por qué los proyectos más fuertes se basan en la contención
Hay una verdad contraintuitiva: los proyectos ERP más exitosos suelen empezar con un alcance reducido. No porque la ambición limitada sea mejor, sino porque la secuenciación disciplinada permite ganar competencia y confianza antes de añadir complejidad.
Muchas organizaciones piensan que más funcionalidades en el go-live significan valor más rápido. En la práctica ocurre lo contrario. Implentaciones grandes y complejas tardan más en configurarse, son más difíciles de probar, requieren formación extensa y multiplican las posibilidades de fallos. Cuando aparecen problemas, afectan a muchos procesos a la vez, complicando el diagnóstico y aumentando la frustración.
Implantar por fases permite concentrar energía en acertar en los procesos clave. Los problemas se limitan a un conjunto menor de funciones, lo que facilita solucionarlos. Los usuarios no se ven abrumados por aprender un sistema nuevo entero de una sola vez. La organización acumula éxitos que facilitan las fases siguientes.
Esto exige que los gestores defiendan los límites de fase aun cuando haya presión para abarcar más. Requiere decir: "Esa funcionalidad es valiosa, pero pertenece a la fase 2" y mantener esa postura cuando aumente la presión. También exige liderazgo que prefiera un progreso sostenible a la apariencia de una transformación completa de golpe.
Las organizaciones que practican esta contención entregan proyectos que se mantienen dentro del presupuesto, cumplen plazos y alcanzan sus objetivos. Entienden que implantar no es una carrera para activar todo cuanto antes, sino un proceso meditado de construir una base estable y crecer desde ella.
Pasos prácticos para gestores que arrancan un ERP
Si vas a liderar una implantación, estas acciones aumentan las probabilidades de ajustarte al presupuesto y generar valor.
Arranca con una evaluación detallada de procesos actuales, calidad de datos y necesidades de integración antes de hablar con proveedores. Esta evaluación es la base para un alcance realista y te ayuda a detectar problemas que afectarán a coste y plazo. Muchas empresas la omiten y confían en el discovery del proveedor, pero los proveedores tienen visibilidad limitada sobre calidad de datos y preparación organizativa.
Elabora un documento de alcance que separe lo imprescindible de lo deseable y organiza las funciones por fases. Involucra a los dueños de proceso para que las prioridades reflejen la realidad operativa, no solo preferencias ejecutivas. Ese documento será la referencia frente a solicitudes de cambio.
Presupuesta usando el modelo de cuatro capas, incluyendo contingencias para riesgos identificados y dejando claro qué no está incluido para evitar suposiciones de cobertura integral.
Establece la gobernanza antes del inicio oficial: define el comité de dirección, la cadencia de reuniones y la autoridad para decidir. Documenta y comunica el proceso de control de cambios y asigna responsables por cada macro área.
Planifica la adopción y la gestión del cambio con el mismo rigor que la configuración técnica. Identifica superusuarios desde el principio, intégralos en las pruebas y prepáralos para apoyar a sus compañeros tras el go-live. Diseña formación por roles centrada en los flujos reales que cada grupo usará.
Diseña un plan de comunicaciones que mantenga informadas a las partes interesadas sin saturarlas. Actualizaciones regulares que destaquen avances, saquen a la luz riesgos y aclaren decisiones ayudan a mantener la confianza y reducen sorpresas de última hora que descuadran presupuesto o plazo.
Comparativa de estrategias para controlar el presupuesto en proyectos ERP
| Estrategia | Costo Adicional | Duración del Proyecto | Nivel de Dificultad | Mejor Para |
|---|---|---|---|---|
| Presupuesto sin análisis previo | +30-50% | Impredecible | Alta | Empresas sin experiencia ERP |
| Modelo de cuatro capas | +10-15% | Controlada | Media | Proyectos medianos a grandes |
| Evaluación de preparación | +5-8% | 2-4 semanas previas | Baja | Cualquier tamaño de empresa |
| Despliegue Big Bang | +40-60% | 4-6 meses | Muy alta | Empresas pequeñas con riesgo bajo |
| Despliegue por fases | +15-20% | 8-12 meses | Media-Alta | Empresas grandes y complejas |
| Gobernanza rigurosa | +8-12% | Según plan | Media | Proyectos de cualquier escala |
| Sin medición post go-live | +25-35% | Extensión indefinida | Alta | No recomendado |
Sobre el autor
Vince Louie Daniot es escritor especializado en negocio y tecnología, con foco en ERP, transformación digital y estrategia operativa. Escribe para ayudar a responsables y equipos de proyecto a tomar decisiones más inteligentes en selección de software, planificación de implantaciones y mejora de procesos. Su trabajo busca transformar temas complejos en pautas prácticas y aplicables para organizaciones en crecimiento.
Preguntas frecuentes
¿Por qué las implantaciones ERP suelen superar el presupuesto inicial?
Normalmente se debe a una definición de alcance incompleta en la planificación, subestimación de la complejidad de la migración de datos, expansión de alcance por solicitudes informales, falta de recursos internos y gestión del cambio insuficiente que alarga la estabilización. La mayoría de los sobrecostes provienen de lagunas en la planificación, no de fallos en la ejecución.
¿Cómo decidir qué funcionalidad incluir en la fase 1 y qué dejar para más adelante?
La fase 1 debe limitarse a lo necesario para operar: gestión financiera, reporting esencial, procesamiento de transacciones y requisitos de cumplimiento. Las funciones que aumentan eficiencia pero no son críticas conviene dejarlas para fases posteriores. El criterio es qué no puedes operar sin ello, no qué estaría bien tener.
¿Qué porcentaje del presupuesto debería destinarse a gestión del cambio y formación?
Se recomienda reservar entre el 15% y el 20% del presupuesto de implantación para gestión del cambio, formación y actividades de adopción. Incluye materiales formativos, sesiones por rol, programas de superusuario, documentación y soporte post-go-live. Muchas empresas destinan menos del 10% y luego sufren baja adopción y periodos de estabilización prolongados.
¿Cómo evitar la expansión de alcance sin parecer inflexible?
Un proceso formal de control de cambios que evalúe cada solicitud contra criterios claros (impacto en negocio, alineación con objetivos de fase, efecto sobre plazo y presupuesto y disponibilidad de recursos) es clave. Reconoce el valor de la petición, explica las compensaciones y ofrece incluirla en una fase posterior definida. Mostrar las alternativas hace visibles los trade-offs y protege el alcance actual.
¿Cuáles son señales de alarma de que un proyecto ERP va hacia un sobrecoste?
Señales tempranas: requisitos añadidos informalmente fuera del control de cambios, pruebas que descubren más problemas de los previstos, recursos internos que se liberan para otras tareas, migraciones de datos que tardan mucho más de lo estimado e integraciones más complejas de lo previsto. También son signos de alerta reuniones de comité pospuestas o con mala asistencia, decisiones que se revisitan y caída de la moral del equipo. Ante estos indicios, hay que actuar de inmediato.