Desarrollo a medida o software estándar: cómo decidir
La pregunta no es cuál es mejor. Es qué parte de tu operación te distingue de tu competencia y cuál no. Un criterio para clasificar cada proceso, y las cuatro situaciones en las que construir es un error caro.
Lectura de 9 minutos
En esta guía
Respuesta corta
Construye a la medida solo lo que te distingue de tu competencia. Todo lo demás —contabilidad, nómina, facturación, inventario básico— cómpralo hecho: son procesos donde ser diferente no te da ventaja, te da trabajo. La mayoría de las empresas en México termina en un modelo híbrido: un ERP estándar como base y dos o tres módulos propios donde el negocio realmente se juega.
La pregunta está mal planteada
"¿Nos conviene un software a la medida o uno estándar?" es una pregunta que no se puede responder, porque supone que la empresa es una sola cosa. No lo es. Una empresa son veinte procesos distintos, y cada uno tiene su propia respuesta.
Tu contabilidad no te distingue de nadie. Cumple la ley igual en tu empresa que en la de enfrente, y si es diferente probablemente es porque está mal. Tu forma de programar la producción cuando entran tres pedidos urgentes el mismo día, en cambio, puede ser exactamente la razón por la que tus clientes te eligen.
La pregunta correcta es esta: ¿en qué procesos ser diferente me da ventaja, y en cuáles solo me da trabajo? Los primeros se construyen. Los segundos se compran hechos.
La prueba de los treinta segundos
Toma un proceso y pregúntate: si mañana lo hiciera exactamente igual que mi competencia, ¿perdería algo? Si la respuesta es no, ese proceso no merece software propio. Si la respuesta es que perderías margen, tiempo de entrega o clientes, ahí sí hay algo que vale la pena construir.
No son dos caminos, son tres
La discusión suele plantearse como una disyuntiva, pero en la práctica hay un escalón intermedio que resuelve la mayoría de los casos y casi nadie menciona.
| Camino | En qué consiste | Cuándo es la respuesta correcta |
|---|---|---|
| Configurar | Ajustar un producto estándar con sus propias opciones, sin escribir código | El proceso es común y el producto ya lo contempla |
| Extender | Agregar campos, reglas o reportes propios sobre la base del producto | El proceso es casi común, con dos o tres particularidades tuyas |
| Construir | Desarrollar el módulo desde cero, integrado al resto | El proceso es tuyo y ningún producto lo contempla |
El error más común no es elegir mal entre configurar y construir: es saltarse el escalón de en medio. Buena parte de lo que se pide como desarrollo se resuelve extendiendo.
Un proveedor que responde a todo con "eso lo desarrollamos" debería explicarte por qué configurar no alcanza. Uno que responde a todo con "el sistema no lo hace así, hay que adaptar el proceso" te está pidiendo que cambies la operación para acomodar una herramienta, y eso solo tiene sentido cuando el proceso actual no aporta nada.
Cuándo no construir
Estas son las cuatro situaciones donde desarrollar a la medida es un error, aunque el proveedor esté dispuesto a cobrarlo:
- El proceso está regulado. Facturación electrónica, cumplimiento fiscal, nómina. La ley cambia y el producto estándar se actualiza solo. Si lo construyes, cada reforma es un proyecto tuyo.
- Es un proceso de manual. Contabilidad, cuentas por pagar, control de vacaciones. Hacerlos distinto no te da ventaja; te da un sistema que solo tú sabes usar.
- Lo pides porque el equipo no quiere cambiar. A veces "el sistema tiene que hacerlo como lo hacemos" significa "no queremos revisar cómo lo hacemos". Vale la pena distinguir un proceso valioso de una costumbre.
- Todavía no sabes cómo debería funcionar. Si el proceso está en discusión, construir lo congela en su versión menos pensada. Primero se define, después se automatiza.
Construir un proceso que estás por rediseñar es pagar dos veces por la misma cosa.
Brenda Infinite® · INCEPTIOCuándo sí construir
Y estas son las cuatro donde el producto estándar te va a quedar corto, sin importar cuánto lo configures:
- El proceso es tu ventaja competitiva. Si tus clientes te eligen por cómo haces algo, ese algo no puede depender de lo que un fabricante de software decidió incluir.
- Tienes reglas que ningún producto contempla. Reglas de precio por combinación de cliente, volumen y temporada. Secuencias de producción con restricciones propias. Cálculos de comisión que se negociaron uno por uno.
- Necesitas conectar sistemas que no se hablan. Un ERP, un piso de planta, un almacén y una plataforma de venta que deben compartir un solo dato. Eso rara vez viene resuelto y casi siempre se construye.
- El volumen rompe la herramienta estándar. Cuando un producto genérico empieza a tardar minutos en lo que debería tomar segundos, ya no es cuestión de configuración.
Cómo clasificar cada proceso
Este es el ejercicio concreto. Haz una lista de tus procesos y pásalos por tres preguntas. La combinación de respuestas da el camino.
| Pregunta | Si la respuesta es sí | Si la respuesta es no |
|---|---|---|
| ¿Mis clientes notarían si lo hiciera como todos? | Candidato a construir | Producto estándar |
| ¿Está regulado por una autoridad? | Producto estándar, siempre | Depende de las otras dos |
| ¿Sé exactamente cómo debe funcionar hoy? | Se puede automatizar ya | Primero definir el proceso |
Un proceso que responde sí a la primera, no a la segunda y sí a la tercera es el caso claro de desarrollo a la medida. Todo lo demás merece una conversación antes de decidir.
Al terminar el ejercicio, la mayoría de las empresas descubre lo mismo: de veinte procesos, dos o tres justifican software propio. Los otros diecisiete no. Esa proporción es la que hace que el modelo híbrido sea la respuesta más frecuente.
El costo que nadie compara
Las comparaciones suelen mirar el precio inicial, que es la parte menos importante. Un producto estándar arranca barato y un desarrollo arranca caro, pero eso no dice quién sale mejor en cinco años.
| Concepto | Producto estándar | Desarrollo a la medida |
|---|---|---|
| Inversión inicial | Baja: licencia más configuración | Alta: análisis, construcción y pruebas |
| Costo recurrente | Licencia por usuario, cada mes, para siempre | Mantenimiento, generalmente menor que la licencia |
| Un cambio en el proceso | Depende de que el fabricante lo contemple | Se agenda y se hace |
| Actualizaciones | Incluidas y automáticas | A tu cargo, con un plan de versiones |
| Si creces al doble | Se duplica el costo de licencias | El costo no crece con los usuarios |
| Propiedad | Del fabricante; tú rentas el uso | Tuya, con el código fuente en tu poder |
En INCEPTIO todo desarrollo a la medida es propiedad del cliente y se entrega con el código fuente. Puedes consultar los rangos de licencia de un ERP estándar en la guía de costos de Odoo en México.
El punto de quiebre
La licencia por usuario es un costo que crece con tu empresa. El desarrollo propio es una inversión que se paga una vez. Si planeas duplicar la plantilla en tres años, la cuenta cambia por completo, y conviene hacerla antes de comprometerse a un modelo por usuario.
Lo híbrido, que es lo que casi siempre pasa
En la práctica muy pocas empresas terminan en uno de los extremos. Lo que funciona es una base estándar que resuelve los procesos comunes, más módulos propios en los dos o tres puntos donde el negocio se juega.
Un caso típico en manufactura: el ERP lleva contabilidad, compras, inventario y facturación, todo configurado sin escribir una línea. Y encima corre un módulo propio de programación de producción, porque las reglas de secuenciado son de la empresa y ningún producto las contempla.
Lo que hace viable ese modelo es la integración. Si el módulo propio y el ERP no comparten el mismo dato en tiempo real, lo híbrido se convierte en dos sistemas que alguien concilia a mano cada mes, y ahí se pierde todo el beneficio.
Cómo decidir en una hora
No hace falta un estudio de tres meses para tener claridad. Con una hora y una hoja se avanza más de lo que parece:
- Lista tus procesos, sin detalle. Diez o quince renglones bastan. Facturar, comprar, producir, entregar, cobrar, pagar nómina.
- Marca los que un cliente notaría. Si cambiaran, ¿alguien fuera de la empresa se daría cuenta? Esos son los candidatos.
- Tacha los regulados. Van a producto estándar sin discusión.
- De los que quedan, marca los que hoy se resuelven en hoja de cálculo. Casi siempre son los que más duelen y los que más rápido rinden.
- Ordena por dolor, no por facilidad. El proceso que más tiempo consume o más errores genera va primero, aunque no sea el más sencillo.
Lo que sale de ahí no es una decisión final, pero sí una conversación mucho mejor con cualquier proveedor. Y si en ese ejercicio descubres que casi todo cae en producto estándar, es una buena noticia: significa que tu operación no necesita software propio para funcionar bien, y ese dinero rinde más en otro lado.
Preguntas frecuentes
Depende del proceso, no de la empresa. Conviene construir a la medida solo lo que te distingue de tu competencia: si tus clientes te eligen por cómo haces algo, ese algo no puede depender de lo que un fabricante decidió incluir. Todo lo demás —contabilidad, nómina, facturación, inventario básico— conviene comprarlo hecho. La mayoría de las empresas termina en un modelo híbrido.
En cuatro casos: cuando el proceso está regulado y el producto estándar se actualiza solo ante cada cambio de ley; cuando es un proceso de manual donde ser distinto no da ventaja; cuando se pide porque el equipo no quiere revisar cómo trabaja; y cuando todavía no está definido cómo debería funcionar, porque construirlo lo congela en su versión menos pensada.
Sí, y es la que resuelve la mayoría de los casos: extender. Consiste en agregar campos, reglas o reportes propios sobre la base de un producto estándar, sin construir el módulo desde cero. Aplica cuando el proceso es casi común pero tiene dos o tres particularidades tuyas. El error más frecuente no es elegir mal entre los extremos, es saltarse este escalón.
Con tres preguntas. ¿Mis clientes notarían si lo hiciera como todos? ¿Está regulado por una autoridad? ¿Sé exactamente cómo debe funcionar hoy? Un proceso que responde sí, no y sí es el caso claro de desarrollo a la medida. Si está regulado, va a producto estándar siempre. Si no sabes cómo debería funcionar, primero se define el proceso y después se automatiza.
Al inicio sí, pero la comparación por precio inicial engaña. La licencia de un producto estándar es un costo por usuario que se paga cada mes para siempre y crece cuando crece la empresa; el desarrollo propio se paga una vez y su costo no aumenta con los usuarios. Si planeas duplicar la plantilla en tres años, la cuenta a cinco años cambia por completo.
En INCEPTIO, del cliente. Todo desarrollo a la medida se entrega con el código fuente y es propiedad de quien lo contrató. No hay dependencia obligatoria del proveedor para mantenerlo ni cobro por liberarlo: si algún día decides continuar con otro equipo, te llevas el sistema completo.
Sí, y es el modelo más frecuente. Un caso típico en manufactura: el ERP lleva contabilidad, compras, inventario y facturación configurados sin escribir código, y encima corre un módulo propio de programación de producción porque las reglas de secuenciado son de la empresa. Lo que hace viable ese modelo es la integración: si ambos no comparten el mismo dato en tiempo real, terminan siendo dos sistemas que alguien concilia a mano.
Una hora de trabajo propio alcanza para avanzar bastante: listar diez o quince procesos, marcar los que un cliente notaría si cambiaran, tachar los regulados, y de los que queden señalar los que hoy se resuelven en hoja de cálculo. No es una decisión final, pero convierte cualquier conversación con un proveedor en algo mucho más productivo.
¿Ya hiciste el ejercicio y quedaste con dudas?
En el diagnóstico revisamos tus procesos uno por uno y te decimos cuáles configurar, cuáles extender y cuáles construir. Si la respuesta es que no necesitas desarrollo, esa también es una respuesta válida y te la damos igual.
Desarrollo a medida o software estándar: cómo decidir
La pregunta no es cuál es mejor. Es qué parte de tu operación te distingue de tu competencia y cuál no. Un criterio para clasificar cada proceso, y las cuatro situaciones en las que construir es un error caro.
Lectura de 9 minutos
En esta guía
Respuesta corta
Construye a la medida solo lo que te distingue de tu competencia. Todo lo demás —contabilidad, nómina, facturación, inventario básico— cómpralo hecho: son procesos donde ser diferente no te da ventaja, te da trabajo. La mayoría de las empresas en México termina en un modelo híbrido: un ERP estándar como base y dos o tres módulos propios donde el negocio realmente se juega.
La pregunta está mal planteada
"¿Nos conviene un software a la medida o uno estándar?" es una pregunta que no se puede responder, porque supone que la empresa es una sola cosa. No lo es. Una empresa son veinte procesos distintos, y cada uno tiene su propia respuesta.
Tu contabilidad no te distingue de nadie. Cumple la ley igual en tu empresa que en la de enfrente, y si es diferente probablemente es porque está mal. Tu forma de programar la producción cuando entran tres pedidos urgentes el mismo día, en cambio, puede ser exactamente la razón por la que tus clientes te eligen.
La pregunta correcta es esta: ¿en qué procesos ser diferente me da ventaja, y en cuáles solo me da trabajo? Los primeros se construyen. Los segundos se compran hechos.
La prueba de los treinta segundos
Toma un proceso y pregúntate: si mañana lo hiciera exactamente igual que mi competencia, ¿perdería algo? Si la respuesta es no, ese proceso no merece software propio. Si la respuesta es que perderías margen, tiempo de entrega o clientes, ahí sí hay algo que vale la pena construir.
No son dos caminos, son tres
La discusión suele plantearse como una disyuntiva, pero en la práctica hay un escalón intermedio que resuelve la mayoría de los casos y casi nadie menciona.
| Camino | En qué consiste | Cuándo es la respuesta correcta |
|---|---|---|
| Configurar | Ajustar un producto estándar con sus propias opciones, sin escribir código | El proceso es común y el producto ya lo contempla |
| Extender | Agregar campos, reglas o reportes propios sobre la base del producto | El proceso es casi común, con dos o tres particularidades tuyas |
| Construir | Desarrollar el módulo desde cero, integrado al resto | El proceso es tuyo y ningún producto lo contempla |
El error más común no es elegir mal entre configurar y construir: es saltarse el escalón de en medio. Buena parte de lo que se pide como desarrollo se resuelve extendiendo.
Un proveedor que responde a todo con "eso lo desarrollamos" debería explicarte por qué configurar no alcanza. Uno que responde a todo con "el sistema no lo hace así, hay que adaptar el proceso" te está pidiendo que cambies la operación para acomodar una herramienta, y eso solo tiene sentido cuando el proceso actual no aporta nada.
Cuándo no construir
Estas son las cuatro situaciones donde desarrollar a la medida es un error, aunque el proveedor esté dispuesto a cobrarlo:
- El proceso está regulado. Facturación electrónica, cumplimiento fiscal, nómina. La ley cambia y el producto estándar se actualiza solo. Si lo construyes, cada reforma es un proyecto tuyo.
- Es un proceso de manual. Contabilidad, cuentas por pagar, control de vacaciones. Hacerlos distinto no te da ventaja; te da un sistema que solo tú sabes usar.
- Lo pides porque el equipo no quiere cambiar. A veces "el sistema tiene que hacerlo como lo hacemos" significa "no queremos revisar cómo lo hacemos". Vale la pena distinguir un proceso valioso de una costumbre.
- Todavía no sabes cómo debería funcionar. Si el proceso está en discusión, construir lo congela en su versión menos pensada. Primero se define, después se automatiza.
Construir un proceso que estás por rediseñar es pagar dos veces por la misma cosa.
Brenda Infinite® · INCEPTIOCuándo sí construir
Y estas son las cuatro donde el producto estándar te va a quedar corto, sin importar cuánto lo configures:
- El proceso es tu ventaja competitiva. Si tus clientes te eligen por cómo haces algo, ese algo no puede depender de lo que un fabricante de software decidió incluir.
- Tienes reglas que ningún producto contempla. Reglas de precio por combinación de cliente, volumen y temporada. Secuencias de producción con restricciones propias. Cálculos de comisión que se negociaron uno por uno.
- Necesitas conectar sistemas que no se hablan. Un ERP, un piso de planta, un almacén y una plataforma de venta que deben compartir un solo dato. Eso rara vez viene resuelto y casi siempre se construye.
- El volumen rompe la herramienta estándar. Cuando un producto genérico empieza a tardar minutos en lo que debería tomar segundos, ya no es cuestión de configuración.
Cómo clasificar cada proceso
Este es el ejercicio concreto. Haz una lista de tus procesos y pásalos por tres preguntas. La combinación de respuestas da el camino.
| Pregunta | Si la respuesta es sí | Si la respuesta es no |
|---|---|---|
| ¿Mis clientes notarían si lo hiciera como todos? | Candidato a construir | Producto estándar |
| ¿Está regulado por una autoridad? | Producto estándar, siempre | Depende de las otras dos |
| ¿Sé exactamente cómo debe funcionar hoy? | Se puede automatizar ya | Primero definir el proceso |
Un proceso que responde sí a la primera, no a la segunda y sí a la tercera es el caso claro de desarrollo a la medida. Todo lo demás merece una conversación antes de decidir.
Al terminar el ejercicio, la mayoría de las empresas descubre lo mismo: de veinte procesos, dos o tres justifican software propio. Los otros diecisiete no. Esa proporción es la que hace que el modelo híbrido sea la respuesta más frecuente.
El costo que nadie compara
Las comparaciones suelen mirar el precio inicial, que es la parte menos importante. Un producto estándar arranca barato y un desarrollo arranca caro, pero eso no dice quién sale mejor en cinco años.
| Concepto | Producto estándar | Desarrollo a la medida |
|---|---|---|
| Inversión inicial | Baja: licencia más configuración | Alta: análisis, construcción y pruebas |
| Costo recurrente | Licencia por usuario, cada mes, para siempre | Mantenimiento, generalmente menor que la licencia |
| Un cambio en el proceso | Depende de que el fabricante lo contemple | Se agenda y se hace |
| Actualizaciones | Incluidas y automáticas | A tu cargo, con un plan de versiones |
| Si creces al doble | Se duplica el costo de licencias | El costo no crece con los usuarios |
| Propiedad | Del fabricante; tú rentas el uso | Tuya, con el código fuente en tu poder |
En INCEPTIO todo desarrollo a la medida es propiedad del cliente y se entrega con el código fuente. Puedes consultar los rangos de licencia de un ERP estándar en la guía de costos de Odoo en México.
El punto de quiebre
La licencia por usuario es un costo que crece con tu empresa. El desarrollo propio es una inversión que se paga una vez. Si planeas duplicar la plantilla en tres años, la cuenta cambia por completo, y conviene hacerla antes de comprometerse a un modelo por usuario.
Lo híbrido, que es lo que casi siempre pasa
En la práctica muy pocas empresas terminan en uno de los extremos. Lo que funciona es una base estándar que resuelve los procesos comunes, más módulos propios en los dos o tres puntos donde el negocio se juega.
Un caso típico en manufactura: el ERP lleva contabilidad, compras, inventario y facturación, todo configurado sin escribir una línea. Y encima corre un módulo propio de programación de producción, porque las reglas de secuenciado son de la empresa y ningún producto las contempla.
Lo que hace viable ese modelo es la integración. Si el módulo propio y el ERP no comparten el mismo dato en tiempo real, lo híbrido se convierte en dos sistemas que alguien concilia a mano cada mes, y ahí se pierde todo el beneficio.
Cómo decidir en una hora
No hace falta un estudio de tres meses para tener claridad. Con una hora y una hoja se avanza más de lo que parece:
- Lista tus procesos, sin detalle. Diez o quince renglones bastan. Facturar, comprar, producir, entregar, cobrar, pagar nómina.
- Marca los que un cliente notaría. Si cambiaran, ¿alguien fuera de la empresa se daría cuenta? Esos son los candidatos.
- Tacha los regulados. Van a producto estándar sin discusión.
- De los que quedan, marca los que hoy se resuelven en hoja de cálculo. Casi siempre son los que más duelen y los que más rápido rinden.
- Ordena por dolor, no por facilidad. El proceso que más tiempo consume o más errores genera va primero, aunque no sea el más sencillo.
Lo que sale de ahí no es una decisión final, pero sí una conversación mucho mejor con cualquier proveedor. Y si en ese ejercicio descubres que casi todo cae en producto estándar, es una buena noticia: significa que tu operación no necesita software propio para funcionar bien, y ese dinero rinde más en otro lado.
Preguntas frecuentes
Depende del proceso, no de la empresa. Conviene construir a la medida solo lo que te distingue de tu competencia: si tus clientes te eligen por cómo haces algo, ese algo no puede depender de lo que un fabricante decidió incluir. Todo lo demás —contabilidad, nómina, facturación, inventario básico— conviene comprarlo hecho. La mayoría de las empresas termina en un modelo híbrido.
En cuatro casos: cuando el proceso está regulado y el producto estándar se actualiza solo ante cada cambio de ley; cuando es un proceso de manual donde ser distinto no da ventaja; cuando se pide porque el equipo no quiere revisar cómo trabaja; y cuando todavía no está definido cómo debería funcionar, porque construirlo lo congela en su versión menos pensada.
Sí, y es la que resuelve la mayoría de los casos: extender. Consiste en agregar campos, reglas o reportes propios sobre la base de un producto estándar, sin construir el módulo desde cero. Aplica cuando el proceso es casi común pero tiene dos o tres particularidades tuyas. El error más frecuente no es elegir mal entre los extremos, es saltarse este escalón.
Con tres preguntas. ¿Mis clientes notarían si lo hiciera como todos? ¿Está regulado por una autoridad? ¿Sé exactamente cómo debe funcionar hoy? Un proceso que responde sí, no y sí es el caso claro de desarrollo a la medida. Si está regulado, va a producto estándar siempre. Si no sabes cómo debería funcionar, primero se define el proceso y después se automatiza.
Al inicio sí, pero la comparación por precio inicial engaña. La licencia de un producto estándar es un costo por usuario que se paga cada mes para siempre y crece cuando crece la empresa; el desarrollo propio se paga una vez y su costo no aumenta con los usuarios. Si planeas duplicar la plantilla en tres años, la cuenta a cinco años cambia por completo.
En INCEPTIO, del cliente. Todo desarrollo a la medida se entrega con el código fuente y es propiedad de quien lo contrató. No hay dependencia obligatoria del proveedor para mantenerlo ni cobro por liberarlo: si algún día decides continuar con otro equipo, te llevas el sistema completo.
Sí, y es el modelo más frecuente. Un caso típico en manufactura: el ERP lleva contabilidad, compras, inventario y facturación configurados sin escribir código, y encima corre un módulo propio de programación de producción porque las reglas de secuenciado son de la empresa. Lo que hace viable ese modelo es la integración: si ambos no comparten el mismo dato en tiempo real, terminan siendo dos sistemas que alguien concilia a mano.
Una hora de trabajo propio alcanza para avanzar bastante: listar diez o quince procesos, marcar los que un cliente notaría si cambiaran, tachar los regulados, y de los que queden señalar los que hoy se resuelven en hoja de cálculo. No es una decisión final, pero convierte cualquier conversación con un proveedor en algo mucho más productivo.
¿Ya hiciste el ejercicio y quedaste con dudas?
En el diagnóstico revisamos tus procesos uno por uno y te decimos cuáles configurar, cuáles extender y cuáles construir. Si la respuesta es que no necesitas desarrollo, esa también es una respuesta válida y te la damos igual.