Construir o comprar.
¿Qué estrategia es mejor para mi banca digital?
Construir internamente o comprar algo listo para implementar. Este es uno de los principales dilemas a los que se ven enfrentados directores, ejecutivos y product owners en la industria financiera. Te compartimos estos seis puntos para ayudarte a evaluar mejor la decisión.
Si hay algo cierto en la industria financiera, es que la digitalización llegó para cambiar varios de sus fundamentos. Llegaron nuevos competidores (fintechs y big techs) con soluciones digitales atractivas, simples y cercanas, aprovechando al nuevo cliente exigente y acostumbrado a los estándares de experiencia de usuario que generaron empresas como Facebook, Uber, Airbnb o Netflix.
“Si estas aplicaciones me ofrecen una experiencia totalmente personalizada, ¿por qué mi banco no puede hacerlo?”.
Iñigo Rumayor, CEO de Arcus, tiene gran experiencia colaborando con instituciones financieras y en nuestro podcast dejó una frase de oro, “si te demoras un año en ofrecer lo que tus clientes quieren, puede que cuando lo tengas ya estés fuera del juego”.
De ahí sale el dilema, ¿construir soluciones de manera interna o comprarlas a un proveedor?
En este white paper te dejamos algunos puntos para ayudarte a decidir cuál es el camino a tomar.
1. Control
La primera pregunta que debes hacerte es ¿qué tan core y esencial a mi negocio es esta solución que necesito? De eso dependerá la flexibilidad que puedes tener para tomar una solución lista para implementar o tomar el camino para desarrollar internamente.
Construir
Obtendrás una solución 100% a la medida, de tus necesidades y tendrás control total de los inputs y outputs del producto. Gran control trae gran responsabilidad.
Tendrás que hacerte cargo de todas las definiciones del producto, validaciones y benchmarks de industria, soporte, mantenimiento y ocuparte de escalar y evolucionar el producto.
Comprar
Debes evaluar varios proveedores y analizar qué tanto se acerca su solución a tus requerimientos y cuales de los esenciales están cubiertos. Pierdes control, pero puedes darle feedback a tu proveedor de cosas que necesitas, sin tener certeza de que se vayan a cumplir.
Si el proveedor resuelve sobre un 60% tus necesidades, la sugerencia sería comprar.
2. Costo
A la hora de priorizar proyectos, las variables principales a considerar son el impacto y el costo que tendrá el proyecto. Mientras el impacto es una variable que tiene cierto riesgo, los costos son más fáciles de calcular y estimar. Al hablar de costos nos referimos a cada etapa del ciclo de vida del producto: idea, validación, desarrollo, lanzamiento, evolución y mantenimiento.
Construir
Al construir tienes que hacerte cargo de todos los costos del proyecto, de inicio a fin. Esto significa el equipo de desarrollo, soporte, mantenimiento, infraestructura, certificaciones y validaciones. Un proyecto nuevo tiene riesgos de extenderse y esos costos los deberás asumir. Generalmente un proyecto de cero puede costar desde los cientos de miles a millones de dólares.
Comprar
Al tomar el software de un tercero, estás aprovechando el costo ya incurrido en diseñar, desarrollar, mantener y evolucionar el producto, todo a cambio de una tarifa anual o mensual. A medida que la cartera de clientes del proveedor crece, se van generando economías de escala y traspasarte esos ahorros a ti.
3. Time to value
En una industria que se mueve a gran velocidad, avanzar más lento puede significar quedarse fuera del juego. Elegir uno u otro camino determinará cuánto demores en salir al mercado, acortar estos tiempos impactará en cuándo organización genera y recibe valor.
Construir
Qué tan rápido saldrás al mercado dependerá de la cantidad de recursos que puedas destinar al proyecto para su definición, desarrollo y validación. Además, la salida a mercado dependerá de la cantidad de funcionalidades que quieres agregar a la versión 1.0 del producto.
Deberías estar pensando entre 9 y 12 meses para tener una versión 1.0 probándose con amigos y familia.
Comprar
Comprar una solución lista para integrar te ayudará a salir a mercado y generar valor a la organización mucho más rápido. Los tiempos más relevantes son el proceso de selección de proveedor, alta administrativa y tiempo de implementación.
Con esto puedes estar pensando en 3-6 meses.
4. Soporte y mantenimiento
Lograr un producto sin errores y que cubra el 100% de los casos borde es muy difícil. Esto solo se logra con mucho rodaje y tiempo. Cuando lanzas un producto, este tendrá bugs y errores que deberán ser atendidos. Es esencial considerar el soporte del producto para asegurar que este se mantenga funcionando correctamente ante cualquier escenario.
Construir
Un equipo interno deberá hacerse cargo de dar soporte al producto de punta a punta. Esto significa resolver incidencias en la experiencia de usuario, infraestructura, integraciones, mensajería y paneles de seguimiento.
A medida que el producto crece en funcionalidades y usuarios, estos problemas y requerimientos incrementan.
Comprar
El producto comprado ya tiene cubierto y resuelto una amplia gama de escenarios y casos borde que puedan generar incidencias. El proveedor elegido se encarga de todo el soporte de acuerdo a los SLAs exigidos por la organización, asegurando que el producto se mantenga operativo, incluso a medida que el producto crece y escala a vol existe un crecimiento.
A medida que el producto crece y escala, el proveedor se asegura que el producto no se vea afectado, quitando la responsabilidad de la organización de este tema.
5. Evolución y mejoras
Un producto debe ser pensado como un ser vivo, que evoluciona, crece y mejora a medida que pasa el tiempo. Una buena práctica para incrementar la base de usuarios y retener a los existentes es lanzar una mejora cada 3 meses, una nueva funcionalidad cada 6 meses y un upgrade considerable una vez al año.
Construir
Se deben planificar las evoluciones que se quieren incorporar con anticipación para asegurar presupuesto y disponer de un equipo que vuelva a hacer todo el proceso de desarrollo de producto.
Muchas veces esto puede significar que entra un equipo nuevo que debe considerar una curva de aprendizaje del producto y su tecnología.
Comprar
El proveedor es especialista en su producto e industria y tiene un know how de gran profundidad, lo que le permite desarrollar un roadmap de productos y funcionalidades del cual la organización se puede beneficiar.
El equipo necesario para construir y priorizar este roadmap es mucho más acotado que si se tratase de un desarrollo.
6. Costo de oportunidad
El ancho de banda de los equipos técnicos está cada vez más acotado, por lo que los proyectos tienden compiten entre ellos por ganar prioridad y obtener recursos para implementar. Esto hace que elegir una cosa signifique dejar de hacer varias otras. ¿Cuál priorizas y cuál bajas?
Construir
El ancho de banda de los equipos de tecnología de las instituciones financieras está cada vez más acotado. Desarrollar un producto desde cero requiere cambiar el foco y dedicar un equipo a tiempo completo por varios meses, en vez de estar atendiendo otras necesidades más relevantes del banco y que no se pueden externalizar.
Comprar
Con esta estrategia el costo de oportunidad se reduce enormemente. Cuando se trata de una solución plug and play (lista para implementar), se puede aprovechar los desarrollos ya realizados por el proveedor, integrando la solución en pocos meses (entrando y saliendo) y dejando equipo disponible rápido para seguir con otro proyecto, en vez de tenerlos dedicados por meses o años a armar un solo producto.
¿Entonces qué me conviene?
Tomar una decisión sobre construir o comprar no es simple y requiere de un análisis de qué tan relevante o estratégico es el producto que se quiere, en qué situación se encuentra la institución y cuál es el trade off que está dispuesta a hacer, pensando en que la velocidad y la especialización son esenciales para triunfar en una industria que se mueve cada vez más rápido.
Ferrari vs Red Bull.
Un ejemplo de la vida real.
Construir o comprar no es solo una estrategia en el mundo de la tecnología, también sucede en industrias como el automovilismo.
La Formula 1 es una de las competencias deportivas más exigentes y competitivas del mundo, donde diez escuderías con dos pilotos cada una, corren por ganar el título de mejor piloto y mejor escudería.
Pero al adentrarse en este mundo, se identifican dos categorías de escuderías, las que construyen sus motores y las que compran sus motores. Un ejemplo de una escudería que construye sus propios motores es el famoso fabricante de autos italiano Ferrari. Ellos controlan de punta a punta todo lo que sucede en su motor y cómo optimizar el chasis, neumáticos y frenos para aprovechar el motor al máximo y ganar todos los años. Esto requiere especialización y un gran presupuesto para estar siempre a la vanguardia.
Del otro lado está Red Bull Racing, una escudería que ha tenido un inmenso éxito desde que comenzó. Recordemos que Red Bull es un fabricante de bebidas energéticas y que a través de su expertise en marketing se han involucrado en el mundo de los deportes.
Red Bull no desarrolla sus motores. Desde sus comienzos le compra sus motores a fabricantes como Renault (quien también tiene su escudería y es competencia directa de Red Bull) y Honda. Por supuesto que comprar un motor a un tercero le quita control a Red Bull sobre el rendimiento y dirección de la innovación que se haga, además de obligarlo a ajustar el auto al motor y no tener una sincronía máxima entre ambas partes.
Pero esto también trae sus ventajas, el capital requerido para empezar la escudería es mucho más bajo, el soporte y mantenimiento tampoco cae sobre Red Bull y el dinero que tiene puede destinarlo a marketing o contratar a los mejores pilotos.