Por qué fracasan los proyectos de telemática, y cómo evitar que le pase al suyo

En algún lugar de su organización puede que ya haya un sistema que no usa nadie. Instalado con intención sincera, interesante durante poco, y luego reducido en silencio a una línea de suscripción que aparece una vez al año y se renueva porque cancelar parece más trabajo.

Ocurre con frecuencia, y casi nunca porque fallara la tecnología. Estas son las siete razones, por orden de frecuencia, y lo que previene realmente cada una.

1. Nadie se responsabiliza

El mejor predictor aislado del fracaso.

Un patrocinador impulsa la compra. La instalación termina. El patrocinador pasa al siguiente asunto. Nadie responde del resultado, solo de la implantación, que ya ha concluido.

La solución: designe a una persona responsable de producir los beneficios, no la instalación. Déle tiempo: una asignación real, no un añadido a una carga ya completa. Ponga los indicadores en sus objetivos. Evalúela por ellos cada trimestre. Si no se puede nombrar a nadie, el proyecto no está listo para empezar, y saberlo ahora es más útil que saberlo dentro de dieciocho meses.

2. Los datos se recogen y nunca se usan

Se generan informes. Llegan por correo. Se abren de vez en cuando. No cambia nada, así que no mejora nada.

La tecnología encuentra los problemas. Solo las personas los resuelven. Un sistema sin proceso de intervención se queda con los beneficios pasivos — exoneración, avisos de robo, visibilidad básica — y renuncia a la mayor parte del valor.

La solución: establezca un ritmo antes del arranque y hágalo lo bastante pequeño para sobrevivir al contacto con la realidad. Un cuarto de hora semanal de excepciones. Una conversación mensual de acompañamiento con los tres conductores que más lo necesiten. Una revisión trimestral de rutas. Póngalos en la agenda como compromisos recurrentes con un responsable con nombre. Modesto y constante gana a ambicioso y abandonado, siempre.

3. A la plantilla nunca se la implicó

El sistema llega por anuncio. Los conductores concluyen que no se confía en ellos. La adhesión se hunde, los conflictos se multiplican y, en casos extremos, la gente sortea el sistema deliberadamente.

La solución: consulte antes de cerrar la decisión, no después. Involucre a representantes de los conductores en la redacción de la política. Enséñele a la gente el sistema real en lugar de describirlo. Comprométase por escrito a cómo se usarán y no se usarán los datos, y cúmplalo de forma absoluta. Úselo de forma visible para defender a las personas antes de usarlo nunca para cuestionarlas. E informe a los mandos: un responsable que llama a un conductor por una pausa de nueve minutos echa a perder meses de trabajo.

4. Exceso de alertas

Se activa todo a la máxima sensibilidad porque todo suena útil. La primera semana llegan miles de notificaciones. En un mes ya nadie las lee, incluidas las que importan.

La solución: empiece con tres alertas, no con treinta. Elija las que estén ligadas a una decisión que alguien vaya a tomar de verdad. Revise el volumen a las dos semanas y ajuste los umbrales, en especial los de eventos bruscos, casi siempre mal puestos para el tipo de vehículo en la primera configuración. Amplíe de forma deliberada, una adición cada vez. Y esté igual de dispuesto a desactivar cosas.

5. Nunca se integró

Los datos se quedan en su propio sistema, tras su propio acceso, y nunca entran en el proceso que debían mejorar. Alguien pasa cifras a una hoja de cálculo cada mes. Cuando esa persona se va, los informes se detienen sin ruido.

La solución: identifique las dos o tres conexiones que más importan — normalmente planificación de trabajos, mantenimiento y finanzas — y trátelas como parte de la implantación, con presupuesto y responsable, no como una fase posterior. Una fase dos que no está financiada ni planificada es una fase que no va a ocurrir.

6. Nunca se definió el éxito

No se tomó ninguna línea de partida. Doce meses después nadie puede demostrar el beneficio, así que la renovación se convierte en una discusión de impresiones en vez de un examen de pruebas, y las impresiones favorecen al más escéptico.

La solución: tome la línea de partida antes de la instalación. Combustible por kilómetro. Colisiones por millón de kilómetros. Coste de siniestros a tres años. Días hasta notificar. Utilización. Inmovilizaciones. Pérdidas. Horas administrativas. Cuesta una tarde y no se puede reconstruir después. Después acuerde por escrito las tres cifras que definirán el éxito y la fecha en que se revisarán. Cómo convertirlas en un caso que resista el escrutinio se expone en la guía para construir un caso de negocio de telemática.

7. Solo se compró la tecnología

Se aprobó la suscripción. El tiempo interno para llevar el programa, no. El acompañamiento, la revisión y el cambio de procesos se dieron por hechos dentro de la carga existente, y no cupieron.

La solución: incluya los recursos internos en el caso de negocio de forma explícita, como coste. Lo hace más prudente y más creíble, y hace que el recurso exista de verdad. Un programa sin tiempo asignado entregará los beneficios pasivos y ninguno de los activos, lo que puede seguir siendo positivo, pero es un retorno bastante menor, y el caso de negocio debería haberlo dicho.

Los siete modos de fallo están en el mismo sitio: entre lo que el sistema registra y lo que alguien hace con ello.

Lo que tienen en común los programas que funcionan

Comparten una lista corta de rasgos, y ninguno es técnico:

• Un responsable designado con tiempo, evaluado por resultados
• Un ritmo pequeño y sostenible de revisión e intervención que sobrevive a las semanas cargadas
• Una plantilla a la que se consultó, y un compromiso por escrito que se cumplió
• Una configuración inicial restringida que se amplió de forma deliberada
• Una línea de partida, y la disciplina de medirse contra ella
• Dos o tres integraciones que llevan los datos a donde la gente ya trabaja
• Una revisión a los doce meses que examina pruebas en vez de impresiones

El tercero de ellos es el que más se salta y el más difícil de recuperar, porque mantener la confianza sale más barato que reconstruirla. Hay más sobre esto en cómo presenta la plataforma los datos del conductor.

La prueba de los seis meses

Ponga una fecha en la agenda seis meses después del arranque y responda con honestidad a tres preguntas:

1. ¿Qué decisiones hemos tomado que no habríamos tomado sin esto?
2. ¿Qué ha cambiado de forma medible respecto a la línea de partida?
3. ¿Quién ha hecho el trabajo, y sigue teniendo tiempo para continuar?

Si las respuestas son pobres, el problema es casi con seguridad una de las siete razones anteriores, y las siete se recuperan a los seis meses. A los tres años, cuando llega la renovación y ya nadie recuerda para qué era, son bastante más difíciles de arreglar.

Las preguntas que conviene hacer a un proveedor antes de que todo esto empiece se exponen en la guía de compra de tecnología para flotas.