Automatización: ¿construir internamente, comprar software o contratar consultores? La decisión Make-vs-Buy

La mayoría de los proyectos de automatización en la pequeña y mediana empresa no fracasan por la tecnología. Fracasan por una decisión tomada demasiado pronto y con las cifras equivocadas: ¿construir usted mismo, comprar software ya hecho o contratar a un consultor?

Las tres vías tienen su momento. Pero la pregunta «Make or Buy» solo puede responderse de forma seria cuando dos cosas están claras: usted sabe qué proceso va a tocar, y sabe cuánto le cuesta ese proceso en euros. Exactamente esa es la tarea de la fase O en la metodología Flowrefy. Este artículo ofrece la lógica de decisión detrás. No es una comparación herramienta contra herramienta, sino los umbrales en los que construir, comprar y encargar realmente se separan.

Primero el orden, luego la decisión

La metodología Flowrefy es un bucle con cuatro pasos por proceso: Find (encontrar el cuello de botella más caro), Lay bare (cuantificarlo en euros), Optimize (ordenar, luego elegir exactamente una palanca) y Wire & Watch (implementar y volver a medir).

Make-vs-Buy es una cuestión pura de la fase O. Y en la fase O rige un principio de hierro: primero ordenar, luego comprar software. Quien invierte el orden, automatiza su caos. Solo que más rápido y más caro.

Suena obvio, pero no lo es. El flujo típico en la mediana empresa es así: alguien ve una herramienta en una feria, la comercialización convence, el presupuesto existe. Seis semanas después hay un software que cubre un proceso que nadie había definido con claridad. El resultado es una paralización costosa con interfaz brillante.

Antes de que usted compre o construya algo, deben cumplirse dos requisitos:

1. El cuello de botella está definido. Exactamente un proceso, no cinco. Ese es el principio «un cuello de botella por ciclo».
2. El cuello de botella está cuantificado en euros. Usted conoce los costes anuales del estado actual. Si no, no puede justificar ninguna inversión. Ese es el principio: Si no puede decirlo en euros, no lo toque.

Si cualquiera de los dos puntos está abierto, cualquier discusión Make-vs-Buy es prematura. Entonces debe volver a las fases F y L. Cómo cuantificar el cuello de botella lo muestra el FLOW-Prozesskosten-Analyzer.

Las tres vías lado a lado, con honestidad

Antes de calcular, tres definiciones frías: qué significan realmente las opciones, no cómo se venden.

Construir usted mismo (Make)

Usted desarrolla la automatización con medios propios: plataformas No-Code/Low-Code, scripts propios, desarrolladores internos. Usted posee totalmente la lógica y puede ajustar en cualquier momento. El precio: usted asume mantenimiento, actualizaciones y conocimiento, y por tanto un riesgo de persona. Si se va quien lo construyó, a menudo se va también el entendimiento.

Comprar software listo (Buy)

Usted contrata una solución estándar que cubre su proceso en gran medida. La puesta en marcha es rápida, el proveedor mantiene y desarrolla, el soporte está disponible. El precio: usted se adapta al software, no al revés. En casos especiales se topa con límites, y las licencias recurrentes escalan con usuarios o volumen, a veces de forma incómoda.

Encargar a un consultor

El consultor no es una cuarta vía, sino un acelerador de las otras dos, y por lo general es un coste único. Tiene sentido si en la empresa falta el conocimiento para cuantificar el cuello de botella con rigor, o si una migración es excepcionalmente compleja. Se vuelve peligroso cuando al final queda una caja negra que nadie puede mantener internamente. Entonces solo habrá cambiado un problema de volumen por un problema de dependencia.

Las tres magnitudes que realmente deciden

Olvídese del instinto y del encanto del vendedor. La decisión Make-vs-Buy depende de tres magnitudes medibles.

1. Grado de estandarización

¿Cuánto es de individual su proceso?

• Muy estandarizado (nómina, envío de boletines, ticketing, aprobación de facturas según esquema): miles de empresas tienen exactamente el mismo problema. Aquí hay software maduro por poco dinero. Comprar. Construir sería reinventar la rueda.
• Parcialmente específico (núcleo estándar, pero tres reglas peculiares): herramienta estándar como base, puentecillas pequeñas construir internamente. Forma mixta.
• Muy individual o ventaja competitiva (su proceso es exactamente lo que le diferencia en el mercado): el software estándar le obliga a una lógica ajena. Aquí el desarrollo propio puede ser claramente superior.

Regla práctica: Lo que es estándar, se compra. Lo que le hace único, se construye o se manda construir y se asume.

2. Volumen

¿Cuántas veces se ejecuta el proceso?

El volumen decide si valen la pena los costes fijos. Un desarrollo propio tiene costes iniciales altos y costes marginales bajos. Una licencia comprada tiene costes iniciales bajos, pero costes continuos que suben con usuarios o transacciones.

• Volumen bajo, esporádico: el desarrollo propio rara vez compensa. La inversión inicial nunca se amortiza. Comprar o dejarlo como está.
• Volumen alto y constante: aquí compensa el desarrollo propio. Los costes fijos se reparten entre muchas ejecuciones, mientras que las cuotas de licencia recurrentes dolerían a lo largo de los años.

3. TCO a tres años

Esta es la magnitud en la que muchos fallan: comparan precio de licencia con precio de licencia y pasan por alto los costes reales. Total Cost of Ownership significa: todo lo que ocurre en tres años.

Al comprar debe calcular:

• costes de licencia y puesta en marcha
• cuotas recurrentes multiplicadas por 36 meses (con el crecimiento de volumen esperado)
• migración de datos y configuración
• formación del personal
• esfuerzo de soporte interno (alguien debe mantener la herramienta)

Al construir debe calcular:

• tiempo de desarrollo único (horas por tarifa interna, estimada con honestidad)
• mantenimiento anual (regla: 15 a 25 por ciento del coste de construcción por año)
• hosting e infraestructura
• riesgo de persona (¿cuánto cuesta si se va el constructor?)

Solo estas dos sumas son comparables. Muy a menudo la decisión cambia cuando se incluyen mantenimiento y formación. En ambos sentidos.

Y a veces la decisión descarta ambas opciones. En la análisis modelo AN-2026-03 (construido, no recogido en un cliente) había una oferta de 18.000 euros para una automatización de flujo de trabajo sobre la mesa. El proceso se calculó antes de firmar:

[
  { "label": "Einführungskosten (Buy)", "value": "18.000", "unit": "€", "tone": "critical" },
  { "label": "Ersparnis an Arbeitszeit", "value": "4.000", "unit": "€/Jahr" },
  { "label": "Amortisation", "value": "> 4", "unit": "Jahre", "tone": "critical" },
  { "label": "Durchlaufzeit", "value": "-7", "unit": "%", "note": "12,8 → 11,9 Tage" }
]

La tercera respuesta al dilema Make-vs-Buy a veces es: ninguno de los dos. En este caso el cuello de botella estaba en el proveedor, es decir fuera de la empresa. Ni lo comprado ni lo construido alcanzan allí.

La lógica de decisión en cuatro preguntas

Cuando el cuello de botella y su valor en euros están claros, responda estas cuatro preguntas en orden.

Pregunta 1: ¿Es un proceso estándar? Sí y muy estandarizado → fuerte tendencia a Comprar. Avance a la pregunta 3. No, muy individual → avance a la pregunta 2.

Pregunta 2: ¿Tenemos internamente la capacidad de construirlo y mantenerlo durante tres años? Sí → Construir es una opción real. Avance a la pregunta 3. No → ajuste una herramienta estándar al proceso, o contrate a un consultor para la construcción única y la transferencia de conocimiento interno. Nunca acepte una caja negra sin entrega.

Pregunta 3: ¿Cómo queda el TCO a 3 años en la comparación directa? Calcule ambas sumas. Si están cerca (diferencia inferior a alrededor del 20 por ciento), casi siempre gana Comprar, por menor riesgo y arranque más rápido.

Pregunta 4: ¿Qué ocurre si la persona responsable se va? Si la solución depende de una persona, aplique un recargo de riesgo a la opción Build. O exija al consultor documentación y transferencia como parte del contrato.

Un ejemplo de cálculo ilustrativo

Para que la lógica sea tangible, un escenario de ejemplo completo. Es ficticio y sirve para ilustrar, no describe un cliente real.

Una empresa de ingeniería con 60 empleados identificó en la fase F la elaboración de ofertas como el cuello de botella más caro. En la fase L se cuantificaron los costes: tres personas elaboran ofertas mayormente de forma manual, coste anual aproximadamente 40.000 euros en tiempo atado.

En la fase O se ordenó primero: plantillas unificadas, lógica de precios documentada. Solo entonces se planteó Make-vs-Buy:

• Comprar (software CPQ estándar, herramienta de configuración automática de ofertas): alrededor de 9.000 euros de licencia por año, más puesta en marcha y formación. TCO a 3 años aprox. 35.000 euros. Problema: la lógica de precios especial encaja solo en 70 por ciento.
• Construir (configurador No-Code interno): coste único alrededor de 18.000 euros, más unos 4.000 euros de mantenimiento por año. TCO a 3 años aprox. 30.000 euros. Ventaja: la lógica de precios encaja al 100 por ciento. Riesgo: el conocimiento depende de una persona.

Las sumas están cerca. Decanta la alta individualización de la lógica de precios, que pesa contra una herramienta estándar. Decisión en este escenario: construir, pero con entrega documentada para mitigar el riesgo de persona. Qué variante gana en su caso concreto depende completamente de sus cifras. Para eso existe la calculadora.

Exactamente una palanca, luego medir

Sea cual sea su decisión: implemente por ciclo exactamente una palanca. No compre una herramienta, cambie otro proceso y escriba un script a la vez. Quien cambia tres cosas simultáneamente y al final ve una mejora, nunca sabe qué medida funcionó y cuál solo quemó dinero.

En la fase W (Wire & Watch) vuelva a medir el mismo valor en euros que determinó en la fase L. Así obtiene un verdadero antes/después en euros en lugar de una afirmación. Eso es precisamente lo que distingue la metodología Flowrefy de la habitual historia de «hemos automatizado algo».

Si desea profundizar en la selección concreta de plataformas No-Code una vez definida la dirección Make-vs-Buy, le ayuda la visión general Beste No-Code-Tools. Y quien quiera comprobar si un paso es incluso automatizable antes de comprar o construir, encuentra en el artículo Prozesse automatisieren: Beispiele puntos de partida prácticos.

La lista de verificación breve antes de cada decisión

• Cuello de botella definido: exactamente uno, no cinco
• Costes actuales en euros por año cuantificados
• Proceso ordenado antes de automatizar, no automatizar el caos
• Grado de estandarización evaluado con honestidad
• Volumen conocido (¿con qué frecuencia se ejecuta el proceso?)
• TCO a 3 años calculado para ambas vías, incluyendo mantenimiento y formación
• Riesgo de persona valorado y, si procede, cubierto con recargo o entrega
• Para consultores: documentación y entrega acordadas por contrato

Solo cuando todas las casillas estén marcadas, su decisión será algo más que instinto.

Su próximo paso: el diagnóstico FLOW gratuito

La pregunta Make-vs-Buy solo es tan buena como las cifras sobre las que se apoya. Si ya conoce el cuello de botella, la decisión es un ejercicio de cálculo: grado de estandarización, volumen y TCO a tres años frente a frente. Lo que hoy le cuesta el proceso le calcula el Prozesskosten-Rechner. Esa es la cifra contra la que comparar ambas vías.

Si aún no sabe cuál es el proceso más caro o cuánto cuesta, empiece un paso antes. El diagnóstico FLOW gratuito le ayuda a encontrar el único cuello de botella más caro y a traducirlo a euros antes de que compre o construya nada. Primero medir, luego afinar.