Desindustrialización silenciosa: el ecosistema de sucesión que falta
Bernhard Liebl
7 min. de lectura Alemania pierde cada año tejido económico sin que nadie lo contabilice. Unas 114.000 ...
Leer artículo
7 min de lectura
La decisión de construir o comprar más cara es la que nadie ha tomado conscientemente. En la mayoría de las organizaciones se toma de forma implícita: un equipo construye porque puede construir, o compra porque un proveedor acaba de hacer una presentación. El cálculo riguroso pertenece antes que la diapositiva de estrategia. Quien trata construir, comprar y asociarse como tres opciones calculables decide más rápido y rectifica menos.
Lo más importante en resumen
- El principio supera a la intuición. Compra lo habitual, construye lo singular. Las funciones estándar como el pago o la autenticación deben adquirirse; la capacidad de desarrollo interna debe reservarse para el 10 o 20 por ciento que hace al negocio diferenciable.
- La asociación es la tercera opción subestimada. Entre el desarrollo propio y la licencia de terceros existe el co-desarrollo o el servicio gestionado. Reduce el riesgo cuando falta competencia interna y mantiene la diferenciación más cerca de la propia organización que un producto estándar puro.
- La licencia es solo la punta del iceberg. La integración, la formación y el mantenimiento desplazan significativamente el coste total a lo largo de cinco años. Una decisión que solo compara la tarifa de licencia con las horas de desarrollo está calculando al margen de la realidad.
Relacionado:El modelo operativo que sobrevive a la reorganización / Managed Security Services: el CISO no responde en solitario
¿Qué es la decisión de construir o comprar? Construir o comprar describe la elección de desarrollar internamente una capacidad de software necesaria, adquirirla ya lista o obtenerla a través de un socio. Afecta simultáneamente a los costes, el ritmo, el control y la dependencia. La decisión no es una cuestión puramente de TI, sino que determina dónde concentra una empresa su escasa capacidad de desarrollo.
Por qué la pregunta llega demasiado tarde a la mesa
En la práctica, la cuestión de construir o comprar rara vez aparece al principio. Surge cuando un proyecto ya está en marcha, un equipo ya tiene preferencias o un proveedor ha conseguido una reunión. Con ello, la decisión ya está tomada de facto antes de que nadie haya hecho los cálculos. El verdadero trabajo comienza antes: en la pregunta de si la capacidad en cuestión hace realmente diferenciable al negocio.
Esta clasificación exige una autocrítica honesta. Un procesador de pagos, un servicio de identidad o un sistema de contenidos son problemas resueltos. Aquí, el desarrollo interno compite contra proveedores que llevan años sin hacer otra cosa. Quien aun así construye por cuenta propia financia un producto estándar de segunda categoría y compromete capacidad que ningún competidor llegará a ver jamás.
Tres caminos, un principio
El principio rector es: compra lo habitual, construye lo singular. Los servicios best-in-class asumen las funciones estándar, integrados mediante interfaces. La capacidad de desarrollo interno se concentra, como heurística general, en el 10 o 20 por ciento que realmente diferencia el negocio: un motor de precios, una lógica logística o un algoritmo de matching propio.
Entre construir y comprar existe un tercer camino que a menudo se pasa por alto. Un modelo de colaboración -ya sea co-desarrollo o servicio gestionado- entra en juego cuando la capacidad es diferenciadora pero la empresa aún no dispone de la competencia necesaria. Distribuye el riesgo de implementación y mantiene el control técnico más cerca de la organización, aunque genera una nueva dependencia y plantea la pregunta de quién asume la responsabilidad final. Precisamente esta variante gestionada es la que eligen muchas organizaciones en materia de seguridad, donde la gestión propia resulta poco habitual y el estándar puro sería demasiado rígido.
Quien construye lo habitual por sí mismo paga su diferenciación con las horas que luego le faltan.
La regla empírica que ordena la matriz
Comprar lo estándar, construir la diferenciación, cubrir las brechas con socios. Asignar cada capacidad a una de estas tres categorías aclara la decisión más rápido que cualquier tabla de TCO. Los cálculos vienen después y, por lo general, confirman lo que la clasificación ya había sugerido.
Lo que realmente cuestan las opciones
Las cifras visibles engañan en ambas direcciones. En la opción de compra, la oferta presenta una tarifa de licencia manejable, pero la integración, la adaptación, la formación y la migración añaden costes considerables con el paso de los años. En la opción de desarrollo propio, el primer sprint parece económico, hasta que el mantenimiento, las actualizaciones de seguridad, la evolución de funcionalidades y la retención de desarrolladores escasos dan la vuelta a la balanza. El modelo de colaboración solo desplaza estas partidas, no las elimina: la gestión del proveedor, las cláusulas contractuales de salida, los niveles de servicio, la responsabilidad compartida y la transferencia de conocimiento a la organización propia forman parte del mismo cálculo. Una decisión sólida proyecta las tres opciones a cinco años, incluidos los costes que nunca aparecen en la oferta.
La partida más cara no figura en ninguna tabla: el coste de oportunidad. Cada hora de desarrollo dedicada a un problema estándar es una hora que le falta a la capacidad diferenciadora. Esta diferenciación perdida pesa más a largo plazo que cualquier tarifa de licencia. Quien lo incorpora al cálculo valora automáticamente con más rigor el desarrollo propio en temáticas de commodity.
El factor DACH: recursos y dependencia tecnológica
En la mediana empresa alemana, la ecuación se inclina a menudo por la cuestión del personal. Quien construye necesita un equipo que mantenga la solución durante años, no solo que la desarrolle. En un mercado laboral prácticamente agotado, ese equipo resulta más caro e incierto que cualquier licencia. En el Mittelstand, estos costes de retención suelen favorecer la compra o la colaboración, ya que asegurar un equipo de desarrollo permanente es más difícil que renovar una licencia.
En las grandes corporaciones, en cambio, predomina la preocupación por el lock-in. Un producto estándar profundamente integrado crea vínculos a través de modelos de datos y procesos, y el cambio se encarece con cada año que pasa. Aquí merece la pena complementar la lógica de diferenciación con una lógica de soberanía: mantener las interfaces abiertas, asegurar la titularidad de los datos y, ante componentes críticos, explorar la opción de colaboración antes de que un único proveedor dicte las condiciones. Quien distribuye con claridad los derechos de decisión actúa con mayor rapidez, como demuestra el modelo operativo.
La matriz antes de que exista la diapositiva
El primer paso es una lista de las capacidades en cuestión, cada una con dos valoraciones honestas: en qué medida diferencia el negocio y cuán madura es la competencia propia al respecto. De ahí se desprende casi por sí sola la asignación. Escasa diferenciación conduce a Buy, alta diferenciación con competencia madura a Build, alta diferenciación sin competencia a Partner. Solo para los candidatos así preseleccionados merece la pena el cálculo a cinco años, incluyendo integración, mantenimiento y costes de oportunidad. Este orden invierte la práctica habitual: primero la clasificación estratégica, luego los números, y por último la selección de proveedores. La diapositiva de estrategia aparece al final del proceso, no al principio.
Preguntas frecuentes
¿Cuándo merece la pena el desarrollo propio frente a la compra?
Cuando la capacidad diferencia el negocio de forma perceptible y la competencia propia es lo suficientemente madura como para sostenerla durante años. Para funciones estándar como pagos, autenticación o un sistema de contenidos, esto rara vez se cumple. En esos casos, el desarrollo interno compite contra proveedores especializados y consume capacidad que le falta a la diferenciación.
¿Qué aporta la opción Partner frente a Build y Buy?
Encaja cuando una capacidad es diferenciadora pero la competencia interna no existe. El co-desarrollo o un servicio gestionado trasladan el riesgo de ejecución al exterior y mantienen el dominio técnico dentro de la empresa. Así es posible construir una solución diferenciadora sin tener que contratar un equipo completo desde cero.
¿Por qué no basta la comparación de licencias para tomar la decisión?
Porque la licencia es solo la punta visible del iceberg. Integración, adaptación, formación y migración añaden importes considerables a lo largo de cinco años, y en el desarrollo propio se suman el mantenimiento y los costes de oportunidad. Un cálculo sólido contempla el coste total durante todo el ciclo de vida, desde el primer año hasta la sustitución.
¿Cómo se inicia la decisión de forma ordenada?
Con una lista de las capacidades en cuestión, cada una valorada según su grado de diferenciación y la competencia propia. De ahí surge la preselección en Buy, Build o Partner. Solo entonces viene el cálculo de costes a cinco años para los candidatos y, por último, la selección de proveedores.
Antes en Digital Chiefs
Digital ChiefsEl modelo operativo que sobrevive a la reorganizaciónDigital ChiefsPuerta de Oro: Apple convierte la inteligencia artificial en un fosoDigital ChiefsEl mercado mundial se fragmenta: la fortaleza de Europa se convierte en trampaMás de la red MBF Media
cloudmagazinCloud Repatriation: cuándo compensa la repatriación mybusinessfutureCloud u On-Prem: lo que cuenta desde el punto de vista económico securitytodaySecurity Awareness: la tasa de clics mide lo equivocadoFuente de la imagen: generada por IA (junio de 2026), certificado C2PA integrado en la imagen