7 min. de lectura<\/p>\n
La decisi\u00f3n de construir o comprar m\u00e1s cara es la que nadie ha tomado conscientemente. En la mayor\u00eda de las organizaciones se toma de forma impl\u00edcita: un equipo construye porque puede construir, o compra porque un proveedor acaba de hacer una presentaci\u00f3n. El c\u00e1lculo riguroso pertenece antes que la diapositiva de estrategia. Quien trata construir, comprar y asociarse como tres opciones calculables decide m\u00e1s r\u00e1pido y rectifica menos.<\/strong><\/p>\n Lo m\u00e1s importante en resumen<\/p>\n Relacionado:<\/span>El modelo operativo que sobrevive a la reorganizaci\u00f3n<\/a> \/<\/span> Managed Security Services: el CISO no responde en solitario<\/a><\/p>\n \u00bfQu\u00e9 es la decisi\u00f3n de construir o comprar?<\/strong> Construir o comprar describe la elecci\u00f3n de desarrollar internamente una capacidad de software necesaria, adquirirla ya lista o obtenerla a trav\u00e9s de un socio. Afecta simult\u00e1neamente a los costes, el ritmo, el control y la dependencia. La decisi\u00f3n no es una cuesti\u00f3n puramente de TI, sino que determina d\u00f3nde concentra una empresa su escasa capacidad de desarrollo.<\/p>\n En la pr\u00e1ctica, la cuesti\u00f3n de construir o comprar rara vez aparece al principio. Surge cuando un proyecto ya est\u00e1 en marcha, un equipo ya tiene preferencias o un proveedor ha conseguido una reuni\u00f3n. Con ello, la decisi\u00f3n ya est\u00e1 tomada de facto antes de que nadie haya hecho los c\u00e1lculos. El verdadero trabajo comienza antes: en la pregunta de si la capacidad en cuesti\u00f3n hace realmente diferenciable al negocio.<\/p>\n Esta clasificaci\u00f3n exige una autocr\u00edtica honesta. Un procesador de pagos, un servicio de identidad o un sistema de contenidos son problemas resueltos. Aqu\u00ed, el desarrollo interno compite contra proveedores que llevan a\u00f1os sin hacer otra cosa. Quien aun as\u00ed construye por cuenta propia financia un producto est\u00e1ndar de segunda categor\u00eda y compromete capacidad que ning\u00fan competidor llegar\u00e1 a ver jam\u00e1s.<\/p>\n El principio rector es: compra lo habitual, construye lo singular. Los servicios best-in-class asumen las funciones est\u00e1ndar, integrados mediante interfaces. La capacidad de desarrollo interno se concentra, como heur\u00edstica general, en el 10 o 20 por ciento que realmente diferencia el negocio: un motor de precios, una l\u00f3gica log\u00edstica o un algoritmo de matching propio.<\/p>\n Entre construir y comprar existe un tercer camino que a menudo se pasa por alto. Un modelo de colaboraci\u00f3n -ya sea co-desarrollo o servicio gestionado- entra en juego cuando la capacidad es diferenciadora pero la empresa a\u00fan no dispone de la competencia necesaria. Distribuye el riesgo de implementaci\u00f3n y mantiene el control t\u00e9cnico m\u00e1s cerca de la organizaci\u00f3n, aunque genera una nueva dependencia y plantea la pregunta de qui\u00e9n asume la responsabilidad final. Precisamente esta variante gestionada<\/a> es la que eligen muchas organizaciones en materia de seguridad, donde la gesti\u00f3n propia resulta poco habitual y el est\u00e1ndar puro ser\u00eda demasiado r\u00edgido.<\/p>\n Quien construye lo habitual por s\u00ed mismo paga su diferenciaci\u00f3n con las horas que luego le faltan.<\/p><\/blockquote>\n La regla emp\u00edrica que ordena la matriz<\/p>\n Comprar lo est\u00e1ndar, construir la diferenciaci\u00f3n, cubrir las brechas con socios.<\/strong> Asignar cada capacidad a una de estas tres categor\u00edas aclara la decisi\u00f3n m\u00e1s r\u00e1pido que cualquier tabla de TCO. Los c\u00e1lculos vienen despu\u00e9s y, por lo general, confirman lo que la clasificaci\u00f3n ya hab\u00eda sugerido.<\/p>\n<\/div>\n Las cifras visibles enga\u00f1an en ambas direcciones. En la opci\u00f3n de compra, la oferta presenta una tarifa de licencia manejable, pero la integraci\u00f3n, la adaptaci\u00f3n, la formaci\u00f3n y la migraci\u00f3n a\u00f1aden costes considerables con el paso de los a\u00f1os. En la opci\u00f3n de desarrollo propio, el primer sprint parece econ\u00f3mico, hasta que el mantenimiento, las actualizaciones de seguridad, la evoluci\u00f3n de funcionalidades y la retenci\u00f3n de desarrolladores escasos dan la vuelta a la balanza. El modelo de colaboraci\u00f3n solo desplaza estas partidas, no las elimina: la gesti\u00f3n del proveedor, las cl\u00e1usulas contractuales de salida, los niveles de servicio, la responsabilidad compartida y la transferencia de conocimiento a la organizaci\u00f3n propia forman parte del mismo c\u00e1lculo. Una decisi\u00f3n s\u00f3lida proyecta las tres opciones a cinco a\u00f1os, incluidos los costes que nunca aparecen en la oferta.<\/p>\n La partida m\u00e1s cara no figura en ninguna tabla: el coste de oportunidad. Cada hora de desarrollo dedicada a un problema est\u00e1ndar es una hora que le falta a la capacidad diferenciadora. Esta diferenciaci\u00f3n perdida pesa m\u00e1s a largo plazo que cualquier tarifa de licencia. Quien lo incorpora al c\u00e1lculo valora autom\u00e1ticamente con m\u00e1s rigor el desarrollo propio en tem\u00e1ticas de commodity.<\/p>\n En la mediana empresa alemana, la ecuaci\u00f3n se inclina a menudo por la cuesti\u00f3n del personal. Quien construye necesita un equipo que mantenga la soluci\u00f3n durante a\u00f1os, no solo que la desarrolle. En un mercado laboral pr\u00e1cticamente agotado, ese equipo resulta m\u00e1s caro e incierto que cualquier licencia. En el Mittelstand, estos costes de retenci\u00f3n suelen favorecer la compra o la colaboraci\u00f3n, ya que asegurar un equipo de desarrollo permanente es m\u00e1s dif\u00edcil que renovar una licencia.<\/p>\n En las grandes corporaciones, en cambio, predomina la preocupaci\u00f3n por el lock-in. Un producto est\u00e1ndar profundamente integrado crea v\u00ednculos a trav\u00e9s de modelos de datos y procesos, y el cambio se encarece con cada a\u00f1o que pasa. Aqu\u00ed merece la pena complementar la l\u00f3gica de diferenciaci\u00f3n con una l\u00f3gica de soberan\u00eda: mantener las interfaces abiertas, asegurar la titularidad de los datos y, ante componentes cr\u00edticos, explorar la opci\u00f3n de colaboraci\u00f3n antes de que un \u00fanico proveedor dicte las condiciones. Quien distribuye con claridad los derechos de decisi\u00f3n act\u00faa con mayor rapidez, como demuestra el modelo operativo<\/a>.<\/p>\n El primer paso es una lista de las capacidades en cuesti\u00f3n, cada una con dos valoraciones honestas: en qu\u00e9 medida diferencia el negocio y cu\u00e1n madura es la competencia propia al respecto. De ah\u00ed se desprende casi por s\u00ed sola la asignaci\u00f3n. Escasa diferenciaci\u00f3n conduce a Buy, alta diferenciaci\u00f3n con competencia madura a Build, alta diferenciaci\u00f3n sin competencia a Partner. Solo para los candidatos as\u00ed preseleccionados merece la pena el c\u00e1lculo a cinco a\u00f1os, incluyendo integraci\u00f3n, mantenimiento y costes de oportunidad. Este orden invierte la pr\u00e1ctica habitual: primero la clasificaci\u00f3n estrat\u00e9gica, luego los n\u00fameros, y por \u00faltimo la selecci\u00f3n de proveedores. La diapositiva de estrategia aparece al final del proceso, no al principio.<\/p>\n Cuando la capacidad diferencia el negocio de forma perceptible y la competencia propia es lo suficientemente madura como para sostenerla durante a\u00f1os. Para funciones est\u00e1ndar como pagos, autenticaci\u00f3n 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\u00f3n.<\/p>\n<\/details>\n Encaja cuando una capacidad es diferenciadora pero la competencia interna no existe. El co-desarrollo o un servicio gestionado trasladan el riesgo de ejecuci\u00f3n al exterior y mantienen el dominio t\u00e9cnico dentro de la empresa. As\u00ed es posible construir una soluci\u00f3n diferenciadora sin tener que contratar un equipo completo desde cero.<\/p>\n<\/details>\n Porque la licencia es solo la punta visible del iceberg. Integraci\u00f3n, adaptaci\u00f3n, formaci\u00f3n y migraci\u00f3n a\u00f1aden importes considerables a lo largo de cinco a\u00f1os, y en el desarrollo propio se suman el mantenimiento y los costes de oportunidad. Un c\u00e1lculo s\u00f3lido contempla el coste total durante todo el ciclo de vida, desde el primer a\u00f1o hasta la sustituci\u00f3n.<\/p>\n<\/details>\n Con una lista de las capacidades en cuesti\u00f3n, cada una valorada seg\u00fan su grado de diferenciaci\u00f3n y la competencia propia. De ah\u00ed surge la preselecci\u00f3n en Buy, Build o Partner. Solo entonces viene el c\u00e1lculo de costes a cinco a\u00f1os para los candidatos y, por \u00faltimo, la selecci\u00f3n de proveedores.<\/p>\n<\/details>\n M\u00e1s de la red MBF Media<\/p>\n\n
Por qu\u00e9 la pregunta llega demasiado tarde a la mesa<\/h2>\n
Tres caminos, un principio<\/h2>\n
Lo que realmente cuestan las opciones<\/h2>\n
El factor DACH: recursos y dependencia tecnol\u00f3gica<\/h2>\n
La matriz antes de que exista la diapositiva<\/h2>\n
Preguntas frecuentes<\/h2>\n
\u00bfCu\u00e1ndo merece la pena el desarrollo propio frente a la compra?<\/strong><\/summary>\n
\u00bfQu\u00e9 aporta la opci\u00f3n Partner frente a Build y Buy?<\/strong><\/summary>\n
\u00bfPor qu\u00e9 no basta la comparaci\u00f3n de licencias para tomar la decisi\u00f3n?<\/strong><\/summary>\n
\u00bfC\u00f3mo se inicia la decisi\u00f3n de forma ordenada?<\/strong><\/summary>\n