Comprar, configurar o construir: cómo decidir
Compre cuando el problema ya está resuelto y es común a todo su sector. Configure cuando el problema es común pero su operación no lo es. Construya solo cuando el problema es suyo y es exactamente aquello que lo diferencia. La mayoría de las organizaciones construye demasiado pronto y configura demasiado tarde.
Las tres opciones no son grados de la misma decisión
Se suelen presentar como una escala de personalización: comprar es lo rápido, construir es lo hecho a medida, y configurar está en medio. Es una lectura equivocada y explica buena parte de los proyectos que se atascan.
Son tres compromisos distintos. Al comprar, adopta el modelo de negocio que el producto trae dentro y adapta su operación a él. Al configurar, adapta una plataforma a su proceso dentro de los límites que la plataforma permite. Al construir, define todo — y se queda con el mantenimiento para siempre.
¿Cuándo conviene comprar?
Cuando el problema ya está resuelto y no es donde compite. Contabilidad, nómina, facturación, gestión documental, ERP: miles de organizaciones han recorrido ese camino y el producto incorpora sus lecciones.
La señal de alarma más útil aquí es incómoda: si su proceso no encaja con el producto y no puede explicar en una frase qué ventaja comercial le da esa diferencia, lo que está mal es su proceso, no el producto. Personalizar un ERP para conservar una forma de trabajar que nadie eligió conscientemente es la manera más común de convertir una compra en un desarrollo.
¿Cuándo conviene configurar?
Cuando el problema es común pero su operación no lo es. Es el caso de la mayoría de los proyectos, y el que más se subestima.
Atender clientes por WhatsApp es un problema común: existen plataformas maduras que resuelven la conectividad, la entregabilidad, el inbox, el enrutamiento y la analítica. Pero cómo califica un prospecto, cuándo entra una persona o qué pasa con una conversación que no cerró es específico de cada organización. Ahí la configuración no es una limitación: es el punto donde se decide si el sistema sirve.
Las plataformas actuales admiten mucha más adaptación de la que se les supone. Antes de concluir que hay que construir, conviene saber exactamente dónde topa la que ya tiene.
¿Cuándo conviene construir?
Solo cuando el problema es suyo y es el que lo diferencia. No cuando la plataforma le resulta incómoda, ni cuando falta una función, ni cuando el proveedor tarda en responder.
Construimos WePadel, nuestro producto para comunidades de pádel, por esa razón: el historial y el ranking del jugador tenían que sobrevivir al cambio de club, y ninguna plataforma existente lo permitía porque todas asumen que los datos pertenecen al club. No era una función que faltaba, era la premisa del producto. Ese es el umbral.
Si lo que le falta se puede describir como una lista de funciones, todavía no está en ese umbral.
El costo que casi nadie calcula
Construir no termina en la puesta en producción. Empieza ahí. Lo que compra al construir no es un sistema: es la obligación permanente de mantenerlo, actualizarlo, corregirlo y evolucionarlo mientras el negocio siga existiendo.
Ese compromiso es razonable cuando el sistema es su diferencial. Es una carga difícil de justificar cuando solo quería evitar una limitación de la plataforma que iba a resolverse en dos versiones.
Cuatro preguntas para decidir
Antes de elegir camino, conteste estas cuatro. Si duda en alguna, todavía no tiene la información para decidir.
- ¿Este proceso es donde compite, o solo algo que tiene que funcionar?
- Si su operación no encaja con el producto, ¿puede explicar en una frase qué gana con esa diferencia?
- ¿Ha comprobado dónde topa realmente la plataforma que ya usa, o lo está suponiendo?
- ¿Quién mantiene lo que construya dentro de tres años, y con qué presupuesto?