Cuando un cliente pregunta cuánto demora implementar Abordo, la respuesta corta es "depende, pero menos de lo que crees". La respuesta larga implica explicar el plan en 6 fases que aplicamos en cada despliegue, porque entender el plan es entender por qué el riesgo es manejable, no porque el sistema sea simple sino porque el orden de las cosas está pensado.
La idea central es contraria al reflejo intuitivo: el 80% del sistema se construye y valida antes de tocar el bus. Eso suena raro para un producto que vive en un vehículo, pero es lo que hace la diferencia entre un piloto que termina bien y uno que se tropieza en producción.
Por qué no empezar por el hardware
El reflejo natural sería: "compremos el equipo, instalémoslo en un bus y veamos qué pasa". Es la peor forma de implementar un APC. Tres razones:
- Si algo del software no funciona, ya tienes hardware comprometido en un vehículo en operación. Cualquier iteración requiere parar el bus o trabajar con condiciones difíciles.
- No tienes con qué validar. Sin un sistema de referencia bien probado, comparar contra qué cosa.
- Las decisiones de calibración óptimas no se conocen hasta que el resto está construido. Saber dónde poner la cámara, qué ángulo, qué umbrales — todo eso necesita haber pensado primero el pipeline completo.
Por eso construimos al revés. Primero los datos, después el modelo, después la integración, al final el hardware.
Fase 1: contrato de datos
Antes de cualquier línea de código de visión, lo primero que se construye es el contrato de datos: el esquema que el sistema va a manejar. ¿Qué tabla guarda los eventos? ¿Qué columnas tiene un boleto emitido? ¿Qué identifica a un tramo del recorrido? ¿Cómo se vincula un evento de conteo con la ruta y el chofer?
Este es trabajo de ingeniería de datos con Supabase. Resultado de la fase: un esquema de base de datos y una API de ingesta que puede recibir eventos desde un bus simulado. Sin esto, nada del resto encaja.
Duración típica: 1-2 semanas.
Fase 2: visión
El segundo paso es construir el contador de personas, pero probándolo contra video grabado —no contra el bus real. Conseguimos secuencias de video de buses interurbanos (propias, de pilotos previos, o sintéticas), las usamos para validar que YOLO + ByteTrack producen conteos consistentes con conteos manuales hechos a mano sobre los mismos videos.
Esto permite afinar el pipeline en tiempo controlado: probar distintas calibraciones de la línea virtual, ajustar umbrales de confianza del detector, optimizar el seguimiento. Cuando llegamos al bus real, el modelo ya tiene una base sólida; solo falta calibrarlo a la geometría específica del vehículo.
Duración típica: 2-3 semanas, en paralelo con Fase 1.
Fase 3: reconciliación
Una vez que tenemos eventos de conteo (aún sintéticos o de video grabado) y datos de boletos, construimos el motor de reconciliación. Es la pieza menos visible del producto y la más valiosa: cruza la curva de ocupación medida con la curva de boletos emitidos, tramo a tramo, y produce métricas accionables.
Lo importante de hacerlo en esta fase, antes del piloto en terreno, es que entrenamos el motor con datos sintéticos donde nosotros mismos generamos los eventos. Eso nos permite verificar que la lógica de reconciliación entrega los puntajes de riesgo correctos en escenarios controlados: si los eventos dicen "subió 1 sin boleto", la métrica de riesgo debe subir; si no, hay un bug.
Duración típica: 1-2 semanas.
Fase 4: dashboard
Con el motor produciendo métricas, ya hay algo que mostrar. El dashboard se construye antes que el bus físico esté en operación, lo cual tiene una ventaja importante: el cliente puede empezar a familiarizarse con la herramienta usando datos sintéticos, navegar las pantallas, dar feedback de UX. Cuando llegan los datos reales, no hay sorpresas.
Esta fase también permite descubrir si hay reportes o vistas que el cliente necesita y que no habíamos considerado. Ajustar el dashboard sobre datos simulados es mucho más barato que ajustarlo después.
Duración típica: 1-2 semanas, en paralelo con Fase 3.
Fase 5: integración con boletaje
Cada cliente tiene un sistema de pasajes distinto: algunos usan plataformas comerciales, otros sistemas internos legacy, otros mezcla de ambos. Antes de instalar el bus, construimos el adaptador específico que lee los boletos emitidos del sistema del cliente y los inyecta en nuestra base.
Esta fase es donde típicamente aparecen los detalles que nadie anticipó: formatos de fecha distintos, identificadores de ruta que cambian entre módulos, campos que vienen vacíos parte del tiempo. Cubrirla antes del terreno significa que el día que el bus empiece a emitir eventos, ya hay con qué cruzar.
Duración típica: 1-2 semanas. Variable según la complejidad del sistema del cliente.
Fase 6: terreno
Esta es la fase que la gente imagina como "el proyecto". Es la última, no la primera. Y para entonces el resto del sistema ya funciona end-to-end con datos sintéticos. Solo queda:
- Instalación física: una jornada de mecánico + eléctrico para montar la cámara, el computador, el GPS, el módem y conectar todo a la red eléctrica del bus.
- Calibración: ajustar la línea virtual a la geometría real de la puerta y validar que el pipeline corre fluido sobre el video en vivo.
- Validación con inspector: durante algunos viajes, un inspector hace conteo manual en paralelo al sistema. Comparamos las dos curvas y establecemos el margen de error real para este bus específico. Ese número entra a la documentación del despliegue.
- Activación: el bus pasa a producción y empieza a emitir eventos reales hacia el portal.
Duración típica: 1-2 semanas, incluyendo varios viajes de validación.
La línea de tiempo total
Sumando: las fases 1-5 pueden ocurrir en paralelo (con dependencias entre algunas) en 5 a 8 semanas. La fase 6 son 1-2 semanas adicionales. En total, de cero a un bus en producción real: 6 a 10 semanas.
Eso es para el primer cliente y el primer bus. Para clientes posteriores, las fases 1-3 ya están hechas (es el mismo software para todos). Solo se rehace la 5 (integración con su sistema) y la 6 (instalación + calibración). Eso baja típicamente a 3-4 semanas por cliente nuevo.
Cuando un cliente quiere escalar a más buses de su flota, solo se repite la fase 6. Cada bus adicional son típicamente 1-2 días de instalación + calibración.
Por qué este orden minimiza riesgo
La regla detrás del plan es simple: siempre tener algo que funcione antes de agregar una capa más. En cada fase hay un entregable verificable. Si algo se cae en la fase 3, ya tenemos fase 1 y 2 sirviendo. Nunca pasamos a la siguiente fase sin que la anterior esté validada.
En proyectos donde se hace al revés —comprar hardware primero, instalarlo, recién después ver qué hace— la mayor parte del tiempo se va en debug bajo presión, con el bus parado, con el cliente preguntando cuándo va a funcionar. En el plan al revés que usamos, llegar al bus es el último 20% del proyecto, no el primero.
Cierre
El plan no es burocracia. Es lo que separa un piloto que termina con datos reales y métricas confiables de uno que termina en frustración. Si un proveedor te ofrece instalar el sistema el primer mes y "ver cómo va", desconfía. Si te ofrece construir las piezas en orden lógico antes de tocar el bus, va por buen camino.
Sin importar si terminamos trabajando juntos o no, el plan en 6 fases vale para cualquier APC serio. Si vas a evaluar varias propuestas, úsalo como checklist para entender qué te ofrece cada proveedor.