Cómo especificar un sistema a medida antes de cotizar

Para cotizar un sistema a medida no necesitas entregar un documento técnico perfecto; sí necesitas describir qué decisión, operación o riesgo debe resolver. Una especificación suficiente convierte conversaciones ambiguas en supuestos visibles, entregables verificables y una propuesta que se puede comparar.

La regla práctica es simple: documenta el problema y el resultado esperado antes de decidir pantallas o tecnología. Quien cotiza debe poder responder qué hace el sistema, para quién, con qué datos, dónde termina su responsabilidad y cómo sabrán ambas partes que una entrega funciona.

Empieza por el problema, no por la lista de pantallas

Una lista de pantallas puede ser útil, pero no explica la operación. En lugar de iniciar con necesito un dashboard, escribe una frase de negocio: el responsable de compras necesita ver solicitudes pendientes, validar presupuesto y dejar un historial de aprobación antes de liberar una orden. Esa frase contiene un actor, una decisión, reglas y un resultado.

Luego delimita el proceso. Anota qué lo inicia, qué lo termina, quién participa, qué información entra, qué salidas produce y qué pasa cuando algo falla. Si el proceso cruza ventas, almacén, contabilidad o proveedores, no lo partas por organigrama: sigue el dato y la responsabilidad de punta a punta.

No prometer precisión donde aún hay incertidumbre es una fortaleza. Marca las decisiones pendientes como hipótesis y asigna a un responsable que las resuelva. Es preferible cotizar una fase de descubrimiento para un proceso incierto que disfrazar una suposición como requerimiento cerrado.

El paquete mínimo para pedir cotizaciones comparables

Una buena solicitud no necesita ser extensa, pero debe incluir lo siguiente. Úsalo como checklist y adjunta muestras anonimizadas cuando ayuden a explicar el caso.

• Objetivo y prioridad. Qué problema se busca resolver, qué cambia para el usuario y por qué es prioritario ahora.
• Alcance inicial. Procesos incluidos, áreas incluidas, sedes si aplica y lo que explícitamente queda fuera.
• Usuarios y roles. Quién captura, aprueba, consulta, administra y audita; no basta con decir usuarios internos.
• Flujos principales. De tres a diez historias de uso escritas en lenguaje normal, con inicio, pasos, decisión y resultado.
• Reglas de negocio. Límites, autorizaciones, fórmulas, calendarios, estados y excepciones.
• Datos. Fuente de cada dato, campos mínimos, dueño, calidad actual, importación histórica y exportación requerida.
• Integraciones. Sistemas externos, propósito, dueño técnico, método disponible, frecuencia, volumen y qué ocurre si no responde.
• Requisitos no funcionales. Acceso, auditoría, rendimiento esperado, disponibilidad, respaldo, privacidad y soporte.
• Criterios de aceptación. Escenarios que deben pasar para recibir una entrega.
• Restricciones. Fecha que sí es inamovible, presupuesto orientativo si decides compartirlo, políticas internas y tecnología obligatoria.

Este paquete evita que dos proveedores coticen cosas distintas bajo el mismo nombre. También protege a tu equipo: una propuesta que no declara exclusiones, supuestos y aceptación será difícil de gobernar después.

Cómo escribir requerimientos que se puedan probar

Un requerimiento útil no dice el sistema debe ser intuitivo. Dice qué usuario realiza qué acción, con qué condición y qué evidencia queda. Por ejemplo: una persona con rol supervisor puede aprobar una solicitud de compra sólo si el monto está dentro de su límite; el sistema conserva fecha, usuario, monto previo y motivo de rechazo.

Usa esta plantilla: Como [rol], necesito [acción] para [resultado], bajo [regla o contexto]. Compleméntala con criterios de aceptación: dado un estado inicial, cuando ocurre una acción, entonces el sistema muestra o registra un resultado observable.

Ejemplo de criterio: dado que una solicitud supera el límite del coordinador, cuando éste intenta aprobarla, entonces el sistema la envía al siguiente nivel y registra que no tenía facultad para liberarla. Esto aclara reglas que una pantalla bonita no revela.

Documenta los flujos normales y los incómodos

Los proyectos se rompen más por excepciones que por el camino feliz. Para cada flujo, registra al menos estos casos: dato incompleto, duplicado, aprobación rechazada, usuario sin permiso, integración sin respuesta, corrección posterior y cancelación. No se trata de diseñar cada error al inicio; se trata de saber cuáles pueden afectar dinero, clientes, cumplimiento o continuidad.

Si interviene facturación, describe qué datos originan el comprobante, quién valida la información fiscal y quién resuelve rechazos. El SAT indica para CFDI 4.0 que el código postal, régimen fiscal y uso del comprobante del receptor deben corresponder a los catálogos aplicables; confirma requisitos vigentes directamente con tu asesor fiscal y la información oficial del SAT . No conviertas una interpretación fiscal en una regla de software sin responsable de negocio y revisión especializada.

Alcance: la frontera que evita retrabajo

El alcance no es una lista de deseos; es una frontera. Debe decir qué procesos, usuarios, integraciones y datos se entregan en la primera versión, y qué queda deliberadamente para después. Una primera versión útil suele enfocarse en un flujo completo y medible, no en muchas secciones incompletas.

Escribe fuera de alcance en forma positiva: la primera fase importa el catálogo existente; no incluye limpieza masiva de duplicados, o incluye consulta de estatus desde el ERP; no modifica inventario en el ERP. Así se vuelve visible la decisión necesaria, en vez de descubrirla al final.

Divide el trabajo en entregas demostrables: descubrimiento, diseño validado, construcción de un flujo, integración, migración controlada, capacitación y salida. Cada etapa necesita una entrada, una salida y una decisión de continuación. Una fecha única sin esas compuertas suele esconder riesgo.

Datos e integraciones: lo que más conviene aclarar temprano

Para cada fuente de datos, define cuál es el sistema maestro. Si el nombre del cliente vive en dos lugares, ¿cuál gana ante un conflicto? Si se cambia una orden en el origen, ¿la copia se actualiza, se bloquea o genera una tarea? Estas decisiones determinan más el éxito que el diseño visual.

No aceptes se integra con X como requisito completo. Pregunta: ¿qué evento dispara el intercambio?, ¿qué campos se mandan?, ¿cómo se identifican los registros?, ¿la comunicación es inmediata o por lote?, ¿hay API documentada?, ¿qué se hace con errores y quién los atiende? Cuando no existe API, quizá una importación controlada sea más segura que automatizar una interfaz frágil.

Las automatizaciones con n8n pueden coordinar tareas entre aplicaciones cuando hay interfaces adecuadas, pero también necesitan propiedad, registros, alertas y revisión de credenciales. Lee arquitectura de automatización e IA antes de definir una integración sólo como conectar herramientas.

Seguridad, operación y soporte también son requerimientos

La seguridad no es una fase al final. Define acceso por rol, acciones auditables, quién administra cuentas, cuánto tiempo se conservan datos, cómo se hacen respaldos y qué ocurre al salir una persona de la empresa. OWASP recomienda derivar requisitos de seguridad de la función de negocio y revisar controles de acceso como parte del proceso de requisitos; consulta OWASP SAMM como referencia de práctica, no como sustituto de un análisis de riesgo propio.

Asimismo, documenta el modelo operativo. ¿Quién recibirá incidencias?, ¿qué horario de soporte esperas?, ¿qué severidad requiere atención prioritaria?, ¿quién aprueba cambios?, ¿cómo se capacita a nuevas personas? Si el sistema no tiene dueño operativo, la entrega técnica no cerrará el problema.

Cuando NO conviene cotizar todavía

No conviene pedir un precio cerrado si el equipo no está de acuerdo sobre el problema, si los datos de origen son desconocidos o si nadie puede decidir reglas y prioridades. Tampoco si esperas que el proveedor obtenga permisos de terceros, limpie toda la información histórica o cambie procesos internos sin que esas tareas estén previstas.

En esos casos, pide primero un diagnóstico o taller acotado con entregables: mapa de proceso, inventario de datos, riesgos, alternativas y un backlog priorizado. No es un retraso; es la forma de reducir cambios caros durante la construcción.

Antes de aprobar una propuesta

Revisa que la propuesta responda exactamente a los flujos que documentaste y no a una descripción genérica. Debe separar descubrimiento, construcción, pruebas, migración, soporte y servicios de terceros. Pide ejemplos de evidencia de aceptación: una demostración con roles, registro de errores, exportación de datos y documentación entregable. Si dos propuestas usan palabras parecidas pero incluyen diferentes integraciones, datos históricos o niveles de soporte, no son comparables todavía. Ajusta el alcance antes de elegir.

Conserva decisiones y versiones

Asigna una versión y fecha al alcance aprobado. Cuando una regla cambie, conserva el motivo, la persona que decidió y el efecto esperado. Esa historia evita que una corrección posterior parezca un defecto del proveedor o una petición nueva sin contexto.

FAQ

¿Cuántos requerimientos necesito para cotizar?

Los suficientes para describir un flujo completo, sus roles, datos, excepciones y aceptación. Es mejor tener cinco casos prioritarios bien definidos que cincuenta frases ambiguas.

¿Debo diseñar las pantallas antes de contratar?

No necesariamente. Bocetos ayudan a conversar, pero las reglas, datos y criterios de aceptación deben guiar el diseño. El proveedor puede proponer interfaz una vez que entiende el flujo.

¿Qué es un criterio de aceptación?

Es una condición observable que demuestra que un requerimiento funciona. Debe poder revisarse con un escenario y una evidencia, no depender de una impresión general.

¿Qué hago si mi proceso cambia durante el proyecto?

Registra el cambio, su motivo, impacto en alcance, fecha y prioridad. Después decide si entra a la fase actual, sustituye otro requisito o pasa a una siguiente entrega.

¿Necesito un documento legal para especificar?

La especificación no sustituye contrato. Sirve como anexo técnico y base de aceptación; para obligaciones, propiedad intelectual y responsabilidades, pide revisión de un abogado.

Siguiente paso

Si quieres convertir una necesidad operativa en un alcance cotizable, agenda un diagnóstico sin costo de 30 minutos con SNAPGAD Technology por WhatsApp al 221 407 8660 o en solicitar cotización. Consulta también servicios de software, desarrollo web y portales B2B y glosario.