Desarrollo de software a medida: cuándo conviene

Software a medida o software ya hecho: la pregunta correcta

Muchas empresas parten preguntando cuánto cuesta un desarrollo a medida, cuando la pregunta previa es otra: ¿existe ya una herramienta que resuelva el 80 % de mi necesidad? Si la respuesta es sí, adaptar un producto existente suele ser más rápido y más barato de mantener que construir desde cero.

El software a medida tiene sentido cuando lo que hace diferente a tu negocio es precisamente el proceso que quieres automatizar. Un sistema genérico está pensado para el promedio de las empresas; si tu operación se aleja de ese promedio, terminarás forzando al equipo a trabajar de una forma que no es la suya.

Una forma útil de decidir es comparar tres caminos: usar un producto tal como viene, configurarlo o ampliarlo con integraciones, o construir una solución propia. Cada uno tiene un costo inicial y uno de largo plazo distintos, y conviene estimar ambos antes de elegir. Elegir a medida por orgullo o por desconocer lo que ya existe es una de las decisiones más caras.

Señales de que un desarrollo a medida puede convenir

No hay una regla única, pero hay síntomas que se repiten. El más claro es cuando el equipo ya usa varias planillas y herramientas conectadas a mano, y alguien dedica horas cada semana a copiar datos de un lugar a otro.

Otro síntoma es que el proceso comercial es propio: por ejemplo, una empresa de servicios técnicos que cotiza por visita, arma presupuestos con materiales variables y necesita que el cliente apruebe antes de ejecutar. Encajar eso en un sistema de facturación estándar suele dejar piezas fuera.

Otro caso es el de una distribuidora que arma pedidos con reglas de precio por cliente, por volumen y por zona de reparto. Si hoy esas reglas viven en la cabeza del vendedor más antiguo, un desarrollo a medida puede dejarlas escritas y aplicarlas siempre igual. Lo importante es que el beneficio se pueda medir: horas ahorradas, errores evitados o ventas que antes se perdían.

• Tienes un proceso diferenciador que ningún producto del mercado cubre bien.
• Pagas por módulos o licencias que casi no usas y aun así te falta lo esencial.
• Necesitas integrar sistemas que no se conectan entre sí.
• Los errores manuales (digitar dos veces, olvidar un paso) te cuestan dinero medible.
• El proceso es estable y lo conoces lo bastante bien como para describirlo con detalle.

Cuándo no conviene desarrollar algo propio

Hay necesidades que ya están resueltas de forma madura: emisión de documentos tributarios electrónicos, contabilidad básica, control de inventario general. Reinventarlas implica asumir cambios normativos, soporte y seguridad que un producto establecido ya absorbe.

Tampoco conviene si el proceso aún no está definido. Si hoy cada vendedor cotiza a su manera y nadie sabe cuál es el flujo correcto, programarlo solo congela el desorden. En ese caso, primero se ordena el proceso y después se decide la herramienta.

Cómo levantar requerimientos sin perderse en detalles

Un buen levantamiento parte por observar el trabajo real, no por pedir una lista de deseos. Conversa con quienes operan el proceso a diario, mira cómo usan hoy sus planillas y anota dónde se detienen, dónde corrigen y qué información buscan una y otra vez.

Con eso se construye una lista priorizada. Lo útil es separar lo indispensable de lo deseable y escribirlo como situaciones concretas, por ejemplo: «cuando un cliente acepta el presupuesto, el sistema debe reservar los materiales y generar la orden de trabajo».

Conviene validar esa lista con quienes usarán el sistema y no solo con la gerencia. Es habitual que el dueño describa el proceso ideal y que el equipo operativo conozca los atajos y excepciones que de verdad ocurren. Un recorrido conjunto, con ejemplos reales de las últimas semanas, evita descubrir esos casos recién en las pruebas.

• Quién usa el sistema y qué hace en cada paso.
• Qué datos entran, de dónde vienen y quién los valida.
• Qué reportes o documentos deben salir.
• Qué excepciones ocurren seguido (devoluciones, descuentos, anulaciones).
• Qué sistemas existentes deben seguir funcionando o conectarse.

Alcance inicial: empezar por una versión mínima útil

Los proyectos a medida fracasan más por alcance excesivo que por falta de técnica. Conviene definir una primera versión que resuelva el dolor principal y pueda usarse en la operación real en pocas semanas, aunque sea con funciones limitadas.

Por ejemplo, una distribuidora con rutas de reparto puede partir solo con el registro de pedidos y la hoja de ruta diaria, dejando para una segunda etapa los reportes de rentabilidad por cliente. Usar la primera versión permite corregir supuestos con datos reales antes de invertir en lo siguiente.

Costos más allá del desarrollo inicial

El costo de construir es solo una parte. Un sistema propio requiere alojamiento, respaldos, actualizaciones de seguridad, correcciones y mejoras a medida que el negocio cambia. Pregunta desde el inicio cómo se resolverá cada uno de esos puntos y quién responderá cuando algo falle.

El mantenimiento de un sistema requiere un esfuerzo continuo y no un gasto único. Si el contrato no lo contempla, es probable que la empresa termine pagando urgencias o dejando funciones sin actualizar. Pide que el presupuesto separe construcción, soporte mensual y mejoras futuras.

También cuenta el costo interno: horas del equipo para explicar procesos, probar y capacitarse. Subestimarlo es habitual, y es una de las razones por las que los proyectos se alargan.

• Mantenimiento y soporte posterior a la entrega.
• Cambios normativos que afecten el sistema, como los del SII si emite documentos.
• Respaldos y plan de recuperación ante fallas.
• Documentación para no depender de una sola persona.
• Tiempo interno de pruebas y capacitación.

Propiedad del código y dependencia del proveedor

Antes de firmar conviene dejar claro de quién es el código, qué ocurre si cambias de proveedor y en qué tecnologías se construye. Un desarrollo en tecnologías comunes y con documentación suficiente permite que otro equipo lo continúe si hace falta.

Pide acceso al repositorio, a los entornos y a los datos. Un sistema que solo puede mantener quien lo creó convierte a la empresa en rehén, aunque el contrato sea cordial.

También es sano acordar cómo se entregarán las versiones: con ambientes de prueba separados del real, para que un cambio nunca se pruebe directamente con las ventas del día. Y que exista un registro de cambios, de modo que cualquier persona pueda saber qué se modificó y cuándo.

Cómo evaluar a quien desarrollará el proyecto

Más que la presentación comercial, mira cómo hace preguntas. Un buen equipo desafía tus supuestos, propone alternativas más simples y es capaz de decirte cuándo algo no vale la pena construirlo.

Pide ver trabajos anteriores y, si es posible, conversa con algún cliente sobre cómo fue el soporte después de la entrega. Desconfía de las promesas de plazos muy cortos sin haber entendido el proceso.

Otra buena señal es que el proveedor proponga entregas parciales y te muestre avances funcionando cada pocas semanas. Así detectas desvíos cuando todavía son baratos de corregir, en lugar de recibir un producto terminado que no se parece a lo que imaginabas.

Lista de decisión antes de avanzar

Antes de contratar, responde estas preguntas por escrito. Si varias quedan sin respuesta, probablemente falta trabajo de definición y conviene hacerlo primero.

• ¿Qué problema concreto resolveremos y cómo mediremos que mejoró?
• ¿Qué alternativas existentes evaluamos y por qué no bastan?
• ¿Cuál es la primera versión y en cuánto tiempo se usará en la operación?
• ¿Quién de nuestro equipo será la contraparte y tendrá tiempo para ello?
• ¿Quién mantiene el sistema, con qué condiciones y a qué costo?
• ¿Tenemos acceso al código, a los datos y a la documentación?