¿Cuánto cuesta realmente un software de empresa? Comparar coste y gestión en el tiempo

«¿Cuánto cuesta un software de gestión?» es una pregunta que recibe una respuesta inútil: depende. La pregunta útil es otra: qué partidas de coste aparecerían en los próximos tres años, cuáles de ellas ya existen hoy bajo otro nombre, y qué debería cambiar en el trabajo diario para que la inversión se justifique. Esta guía sirve para construir ese presupuesto con hipótesis escritas, de modo que cualquiera en la empresa las pueda cuestionar.

No encontraréis cifras. Un precio de mercado escrito aquí quedaría superado en un mes y de todos modos sería falso para vuestro caso. Encontraréis la lista de las partidas y la forma de rellenarla con vuestros números.

Las partidas del proyecto, separadas

El presupuesto único es cómodo para firmar e inútil para decidir. Pedid que se divida, porque cada partida tiene un riesgo distinto y una persona distinta que lo puede reducir.

• Análisis: entender el proceso, las excepciones y los casos límite. Es la partida que se recorta primero y es la que genera los cambios sobre la marcha. Lo que no se entiende antes se paga después.
• Desarrollo: normalmente la partida más grande. Hay que leerla junto con el alcance, porque un desarrollo económico sobre un alcance impreciso no es un ahorro.
• Migración de datos: traer fichas e historial, limpiarlos, decidir qué no traer. Se subestima casi siempre, porque el trabajo real no es técnico sino de decisión: establecer qué versión de un dato es la correcta.
• Formación y acompañamiento: no el curso de dos horas, sino el tiempo de vuestras personas en las primeras semanas, cuando trabajan de dos maneras a la vez.

Las dos últimas partidas se pagan en buena parte en horas internas. Si no las incluís en el presupuesto, el proyecto parecerá costar menos de lo que cuesta y vuestros departamentos parecerán de repente lentos sin una razón escrita en ningún sitio.

Las partidas que vuelven cada año

El coste recurrente decide si el proyecto es sostenible. Una inversión inicial se absorbe; un gasto anual mal estimado pesa mientras el sistema exista. La tabla enumera las partidas y el momento en que aparecen.

Dos preguntas que hacer antes de firmar: qué está incluido en el mantenimiento y qué no, y con qué criterio se establece si una intervención es una corrección o una petición nueva. Es la frontera donde nacen casi todas las discusiones del segundo año.

El beneficio hay que contarlo una sola vez

El beneficio más citado es el tiempo ahorrado, y también es el más fácil de inflar. Tres precauciones lo hacen defendible.

• El tiempo ahorrado se convierte en un ahorro solo si se transforma en algo: más trabajo realizado con las mismas personas, un plazo cumplido, una sustitución que no hace falta. Si las horas liberadas se distribuyen en tareas indefinidas, el beneficio es real, pero hay que escribirlo en otra columna.
• No contéis dos veces el mismo efecto. Si atribuís un ahorro a la reducción de errores, no contéis también las horas ahorradas al corregirlos: es el mismo beneficio mirado desde dos lados.
• Los beneficios inciertos deben declararse inciertos. «Más pedidos gestionables» depende del mercado antes que del software: va en una cuenta aparte, con su hipótesis al lado.

La medida de partida hay que tomarla antes, no reconstruirla de memoria después. Se necesita poco y se obtiene en una semana: cuántas veces al mes se ejecuta la operación, cuánto dura, cuántas personas la tocan, cuántos errores se corrigen.

Comparar escenarios, no justificar el elegido

Un presupuesto construido sobre una sola hipótesis sirve para convencer, no para decidir. Los escenarios que poner al lado son al menos tres, y uno es siempre el mismo.

1. No hacer nada. Tiene un coste, y es el coste actual del problema: horas, errores, retrasos, oportunidades perdidas. Si no se escribe, cualquier otro escenario parece solo un gasto de más.
2. Adoptar algo ya hecho y adaptar la forma de trabajar. Coste inicial menor, cuota previsible, limitación sobre lo que no se podrá cambiar.
3. Hacer desarrollar lo que hace falta, entero o solo la parte que os distingue. Coste inicial mayor, mayor adecuación, y la responsabilidad del mantenimiento en el tiempo.

Existe un cuarto escenario que a menudo vale más que los demás: hacer solo el trozo que más duele y aplazar el resto. Cuesta menos, da una respuesta real en pocos meses y permite corregir las hipótesis con hechos en lugar de con estimaciones.

Verificar tras la puesta en marcha

Es la parte que casi nadie hace, y es la que hace útil todo lo demás. A los seis y a los doce meses se retoman las mismas medidas de partida y se mira qué ha pasado de verdad.

• Las mismas magnitudes, medidas de la misma manera. Cambiar de método entre el antes y el después es la forma más sencilla de demostrar cualquier cosa.
• También los efectos negativos: pasos que se han vuelto más lentos, trabajo desplazado de un departamento a otro, dobles registros que se han mantenido.
• Las partidas de coste que no estaban previstas. Sirven más para el proyecto siguiente que para este, y es el motivo por el que hay que anotarlas mientras suceden.

Cuando las cuentas dicen que no lo hagáis

Lo que esta guía no cubre

Aquí se evalúa la inversión en un software de empresa en su conjunto: partidas, beneficios, escenarios y verificación. Los sistemas basados en modelos de inteligencia artificial tienen partidas propias —consumo ligado al uso, actualización de los modelos, revisión humana de las respuestas— que se comportan de forma distinta y se tratan en otro lugar. También la elección entre sistema de gestión estándar y desarrollo a medida, aquí reducida a dos escenarios, merece una comparación más amplia.