El responsable de operaciones sabe antes que nadie que el sistema ya no da para más. Los procesos que deberían ser automáticos los resuelve alguien manualmente. Las integraciones funcionan, pero solo porque hay una persona que sabe exactamente cómo parchearlas cuando fallan. Los informes que el negocio necesita salen de Excel, no del ERP.
El problema no es técnico. Cuando llega el momento de llevarlo al comité, la conversación se reduce a una sola pregunta: ¿cuánto cuesta?
Y ahí es donde la mayoría de los proyectos mueren. La inversión casi nunca es el problema real. El problema es que nadie ha construido el argumento contrario: cuánto cuesta no hacer nada.
Este artículo propone una forma de hacerlo con rigor financiero.
El punto de partida: qué mide el VAN
Antes de hablar de cómo evaluar el proyecto, vale la pena aclarar con qué herramienta trabajamos.
El VAN (Valor Actual Neto) es el indicador estándar en finanzas corporativas para evaluar proyectos de inversión. Responde a una pregunta concreta: teniendo en cuenta lo que cuesta el dinero en el tiempo, ¿cuánto valor genera este proyecto?
Su lógica es sencilla: un euro de beneficio dentro de tres años vale menos que un euro hoy, porque hoy podrías invertirlo. El VAN descuenta todos los flujos futuros del proyecto (inversión, costes, beneficios) a valor presente y suma el resultado. Si es positivo, el proyecto crea valor. Si es negativo, lo destruye.
La clave está en el tipo al que se descuentan esos flujos. Eso es la tasa de descuento.
La tasa de descuento: de dónde sale y por qué importa tanto
La tasa de descuento expresa el coste del capital: lo mínimo que debe rendir el proyecto para que valga la pena inmovilizar recursos en él durante varios años.
En los business cases que he revisado, la tasa de descuento suele aparecer ya fijada antes de que nadie la discuta: un diez por ciento, o el WACC corporativo (el Coste Medio Ponderado del Capital de la empresa, que combina el coste de los fondos propios y el de la deuda según la estructura financiera). Se copia sin ajuste. (Hay quien defiende usar el WACC sin más, y en empresas muy estables con proyectos de perfil similar al negocio principal tiene su lógica. Pero ese no es el caso de una migración ERP.)
Ese número refleja el riesgo del negocio habitual de la empresa. Una migración ERP no se parece al negocio habitual. Los beneficios dependen de la adopción del sistema, de la reingeniería de procesos, de que el proyecto no se alargue. Ese riesgo adicional debería aparecer en la tasa.
Cómo construirla correctamente
El modelo de referencia en finanzas corporativas es el CAPM (Capital Asset Pricing Model), que construye el coste del capital propio a partir de tres piezas. Antes de ver la fórmula, la intuición:
Tasa mínima exigida = lo que rinde un activo seguro + lo que exiges por asumir el riesgo de este proyecto
Ke = Rf + β · (Rm − Rf)
Rf (tasa libre de riesgo). Lo que rinde un activo sin riesgo. Se usa el bono alemán a diez años, en torno al 2,5% a principios de 2025. Es el suelo: ninguna inversión con riesgo debería exigir menos.
Rm − Rf (prima de riesgo de mercado). La rentabilidad adicional que históricamente ha ofrecido la renta variable frente al activo seguro. Para España se sitúa entre el 6% y el 6,5%, según la evidencia documentada por el profesor Fernández en IESE.
β (beta del sector). Ajusta esa prima al tipo de proyecto. Una beta de 1 equivale al riesgo medio del mercado. Para software empresarial, Damodaran publica valores en torno a 1,2 en sus tablas sectoriales globales.
Con estos datos: Ke = 2,5% + 1,2 · 6,2% ≈ 10%
A eso hay que añadir una prima específica de entre uno y tres puntos porcentuales que recoja el riesgo real del proyecto: retrasos en la implantación, beneficios que no llegan en el plazo previsto, o directamente baja adopción cuando el sistema entra en producción. El resultado para una migración ERP típica debería situarse entre el 9% y el 13%, no en el 7% que sale de copiar el WACC corporativo sin ajuste.
Lo que cambia en los números
Una empresa de distribución, 800 empleados, un sistema implantado hace doce años. Presupuesto de migración: 800.000 euros. Los beneficios crecen progresivamente desde 120.000 euros en el primer año hasta 250.000 euros en el séptimo, a medida que la organización adopta el nuevo sistema.
| Tasa de descuento | VAN a 7 años | Payback descontado |
|---|---|---|
| 8% | +247.000 € | 5,1 años |
| 11% | +112.000 € | 5,8 años |
| 14% | -14.000 € | > 7 años |
El mismo proyecto, los mismos flujos. Con una tasa razonable crea valor; con una tasa algo más alta lo destruye. Elegir bien la tasa no es un trámite: cambia el resultado más que cualquier otra hipótesis del modelo, y es la que más rara vez se discute en el comité.
El escenario que nadie modela: el coste de quedarse
Aquí está el argumento que con más frecuencia falta en los business cases de migración.
Cuando el comité pregunta cuánto cuesta el proyecto, compara la inversión contra cero. Como si mantener el sistema actual no tuviese precio. Pero ese sistema tiene un coste que crece cada año: mantenimiento con escalados contractuales, integraciones que alguien sostiene a mano, licencias auxiliares que cubren lo que el ERP no hace, horas de trabajo dedicadas a procesos que un sistema más maduro automatizaría.
La formulación correcta no compara la inversión contra cero. La compara contra el coste acumulado de no hacer nada:
VAN = −Inversión + Σ (Beneficios del nuevo sistema + Costes del sistema actual evitados) / (1 + r)ⁿ
Los costes del sistema actual evitados son flujos positivos reales y verificables (no estimaciones) que casi nunca entran en el modelo. Ignorarlos infravalora el proyecto, y no por poco.
Y tienen un efecto directo sobre la tasa de descuento. Cuando parte de los beneficios son costes que dejan de pagarse (mantenimiento, licencias, integraciones), la incertidumbre del modelo baja. Menos incertidumbre justifica una prima de riesgo más baja y, por tanto, una tasa menor. Los proyectos de migración hacia sistemas más maduros tienen mejor VAN del que aparece en los modelos habituales. El problema es que casi nunca se construyen con el escenario alternativo correcto.
Conclusión
El responsable operativo que sabe que necesita cambiar de sistema tiene razón. El problema es que llevar esa convicción a un comité requiere un lenguaje distinto: flujos de caja, tasa de descuento, VAN.
Construir ese argumento no es complejo, pero exige dos cosas que rara vez se hacen juntas: elegir la tasa de descuento con criterio (no copiarla) y modelar correctamente el escenario alternativo. Quedarse con el sistema actual no es gratis. Ponerle número a ese coste suele ser la parte del business case que más cuesta defender ante el comité, y a la vez la que más cambia el resultado final.
Referencias
- Damodaran, A. (2025). Betas by Sector (Global). NYU Stern.
- Damodaran, A. (2025). Country Default Spreads and Risk Premiums. NYU Stern.
- Fernández, P. (IESE). Market Risk Premium: Required, Historical and Expected. IESE Insight.
SUSCRÍBETE Y SIGUE
¿Te interesa la evaluación financiera de proyectos tecnológicos?
Este artículo forma parte de una serie de publicaciones sobre metodologías de Corporate Finance aplicadas a la transformación digital. Sígueme en LinkedIn para más análisis, suscríbete al feed RSS o explora artículos relacionados al final de esta página.
Ángel Carlos del Pozo Muela
Executive MBA · Corporate Finance aplicada a proyectos ERPDesarrollo de negocio en el sector tecnológico. Escribe sobre la aplicación de Corporate Finance a la evaluación de proyectos ERP.
Aviso
Las opiniones expresadas en este artículo son personales y no representan necesariamente la posición de ninguna organización con la que el autor esté relacionado.