La mayoría de las cotizaciones que no se pueden comparar nacen de una solicitud vaga, como "necesito un sistema de inventarios". Cada proveedor imagina algo distinto y cotiza en consecuencia. Describir tus requerimientos antes de pedir precios no requiere conocimientos técnicos y te ahorra semanas de ida y vuelta. Aquí tienes el método y una plantilla para llenar.
¿Qué es un documento de requerimientos y para qué sirve?
Es una descripción, en tus propias palabras, de lo que el sistema debe resolver y cómo se trabaja hoy. No es una especificación técnica: de la tecnología se encarga el proveedor. Su objetivo es que cualquier empresa que lo lea entienda lo mismo.
Un buen documento sirve para tres cosas: recibir propuestas comparables, reducir sorpresas en el costo y tener una referencia clara para revisar si lo entregado corresponde a lo pedido. Para la mayoría de los procesos, de dos a cinco páginas son suficientes.
¿Qué debe incluir?
- Objetivo: qué problema resuelve el sistema y cómo sabrás que funcionó.
- Proceso actual: los pasos que se siguen hoy y las herramientas que se usan.
- Usuarios y permisos: quién participa y qué puede ver o hacer cada uno.
- Información: los datos que se capturan, los documentos que se adjuntan y los estatus por los que pasa cada registro.
- Reglas de negocio: condiciones, cálculos, validaciones y aprobaciones.
- Reportes y notificaciones: qué necesitas consultar y quién debe enterarse de qué.
- Integraciones: con qué sistemas debe intercambiar información.
- Restricciones: fecha límite, presupuesto de referencia, dispositivos y condiciones de uso.
Cómo definir los requerimientos paso a paso
- Elige un solo proceso para empezar. Es más fácil describir bien un proceso que todo el negocio a la vez. Si no sabes cuál, este método te ayuda a decidir qué procesos automatizar primero.
- Recorre el proceso con quien lo hace. Siéntate con las personas que lo operan y pídeles que te muestren cada paso, incluidos los atajos y excepciones.
- Reúne ejemplos reales: formatos, hojas de cálculo, reportes, mensajes de WhatsApp o correos que forman parte del proceso.
- Escribe el flujo en orden, de principio a fin, con frases cortas: quién hace qué y qué pasa después.
- Lista los usuarios y sus permisos. Piensa también en quién no debe ver cierta información.
- Anota las reglas y excepciones, sobre todo las que hoy dependen de la memoria de una persona.
- Define los reportes que necesitas y cada cuánto los consultas.
- Identifica las integraciones: ERP, facturación, tienda en línea, CRM o bancos.
- Prioriza cada requerimiento como indispensable, deseable o para después.
- Valida el documento con los usuarios y con quien aprobará el presupuesto.
Cómo describir reglas de negocio sin lenguaje técnico
Las reglas son lo que hace único a tu proceso y lo que más influye en el costo. La forma más clara de escribirlas es con la estructura "si pasa esto, entonces el sistema debe hacer aquello". Por ejemplo:
- Si una compra supera el monto que defina la dirección, entonces debe aprobarla el gerente de área.
- Si un producto llega a su existencia mínima, entonces se avisa al responsable de compras.
- Si una orden de servicio no tiene fotos y firma del cliente, entonces no se puede cerrar.
Incluye también las excepciones: quién puede saltarse una regla y qué queda registrado cuando lo hace.
Plantilla para llenar
Copia esta tabla, sustituye el ejemplo por tu caso y responde cada pregunta con frases sencillas. El ejemplo es ilustrativo y corresponde a una empresa de mantenimiento que controla sus órdenes de servicio en Excel.
| Sección | Qué debes responder | Ejemplo (órdenes de servicio) |
|---|---|---|
| 1. Objetivo | ¿Qué problema quieres resolver y cómo sabrás que se resolvió? | Dejar de controlar las órdenes en Excel y saber en todo momento en qué estatus está cada una |
| 2. Proceso actual | ¿Cómo se hace hoy, paso a paso, y con qué herramientas? | El cliente llama o escribe por WhatsApp, recepción lo anota en Excel y avisa al técnico por mensaje |
| 3. Usuarios y permisos | ¿Quiénes lo usan y qué puede hacer cada uno? | Recepción registra; el supervisor asigna; el técnico actualiza y sube fotos; la dirección consulta reportes |
| 4. Información | ¿Qué datos se capturan y qué documentos se adjuntan? | Cliente, dirección, equipo, falla reportada, fotos y firma de conformidad |
| 5. Estatus | ¿Por qué etapas pasa cada registro? | Recibida, asignada, en proceso, terminada y facturada |
| 6. Reglas de negocio | ¿Qué condiciones, cálculos o aprobaciones existen? | Una orden no se cierra sin fotos y firma; solo el supervisor puede reasignarla |
| 7. Notificaciones | ¿Quién debe enterarse de qué y por qué medio? | Avisar al técnico cuando se le asigna una orden y al cliente cuando se termina |
| 8. Reportes | ¿Qué necesitas consultar y cada cuánto? | Órdenes por técnico y por estatus cada semana, y tiempo de atención por cliente |
| 9. Integraciones | ¿Con qué sistemas debe intercambiar información? | Enviar las órdenes terminadas al sistema de facturación para emitir el CFDI |
| 10. Información existente | ¿Qué datos hay que migrar y dónde están hoy? | Catálogo de clientes y equipos en varias hojas de Excel |
| 11. Volumen y lugares | ¿Cuántos usuarios, sucursales y registros aproximados? | Dos sucursales y un equipo de técnicos que trabaja desde el celular |
| 12. Restricciones | ¿Fecha límite, presupuesto de referencia, dispositivos, conexión? | Debe funcionar en celular, incluso con señal intermitente en campo |
| 13. Fuera de alcance | ¿Qué no entra en la primera versión? | Inventario de refacciones y portal para clientes |
Si tu caso se parece al del ejemplo, revisa qué funciones debe tener un sistema de órdenes de trabajo para completar tu lista.
Cómo priorizar lo que entra en la primera versión
Marca cada requerimiento con una de tres etiquetas:
- Indispensable: sin esto, el sistema no resuelve el problema.
- Deseable: aporta valor, pero puedes operar sin ello las primeras semanas.
- Para después: ideas para una segunda etapa.
Una primera versión con solo lo indispensable sale antes, cuesta menos y te permite decidir las siguientes etapas con información de uso real.
Errores comunes al definir requerimientos
- Describir la solución en lugar del problema, por ejemplo "quiero un botón rojo" en vez de "necesito detectar las órdenes atrasadas".
- Copiar todas las funciones de otro sistema sin preguntarte si las necesitas.
- Omitir las excepciones, que suelen ser las que más trabajo dan.
- No incluir a quienes usan el proceso a diario.
- Pedir todo para la primera versión.
Qué hacer con el documento
Envía el mismo documento a todos los proveedores y pide que respondan con una propuesta escrita que indique alcance, exclusiones, calendario y presupuesto. Así podrás compararlas con las 12 preguntas para elegir una empresa de desarrollo de software y entender por qué varían los precios con la guía de cuánto cuesta el software a medida en México.
Si prefieres no hacerlo solo, en UniqueCore el diagnóstico incluye la definición de requerimientos: conversamos con tu equipo, ordenamos la información y te entregamos una propuesta por escrito. Puedes solicitar tu diagnóstico aquí.
