En una empresa con operación real —un acopio, una flota, un depósito— un piloto no es una versión incompleta del sistema que imaginaste. Es un experimento acotado a un equipo o una sucursal, diseñado para responder una pregunta específica antes de comprometer todo el presupuesto. El problema es que antes de construir hay decisiones de alcance, integración y adopción interna que condicionan todo lo que viene después.
¿Qué problema estás resolviendo realmente?
La trampa más común es confundir el síntoma con el problema. Una empresa que pide un sistema para gestionar despachos puede estar describiendo, en realidad, un problema de coordinación entre depósito y transporte, de visibilidad sobre el stock, o de errores manuales al cargar un remito. Construir una solución sobre la descripción superficial puede resultar en algo que funciona pero no resuelve nada.
El costo de no responder esta pregunta a tiempo es alto en cualquier industria: según BCG, el 70% de los procesos de transformación digital en empresas no alcanza los objetivos que se propuso, casi siempre porque el proyecto se definió por lo que la tecnología podía hacer y no por el problema operativo real que había que resolver primero.
El piloto empieza en la definición del problema, no en la primera pantalla.
¿A quién le importa este problema primero?
No todos los equipos que van a usar un sistema tienen el mismo problema con la misma intensidad. Hay un área —despacho, administración, control de stock— que sufre el proceso actual con más fuerza, tiene menos alternativas manuales disponibles y está dispuesta a tolerar una solución imperfecta a cambio de resolver algo que le duele todos los días. Ese es el equipo que hay que entrevistar, observar y servir primero.
¿Qué necesita ser verdad para que esto funcione?
Antes de escribir una línea de código, conviene listar las hipótesis más riesgosas del proyecto. No las más evidentes, sino las que si resultaran falsas harían que todo lo demás perdiera sentido. Esas son las que el piloto necesita poner a prueba.
¿Cuál es el alcance mínimo real?
El alcance de un piloto no lo define lo que el sistema necesita para reemplazar todo lo anterior de una vez. Lo define la hipótesis que querés validar. Todo lo que no contribuye directamente a probar esa hipótesis es ruido que agrega costo, tiempo y resistencia al cambio sin generar aprendizaje.
La decisión más importante
La decisión más importante antes de construir un piloto no es tecnológica. Es saber qué pregunta querés que responda. Un piloto bien delimitado acelera más la adopción real que cualquier plan de implementación total desde el día uno.