Comprar vs. construir: ¿Qué estrategia es mejor para tu empresa?

Dentro del decálogo de preguntas frecuentes a las que deben enfrentarse fabricantes de tecnología y empresas de servicios, existe una cuya respuesta no ha cambiado y debería enseñarse en la primera clase de ventas. ¿Por qué deberíamos adquirir la plataforma de un tercero si esto lo podemos hacer nosotros? Esta pregunta, usualmente formulada por el área de tecnología, se conoce como la “buy vs. build question” y suele ocupar una porción significativa de los ciclos de ventas de nuevas tecnologías y soluciones digitales.

Resulta fácil llegar a la conclusión de que no existe necesariamente una única respuesta correcta; en el extremo de construir todo, nos encontraríamos con áreas de IT que desarrollan su propio lenguaje de programación, almacenan toda su data en máquinas inventadas por ellos, en sistemas on premise. Tomando prestada la idea de red de información que propone Harari, básicamente nos encontramos en el escenario de una notaría donde todos los archivos tienen una copia manual en un archivador cuya lógica solo entienden los burócratas que participan a diario en su construcción, alejados de cualquier avance en la industria.

En el otro extremo, nos encontraríamos con decenas de tecnologías de propósito único con poca comunicación entre ellas. Una torre de Babel que requiere constantemente de nuevas tecnologías que conecten los silos de información, convirtiéndose en una capa adicional de la cebolla que se hace más grande en la medida que aumentan las necesidades de compartir información. Asimismo, crece la frustración de tener que contratar plataformas complejas para problemas aparentemente sencillos. Esta es la semilla de las frases más comunes de este microcosmos: “Estoy matando moscas con escopeta” y “tenemos un Ferrari parqueado”.

Entendiendo entonces que Buy vs. Build no es una pregunta menor, corresponde pensar en cuál debería ser la lógica que ayude a inclinar la balanza hacia un lado o el otro. En la práctica, nos hacemos y le hacemos a nuestros clientes preguntas aparentemente sencillas que deberían ayudar a definir el camino:

¿Plataforma o práctica? cómo elegir la mejor solución

Mi más grande mentor en ventas de tecnología decía que se puede hacer excelente CRM en Excel y pésimo CRM en las tecnologías más avanzadas, para ilustrar cómo los problemas estructurales no se solucionan invirtiendo solo en tecnología, sino en procesos, estrategia y equipo. Dicho esto, es común ver equipos que han desarrollado una práctica con los años, ya sea de analítica de datos, centralización de información del consumidor o automatización de campañas de comunicación masiva con las uñas. Cuando la solución a los problemas de agilidad y escalabilidad de procesos sencillos se convierte en contratar más personas, ahí sí se están matando moscas con escopeta.

Core Business: alinear la inversión con tu estrategia

¿Cuál es la misión y la visión de la compañía? ¿Cuáles son los KPIs del próximo trienio? Lo normal es encontrar variaciones sobre las mismas respuestas: “queremos vender más”, “queremos vender más barato”, “queremos que las relaciones con nuestros clientes sean a más largo plazo”. En ese sentido, los esfuerzos de la compañía deberían centrarse justo en esas iniciativas y los procesos que las soportan. Eso de ninguna manera quiere decir que las áreas de desarrollo no estén en capacidad de grandes proyectos, pero hay que considerar si esas inversiones responden al negocio central de la empresa y si serán escalables. Hay casos en que pueden convertirse en un spin-off, donde se abre una nueva fuente de ingreso. Otros, donde desafortunadamente no existe un mercado tan específico o la competencia es tan fuerte en el sector que, por más apropiada que sea la solución, no hay voluntad de colaboración con posibles clientes.

El foco de negocio tiene otro punto importante: tener la claridad de que los esfuerzos de la compañía justificarán inversiones en mantener y mejorar la plataforma. Para ponerlo más sencillo con un ejemplo: los bancos han enfocado su propuesta de valor en la seguridad del dinero y en el ofrecimiento de portafolios que permitan darles uso a esos ahorros. Podemos contar con que seguirán invirtiendo en ese sentido. Esa opción suena más atractiva que guardar la nómina debajo del colchón, por más que invirtamos con frecuencia esos ahorros en reforzar el colchón. (Paradójicamente, el sector financiero parece ser el más propenso a optar por desarrollos in-house).

Sistemas legacy: el reto de decidir entre modernizar o construir desde cero

Muchos de los desarrollos de las compañías se concentran en poder mantener vigentes sistemas legado, usualmente on premise, que albergan los procesos más nucleares de la compañía. Algo así como su cerebro reptiliano, que sencillamente no puede fallar porque se vendría abajo el resto del sistema. Esto puede llegar al límite en que es más sencillo iniciar de nuevo el montaje de estructuras que hacer una migración a sistemas más modernos o eficientes. Esos desarrollos a la medida para sistemas legado pueden estar limitados por las capacidades de las plataformas antiguas, tanto como fuente, como destino de datos:

Dificultad para APIficar, tiempos de procesamiento largos, lenguajes de programación en desuso… hacen que las limitaciones legacy deriven en limitaciones actualizadas. Corresponde evaluar si el proyecto y la plataforma pueden ser pequeños pasos en búsqueda de apoyar una transformación de base o en federalizar la dependencia en un sistema específico, o si, por el contrario, está condenado a no poder desplegarse como un proyecto verdaderamente innovador.

Claves para reducir riesgos en tecnología

Esta pregunta es probablemente la más antipática de hacer: ¿está preparada la compañía para sobrevivir a la ausencia del Product Owner del sistema desarrollado localmente? Esto abre la conversación sobre recursos de aprendizaje, foros de ayuda en comunidad, ecosistema de partners y cantidad de profesionales que conozcan la plataforma en cuestión. Dudas que usualmente no aparecen en un RFP y respuestas que suelen ser protagonistas en el momento en que se decide migrar de una plataforma a otra.

Usualmente, estas preguntas vienen complementadas, cuando se abre la discusión, con otros elementos a tener en cuenta por los tomadores de decisiones. Las respuestas suelen ser difíciles de tener ex ante, pero sirven para dar luces sobre lo que puede venir a futuro:

1. Costo total de propiedad (TCO): no solo el precio inicial, sino costos de mantenimiento, soporte, capacitación y escalabilidad.
2. Velocidad de implementación: una plataforma comprada puede estar lista en semanas, mientras que un desarrollo propio puede tardar años.
3. Riesgo tecnológico y obsolescencia: la tecnología y el mercado cambian más rápido que los ciclos internos de desarrollo.
4. Flexibilidad y personalización: plataformas de terceros pueden ser más rígidas, pero un desarrollo interno puede adaptarse 100% – con costo.
5. Impacto en la innovación: comprar puede liberar recursos para innovar en otras áreas clave.

En definitiva, la disyuntiva entre construir o comprar no debería resolverse desde el orgullo tecnológico ni desde la presión comercial, sino desde una visión estratégica clara: ¿qué decisión nos acerca más rápido y de forma más sostenible a nuestros objetivos de negocio? La tecnología, sea propia o adquirida, es un medio y no un fin; la verdadera ventaja competitiva surge de cómo la integramos, la escalamos y la ponemos al servicio de nuestra propuesta de valor. Quien logre equilibrar la velocidad del mercado con la solidez de su arquitectura interna, no solo responderá bien a la pregunta de “Buy vs. Build”, sino que estará mejor preparado para las preguntas que aún no se han formulado.

Contact us at y busquemos juntos la mejor alternativa para tu negocio.