«Necesito una app para mi empresa» puede ser el inicio de una conversación, pero todavía no es un requerimiento. No explica qué está fallando, quién necesita resolverlo ni cómo sabremos que la inversión valió la pena. Si tres proveedores interpretan esa frase de manera distinta, recibirás tres cotizaciones difíciles de comparar.
Antes de evaluar un desarrollo de software a medida, conviene ordenar el negocio que ese software deberá acompañar. No necesitas escribir un documento técnico ni elegir tecnologías. Necesitas describir el trabajo real, sus límites y el cambio que esperas conseguir.
Estas diez preguntas te ayudarán a preparar una primera reunión. Usaremos ejemplos hipotéticos de una distribuidora que recibe pedidos por WhatsApp, controla existencias en Excel y factura en otro sistema. Puedes adaptar el ejercicio a una clínica, una empresa de servicios o una operación logística.
1. ¿Qué problema queremos resolver?
Empieza por una dificultad observable, no por una funcionalidad. «Queremos un panel» describe una posible solución. «No sabemos qué pedidos llevan más de un día pendientes» describe un problema que merece investigarse. Identifica a quién afecta, con qué frecuencia ocurre y qué consecuencias tiene.
Busca evidencia sencilla: horas de trabajo repetido, reclamos, entregas retrasadas o ventas que no se pudieron atender. Si aún no tienes cifras, revisa una muestra de operaciones y registra lo que encuentres; distingue lo medido de lo estimado.
Ejemplo: la distribuidora descubre que sus vendedores prometen productos sin confirmar disponibilidad. El objetivo inicial no es «tener una app», sino reducir pedidos confirmados que después deben corregirse por falta de stock.
Deja por escrito: una frase con el problema, el equipo afectado y su impacto.
2. ¿Cómo funciona hoy el proceso?
Dibuja el recorrido desde el hecho que inicia el trabajo hasta el resultado final. Incluye correos, hojas de cálculo, llamadas y aprobaciones informales. Describe lo que ocurre un martes cualquiera, incluso cuando difiere del procedimiento oficial.
Pregunta dónde espera cada operación, dónde se copia información y qué pasos dependen de que una persona recuerde hacer algo. Antes de pensar en automatización de procesos, revisa si hay actividades que podrían eliminarse o simplificarse.
Ejemplo: el vendedor recibe el pedido, consulta stock por chat, lo transcribe a Excel y avisa a administración. Almacén vuelve a copiar los productos para preparar el despacho. Ese mapa revela duplicación y puntos de espera que una lista de pantallas no mostraría.
Deja por escrito: un flujo sencillo con entradas, pasos, responsables y resultado.
3. ¿Quiénes intervienen y qué decisiones toman?
No basta con contar usuarios. Identifica roles, responsabilidades y decisiones: quién registra, quién aprueba, quién corrige y quién solo consulta. Incluye a clientes o proveedores si participarán en el sistema, y nombra a una persona del negocio que pueda resolver dudas durante el proyecto.
La gerencia conoce las prioridades, pero el equipo operativo conoce los atajos y problemas cotidianos. Ambos deben participar en la definición y validación de los requisitos de software.
Ejemplo: ventas puede crear pedidos, almacén confirmar disponibilidad y finanzas autorizar crédito. El supervisor aprueba descuentos excepcionales. Si todos reciben el mismo permiso para editar todo, el sistema pierde controles que el negocio sí necesita.
Deja por escrito: una lista de roles con sus acciones permitidas y decisiones reservadas.
4. ¿Qué reglas y excepciones existen?
Las reglas convierten un flujo en una operación confiable. Describe condiciones, límites, plazos y autorizaciones. Después pregunta qué ocurre cuando un caso se sale del camino habitual: cancelaciones, devoluciones, información incompleta o aprobadores ausentes.
No necesitas anticipar todas las situaciones posibles. Sí conviene revisar casos recientes y separar las excepciones frecuentes de las raras, para acordar cuáles resolverá el sistema y cuáles requerirán intervención humana.
Ejemplo: los pedidos que superan el crédito disponible necesitan aprobación de finanzas. Pero un cliente puede adelantar una parte del pago. ¿Se libera todo el pedido o solo algunos productos? ¿Quién confirma ese adelanto? Esa respuesta cambia el alcance.
Deja por escrito: las reglas principales y al menos tres casos excepcionales con su resolución actual.
5. ¿Qué datos entran, cambian y salen?
Enumera la información necesaria para operar: clientes, productos, precios, documentos, estados y fechas. Indica de dónde proviene, quién la mantiene y cuál es la fuente válida cuando dos archivos muestran valores distintos.
Revisa también los resultados: reportes, alertas, comprobantes o archivos para otras áreas. Si necesitas migrar información histórica, define qué período importa y quién revisará duplicados, campos incompletos y registros desactualizados.
Ejemplo: ventas identifica un producto por nombre y almacén por código. Antes de conectar ambos procesos, la distribuidora necesita un catálogo común. De lo contrario, la integración podría multiplicar errores en lugar de eliminarlos.
Deja por escrito: un inventario de datos y muestras sin información sensible de los archivos o reportes que utilizan.
6. ¿Con qué sistemas debe integrarse?
Lista las herramientas que seguirán funcionando: ERP, CRM, facturación, pagos, correo o sistemas internos. Para cada conexión, especifica qué información debe viajar, en qué dirección y con qué frecuencia. «Integrarse con el ERP» es demasiado amplio para estimar esfuerzo.
Confirma con el responsable del sistema si existen interfaces disponibles, documentación, acceso de prueba y costos adicionales. Considera qué hará el equipo si la conexión falla: esperar, reintentar o continuar con un procedimiento alternativo.
Ejemplo: el nuevo sistema enviará pedidos aprobados al facturador y recibirá el número del comprobante. Consultar existencias es otra integración, con reglas distintas. Si se reenvía un pedido por un error de conexión, no debería producir dos comprobantes.
Deja por escrito: sistemas, datos intercambiados, frecuencia y contacto responsable de cada conexión.
7. ¿Qué volumen y concurrencia esperamos?
Una operación pequeña y una campaña intensa pueden exigir comportamientos diferentes. Estima usuarios totales, personas conectadas al mismo tiempo, operaciones diarias y tamaño de archivos. Anota los picos conocidos y el crecimiento esperado, indicando qué cifras son aproximaciones.
También describe cuánto puede esperar el usuario y qué pasa si el servicio deja de estar disponible. Estas respuestas ayudan a definir infraestructura y pruebas proporcionales a la operación, sin sobredimensionar desde el inicio.
Ejemplo: la distribuidora tiene cuarenta vendedores, pero treinta registran pedidos antes del cierre de ruta. El pico simultáneo importa más que el total de cuentas. Además, varios trabajan con señal irregular y necesitan conservar un pedido si se interrumpe la conexión.
Deja por escrito: volumen habitual, pico, crecimiento previsto y condiciones reales de uso.
8. ¿Qué restricciones de seguridad y cumplimiento existen?
Identifica qué información es sensible para tu empresa y quién debería acceder a ella. Reúne políticas internas, compromisos contractuales y requisitos que tu área legal o responsable de cumplimiento deba confirmar. No dejes estas decisiones para la semana del lanzamiento.
Plantea necesidades concretas: permisos por rol, registro de cambios, respaldo, recuperación y baja de accesos cuando alguien deja la empresa. Aclara también quién administrará el servicio y qué información podrá consultar el proveedor durante el soporte.
Ejemplo: un vendedor necesita consultar sus clientes, pero no descargar toda la cartera ni revisar márgenes de otros equipos. Finanzas requiere conocer quién cambió una condición de crédito y cuándo. Esas restricciones deben entrar en el alcance inicial.
Deja por escrito: información restringida, responsables de validación y controles indispensables.
9. ¿Qué resultado permitiría decir que el proyecto funcionó?
«Que el sistema esté listo» confirma una entrega, pero no necesariamente una mejora. Define una línea base, una meta y un período de observación. Elige indicadores cercanos al problema: tiempo de atención, errores, trabajo manual o cumplimiento de plazos.
Separa el resultado del negocio de los criterios de aceptación del software. El primero requiere adopción y cambios operativos; los segundos permiten comprobar que cada función hace lo acordado. Asigna responsables a ambos.
Ejemplo: como meta hipotética, la distribuidora busca reducir el registro de un pedido de quince a cinco minutos durante el primer mes de uso. Como aceptación, exige poder registrar, aprobar y enviar un pedido válido sin volver a digitar sus productos.
Deja por escrito: indicador, situación actual, meta, plazo y persona que medirá.
10. ¿Qué parte es imprescindible y qué puede esperar?
Prioriza un recorrido completo que entregue valor. Distingue lo indispensable para operar de lo conveniente y lo que puede evaluarse después. Explicita presupuesto disponible, fechas relevantes y dependencias, aunque todavía sean rangos.
Una primera versión útil necesita validación, capacitación y soporte. Reservar todo el presupuesto para funcionalidades puede dejar al equipo sin recursos para adoptar el cambio. Si necesitas comparar alternativas, revisa nuestra guía de software a medida frente a software estándar.
Ejemplo: registrar pedidos, validar crédito y confirmar disponibilidad son imprescindibles. Un panel predictivo puede esperar. El acceso por roles y la prevención de pedidos duplicados pertenecen a la operación básica y no deberían tratarse como adornos opcionales.
Deja por escrito: alcance inicial, funcionalidades posteriores y exclusiones explícitas.
Cómo usar estas respuestas en una primera reunión con un proveedor
Reúne las respuestas en un documento breve y adjunta el flujo actual, ejemplos de operaciones y reportes sin datos sensibles. Marca las dudas pendientes: son temas para investigar, no espacios que debas llenar con suposiciones. Invita a una persona que ejecute el proceso y a quien pueda tomar decisiones.
Comparte el mismo material con cada proveedor. Pide que su propuesta detalle alcance, supuestos, integraciones, criterios de aceptación y costos de operación. Así podrás comparar qué problema resolverá cada alternativa y qué quedará fuera, además del precio.
Si estás buscando una empresa de desarrollo de software en Perú, en CodiLabs podemos ayudarte a ordenar esa necesidad y evaluar el siguiente paso. Conoce nuestra consultoría tecnológica o agenda una conversación sobre tu proceso. Trae estas diez respuestas, incluso incompletas: serán una mejor base para decidir qué construir y por dónde empezar.
