Qué preguntar a un proveedor de software antes de firmar

Cuando compras una máquina, sabes qué preguntar: qué produce, cuánto consume, qué garantía tiene, quién la repara. Cuando compras software a medida, apenas tienes referencias, y la falta de estas referencias puede generar problemas más adelante en la colaboración.

La siguiente lista está hecha desde tu perspectiva, la de quien firma. No son preguntas técnicas. Son las preguntas que muestran cómo será la relación dentro de un año, cuando el entusiasmo del principio se haya agotado.

1. A quién pertenecen los datos y cómo los extraigo del sistema

Una de las primeras preguntas. Los datos del sistema (clientes, ofertas, precios, pedidos, historial) pertenecen a tu empresa. Tienes que poder responder con claridad a:

• ¿puedo exportar los datos en cualquier momento, por mi cuenta, sin pedírselo a nadie?
• ¿en qué formato se extraen: uno que pueda leer otro programa o solo un archivo propio de ellos?
• si mañana termino la colaboración, ¿qué me llevo conmigo?

Un proveedor serio responde de inmediato y sin rodeos. Si la respuesta es vaga o condicionada, ya has averiguado algo importante.

2. Qué ocurre con el código

Que el software esté hecho a medida para ti no significa automáticamente que sea tuyo. Hay varias opciones posibles, todas legítimas, pero tienes que saber en cuál te encuentras:

• el código te pertenece y te lo entregan;
• el código pertenece al proveedor y tú tienes derecho de uso;
• opción intermedia: licencia exclusiva, con acceso al código bajo ciertas condiciones.

No importa tanto cuál sea la opción, sino que quede por escrito en el contrato antes de firmar, y no discutirse después.

3. Quién puede trabajar en el sistema además de vosotros

Una pregunta sencilla con grandes implicaciones: si dentro de dos años quiero que continúe otra persona o equipo, ¿es posible?

Lo que revela la respuesta: si el sistema está construido sobre tecnologías conocidas y documentadas, cualquier equipo competente puede tomar el relevo. Si está desarrollado sobre algo que solo ellos utilizan, tendrás un único proveedor posible para siempre, y ellos lo saben.

4. Qué significa «modificación» y cómo se paga

Aquí suelen surgir malentendidos. Tras el lanzamiento es muy probable que aparezcan solicitudes de modificación, porque es entonces cuando tu equipo comprende realmente lo que necesita.

Pregunta antes:

• cómo se estima una modificación y quién aprueba dicha estimación;
• qué entra dentro del mantenimiento y qué se factura aparte;
• qué ocurre con los errores: ¿un error en una funcionalidad ya pagada se repara en garantía o se factura?

La diferencia entre «reparación» y «modificación» debe definirse en el contrato, no negociarse en mitad de un problema.

5. Cómo es la entrega

Un proyecto no termina cuando el sistema funciona, sino cuando tu equipo lo utiliza sin tener que preguntar a nadie.

Pregunta qué recibes al final: instrucciones de uso para cada rol de la empresa, una sesión de formación, un documento que explique dónde residen los datos y cómo realizar una modificación de catálogo sin ayuda. Sin esto, seguirás dependiendo de ellos para operaciones cotidianas.

6. Qué ocurre si decides marcharte

No es una pregunta hostil, es una pregunta de gestión. Cómo se finaliza la colaboración, con qué plazo de preaviso, qué recibes al salir, cuánto tiempo mantienes el acceso al sistema después.

Un proveedor que ha construido la relación de forma correcta no tiene nada que ocultar aquí. Uno que se apoya en que no te puedes marchar evitará el tema.

7. Quién es la persona con la que hablaré dentro de seis meses

A menudo hablas con alguien con buenas dotes comerciales y luego trabajas con otra persona. Pregunta quién será la persona de contacto tras el lanzamiento, cómo se reporta una incidencia y en qué plazo se suele responder. No necesitas promesas espectaculares: necesitas una respuesta concreta y coherente.

8. Cómo trabajáis si el alcance cambia durante el proyecto

Es muy probable que los requisitos del proyecto cambien durante la marcha. La pregunta útil no es «¿se puede cambiar?», sino «cómo decidimos juntos qué entra y qué queda fuera».

Un proveedor que dice «sí» a todo, sin debatir jamás qué sale del alcance a cambio, entregará más tarde o menos de lo que esperabas. Un proveedor que rechaza cualquier cambio en el alcance entregará exactamente lo que pediste al principio, aunque con el tiempo se haya demostrado erróneo.

9. ¿Puedo ver cómo funciona en mi caso concreto antes de firmar?

La comprobación más simple. No una demostración genérica, sino algo construido sobre tus datos, aunque sea un ejemplo parcial, con un solo producto.

Si el proveedor puede preparar un ejemplo relevante para tu caso, es señal de que ha empezado a entender el proceso y no solo el requerimiento técnico. Si no puede mostrar nada hasta que firmes, estás comprando una descripción.

10. Qué no debería hacer con vosotros

Un buen proveedor sabe dónde no encaja. Quizá necesitas un software estándar y no uno hecho a medida. Quizá tu problema radica en el proceso y no en el software, y cualquier sistema solo aceleraría el colapso del mismo caos.

Quien te dice esto desde el inicio te ahorra dinero. Quien acepta cualquier proyecto te vende lo que has pedido, no lo que necesitas.

---

Si estás en el punto de comparar varias ofertas, resulta útil partir del mapa de tu proceso y no de una lista de funcionalidades. En una conversación inicial desglosamos el flujo actual de presupuestación y te quedas con él, trabajes con quien trabajes más adelante. Y nuestra forma de trabajar está descrita paso a paso para que sepas en qué fijarte a la hora de comparar.