📋 Resumen ejecutivo
- La pregunta “¿a medida o estándar?” es casi siempre una pregunta de procesos, no de software.
- La mayoría de los procesos que una PyME considera “únicos” son históricos, no diferenciales. Automatizarlos a medida es pagar por cristalizar el desorden.
- Estándar conviene para procesos commodity, urgencia menor a 90 días, o cuando no tenés quién especifique requerimientos.
- A medida conviene cuando el proceso es tu ventaja competitiva real, ya chocaste contra un techo medible del estándar, y el repago es menor a 24 meses.
- La tercera opción —estándar + módulo satélite a medida— resuelve la mayoría de los casos reales con menor costo y riesgo acotado.
- Regla de presupuesto: un desarrollo propio cuesta 15–20% anual del monto inicial solo en mantenimiento.
Tu sistema de gestión no te alcanza. Hay tres planillas paralelas que nadie unificó, un proceso clave que se hace “a mano” porque el software no lo contempla, y cada vez que pedís un cambio te dicen que está en el roadmap.
Entonces aparece la pregunta: ¿mandamos hacer algo a medida?
Esa decisión, tomada mal, cuesta entre 6 y 18 meses de proyecto y un presupuesto que casi siempre se duplica. Tomada bien, es la diferencia entre una operación que escala y una que se traba. La mayoría de las PyMEs argentinas la toma por el motivo equivocado: porque el sistema actual “no se adapta a cómo trabajamos”. Y ahí está el problema de fondo. Decidir entre software a medida o estándar empieza mucho antes de pedir una cotización.
La pregunta correcta no es “a medida o estándar”
Es: ¿este proceso es una ventaja competitiva o simplemente es cómo lo venimos haciendo?
Un proceso puede ser distinto por dos razones muy diferentes:
- Es diferencial: hacés algo que la competencia no hace, y esa forma de hacerlo es parte de por qué te eligen.
- Es histórico: se hace así porque alguien lo armó hace ocho años y nadie lo revisó.
La mayoría de los procesos que las PyMEs consideran “únicos” son del segundo tipo. Pagar un desarrollo a medida para automatizar un proceso histórico es pagar por cristalizar el desorden. Peor: lo volvés más caro de cambiar, porque ahora está escrito en código.
Antes de cotizar cualquier desarrollo, mapeá el proceso y preguntate si lo defenderías frente a un cliente. Si la respuesta es “y… siempre lo hicimos así”, no necesitás software: necesitás rediseñar el proceso. Y para eso, graficarlo en BPMN antes de automatizar es el paso que no se puede saltear.
Cuándo conviene un software estándar
Un software estándar (SaaS, producto de mercado, vertical de tu industria) tiene sentido cuando:
El proceso es commodity
Facturación, liquidación de sueldos, contabilidad, gestión de stock básica, CRM de ventas. Nadie gana clientes por tener una facturación distinta. Estos procesos ya están resueltos por miles de empresas antes que vos, y el estándar incorpora buenas prácticas que no tenés que descubrir solo.
Necesitás resultados en menos de 90 días
Un estándar se implementa en semanas. Un desarrollo a medida, en meses. Si el dolor es urgente —te estás quedando sin capacidad operativa ahora— el estándar te compra tiempo.
No tenés a nadie que pueda especificar requerimientos
Un desarrollo a medida requiere que alguien de tu lado sepa exactamente qué pedir, valide entregas y decida sobre casos borde. Si esa persona no existe o no tiene tiempo, el proyecto va a fracasar independientemente del proveedor.
El costo de mantenimiento te preocupa
El estándar reparte el costo de evolución entre todos los clientes. El desarrollo a medida lo pagás vos entero, todos los años, para siempre. Regla práctica: presupuestá entre 15% y 20% anual del costo inicial solo para mantener vivo un desarrollo propio.
Necesitás integrarte con el ecosistema
ARCA (ex AFIP), bancos, marketplaces, medios de pago. Los estándares ya tienen esas integraciones resueltas y actualizadas cuando cambia la normativa. En un desarrollo propio, cada cambio regulatorio es un ticket que pagás.
Cuándo conviene desarrollo a medida
El proceso es tu diferencial real
Pensemos en una distribuidora de insumos gastronómicos que arma pedidos combinando stock propio con compra directa a productor según margen y disponibilidad, en tiempo real. Ningún ERP estándar contempla esa lógica, y es exactamente la razón por la que sus clientes le compran a ellos. Ahí el desarrollo se justifica.
El estándar te obliga a operar peor
No a operar distinto: peor. Si adoptar el sistema implica agregar tres pasos manuales, duplicar carga de datos o perder trazabilidad que hoy tenés, el “ahorro” del estándar se te va en horas de gente.
Ya probaste el estándar y chocaste contra un techo medible
Este es el escenario más sólido. Usaste el producto seis meses, documentaste exactamente qué no resuelve, y podés cuantificar cuánto te cuesta ese gap. Ahora tenés una especificación real, no una intuición.
Hay un caso que ilustra bien este punto: un proceso bien documentado que igual no escalaba, porque el volumen superaba lo que cualquier herramienta genérica podía absorber.
El volumen justifica la inversión
Si el desarrollo cuesta X y te ahorra 40 horas mensuales de trabajo administrativo, calculá el repago. Si supera los 24 meses, el número no cierra para una PyME: el negocio cambia más rápido que eso.
La tercera opción que casi nadie evalúa
Entre “compro lo que hay” y “mando a hacer todo desde cero” existe un espectro completo:
| Opción | Cuándo aplica | Costo relativo |
|---|---|---|
| Estándar puro | Proceso commodity | Bajo |
| Estándar + configuración | Necesitás flexibilidad en reglas, no en lógica | Bajo-medio |
| Estándar + integraciones | El core funciona, faltan conexiones | Medio |
| Estándar + módulo satélite a medida | 90% resuelto, un proceso crítico no | Medio |
| Desarrollo a medida completo | El core mismo es diferencial | Alto |
El “estándar + módulo satélite” resuelve la mayoría de los casos reales. Mantenés el ERP o CRM para lo commodity, y desarrollás una aplicación específica que resuelve tu proceso crítico y se integra por API. Costo mucho menor, riesgo acotado, y si el módulo falla no te cae toda la operación.
Aplicación práctica: el checklist de decisión
Antes de pedir una sola cotización, hacé esto:
1. Mapeá el proceso en cuestión. No en la cabeza: en papel o en un diagrama. Actividades, responsables, decisiones, tiempos de espera.
2. Aplicá Lean primero. ¿Cuántos pasos existen solo por controles duplicados, reprocesos o esperas? Sacalos. Un proceso que baja de 14 pasos a 8 antes de automatizarse cuesta la mitad de automatizar. Si no sabés por dónde empezar, revisá los 7 desperdicios Lean que frenan los procesos administrativos.
3. Clasificá cada actividad: commodity o diferencial. Sé honesto. “Nuestra forma de facturar es especial” casi nunca es cierto.
4. Buscá tres soluciones estándar y probalas de verdad. Trial completo, con datos reales, dos semanas mínimo. No demo de vendedor.
5. Documentá los gaps concretos. No “no me gusta la interfaz”. Sí: “no permite asociar un comprobante a más de una orden de compra, y eso pasa 40 veces por mes”.
6. Cuantificá el gap. Horas mensuales perdidas × costo hora. Ese es tu presupuesto máximo razonable para resolverlo a medida, dividido en 24 meses.
7. Recién ahí, cotizá. Y pedí que el desarrollo cubra solo el gap, no todo el sistema.
Antes de avanzar con cualquiera de las dos opciones, conviene verificar que el proceso esté maduro: este checklist Lean te dice si realmente está listo para digitalizarse.
El error más caro: automatizar el caos
Vale la pena decirlo con todas las letras porque es el error que más plata cuesta.
Si tu proceso está desordenado, el software a medida no lo va a ordenar. Lo va a fijar. Vas a pagar para que el desorden sea más rápido, más difícil de cambiar y ahora, además, dependiente de un proveedor.
Los síntomas de que estás por cometerlo:
- No podés explicar el proceso en un diagrama de una carilla
- Cada persona del equipo describe el proceso distinto
- Hay pasos que existen “por las dudas” y nadie sabe quién los pidió
- La especificación funcional que entregaste al desarrollador es un listado de pantallas, no de reglas de negocio
Si tenés dos o más de estos, no estás listo para desarrollar nada. Estás listo para rediseñar.
Este principio no es una opinión de MetrikPro: es un patrón documentado. Las investigaciones del Standish Group sobre proyectos de software vienen mostrando hace años que la mayoría de los fracasos no son técnicos, sino de definición de requerimientos y alcance (Standish Group – CHAOS Report).
Advertencia: los costos ocultos del desarrollo propio
Lo que casi nunca entra en el presupuesto:
- Dependencia del proveedor. Si desaparece, ¿quién mantiene el código? Exigí repositorio propio y documentación desde el día uno. Es la misma lógica de la dependencia del dueño: si todo pasa por un solo punto, tenés un riesgo, no una ventaja.
- Curva de adopción. Un sistema hecho a medida no tiene tutoriales, comunidad ni gente que ya sepa usarlo. La capacitación es 100% tuya.
- Deuda técnica. A los tres años, el desarrollo que hiciste está sobre versiones viejas de todo. Migrar cuesta.
- Costo de oportunidad. Los meses que tu equipo dedica a especificar, validar y testear son meses que no dedica a vender u operar.
Conclusión
La pregunta “¿a medida o estándar?” suele ser una pregunta de software que en realidad es una pregunta de procesos.
Las empresas que eligen bien no son las que analizan mejor el mercado de sistemas: son las que saben exactamente cuál de sus procesos les da ventaja competitiva y cuál es simplemente inercia. Con esa claridad, la decisión técnica se vuelve obvia.
Sin esa claridad, cualquier decisión —comprar o desarrollar— termina siendo cara.
Primero el proceso. Después la tecnología. Siempre en ese orden.
Preguntas frecuentes
Varía demasiado según alcance como para dar un número útil. Lo que sí es estable es la estructura de costos: al monto inicial hay que sumarle entre 15% y 20% anual de mantenimiento, más capacitación interna y el costo de oportunidad del equipo durante la especificación. Si el presupuesto que te pasaron no menciona mantenimiento, está incompleto.
Preguntate si lo defenderías frente a un cliente como razón para elegirte. Si podés explicar por qué esa forma de trabajar te hace ganar negocios, es diferencial. Si la respuesta es “siempre lo hicimos así”, es histórico.
Sí, y suele ser la mejor secuencia. Usar el estándar seis meses te da algo que ninguna cotización previa puede darte: una lista documentada y cuantificada de qué no resuelve. Esa lista es tu especificación real.
Es una aplicación a medida acotada que resuelve un proceso crítico específico y se integra por API con tu sistema estándar. Conviene porque el costo y el riesgo son mucho menores que reemplazar todo el core, y si falla no te cae la operación entera.
No hay número mágico, pero sí una señal: si al mapearlo encontrás pasos que existen por control duplicado, reproceso o espera, sacalos antes de automatizar. Cada paso eliminado es desarrollo que no pagás.
Es el riesgo principal. Se mitiga desde el contrato: repositorio de código en una cuenta tuya, documentación técnica como entregable obligatorio, y stack tecnológico común (no frameworks exóticos) para que otro equipo pueda tomarlo.
¿No sabés en qué categoría cae tu operación?
Flow 360° es un diagnóstico gratuito que te ayuda a mapear tus procesos y detectar cuáles son diferenciales y cuáles son solo inercia acumulada. En 15 minutos vas a tener mucho más claro si necesitás un sistema nuevo o un proceso nuevo.
Deja un comentario