Lo que aprendí intentando llevar una idea de hackatón hasta producción
En el primer artículo de esta serie, donde conté lo que aprendí compitiendo en dos hackatones internas de mi empresa, terminé haciéndome una pregunta aparentemente sencilla: ¿qué ocurre el lunes después de la hackatón?
Esta vez decidí averiguarlo.
En nuestra segunda hackatón trabajamos alrededor de un concepto que llamamos "Inteligencia Geográfica para Telcos". El nombre venía del contexto donde nació la idea, pero el problema de fondo no es exclusivo de las telecomunicaciones: le pasa a cualquier empresa que tenga clientes y direcciones. La premisa era simple. Casi siempre vemos la dirección de un cliente como un dato más, guardado en algún sistema. ¿Y si en cambio la tratáramos como un activo capaz de generar inteligencia de negocio?
Una ubicación puede ayudar a decidir dónde vender, dónde expandir cobertura, cómo atender mejor a un cliente o cómo optimizar operaciones en campo.
En el corazón de nuestra propuesta había algo menos espectacular que el nombre del proyecto, pero fundamental: una API capaz de traducir, normalizar y estandarizar direcciones, creando un lenguaje común entre sistemas que tradicionalmente manejaban esa información de formas diferentes, generando fuertes barreras.
El problema típico es trasladar al cliente la complejidad de digitar o entender una dirección, o convivir con diferentes formas de la misma Kra 15ª 25-56 Bis Ap 502, carrera 15 A # 25-56Bis apartamento 502, Cr 15-A Numero 25-56 VIS Apto 5-02, ¿cómo saber si hace referencia a un solo cliente? ¿Cuál es la oficial? ¿Cómo hacer que diversos sistemas sepan que es la misma?
Resuelto ello, imaginábamos algo más ambicioso: agentes apoyados en IA que entregaran información contextual a equipos comerciales y de servicio para ayudarles a tomar mejores decisiones en campo: quiénes viven allí, qué tecnología hay disponible, qué oportunidades comerciales o prospectos existen y qué problemas hay por resolver a nuestros clientes en ese lugar.
La idea no obtuvo uno de los lugares de honor entre las tres primeras: quizás no transmitimos bien la idea (el reto del pitch de 3 minutos), o bien los números que las sustentaban no ayudaron lo suficiente o quizás, la más cruda de mis teorías, el problema es tan agudo, tradicional y enquistado que pareciéramos haber aprendido a convivir con él. Pero seguía, sin embargo, pareciéndome una buena idea. Y ahí aprendí algo que desde entonces casi se convirtió en una máxima para mí: de nada sirve una idea maravillosa sin unas manos que la sepan ejecutar. No basta con tener la idea correcta; la empresa también tiene que generar el ambiente donde esa tecnología pueda aplicarse.
Así que decidí continuar.
Una idea empieza a crecer cuando deja de pertenecerte
Antes de la hackatón ya habíamos identificado un par de procesos donde esta capacidad podía generar valor. Una de reducción de tiempo en captura de hasta 3 minutos en canales y otra relacionada con la simplificación para hablar el lenguaje de las direcciones con un sistema de más de 30 años para el que había que memorizar reglas.
Durante el evento ocurrió algo todavía más interesante: personas de hiperautomatización y canales comenzaron a descubrir otros usos que nosotros no habíamos imaginado.
Ahí apareció una señal. Tal vez el verdadero valor estaba en construir una capacidad reutilizable que otros pudieran aprovechar.
Decidí entonces concentrarme en el corazón de la solución: convertir esa API de normalización y estandarización en un componente genérico que pudiera servir posteriormente a diferentes procesos.
Sonaba razonable. Incluso sencillo. Y entonces apareció la organización.
Del salón de juegos a los pasillos
Una hackatón se parece un poco a un gran salón de juegos creativos.
Durante unas horas las ideas corren con libertad. Se conversa, se prueba, se descarta, se vuelve a intentar y, algunos pasabocas y refrescos después, aquello que por la mañana era apenas una conversación empieza a parecer una solución.
Pero cuando una idea quiere convertirse en realidad debe abandonar aquel salón y entrar en los pasillos de la organización.
Primero había que formalizar la iniciativa. Había nacido en una hackatón y no había llegado siguiendo el proceso habitual de demanda y asignación de capacidades.
Después apareció arquitectura: ¿dónde encajaba ese componente?, ¿cómo debía integrarse? Sin esas respuestas difícilmente llegaría a fábrica.
Luego infraestructura: ¿dónde desplegarlo? Después financiación, estándares de implementación, seguridad y operación. Cada puerta conducía a otra.
Demanda. Arquitectura. Infraestructura. Presupuesto. Seguridad. Fábrica. Operación. Y entendí algo importante: ninguna de esas puertas estaba allí por capricho.
Cada una protege algo. Arquitectura evita nuevas islas. Seguridad protege información y operación. Demanda ordena prioridades. El presupuesto reconoce que los recursos son limitados.
El problema no eran las puertas. La pregunta era: ¿deben todas las ideas atravesar las mismas puertas, en el mismo orden y con las mismas reglas?
La puerta más compleja no era tecnológica
Algunos procesos que podían beneficiarse de la nueva capacidad ya tenían sistemas, responsables y formas establecidas de trabajar. Naturalmente, no todos estaban esperando que alguien apareciera con una idea nueva para cambiar lo que funcionaba.
Es frecuente escuchar “lo que funciona no se toca”, o “no creo que estemos preparados para ello”, o la mejor de todas: “ese tema ya se ha intentado cambiar y la verdad no ha sido posible”.
Es fácil llamarlo "resistencia al cambio". Con el tiempo he aprendido a desconfiar un poco de esa expresión.
Quien lleva años siendo responsable de que algo funcione tiene razones legítimas para protegerlo. Una nueva solución también introduce incertidumbre, trabajo y riesgos.
La innovación puede resultar fascinante para quien la propone y bastante menos romántica para quien tendrá que operarla el lunes siguiente.
Ahí aparece una dimensión que ninguna API resuelve: las personas.
Empecé a entender el cementerio de los ganadores
En mi artículo anterior hablaba, con algo de ironía, del "cementerio de los ganadores": iniciativas premiadas en hackatones anteriores que todavía no habían llegado a producción.
Después de intentar avanzar con la nuestra, empecé a mirarlas con otros ojos. Quizá aquellas ideas no estaban muertas. Tal vez simplemente seguían buscando la salida entre los pasillos de la organización.
Podemos crear espacios extraordinariamente ágiles para innovar y después pedirles a las ideas resultantes que continúen su viaje por procesos concebidos para iniciativas mucho más previsibles.
Es como construir un vehículo muy rápido y descubrir después que la carretera por la que debe circular tiene un límite de velocidad diferente. El vehículo no está mal. La carretera tampoco. Simplemente fueron diseñados bajo premisas diferentes.
Tal vez tengamos que innovar la forma de innovar
Si queremos aprovechar realmente las posibilidades de la Inteligencia Artificial, quizá no sea suficiente con organizar hackatones, crear laboratorios o capacitar personas.
También tendremos que revisar cómo recibimos una idea, la validamos, financiamos, protegemos, convertimos en producto y finalmente la escalamos.
Eso no significa eliminar gobierno, arquitectura o seguridad. Quizá significa construir caminos más inteligentes: una idea experimental podría recorrer un camino de tres etapas, con niveles de exigencia que crecen a medida que va demostrando su valor.
- Validación ligera: mecanismos rápidos y de bajo costo para probar si la idea tiene mérito.
- Incubación: si demuestra valor, empieza a sumar progresivamente arquitectura, seguridad, inversión y gobierno.
- Solución industrializada: la idea madura hasta cumplir con todos los estándares de la organización y opera como cualquier otra solución de producción.
Experimentar rápido no significa implementar irresponsablemente. Pero gobernar responsablemente tampoco debería significar experimentar lentamente.
Y también debemos preparar a las personas. No podemos pedir nuevas formas de pensar mientras dejamos intactos todos los roles, incentivos y procesos que sostienen las formas anteriores.
El próximo tren ya salió
El primer artículo de esta serie cerraba con la idea de subirnos al próximo tren, siempre que mantuviéramos la curiosidad y la disposición de aprender. Pues bien: ese tren ya salió.
La IA está reduciendo dramáticamente el tiempo necesario para imaginar, diseñar, prototipar y construir soluciones. Y eso está abriendo una nueva brecha.
No necesariamente entre quienes tienen IA y quienes no. Sino entre la velocidad a la que podemos crear y la velocidad a la que nuestras organizaciones pueden absorber lo creado.
Esa brecha puede convertirse rápidamente en un problema competitivo.
Porque mientras una buena idea recorre nuestros pasillos buscando arquitectura, presupuesto, capacidad y patrocinio, afuera puede haber alguien resolviendo el mismo problema sin tener que atravesarlos.
A lo largo de mi carrera en tecnología he visto pasar muchas olas: nuevas arquitecturas, Internet, reingeniería, movilidad, agilismo, nube y ahora Inteligencia Artificial. Cada una nos obligó a aprender algo nuevo.
Esta vez sospecho que el desafío será mayor: la próxima gran transformación quizá no consista solamente en adoptar Inteligencia Artificial. Quizá consista en transformar nuestras organizaciones para que sean capaces de seguirle el ritmo.
Y como decía al principio: de nada sirve una idea maravillosa sin unas manos que la sepan ejecutar.
Si en su organización hay buenas ideas buscando la salida entre los pasillos y puertas, me encantaría conversarlo. Escríbame o agendemos una sesión.
