Cuatro cosas, y ninguna es técnica: el problema descrito en términos de negocio, acceso a quien hoy hace el trabajo, un inventario de los sistemas que ya usas y un responsable interno con tiempo. No necesitas requerimientos, diseños ni haber elegido tecnología. Eso lo produce la fase de estructuración, y es responsabilidad del proveedor.
Casi nadie contrata software por gusto. Se contrata cuando un proceso ya no aguanta: los pedidos se pierden entre WhatsApp y Excel, los informes toman más tiempo que el trabajo que describen, o tres sistemas guardan la misma información y ninguna coincide.
El error habitual es llegar al proveedor con la solución ya decidida ("necesito una app con estas doce pantallas") en lugar de con el problema. El proveedor cotiza lo que le pidieron, construye lo que cotizó, y seis meses después el sistema hace lo que decía el documento y no lo que necesitaba la operación. Esta página es para evitar ese camino.
Cuatro cosas que puedes reunir en una semana sin ayuda técnica.
No "necesito una app", sino "cada pedido pasa por tres personas y un Excel, y dos veces al mes se despacha algo que ya no había en inventario". Con la segunda frase un proveedor puede proponer; con la primera solo puede adivinar.
Ejemplo: "Los técnicos llenan actas de mantenimiento en papel; el cliente recibe el PDF una semana después y no hay forma de saber qué equipo se atendió." Ese fue el punto de partida del proyecto de Navas.
El proceso real vive en la cabeza de la persona que lo ejecuta todos los días, no en el organigrama. Si el proveedor solo habla con gerencia, construirá el proceso como debería ser en teoría y el equipo no lo usará.
Basta con que dos o tres personas puedan dedicar un par de horas a mostrar cómo trabajan hoy, con sus atajos y sus excepciones.
Facturación, CRM, nómina, WhatsApp Business, hojas de cálculo compartidas. Casi ningún sistema nuevo vive solo; saber con qué debe hablar cambia el alcance y el presupuesto más que cualquier funcionalidad.
No hace falta documentación técnica. Una lista de nombres de herramientas y quién las administra es suficiente para empezar.
Alguien de tu empresa que revise las entregas, responda dudas y tome decisiones pequeñas sin convocar una reunión. Los proyectos que se atrasan casi siempre se atrasan de este lado, no del lado del proveedor.
Suele ser quien más sufre el problema hoy. Necesita entre dos y cuatro horas semanales durante el proyecto.
Y por qué pedirlo antes de tiempo suele salir caro.
Redactar requerimientos sin haber hecho el levantamiento produce especificaciones que describen la solución que imaginaste, no el problema que tienes. El levantamiento es trabajo del proveedor; pedirte que lo hagas es transferirte su responsabilidad.
Un diseño hecho antes de definir el alcance ancla la conversación en cómo se ve y no en qué resuelve. Los diseños llegan después de acordar qué construye la primera versión.
Salvo que tu empresa ya tenga un equipo técnico con un stack definido, la elección de lenguaje o nube es una consecuencia del problema, no un punto de partida. Un proveedor serio te explicará por qué elige lo que elige.
Sirve como contexto, pero la primera versión debe resolver un problema concreto y medible. Las listas largas producen presupuestos largos y proyectos que nunca terminan.
Esto es lo que produce la fase de estructuración. Si un proveedor pasa directo a cotizar sin entregar nada de esto, está cotizando lo que cree que quieres oír.
Qué módulos y funcionalidades incluye la primera versión y, con la misma claridad, qué queda fuera a propósito.
Cómo se conecta con tus sistemas actuales y dónde se despliega: en la nube del proveedor o en una cuenta a nombre de tu empresa.
Qué recibes en cada etapa, en qué orden, y con qué criterios se acepta cada entrega antes de pasar a la siguiente.
Con lo que incluye y lo que se cobra aparte (licencias, infraestructura, soporte). Una cifra única sin desglose es una cifra que va a cambiar.
Datos incompletos, integraciones sin API, adopción del equipo. Qué puede salir mal y qué se hará si ocurre.
Qué viene después de la primera versión y qué decisiones de hoy la preparan para crecer sin reescribirla.
En GeekCorp esta fase es una consultoría inicial sin costo y termina en un documento de alcance con propuesta formal. Lo que se firma es lo mismo que se construye.
El punto de partida no fue una lista de funcionalidades sino un problema operativo: el transporte público de Montería no tenía forma de saber en tiempo real dónde estaba cada bus ni cuánto se recaudaba. "Modernizar el transporte" es una frase que no se puede cotizar; ese problema sí.
De ahí salió una división por fases con entregables que se podían usar y aceptar por separado: primero el monitoreo de flota, luego los validadores a bordo, después las aplicaciones para usuarios y para operadores. Cada fase tenía sus criterios de aceptación antes de pasar a la siguiente.
El proyecto tomó doce meses para el alcance completo de una ciudad, se ejecutó en el marco del convenio 1367-2024 del Ministerio TIC con la Universidad Nacional de Colombia, y hoy está en operación a la vista de cualquiera. Sin esa estructura habría sido un proyecto imposible de aceptar, de pagar y de terminar.
No. Necesitas conocer tu operación y poder explicar el problema en términos de negocio. Traducirlo a decisiones técnicas es trabajo del proveedor, y un proveedor serio te explica esas decisiones en un lenguaje que puedas evaluar.
Es la situación normal. El alcance sale del levantamiento, no lo trae el cliente. Lo que sí necesitas tener claro es el problema: qué duele, a quién y cuánto cuesta hoy. Con eso se define una primera versión que lo resuelva y se deja el resto para después.
Entre una y tres semanas según el tamaño de la operación, e incluye conversaciones con quienes ejecutan el proceso. En GeekCorp esta consultoría inicial no tiene costo y termina en un documento de alcance con propuesta formal. Si tu caso se resuelve mejor con una herramienta que ya existe, te lo decimos ahí.
Puedes, pero cualquier cifra dada antes de entender tu operación es inventada, tanto si viene de nosotros como de cualquier otro proveedor. Una cotización rápida sirve para comparar quién pregunta más antes de responder, no para saber cuánto cuesta el proyecto.
Op-Tra, el sistema de modernización del transporte público de Montería, partió de un problema operativo (controlar la flota y el recaudo en tiempo real) y se dividió en fases con entregables: monitoreo de flota, validadores a bordo, aplicaciones para usuarios y operadores. Tomó doce meses para el alcance completo de una ciudad y hoy está en operación. Sin esa división por fases habría sido un proyecto imposible de aceptar y de pagar.
Alcance, entregables por fase, criterios de aceptación, presupuesto con lo que incluye y lo que no, quién queda dueño del código y de las cuentas, cómo se manejan los cambios de alcance, garantía y soporte, y qué recibes si terminas la relación. Tenemos una guía completa con checklist para evaluar proveedores.
Describe el problema con tus palabras. Te respondemos con las preguntas que necesitamos para estructurarlo, no con una cotización genérica.
(+57) 301 120 3779
info@geekcorp.co
Sede: Córdoba · Presencia en Montería y Barranquilla
¡Contáctanos por WhatsApp!