Porque falham os projetos de telemática — e como garantir que o seu não falha

Algures na sua organização poderá já existir um sistema que ninguém usa. Instalado com intenção genuína, interessante por pouco tempo, e depois reduzido discretamente a uma linha de subscrição que aparece uma vez por ano e é renovada porque cancelar parece dar mais trabalho.

Acontece com frequência, e quase nunca por a tecnologia ter falhado. Aqui ficam as sete razões, por ordem de frequência, e o que evita realmente cada uma.

1. Ninguém é responsável

O mais forte indicador isolado de fracasso.

Um patrocinador impulsiona a compra. A instalação termina. O patrocinador passa ao assunto seguinte. Ninguém responde pelo resultado — apenas pela implementação, que já acabou.

A solução: designe uma pessoa responsável por produzir os benefícios, não pela instalação. Dê-lhe tempo — uma afetação real, não um acréscimo a uma carga já cheia. Ponha os indicadores nos seus objetivos. Avalie-a por eles trimestralmente. Se ninguém puder ser nomeado, o projeto não está pronto para arrancar, e sabê-lo agora é mais útil do que daqui a dezoito meses.

2. Os dados são recolhidos e nunca usados

São gerados relatórios. Chegam por e-mail. São abertos de vez em quando. Nada muda, logo nada melhora.

A tecnologia encontra os problemas. Só as pessoas os resolvem. Um sistema sem processo de intervenção fica com os benefícios passivos — ilibação, alertas de furto, visibilidade básica — e abdica da maior parte do valor.

A solução: estabeleça um ritmo antes do arranque e torne-o pequeno o suficiente para sobreviver ao confronto com a realidade. Um quarto de hora semanal sobre exceções. Uma conversa mensal de acompanhamento com os três condutores que mais precisam. Uma revisão trimestral de percursos. Coloque-as na agenda como compromissos recorrentes com um responsável identificado. Modesto e consistente ganha a ambicioso e abandonado, sempre.

3. As equipas nunca foram envolvidas

O sistema chega por anúncio. Os condutores concluem que não confiam neles. A adesão desaba, os litígios multiplicam-se e, em casos extremos, as pessoas contornam o sistema deliberadamente.

A solução: consulte antes de a decisão estar fechada, não depois. Envolva representantes dos condutores na redação da política. Mostre às pessoas o sistema real em vez de o descrever. Comprometa-se por escrito quanto à forma como os dados serão e não serão usados, e cumpra-o em absoluto. Use-o visivelmente para defender as pessoas antes de alguma vez o usar para as questionar. E informe as chefias — um responsável que telefona a um condutor por causa de uma pausa de nove minutos deita meses de trabalho a perder.

4. Excesso de alertas

Liga-se tudo na sensibilidade máxima porque tudo parece útil. Na primeira semana chegam milhares de notificações. Ao fim de um mês já ninguém as lê, incluindo as que importam.

A solução: comece com três alertas, não com trinta. Escolha os que estão ligados a uma decisão que alguém vai mesmo tomar. Reveja o volume ao fim de duas semanas e afine os limiares — em especial os de eventos bruscos, quase sempre errados para o tipo de veículo na primeira configuração. Alargue deliberadamente, uma adição de cada vez. E esteja igualmente disposto a desligar coisas.

5. Nunca foi integrado

Os dados ficam no seu próprio sistema, atrás das suas próprias credenciais, e nunca entram no processo que deviam melhorar. Todos os meses alguém copia números para uma folha de cálculo. Quando essa pessoa sai, os relatórios param em silêncio.

A solução: identifique as duas ou três ligações que mais importam — normalmente planeamento de trabalhos, manutenção e finanças — e trate-as como parte da implementação, com orçamento e responsável, e não como uma fase posterior. Uma fase dois que não está financiada nem calendarizada é uma fase que não vai acontecer.

6. O sucesso nunca foi definido

Não foi registada qualquer base de partida. Doze meses depois ninguém consegue demonstrar o benefício, pelo que a renovação passa a ser uma discussão de impressões em vez de um exame de provas — e as impressões favorecem quem for mais cético.

A solução: registe a base de partida antes da instalação. Combustível por quilómetro. Colisões por milhão de quilómetros. Custo de sinistros a três anos. Dias até à participação. Utilização. Imobilizações. Perdas. Horas administrativas. Leva uma tarde e não pode ser reconstruída depois. Acorde depois por escrito os três números que definirão o sucesso e a data em que serão revistos. Como transformar isso num argumento que resiste ao escrutínio está exposto no guia para construir um argumento de investimento em telemática.

7. Só a tecnologia foi comprada

A subscrição foi aprovada. O tempo interno para conduzir o programa não. O acompanhamento, a revisão e a mudança de processos foram dados como cabendo na carga existente, e não couberam.

A solução: inclua explicitamente os recursos internos no argumento de investimento, como custo. Torna-o mais prudente e mais credível, e garante que o recurso existe mesmo. Um programa sem tempo atribuído entregará os benefícios passivos e nenhum dos ativos — o que pode continuar a ser positivo, mas é um retorno bastante menor, e o argumento devia tê-lo dito.

As sete formas de falhar estão no mesmo sítio: entre o que o sistema regista e o que alguém faz com isso.

O que os programas bem-sucedidos têm em comum

Partilham uma lista curta de características, e nenhuma delas é técnica:

• Um responsável designado com tempo, avaliado por resultados
• Um ritmo pequeno e sustentável de revisão e intervenção que sobrevive a semanas cheias
• Equipas que foram consultadas, e um compromisso escrito que foi cumprido
• Uma configuração inicial restrita que foi alargada deliberadamente
• Uma base de partida, e a disciplina de medir em relação a ela
• Duas ou três integrações que levam os dados para onde as pessoas já trabalham
• Uma revisão aos doze meses que examina provas em vez de impressões

O terceiro destes é o mais vezes saltado e o mais difícil de recuperar, porque manter a confiança sai mais barato do que reconstruí-la. Há mais sobre isso em como a plataforma apresenta os dados do condutor.

O teste dos seis meses

Marque uma data seis meses após o arranque e responda honestamente a três perguntas:

1. Que decisões tomámos que não teríamos tomado sem isto?
2. O que mudou de forma mensurável face à base de partida?
3. Quem fez o trabalho, e continua a ter disponibilidade para o manter?

Se as respostas forem fracas, o problema é quase de certeza uma das sete razões acima — e as sete recuperam-se aos seis meses. Aos três anos, quando chega a renovação e já ninguém se lembra para que servia, são bastante mais difíceis de corrigir.

As perguntas que vale a pena fazer a um fornecedor antes de tudo isto começar estão expostas no guia de compra de tecnologia para frotas.