Cuánto cuesta realmente un proyecto de software: las cinco partes del presupuesto

Cuando una empresa decide cambiar o implementar un software de gestión, la conversación casi siempre empieza por el mismo número: el precio de la licencia. Y casi siempre ese número resulta ser el más pequeño de todos los que van a aparecer en el proyecto.

No es un problema de proveedores ni de mala fe. Es un problema de cómo se arma el presupuesto: la mayoría de las empresas pide una cotización, compara la cifra mensual o anual, y decide. El resto de los costos —que existen, son reales y son predecibles— aparecen después, cuando ya no hay margen de negociación.

Este artículo no trata de qué software elegir. Trata de otra cosa: qué debe contener el presupuesto completo de un proyecto de software, y quién paga cada parte.

Las cinco partes de un proyecto, no una

Un proyecto de software de gestión tiene cinco componentes de costo. Si alguno falta en la propuesta, no es que no exista: es que lo vas a pagar de otra forma, generalmente con horas de tu propio equipo.

1. Licencia o suscripción

Es lo que se paga por el derecho a usar el sistema. Puede ser por usuario, por módulo, por sucursal o por volumen de comprobantes. La pregunta que hay que hacer no es solo «cuánto cuesta», sino «qué incluye y qué no»: cuántos usuarios, cuántas empresas, cuántos documentos, qué módulos están dentro y cuáles se cobran aparte.

2. Implementación y configuración

Un sistema en blanco no sirve. Alguien tiene que cargar el plan de cuentas, los ítems, los precios, los clientes, los puntos de emisión, los usuarios y sus permisos, las secuencias y las reglas del negocio. Ese trabajo puede hacerlo el proveedor, tu equipo o una mezcla. Lo que no se puede es no hacerlo.

3. Migración de datos

La información del sistema anterior hay que llevarla al nuevo: saldos, historial, maestros. No es copiar y pegar; es depurar, mapear y validar. Un histórico tributario mal migrado genera problemas durante años. Conviene que este ítem esté escrito con alcance explícito: qué se migra, qué no, y qué pasa con lo que no se migra.

4. Capacitación

Capacitar no es una sesión de dos horas antes de arrancar. Es formar a los usuarios en sus tareas reales, con sus datos reales, y dejar material de consulta. Si el equipo no usa bien el sistema, el sistema no rinde, sin importar cuánto se pagó por él.

5. Soporte y mantenimiento

Los sistemas cambian: cambian las normas, cambian los procesos, cambia la empresa. El soporte cubre incidencias y actualizaciones. La pregunta no es si lo necesitas —lo necesitas— sino qué incluye, con qué tiempo de respuesta y a qué costo se renueva.

Los costos que no aparecen en ninguna cotización

Hay una segunda categoría de costos que casi nunca se presupuesta, porque no los factura nadie: son los internos. Y en proyectos que se salen de presupuesto, casi siempre están aquí.

• Tiempo del equipo clave. El contador, el jefe de bodega, el gerente de ventas y el de sistemas van a dedicar horas a definir procesos, validar datos y probar. Ese tiempo no es gratis: es tiempo que no se dedica a su trabajo.
• Doble operación durante la transición. Hay un período en el que se trabaja en el sistema viejo y en el nuevo a la vez. Es inevitable en un cierre contable, pero su duración depende de la calidad de la planificación.
• Productividad reducida las primeras semanas. Todo cambio de herramienta genera una curva. Se nota más en los procesos de alto volumen: facturación en caja, despacho, atención al cliente.
• Costo de la rotación del personal. Si la persona que entendía el sistema se va, el conocimiento se va con ella. La documentación de la configuración es parte del proyecto, no un extra.

El error clásico: presupuestar por módulo y no por proceso

Un presupuesto armado por módulos dice «facturación, inventario, compras, contabilidad». Es ordenado, pero no responde la pregunta que realmente importa: ¿cómo va a funcionar mi operación el día uno?

El presupuesto útil está armado por procesos: cómo se emite una factura, cómo entra mercadería, cómo se cierra la caja, cómo se atiende un pedido. Cada proceso tiene un dueño, unos datos y unos usuarios. Cuando el proyecto se planifica así, los módulos aparecen como consecuencia y los costos ocultos se vuelven visibles antes de firmar.

Cómo leer una propuesta sin comparar solo el total

Dos propuestas con el mismo total pueden ser proyectos completamente distintos. Antes de decidir, vale revisar que cada una responda explícitamente:

1. ¿Cuántos usuarios incluye y qué pasa si mañana son cinco más?
2. ¿La implementación tiene alcance y fechas, o es «acompañamiento» sin límite definido?
3. ¿La migración está incluida? ¿Con qué datos y qué validación?
4. ¿Cuántas jornadas de capacitación y para cuántas personas?
5. ¿Qué cubre el soporte, con qué horario y qué tiempo de respuesta?
6. ¿Qué cuesta la renovación anual? ¿Sube con la inflación, con los usuarios, con el volumen?
7. ¿Qué pasa si el proyecto se extiende? ¿Hay tarifa por hora adicional?

Una propuesta que contesta estas siete preguntas es comparable con otra. Una que solo da un total, no lo es —aunque el número sea más atractivo.

En nuestro enfoque de implementación y soporte procuramos que esas respuestas estén por escrito desde el inicio, no que se descubran en la primera reunión de seguimiento.

Un rango de referencia: qué proporción ocupa cada parte

No hay una fórmula universal, pero la experiencia en proyectos de gestión para empresas ecuatorianas muestra un patrón bastante estable: la licencia rara vez es la mayor parte del costo de un proyecto bien hecho. Implementación y migración suelen pesar tanto o más que la licencia del primer año, y el costo interno del equipo —ese que no se factura— puede ser comparable a todo lo anterior junto.

Eso tiene una consecuencia práctica: optimizar el 15% de la licencia y descuidar la implementación es una mala decisión económica, aunque se sienta como un ahorro inmediato.

Presupuestar el proyecto completo, no la compra

Un proyecto de software no se parece a comprar un equipo: se parece más a una mudanza. El camión es una parte; las cajas, el embalaje, el tiempo de acomodar todo y los días en que nada está donde debería estar, son la otra. Y quien solo presupuesta el camión casi siempre termina pagando lo demás de su propio bolsillo.

Si estás armando el caso de negocio para un cambio de sistema, en Wide Solutions podemos ayudarte a estructurarlo con estas cinco partes y revisar qué costos internos deberías considerar. Conversarlo antes es mucho más barato que descubrirlo a mitad de la implementación.

Preguntas frecuentes

¿El costo interno del equipo se puede reducir?

Se puede planificar. Con alcance claro, datos depurados antes de empezar y capacitación oportuna, la dedicación del equipo clave baja de forma significativa. Lo que no se puede es eliminarlo.

¿Conviene pagar implementación o hacerla internamente?

Depende de si tu equipo tiene el conocimiento técnico y la disponibilidad. Hacerla internamente suele costar menos en efectivo y más en tiempo y riesgo. La opción híbrida —proveedor configura, tu equipo valida— es la más común en PYMES.

¿Cuánto debe durar la doble operación?

No hay un número único; depende del volumen y del cierre contable. Lo importante es que esté planificada con fecha de fin y con criterios de salida claros.

¿Vale la pena un proyecto por fases?

Frecuentemente sí, sobre todo en empresas con varios procesos críticos. Permite controlar el riesgo y aprender antes de escalar. La condición es que las fases tengan alcance definido y no se conviertan en un proyecto permanente sin cierre.