Hace unos días, desde el Hub de Innovación Minera del Perú, tuvimos una conversación que me dejó varias ideas dando vueltas. Junto con André Sougarret y Andrés Rodríguez, de Alza Mining Technology, y startups que han tenido que llevar sus tecnologías a faena, hablamos de algo que en minería conocemos bastante bien: por qué una tecnología que se ve muy bien en una presentación puede encontrarse con una realidad completamente distinta cuando llega a la operación. Ese era precisamente el espíritu de la sesión: hablar menos de productos y más de lo que realmente ocurre cuando intentamos implementar tecnología en campo.
Uno de los aprendizajes que más me llamó la atención fue tremendamente simple. Una de las startups había avanzado con su piloto y recibido validaciones de distintas personas de la organización. Todo parecía encaminado hasta que apareció el feedback de un área importante que no había sido involucrada desde el inicio. El comentario era válido, pero llegó tarde y obligó a realizar retrabajos que nadie había previsto. La lección parece obvia después de escucharla: cuando piloteamos una tecnología, no basta con identificar al usuario; tenemos que entender todo el sistema de actores que hará posible —o imposible— que esa solución escale. Operaciones, mantenimiento, TI, seguridad, abastecimiento o quien corresponda no deberían aparecer cuando el piloto ya está terminando. Parte del diseño del piloto consiste justamente en descubrir quién debe estar sentado en la mesa desde el comienzo. Es consistente con una de las preguntas centrales de la sesión: qué necesita la tecnología del cliente —redes, energía, acceso, datos o personas— y quién se hace cargo cuando alguna de esas condiciones no existe.
El segundo aprendizaje me pareció incluso más interesante. A veces una startup llega a faena pensando que su tecnología resuelve un problema y vuelve descubriendo que puede resolver dos o tres. Estar físicamente en la operación permite observar cosas que desde afuera son difíciles de anticipar. Y aquí ocurre algo curioso: quien trabaja todos los días dentro de un proceso puede haberse acostumbrado tanto a él que ciertas oportunidades de mejora dejan de ser visibles. El que llega de afuera, precisamente porque no conoce todos los “siempre lo hemos hecho así”, puede hacer una pregunta distinta, conectar dos problemas o descubrir un uso para su tecnología que ni el propio desarrollador había imaginado. Pilotear también es observar. Y por eso una visita a faena puede terminar siendo tan valiosa como la prueba tecnológica misma.
Esto cambia bastante la manera en que deberíamos entender un piloto. Normalmente pensamos que su propósito es responder una pregunta relativamente sencilla: ¿la tecnología funciona o no funciona? Pero en realidad hay muchas otras preguntas ocurriendo al mismo tiempo. ¿Funciona en nuestras condiciones? ¿El operador la usa? ¿Qué infraestructura necesita? ¿Quién valida el resultado? ¿Qué capacidades deben quedar instaladas? ¿Qué tendría que cambiar para implementarla en otra operación? Y, sobre todo, ¿el valor que pensábamos que generaría realmente existe? No es casualidad que durante la sesión una parte importante de la conversación estuviera dedicada precisamente a qué falló en el primer despliegue, cómo se corrigió, cómo se convenció al operador y por qué algunos pilotos que funcionan nunca llegan a convertirse en contratos.
Aquí aparece una dimensión de la que creo que hablamos poco: durante el piloto también se construye el modelo de negocio. Evidentemente, antes de comenzar la empresa minera necesita cierta visibilidad sobre los costos futuros de una implementación, especialmente cuando existe un CAPEX relevante. Sería un error descubrir, después de un piloto exitoso, que escalar la solución cuesta varias veces más de lo esperado. Pero tampoco parece razonable exigir que una tecnología en desarrollo tenga completamente definido su precio final antes de haber validado cuánto valor genera realmente en la operación.
Es justamente durante el piloto cuando ambas cosas empiezan a encontrarse. La minera puede comprobar si el beneficio estimado existe y dimensionarlo mejor; mientras que la startup aprende cuánto cuesta implementar, soportar y escalar su solución en condiciones reales. Con esa información se puede afinar el precio, el modelo de implementación y hasta la propuesta de valor. Y aquí surge una posibilidad interesante: si la empresa minera compartió el riesgo de probar una tecnología cuando todavía existía incertidumbre, ¿por qué no pensar también en condiciones que reconozcan esa apuesta temprana? Pueden existir condiciones preferentes para futuros despliegues, acuerdos de escalamiento u otros mecanismos que permitan que quien ayudó a validar la solución también participe de parte del valor que contribuyó a construir.
Hay además algo mucho más cotidiano que puede definir el éxito o fracaso de estos procesos: entender con quién estamos trabajando. Una startup no es una gran compañía tecnológica en pequeño. Su estructura financiera es completamente diferente. Para un emprendimiento, ciclos de pago de 60, 90 o más días pueden hacer inviable un piloto, porque muchas veces el desembolso de la minera no es simplemente el pago posterior por un servicio prestado: son los recursos que la startup necesita para comprar componentes, movilizar al equipo e implementar la propia prueba. Si queremos trabajar con tecnologías en estadios tempranos, nuestros procesos administrativos también tienen que aprender a convivir con esa realidad.
Quizás por eso uno de los mayores aprendizajes de esta conversación es que pilotear no debería entenderse como abrirle temporalmente la puerta de una faena a una tecnología para ver si funciona. Es mucho más interesante que eso. Es un espacio de aprendizaje compartido donde se valida la tecnología, pero también se descubre valor, se alinean actores, se construye confianza y comienza a tomar forma un modelo de negocio que todavía no estaba completamente escrito.
Y tal vez ahí esté el cambio más importante: dejar de mirar el piloto como el último examen que debe aprobar un proveedor para convertirse en contrato y empezar a verlo como un espacio de co-construcción. Porque cuando trabajamos con tecnologías que todavía están madurando, la empresa minera no es solamente cliente y la startup no es solamente proveedor. Durante un tiempo, ambas están aprendiendo juntas. Y si sabemos diseñar bien ese espacio, el resultado puede ser mucho más valioso que demostrar que una tecnología funciona: podemos ayudar a construir una solución que realmente tenga posibilidades de escalar.
Pamela Antonioli De Rutté
Gerente general del Hub de Innovación Minera del Perú
[email protected]