Calcular el retorno de un proyecto de software sin engañarse
La mayoría de cálculos de retorno omiten el costo de mantenimiento y sobreestiman el ahorro. Este es el modelo completo.
Los costos que suelen faltar
Al presupuesto de desarrollo hay que sumar la infraestructura durante toda la vida útil, el mantenimiento anual —que rara vez baja del quince por ciento del costo inicial—, el tiempo del personal propio dedicado a definición y pruebas, la capacitación, y el costo de la transición mientras conviven el proceso viejo y el nuevo.
Omitir el tiempo del personal propio es el error más frecuente, porque no aparece como desembolso. Pero es tiempo que se deja de dedicar a otra cosa.
Los beneficios que sí se pueden defender
Horas liberadas: número de personas, horas por semana, costo por hora cargado. Es el cálculo más sólido siempre que se sea honesto sobre si esas horas se reasignan o simplemente se dejan de hacer horas extra.Errores evitados: frecuencia actual del error, costo unitario de corregirlo, reducción esperada. Requiere tener medida la frecuencia actual, lo que muchas organizaciones descubren que no tienen.Ingresos adicionales: el más atractivo y el más difícil de atribuir. Conviene ser conservador y presentarlo como escenario, no como línea base.Lo que no se debe forzar en el cálculo
Mejoras de satisfacción, reducción de riesgo reputacional o mejor calidad de la información para decidir son beneficios reales que resisten mal la conversión a pesos.
Intentar cuantificarlos con supuestos frágiles debilita todo el caso de negocio: un evaluador escéptico atacará esa cifra y arrastrará con ella las que sí eran sólidas. Es preferible presentarlos por separado, como beneficios cualitativos declarados.
Presentar escenarios, no un número
Un cálculo único invita a discutir si el número es correcto. Tres escenarios —conservador, esperado y optimista— con los supuestos explícitos de cada uno trasladan la conversación a los supuestos, que es donde debe estar.
Si el escenario conservador ya justifica la inversión, la decisión es clara. Si solo el optimista lo hace, el proyecto necesita otra justificación.
¿Necesita construir el caso de negocio de un proyecto?
Escríbanos con el contexto de su organización. Respondemos con criterio técnico, no con un formulario de ventas.
Contactar