Vas a pedir cotizaciones para un sistema. Mandas un correo que dice “necesitamos un software para gestionar nuestra operación, por favor cotizar”. Y recibes propuestas que no se parecen entre sí, con precios que varían cinco veces, imposibles de comparar.
No es culpa de los proveedores. Es que cada uno imaginó un sistema distinto. Esta guía te da el documento que necesitas escribir antes de pedir el primer número.
Por qué importa tanto
Un pedido vago produce tres efectos, todos malos:
- Propuestas incomparables. Uno cotiza tres módulos, otro siete. El precio no significa nada.
- Los serios cotizan alto. Ante la incertidumbre, un proveedor responsable se cubre.
- Los que cotizan bajo lo hacen porque entendieron menos. Y lo van a compensar después con adicionales.
Un documento de dos o tres páginas bien escrito puede cambiar por completo la calidad de lo que recibes. No necesitas conocimiento técnico: necesitas claridad sobre tu propio negocio.
Lo que debe contener
1. El problema, no la solución
Empieza por lo que duele, no por lo que crees que lo resuelve. En vez de “necesitamos un ERP”, escribe: “hoy llevamos el inventario en tres hojas de cálculo que no se hablan entre sí, y cada cierre de mes nos toma cuatro días de conciliación manual”.
Esa descripción permite que un buen proveedor te proponga algo mejor de lo que pediste. La primera formulación cierra la puerta.
2. Cómo trabajan hoy
Describe el proceso actual, incluidos los pasos informales. Especialmente esos: los grupos de WhatsApp, el archivo que alguien mantiene a mano, la llamada al proveedor para confirmar. Ahí es donde suele estar el requerimiento real.
3. Quiénes lo van a usar
| Dato | Ejemplo |
|---|---|
| Rol | Bodeguero |
| Cuántos | 4 personas |
| Desde dónde | Tablet en bodega, a veces sin señal |
| Qué necesita hacer | Registrar entradas y salidas, imprimir guías |
| Qué NO debe poder hacer | Ver costos ni modificar precios |
La última columna es la que casi nadie escribe y la que más define el diseño de permisos.
4. Qué debe hacer, priorizado
Lista las funciones y clasifícalas en tres grupos, sin trampa:
- Indispensable: sin esto no podemos operar y no lanzamos.
- Importante: lo necesitamos, pero puede venir en una segunda fase.
- Deseable: si el presupuesto alcanza.
La tentación es marcar todo como indispensable. Resistirla es lo que permite tener una primera versión en cuatro meses en vez de en doce.
5. Con qué debe integrarse
Por cada sistema externo, indica: cuál es, qué información debe intercambiar, en qué dirección y con qué frecuencia. Si sabes si tiene API, mejor; si no, dilo y que el proveedor lo investigue.
Las integraciones son donde más se subestima el esfuerzo. Mencionarlas desde el inicio evita la sorpresa a mitad de proyecto.
6. Volúmenes
Números aproximados bastan, pero tienen que estar:
- Cuántos registros manejas hoy (productos, clientes, transacciones al mes).
- Cuánto esperas crecer en dos o tres años.
- Cuántos usuarios simultáneos en el momento pico.
- Si hay estacionalidad marcada.
Un sistema para 500 transacciones mensuales y uno para 50.000 no se diseñan igual, aunque hagan lo mismo.
7. Restricciones
Todo lo que acota la solución: normativa que debes cumplir, sistemas que no se pueden reemplazar, políticas de dónde pueden estar alojados los datos, fechas límite de negocio, presupuesto disponible.
8. Cómo sabrás que funcionó
Define el criterio de éxito en términos medibles: “el cierre de mes pasa de cuatro días a uno”, “eliminamos la doble digitación entre ventas y bodega”. Sin esto, “el sistema funciona” es una opinión.
Lo que NO debes escribir
| Evita | Por qué |
|---|---|
| Especificar la tecnología | Salvo que tengas una restricción real, limita sin necesidad |
| Diseñar las pantallas | Describe qué necesitas lograr, no cómo se ve |
| Copiar requerimientos de otra empresa | Terminas pagando por lo que otro necesitaba |
| Ocultar el presupuesto | Impide que te propongan un alcance viable |
| Pedir “todo lo que se pueda” | Garantiza un proyecto que no termina |
Lo del presupuesto genera resistencia porque parece perder poder de negociación. En software funciona al revés: un rango permite diseñar la mejor solución posible dentro de lo que tienes. Sin él, recibes propuestas que no puedes pagar o alcances recortados sin criterio.
Un formato que funciona
No necesitas un documento formal de veinte páginas. Esta estructura basta:
- Contexto: a qué se dedica tu empresa, tamaño, sector. Media página.
- Problema: qué duele hoy y cuánto cuesta. Media página.
- Situación actual: cómo se hace hoy, qué sistemas usan. Una página.
- Usuarios y roles: tabla. Media página.
- Funcionalidades priorizadas: lista en tres niveles. Una página.
- Integraciones: tabla. Media página.
- Volúmenes y restricciones: media página.
- Criterio de éxito y rango de inversión: media página.
Cuatro o cinco páginas. Con eso, las propuestas que recibas van a ser comparables y realistas.
Qué esperar de un buen proveedor
Aun con el mejor documento, un proveedor serio va a hacerte preguntas y a cuestionar cosas. Eso es buena señal, no falta de comprensión: significa que está pensando en tu problema en vez de cotizar lo que leyó.
Desconfía del que cotiza sin preguntar nada. O entendió todo perfectamente —poco probable— o no está entendiendo nada.
Preguntas frecuentes
¿Necesito conocimiento técnico para escribir esto?
No. Todo lo que pide el documento es conocimiento de tu negocio: qué hacen, cómo, con qué volúmenes y qué duele. La parte técnica —arquitectura, tecnología, diseño— es responsabilidad del proveedor, y de hecho no conviene que la definas tú.
¿Puedo pedir ayuda para escribirlo?
Sí, y muchos proveedores ofrecen esa fase como un servicio de discovery pagado y acotado, cuyos entregables quedan a tu nombre. La ventaja adicional es que con ese documento puedes pedir cotizaciones comparables a varios, todos sobre la misma base.
¿A cuántos proveedores debo pedir cotización?
Tres suele ser un buen número: suficiente para comparar sin volver interminable la evaluación. Lo importante es que todos reciban exactamente el mismo documento; si a uno le explicas más por teléfono, ya no son comparables.
¿Y si mis requerimientos cambian después?
Van a cambiar, es normal y no invalida el ejercicio. El documento sirve como línea base: cuando algo cambie, se ve claramente qué cambió respecto de lo cotizado y se puede evaluar su impacto de forma ordenada. Sin línea base, cualquier discusión sobre alcance es palabra contra palabra.
Artículos relacionados
- Cómo se cotiza un proyecto de software: qué es el discovery
- Propiedad del código fuente: qué exigir en el contrato de desarrollo
- Ágil o cascada: qué metodología conviene a tu proyecto de software
Desarrollo de software a medida
¿Tienes un proyecto de sistema en mente?
Hacemos el diagnóstico sin costo: levantamos el problema, te decimos qué se necesita de verdad y entregamos una propuesta escrita con alcance y precio cerrados en 3 a 5 días hábiles.
Conversemos tu proyecto
Ver portafolio
64 clientes en 14 verticales · proyectos@bluenova.com.ec · +593 96 949 8704
Sigue leyendo
Comentarios y opiniones
0 comentarios · Moderación previa
Cuéntanos tu experiencia, dudas o casos similares. Revisamos cada comentario antes de publicarlo para mantener conversaciones de calidad. También puedes suscribirte para recibir nuevos artículos.