Decide primero el problema, no la tecnología
El error empieza con la pregunta “¿construir o comprar?”. Yo primero preguntaría si esta función es una ventaja competitiva. Para una transcripción típica puedes comprar. Para datos y reglas únicos, puede que necesites tu propio flujo de trabajo.
El error que eliminaría primero: Construir un sistema propio para controlar una tarea commodity.
Qué preparar y qué resultado esperar
- Resultado: Comparas opciones por coste total de propiedad y las validas en un solo piloto.
- Anota usuarios, proceso, integraciones, datos, plazos, restricciones obligatorias y una vía de salida de la solución.
- Mantén los datos de origen y los permisos de acceso separados del resultado para poder verificar qué hizo realmente el trabajo de decisión build-or-buy.
- Para dos opciones mide tiempo hasta el resultado, precisión, coste por operación, exportación de datos y sustitución del proveedor.
Compara comprar, construir e híbrido en un solo piloto
- Reúne requisitos antes de elegir
En una sola tabla fija tarea, usuarios, integraciones, clases de datos, SLA, volumen y prohibiciones firmes.
Проверьте: Los requisitos no incluyen la palabra “moderno” sin un significado medible.
Если не сработало: Sustituye un deseo por un criterio: tiempo, precisión, acceso, exportación.
- Puntúa opciones con pesos
Rellena una matriz 1–5: ajuste 25%, seguridad 20%, velocidad 20%, coste a 3 años 20%, control/portabilidad 15%. Puntuación = suma(rating × peso) / 5.
Проверьте: Los pesos reflejan el riesgo de negocio, no el gusto personal de un desarrollador.
Если не сработало: Alinea los pesos con el responsable del proceso y con seguridad.
- Calcula el TCO
TCO de compra = licencias + implementación + integraciones + formación + salida. TCO de construcción = análisis + desarrollo + pruebas + infraestructura + soporte.
Проверьте: Hay una estimación de soporte y de propiedad en el tercer año.
Если не сработало: Añade un rango y declara los supuestos de forma explícita.
- Ejecuta el mismo piloto
Da a ambas opciones la misma muestra de entrada y el mismo criterio de resultado. Comprueba no solo la calidad, sino lo fácil que es corregir un error y exportar los datos.
Проверьте: La decisión se toma tras una tarea real, no una presentación.
Если не сработало: Detén el piloto si no puedes verificar el resultado con seguridad.
Comparo tres opciones
Añade a la tabla SaaS, API + tu propio flujo y un sistema totalmente a medida. Para cada una calcula el TCO a 3 años: lanzamiento, licencias, API, integraciones, personas, seguridad, infraestructura, soporte y migración. No compares una suscripción mensual con el salario de un desarrollador.
Puntúa velocidad de lanzamiento 20%, ajuste 20%, TCO 20%, control de datos 15%, seguridad 15% y salida del proveedor 10%. Puntuación = suma(rating × peso). Antes de decidir, ejecuta 20 casos reales e intenta exportar los datos.
TCO = launch + licenses + API + integrations + people + security + support
Score = sum(rating * weight)Prueba de salida del proveedor
Pide una exportación en un formato claro, comprueba el borrado de datos, los derechos de acceso, el SLA, el precio de un crecimiento de volumen ×10 y el plazo de migración. Si la empresa no puede nombrar un responsable del sistema tras el lanzamiento, da igual si es build o buy: la solución aún no está lista.
Un piloto que zanja la discusión
Da a SaaS, a un flujo por API y al desarrollo a medida la misma muestra de 20 ejemplos reales. En cada uno registra tiempo, precisión, correcciones manuales, coste y si se pueden exportar los datos de origen. No decidas a partir de una demo con entrada perfecta.
Si un servicio listo cubre el 80% de un proceso típico y el 20% restante puede seguir manual, a menudo es mejor que una plataforma completa. Elige un sistema a medida solo con un responsable, presupuesto de soporte y plan de salida; si no, el “control” termina en un desarrollador que se fue de vacaciones.
Cómo puntuar una opción que vivirá tres años
| Criterio | Pregunta | Buena señal |
|---|---|---|
| Entrada | ¿Qué entra exactamente en la decisión build-or-buy? | Anota usuarios, proceso, integraciones, datos, plazos, restricciones obligatorias y una vía de salida de la solución. |
| Acción | ¿Qué puede hacer el sistema por su cuenta? | Solo acciones predefinidas, sin acceso a toda la cuenta |
| Verificación | ¿Cómo sabes que el resultado se puede aceptar? | Para dos opciones mide tiempo hasta el resultado, precisión, coste por operación, exportación de datos y sustitución del proveedor. |
| Fallo | ¿Adónde va un caso poco claro? | Quédate con la opción que el equipo pueda soportar, aunque sea menos impresionante en una demo. |
Qué debe cambiar después de la configuración
Comparas opciones por coste total de propiedad y las validas en un solo piloto.
Por qué “lo construiremos nosotros” casi siempre se subestima
Construir un sistema propio para controlar una tarea commodity.
Comprar una herramienta sin API ni exportación de datos.
No contar el soporte ni el tiempo del equipo interno.
Comparar funciones de demo en lugar de una operación real.
Cuándo la elección ya afecta a la arquitectura del negocio
Incorpora a un especialista cuando la elección toca la arquitectura, varios sistemas, datos personales o un TCO plurianual.
Qué revisar en el contrato y en el código
¿Cuándo encaja lo híbrido?
Cuando la parte base se puede comprar y las reglas, datos o integraciones únicas se quedan contigo.
¿Deberías incluir el salario del responsable?
Sí. El TCO incluye horas del equipo, de contratistas y del responsable interno.
¿Cuándo deberías comprar listo?
Cuando la tarea es típica, importan la velocidad y las integraciones, y los requisitos no crean un diferenciador fuerte.
¿Cuándo deberías construir tú mismo?
Cuando el proceso es único, los datos no pueden salir, se requiere lógica especial o el coste de licencia crece más rápido que el desarrollo.
