Cómo preparar los requisitos antes de pedir presupuesto de un software a medida

Para pedir presupuesto de un software a medida no hace falta llevar un documento técnico de ochenta páginas, ni diagramas, ni una lista de tecnologías. Lo que necesita un proveedor serio para darte una propuesta con sentido es entender tu negocio: qué problema existe hoy, cómo se resuelve ahora, quién lo sufre y qué tendría que cambiar.

Esta guía es para el momento en que ya has decidido hablar con alguien. Explica qué conviene tener ordenado antes de la primera reunión, cómo separar lo necesario de lo que puede esperar y, también, qué no hace falta preparar porque es trabajo del proveedor. Al final hay una lista para comprobar que lo tienes.

Por qué preparar esto cambia el presupuesto que recibes

Un presupuesto es una estimación sobre lo que el proveedor ha entendido. Si le das poco, rellenará los huecos con suposiciones, y dos proveedores supondrán cosas distintas: uno imaginará un sistema sencillo y dará una cifra baja que luego crecerá con cada cambio; otro se cubrirá con un margen amplio. Ninguno de los dos te está engañando: están presupuestando proyectos diferentes. Qué rangos maneja el mercado y qué hace subir la cifra lo contamos en cuánto cuesta desarrollar software a medida.

Con la información de esta guía no se eliminan todas las dudas, pero las que quedan son preguntas concretas y no suposiciones. Y te permite algo que vale mucho: dar exactamente la misma información a cada proveedor y comparar sus respuestas. Qué mirar en esa comparación lo contamos en cómo elegir una empresa de desarrollo de software a medida.

1. Qué problema existe hoy

Empieza por lo que pasa, no por lo que quieres construir. Una frase o dos, en el idioma de la empresa:

• «Los partes de trabajo llegan por WhatsApp y alguien los pasa a mano al Excel de facturación; cada mes se escapan algunos.»
• «Para saber el margen de un proyecto hay que cruzar tres archivos y nadie lo hace hasta que el proyecto ha terminado.»
• «Los clientes llaman para preguntar en qué estado está su pedido porque no tienen dónde verlo.»

Si te cuesta formularlo, piensa en qué tarea preferiría no hacer nadie, qué error se repite o qué pregunta no se puede contestar sin buscar en varios sitios.

2. Cómo se resuelve actualmente

Describe el proceso tal y como ocurre hoy, con sus atajos. No el procedimiento oficial, sino lo que hace de verdad la gente. Basta con una lista de pasos: qué inicia el proceso, qué se hace después, dónde se apunta cada cosa y cómo termina.

Ese recorrido es lo más valioso que puedes llevar. Es donde un proveedor ve qué se puede automatizar, qué datos se repiten y dónde está el punto que falla.

3. Quién participa en el proceso

Enumera los perfiles, no las personas: administración, jefe de obra, comercial, almacén, dirección, el propio cliente. Para cada uno, una línea sobre qué hace en el proceso y con qué frecuencia. Un sistema que usan dos personas en la oficina no se plantea igual que uno que usan treinta en la calle desde el móvil.

4. Qué herramientas intervienen

Haz inventario de todo lo que se toca durante el proceso, aunque parezca menor:

• hojas de cálculo (Excel, Google Sheets);
• ERP o programa de facturación y contabilidad;
• CRM;
• correo electrónico;
• WhatsApp u otras aplicaciones de mensajería;
• software del sector;
• la web o la tienda online;
• carpetas compartidas, documentos, papel.

Para cada una, apunta si se quiere mantener, sustituir o simplemente dejar de usar para este proceso. No todo tiene que cambiar: la contabilidad o las nóminas suelen estar bien resueltas y lo razonable es conectarse a ellas, no rehacerlas.

5. Qué información entra

¿Qué datos llegan al proceso y de dónde? Un pedido por correo, un formulario de la web, una llamada, una hoja que manda un proveedor, una foto desde la obra. Si puedes, guarda dos o tres ejemplos reales —con los datos personales tapados—: un proveedor aprende más de un pedido real que de una descripción.

6. Qué información sale

¿Qué tiene que producir el proceso? Una factura, un albarán, un aviso al cliente, un informe para dirección, un pedido a un proveedor, un dato que va a otro sistema. Igual que antes, los ejemplos reales ayudan: el informe que hoy se hace a mano es la mejor especificación de lo que tiene que salir.

7. Qué tareas son manuales

Señala los pasos en los que alguien copia, comprueba, busca, recuerda o avisa. Copiar un dato de un sitio a otro, revisar si algo se ha hecho, perseguir a alguien para que responda, preparar un resumen cada lunes. No hace falta medir cuánto tiempo lleva cada una; basta con saber cuáles existen y cuáles generan errores.

8. Qué excepciones existen

Es la parte que más se olvida y la que más cambia un presupuesto. El proceso normal suele ser sencillo; lo que complica un sistema son los casos que no siguen la norma:

• el cliente que paga en tres plazos;
• el pedido que se sirve en dos entregas;
• el trabajo que se cancela a medias;
• el descuento que solo aprueba dirección;
• la devolución parcial.

Pregunta a quien trabaja en el proceso a diario: «¿Qué casos te obligan a hacer algo distinto?». Cada respuesta es una regla que el sistema tendrá que conocer.

9. Qué perfiles necesitan acceso y a qué

No todos tienen que ver lo mismo. Piensa en quién debe poder consultar, crear, modificar, aprobar o borrar cada cosa. Los márgenes, por ejemplo, rara vez debería verlos todo el mundo; un cliente con acceso solo debería ver lo suyo. Con una tabla sencilla de perfiles y permisos es suficiente.

10. Con qué sistemas hay que integrarse

De las herramientas del punto 4, ¿cuáles tienen que intercambiar datos con el sistema nuevo? Para cada una, apunta qué dato viaja y en qué sentido, y si sabes que el programa tiene una forma de conectarse (una API) o solo permite exportar archivos. Si no lo sabes, no pasa nada: anota el nombre y la versión, y el proveedor lo comprobará.

11. Qué datos hay que migrar

¿Hay información actual que debe estar en el sistema desde el primer día? Clientes, productos, histórico de trabajos, tarifas. Indica dónde está, aproximadamente cuánto volumen hay y en qué estado: no es lo mismo una base de datos ordenada que diez hojas de cálculo con formatos distintos. Limpiar datos es trabajo, y conviene que aparezca en el presupuesto y no a mitad de proyecto.

12. Qué tiene que resolver la primera versión

Aquí está la decisión que más ordena el proyecto. Separa lo que pides en tres columnas:

Necesario	Deseable	Futuro
Sin esto, la primera versión no resuelve el problema	Mejora mucho el uso, pero se puede vivir sin ello unas semanas	Tiene sentido cuando lo anterior funcione
Ej.: registrar el parte desde el móvil y que llegue a facturación	Ej.: adjuntar fotos al parte	Ej.: portal para que el cliente vea el estado

Sé exigente con la primera columna. Una primera versión pequeña que se usa de verdad enseña más que una grande que tarda meses en llegar, y lo que se aprende en las primeras semanas suele cambiar el orden de lo deseable y lo futuro.

13. Cómo sabrás que ha funcionado

Define el éxito con frases que se puedan comprobar, sin inventar cifras que todavía no conoces:

• que el mismo dato no se teclee dos veces;
• que haya una sola fuente de información para clientes y pedidos;
• que desaparezca una tarea manual concreta;
• que se pueda conocer el margen de cada trabajo sin cruzar archivos;
• que los avisos al cliente salgan solos cuando cambia un estado;
• que no haya que copiar datos de un sistema a otro.

Si hoy tienes alguna medida real —cuántos pedidos se gestionan al mes, cuántas personas tocan el proceso—, inclúyela. Si no la tienes, no hace falta inventarla: lo importante es que el resultado esperado sea concreto.

Lo que no hace falta preparar

Igual de útil que saber qué llevar es saber qué no te corresponde. No hace falta que prepares:

• Diseños de pantallas perfectos. Un boceto en papel puede ayudar a explicar una idea, pero las pantallas son la última decisión, no la primera.
• La arquitectura técnica. Cómo se organiza el sistema por dentro lo decide el proveedor a partir de tu proceso.
• La elección de tecnologías. Salvo que tengas un motivo concreto, como un equipo interno que ya trabaja con una.
• El diseño de la base de datos.
• Documentación técnica avanzada.

Todo eso es trabajo del proveedor. Si lo traes hecho, como mucho servirá de referencia; si te lo exigen antes de hablar, te están pidiendo que hagas tú una parte del análisis que deberían hacer ellos.

Lista para la primera conversación

Antes de la reunión, comprueba que puedes responder a estos trece puntos. No hace falta que sea un documento formal: unas notas ordenadas valen.

1. El problema, en una o dos frases.
2. El proceso actual, paso a paso, con sus atajos.
3. Los perfiles que participan y qué hace cada uno.
4. Las herramientas que intervienen y cuáles se mantienen.
5. Ejemplos reales de lo que entra (con datos personales tapados).
6. Ejemplos reales de lo que sale.
7. Las tareas manuales que se quieren eliminar.
8. Las excepciones que conoce quien trabaja en el proceso.
9. Quién debe ver y hacer qué.
10. Los sistemas con los que hay que conectarse.
11. Los datos que hay que migrar, dónde están y en qué estado.
12. La primera versión: necesario, deseable y futuro.
13. Cómo sabrás que ha funcionado.

Si al rellenarla descubres que el problema es pequeño, que lo usan dos personas o que el proceso todavía cambia cada semana, quizá todavía no necesites un desarrollo propio. Las señales que lo indican las explicamos en cuándo dejar Excel y cuándo no.

Si tienes esto, ya podemos hablar

Con esta información, la primera conversación deja de ser una presentación y pasa a ser un análisis. En Bolmia empezamos así los proyectos de software a medida para empresas: por el proceso, sus excepciones y los sistemas que ya funcionan, antes de hablar de pantallas.

No hace falta que la lista esté completa. Si tienes claro el problema y el proceso, cuéntanoslo y lo terminamos de ordenar juntos, incluida la parte en la que quizá la respuesta sea no construir nada.