Un piloto de cualquier producto puede funcionar. Este producto sale al mercado, el canal responde y las primeras operaciones llegan sin grandes problemas. Un primer éxito.
La siguiente fase es una pregunta: ¿podemos multiplicarlo sin multiplicar también los costes, los desarrollos específicos y la complejidad de lo que ya tenemos?
La respuesta radica en que la escalabilidad no consiste únicamente en soportar más volumen. También implica poder incorporar nuevos productos, canales, reglas y cambios sin reconstruir el modelo cada vez. No es crecer por crecer.
Por eso, quizá el mejor indicador no sea cuánto tardamos en lanzar el primero, sino qué ocurre cuando queremos lanzar el segundo. Parametrización, modularidad, integración y capacidad de adaptación son las piezas que permiten transformar un proyecto que funciona en un modelo capaz de crecer.
En este artículo desarrollaremos este último punto.
Que un piloto funcione no significa que el modelo escale
En nuestro sector es habitual vivir situaciones como la siguiente: se lanza un piloto, el producto funciona, el canal lo acepta y los primeros clientes llegan. Conclusión: el proyecto cumple las expectativas iniciales.
Son, evidentemente, buenas noticias … .hasta que damos el salto a la siguiente fase y llega el momento de crecer.
¿Qué puede ocurrir ? Pues que descubrimos que una modificación aparentemente sencilla exige desarrollo. Que el segundo canal necesita una integración prácticamente nueva. Que algunas incidencias se estaban resolviendo manualmente. Que determinadas excepciones dependían del conocimiento de dos o tres personas. O que procesos que funcionaban con unos pocos miles de operaciones empiezan a tensionarse cuando el volumen aumenta.
Nada de esto significa necesariamente que el piloto estuviera mal diseñado. Ni mucho menos. Pero podríamos decir que significa que “pilotar” y “escalar” son dos pruebas diferentes.
Un piloto es para demostrar que una idea puede funcionar. Cuando se escala el objetivo es ver si esa idea (que el piloto ha demostrado que funciona) puede repetirse, evolucionar y operar con eficiencia.
NOTA: En otro artículo ya se comentó esta “tensión” entre estos dos conceptos de volumen y operación. Ver el artículo “Seguros masivos: el verdadero factor de escala es la tecnología”.
La diferencia fundamental se resume en esta frase: soportar más operaciones no es lo mismo que estar preparado para evolucionar.
La pregunta importante: ¿qué ocurre la segunda vez?
Hay una pregunta sencilla que puede revelar mucho sobre la escalabilidad de un proyecto:
¿Qué ocurre cuando tenemos que hacerlo otra vez?
Lanzar un primer producto (a través de un piloto, por ejemplo) puede requerir un esfuerzo extraordinario. Esfuerzo que puede incluir: un equipo dedicado, una integración específica con otras herramientas propias o ajenas, determinados desarrollos a medida e incluso algunos procesos manuales provisionales. Y podríamos seguir.
Pero es habitual, es razonable. Al fin y al cabo, estamos probando.
Ahora bien, ¿qué sucede con el segundo producto?
¿Podemos reutilizar lo construido de alguna manera? ¿Las reglas se parametrizan para poder ser más eficientes? ¿Podemos incorporar otro canal sin rehacer la integración desde cero? ¿Las nuevas condiciones pueden configurarse o deben entrar otra vez en una cola de desarrollo?
Y después llega el tercero.
La repetibilidad es probablemente uno de los mejores indicadores de escalabilidad porque obliga a mirar más allá del éxito inicial.
El primer lanzamiento demuestra que algo puede hacerse. El segundo, el tercero y el cuarto empiezan a demostrar si existe realmente un modelo.
Por eso, antes de escalar conviene cambiar ligeramente la pregunta. Mejor dicho, conviene hacerse siempre dos preguntas muy complementarias. La primera :“¿aguantará más volumen?”, y la segunda: “¿será cada nueva evolución más sencilla o más complicada que la anterior?”.
El verdadero time-to-market empieza después del primer lanzamiento
Habitualmente entendemos el concepto de time-to-market como el tiempo necesario para llevar una idea al mercado. O sea lanzarlo.
Pero en la sección anterior hemos enfatizado los consecutivos lanzamientos: un primero, después un segundo, luego un tercero…..Esto es importante porque el time-to-market debe estar claro pues puede resultar engañoso si únicamente medimos la primera salida.
Si nos quedamos en la “primera salida” una organización puede conseguir un lanzamiento rápido si realiza un esfuerzo excepcional a todos los niveles. Lo difícil es convertir esa velocidad en una capacidad permanente.
NOTA: En el artículo “Time to market en seguros: acelerar innovación e inclusión” ya planteábamos precisamente el valor de contar con una arquitectura preparada para crear productos, integrarse con terceros y operar en diferentes canales sin depender permanentemente de grandes proyectos a medida.
La cuestión es llevar esa idea del time-to-market un paso más allá.
El verdadero time-to-market de una organización no debería medirse únicamente preguntando:
¿Cuánto tardamos en lanzar este producto?
También deberíamos preguntar:
¿Cuánto tardaremos en lanzar el siguiente aprovechando lo que ya hemos construido?
Aquí está la diferencia: velocidad puntual y agilidad estructural.
Si cada lanzamiento vuelve a empezar prácticamente desde cero, quizá somos rápidos ejecutando proyectos. Pero todavía no hemos construido una verdadera capacidad para escalar.
Los gaps que convierten crecimiento en complejidad
Avancemos en la temática que estamos tratando y cambiemos el punto de vista.
Cuando un modelo empieza a evolucionar aparecen brechas entre lo que negocio quiere hacer y lo que la operación o la tecnología pueden resolver de forma estándar. Es lo que popularmente llamaríamos “la teoría es una cosa y la práctica otra bien distinta”
Por ejemplo: Un nuevo producto requiere una excepción. Un canal utiliza un formato diferente al anterior. Una regla comercial no puede configurarse como la previa. Una renovación necesita un flujo específico que no estaba contemplado. Una integración requiere desarrollo desde cero. Un proceso que no estaba previsto acaba resolviéndose manualmente.
Cada uno de estos gaps puede parecer pequeño. El problema aparece cuando se acumulan.
Cada excepción añade coste en el presente, pero también puede añadir complejidad al siguiente cambio. Una adaptación específica genera otra dependencia. Una integración construida exclusivamente para un canal puede dificultar la siguiente. Un proceso manual provisional termina convirtiéndose en permanente porque “siempre se ha hecho así”.
¿Estamos escalando el negocio o estamos acumulando excepciones…que frenarán esta escalada?
Esa pregunta es especialmente relevante en modelos masivos, donde cualquier fricción pequeña se multiplica por el volumen.
NOTA: Como analizamos en “Escala con control: cómo operar seguros masivos digitales de forma eficiente y confiable”, lanzar rápido es solo el primer paso. Cuando aumenta el volumen, sostener eficiencia, control y continuidad operativa se convierte en la verdadera prueba.
Modularidad, adaptabilidad e integración: la arquitectura de la escala
Si hay algo que tambien debemos destacar es que la tecnología tiene, en estos procesos, un papel “diferente”.
¿En qué sentido? No se trata simplemente de disponer de más funcionalidades (que no es malo). Se trata de construir sobre una base capaz de cambiar.
¿Y qué quiere decir “cambiar”? Entre otras cosas disponer de una tecnología que:
- permite incorporar componentes y capacidades sin obligar a reconstruir el conjunto.
- es adaptable y permite configurar productos, reglas y procesos para responder a nuevas necesidades.
- y que es integrable y permite convivir con algo fundamental: lo que ya existe.
Porque prácticamente ningún proyecto asegurador parte de una hoja en blanco. Hay sistemas corporativos, core aseguradores, CRMs, aplicaciones, canales digitales, sistemas financieros, aseguradoras y herramientas de terceros que deben seguir funcionando. Y los conceptos de incorporar, adaptar e integrar son imprescindibles.
Así que, en efecto, la escalabilidad depende también de la capacidad para integrarse con ese ecosistema que ya existe.
NOTA: SegNeurona es un ejemplo claro. Sus características y funcionalidades reflejan y son coherentes precisamente con este planteamiento: integración con sistemas corporativos y aseguradoras, configuración y gestión de productos, automatización de intercambios de información para grandes volúmenes, APIs y servicios web, integración con aplicaciones de terceros y capacidad para adaptarse a modelos de negocio escalables. (1)
La relevancia de estas capacidades no está en la tecnología en sí misma. Está en lo que permiten evitar y que permiten potenciar la escalabilidad: menos desarrollos específicos, menos dependencias, menos distancia entre lo que negocio necesita y lo que operaciones y tecnología pueden ejecutar, etc…
Cuando negocio, operación y tecnología hablan idiomas distintos
Un punto que es interesante destacar, y que ilustra la importancia de todo lo que rodea a la “integración”, es el siguiente. En muchas organizaciones, un cambio aparentemente sencillo empieza así:
- Negocio plantea una necesidad.
- El departamento de operaciones analiza cómo ejecutarla.
- Y el departamento de tecnología y desarrollo determina qué debe modificarse.
Hasta aquí, completamente normal.Pero, ¿y si cada nueva necesidad acaba convirtiéndose en un proyecto tecnológico específico ?
- Cambiar una cobertura.
- Añadir un distribuidor.
- Crear otra modalidad de cobro.
- Adaptar una regla.
- Incorporar una aseguradora.
- etc
Si cada evolución (necesaria porque debe cubrir esa necesidad) abre un proceso complejo entre negocio, operaciones e IT, el coste del cambio aumenta y el time-to-market se alarga.
Una plataforma tecnológica madura debería reducir precisamente esa distancia.
No significa eliminar desarrollo ni convertir cualquier cambio en algo inmediato.
Significa que una parte creciente de la evolución pueda resolverse mediante parametrización, componentes reutilizables, integraciones normalizadas y procesos ya preparados para adaptarse.
La escalabilidad se empieza a notar cuando la organización aprende y reutiliza ese aprendizaje en el siguiente lanzamiento.
Las preguntas que revelan si estamos preparados
Hemos visto varios aspectos relevantes: concepto de piloto vs escalabilidad, time-to-market y sus restricciones, la plataforma tecnológica y su modularidad, la importancia de la integración , etc
Pero, ¿hasta dónde podemos llegar? ¿estamos preparados?
No necesitamos una checklist de veinte puntos para empezar a detectar dónde están los límites. Basta con hacerse algunas preguntas incómodas :
- Si mañana queremos modificar una cobertura o una regla, ¿podemos parametrizarla y hacerlo rápidamente o necesitamos desarrollar ?
- Si incorporamos un segundo canal, ¿aprovechamos una arquitectura de integración existente o empezamos de nuevo?
- Si multiplicamos las operaciones, ¿qué procesos manuales se multiplicarán también?
- ¿Qué ocurre con las incidencias y las excepciones cuando dejan de ser diez y pasan a ser cientos?
- ¿El modelo está preparado únicamente para vender o también para cobrar, renovar, cancelar, atender y gestionar cartera?
- ¿Podemos ver y medir lo que ocurre durante todo ese proceso?
Y quizá la más reveladora y que hemos machacado a lo largo del artículo:
¿El siguiente lanzamiento será más sencillo que el anterior?
Si la respuesta sistemática es no, merece la pena analizar por qué. Puede que el problema no esté en la capacidad del equipo para ejecutar. Puede estar en la base, puede estar en la arquitectura sobre la que estamos intentando crecer.
Escalar no es simplemente hacer más. También es aprender.
Existe otra idea importante: escalar no debería consistir ÚNICAMENTE en reproducir más veces exactamente lo mismo. Y a estas alturas está quedando bastante claro que el adverbio anterior debe ir en mayúsculas.
Escalar es evolucionar y está intrínsecamente ligado al aprendizaje. Es decir, un modelo que aprende debería mejorar. Porque es de sentido común.
Después de un lanzamiento sabemos más, aprendemos sobre el producto, el canal, la conversión, las incidencias, la atención, las renovaciones y el comportamiento de la cartera.
Ese conocimiento debería permitir ajustar y mejorar la siguiente mejora del producto. ¿Por qué?
Porque seguro que podremos, entre otras cosas:
- Parametrizar mejor una regla.
- Eliminar una tarea manual que aún seguía presente.
- Automatizar una excepción recurrente.
- Mejorar una integración.
- Añadir un indicador.
- Adaptar el producto.
La escalabilidad tiene, por tanto, una dimensión de volumen, pero también una dimensión de aprendizaje. De mejora continua.
Por eso, una arquitectura tecnológica preparada para escalar debe permitir cambiar sin poner en riesgo lo que ya funciona.
NOTA: Esa idea es también uno de los ejes de la “Time-to-Market y Escalabilidad en Seguros: Guía Operativa para Latam”, donde se plantea la necesidad de pasar del primer lanzamiento a una capacidad continua para iterar y crecer.
Así, nuestra conclusión es clara: el objetivo no es simplemente lanzar más. Es conseguir que cada lanzamiento aproveche mejor todo lo aprendido anteriormente.
Conclusión: Del proyecto a la plataforma
Un piloto puede gestionarse como un proyecto. Tiene un principio, un equipo, unos objetivos y un lanzamiento.
Pero un negocio masivo necesita algo distinto.
Necesita una plataforma sobre la que puedan aparecer nuevos productos, nuevos canales y nuevas reglas sin que cada evolución implique reconstruir la base.
En este contexto, plataformas como SegNeurona aportan una arquitectura preparada para gran distribución, retail y entidades financieras, con capacidades de configuración de productos e integración con sistemas corporativos, aseguradoras y aplicaciones de terceros. (1)
Nuestro mantra es claro: el valor no está únicamente en lanzar.Está en poder volver a hacerlo. Y volver a hacerlo mejor.
Porque cuando cada evolución necesita prácticamente un nuevo proyecto, quizá el problema no sea la velocidad de ejecución. Quizá debamos revisar la propia arquitectura del modelo.
Un modelo realmente escalable debería conseguir que el siguiente lanzamiento sea más fácil que el anterior, no más difícil.
Infografía
FAQs / Preguntas y respuestas frecuentes
¿Qué diferencia un piloto exitoso de un modelo escalable?
Un piloto demuestra que una propuesta puede funcionar en unas condiciones determinadas. Un modelo escalable demuestra además que puede aumentar volumen, evolucionar e incorporar cambios sin multiplicar costes y complejidad.
¿Por qué la parametrización es importante?
Porque permite resolver una parte de los cambios de producto, reglas o procesos mediante configuración y reduce la dependencia de desarrollos específicos.
¿Qué significa realmente mejorar el time-to-market?
No solo lanzar rápidamente el primer producto. También reducir el esfuerzo necesario para lanzar el segundo, introducir cambios o incorporar nuevos canales.
¿Por qué es importante la modularidad?
Porque facilita evolucionar por componentes y adaptar la solución a nuevas necesidades sin tener que reconstruir todo el modelo.
¿Por qué la integración con sistemas existentes es crítica?
Porque aseguradoras, bancos y distribuidores ya disponen de ecosistemas tecnológicos propios. Escalar requiere convivir con ellos y conectar nuevas capacidades sin sustituir innecesariamente lo que ya funciona.
¿Cuál puede ser una buena pregunta para evaluar la escalabilidad?
Una especialmente útil es: “¿El siguiente lanzamiento será más sencillo que el anterior?”. Si cada evolución exige empezar prácticamente de cero, existen barreras estructurales que conviene revisar.